プロトタイプ開発とは？種類・進め方から本開発前の検証ポイントまで解説

プロトタイプ開発とは、本開発の前に試作品を作り、利用者や関係者に試してもらいながら、作るものを固めていく進め方です。

試作品はきれいに作るほど良いと思われがちですが、重要なのは何を確かめたいかを先に決め、それに必要な分だけ作ることです。この記事では、プロトタイプの種類と完成度の選び方、ほかの開発手法との違い、進め方、外部に頼むときに決めておくことを解説します。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る

プロトタイプ開発とは？

プロトタイプ開発とは、完成品を作る前に試作品（プロトタイプ）を作って見せ、意見をもとに直しながら仕様を固めていく開発の進め方です。文章の要件や会議での説明だけでは伝わりにくい「画面の見え方」や「操作の流れ」を、早い段階で目に見える形にする点に特徴があります。

プロトタイプとは｜試作品・モックアップとの関係

プロトタイプとは、完成品を作る前に作る試作品のことです。英語の「prototype」は原型を意味し、日本語では「試作品」「試作機」と訳されます。

なお、画面の見た目だけを再現したものは「モックアップ（モック）」と呼ばれ、プロトタイプの一種として扱われます。違いは次の「種類」の章で説明します。

プロトタイプ開発で確かめられること

プロトタイプで確かめられるのは、主に「外から見てわかること」です。たとえば、画面の情報がわかりやすいか、目的の操作まで迷わずたどり着けるか、業務の流れに沿って使えるか、といった点です。

もう1つの役割は、関係者の認識をそろえることです。発注する側と開発する側、事業部門と情報システム部門のあいだで「作りたいもの」のイメージがずれたまま本開発に入ると、完成してから「思っていたものと違う」となりかねません。試作品を一緒に見ながら話すことで、言葉だけでは気づけないずれを本開発の前に見つけられます。

MVP・PoCとの違い

プロトタイプと混同されやすい言葉に、MVPとPoCがあります。PoCは「技術的に作れるか・効果が出るか」という中身を確かめるもの、MVPは必要最小限の製品を実際の顧客に使ってもらい「本当に使われるか」を確かめるものです。

これに対してプロトタイプは、画面や操作の流れといった外側を見せて意見を集めるためのものです。3つの詳しい違いと、どれから始めるかの考え方は「MVP開発とは？PoC・プロトタイプとの違いと進め方」で解説しています。

プロトタイプの種類｜どこまで作るかで分ける

プロトタイプには、完成度と、作ったものをその後どう扱うかの2つの分け方があります。どの種類を選ぶかは、何を確かめたいかで決まります。

完成度で分ける｜紙・ワイヤーフレームから動くプロトタイプまで

完成度による分け方は、おおむね次の3段階です。

• 紙・ワイヤーフレーム：画面に何を置くかを線や枠で描いたもの。手書きやスライドでも作れ、数時間で直せる
• モックアップ：完成品の見た目を再現した画面。色や文字の大きさまで確認できるが、ボタンを押しても動かない
• 動くプロトタイプ：画面の切り替わりや入力などの動きを付けたもの。実際の操作に近い形で試せる

東京都デジタルサービス局の手順書では、モックアップを「完成品を模した画像や画面、Webページなど」、画面遷移や動きを実装したものを「デザインプロトタイプ」と区別しています。そのうえで、利用者の目線で評価するには、画面の遷移ができるデザインプロトタイプが望ましいとしています。

作ったものの扱いで分ける：使い捨て型と進化型

もう1つの分け方が、試作品をその後どう扱うかです。確認が終わったら捨てて本開発で作り直すものを「使い捨て型」、試作品に機能を足しながら完成品へ育てていくものを「進化型」と呼びます。

使い捨て型は、早く安く試せる一方で、本開発で同じ画面を作り直すことになります。進化型は作り直しを減らせますが、最初から本番で使える品質と作り方が必要です。どちらを選ぶかは、試作の段階で決めておくと後の判断がぶれません。

確かめたいことから作るものを決める

完成度は高いほど良いわけではありません。確かめたいことが「画面に何を載せるか」なら紙やワイヤーフレームで足り、時間をかけて作り込むと、直しにくくなるうえに見た目の話に議論が流れがちです。

一方で、業務の流れに沿って使えるかを確かめたいなら、画面が切り替わる動くプロトタイプが必要です。なお、裏側の仕組みが技術的に作れるかを確かめたい場合は、プロトタイプではなくPoCの領域になります。

ほかの開発手法との違い

プロトタイプ開発は、ウォーターフォール開発やアジャイル開発と並べて語られることが多い進め方です。違いは、試作品で確かめる工程を本開発の前に置くかどうかにあります。

ウォーターフォール開発との違い

ウォーターフォール開発とは、要件定義・設計・開発・テストを順番に進め、原則として前の工程に戻らない進め方です。計画を立てやすい反面、利用者が完成に近い形のシステムを触るのはテストの段階になり、そこで要望とのずれが見つかると大きな手戻りになります。

プロトタイプ開発では、要件を固める段階で試作品を作り、利用者に見てもらいます。ずれを早く見つけて仕様に反映し、その後の開発はウォーターフォールで進める、という組み合わせも一般的です。

アジャイル開発・スパイラル開発との違い

アジャイル開発は、機能を小さな単位に分け、短い期間で「作る・試す・直す」を繰り返しながら完成品そのものを育てていく進め方です。スパイラル開発も、設計・試作・評価を繰り返して完成度を高めていきます。

これらとプロトタイプ開発の違いは、繰り返しの対象です。アジャイル開発やスパイラル開発は本番のシステムを少しずつ作り上げますが、プロトタイプ開発は本開発の前に「何を作るか」を固めることに重きを置きます。アジャイル開発の進め方は「アジャイル開発とウォーターフォールの違いから失敗しない進め方まで解説」をご覧ください。

プロトタイプ開発のメリットとデメリット

プロトタイプ開発の最大の利点は、本開発の手戻りを減らせることです。ただし、試作にも費用と時間がかかるため、効果が出る場面を見極める必要があります。

メリット：認識のずれと本開発の手戻りを減らせる

試作品を見ながら話すことで、発注側と開発側、事業部門と情報システム部門のあいだの認識のずれが、本開発の前にわかります。システムは作り進めるほど変更の影響が大きくなるため、ずれを早く見つけるほど直す費用は小さくて済みます。

また、利用者が画面を触って迷った箇所や、不要だとわかった機能を仕様から外せる点も利点です。「作ってから気づく」を「作る前に気づく」に変えることが、プロトタイプ開発の価値といえます。

デメリット：試作の費用と「このまま使える」という誤解

デメリットは、試作そのものに費用と時間がかかることです。意見を受けて直す回数が増えるほど、作業量も増えます。直す回数と期限を決めずに始めると、試作が終わらなくなるおそれがあります。

もう1つ注意したいのが、見た目が完成品に近いほど「このまま本番で使えるのでは」と受け止められやすい点です。使い捨て型の試作品は、本番に必要な安全性や処理の速さを考えずに作っていることが多く、そのまま使うと後で問題になります。試作品を作り込みすぎる失敗については「デザイン思考で新規事業を成功に導く方法とは？」でも取り上げています。

プロトタイプ開発の進め方5ステップ

メリットを生かすには、作る前の準備と、試したあとの結果の扱いが鍵になります。ここでは、東京都デジタルサービス局の手順書も参考に、5つのステップで進め方を整理します。

①確かめたいことと確認ポイントを決める

最初に、試作品で何を確かめたいかを決めます。「画面の情報がわかりやすいか」「申し込みまで迷わず進めるか」のように、利用者の行動で答えが出る形にしておくと、試したあとの評価がしやすくなります。

確認ポイントは、利用者から見た使いやすさだけでなく、運用する側の目線も含めて考えます。東京都の手順書でも、UI（画面のわかりやすさ）、UX（利用者の期待に応えているか）に加えて、提供する側が無理なく運用できるかを観点に挙げています。

②作る範囲と完成度を決める

次に、すべての画面を作るのではなく、確かめたいことに必要な範囲に絞ります。ただし、サービスの中心となる機能は作成の対象に含めることが重要です。

完成度は、前の章で説明したとおり、確かめたいことに合わせて選びます。あわせて、試作品を使い捨てにするか、本開発に生かすかもこの段階で決めておきます。

③プロトタイプを作る

範囲と完成度が決まったら、試作品を作ります。紙やワイヤーフレームなら社内でも作れますが、動くプロトタイプは、デザインツールや開発の知識が必要になるため、外部の開発会社やデザイン会社に頼むことも多い工程です。

作り終えたら、試してもらう前に作った側が一通り操作し、想定どおりに動くかを確かめておきます。

④実際に使う人に試してもらう

試作品は、実際にサービスを使う予定の人に試してもらいます。社内の関係者だけで確認すると、操作に慣れている人の目線になりやすいためです。

試してもらう際は、操作を見守りながら、迷った箇所の理由を聞きます。一方で、手順書は「テスターにサービスの直接的な改善策を聞かない」ことも求めています。改善策を考えるのは作る側の役割です。具体的な質問の仕方は「ユーザー検証とは？目的・手法・成功事例まで徹底解説」をご覧ください。

⑤見つかった課題を本開発に反映する

最後に、試して見つかった課題を一覧にまとめ、本開発で対応するかを決めます。課題・改善案・対応方針・対応状況を1つの表で管理しておくと、本開発の担当者にもそのまま引き継げます。

見落としやすいのが、対応しないと決めた課題の扱いです。東京都の手順書は、対応しない項目についても「対応しない理由と判断者、延期後の対応スケジュールを記録」するよう求めています。記録がないと、本開発の途中で同じ議論を繰り返すことになりかねません。

プロトタイプ開発が向いているケース・省いてよいケース

ここまでの進め方は、どの案件にも同じように必要なわけではありません。利用者の使いやすさが成果を左右するほど、プロトタイプを作る価値は大きくなります。

向いているケース	省いてもよいケース
新規事業や新しいサービスで、利用者の反応がまだわからない	既存の画面に小さな項目を足すなど、変更の範囲が小さい
画面の使いやすさが利用や売上に直結する（申し込み画面、マッチングの検索画面など）	パッケージやSaaSを、画面を変えずにそのまま使う
事業部門・情報システム部門・外部の会社など、関係者が多い	社内の少人数が使うツールで、作ってから直しやすい
発注する側がシステム開発に慣れておらず、完成形を言葉にしにくい	他社サービスで同じ操作に慣れた利用者が使い、画面の形がおおむね決まっている

省いてもよいケースでも、画面の構成を紙に描いて関係者と確認するだけで防げるずれはあります。プロトタイプを作るかどうかは「作る・作らない」の二択ではなく、どこまで作るかで考えると判断しやすくなります。

プロトタイプ開発を外部に頼むときに決めておくこと

試作を外部の会社に頼む場合は、何を作ってもらうかに加えて、作ったものをどう使うかまで先に決めておくことが重要です。ここを決めずに頼むと、試作の後に本開発の見積もりを取り直したり、作り直しが発生したりします。

何を作ってもらい、何を受け取るか

依頼の際は、確かめたいこと、作る画面の範囲、完成度、試してもらう人と回数を伝えます。受け取るものは、試作品そのものに加えて、試した結果と課題の一覧まで含めておくと、本開発に引き継ぎやすくなります。

作ったものを本開発でどう扱うか

試作品を使い捨てにするか、本開発のもとにするかは、依頼の前に決めておきます。進化型にする場合は、本開発を同じ会社に頼むのか、別の会社が引き継げる形で作ってもらうのかによって、試作の作り方や費用が変わります。

費用と期間は何で決まるか

プロトタイプの費用と期間は、主に作る画面の数、完成度、試して直す回数で決まります。紙やワイヤーフレームなら短期間で作れますが、動くプロトタイプは、画面の切り替わりや入力の動きを作る分だけ費用と時間が増えます。見積もりを比べる際は、金額だけでなく、どの完成度で何回の修正を含むかをそろえて確認します。

AIで画面を作る方法も増えている

最近は、文章で指示するだけで画面の案を作れるAIツールも増えています。紙やワイヤーフレームの代わりに、短時間で見た目のある試作品を作れるのが利点です。ただし、作れる範囲や本番に生かせるかはツールによって異なります。

試作と本開発を同じ流れで進める選択肢

使い捨て型の試作は手軽な反面、本開発で同じものを作り直す手間が残ります。カスタメディアプラットフォームのAI駆動セルフ開発ツール「S-MASE」は、インフラ・データベース・画面を自動生成でき、低コストで仮説検証を繰り返せます。900件以上の構築実績をもとにした仕組みで、検証で得た経験をそのまま本開発に持ち込めるのが特徴です。

よくある質問

まとめ｜プロトタイプは「何を確かめるか」を決めてから作る

プロトタイプ開発は、本開発の前に試作品を作って見せ、利用者や関係者の意見をもとに仕様を固めていく進め方です。種類は完成度と作ったものの扱いで分かれ、どれを選ぶかは確かめたいことで決まります。

進め方は、確かめたいことを決め、範囲と完成度を絞って作り、実際に使う人に試してもらい、課題を本開発に反映する流れです。作り込む前に「何を確かめるか」と「作ったものをどう扱うか」を決めておくことで、試作の費用を本開発の手戻りの削減につなげられます。

試作から本開発までを相談したい方へ

カスタメディアでは、新規事業やサービスのアイデアを形にして確かめ、本開発へつなげるまでのご相談を承っています。マッチングやEC、コミュニティなどのプラットフォーム型サービスを、AI駆動セルフ開発ツール「S-MASE」で検証を繰り返しながら開発し、その経験を本開発に生かす方法をご紹介します。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る