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