プロトタイプ開発とは、作る前に「形」を確かめること
プロトタイプ開発とは、製品やシステムを本格的に作る前に試作品を作り、関係者や利用者に見せたり触ってもらったりして、考えていた形が正しいかを確かめる進め方です。
言葉で書いた要件は、読む人によって思い浮かべるものが違います。要件の文書に全員が同意していても、できあがった画面を見て初めて「思っていたものと違う」と分かることがあります。プロトタイプは、この食い違いを、費用の小さい段階で表に出すための道具です。
プロトタイプで確かめられることは、主に次の三つです。
- 伝わるか：何ができるサービスなのかが、説明なしで分かるか。
- 使えるか：利用者が迷わずに、目的の操作を最後まで行えるか。
- そろっているか：社内の関係者や開発者のあいだで、作るものの認識が一致しているか。
一方、プロトタイプでは確かめにくいこともあります。実際に使い続けるか、対価を払うか、技術的に求める性能が出るか、です。これらは別の手段で確かめます。
プロトタイプの種類と、必要な精度
プロトタイプには、作り込みの度合いによっていくつかの段階があります。どれを選ぶかは、確かめたいことで決めます。
- 紙や手描きの画面：画面の構成と流れを、短い時間で何通りも試せます。考えを広げる段階や、社内で方向をそろえる段階に向いています。見た目が粗いため、見る人が遠慮なく意見を言いやすい利点があります。
- 画面だけが操作できる試作：画面の設計用の道具で作り、押すと次の画面に進むようにしたものです。裏側の処理やデータは作りません。利用者に操作してもらい、迷う箇所を見つけるのに向いています。
- 一部が実際に動く試作：核となる処理だけを実際に作り、実物に近いデータで動かします。操作した結果の内容によって利用者の反応が変わるサービス、たとえば検索や提案の中身が価値を左右するものは、ここまで作らないと確かめられないことがあります。
気をつけたいのは、必要以上に精度を上げないことです。見た目を完成品のように作り込むと、見る人の意見が色や文言などの細部に集まり、確かめたかった流れについての意見が出にくくなります。また、作り込んだものは、作った側が捨てにくくなります。
プロトタイプ開発の工程
工程は、次の順で進めます。
- 確かめたいことを一つ決める。「この申し込みの流れで、初めての人が最後まで進めるか」のように、一文で書きます。目的が複数あると、試作が大きくなり、結果も読み取りにくくなります。
- 対象の利用者と場面を決める。誰が、どんな状況で使うのかを決めます。ここが曖昧だと、確かめる相手を選べません。
- 利用者にやってもらう課題を決める。「来週の予約を一件入れ、その後で時間を変更してください」のような、具体的な課題を用意します。試作は、この課題に必要な画面だけを作ります。
- 必要な精度で作る。前の節の種類から選びます。課題に関係しない画面は作りません。
- 利用者に触ってもらい、観察する。操作の仕方は説明せず、どこで止まり、何を見て、何を言ったかを記録します。感想を聞くより、行動を見ます。進め方は操作を説明しないユーザーテストの方法で詳しく扱っています。
- 結果を整理し、直す。つまずいた箇所を、原因ごとに分けます。言葉が分からない、次に何をすればよいか分からない、そもそも流れが業務に合っていない、などです。直したら、別の利用者でもう一度確かめます。
- 次の段階に渡す。確かめられたこと、直した理由、まだ確かめていないことを記録し、要件の定義や開発に渡します。
この工程で見落としやすいのは最後の段階です。試作そのものより、なぜその形になったのかという理由のほうが、後の開発で役に立ちます。理由が残っていないと、開発の途中で同じ議論をやり直すことになります。要件への落とし込みはMVPの要件定義で作らない範囲まで決める方法につながります。
PoC・MVPとの使い分け
プロトタイプ、PoC、MVPは、作るものの大きさの順ではなく、答える問いの違いで使い分けます。
- 「この形で伝わるか、使えるか」を確かめたいなら、プロトタイプです。
- 「技術的に実現できるか、業務の中で成り立つか」を確かめたいなら、PoCです。
- 「顧客が実際に使い続け、対価を払うか」を確かめたいなら、MVPです。
順番は決まっていません。もっとも不確かなものから確かめます。たとえば、技術は確かで、顧客の課題も聞き取りで確かめてあり、残る不安が「画面が複雑で現場の人が使えないのではないか」であれば、プロトタイプから始めます。技術的に実現できるかが分からない場合は、画面を考える前にPoCで確かめます。
組み合わせて使うこともあります。プロトタイプで流れを確かめてからMVPを作ると、公開した後に「使い方が分からなくて使われなかった」という、仮説とは関係のない理由での失敗を減らせます。整理の仕方はPoC・試作画面・MVPを答えたい問いから選ぶ考え方にまとめています。
プロトタイプ開発とアジャイル開発の違い
開発の進め方としての違いも、概念のレベルで簡単に整理します。
開発手法としてのプロトタイプ開発は、早い段階で試作を作り、発注者や利用者の確認を受けて要件を固め、その後に本番の開発に進む考え方です。要件を文書だけで固めて順に作り進める方法に比べ、認識の違いを早く見つけられます。試作は、確認が済んだら捨てる場合と、それを元に本番を作る場合があります。
アジャイル開発は、短い期間ごとに、実際に動く製品の一部を作って確認することを繰り返す考え方です。作るものは試作ではなく、本番の一部です。
つまり、プロトタイプ開発は「本番の前に試作で確かめる」、アジャイル開発は「本番を小さく作りながら確かめ続ける」という違いです。両者は排他的ではありません。アジャイルに進める開発の最初や途中で、新しい画面の流れをプロトタイプで確かめてから実装する、という組み合わせは自然です。発注側の関わり方は発注側の判断を止めないアジャイル開発の会議設計で扱っています。
よくある質問
Q. プロトタイプをそのまま本番のシステムに使えますか。
画面だけの試作は、本番には使えません。一部が動く試作は使える場合もありますが、確かめることを優先して作ったものは、安全性や保守のしやすさが本番の水準に達していないことがあります。そのまま使うつもりなら、作る前にその方針を決め、作る人と共有します。後から方針を変えると、どちらの目的にも合わないものになります。
Q. 何人くらいの利用者に確かめればよいですか。
一律の人数は示せません。対象とする利用者の種類ごとに数人に試してもらい、同じ箇所でのつまずきが繰り返し現れるかを見ます。新しい発見が出なくなってきたら、直して次の回に進みます。一度に多くの人で試すより、直しながら少人数で繰り返すほうが、直した結果を次の回で確かめられます。
Q. 社内の人に試してもらうだけでは不十分ですか。
認識をそろえる目的であれば十分です。使えるかを確かめる目的であれば、社内の人はサービスの背景を知っているため、実際の利用者がつまずく箇所を通り過ぎてしまうことがあります。対象の利用者に近い人に、背景を説明せずに試してもらうことが必要です。
Otsumuに相談できること
Otsumuは、新規事業の検証・MVP開発・運用の自動化を、戦略と開発を分けずにひとつのチームで支援しています。プロトタイプに関わる範囲としては、PoC / MVP Sprintの成果物に、検証目的・機能範囲の合意と、主要画面と利用シナリオが含まれます。その先の検証用のPoC / MVPシステム、効果測定の項目・計測設計、検証結果と次フェーズの改善方針までを、6週間を目安に設計します。参考価格は税別300万円〜で、機能数・外部連携・セキュリティ要件で変動し、正式な見積もりは相談後です。
紙や画面だけの試作は、社内で十分に進められます。この記事の工程で、まず一つの課題から試してみてください。確かめるべきものがプロトタイプなのか、PoCやMVPなのかを整理したい場合は、30分の無料診断でお話をうかがいます。5つの質問による診断で、現在地を先に確かめることもできます。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21