顧客に見せるなら、ログイン画面も管理機能も必要だと思っていないでしょうか。いま知りたいのが「記録を探す流れが伝わるか」なら、画面を紙で並べるだけでも確認できる部分があります。一方、実際の検索結果が正しいかは、紙の画面だけでは分かりません。
プロトタイプは、未確認の仮説に合う形を選び、何を観察すれば判断が変わるかを決めてから作りましょう。完成品へ近づけること自体が目的ではありません。
この記事では、企画を一枚で示す形から、小さく提供して確かめる形まで、四つの選択肢を比べます。作る範囲と、その結果だけでは分からないことを分けられるようになります。
まず行うこと： 企画書の未確認事項を一つ選び、「誰が何をできれば、次の何を決められるか」を書く。
1週間以内の実行案： 必要な相手・作業・利用できる資料を確認し、最小の試作と観察項目を用意する。試せたら結果と未確認事項を残す。相手や許可がそろわなければ、作り込みを増やさず試行の条件を整えるところまで進めます。
プロトタイプの種類は、形の豪華さより答えたい問いで選ぶ
ここでは四つに整理しますが、必ず順番に通る階段ではありません。GOV.UKのプロトタイプ作成ガイドも、スケッチからコードまで目的に合う形を選ぶ考え方を示しています。以下は、その考え方を事業検討の用事へ整理した比較です。
例は「保全担当者が修理記録を探すサービス」です（仮例）。
形態 | この例で確かめること・作るもの | 観察すること／まだ言えないこと |
|---|---|---|
コンセプトシート | 課題と提案が伝わるか。一枚に対象業務・困る場面・提案を書く | 相手が想起する実際の場面や代替手段を聞く。好意的な感想だけでは購入は分からない |
ペーパープロトタイプ・モックアップ | 操作の流れが分かるか。検索から記録表示までの画面を並べる | 「この設備の前回の修理を探す」という作業で、選ぶ場所や迷いを観察。実際の検索精度・速度は分からない |
動くプロトタイプ | 主要な処理が対象条件で動くか。許可されたサンプル記録で検索を動かす | 正しい記録へ到達するか、誤りや確認負担を記録。本番の安全性・性能・すべてのデータへの対応は別に確認する |
MVPなど、提供範囲を絞った試行 | 提供条件の下で使われるか。対象業務と支援範囲を限定して提供する | 申込み、支払い、実利用、継続を別々に記録。初回利用から長期の継続や全社展開までは分からない |
MVPは必ず有料という意味ではありません。支払いを確かめたい試行なら、実際に提供できる範囲と価格を示す必要があります。裏側を人が行う方法も選べますが、必要な手作業と費用を残し、自動で提供できた実績に置き換えないようにします。
作る前に、未確認の仮説を観察できる作業へ変える
「便利だと思うか」から、「何ができるか」へ問いを具体化しましょう。先ほどの例で、検索画面を作る前の設計は次のようになります。
- 未確認の仮説： 保全担当者は、設備名から過去の修理記録を探せる。
- 最小の形： 設備を選び、記録を開くまでのモックアップ。答えの正しさを調べる段階ではなく、操作の理解を先に確かめる。
- 試してもらうこと： 故障対応を想定した設備と必要な記録を伝え、どこから探すかを見せてもらう。先に操作を説明して正解へ誘導しない。
- 残すこと： 相手が選んだ箇所、迷った箇所、必要とした説明。説明した後に完了した場合は、その支援も記録する。
表示された記録が正しいかを知りたいなら、このモックアップでは不足です。情報管理担当へ使えるデータを確認し、現場担当が期待する記録を決めたうえで、主要処理の試作へ進みます。前の形が安いからではなく、その形では答えられない問いがあるから、作る範囲を変えます。
好反応・作業の成功・支払い・継続は、別の結果として読む
「使いたい」と言われたら、その場で購入確認済みにはしません。何に期待したのかを聞き、次に必要な確認へつなぎます。
- 説明には好反応だが操作で止まる： 提案への期待と使いやすさは別。止まった箇所を直して再確認する。
- 支援付きでは完了できる： 支援がない条件でもできるか、または支援込みで提供を続けられるかを確かめる。
- 試用されたが購入判断者は別にいる： 利用者の評価に加え、比較対象・予算・承認条件を判断に関わる人へ確認する。
- 初回の支払いはあった： その価格と支援条件で買われた材料として残す。次の利用機会で続けて使うかは、別に確かめる。
うまくいかない場合も、顧客課題がないと即断しないようにしましょう。操作、データ、提供条件のどこが影響したかを分ける必要があります。逆に、何度直しても重要な条件を満たせないなら、同じ試作を磨くより対象や案の見直しを検討します。
生成AIで試作しても、確認と運用の仕事は残る
生成AIは画面案やコードの作成を補助できますが、開発期間や費用が一定の割合で減るとは限りません。要件の整理、生成物の修正、データの利用確認、試行の準備も含めて、今回の作り方を比べましょう。
GOV.UKのガイドは、コードで作る試作も、そのまま本番の安全性や性能を満たすものではないと注意しています。実顧客への提供へ移るときは、試作で確認した価値と、本番に必要な品質・運用を分けて判断します。
作り込みを増やす前に、今回の問いへ戻る
作り込みが増えたら、「この機能がなくても、今回の問いに答えられるか」を見直しましょう。試行に必要なアクセス制御などは削れません。一方、検証に使わない管理機能まで先に完成させる必要はありません。作る範囲・試す作業・次の判断をそろえることが、最初に行う設計です。