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