プロトタイプとは？意味と開発での役割・MVP/PoCとの違い

プロトタイプは、完成前のサービスや製品について「この画面で利用者は迷わないか」「この業務手順で処理を完了できるか」といった仮説を確かめるための試作品です。Webサービスやスマホアプリでは、見た目だけの画面案から、クリックして操作できる画面、限定的に動く試作まで、目的に応じて形が変わります。

重要なのは、動くものを早く作ることではありません。何が不確実なのかを整理し、モックアップ、プロトタイプ、PoC、MVPのどれを使うか決めることです。この記事を読むと、検証したい不確実性に応じて手法と再現範囲を選び、次の開発判断へ進めるようになります。

試作品の名称ではなく、最初に解消したい不確実性と確認したい問いから検証手段を選びます。

01Sectionプロトタイプとは？完成品との違い

プロトタイプ（prototype）は一般に、量産や本格的な開発へ進む前に作られる試作品・原型を指す言葉です。自動車や家電などの工業製品では、量産に入る前に設計や使い勝手を検証するための試作機をプロトタイプと呼びます。ソフトウェアの分野では、完成前に画面や機能の一部を再現し、仮説を確かめるための試作を指します。この記事では、Webサービス・スマホアプリ開発における活用を中心に説明します。

英国政府のプロトタイプ作成ガイドでも、紙のスケッチからコードで動く試作品まで、目的に応じた複数の形式が示されています。したがって、プロトタイプを「動くアプリ」と限定して捉える必要はありません。

開発で再現する対象は、主質問に合わせて決める

再現対象は、検証したい問いによって変わります。たとえば、画面の意味や用語を理解できるかを確かめるなら、主要画面と文言だけでも足りる場合があります。一方で、利用者が申請から承認までの業務を完了できるかを確かめるなら、役割ごとの操作や代表的な分岐を再現する必要があります。

主な再現対象には、次のようなものがあります。

• 画面構成、情報の優先順位、入力項目、用語
• 主要タスクの操作、画面遷移、エラー時の案内
• 申請・承認などの役割別業務フロー
• 端末機能、API呼び出しなど、限定的な機能・技術要素

完成品との違いは、本番と同じ品質を備えることではなく、仮説の判断に必要な範囲へ意図的に絞る点にあります。利用者視点をライフサイクル全体で扱う人間中心設計の考え方は、ISO 9241-210でも示されています。

プロトタイプが有効な場面と、簡略化できる場面

要件、用語、操作導線、役割分担、業務フローに関係者間の認識差があるときは、試作品を介して確認する価値があります。文章の仕様書だけでは見つけにくい誤解や、実際に操作したときの迷いを早い段階で把握しやすくなるためです。

反対に、仕様が十分に固まり、既存の仕組みをほぼ同条件で再現するだけの場合は、大がかりな試作が常に必要とは限りません。画面レビューや要件確認で足りるかを、まず主質問から見極めます。

02Sectionプロトタイプを作る目的と、単体では判断できないこと

プロトタイプは、利用者の課題そのものを探す手段というより、想定した解決策が機能するかを評価する手段です。この二つを分けると、作る範囲と評価方法を決めやすくなります。

課題発見・優先度確認と、解決策評価を分ける

課題発見の段階では、「誰が、どの場面で、何に困っているのか」「その困りごとは優先して解く価値があるのか」を確かめます。現状業務の観察、利用者ヒアリング、問い合わせ記録や利用データの確認が中心になります。GOV.UKの利用者ニーズ調査ガイドも、まず利用者と現行の行動、ニーズを理解することを重視しています。

その後、解くべき課題と優先度が見えてきたら、プロトタイプで想定解決策を評価します。たとえば、利用者が画面上の用語を理解できるか、主要タスクを完了できるか、現場の手順や責任分担に合うかを確認します。

この順序により、「画面への感想は集まったが、そもそも解くべき課題だったのか分からない」という状態を避けやすくなります。レビューで得た意見も、好みの一覧ではなく、仮説を支持する観察結果かどうかで整理できます。

プロトタイプで確認しやすいこと、別途検証すべきこと

プロトタイプは、主に操作性と業務適合性の検証に向きます。代表的な利用者が、想定した条件で主要タスクを理解し、進められるかを観察します。

一方で、プロトタイプの結果だけで、本番サービスとしての可否まで決めることはできません。

03Section不確実性からプロトタイプの形式・忠実度を選ぶ

最初に確認すべきことを一つに絞ると、試作の形式と再現範囲を過不足なく決めやすくなります。

再現度は高いほどよいわけではありません。画面理解を確かめたいだけなのに本番連携まで実装すれば、検証前の負担が増えます。逆に、認証や外部連携の成立性を静的画面だけで判断することもできません。まず、今回もっとも解消したい不確実性を一つ定めます。

まず、利用者の困りごとと優先度が分かっているか確認する

利用者の困りごとや優先度が不明な段階では、プロトタイプを先に作るよりも、現状業務の観察、ヒアリング、既存データの確認を行います。解決策を試す前に、対象とする課題を絞るためです。

課題が定まっているなら、次の順で検証手段を選びます。

1. 1画面・用語・操作導線が不明なら、ペーパー、ワイヤーフレーム、静的画面、またはクリック可能な画面を使います。画面構成、情報の優先順位、用語の理解、主要な導線を確認します。
2. 2業務フローへの適合が不明なら、役割別の代表シナリオを含むクリック可能な画面プロトタイプを使います。担当者、承認者などが、業務の流れに沿って処理を完了できるかを見ます。
3. 3技術連携・認証・データ処理の成立性が不明なら、PoCまたは限定実装を使います。接続先、データ形式、必須処理、失敗時の扱いを対象にします。
4. 4顧客価値・継続利用・提供運用が不明なら、MVPまたは限定パイロットを検討します。実際の利用状況や運用上の課題を通じて、価値提供を学びます。

GOV.UKのガイドが示すように、スケッチはアイデアの探索や共有に、より現実的なコードプロトタイプは利用者調査に使えます。形式名ではなく、問いに対して必要な再現度を選ぶことが重要です。

複数の不確実性がある場合は、最大リスクを先に検証する

画面、業務、技術の不確実性が同時にある案件では、すべてを一つの試作品で解こうとしないほうが進めやすくなります。特に、外部システム連携が成立しなければサービスの前提が崩れる場合は、PoCで技術条件を先に確認します。

その後、連携結果を利用者が理解して業務を終えられるかは、プロトタイプで別途確かめます。各検証で「再現すること」と同時に、「性能、実データ、認証、全例外処理など今回は再現しないこと」を決めておくと、結果の解釈を誤りにくくなります。

04Sectionモックアップ・プロトタイプ・PoC・MVPの違い

4つの用語は呼び方に幅があります。依頼や会議では、名称に加えて主質問、再現範囲、評価者、終了判断をそろえます。

これらの用語には組織や開発手法による呼び方の違いがあります。以下は唯一の定義ではなく、検証を設計するための一般的な整理です。

会議や依頼時には、名称だけで合意しないことが大切です。「何を確かめるか」「どこまで再現するか」「誰が評価するか」「実利用するか」「何が分かれば終えるか」を明文化してください。PoCとMVPで検証・提供環境を分ける実務例として、California Department of General Servicesの方針も参照できます。ただし、これは同州のGenAIに関する方針であり、すべての案件に共通する定義ではありません。

既存システムと連携する申請・承認サービスで考える

顧客価値や実利用を確かめるMVPとの違いは、MVPの解説も参照してください。

プロトタイプでは、利用者が連携結果を見て申請・承認を完了できるかを確かめます。申請・承認画面、連携結果の表示、代表的なエラー表示を再現し、現場担当者や承認者に操作してもらいます。重大な迷い、業務上の欠落、用語の誤解を確認します。

PoCでは、所定の認証、API、データ形式、応答条件で処理が成立するかを確かめます。認証、API呼び出し、データ変換、エラー・再試行、ログを対象にし、開発担当、連携先、セキュリティ担当が確認します。必須条件で接続・処理できるか、残る制約への対応方針を立てられるかが判断材料です。

連携の技術成立性が最大リスクなら、PoCを先に進めます。 技術的に成立しても利用者が業務を完了できるとは限らないため、利用体験と業務適合性はプロトタイプで確認します。

05Sectionプロトタイプ検証を次の意思決定につなげる進め方

検証開始前に、仮説、再現・非再現範囲、観察方法、終了後の判断を決めておくと、結果を次の行動へ結び付けやすくなります。

試作品を作ること自体を目的にすると、レビュー後に「意見は集まったが、何を決めるのか分からない」状態になりがちです。開始前に仮説と終了判断を置き、観察結果を次の行動へ結び付けます。GOV.UKのユーザー調査計画ガイドも、目的、重要な質問、参加者、記録方法を事前に計画することを勧めています。

仮説から評価までを設計する6つのステップ

観察結果を採用・修正・追加検証・縮小／見送りへつなげる

参加者数や合格率に一律の正解はありません。対象タスクの重要度、参加者の代表性、失敗した場合の業務リスクに応じて設計します。次の表は、案件ごとに具体化する意思決定ゲートの例です。

評価後は、フィードバックを「要望」「感想」だけで分類せず、仮説、観察結果、未検証リスク、次の行動としてまとめます。これにより、画面修正で解決すべき問題と、技術検証や業務設計を追加すべき問題を分けられます。

期間・費用の比較条件と相談前の確認

プロトタイプの期間や費用は、形式名だけでは比較できません。対象業務、再現度、認証・連携の有無、テスト支援、修正条件、成果物の扱いが異なるためです。公開情報だけでは、これらの条件をそろえた一般的な数値比較は難しいため、同じ前提をそろえて確認します。

英国NIHR Maudsley Biomedical Research Centreの開発見積もりガイドはデジタルヘルスアプリを対象に、複雑性、対象プラットフォーム、第三者連携、テスト、要件変更などを見積もり条件として挙げています。一般的な相場を示す資料ではありませんが、比較時に確認すべき条件の整理には役立ちます。

プロトタイプ・PoC・MVP開発の進め方を相談する

検証したい仮説、再現範囲、連携条件、評価方法を整理したうえで、プロトタイプ・PoC・MVPのどこから進めるかを比較できます。

MVP・PoC開発785社掲載

MVP・PoC開発の相談先を探す