プロトタイプ開発とは、アプリケーションやシステム開発における手法の一つです。
本番環境にリリースする前に試作品を開発し、発注元に試験・評価をしてもらいます。これにより、修正リスクを軽減でき、場合によっては人件費などのコストを大幅に削減できます。
広く用いられている手法ですが、開発担当者のなかには「プロトタイプ開発の具体的なメリットは何？」「アジャイルやMVPとどう使い分けるべきなの？」と疑問がある方も多いことでしょう。
そこで今回はプロトタイプ開発について、概要、具体的なメリット・デメリット、他の開発手法との違いなどを網羅的に解説します。気になる方はぜひ記事を読んだうえで、発注元・発注内容に応じて取り入れてみましょう。
＼ ホワイトペーパー ／
貴社のPowerApps導入をぐっと前に進めるための
資料3点セット
【下記の３点の資料が無料でダウンロードできます】
- Powe Apps 活用事例集
- 【MS365で使える範囲も分かる】PowerAppsのライセンス早見表
- 【担当者のスキルレベルや導入の進め方から判断！】PowerPlatformで内製化をすすめるためのロードマップ
プロトタイプ開発の概要
Webサービス仕組みの初期段階で、必要最小限の機能を試作開発したものをプロトタイプと言います。
この試作品を基にして試験・評価・修正のサイクルを何度も繰り返しながら徐々に完成度を高めていく手法をプロトタイピング開発技法と称します。
プロトタイプ開発とは？
プロトタイプ開発は、Webサービス提供プロジェクトの早期段階で試作品を作成して、その試作品を発注元に試験・評価してもらう開発技法です。
通常のソフトウェア開発との違い
プロトタイプ開発と製品班・実装版の開発との相違を紹介します。Webサービス提供システムを早期の段階で確認することで、費用を最低限に抑えることができます。
量産品・実装版の開発工程に遷移してからの仕様変更は膨大な費用が必要です。その仕様変更を抑止するためにプロトタイプ開発を導入します。
ウォーターフォール開発との違い
ウォーターフォール開発とは、その名の通り上流から下流にかけて進めていく開発手法です。既に大方の要件が定まっている場合は、開発途中で大きな変更点は生まれにくいため、ウォーターフォール型の開発を採用しやすいといえます。
プロトタイプ開発の場合はプロジェクトの早期段階で試作品を確認してもらいますが、ウォーターフォール型の場合は確認の作業が入りません。
ただし「開発者に任せきり」というわけではなく、ウォーターフォール型の場合でも開発チーム内で細かく確認しながら完了まで進めていきます。
ウォーターフォール開発については、以下の記事で詳しく説明しています。こちらも参考にしてみてください。
アジャイル開発との違い
アジャイル型の開発は、開発工程を細かく区切ったうえで、一つの工程が完了するたびに、利用者などに確認を取りながら進めるスタイルです。
最終形が定まっていない場合は、利用者にイメージしてもらえるように試行錯誤しながら開発を進める必要があるため、アジャイル開発がよく用いられます。
プロトタイプ開発では「試作品を確認してもらう」に留まりますが、アジャイルの場合はより密にコミュニケーションを取りながら確認してもらいます。
アジャイル開発については、以下の記事で詳しく説明しています。こちらも参考にしてみてください。
MVP開発との違い
MVPとは「Minimum Viable Product」の略です。日本語に訳すると「最小限の価値を提供するプロダクト」となります。
MVP開発とプロトタイプ開発はよく似ています。違いは「試作品をプロジェクト内メンバーに使ってもらうか、市場にリリースするか」です。プロトタイプ開発の場合はプロジェクト内（開発チーム、クライアント等）の反応を見ますが、MVPは実際に市場にリリースしたうえでユーザーのリアクションを確認します。
MVPには「オズの魔法使い」「スモークテスト」「コンシェルジュ」などの手法があります。利用ユーザーの規模感、ターゲットの種類によって使い分けられます。
MVP開発については、以下の記事で詳しく説明しています。こちらも参考にしてみてください。
プロトタイプ開発の目的
プロトタイプ開発の目的を紹介します。プロトタイプ開発は、Webサービス・アプリケーション開発中に発生する仕様変更による手戻り・費用増加のリスクを抑制する目的で採用されます。
初期段階で必要な機能を明確にした上でアプリケーション開発します。そのため大幅な手戻り・費用増加のリスクを抑止します。
開発リスクの軽減
初期段階でフィードバックを得られることです。プロトタイプ開発を作成することで、問題の早期発見が実現できます。
量産品・実装版の開発を開始してから仕様変更が発生したとき、それまでの作業が無駄になるリスクを抑止することができます。
仕様認識の共有化
発注元と開発先の認識(仕様)の乖離に解消に繋がります。プロトタイプ開発版を発注元で使用確認・検証することで、発注元との認識の乖離を抑止できます。
認識の乖離は、発注元と開発先との要件定義・概要設計の共有化がされていないことです。
仕様変更の手戻り抑制
量産品・実装版を開発するために、プロトタイプ開発をすることで開発コストを軽減することができます。
量産品・実装版の開発工程に遷移してからの仕様変更は手戻り・費用増加に繋がります。プロトタイプ開発中に仕様変更を組み入れることができる開発技法です。
プロトタイプ開発のメリット
プロトタイプ開発のメリットを紹介します。Webサービスやスマートフォンアプリケーション、パソコンソフトウェア開発においてプロトタイプ開発採用するケースが多いです。
初期段階で仕様を確定できる
発注元・一般ユーザーのニーズを満たすアプリケーションを開発し易いことです。プロトタイプ開発は初期段階で試作品を作成して、発注者・一般ユーザーから意見・仕様変更を受け取ります。
発注元・一般ユーザーからの意見・仕様変更を踏襲した量産品・実装版を製作するために、ニーズを満たすアプリケーション開発を実現させます。
開発コスト費用の軽減化
手戻り工数や追加費用を削減ができます。プロトタイプ開発は手戻り工数・追加費用を最低限に抑えるために開発費用を軽減することができます。
事前に多岐に渡る試験を実施しても、全ての性能を問題なく発揮するアプリケーションを完璧に開発できるとは限りません。量産品・実装版の開発工程で想定外の不具合・仕様変更が生じたときは、多大な手戻り・追加費用が発生するケースは多々あります。
プロジェクト開発リスクを低減できることは、プロトタイプ開発の大きなメリットです。
仕様の認識を共有化できる等
仕様の認識を共有化することに最適です。プロトタイプ開発でWebサービス・アプリケーションを製作することで、プロジェクトメンバー全体で認識の共有化が図れます。
要件定義だけでは最終的なアプリケーション仕様を想定するのは難しくなります。発注元・開発先で仕様の共有化が図られない可能性があります。
発注元・開発先で仕様の認識に乖離がある状態でアプリケーション開発を進めていくと、想定外な不具合が生じるようです。
しかし、プロトタイプ開発は試作品を作成するので、発注元・開発先間で量産品・実装版に関する仕様の認識を共有化できます。カットオーバー後のトラブルが生じるリスクを低減できます。
プロトタイプ開発のデメリット
プロトタイプ開発は他の開発手法と比べてデメリットもあります。事前に対処法を確認したうえで採用しましょう。
プロジェクトの規模によって向き不向きがある
プロトタイプ開発は、試作品を試してもらい、フィードバックを受けて、本格的に開発を進めます。
つまり検証・評価の担当者が増えると、それだけ改善案も増えていきます。すると「フィードバック～改善」のサイクルが長期間続いてしまうこともあります。すると開発のスピード感が失われるのがデメリットです。
プロトタイプ開発は「成果物について、ある程度のイメージを共有できている」という前提があるからこそ成立する手法です。
しかしフィードバックが長期間続くということは「成果物のイメージが関係各所で定まっていなかった」という背景があります。事前に成果物について、イメージを共有しておくことが重要です。
開発費用が膨らみやすい
プロトタイプ開発では「プロトタイプ」と「本番」の2つを開発する必要があります。プロトタイプといっても、本番環境の性能に近づけたものを作るため、作成回数が増えると必然的に開発コストも上がります。
コストを抑えるためには「作成回数を減らすこと」が重要です。そのためプロトタイプ開発前段階で要件定義をしっかり固めておき、漏れがないようにしましょう。事前に利用ユーザーと十分にヒアリングをしたうえで要望を吸収しておくことが大切です。
予定よりも長期化するリスクがある
先述した通り、プロトタイプに対して修正点や要望がたくさん出た場合、それだけ対応工数がかかります。すべてに対応するとなると、開発側の負担も大きくなっていきます。
プロトタイプを開発する前にしっかりと成果物のイメージを共有することはもちろん大切です。
また「修正対応をする範囲」「実際に利用者となるレビュアーの数」は、最初に制限をしておくことをおすすめします。無制限のまま、すべてに対応してしまうと、理想だけが先走ってしまい、リリースが遅れていきます。
フィードバックに対して優先度を決めたうえで「どこまでをプロトタイプ段階で修正するか」「どこまでを本番リリースの機能要件に含めるか」「どこからをリリース後の改修項目とするか」を定義することが重要です。
プロトタイプ開発の流れ・工程
実際のプロトタイプ開発の流れについて紹介します。
要件定義
はじめに開発するシステムの仕様や機能を定義していきます。前提として利用想定ユーザーにきちんとヒアリングをします。そのうえで要望を満たせるシステムを開発しなければいけません。
主に以下の項目を丁寧に定義していきましょう。
- プロジェクトの概要・目的
- 背景情報
- 関係者・レビュー担当者
- システムの目標と範囲
- システムの主要な目標
- システムがカバーする範囲（スコープ）
- システムが対応しない範囲（スコープ外）
- 品質保証要件
- テスト戦略
- テストケースの作成
- テスト実施計画
- リスク管理
- 潜在的なリスクの特定
- リスクの優先順位付け
- リスク対策
- スケジュールとマイルストーン
- 予算・費用
ただしプロトタイプ開発の場合、後から検証や改善を行うので、このタイミングでは必要以上に細部まで作りこまないようにします。
設計
プロダクトのデザインや機能など、実装方法を設計します。主に以下の項目について整理し定義していきます。
- 機能要件
- 必須機能の一覧
- 各機能の詳細説明
- ユーザーストーリーやユースケース
- 機能間の依存関係
- 非機能要件
- 性能要件（応答時間、スループットなど）
- 可用性要件
- セキュリティ要件
- 拡張性要件
- 保守性要件
- 互換性要件
- UI要件
- データ要件
- システム統合要件
- 技術要件
- プログラミング言語、フレームワーク、ツールなど
- 開発環境
- テスト環境
これらの項目が揃ったら、プロトタイプの開発に着手していきましょう。
プロトタイプ作成
要件定義・設計段階で定義した項目に基づいて、プロトタイプを作成します。後工程でフィードバック・修正が発生するため、このタイミングでは必要最小限の機能を搭載したものを開発します。
ここで間違いがちなのは「先にフィードバック内容を主観で判断してプロトタイプに盛り込んでしまうこと」です。あくまで、ユーザー主体で機能を搭載するための開発手法なので、勝手な判断は危険です。フィードバックの段階で「必要ない」と言われてしまう可能性があります。
フィードバック・修正
プロトタイプをもとにユーザーからフィードバックをもらうフェーズです。フィードバック内容をもとに改善・修正を行います。修正が完了次第、再度ユーザーに共有しフィードバックを受け取ります。このサイクルを当初決めた機能要件を満たすレベルまで続けていきます。
先述しましたが、このフィードバックと修正のサイクルが長期的に続いてしまい、想定していたスケジュールを超過してしまうケースはたびたび起こります。
スケジュールが長引くと、それだけコストもかかってしまいます。事前にスケジュール・コストともに上限を決めておき、守れるようにコントロールするスキルが必要です。
本番開発・リリース
フィードバック、修正をもとにプロトタイプが着地したら、最終的に決まった細かな仕様をもとに本番開発を行います。
プロトタイプ開発の魅力は、本番反映後の追加修正が少なく済む点です。本番リリース前の最終確認で膨大な修正点が出ないように、ユーザーとコミュニケーションを取りましょう。
また微修正が発生する場合は「本番反映前のタスクか」「リリース後に対応するか」を判断する必要があります。
リリース後は運用・保守へのフェーズに入ります。利用するなかで新たな改善点が生まれますので、継続的にユーザーからフィードバックを受けつつ、安定して運用できるまで改善を繰り返しましょう。
プロトタイプ開発の費用相場
プロトタイプ開発の種類別費用の相場は下記表の通りです。
| № | ソフトウェアの種類 | 費用相場(下限) | 費用相場(上限) |
| 1 | ショッピングカート・EC機能開発 | 100万円 | 300万円 |
| 2 | 商品カタログ・パンフレット作成 | 50万円 | 100万円 |
| 3 | 通話系・メッセージアプリケーション開発 | 100万円 | 500万円 |
| 4 | 各種アプリケーション・ツール系開発 | 50万円 | 300万円 |
| 5 | ゲーム系ソフトウェア開発 | 300万円 | 1,000万円 |
| 6 | ソーシャル・ネット・ワーク位置情報開発 | 500万円 | 1,000万円 |
| 7 | Ｗｅｂサービス上の課金系ソフトウェア開発 (Amazonなどの通販購入・音楽サイトの楽曲をDL購入して使用権を購入する仕組み) | 10万円(1) | 20万円(1) |
(1)過去の開発実績資産を基に修飾利用してプロトタイプ開発したケースでの参考金額です。
プロトタイプ開発の機能別費用の相場は下記表の通りです。
| № | 機能の種類 | 費用相場(下限) | 費用相場(上限) |
| 1 | Ｗｅｂサービスへのログイン機能開発 | 10万円 | 20万円 |
| 2 | アプリケーション内の決済機能開発 | 20万円 | 50万円 |
| 3 | ブッシュ通知機能(サーバ側からの情報通知) | 10万円 | 100万円 |
| 4 | ナビゲーション機能開発 | 2万5,000円 | 5万円 |
| 5 | 画面表示切換え機能開発（縦表示⇔横表示） | 5万円 | 10万円 |
| 6 | 位置情報表示機能開発 | 10万円 | 25万円 |
| 7 | チャット・メッセージ機能開発 | 20万円 | 40万円 |
| 8 | 多システムのアプリケーション連携機能開発 | 5万円 | 40万円 |
| 9 | Ｗｅｂサービス画面実装機能開発 | 10万円 | 100万円 |
プロトタイプ開発がおすすめなケース
プロトタイプ開発が特におすすめなケースを、ウォーターフォール型、アジャイル型と比較したのが、以下の表です。
| 項目 | ウォーターフォール型がおすすめ | アジャイル型がおすすめ | プロトタイプ開発がおすすめ |
| プロジェクトの不確実性 | 要件が明確で、変更が少ない場合 | 要件が定まっておらず、柔軟な対応が必要 | 要件が一部定まっており、ユーザーのフィードバックを通じて明確化する必要がある場合 |
| ユーザーの関与 | ユーザーの関与が少なくて済む場合 | ユーザーと頻繁にコミュニケーションを取りながら進めたい場合 | ユーザーのフィードバックが重要で、早期にプロトタイプを見せて意見をもらいたい場合 |
| 開発速度 | 明確な計画に基づき、順序立てて進めるため、予定通り進行しやすい場合 | 短いスプリントで頻繁にリリースを行い、逐次改善したい場合 | 早期に動作するモデルを作成し、フィードバックを基に迅速に修正したい場合 |
| コスト管理 | 初期の計画段階でコストを厳密に見積もり、変更が少ない場合 | コスト変動に柔軟に対応できる場合 | コストが不確定で、試行錯誤を通じて最適な解を見つけたい場合 |
プロトタイプ開発はユーザーの声をもとに開発を進めていく手法です。例えば新規サービスなど、実現性が不確実なケースなど、いきなり本番リリースを進めることにリスクがある際に採用されます。
プロトタイプ開発の成功事例
プロトタイプ開発の成功事例を紹介します。
Coloplast
Coloplast社はデンマーク発の医療用装具・治療材料で世界トップクラスのメーカーです。同社は人工肛門保有者などの負担を軽減するために、ストーマ袋やカテーテルを装着しながらの生活が楽になるためのメンテナンス支援アプリを考えていました。
そのうえで重要なのはユーザー満足度です。同社はストーマケアアプリとカテーテルアプリを、専門家だけでなく実際の患者に使ってもらいながらプロトタイプを開発しました。
参考：Coloplast｜デジタルソリューションを介してオストミー患者の生活の質を改善｜モンスターラボグループ
Nintendo Labo（任天堂）
Nintendo Laboとは段ボール、Nintendo Switch、ゲームソフトを使って、自分でコントローラーを使いながら遊べるプロダクトです。
この製品はセンセーショナルです。前例がないため、リリースしても遊ばれない、というリスクがあります。そのため任天堂はプロトタイプを子どもたちに使ってもらいながら、開発を進めました。
Nintendo Laboは段ボールを使って遊ぶ製品です。段ボールの試作品は低予算で作れます。プロトタイプ開発としては相性がいい素材です。
参考：Nintendo Labo : 開発者INTERVIEW | Nintendo Switch | 任天堂
G-Force（ダイソン）
G-Forceとは、最初にダイソン社がリリースした掃除機です。創業者ダイソン・ジェームス氏は、掃除機の吸引力が落ちる原因を「紙パックの目詰まり」だと定義しました。
その後、5年間で5,000以上の試作品を作成し、フィードバックを受けて修正し続け、完成したのがG-Forceだったといいます。
その結果、ダイソンの製品は現在でも掃除機の市場で大きなシェアを獲得するに至っています。参考：5000回以上の失敗「楽しむ」 ダイソン創業者の挑戦｜日経BizGate
まとめ
試作品を作成する工数が必要ですが、量産品・実装版の開発工程で大幅な手戻り・仕様変更が生じるリスクを抑制することができ技法が、プロトタイプ開発です。
不確実性の高い新規分野は、プロトタイプ開発でリスクを低減させることが有効的です。
