プロトタイプ開発は、小〜中規模であれば約3週間が目安です。仮説設計、画面設計、試作テストの順に進め、操作感を確かめます。
新規プロダクトやアプリの企画では、文書や静止画だけだと認識がずれやすく、期間・納期の遅れも懸念されます。全体像は、下の完全ガイドでも確認できます。
▼全体ガイドの記事
・プロトタイプ開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
プロトタイプ開発の期間が「短い」理由
プロトタイプは検証を素早く行うため、本開発より短い期間で作ります。中規模のWebアプリやスマホアプリの本開発は、2〜4ヶ月以上かかります。
具体的には、小〜中規模のプロトタイプは約3週間が目安です。ただし、期間を延ばして作り込みすぎると、検証の速さという利点が失われます。
試作の期間は、何を確かめるかによって変わります。短期間で作れる理由と短くすべき理由を理解しておくと、作り込みすぎて検証が遅れるのを防げます。
プロトタイプは「操作感」を確かめる試作
プロトタイプでは、ユーザーが画面を迷わず使えるかを、実際に触れる試作品で確かめます。
検証の対象はUI・UXの操作感です。裏側のロジックや大量アクセスへの対応など、システムの内部品質は対象にしません。
たとえば検索ボタンを押したときは、実データベースではなく、用意したダミーの結果を表示すれば検証できます。見るのは、検索操作に迷わないかです。
内部処理まで本物どおりに作ると、本開発に近い規模となり、期間も費用も増えます。そのため、画面と操作感に対象を絞り、それ以外の作り込みを省くことが、短納期の前提になります。
- 画面配置：情報が分かりやすく置かれているか
- 画面遷移：操作後の移動が自然か
- 操作の到達性：目的の操作まで進みやすいか
PoC・モックアップ・MVPとの期間の違い
PoC（Proof of Concept＝概念実証）は、技術的に実現できるかを確かめる手法です。新しいAIモデルの精度や基幹システムとのAPI連携などを検証し、見た目や操作感は作り込みません。
モックアップは配色やレイアウトのイメージを関係者と共有する手法で、プロトタイプは画面をクリックして遷移できる状態まで作り、操作感を試します。
MVP（最小実用プロダクト）は、実際に動く製品を公開し、継続率や収益をもとに需要を測ります。
PoCからプロトタイプ、MVPへと検証する問いが深くなるほど、期間も長くなります。そこで、操作感の検証が目的なら、期間を延ばす前に別の手法の目的が混ざっていないかを確認します。
類似の試作手法は目的が混同されやすいため、違いを押さえておくと、プロトタイプに適した期間を判断しやすくなります。各手法は確かめる内容が違い、期間の目安も異なります。
- PoC：数日〜2週間
- モックアップ：1〜2週間程度
- プロトタイプ：約3週間
- MVP：1〜3ヶ月
小〜中規模で「約3週間」が目安となる根拠
約3週間という目安は、検証に必要な工程から逆算して出したものです。要件定義・仮説設計では課題と機能を絞り、デザインカンプでは本番に近い見た目を作ります。
ワイヤーフレームで画面の骨組みを描き、クリッカブルデモでリンクとタップ遷移を作ります。テストでは対象ユーザーに触れてもらいます。
画面数が多い場合や、複数のユーザー層でテストする場合は、4〜5週間に延びることもあります。期間は月単位でなく、週単位で考えます。
なお、2〜3ヶ月かかるなら、MVPや本開発の範囲に入っている可能性があります。操作感を素早く確かめる目的から外れていないか、点検します。
期間を短く区切ることで、検証結果を早く得て、次の判断に進めます。約3週間のうち、仮説設計とデザインカンプの2工程が大半を占めます。
- 要件定義・仮説設計：約1週間
- デザインカンプ作成：約1週間
- その他の工程：各数日
プロトタイプ作成の典型的な工程とスケジュール
工程を分けて各フェーズの日数を事前に決めておくと、予定どおりに進めやすくなります。一般的には5つの工程を順に進め、後工程ほど前工程で出来上がったものに依存します。
約3週間で完成させる想定で、工程ごとの作業内容と期間、工数配分を見積もります。配分を把握すると、時間をかける工程と軽くする工程を判断できます。
- 要件定義・仮説設計
- ワイヤーフレーム作成
- デザインカンプ作成
- クリッカブルデモ構築
- ユーザーテスト・検証
要件定義・仮説設計とワイヤーフレーム作成
要件定義・仮説設計には約1週間、全体工数の20〜25%程度を充てます。誰の課題を、どの機能で解決するかをここで決めておくと、後の工程が定まりやすくなります。
作る画面は、検証したい操作の範囲に限ります。たとえば会員登録から商品検索、カート投入までの流れが対象になります。
何が分かれば成功かを決め、関係者で合意しておきます。ここまで決めておくと、後から画面を追加する要望が膨らむのを防げます。
ワイヤーフレーム作成には数日を見込みます。色や装飾を省いた段階で、情報の配置と画面の遷移を描きます。
先に色付きのデザインを作ると、構成を変えたときの手間が大きくなります。そのため、白黒の骨組みで合意してから装飾に進みます。
- 対象を絞る：検証する課題と操作フローを決める
- 成功条件を合意する：仮説を1ページにまとめる
- 骨組みから描く：白黒の画面で配置と遷移を確認する
デザインカンプ作成とクリッカブルデモ構築
ワイヤーフレームの合意後、デザインカンプを作ります。約1週間、全体工数の15〜20%程度を見込みます。
デザインカンプでは、ブランドカラーやタイポグラフィ（書体・文字サイズ）、アイコンまで整えるため、本番に近い見た目を確認できます。
ボタンの見えやすさや文字の読みやすさは、操作感の検証と並行して確認します。続くクリッカブルデモの構築には、数日を充てます。
クリッカブルデモは、画面をリンクでつなぎ、ボタンをタップすると遷移する「動くモック」です。FigmaやAdobe XDなら、コードを書かずに作れます。
たとえば、目的の画面まで2タップ余計にかかる導線や、戻るボタンの位置の分かりにくさは、実際に触って初めて気づけます。画面を動かせる状態にすることが、操作感を検証する核心です。
- デザインカンプ：本番に近い見た目を整えた静止画
- クリッカブルデモ：画面遷移をタップで試せる試作品
ユーザーテストと工数配分の目安
最後の数日はユーザーテストに充て、ターゲットユーザーにデモを操作してもらいます。目的の操作に迷わず進めるかを観察します。
思考発話法では、操作ごとに「次はどうすればいいと思いますか」と声に出してもらいます。これにより、つまずいた箇所を明確にできます。
完了率や完了時間、迷った箇所の数は記録しておきます。たとえば、商品をカートに入れるタスクを何割完了できたかも測ります。
定量・定性のデータからUIの改善点を判断し、必要なら画面を修正して再テストします。工数は、要件定義に20〜25%、デザインカンプに15〜20%程度です。
残りの工数は、ワイヤーフレーム、デモ構築、テストに振り分けます。
- 観察する：操作中の迷いを思考発話法で把握する
- 記録する：完了率、完了時間、迷った箇所を測る
- 配分する：前半の仮説設計を重視し、後半を軽くする
納期を短縮する進め方
プロトタイプの価値は、早く作って検証し、次の判断に進める点にあります。同じ結果を得られる範囲で納期を短くする工夫は、効果が大きくなります。
検証の質を保ちながら不要な作り込みを省く具体策は、MoSCoW法での機能選別、6割の完成度での反復、デザインツールやノーコードによる工程の圧縮です。
MoSCoW法による検証機能の絞り込み
検証に必要な機能だけに絞れば、納期を短縮できます。MoSCoW法では、機能を次の4段階に分けます。
- Must：必須
- Should：推奨
- Could：あれば良い
- Won’t：今回はやらない
作るのは、操作感の検証に欠かせないMustの画面と機能に限ります。たとえば会員登録から商品検索、カート投入を試すなら、その流れに必要な画面をMustにします。
お気に入りやレビュー投稿、設定画面などはShould以降に回します。この絞り込みによって、見積もりの期間・費用は30〜50%、つまり3〜5割下がります。
全画面をそろえたくなるのは自然なことです。ただし、検証に不要な画面を足しても結果は変わらず、納期が延びます。そのため、プロトタイプでは仮説に直接関わる機能だけをMustに残します。
「6割の完成度」による素早い反復
プロトタイプは100%を目指さず、6割の完成度で早く形にします。目的は完成品を作ることではなく、関係者やユーザーとの認識のズレを早期に見つけることです。
100点の試作に2週間かけるより、6割程度でも触れるものを数日で見せるほうが、ズレを早く発見できます。その結果、開発速度も上がります。
作り込んでいる間は意見をもらえないため、ズレの発見が遅れます。完成後に根本的な方向性の違いが分かれば、その作り込みは無駄になります。
まずは粗くても動くものを見せ、意見を受けて直す流れを何度も繰り返します。未完成の試作品を早く見せて直すことが、プロトタイプの使い方です。
- 早く形にする：まず触れる状態を目指す
- 意見を受ける：認識のズレを早期に把握する
- 修正を重ねる：フィードバックを踏まえて直し、再び試す
ツール・ノーコードによる工程の圧縮
デザインツールやノーコードツールを使うと、工程を圧縮できます。FigmaやAdobe XDなどのUIデザインツールなら、カンプ作成からデモ構築まで、同じツール内でコードを書かずに進められます。
デザイナーとエンジニアが同じ画面を見て話せるため、認識合わせの往復も減らせます。
データ保存や検索結果の表示まで試す場合は、Bubble、FlutterFlow、STUDIOなどのノーコードツールが候補です。これらを使えば、フルスクラッチで作る場合の30〜50%のコスト・期間で、データ連携を含む試作品を構築できます。
検証の深さに合わせてツールを使い分けると、必要十分な作り込みに抑えられます。画面遷移と見た目だけならFigmaなどで足ります。擬似的なデータの動きまで試すなら、ノーコードを選びます。
ツール選定の段階から過剰な作り込みを避けることが、納期短縮の出発点です。
- 画面と見た目を確認：Figmaなどのデザインツール
- データの動きも確認：ノーコードツール
納期が伸びる原因と対策
短期間で終えるはずの試作でも、スケジュールがずるずる延びることがあります。納期遅延は、検証範囲の膨張、目的の曖昧さ、進め方と契約形態の不一致で起こり、いずれも事前の対策で防げます。
検証範囲の膨張（ミニ本開発化）
納期遅延の最大の原因は、検証範囲の膨張です。本物どおりに動かしたい機能や認証などが加わると、操作感の検証を超えて本開発に近づいてしまいます。
この状態は「ミニ本開発化」とも呼ばれます。その結果、プロトタイプの短納期・低コストという利点が失われ、期間と費用が大きく超過します。
そこで、最初に決めた検証範囲を関係者全員で守ります。新しい要望は、仮説に関係するかを問い直し、本開発に回せないかも考えます。
Won’tに分類した機能を明文化しておき、要望が出るたびに照らして判断します。作らない部分を決めることは、作る範囲を決めることと同じだけ大切です。
- 要望を問い直す：検証仮説に関係するか確認する
- 本開発に回す：今回の範囲から外す機能を決める
- Won’tを参照する：追加要望を事前の分類と照合する
検証目的の曖昧さによる手戻り
目的を決めずに作り始めると、何を確かめる試作なのかが分からなくなります。画面の方向性が定まらず、作り直しも発生します。
デザインの好みや細部の議論に時間を取られ、操作感の検証が進まないこともあります。そうならないよう、着手前に確かめたいことと成功の目安を先に決めておきます。
この計画書は関係者で合意しておきます。たとえば、初めて使う人が説明なしで会員登録から商品購入までを80%以上完了できることを、基準にできます。
基準があれば、デザインの議論でも検証目的に役立つかどうかで判断できます。目的を先に言葉にしておくことが、手戻りを防ぐ最も効果的な方法です。
- 検証内容を決める：何を確かめるか計画書に記す
- 成功条件を置く：完了率など具体的な基準を合意する
- 判断に使う：検証目的に沿って決める
契約形態とスケジュールの守り方
プロトタイプは試作しながら仕様を固めるため要件が変わりやすく、契約形態が進め方に合わないと遅延につながります。
成果物の完成を約束する請負契約では、仕様変更のたびに追加費用や契約変更の交渉が起き、スケジュールが停滞することがあります。
作業時間や体制に対して費用を払う準委任契約は、要件が固まらない段階での仕様変更に対応しやすく、相性が良いとされます。
発注時には、検証内容、想定期間、今回の範囲をパートナーと確認します。ユーザーテストと次の判断の日も、先に決めておきます。
ゴールから逆算して各工程の締め切りを置くと、作り込みすぎを抑えられ、約3週間の納期を守りやすくなります。
- 契約を選ぶ：仕様変更の起こりやすさを踏まえる
- 範囲を合意する：検証内容と期間を共有する
- ゴールから逆算する：テスト日と工程の締め切りを置く
まとめ
プロトタイプは、動くUIと操作感を確かめる試作です。小〜中規模なら、約3週間で作れます。
工程は、仮説設計、画面設計、デモ構築、ユーザーテストの順に進みます。検証範囲を絞り、短い周期で試作と修正を重ねます。
PoCは「作れるか」、プロトタイプは「使えるか」、MVPは「売れるか」を検証します。操作感の確認なら、週単位で進められます。
納期を短くするには、MoSCoW法で機能を絞ること、6割の完成度で見せること、ツールを活用することが役立ちます。目的や範囲、契約形態も事前に整えておきます。
MoSCoW法による絞り込みで、見積もりの期間・費用は3〜5割減ります。一方で、範囲の膨張や目的の曖昧さ、請負契約との不一致は遅延につながります。
素早く作って検証する日程は、本開発での手戻りを抑え、開発全体を前に進める手段になります。進め方やパートナー選びに悩む場合は、開発会社への相談も選択肢です。
▼全体ガイドの記事
・プロトタイプ開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。