プロトタイプは、完成品を小さく作ることではなく、アイデアの不確かな部分を早く試すための試作品です。見た目が雑でも、確かめたい問いに答えられるなら役に立ちます。高校「情報」の問題解決では、最初から完成品を作るより、試して直す循環を早く回す考え方が重要です。
完成度ではなく「何を確かめたいか」で作る
学校行事の案内アプリを考えているとします。最初からログイン、地図、通知、デザインまで作る必要はありません。
「初めて使う人が目的の教室を迷わず探せるか」を確かめたいなら、紙に画面を描き、ボタンを押す代わりにページをめくるだけでも試せます。一方、「文字サイズが読みやすいか」を確かめたいなら、実際の画面サイズに近い表示が必要です。
プロトタイプの作り方は一つではなく、検証したい問いによって必要な忠実度が変わるのです。
低忠実度と高忠実度を使い分ける
初期段階では、紙・付箋・簡単な図などの低忠実度プロトタイプが向いています。大きな構成をすぐ変えられ、作り直しに抵抗が少ないからです。
アイデアが絞れてきたら、クリックできる画面模型や実際に動く一部機能など、より完成品に近い試作品へ進みます。ここでの目的は「だんだん豪華にする」ことではありません。次に確かめたい疑問が変わったから、必要な表現も変えるのです。
よくある失敗は試作品を作品として守ること
時間をかけてきれいな試作品を作ると、使う人から「この画面は分かりにくい」と言われても直したくなくなります。これでは、早く失敗して学ぶというプロトタイプの利点が消えます。
もう一つは、質問を決めずに人へ見せ、「どうですか？」と感想だけを集めることです。感想が良くても、必要な機能が使えるかは分かりません。
「この画面から予約完了まで迷わず進めるか」のように、観察したい行動を決めて試します。
紙で一回試す：図書館の本を探す画面
「本を探している生徒が、分類から棚の場所を見つける」仕組みを考えます。
- 紙にトップ画面を描く
- 「小説」「自然科学」「歴史」などの選択肢を置く
- 友達に「昆虫の本を探して」と頼む
- どこで止まったかだけを記録する
- 説明せずに使えなかった部分を直す
見た目の美しさより「利用者が次の行動を選べるか」を確認します。説明しなければ使えないなら、画面側の手がかりが不足しています。
プロトタイプで分からないこともある
紙の画面で操作の流れは試せても、通信速度、同時アクセス、セキュリティ、実際の処理時間などは十分に検証できません。逆に、動くコードがあっても、ユーザーが目的を理解できるかは別問題です。
一つのプロトタイプで全部を証明しようとせず、「今回分かること／分からないこと」を書いておくと、結果を過大評価しません。
フィードバックは感想より行動を見る
「使いやすかったです」という感想だけでは、どこが本当に使いやすかったか分かりません。利用者がどのボタンで止まったか、どこで戻ったか、何を読み飛ばしたかを観察すると、修正箇所が具体的になります。
だからテストでは、操作中にすぐ答えを教えすぎないことも重要です。制作者が横から説明し続ければ、完成品だけで使えるかを検証できません。
次は『仮説→試作品→観察→修正』を1周する
次に何かを作る課題が出たら、最初に「利用者は○○できるはず」という仮説を一文で書いてください。その仮説だけを試せる最小の試作品を作り、実際に誰かに使ってもらい、予想と違った点を一つ直します。
プロトタイプの価値は、完成品に近づいた量ではなく、分からなかったことが減った量で考えると判断しやすくなります。
テスト後は「直す量」を一つに絞る
試作品を使って問題が10個見つかっても、一度に全部直すと、どの変更が効果を生んだか分からなくなることがあります。まず利用を妨げている大きな問題を一つ選び、修正してもう一度試します。
たとえば「ボタンの色」「文章の長さ」「画面遷移」を同時に変えるより、「次へ進む場所が分からない」という問題に対してボタン位置だけ変え、迷いが減ったかを見る方が原因と結果を追いやすくなります。改善の速さは、変更数の多さではなく、学べる試行回数で考えます。
試作品の記録を残すと、改善理由が追える
プロトタイプを直すたびに、日付・確かめたいこと・変更した点・観察結果を四行だけ残しておくと、なぜ今の形になったかを後から説明できます。変更履歴がないと、「最初からこの形が正しかった」と思い込みやすく、失敗から得た情報が消えます。
学校の制作課題でも、完成品だけでなく、どの仮説が外れ、何を変えたかを説明できると、問題解決の過程そのものを評価できます。失敗を隠すのではなく、設計判断の証拠へ変えることができます。
「作った量」ではなく「潰せた不確実さ」で評価する
プロトタイプを作ると、画面数や機能数が多いほど進んだ気になりがちです。しかし目的は完成品を早く作ることではなく、まだ分かっていないことを早く確かめることです。
たとえば図書館アプリなら、「検索結果の並び順が理解できるか」を試したいのに、ログイン画面や色選びまで作り込む必要はありません。逆に、紙一枚の試作品でも、利用者が本を見つけられず迷うなら大きな学びがあります。
作る前に「この試作品で何が分かれば次へ進めるか」を一文で書き、テスト後には「分かったこと／まだ分からないこと」を分けると、見た目の完成度に引っ張られにくくなります。
参考にした範囲
文部科学省の高等学校「情報」関係資料で扱われる問題発見・解決の流れを踏まえ、試作と評価を学習者が実行できる形に整理しています。
