プロトタイプ開発を外部に頼むとき、多くの担当者が迷うのは、試作の要件の書き方と、RFP（提案依頼書）で何を伝えるかです。本番の要件定義書をそのまま流用すると、試作には過剰な要求になり、見積りが膨らんでスピードも失われます。
全体像がまだの方は、まずプロトタイプ開発の完全ガイドをお読みください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
検証目的と成功・撤退基準の明文化
プロトタイプのRFPで最初に書くべきは、「この試作で何を検証したいのか」という検証目的です。プロトタイプは画面の見た目と操作感（UI/UX）を確かめる試作なので、操作性のどこに不安があり、何を確かめたいのかを言語化しなければ、ベンダーは適切な試作を提案できません。
目的が曖昧なまま依頼すると、試作はできても判断材料にならないという最悪の結果を招きます。
RFP冒頭で示す検証したい問い
検証目的は「問い」の形で書くと明確になります。プロトタイプで検証するのは、技術の実現性（PoC）でも市場性（MVP）でもなく、あくまで操作性や使い勝手です。そのため、問いも操作の体験に関するものになります。
さらに、この検証の問いをRFPの冒頭に置くことで、ベンダーは試作の方向性を正しく理解できます。検証したいことが複数ある場合は、優先順位を付けて列挙します。すべてを一度の試作で検証しようとすると、試作が肥大化してスピードが落ちてしまうからです。
なかでも、不安が大きく、外したときの損害も大きい操作から優先して検証する設計が望ましいです。検証の問いを優先順位付きで明示しておけば、限られた予算と期間の中で、ベンダーが何を重点的に試作すべきかを判断できます。
試作にどの画面・操作を含めるかという具体的な範囲は、『プロトタイプ開発の必要機能や標準機能の一覧について』もあわせてご覧ください。
問いは「〜できるか」の形で一文にします。たとえば、現場の入力作業と初回利用の操作を、それぞれ問いにできます。
- 入力作業の完了：現場担当者が、マニュアルなしで主要な入力作業を完了できるか
- 初回利用の迷い：新規ユーザーが、初回利用で目的の操作に迷わずたどり着けるか
本開発に進む・止める判断基準の数値化
検証目的とセットで欠かせないのが、成功と撤退の判断基準です。「どうなったら本開発に進み、どうなったら止めるか」を、できるだけ具体的に、可能なら数値で定めておきます。
基準を先に決めておけば、試作後の判断が感情論やサンクコストに左右されずに済みます。
この基準の重要性は、隣接する検証手法の失敗からも裏付けられます。BCGの2024年の調査では、74%の企業がPoC段階を超えられていないとされ、検証が本番化につながらない「PoC死」が大きな課題になっています。その主因の一つが、成功・撤退基準の欠如です。
プロトタイプでも同じで、基準のない試作は「なんとなく良さそう」で終わるか、逆に「もう少し作り込めば」と延々と続いてしまいます。RFPに判断基準を明記することは、この曖昧さを断ち切る最大の防衛策です。
基準は、ユーザーテストの結果を数字で判断できる形にしておきます。たとえば、対象者の完了の割合と、主要動線で迷った人の割合で線を引けます。
- 成功の基準：ユーザーテストの対象者の8割が、マニュアルなしで主要操作を完了できたら、本開発に進む
- 見直しの基準：主要動線で半数以上が迷ったら、画面構成を見直す
RFPでの作るものと作らないもの（Won’t）の切り分け
プロトタイプのRFPで、本番システムのRFPともっとも異なるのは、「作らないもの」を明記する点です。試作の見積りが膨らみ、スピードが失われる最大の原因は、検証に不要な機能まで作り込んでしまうことだからです。
これを防ぐには、作る範囲と同じくらい丁寧に、作らない範囲（Won’t）を定義する必要があります。
Won’t（作らないもの）の明示と肥大化の防止
RFPには、試作であえて作らないと決めたWon’tの機能を、箇条書きで明記します。Won’tに入るのは、操作性の検証に直接関係しない要素です。「試作では対象外」と宣言しておくことで、ベンダーは無駄に見積りを膨らませずに済み、発注側も「なぜこの機能がないのか」と後から戸惑わずに済みます。
Won’tの定義は、試作の費用を直接左右します。一次データでも、試作段階で生成AIやノーコードを活用すれば、従来の50〜75%のコスト削減が可能とされます。ただし、これは「検証に必要な範囲に絞る」ことが前提です。
逆にWon’tを曖昧にしたまま本番同等の作り込みを求めれば、試作のはずが本開発並みの費用になりかねません。だからこそ、RFPでWon’tを明示することは、試作を試作らしい費用に抑えるための、もっとも実効性の高い手段です。
Won’tには、本番で求められる作り込みのうち、検証に使わないものが入ります。
- 例外と権限の作り込み：エラー処理や例外フロー、権限ごとの細かな出し分け
- 大規模データと連携：本番同等の大量データ、外部システムとの実連携、セキュリティの作り込み
忠実度とユーザーテスト設計の盛り込み
RFPには、求める試作の忠実度を明示します。忠実度によって必要な工数と費用が変わるためです。忠実度を指定せずに依頼すると、ベンダーごとに前提が異なり、見積りを比べられなくなります。
検証の段階に応じて二段構えで依頼するのが、コストを抑える定石です。
さらに、試作は作るだけでなく「触ってもらって学ぶ」ことが本質なので、ユーザーテストの設計支援もRFPに含めるとよいです。テストの設計では、誰に（想定ユーザーに近い何名に）、どんなタスクを与え、何を観察するかを決めておきます。
こうしたテスト設計を支援できるベンダーであれば、試作から得られる学びの質が上がります。ユーザビリティ検証では、5名程度でも主要な問題の大半が表面化するとされ、少人数でも有効です。
試作の制作とテスト設計をセットで依頼することで、「作って終わり」を避けられます。
忠実度の段階によって、試作で確かめられる中身が変わります。
- 低忠実度：ワイヤーフレームで情報構造を検証する
- 高忠実度：インタラクティブ試作で操作感まで検証する
追加費用と本開発移行の条件の取り決め
プロトタイプは試行錯誤の連続なので、当初の想定どおりに進まないことが前提です。このため、RFPと契約の段階で「追加費用の取り決め」と「本開発への移行条件」を明確にしておくことが、後のトラブルを防ぎます。
試作を「作って終わり」にせず、その先の本開発まで見据えた取り決めが、投資効果を左右します。
準委任契約による追加費用の発生条件の明確化
プロトタイプ開発は、検証の結果に応じて画面を作り直したり、追加の試作を行ったりすることが珍しくありません。そのため、成果物を固定する請負契約よりも、作業時間に対して報酬を払う準委任契約のほうが、試行錯誤を前提とする試作には適している場合が多いです。
RFPの段階で、どこまでが当初費用の範囲で、どこからが追加費用になるのか、その発生条件を明確にしておくことが、後の「言った・言わない」を防ぎます。
追加費用の罠を避けるには、修正の回数や範囲について、あらかじめ目安を取り決めておくことが有効です。曖昧なまま進めると、発注側は「これくらい無料でやってくれるはず」、ベンダーは「これは追加のはず」と認識がずれ、信頼関係を損ないます。
準委任契約であっても、こうした目安を共有しておけば、双方が安心して試行錯誤に集中できます。取り決める目安は、修正の範囲と想定外の画面追加の扱いの2点です。
- 修正の範囲：ワイヤーフレームの修正は3巡まで当初費用に含む
- 追加分の見積り：想定外の画面追加は別途見積り
RFPに織り込む本開発移行と知識の引き継ぎ
試作が成功し本開発に進む場合に備えて、移行の条件をRFPに織り込んでおきます。
とくに注意したいのが、試作チームと本開発チームの分断による知識の断絶です。試作で「なぜこの画面構成にしたのか」「どの操作がユーザーに評価されたのか」という文脈は、本開発の設計品質を左右する貴重な資産です。
これが引き継がれないと、本開発で同じ検討を一からやり直すことになり、試作の意味が半減します。
riplaは、フルスクラッチ受託と伴走型開発の立場から、試作から本開発、本番移行までを同じ体制で支援し、検証で得た学びを断絶させずにつなぎます。試作で何を作り込むべきかという機能の範囲は、前述の関連記事もあわせてご覧ください。
移行の際には、引き継ぎ方と成果物の扱いを決めておきます。
- 要件への引き継ぎ：試作で確定した画面・操作を、本開発の要件にどう引き継ぐか
- 成果物と費用感：試作の成果物（画面データやテスト結果）の納品方法と、同じパートナーに本開発を依頼する場合の概算費用感
まとめ
プロトタイプ開発のRFP・要件定義で核となるのは、検証目的と成功・撤退基準を明文化し、作るものと作らないもの（Won’t）を切り分けることです。そのうえで、ユーザーテストの設計と追加費用・本開発移行の条件まで盛り込みます。本番の要件定義書をそのまま流用すると過剰な要求になるので、試作専用の軽量な要件として整理します。
成功・撤退基準を数値で定めれば検証止まりを避けられ、Won’tを明記すれば試作の肥大化を防げます。また、生成AIやノーコードを活用すれば50〜75%のコスト削減も可能とされますが、それも検証に必要な範囲に絞ることが前提です。
要件定義で大切なのは、試作を「作って終わり」にせず、検証から本開発へつなぐ前提で書くことです。検証目的から逆算して作らないものを決め、本開発への移行と知識の引き継ぎまで取り決めておけば、試作への投資が確実に本開発の品質向上に結びつきます。
riplaは、フルスクラッチ受託と伴走型開発を組み合わせ、RFP設計から試作・本開発・本番移行まで、知識を断絶させずに支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。