LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

要件定義の外注とは何か：上流工程を単独で委託する意味

要件定義の外注とは、システム・アプリ開発プロジェクトの最上流にあたる「何を作るかを決める工程」を、社外の専門家に委託することです。設計・実装・テストといった後続フェーズを発注せず、要件定義の工程だけをスコープとして契約するケースを指します。

要件定義を単独で外注する背景には、「社内に要件をまとめられる人材がいない」「前回の開発で仕様の曖昧さからやり直しが生じた」「中立な立場で業務要件を整理したい」といった課題があります。

IPA（独立行政法人情報処理推進機構）は、ソフトウェア開発分析データ集2022において、5,546件のプロジェクトデータを集計・公開しています^*1。同レポートは、信頼性・生産性の両面が低下傾向にあると報告しており、上流工程での品質確保が後続コストを左右することを示唆しています。

要件定義で行う3つの作業：業務要件・機能要件・非機能要件

要件定義の外注を検討するうえで、まず「要件定義工程で何を決めるか」を把握しておく必要があります。主な作業は業務要件の整理・機能要件の特定・非機能要件の定義の3領域に分かれます。

業務要件の整理：「なぜ作るか」「誰が使うか」を言語化する

業務要件とは、システムが解決すべき業務課題と、達成すべきビジネス目標を定義したものです。「受注処理を現在の3時間から1時間以内に短縮したい」「営業担当が外出先からリアルタイムで在庫を確認できるようにしたい」といった、業務視点の目的を明確にします。

この作業は発注側の業務知識が前提になるため、外注先の担当者がヒアリングを重ねてドキュメント化するプロセスが中心になります。ヒアリング対象が多部門にわたる場合、外注側のファシリテーション能力がアウトプット品質を左右します。

機能要件の特定：システムが「何をするか」を列挙する

機能要件とは、システムが提供すべき個々の機能を具体的に列挙したものです。ログイン認証・マスタ管理・帳票出力・外部API連携など、画面単位・機能単位で洗い出します。

要件定義の外注先は、業務要件のヒアリング結果をもとに機能の候補を提示し、優先度付け（MoSCoW法など）を支援します。この段階で機能スコープを確定しないまま開発に進むと、後工程での仕様変更・追加の原因になります。

非機能要件の定義：性能・セキュリティ・可用性などの品質条件

非機能要件とは、システムの動作品質に関する条件です。応答速度・同時接続数・データ保存期間・可用性（稼働率の目標値）・セキュリティ要件（認証方式・暗号化・アクセス制御）などが含まれます。

非機能要件は「特に指定がなければ後回し」になりがちですが、クラウドインフラの選定や開発コストに直結するため、要件定義段階で大枠を決めておくことが大切です。

成果物の構成：要件定義書・RFP・画面設計入口まで

要件定義外注の成果物は、次工程（基本設計・開発）に引き渡すドキュメント群です。契約スコープによって内容は異なりますが、代表的なものを以下に整理します。

契約スコープが「要件定義書＋RFP作成まで」か「画面一覧・業務フロー図も含む」かによって、費用・期間が変わります。外注を依頼する前に、「次の工程（基本設計）を誰が担うか」を念頭に、どこまで成果物が必要かを明確にしておくことが大切です。

外注するメリット：客観性・専門性・工数削減の3点

要件定義を外注する主なメリットは、客観性の確保・専門技術力の活用・社内工数の削減の3点に整理できます。

メリット1：中立な第三者が業務課題を可視化できる

社内メンバーだけで要件定義を行うと、部門間の利害関係や「これまでのやり方」への固執が影響し、課題が見えにくくなる場合があります。外部の担当者は既存業務に縛られず、ユーザーや業務プロセスを客観的に評価できます。

特に複数部門が利用するシステムでは、調整・合意形成のファシリテーションを外注先が担うことで、社内の政治的調整コストを軽減できます。

メリット2：IT・業務双方の専門知識を即時に活用できる

要件定義には、業務分析の視点とITシステムの実現性評価の両方が求められます。社内に兼ね備えた人材がいない場合、外注先のコンサルタント・上級SEに任せることで、要件の実現可能性チェックと費用対効果の試算を同時に進められます。

メリット3：後続工程のやり直しリスクを低減できる

要件の曖昧さを解消しないまま開発に進むと、実装フェーズでの仕様変更・追加が頻発し、開発コストが膨らむリスクがあります。外注による精度の高い要件定義は、設計・開発・テスト各フェーズの手戻りを抑える効果が期待できます。

外注の注意点：情報共有コスト・ベンダー依存・契約形態

要件定義の外注にはリスクも伴います。事前に把握しておくべき注意点を3点整理します。

注意点1：自社業務の深いヒアリングに時間がかかる

外注先は自社業務を知らない状態からスタートします。ヒアリング・ドキュメント確認・関係者調整に、発注側も相応の時間と人的リソースを提供する必要があります。「丸投げすれば完結する」ではなく、「社内の窓口担当者が主体的に関与する」前提で体制を組むことが大切です。

注意点2：開発工程と同一会社に依頼すると利益相反が生じやすい

要件定義と後続の開発を同一ベンダーに依頼する場合、ベンダーが開発受注を意識して要件を広く・複雑に設定するインセンティブが働く場合があります。機能要件の肥大化や非機能要件の過剰な仕様設定が、開発費用の増大につながるリスクがあります。

この点を懸念する場合は、要件定義フェーズのみ中立なコンサルタント会社に依頼し、その成果物（要件定義書・RFP）をもとに開発会社を競争見積もりする「分離発注」が選択肢になります。

注意点3：準委任契約と請負契約では責任範囲が異なる

要件定義の外注には「準委任契約（民法第656条）」が使われるケースが多くあります。準委任契約では、成果物の完成を保証する義務はなく、善管注意義務のもとで作業を遂行することが契約内容になります。

一方、成果物（要件定義書の納品）に品質基準を設けたい場合は、請負契約にすることもできます。どちらの形態で契約するかにより、修正対応・追加ヒアリングの費用負担の線引きが変わります。契約前に「成果物の検収基準」「追加作業の費用精算ルール」を明文化しておきましょう。

費用の考え方：人月単価・工期・規模感の目安

要件定義外注の費用は、「人月単価 × 工数（人月）」を基本として算出されます。以下は市場参考値であり、一次資料ではありません。実際の費用はプロジェクト規模・依頼先の体制・スコープによって大きく異なります。

人月単価の参考レンジ

要件定義フェーズを担当するコンサルタント・上級SE（シニアエンジニア）の人月単価は、担当者の経験・専門性・会社規模によって異なります。発注ラウンジ等の業界情報では、エンジニア・コンサルタントの人月単価は経験・スキルに応じて幅があると報告されています^*2。

要件定義は上流工程のため、一般的な実装エンジニアより経験値の高い担当者が関与することが多く、その分だけ単価が高くなる傾向があります。費用を事前に概算したい場合は、複数社に見積もりを依頼し比較することを推奨します。

工数（期間）の目安：規模によって変わる

要件定義の期間は、対象システムの規模・複数部門の関与度合い・既存システムの有無によって変わります。以下は規模感の目安です（市場参考値・プロジェクトによって大きく異なります）。

上記はあくまで目安です。「どこまでを要件定義スコープとするか（RFPや画面遷移図まで含めるか）」によって期間・費用は変わります。初回見積もりの段階でスコープを明確にして依頼することが、費用の透明性確保につながります。

費用を左右する要因：スコープ・体制・前提条件の整備

要件定義外注の費用を大きく左右する要因は次の3つです。

• スコープの広さ：RFP作成まで含むか、業務フロー図・画面一覧まで含むか
• ヒアリング対象の人数・部門数：関係者が多いほどヒアリング・合意形成コストが増加します
• 発注側の事前準備：業務課題や現行フローが整理されているほど、外注側の調査工数を削減できます

開発会社と同一か分離発注か：判断基準と選び方

「要件定義から開発まで1社に一括依頼するか、要件定義は別会社に依頼するか」は、多くの企業担当者が直面する判断です。それぞれのメリット・デメリットを整理します。

一括発注が向いているケース

開発したいシステムのスコープが明確で、過去に取引実績のある信頼できる開発会社が存在する場合は、一括発注の管理シンプルさが利点になります。スタートアップや小規模プロジェクトで、スピードを優先したい場合も一括発注が選ばれやすいです。

分離発注が向いているケース

「今後も定期的にシステム発注を行う」「複数ベンダーに見積もりを取って費用を比較したい」「特定ベンダーに依存したくない」という場合は、分離発注が有効です。大規模なシステム刷新や、基幹業務に関わるシステムでは、中立性の高い要件定義書がベンダー選定の精度を高めます。

元請（プライムベンダー）への依頼：責任ラインを明確にする

要件定義から開発・運用まで一気通貫で依頼したい場合、元請（プライムベンダー）に一括委託するモデルがあります。元請は下請け管理・品質管理・進捗管理を含めて責任を持つため、発注側の管理負荷を低く保ちながら、高品質なアウトプットを期待できます。

ただし、元請への一括発注では「要件定義書の妥当性を発注側が確認できるか」が重要になります。第三者レビュー（発注側のSME＝Subject Matter Expert、または外部コンサルタント）を活用して、成果物の品質を担保する体制を整えておくことが大切です。

進め方の実務：依頼前準備から成果物受け取りまで

要件定義外注を成功させるための実務ステップを整理します。

ステップ1：依頼前に「課題と目標」を言語化する

外注先に渡す前提情報として、「現在の業務課題」「システム化で達成したい目標（KPI）」「利用ユーザー」「予算感・スケジュール希望」を社内でまとめておきましょう。この事前整理が不十分だと、ヒアリングが発散し工数・費用が増加します。

ステップ2：外注先の選定基準を明確にする

要件定義を担当する会社・担当者に求めるスキルセットは、業務分析力・ファシリテーション力・IT実現性評価力の3つです。提案依頼の段階で「類似業種・規模での要件定義実績」を確認し、担当者のプロフィール（経験年数・担当業種）を提案書に含めてもらうと選定精度が上がります。

ステップ3：キックオフで「スコープ・成果物・合意形成ルール」を確認する

契約締結後のキックオフで、成果物の定義（要件定義書の目次・フォーマット）・意思決定者・エスカレーションルートを確認します。「仕様確定の権限を持つ社内担当者が誰か」を外注先に伝えることで、ヒアリング段階での手戻りを防げます。

ステップ4：中間レビューで方向性のずれを早期発見する

要件定義の中間成果物（業務フロー図・機能要件一覧）の段階でレビューを実施することを推奨します。最終納品まで待つとやり直しコストが大きくなります。週次や隔週のレビュー会議をスケジュールに組み込み、方向性のずれを早期に修正できる体制が大切です。

ステップ5：成果物の検収基準を事前に決めておく

要件定義書の検収は「要件の網羅性」「業務フローとの整合性」「次工程（基本設計）への引き継ぎ可能性」を確認する作業です。検収基準を契約前に合意しておくことで、納品後のトラブルを防げます。

まとめ：要件定義外注の3つの判断軸

本稿では、要件定義を単独で外注する際の「何を依頼するか」「費用をどう考えるか」「誰に依頼するか」を整理しました。要点を3点に集約します。

第一に、要件定義外注の核心は「業務要件・機能要件・非機能要件を精度高く文書化し、次の開発工程の手戻りを防ぐこと」です。成果物として要件定義書・RFP・業務フロー図・画面遷移概要などを確認してから依頼先を選定しましょう。

第二に、費用は「人月単価 × 工数」が基本ですが、スコープ（RFPや画面一覧まで含めるか）・関係者の人数・事前準備の質によって大きく変わります。複数社に見積もりを依頼し、スコープを揃えたうえで比較することを推奨します。

第三に、発注形態（一括か分離か）の選択は「ベンダーの中立性」と「引き継ぎコスト」のトレードオフです。大規模システムや複数ベンダー比較を予定している場合は分離発注、スピードと一貫性を重視する場合は一括発注が選ばれやすいです。

よくある質問

要件定義だけを外注することは一般的ですか？

要件定義のみを単独で外注する形態は、大規模なシステム刷新や基幹業務システムの構築では選択されるケースがあります。特に「中立な立場でRFPを整備したい」「複数ベンダーに競争見積もりを取りたい」という場合に有効です。一方、小規模プロジェクトでは要件定義から開発まで一括で依頼するケースが多く、分離発注が向いているかはプロジェクト規模と目的によって変わります。

要件定義の外注先はどのように選べばよいですか？

選定で確認すべきポイントは3点です。まず、自社と同じ業種・規模のシステム開発における要件定義の実績があるかを確認しましょう。次に、担当者の経験（コンサルタント・上級SEとしての実績年数）を提案時に開示してもらいましょう。最後に、成果物のサンプル（要件定義書・業務フロー図の過去事例）を提示できるかを確認することで、アウトプット品質の目安になります。

要件定義を外注するときの契約形態は準委任と請負のどちらがよいですか？

要件定義外注では準委任契約が多く使われます。準委任契約は成果物の完成を保証しない代わりに、柔軟に作業範囲を調整できる点が特徴です。一方、「要件定義書の納品と検収」を明確にしたい場合は、成果物の完成を義務づける請負契約も選択肢になります。どちらが適しているかは、プロジェクトの不確実性（要件の曖昧さの程度）と、発注側の管理能力を踏まえて判断することを推奨します。

要件定義書だけ作ってもらえば、あとは別の会社に開発を頼めますか？

要件定義書の完成度が高ければ、別の開発会社に引き継いで開発を依頼することは可能です。ただし、引き継ぎには「要件定義書のフォーマット・詳細度が開発会社の要件と合っているか」の確認が必要です。開発会社によっては独自の仕様書フォーマットを持つため、要件定義外注の段階で「最終的に依頼する開発会社が読めるドキュメントを作成する」というゴールを外注先と共有しておくことが大切です。

要件定義を外注すると、社内にノウハウが蓄積されませんか？

外注だけに依存すると、業務分析や要件整理のノウハウが社内に残りにくいという指摘は正当です。この課題に対しては、外注先の作業に社内担当者が積極的に参加してノウハウ移転を図るか、初回プロジェクトを外注しながら社内メンバーが学習する「OJT型の伴走支援」を契約内容に含めることが有効です。長期的に内製化を目指す場合は、外注先とのナレッジ移転計画を最初から設計に組み込むことを推奨します。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（2022年）
2. *2　出典：発注ナビ（hnavi.co.jp）「人月単価とは？大まかな相場と構成要素についても解説」（参考情報・一次公的資料ではありません）