発注する側がPoC（Proof of Concept＝概念実証）を外注するとき、最初の関門はRFP（提案依頼書）と要件定義です。検証目的と評価指標、対象外、追加費用、本番移行の条件を先に定めると、結果を本開発の判断につなげられます。
全体像はPoC開発の完全ガイドもご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
検証目的と評価指標の二層構成
PoCのRFPでは、検証目的と評価指標を分けて定義します。検証目的はビジネス上の問いで、評価指標は成立と判断するための具体的な数値です。この二つを分けて書くことが、PoCの要件定義の出発点になります。
ビジネス目的と技術指標の書き分け
評価指標は、ビジネス目的の達成度と技術指標の達成度に分けて定義します。
- ビジネス目的：受注処理の手入力をなくし、業務を効率化できるか
- 技術指標：帳票の文字認識・項目抽出の精度が95%以上か
両層を書き分けておくと、検証の結果を正しく解釈できます。
技術指標を満たしても、ビジネス目的につながらなければ、本開発に進む意味は薄くなります。逆に、ビジネス目的に沿う結果でも技術指標を満たせなければ、同じく本開発の判断は下しにくくなります。
食品卸の事例では、精度95%と、2か月以内の基幹システムとのAPI連携を条件にしました。条件に届かなかったため、約70万円・2週間で撤退しています。
RFPに評価指標を数値で書いておくと、撤退の判断を感情ではなく事実に基づいて下せます。さらに、検証を引き延ばさず冷静に判断するうえでも役立ちます。
プランB（達成できなかった場合）の明文化
発注側は、評価指標に届かなかったときに迷わないよう、PoC終了後の対応をRFPで定めておきます。
- 撤退：検証の終了
- 再検証：別の技術アプローチでの試行
- 条件付きで本開発へ進む：基準を見直したうえでの判断
プランBを決めていないと、「ここまで進めたのだから」と検証を延ばし、PoC死に陥るおそれがあります。
プランBを明文化することは、ベンダーに向けたメッセージにもなります。撤退も選択肢だとRFPに明記しておくと、検証を延ばして売上を伸ばそうとするベンダーを見分けやすくなります。
また、誠実なパートナーは、撤退基準の設計にも協力します。評価指標とプランBをセットで定めておくと、PoCのRFPが判断の軸になります。
成立を確認した技術要素の絞り込みについては、『PoC開発の必要機能・標準機能の一覧について』もご覧ください。
「作らないもの」と追加費用の取り決め
PoCのRFPでは、競合記事で扱いが薄くても、「作らないもの（Won’t）」と追加要望の費用を定めることが欠かせません。
検証する内容と同じくらい、対象外もはっきり決めておく必要があります。決めないままだと、PoCが本開発のミニチュアのように膨らみかねません。
検証スコープと対象外の線引き
検証する範囲と対象外は、RFP上で分けて示します。たとえば帳票読み取りであれば、次のように線引きできます。
- スコープ内：文字認識精度の検証
- スコープ外：本番運用に耐えるUIの作り込み
- スコープ外：複数帳票フォーマットへの対応
MoSCoW法でWon’tに分類した要素をRFPに書き写すと、作らないものの線引きがはっきりします。
この線引きは、見積もりの妥当性を判断するうえでも役立ちます。たとえば範囲が明確であれば、各社の提案を同じ条件で比べられます。
範囲が曖昧だと、ベンダーは安全側に大きく見積もるか、後の追加請求を前提に安く見せることがあります。その結果、適正な比較が難しくなります。さらに、作らないものを明記すると、見積もりの精度も上がります。
追加要望が出た場合の費用ルール
追加要望でPoCの範囲が膨らんでも、費用の扱いで揉めないよう、追加作業のルールをRFPで決めておきます。
- 追加見積もり：スコープ外の要望に見積もりを出す方法
- 概算単価：追加作業の費用を見積もる基準
- 合意プロセス：追加作業を決定する手順
ルールが曖昧だと、想定外の請求が発生したり、ベンダーが赤字を恐れて検証に消極的になったりします。
要件が固まらないまま試行錯誤するPoCでは、成果物を固定する請負契約より、稼働を提供する準委任契約が合うことがあります。
準委任であれば、検証の途中で方向性を調整できます。ただし成果は保証されないため、評価指標とプランBで判断の軸を定めておきます。
契約形態の詳しい判断の軸については、『PoC開発のメリット・デメリット・効果と判断基準について』もご覧ください。
AIプロジェクトと本番移行を見据えた要件
AIのPoCや本番移行を視野に入れる場合は、AI案件に固有の要件をRFPに盛り込んでおく必要があります。AI特有の整理や本番化の障壁を先回りして提案を求めておくことが、PoC後に本番化が否決されるのを防ぐ鍵になります。
機械学習プロジェクトキャンバスによる要件の整理
機械学習プロジェクトキャンバスなどの整理フレームを使うと、AIのPoCに必要な観点を一枚で共有できます。
- 課題とデータ：解決したい課題、利用できるデータ
- 評価と利用：評価指標、想定する利用シーン
- 運用：運用後の保守体制
関係者の認識を揃えるには、データの量や品質も前提として明記しておくことが大切です。AIプロジェクトの成否は、データの質と量に大きく左右されるためです。
評価指標は、ビジネス層と技術層に分けて考えます。精度や再現率が高くても、ビジネス目的に貢献しなければ意味がありません。
両者への対応と、達成できない場合のプランBを整理しておくと、検証結果を本開発の判断に結びつけられます。
ハルシネーションや精度劣化への対応方針も、この段階で要件として整理しておきます。
デプロイ手法・本番移行の提案要求
本番移行を見据えるなら、RFPで本番展開のデプロイ手法を提案するよう求めておきます。リスクを抑える手法には、次のようなものがあります。
- IaC：インフラをコード化し、環境構築を再現する
- カナリアリリース：段階的に切り替える
- ブルーグリーンデプロイ：段階的に切り替える
提案の段階で、本番化までの道筋を描けるベンダーかどうかを見極められます。
本番化で課題になりやすいのは、データ取得の継続性とセキュリティ要件です。また、監査ログや業務適合への対応見込みも、提案事項に含めます。
技術的には作れても、これらの課題で本番化が否決されることがあります。そのため、提案の段階で考え方を確認しておくと、PoC後の移行を見通せるパートナーを選べます。
PoCのチームと本開発のチームが分断される事態を避けるためにも、本番移行まで見通せるベンダーを選ぶ必要があります。
まとめ
PoCのRFPでは、目的と評価指標、合格と撤退の基準を数値で定めます。あわせて、Won’tや追加費用、本番移行に向けた提案要求も盛り込みます。
通常の開発RFPは、機能と納品物を中心に書きます。一方でPoCのRFPは、何を確かめ、何を合格とし、未達のときにどうするかを明らかにするものです。
機械学習プロジェクトキャンバスやデプロイ手法の提案要求は、AI案件や本番移行の検討にも役立ちます。
RFPの質は、PoCから得られる判断材料の質を左右します。まずは自社のテーマで、検証目的と評価指標を分け、プランBとWon’tを明文化しましょう。
riplaは、フルスクラッチ受託と伴走支援を組み合わせ、評価指標の設計から本番移行を見据えた要件整理、本開発、本番化まで一貫して支援しています。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。