外部開発チームに発注したり、社内に開発体制を立ち上げたりするとき、その成否を最初に左右するのが「要件定義」と、外部に依頼する場合の「RFP（提案依頼書）」です。どんなに優秀なチームを集めても、何を作るか・どんな体制で進めるかという前提が曖昧なままでは、プロジェクトは必ず迷走します。とくに開発体制づくりにおける要件定義は、機能要件だけでなく「誰がどの役割を担い、内製と外注の責任をどう分けるか」という体制の要件まで含めて定義しなければなりません。
本記事は、開発体制のRFP・要件定義書・提案依頼書を、発注企業・推進担当者の視点から実務レベルで掘り下げる解説です。現場に眠る「隠れた要件」を引き出すヒアリングとファシリテーション、外部開発チームを選定するためのRFPの書き方、非IT部門との衝突を解消するステークホルダーマネジメント、そして曖昧なRFPがもたらすリスクまで、競合があまり踏み込まない実務の勘所を具体的に解説します。読み終えるころには、自社が「どんな要件をどう整理し、RFPに落とし込むべきか」の道筋が描けるはずです。なお、開発体制構築の全体像をまだ把握していない方は、まず開発体制開発の完全ガイドから読むことをおすすめします。
隠れた要件を引き出すヒアリングとファシリテーション
要件定義の最大の難所は、新しい機能を考えることではなく、現場が「当たり前すぎて言わないこと」を引き出すことです。長年その業務に携わっている人ほど、自分の暗黙知を要件として語れません。この隠れた要件を表に出せるかどうかが、後の手戻りを大きく左右します。
AsIsからToBeを描くヒアリングの進め方
隠れた要件を引き出す王道は、まず現状（AsIs）の業務フローを徹底的に可視化することです。「普段どう作業していますか」「どこで手が止まりますか」「例外的な処理はどんなときに起きますか」と問いを重ね、実際の業務を細部まで描き出します。とくに「例外処理」にこそ隠れた要件が潜んでいます。通常フローは誰でも語れますが、月末だけの特別処理や、特定の取引先への個別対応といった例外は、聞かれて初めて言語化されることが多いのです。
AsIsを可視化したら、次にあるべき業務の姿（ToBe）を設計します。ここで重要なのは、現状をそのままシステム化するのではなく、無駄や手戻りを取り除いた理想形を描くことです。ToBeを描く過程で「本当はこうしたかった」という潜在的な要望が表に出てきます。AsIsとToBeを行き来しながら要件を磨くこの作業こそ、要件定義の核心です。これを怠ってベンダーに丸投げすると、現場と噛み合わないシステムが完成し、巨額の投資が無駄になるリスクがあります。
ファシリテーションで暗黙知を引き出す技術
要件定義の場は、単なる質問の繰り返しではなく、ファシリテーションの技術が問われる場です。現場の担当者は、専門用語で問われると萎縮し、本音を語らなくなります。ファシリテーターは、業務の言葉に寄り添い、「それはなぜそうしているのですか」と背景を掘り下げる問いを重ねることで、暗黙のルールを表に出していきます。問い詰めるのではなく、現場の知見を尊重しながら言語化を助ける姿勢が、隠れた要件を引き出す鍵です。
近年は、AI時代に要求がより曖昧になる傾向もあります。「とりあえずAIで何かできないか」といった漠然とした期待を、具体的な要件に翻訳する役割が、ファシリテーターにいっそう求められています。この要件の翻訳は、開発体制が提供すべき役割の一つでもあります。役割定義やPdMの機能については『開発体制の必要機能や標準機能の一覧について』もあわせてご覧ください。ファシリテーションによって曖昧な要求を構造化できるかが、要件定義の質を決めます。
機能要件と非機能要件・体制要件を整理する
引き出した要件は、ただ羅列するだけでは使えません。機能要件・非機能要件・体制要件に分類し、それぞれを優先度づけして整理することで、初めてRFPや見積りの土台になります。とくに開発体制の文脈では、「どんな体制で進めるか」という体制要件を明示することが、他の要件定義との大きな違いです。
機能要件を必須・優先・将来で分類する
機能要件は、すべてを同列に扱ってはいけません。「これがないと業務が回らない必須要件」「あると効果が大きい優先要件」「将来的に検討する要件」の三段階に分類することで、開発の優先順位とコストの上限が見えてきます。すべてを必須にすると見積りが膨らみ、予算超過の原因になります。MoSCoW法（Must・Should・Could・Won’t）のような分類で、要件の重み付けを明確にすることが、現実的なプロジェクト計画の前提です。
見落とされがちなのが非機能要件です。性能（どれくらいの負荷に耐えるか）、セキュリティ（どんな脅威に備えるか）、可用性（どれくらい止まらないか）といった要件は、機能のように目に見えないため後回しにされがちです。しかし、これらを要件段階で定義しておかないと、リリース後に「想定したアクセスに耐えられない」「セキュリティ要件を満たしていない」といった重大な問題が噴出します。非機能要件こそ、要件定義書に明確に書き込むべき項目です。
求める開発体制そのものを要件化する
開発体制の要件定義に特有なのが、「どんな体制で進めてほしいか」を要件として明記することです。たとえば、専任のPMを置いてほしいのか、QAは内製と外注のどちらが担うのか、コミュニケーションは週次の定例で十分か日次が必要か、といった体制への要求です。これを明示しないと、外部開発チームの提案は「人数と単価」だけの比較になり、体制の質を評価できません。求める役割構成と責任分担を要件化することが、適切なパートナー選定の前提になります。
体制要件には、内製と外注の責任分担も含まれます。RACIの考え方を要件に落とし込み、どの判断は自社が下し、どこから外部に委ねるかを明文化する。これを契約形態（準委任か請負か）と結びつけて整理することで、後の責任分解のグレーゾーンを未然に防げます。体制要件の明確化は、機能要件の整理と同じくらい、いやそれ以上に、プロジェクトの安定性を左右する重要な作業です。曖昧なまま走らせると、トラブル発生時に責任の押し付け合いが起きます。
外部開発チームを選定するRFPの書き方
整理した要件を、外部開発チームへの依頼書として形にするのがRFP（提案依頼書）です。RFPの質は、集まる提案の質を直接決めます。曖昧なRFPには曖昧な提案しか集まらず、各社を比較する軸も定まりません。発注側が主導権を握り、評価できるRFPを書くことが、よいパートナーと出会う第一歩です。
RFPに必ず盛り込むべき項目
RFPに最低限盛り込むべき項目は、次のように整理できます。
・プロジェクトの背景と目的：なぜこの開発を行うのか、達成したいビジネス成果は何か
・機能要件と非機能要件：必須・優先・将来に分類した要件と、性能・セキュリティの基準
・求める開発体制：希望する役割構成、コミュニケーション頻度、内製との責任分担
・契約形態と前提：準委任か請負か、検収基準、保守の範囲
・スケジュールと予算感：希望する納期と、概算の予算レンジ
・評価基準：何を重視して提案を評価するか
とくに「求める開発体制」と「評価基準」を明記することが、体制の質で各社を比較するための要になります。
RFPは、すべてを発注側が決めて押し付けるものではありません。提案の自由度を適度に残すことで、各社の知見やノウハウを引き出せます。「課題は明示するが、解決策は提案を求める」という書き方をすると、ベンダーの本当の実力が見えてきます。要件を固めすぎず、かといって曖昧にもしすぎないバランスが、よいRFPの条件です。背景と目的を丁寧に伝えれば、優れたパートナーはこちらが気づかなかった提案も返してくれます。
見積りの妥当性を判断する軸
RFPに対して集まった見積りを、どう評価すればよいでしょうか。安いから良い、高いから悪いという単純な判断は危険です。見積りの妥当性を判断する一つの参考として、システム開発の工期と工数には経験則があります。たとえばジャステックは、基準工期を「2.7×(人月)の3乗根」と定式化し、環境変数によってマイナス40%からプラス40%まで補正するモデルを公表しています（出典：ジャステック）。こうした客観的な目安と照らせば、提示された工期や工数が現実的かを判断できます。
見積りを評価するうえで、極端に安い提案には注意が必要です。連携や移行といった工程を見積りから削って安く見せ、後から追加費用を請求するケースがあるためです。見積りは総額だけでなく、内訳の妥当性を確認することが大切です。また、提案各社の財務的な安定性も見ておくとよいでしょう。たとえばジャステックは売上高経常利益率17.5%という高い水準を公表しており（出典：ジャステック）、こうした指標は事業の持続性の参考になります。見積りの安さに飛びつかず、内訳と提案の中身で妥当性を判断することが、後の追加費用トラブルを防ぎます。
非IT部門との合意形成とステークホルダーマネジメント
要件定義は、技術部門だけで完結するものではありません。実際に業務を行う非IT部門、予算を握る経営層、現場の管理職など、多様なステークホルダーの合意がなければ、要件は途中でひっくり返ります。要件定義の成否は、このステークホルダーマネジメントの巧拙にかかっていると言っても過言ではありません。
非IT部門との衝突を解消する進め方
非IT部門と技術部門は、しばしば衝突します。現場は「今のやり方を変えたくない」と抵抗し、技術側は「理想的な仕組みにしたい」と主張する。この対立を放置すると、要件はまとまらず、たとえ完成しても現場が使わないシステムになります。衝突を解消する鍵は、技術の言葉で説得するのではなく、現場の業務がどう楽になるかという「相手の利益」で語ることです。要件定義の場を、対立の場ではなく、共に課題を解決する協働の場へと転換するファシリテーションが求められます。
有効なのは、現場のキーパーソンを早い段階で要件定義に巻き込むことです。決まったものを後から説明するのではなく、要件を作る過程に参加してもらうことで、「自分たちが作った仕組み」という当事者意識が生まれます。この当事者意識が、後の導入時の抵抗を大きく減らします。非IT部門との合意形成は、説得のテクニックではなく、巻き込みのプロセス設計だと捉えるべきです。早期から現場を巻き込むほど、要件は現実に即したものになります。
経営層へROIで投資判断を説明する
経営層を要件定義の合意に巻き込むには、技術的な詳細ではなく、投資対効果（ROI）の言葉で語る必要があります。この開発体制への投資が、どれだけのコスト削減や売上向上につながるのか。IRR（内部収益率）やROI、顧客獲得コストであるCACといった経営指標に翻訳して提示することで、経営層は投資判断を下せるようになります。要件定義書に「この投資で何が得られるか」を明示することは、稟議を通すための必須条件です。
経営層への説明では、定量的な効果だけでなく、投資しなかった場合のリスクも併せて示すと説得力が増します。曖昧なRFPで発注して炎上した場合の損失、要件定義を怠って手戻りが発生した場合のコスト増を具体的に示すことで、要件定義に十分な時間と予算をかけることの正当性が伝わります。経営層へのROI説明は、要件定義というプロセスそのものへの投資を正当化する役割も担っています。投資の意義とリスクの両面を提示することが、合意形成の近道です。
まとめ
開発体制の要件定義とRFP作成を振り返ると、その本質は「現場の隠れた要件をファシリテーションで引き出し、機能・非機能・体制の各要件を分類して整理し、求める体制と責任分担までRFPに明文化し、非IT部門と経営層の合意を取りつける」という一連のプロセスにあります。AsIsの例外処理にこそ隠れた要件が潜み、見積りは工期工数の経験則と内訳で妥当性を判断し、ステークホルダーは早期の巻き込みと経営層へのROI説明で合意を形成します。曖昧なRFPは見積り比較を不可能にし、責任分解のグレーゾーンを生んで炎上の火種になります。
要件定義は、開発の前段階の事務作業ではなく、プロジェクトの成否を決める最重要工程です。隠れた要件の発掘と体制の要件化という二つを外さず、現場と経営の双方を巻き込みながら、主導権を握って進めてください。riplaはフルスクラッチ受託と外部開発チーム・専属チームの提供を通じて、現場ヒアリングからRFP作成、ベンダーとの協働による要件の磨き込みまでを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。