プロトタイプとは?本格的に作る前にアイデアを確かめる
目次
「画面の案はできたけれど、このまま作ってよいのだろうか」。そんなときに使えるのがプロトタイプです。プロトタイプは、アイデアや使い方を確かめるための試作品。完成品を先に作るのではなく、知りたいことに合わせて、紙に描いた画面や操作できる画面を用意します。
大事なのは、完成品にどれだけ似せたかよりも、何を確かめられるかです。この記事では、ソフトウェアの画面や操作の試作を中心に、一つの問いから試作品の範囲を決める方法を紹介します。
- 試作する前に、誰のどの作業を確かめたいかを書く
- 問いに合わせて、紙の画面か操作できる画面かを選ぶ
- 試作品で確認できたことと、本番でまだ確かめていないことを分ける
試作品で何を確かめる?
「使いやすい画面にしたい」だけでは、作る人によって試作品の範囲が変わります。「初めて申請する人が、必要な添付資料の場所を見つけられるか」のように、利用者と作業を一つ選んでみましょう。
まだ困りごと自体がはっきりしていないなら、試作を急ぐより、要望と課題の違いに沿って背景を整理します。ボタンを増やす案があっても、本当の困りごとは資料の名前が分かりにくいことかもしれません。
画面の意味・作業の流れ・操作を分ける
確かめたいことを分けると、必要な試作品も選びやすくなります。
| 確かめたいこと | 問いの例 | 用意するものの例 |
|---|---|---|
| 言葉や配置の意味 | この見出しから、何がある場所だと理解するか | 見出しと内容を置いた画面案 |
| 作業の流れ | 資料を確認したあと、申請に戻れるか | 前後の画面をつないだ案 |
| 操作の反応 | 添付の選択後、追加されたことに気づけるか | 操作に応じて表示が変わる案 |
これは試作を考えるための整理例です。一枚の画面を見てもらうだけで、操作後の反応まで確認できたことにはしません。
確かめたいことに合わせて形を選ぶ
プロトタイプの形は一つではありません。英国政府の試作ガイドも、紙のスケッチからコードで動く試作品までを挙げ、目的に合う形式を選ぶ考え方を説明しています。
紙の案と、操作できる案
紙や静止画なら、案を並べて、どこに何を置くかを話し合えます。描き直しもしやすいため、内容や配置がまだ大きく変わりそうな段階で使えます。
一方、画面の行き来や操作後の変化を確かめたいなら、クリックや入力に反応する試作品を考えます。すべての機能を動かす必要はありません。今回の作業に関係する部分を動かし、それ以外は試せないことを明示します。
細かく作り込めばよい、というわけではありません。配色の検討が目的でないのに色の調整を続けたり、資料の見つけやすさを調べたいのに管理者設定まで作ったりすると、確かめる問いから離れてしまいます。
一つの場面だけ試作してみる
ここからは、架空の申請管理サービスを例にします。実在する顧客やアーコレ!の開発事例ではありません。

確かめたいのは「初めて申請する担当者が、見積書を確認する場所を見つけられるか」です。画面案Aでは資料へのリンクを説明文の中に置き、画面案Bでは「申請に必要な資料」という欄にまとめます。どちらがよいかを先に決めず、探す様子や言葉の受け取り方を確かめる準備をします。
二つの案を見せる場合、先に見た案で操作を覚える影響も考えます。比較の条件をそろえられないときは、厳密な優劣の判定ではなく、それぞれで起きた迷いや気づきを残す使い方にします。
作らない部分も決める
この例なら、申請のトップ画面、資料の確認画面、元に戻る動線が試作の候補です。請求処理や管理者設定は、今回の問いには含めません。本番への送信や実在する資料の取得も行わない形にします。
次のシートは、編集部が用意した試作範囲の整理例です。
| 記入欄 | 架空例 | 自分の案 |
|---|---|---|
| 誰の作業か | 初めて申請する担当者 | [記入] |
| 確かめたい問い | 見積書の確認場所を見つけられるか | [記入] |
| 必要な画面 | 申請トップ、資料の確認画面 | [記入] |
| 今回は動かない部分 | 申請送信、実データの取得 | [記入] |
| 観察したい行動 | 最初に探す場所、迷う表示、戻り方 | [記入] |
「使いやすいか」のように広い問いになった場合は、「資料の場所を見つけられるか」「資料から元の申請へ戻れるか」に分け、今回はどちらを見るか選びます。
書いたあと、問いと関係のない画面が入っていないか見直します。逆に、必要な画面が足りず途中で止まるなら、そのつながりを補います。当日の進め方や記録の取り方は、ユーザーテストの進め方で詳しく扱っています。
試作品で分かること、まだ分からないこと
試作品で操作ができたとしても、それだけで「多くの人が買う」「使い続ける」「本番で問題なく動く」とまではいえません。どの相手が、どの条件で試した結果なのかも合わせて残します。
紙の画面では実際の読み込み時間を確かめられません。操作できる試作品でも、権限、データ量、通信環境などを再現していなければ、その条件での使い勝手は未確認です。確認できた範囲を書いておくと、次に何を調べるかが明確になります。
試作品を共有するときは、試作だと分かる表示を付け、必要な相手にアクセスを限定します。共有先が転送してもよいものかも、あらかじめ確認します。テスト用の架空データを使い、本番への送信や変更につながらないことも確認してください。試作向けに簡略化したコードは、そのまま本番品質だと扱わず、公開前に別途確認します。
プロトタイプは新サービスの最初だけでなく、公開済みの機能を見直す際にも使えます。一度試して終わりにせず、分かったことから案を直し、必要なら別の問いを確かめます。
最初の一歩:画面を作る前に、問いを一つ書く
まずは「誰が、何をできるか確かめたい」の一文を書いてみましょう。その問いに必要な画面だけを並べ、動かす部分と動かさない部分を分けます。
試したあとには、確認したこと、まだ分からないこと、次に直す案を残します。複数の改善候補の中で次の取り組みを決めるときは、プロダクトロードマップの作り方につなげて考えてみてください。
参考資料
- GOV.UK:Making prototypes — 試作品の形式と選択、本番コードとの区別を参照。本文の申請例・整理シートは編集部による架空例です。