プロトタイプとは、本番開発に入る前に画面、操作感、業務フロー、必要な機能の過不足を確認するための試作品です。完成品を先に作るのではなく、文章だけでは判断しにくい部分を小さく形にして、関係者の認識ズレを早い段階で見つけるために使います。
特にWebサービス、業務システム、アプリ開発では、MVP、PoC、モックアップとの違いが曖昧なまま外注相談に進むと、見積もりの範囲や成果物の期待値がずれやすくなります。この記事では、プロトタイプの意味、使うべき場面、作り方、費用と期間の目安、外注前に決めるべき条件を、発注者目線で整理します。
この記事のポイント
- プロトタイプは完成品ではなく本番開発前の判断材料
- MVPは市場反応、PoCは実現性、モックアップは見た目を確認する
- 費用は画面数、忠実度、修正回数、実装有無で大きく変わる
- 外注前は検証仮説、主要画面、成果物、次フェーズの条件を決める
プロトタイプを作るかどうかは、流行やツールで決めるものではありません。自社が本番開発へ進む前に、何を見れば判断できるのかを決め、その判断に必要な粒度だけ作ることが重要です。
目次
プロトタイプとは何を確認する試作品か
プロトタイプは判断材料
プロトタイプは、完成品の縮小版ではありません。目的は、作りたいシステムを本番品質で実装することではなく、関係者が画面を見たり、クリックしたり、簡単な入力の流れを試したりしながら、開発前に判断すべきことを明らかにすることです。
たとえば、予約サービスなら検索、一覧、詳細、日時選択、確認、完了までの流れをつなぐだけでも、ユーザーがどこで迷うかを確認できます。社内申請システムなら、申請者、承認者、管理者の画面を簡単に並べることで、業務フローと画面設計のズレを見つけやすくなります。
発注者側にとっての価値は、開発会社に丸投げする前に、何を作るべきかを自分たちの言葉で説明できるようになることです。プロトタイプを通じて、画面、利用者、入力項目、承認の流れ、後回しにする機能を整理しておくと、要件定義や見積もりの前提も合わせやすくなります。
MVP・PoCとの違い
MVP、PoC、プロトタイプは混同されやすい言葉ですが、違いは「何を検証するか」で整理できます。プロトタイプは操作感や仕様の認識合わせ、PoCは技術的に実現できるか、MVPは実際のユーザーや市場で価値があるかを確認するものです。
| 種類 | 主な目的 | 確認すること | 見せる相手 |
|---|---|---|---|
| プロトタイプ | 認識合わせ | 画面遷移、操作感、仕様の過不足 | 発注者、利用部門、開発会社 |
| PoC | 実現性の確認 | 技術、外部連携、処理速度、精度 | 技術者、意思決定者 |
| MVP | 価値の検証 | 利用、継続、問い合わせ、課金意向 | 実際のユーザー、市場 |
新規事業では、プロトタイプで画面や導線を確認し、必要に応じてPoCで技術リスクを見て、その後にMVPで市場反応を確かめる流れが自然です。ただし、必ずこの順番で全部実施する必要はありません。画面の不確実性が大きいならプロトタイプ、技術リスクが大きいならPoC、顧客価値の検証が主目的ならMVP開発の進め方を優先します。
モックアップとの違い
モックアップは、主に見た目やレイアウトを確認するための静的な画面です。プロトタイプは、そこに画面遷移や操作の流れを加え、利用者が目的を達成できるかを確認します。つまり、モックアップは「どう見えるか」、プロトタイプは「どう使えるか」を見るものです。
最初からクリック可能なプロトタイプを作る必要がない場合もあります。社内で画面イメージを合わせたいだけなら、紙ラフやワイヤーフレーム、簡単なモックアップで十分なことがあります。画面の骨組みから整理したい場合は、モックアップの作成方法を先に確認すると、作り込みすぎを防ぎやすくなります。
一方で、入力、検索、承認、予約、決済前後の確認など、操作の順番が成果に直結する場合は、静止画だけでは足りません。利用者がどの画面からどの画面へ移り、どこで判断し、どこで迷うのかを見るために、プロトタイプが役立ちます。
プロトタイプが有効な場面
プロトタイプが有効なのは、文章だけでは完成イメージを共有しにくいプロジェクトです。特に、関係者が多い、業務フローが複雑、利用者の行動を見ないと判断できない、新規サービスで前例が少ないといった状況では、本番開発前に小さく試す価値があります。
プロトタイプが向くケース
- 画面遷移や入力フローが成果に影響する
- 利用部門と決裁者で完成イメージがずれている
- 新規事業や初めてのシステム化で要件が固まり切っていない
- 本番開発の費用が大きく、先に手戻りリスクを減らしたい
現場でよく見るのは、発注者が「一覧と詳細があればよい」と考えていても、実際に画面へ落とすと検索条件、並び順、権限、エラー表示、承認者への通知などが次々に出てくるケースです。プロトタイプは、こうした曖昧さを開発前に表へ出すための道具です。
省いてよいケース
一方で、プロトタイプを作らなくてもよいケースもあります。既存システムの小さな改修、同じパターンの画面追加、法律や社内ルールで要件がほぼ固定されている機能などは、文章と簡単な画面ラフだけで十分な場合があります。
判断の目安は、関係者全員が同じ完成イメージを持てるかどうかです。「見てみないと分からない」「使ってみないと決められない」部分が多いなら、プロトタイプを挟む価値があります。逆に、仕様が明確で、利用者の操作も既存画面とほとんど同じなら、設計や要件定義へ進んだ方が早いこともあります。
ただし、省く場合でも画面一覧、主要な操作フロー、完了条件は残しておきましょう。開発会社へ「既存と同じ」と伝えたつもりでも、実際には権限、データ更新、例外処理、検収条件が違うことがあります。
プロトタイプとはどう作るか・費用と外注準備
検証仮説を一文にする
プロトタイプの作り方で最初に決めるべきことは、ツールやデザインではなく検証仮説です。「誰が、どの場面で、何を判断できればよいのか」を一文にします。たとえば「初回利用者が会員登録から予約完了まで迷わず進めるか」「承認者が差し戻し理由を迷わず入力できるか」のように、確認後の判断につながる形にします。
仮説が曖昧なまま進めると、画面を増やしすぎたり、見た目の作り込みに時間を使いすぎたりします。プロトタイプは「便利そうなものを全部試す」工程ではありません。最も不確実な部分に絞って、短い時間で判断材料を得る工程です。
最初に決めること
- 誰のどの行動を確認するか
- どの画面や操作で迷いが起きそうか
- 検証後に何を決めるか
- 本番開発へ進む条件をどう置くか
主要画面と成果物を絞る
検証仮説が決まったら、主要画面と成果物を絞ります。全画面を作るのではなく、利用者が目的を達成するために必ず通る流れを選びます。予約サービスなら検索、一覧、詳細、日時選択、確認、完了。社内申請なら申請、確認、承認、差し戻し、完了通知のように、1本の流れに絞ると判断しやすくなります。
成果物も、クリック可能なURLだけでは足りません。画面一覧、画面遷移、レビュー結果、採用する仕様、捨てる仕様、次フェーズへ申し送る論点まで残すと、要件定義や見積もりへ接続できます。発注前の資料化まで進めるなら、要件定義書の作り方もあわせて確認すると、プロトタイプで得た判断を次の開発範囲へ落とし込みやすくなります。
Figmaのようなプロトタイピングツールでは、画面同士をつないでユーザーの流れを確認できます。ツールの仕様自体を確認したい場合は、Figma公式のプロトタイピングガイドが参考になります。ただし、ツール選びよりも検証する範囲の整理が先です。
粒度ごとの費用目安
プロトタイプの費用と期間は、作り込みの粒度で変わります。紙ラフやワイヤーフレームなら短期間で作れますが、実際のデータ入力や権限、外部連携まで含めると、本番開発に近い費用が必要になります。外注時は、金額だけではなく、どの粒度の成果物なのかを必ず確認しましょう。
| 粒度 | 確認できること | 期間の目安 | 費用の目安 |
|---|---|---|---|
| 紙ラフ・画面ラフ | 画面構成、主要導線 | 0.5〜2営業日 | 内製ならほぼ0円〜数万円 |
| ワイヤーフレーム | 情報設計、画面の優先順位 | 2〜5営業日 | 5〜20万円程度 |
| クリック可能なプロトタイプ | 画面遷移、操作感、離脱しそうな箇所 | 1〜3週間 | 20〜100万円程度 |
| 高忠実度プロトタイプ | 見た目、レビュー、社内合意 | 2〜6週間 | 50〜200万円程度 |
| 一部機能を含む実装型 | データ入力、処理、業務フロー | 1〜3か月 | 100万円〜 |
これらは一般的な目安です。実際の費用は、画面数、ユーザー種別、修正回数、デザインの忠実度、データ処理の有無、外部システム連携の有無で変わります。安く見えても修正回数が含まれていない、成果物が画面画像だけ、レビュー結果が残らないといった見積もりでは、次工程で手戻りが起きる可能性があります。
レビュー結果を次へ渡す
プロトタイプの価値は、作った画面そのものよりも、レビューで得た判断を次工程へ渡せる状態にすることにあります。打ち合わせで出た意見を議事録に残すだけでは、採用する仕様、保留する仕様、検証し直す仕様が混ざりやすくなります。
レビュー後は、画面ごとに「本番開発へ残す」「MVPで検証する」「PoCで実現性を見る」「今回は捨てる」を分けます。あわせて、なぜその判断にしたのか、誰が確認したのか、次の見積もりに含めるのかを残しておくと、ベンダーとの会話が具体的になります。
この整理をしないまま本番開発へ進むと、プロトタイプで見つけた課題が口頭のまま流れ、設計段階で同じ議論を繰り返すことになります。試作品を作るだけで終わらせず、判断メモまで成果物に含めるのが実務上は重要です。
外注前に確認する条件
プロトタイプを外注する場合は、ベンダーに「いい感じに試作品を作ってください」と依頼しないことが重要です。発注者側で、検証目的、対象ユーザー、主要画面、成果物、レビュー参加者、修正回数、次フェーズへ進む条件を整理しておくと、見積もりの前提がそろいやすくなります。
この段階で必要なのは、細かな仕様書を完成させることではありません。未確定の論点を見える化し、ベンダーと同じ前提で会話できる状態を作ることです。ここはベンダーコントロールにもつながりますが、この記事の主目的はベンダー管理そのものではなく、外注前に渡せる判断材料を作ることです。
見積もりを依頼するときは、プロトタイプで確認したい範囲と、本番開発に含めたい範囲を分けて伝えます。ここを混ぜると、ベンダー側は安全を見て大きめの見積もりを出すか、逆に画面だけの軽い見積もりを出すしかなくなります。発注者側が「今回は判断材料を作る範囲」「次に実装する範囲」を分けておくほど、提案の比較もしやすくなります。
| 確認項目 | 決める内容 | 曖昧なまま進めた場合 |
|---|---|---|
| 検証目的 | 何を判断する試作品か | 画面追加が止まらない |
| 対象ユーザー | 誰の操作を確認するか | レビュー意見が散らばる |
| 成果物 | URL、画面一覧、レビュー結果、判断メモ | 次工程へ引き継げない |
| 修正範囲 | 何回まで含むか、追加費用の条件 | 後から費用が増える |
| 完了条件 | 本番開発へ進む判断基準 | 作っただけで終わる |
プロトタイプのレビューでは、好みのデザインを議論するよりも、「この画面で利用者は判断できるか」「この機能は本番開発に残すか」「この処理はPoCが必要か」「この範囲でMVPに進めるか」を確認します。レビュー後に残った論点を、要件定義やMVPキャンバスへ落とし込むと、次の発注相談が具体的になります。
