外部の開発チームにシステム開発を任せるなら、RFPと要件定義には、機能要件に加えて開発体制の要件を明記することが大切です。
体制の要件は見落とされやすく、競合記事の多くは機能要件に終始し、体制要件には踏み込みません。曖昧だと、提案時と実開発のチームが違うといった食い違いが起きます。全体像は開発チームの完全ガイドで確認できます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
隠れた要件を引き出すヒアリングとファシリテーション
要件定義の質は、発注側が自社の要望をどれだけ言葉にできるかで決まります。ところが実際には、本当に必要な要件を発注側自身が把握できていないことがほとんどです。長年の業務に埋め込まれた暗黙のルールや、部門ごとに違う期待は、ヒアリングで意図して引き出さなければ表に出てきません。だからこそ、要件定義の最初の仕事は、この「隠れた要件」を掘り起こすことになります。
暗黙の業務ルールを引き出すファシリテーション
現場の担当者は、日々当たり前にやっている作業を「わざわざ言うまでもないこと」と捉え、要件として口に出さないことが多いものです。そのため、隠れた要件を引き出すには、次の順に進めるのが有効です。
- 現行業務の把握：現状の業務フロー（AsIs）を一緒に書き起こす。
- 例外と目的：「この作業はなぜ必要か」「例外的なケースはあるか」を一つひとつ問い直す。
暗黙のルールは、契約条件ごとの特例処理や、特定の取引先だけの例外対応といった形で言語化されていきます。
外部開発チームを活用するなら、このファシリテーションを誰が担うかも要件定義の大事な論点になります。発注側に要件をまとめる人がいない場合は、要件定義の段階から伴走できる開発チームを選ぶことが、プロジェクト全体の成否を左右します。
一次情報では、職種を横断したモブプログラミングで、企画・設計・開発のメンバーが同じ場で議論し、詳細な仕様書を介さずに認識を合わせる「仕様書レス設計」を実現した例が示されています。こうした進め方は、要件の引き出しと設計を同じチームで一体的に進める一つの形です。要件を引き出す力も、開発チームに求めるべき機能のひとつだといえます。
非IT部門との合意形成とステークホルダー管理
要件定義で見落とされがちなのが、非IT部門との合意形成です。システムを実際に使うのは現場の非IT部門であるため、彼らの要件を無視して情報システム部門だけで固めると、リリース後に「現場で使えない」という事態を招きかねません。さらに、非IT部門は技術用語に慣れていないため、要件のすり合わせでは衝突も起きやすくなります。
このため、要件定義のファシリテーターには、技術と業務の双方を翻訳しながら、利害の異なる部門の合意を形成するステークホルダーマネジメントの力が求められます。
合意形成を進めるには、関係者の期待値を早い段階で揃えることが欠かせません。非IT部門を含む全ステークホルダーには、このシステムの範囲と期限について同じ理解を持ってもらう必要があります。
- 実現範囲：このシステムで何が実現でき、何は実現できないのか。
- 期限と範囲：いつまでに、どこまでを作るのか。
この調整を怠ると、要件は固まったように見えて、後から「そんなはずではなかった」という不満が噴き出します。要件定義は、技術文書を作る作業であるだけでなく、関係者全員の合意を取りつける政治的なプロセスでもあります。そこで、誰を巻き込み、誰の合意を取るべきかを設計することが、要件の安定につながります。
外部開発チーム選定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の明確化を前提にした支援を行います。全体像を改めて確認したいときは、完全ガイドをご活用ください。
▼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を創業。