外部開発チームや専属開発チームに自社のシステム開発を委ねるとき、その成否を最初に決めるのがRFP（提案依頼書）と要件定義です。とくに「どんなチーム体制で開発を進めてほしいか」という要件は、機能要件以上に見落とされがちで、ここが曖昧なまま発注すると、エース営業が提案に来たのに実際の開発は経験の浅い別チームだった、という体制のギャップに直面します。本記事では、開発チームを外部に求める際のRFP・要件定義書・提案依頼書の書き方を、チーム編成・組成の観点から具体的に解説します。
競合記事の多くは機能要件の書き方に終始し、「どんなチームに、どんな責任体制で任せるか」という体制要件には踏み込みません。しかし発注側がもっとも痛い目を見るのは、機能ではなく体制の認識ずれです。本記事では、隠れた体制要件の引き出し方、外部開発チーム選定RFPに盛り込むべき項目、責任分解（RACI）の契約への落とし込み、そして非IT部門を含むステークホルダーの合意形成まで、要件定義の実務を掘り下げます。なお、開発チーム・開発体制の全体像をまだ把握していない方は、まず開発チームの完全ガイドから読むことをおすすめします。
隠れた要件を引き出すヒアリングとファシリテーション
要件定義の質は、発注側がどれだけ自社の要望を言語化できているかにかかっています。しかし現実には、発注側自身が「本当に必要な要件」を把握できていないことがほとんどです。長年の業務に埋め込まれた暗黙のルールや、部門ごとに異なる期待は、ヒアリングで意図的に引き出さないと表に出てきません。要件定義の最初の仕事は、この「隠れた要件」を掘り起こすことです。
暗黙の業務ルールを引き出すファシリテーション
隠れた要件を引き出すには、単に「何が欲しいですか」と尋ねるだけでは不十分です。現場の担当者は、日々当たり前にやっている作業を「わざわざ言うまでもないこと」と捉え、要件として口に出さないからです。有効なのは、現状の業務フロー（AsIs）を一緒に書き起こしながら、「この作業はなぜ必要なのか」「例外的なケースはあるか」を一つひとつ問い直すファシリテーションです。このプロセスで、契約条件ごとの特例処理や、特定の取引先だけの例外対応といった、暗黙のルールが言語化されていきます。
外部開発チームを活用する場合、このファシリテーションを誰が担うかも要件定義の重要な論点です。発注側に要件をまとめる人材がいない場合、要件定義の段階から伴走できる開発チームを選ぶことが、プロジェクト全体の成否を左右します。職種を横断したモブプログラミングで、企画・設計・開発のメンバーが同じ場で議論し、詳細な仕様書を介さずに認識を合わせる「仕様書レス設計」を実現した一次情報もあります。これは、要件の引き出しと設計を同じチームで一体的に進める一つの形です。要件を引き出す力そのものが、開発チームに求めるべき機能だと言えます。
非IT部門との合意形成とステークホルダー管理
要件定義で見落とされがちなのが、非IT部門との合意形成です。システムを実際に使うのは現場の非IT部門であり、彼らの要件を無視して情報システム部門だけで要件を固めると、リリース後に「現場で使えない」という事態を招きます。一方で、非IT部門は技術用語に不慣れなため、要件のすり合わせでは衝突も起きやすくなります。要件定義のファシリテーターには、技術と業務の双方を翻訳しながら、利害の異なる部門の合意を形成するステークホルダーマネジメントの力が求められます。
合意形成を進めるうえでは、関係者の期待値を早期に揃えることが重要です。「このシステムで何が実現でき、何は実現できないのか」「いつまでに、どこまでを作るのか」を、非IT部門を含む全ステークホルダーが共通理解として持つ。この期待値の調整を怠ると、要件は固まったように見えて、後から「そんなはずではなかった」という不満が噴き出します。要件定義は技術文書を作る作業である以前に、関係者全員の合意を取りつける政治的なプロセスでもあります。誰を巻き込み、誰の合意を取るべきかを設計することが、要件の安定につながります。
外部開発チーム選定RFPに盛り込むべき項目
引き出した要件は、RFP（提案依頼書）という形で発注先候補に提示します。RFPの完成度が、集まる提案の質と、後の認識ずれの少なさを決めます。とくに開発チームを外部に求める場合は、機能要件だけでなく「どんな体制で開発を進めてほしいか」という体制要件を明記することが、提案の比較を可能にします。ここでは、開発チーム選定RFPに必ず盛り込むべき項目を整理します。
体制要件と機能・非機能要件の書き分け
RFPに書く要件は、大きく機能要件・非機能要件・体制要件の三つに整理できます。機能要件は「何ができるか」、非機能要件は性能・セキュリティ・可用性といった「どう動くか」、そして体制要件は「誰が、どんな役割で開発するか」です。多くのRFPは前者二つに偏り、体制要件を書き漏らします。しかし体制要件こそが、開発チームを外部に求める際の核心です。
・アサインされるメンバーの役割（PM・テックリード・エンジニア・QA）と人数
・各メンバーのスキルセットと経験年数の要件
・開発手法（ウォーターフォール／アジャイル／ハイブリッド）の希望
・進捗報告や振り返り（KPTなど）の頻度と形式
これらを明記することで、提案各社が「どんなチームを、どう動かすか」を具体的に示さざるを得なくなり、後述する体制ギャップを未然に防げます。
機能要件を書く際は、すべてを同列に並べるのではなく、必須・優先・将来という優先度をつけることが重要です。予算や納期の制約のなかで、何を最初に作り、何を後回しにするかを発注側が示すことで、提案各社の見積りが現実的になります。優先度のない要件リストは、各社が好き勝手に解釈する余地を残し、見積りの比較を困難にします。要件には必ず重み付けを与え、トレードオフの判断軸を発注側が持っておくことが、RFPの実効性を高めます。チームに備えるべき役割・機能の具体的な一覧については、関連記事『開発チームの必要機能や標準機能の一覧について』もあわせてご覧ください。
曖昧なRFPが招くリスクと見積りの妥当性
曖昧なRFPは、後のトラブルの温床になります。要件が曖昧なまま発注すると、開発が進むなかで「これは要件に含まれていたのか」という解釈の食い違いが生まれ、追加費用をめぐる交渉が泥沼化します。とくに体制要件が曖昧だと、提案時のメンバーと実開発のメンバーが入れ替わる体制ギャップが起きやすくなります。RFPの段階で「提案メンバーが実際にアサインされること」「変更時は事前承認を要すること」を明記しておくことが、この種のリスクへの防衛策になります。
見積りの妥当性を判断する軸として、工期と工数の見積もり根拠を確認することも有効です。たとえばジャステックは、基準工期を「2.7×(人月)の3乗根」という式で算出し、開発環境の変数によって-40〜+40%の補正をかける考え方を示しています。この種の根拠を持つ見積りは、感覚的な数字より信頼性が高いと言えます。見積りを比較する際は、総額の大小だけでなく、その金額がどんな前提とロジックで積み上げられているかを問うことが、妥当性の判断につながります。曖昧なRFPには曖昧な見積りしか返ってこない、という原則を忘れてはいけません。
責任分解（RACI）を契約に落とし込む要件定義
外部開発チームとの協働で最もトラブルになりやすいのが、責任の所在です。「この不具合は誰の責任か」「この追加作業は誰の負担か」という問いに明確に答えられないと、プロジェクトは責任の押し付け合いに陥ります。これを防ぐのが、責任分解を要件定義と契約の両方に落とし込む作業です。RACIマトリクスを契約の付属文書として整備することが、後のグレーゾーンをなくす最も確実な方法です。
準委任・請負の境界とコスト負担の要件化
外部開発チームとの契約形態は、大きく準委任と請負に分かれます。準委任は「労力の提供」に対して対価を払う形で、成果物の完成責任は発注側にあります。一方、請負は「成果物の完成」に責任を負う形です。この違いは、不具合対応や仕様変更が生じたときのコスト負担に直結します。準委任なら追加作業は追加費用、請負なら契約範囲内の不具合修正は受注側の負担、というのが原則です。要件定義の段階で、どのフェーズを準委任、どのフェーズを請負にするかを設計することが、後のコスト負担の明確化につながります。
とくに要件が固まりきらない上流フェーズは準委任、要件が確定した実装フェーズは請負、といった使い分けが現実的です。要件が曖昧な段階で請負契約を結ぶと、受注側は不確実性を見越して見積りを高めに積むか、後の仕様変更で揉めるかのどちらかになります。契約形態とRACIを整合させ、「どのフェーズで、誰が、どこまでの責任を負うか」を要件として明文化する。この一手間が、責任の押し付け合いという最悪の事態を防ぎます。なお、こうした契約・責任の設計を怠った場合に生じる具体的な失敗やリスクについては、要件定義の裏返しとして押さえておく価値があります。
非機能要件と品質基準の要件化
体制要件・機能要件と並んで重要なのが、非機能要件と品質基準の明文化です。性能（応答速度・同時接続数）、セキュリティ（認証・暗号化・脆弱性対策）、可用性（稼働率・障害時の復旧目標）といった非機能要件は、後から追加すると大きな手戻りになるため、要件定義の段階で具体的な数値とともに定める必要があります。「速いシステム」ではなく「ピーク時に何件の同時アクセスを何秒以内で処理する」といった形で、検収の合否を判定できる粒度まで落とし込みます。
品質基準も、要件定義で合意しておくべき項目です。どの程度のテストカバレッジを求めるか、バグ摘出率をどの指標で測るか、検収時にどんな品質を満たしていれば合格とするか。これらを曖昧にすると、検収段階で「品質が不十分だ」「いや要件は満たしている」という水掛け論になります。ソニーがピアレビューで検出率1.92件/時（一般0.29件/時）という品質を実現したように、品質は測定可能な指標で語れます。品質基準を要件として数値で定め、契約に紐づけることが、検収を巡るトラブルを防ぐ最後の砦になります。
まとめ
開発チームを外部に求めるRFP・要件定義を振り返ると、その核心は「機能要件に加えて体制要件をRACIで明文化し、契約形態（準委任／請負）と整合させ、非IT部門を含むステークホルダーの合意を取りつけてから発注する」という一連の設計にあります。隠れた要件はファシリテーションで引き出し、見積りは工期・工数の根拠まで問い、責任分解は契約の付属文書として整備する。これらを丁寧に行うことが、提案メンバーと実開発メンバーが異なる体制ギャップや、責任の押し付け合いを防ぎます。
要件定義は、書類を完成させる作業ではなく、合意とリスク回避を先回りで設計する作業です。とくに「誰が、どんな責任で開発するのか」という体制要件は、競合が見落としがちな最重要ポイントです。riplaはフルスクラッチ受託と国内開発を組み合わせ、外部開発チーム／専属チームとして要件定義の段階から伴走し、体制要件とRACIの明確化を前提にした支援を行います。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。