【授業レポート】システム開発入門 第15週目：テストプレイで改善点を見つける

システム開発入門の第15週では、先週用意した操作シナリオを使い、クラスメイト同士でアプリをテストプレイしました。

操作する人が迷った場面を付箋に残し、フィードバックを具体的な修正プランへ変えるまでが今回の課題です。

テストプレイとは、作り手以外の人に実際の操作を試してもらい、想定した手順が伝わるか、迷いや入力ミスが起きないかを確かめる活動です。

プログラムがシナリオ通りに動くかだけでなく、使う人の立場から操作の分かりやすさを見直します。

作り手だけでは見つけにくい迷いを確かめる

授業のはじめに、田中先生はテストプレイの目的を次のように伝えました。

「プログラムは“書くだけ”では完成しません。実際に触ってもらい、感想や改善点をもらうことで、初めて価値が高まります。」
田中先生

作り手は操作方法を知っているため、説明がなくても次へ進めます。

一方、初めて触る人がどこで止まるかを観察すると、入力案内や画面の流れに足りないものが見えてきます。

ペアでテストプレイを実施

生徒はペアを組み、相手が作ったシナリオに沿ってアプリを操作しました。

操作中に気づいたことは、その場で付箋に書き留めます。

• 入力方法は分かりやすいか
• 表示されるメッセージの文言は適切か
• 想定外の操作をしたときに、どのような反応になるか

実際のテストでは、操作する側から次の声が上がりました。

「シナリオ通りに動くけど、Enterの前に何をすればいいか迷った」
生徒A

「ボタンがないから選択肢の入力が間違いやすかった」
生徒B

どちらも、プログラムの動作そのものではなく、次に何をすればよいかを伝える案内や入力方法に関する気づきです。

「分かりにくい」を具体的なフィードバックへ

テストプレイの後は、付箋をホワイトボードに貼り、全員でフィードバックを共有しました。

• タイトル画面に操作例を載せる
• 結果を表示した後、最初に戻れるようにする
• エラー時のメッセージを具体的にする

「“具体的に”がキーワード。『分かりにくい』だけでなく、『ここがこう分かりにくい』と伝えよう。」
田中先生

具体的なフィードバックにするには、「どの画面で」「何をしようとして」「何に迷ったか」を分けて伝えます。

今回の「Enterの前に何をすればいいか迷った」という声には、迷ったタイミングと内容が含まれているため、「入力ガイドを追加する」という修正案へつなげられます。

フィードバックを修正プランに変える

生徒は寄せられた指摘を整理し、改善点、重要度と難易度、修正する箇所と対応方法をワークシートに記入しました。

修正案を一度に並べるだけでは、どこから着手するかが曖昧になります。

そこで授業では、重要度と難易度を手掛かりに優先順位を付けました。

「まずは入力ガイドを追加、そのあと戻る機能を実装しよう」
生徒C

「エラーメッセージは例を出してみるといいかな」
生徒D

今回の授業で身につけた流れ

今回の実習は、次の四つの段階で進みました。

1. シナリオに沿って、作り手以外の人が操作する
2. 迷った場所や入力ミスが起きた場面を記録する
3. 場所と理由が伝わる言葉でフィードバックする
4. 重要度と難易度を整理し、修正プランを作る

発展的に学びたい場合は、仕様、テスト、小さな変更をつなぐ開発の実践も参考になります。

田中先生は、フィードバックを受け止めることと、指摘を改善プランへ変えることもエンジニアに必要だと授業を振り返りました。

次回は改善実装と最終チェックへ

次回の授業では、今回作った修正プランに沿ってアプリを直し、最終チェックを行います。

使う人の声を記録して終えるのではなく、具体的な修正へつなげることで、より迷いにくいアプリを目指します。