プロトタイプとは｜新規事業でのプロトタイピングの進め方

「一度、画面にしてみよう」。企画が会議を通ると、たいていこの一言から試作が始まります。プロトタイプとは、完成品を作る前に、事業仮説の不確かな部分を試せる形へ置き換えた仮の成果物です。ところが数週間後、完成品に近い見た目はできたのに、顧客の反応からは何も判断できません。社内説明用のデモだけが残る現場は少なくありません。

分かれ目は完成度ではなく、検証する問いを1つに絞れているかどうかです。新規事業では、対象者の行動を観察できる最小の形をまず作り、「誰のどの行動が取れたか」を判断の起点にします。Nielsen Norman Groupも、同一シナリオの小規模ユーザーテストで主要な問題の約85%が可視化できたという知見を示しています（2000年、Why You Only Need to Test with 5 Users）。数を集める前に、まず観察できる形を作ります。

試作の目的は、関係者と顧客の認識のずれを表に出し、大きな費用をかける前に仮説を残すか捨てるかを決めることです。

プロトタイプとは｜完成前に仮説を試すための成果物

プロトタイプとは、製品やサービスを完成させる前に、価値・操作・業務・技術に関する仮説を確かめるための仮の成果物です。紙に描いた画面、クリックできる画面遷移、裏側を手作業で代行するサービス、限られた機能だけが動く試作。確かめたい問いに応じて、形はここまで変わります。

「プロトタイプ＝動くアプリ」ではありません。顧客が価値を理解するかを見るなら数枚の画面で足りますし、操作の迷いを見るなら画面遷移が要ります。既存システムとの接続が焦点なら、利用画面よりも接続部分を先に動かすべきです。

プロトタイプが一時点の成果物を指すのに対し、プロトタイピングは作成・テスト・学習・修正の反復を指します。必要な条件は3つです。確かめたい問いがあること、対象者が反応を返せること、観察結果が次の判断につながること。これがそろわなければ、どれだけ完成度が高くても検証用のプロトタイプにはなりません。

モックアップ・MVP・PoCとの違い

プロトタイプは「仮説を試せる形」、モックアップは「見た目や配置を確認する見本」、MVPは「顧客へ価値を届けて学ぶ最小限の製品」、PoCは「成立可能性を確かめる検証活動」です。現場では呼び方が重なりがちなので、名称の統一に時間を使うより、目的と判断できる範囲を関係者間でそろえるほうが混乱を減らせます。

モックアップをプロトタイプの一種と呼ぶ場合もあります。ただ、静的な見本を見せただけで「操作性まで検証した」とは言えません。見た目の見本はモックアップ、対象者の行動を観察できる形はプロトタイプと呼び分けます。

MVPは、顧客へ実際に価値を届け、その反応から学ぶ段階のものです。社内だけで触る画面や技術試作はMVPに当たりません。一方のPoCは検証活動の枠組みであり、その手段としてプロトタイプを使う、という関係にあります。

プロトタイプを作る前に検証する問いを決める

プロトタイプ作成の起点は、画面や機能の一覧ではなく、「次の会議で決めたいこと」を1文にする作業です。「使いやすいか」では広すぎます。「申請担当者が説明を受けずに申請を完了できるか」まで狭めれば、必要な画面と観察項目がおのずと決まります。

プロトタイプで確かめられるのは、顧客が課題を自分ごととして捉えるか、価値を理解するか、迷わず操作できるか、既存業務へ組み込めるか、技術上の制約を越えられるか。問いの種類がこれだけあるからこそ、同じ試作品で全部を調べようとすると結果の解釈がぼやけます。

仮説は「対象者・状況・行動・観察事実」を含む文にします。たとえば「月次申請を担当する営業担当者は、管理部門から説明を受けなくても、案件情報の入力から承認依頼まで進められる」。この形なら、対象者の条件、渡す課題、観察する行動、詰まった箇所まで記録できます。「便利だと思うか」と尋ねるだけでは、実際に進められるかどうかは分かりません。

あわせて、仮説が外れたと判断する条件も書いておきます。説明なしでは進めない、別担当者への確認が要る、必要な情報が手元にない。こうした観察が出たときに、画面・業務フロー・対象顧客のどれを見直すのかを決めておきます。分岐を先に置いておけば、結果の後付け解釈を減らせます。

作る時期は、要求が固まった後ではなく、まだ複数案を捨てられる段階です。確定事項が増えるほど、「ここまで作ったから」という理由で修正の幅が狭くなっていきます。

プロトタイプの種類と忠実度の選び方

プロトタイプの種類は、完成品への近さではなく、確かめたい仮説に必要な反応が取れるかどうかで選びます。顧客が価値を理解するかを見るのに本番同等の処理は要りませんし、技術接続を確かめるのに美しい画面も要りません。

忠実度とは、完成品にどれだけ近く見え、近く動くかの度合いです。低忠実度は紙や簡単な図、高忠実度は画面・挙動・文言が完成品に近い状態を指します。高忠実度ほど良いわけではなく、作り込むほど変更しにくくなるのが実務上の難点です。

新規事業で使いやすい形は、次の5つに分けられます。どれも単独で完結するとは限らず、問いに応じて組み合わせて使います。

• 紙・スライド型：利用場面や操作順を示し、価値の理解と情報の順序を見る
• クリック型：画面をつなぎ、操作の迷い、用語、必要な入力項目を観察する
• 手動代行型：裏側を人が処理し、自動化の前に依頼内容と提供価値の対応を試す
• 場面再現型：店舗や対面接客を簡易に再現し、画面の外の動線と受け渡しを見る
• 技術試作型：接続や処理など、うまくいくか読めない箇所だけを動かし、利用体験とは分けて判定する

始めるのは、仮説が外れたと分かる最も軽い形からです。紙で価値が伝わってから操作へ進み、操作が成立してから技術や運用を深めます。問いが変われば、忠実度も選び直します。

プロトタイピングの進め方｜作る前から学びを残すまで

プロトタイピングは、意思決定を定め、仮説を観察可能な形へ変え、対象者に試してもらい、事実をもとに次の判断を更新する流れで進めます。制作工程だけを切り出さず、テスト後の判断まで一続きに設計することが要点です。

1. 次に決めることを書く：継続、対象変更、機能削減、開発着手など、テスト後に選ぶ行動を先に置きます
2. 仮説と、外れたと分かる条件をそろえる：誰が、どの状況で、何をするか。そして、どの観察が出たら仮説を外すかを決めます
3. 対象者と課題を決める：対象業務の経験と、導入・利用・承認のどこに関わるかで条件を切り、場面を渡して行動してもらいます
4. 問いに必要な部分だけ作る：今回の判断に関わる場面だけを作り、未実装の箇所は未実装だと明示します
5. 説明せずに観察する：最初に何を見たか、どこで止まったかを記録し、理由は終了後に聞きます。行動と本人の説明は分けて残します
6. 事実・解釈・判断を分けて更新する：「入力欄の意味を尋ねた」は事実、「用語が難しい」は解釈、「文言を変える」は判断です。混ぜずに書き分けます

テスト開始時には「評価するのは参加者ではなく試作品です」と必ず伝えます。進行役が途中で助けたら、その内容を記録してください。助けた後に完了できたことは、自力で進めた証拠にはなりません。

1回のテストで結論を固定するのも早計です。同じつまずきが続くのか、対象者の条件で反応が分かれるのかを見ます。数えるべきは反応の数ではなく、次の判断がどう変わったかです。

BtoB新規事業では利用者以外の役割も試す

BtoBのプロトタイプ検証では、利用者の操作だけでなく、購入判断者・承認者・管理者、そして関連部門へ情報が渡る流れまで分けて確かめます。一人の利用者が「使いやすい」と評価しても、契約・導入・運用が進むとは限らないからです。

業務支援サービスを例にすると、利用者は日常操作を、部門責任者は予算と成果を、管理者は権限と例外対応を、情報システム・法務・購買はデータ・接続・契約条件を見ています。同じ画面を全員に見せても、それぞれの判断材料にはなりません。

そのため、役割ごとに渡す材料を変えます。利用者には操作課題を、購入判断者には導入前後の変化を、管理者には登録・権限・例外対応を、関連部門にはデータの種類と受け渡しを示します。なお、本番の機密情報は使いません。

もう1つ、観察の環境にも注意が要ります。営業担当者が横で説明し続けると、試作品だけで理解できたのかが分からなくなるためです。商談と検証を同日に行う場合も、前半は黙って行動を観察し、提案と質疑は後半に分けます。

プロトタイプで確認できるのは「理解できる」「操作できる」まで。「対価を払う」「社内稟議を通す」「継続利用する」は未確認のままです。次の段階では、申込、予約、試験導入、限定販売など、実際の行動を伴う検証へ移ります。

プロトタイプ検証が曖昧になる原因と直し方

プロトタイプ検証が曖昧になる主因は、試作品の粗さではありません。問い・対象者・観察事実・判断基準のどれかが欠けていることです。見た目を磨く前に、「何が分かれば次へ進めるのか」を点検してください。

作り込みが先行して変更できない

要求をすべて盛り込み、完成品に近づけてから見せると、テストで大きな問題が出ても修正をためらうようになります。今回の問いに関係しない画面・例外処理・装飾を外し、捨てられる範囲で作ってください。試作品の目的は保存ではなく学習です。

「どう思いますか」で感想を集める

好意的な感想は、利用できる証拠でも購入する証拠でもありません。特定の場面を渡し、説明なしで行動してもらいます。「最初に何をしますか」「次に何が起きると思いましたか」。このように予想と行動を聞き、質問で正解へ誘導しないことが肝心です。

会いたい相手ではなく、会いやすい相手で試す

社内の同僚や既存顧客は、背景を知っているぶん説明不足を補ってくれます。対象者は「今回の課題を経験した人」「利用判断に関わった人」のように、行動の条件で定義しましょう。対象外の人から得た反応も捨てずに残しますが、想定顧客の反応と同じ箱には入れません。

進行役が試作品を弁護する

対象者が迷うたびに説明を挟むと、終了時には全員が操作できたように見えます。迷った箇所は欠陥ではなく観察材料です。助ける場合は、どの時点で何を伝えたかを書き残し、その前後を分けて判断します。

結果を見てから合格条件を動かす

期待と違う反応が出た後で「今回は参考意見だから」と扱いを変えると、検証ではなく正当化になります。継続・修正・停止へ進む条件は、開始前に置きます。条件を変える必要が出たら、今回の判定には使わず、次の試行の条件として記録します。

最後に、作り直しの判断基準です。プロトタイプを作り直すべきなのは、見た目が古くなったときではありません。問いが変わったとき、対象者が変わったとき、前提が崩れたとき、より軽い方法で確かめられると分かったときです。同じ成果物を修正し続けるより、問いに合わせて別の形へ切り替えるほうが、何を学んだかが明確になります。

まとめ｜プロトタイプは次の判断ができた時点で役目を終える

プロトタイプの完成条件は、完成品に近づくことではなく、対象者の反応から次の事業判断を選べる状態になることです。仮説を残すか、変えるか、捨てるか。その判断ができた試作品は、粗く見えても役目を果たしています。

画面を作る前に問いと、外れたと分かる条件を狭めます。作った後は感想ではなく行動を見ます。BtoBでは利用者・購入判断者・管理者・関連部門の判断を分けて確かめてください。学びが取れたら試作品を守らず、次の形へ変える。これがプロトタイピングです。

プロトタイプ検証の準備項目を一枚にまとめる

仮説、反証条件、対象者、観察項目、テスト後の判断。この5点がそろっていれば、外部の検証支援へ相談する場合も、初回の打ち合わせを試作品の説明だけで終わらせずに済みます。これらを一枚に記入できる「プロトタイプ検証設計シート」を、社内レビューと相談前の整理に使える形で用意しています。

［ 資料DL（検証準備チェック）→検証支援相談 ］