# 要件定義の費用相場｜外注範囲と依頼方法 - 公開日: 2026-09-23 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/public/column/requirements-definition-outsourcing-cost 要件定義（＝作るものと満たす条件を決める工程）を外注する費用は、一般に小規模で50万〜150万円、中規模で150万〜500万円、大規模で500万〜1,500万円以上が目安です。開発費とは別に予算化し、成果物・対象業務・意思決定者・完了条件をそろえて見積もりを比較することが、手戻りを防ぐ要点です。 要件定義は、単に欲しい機能を一覧にする工程ではありません。システムを導入する目的、利用者、業務ルール、外部サービスとの連携、セキュリティ、運用方法、受け入れ条件まで整理し、開発会社が設計と見積もりを行える状態にする工程です。 一方で、要件定義の費用や成果物には共通の定価がありません。同じ「要件定義一式」という見積もりでも、数回のヒアリングだけで終わる場合と、現場調査や画面試作まで含む場合では内容が大きく異なります。本記事では、システム開発の発注者が要件定義を外注するときの費用相場、期間、準備、見積もりの見方を解説します。 ## 要件定義を外注する費用相場と期間 要件定義の費用は、対象業務の数、関係者数、システム連携、既存資料の整備状況によって決まります。一般的な目安は、50万〜500万円程度が中心ですが、大規模な基幹システムや複数部門を横断する案件では1,000万円を超えることもあります。 以下は、要件定義のみを外注する場合の一般的な目安です。金額は税別を想定した概算であり、開発、デザインの完成、データ移行作業、システム利用料などは含みません。 |規模|費用相場|期間の目安|案件の例| |---|---:|---:|---| |小規模|50万〜150万円|2〜6週間|単一部門で使う業務ツール、小規模Webサービス、既存業務の一部電子化| |中規模|150万〜500万円|1.5〜3か月|複数権限を持つ業務システム、外部サービスと連携するWebサービス、スマホアプリ| |大規模|500万〜1,500万円以上|3〜6か月以上|複数部門を横断する基幹システム、多数の外部連携やデータ移行を伴うシステム| 小規模でも、既存システムの仕様が不明、関係者の意見が分かれている、法令や業界固有のルールが多いといった条件があれば、調査期間と費用は増えます。反対に、業務フローや機能の優先順位が社内で整理されていれば、ヒアリングと文書化に必要な工数を抑えやすくなります。 ### 費用は担当者の工数から算出される 要件定義の見積もりは、一般に担当者の人月単価または人日単価と、必要な工数を掛けて算出されます。人月とは、1人が1か月稼働する作業量の単位です。 要件定義には、主に次の担当者が関わります。 - プロジェクトマネージャー：進行、課題、予算、関係者を管理する担当者 - ビジネスアナリスト：現行業務を調査し、改善後の業務と要件を整理する担当者 - システム担当者：実現方法、外部連携、データ、セキュリティなどを検討する担当者 - UI・UXデザイナー：画面構成や利用者の操作手順を整理する担当者 すべての案件に4職種が専任で必要になるわけではありません。小規模案件では1〜2人が複数の役割を兼ねることもあります。重要なのは担当者数の多さではなく、見積もりの工数がどの作業に使われるかを確認することです。 ### 費用を大きく左右する条件 特に影響が大きいのは、次の条件です。 - 対象となる部署、拠点、利用者区分の数 - ヒアリング対象者と会議回数 - 現行業務の複雑さと例外処理の数 - 既存システム、会計ソフト、決済、APIなどとの連携数 - 移行するデータの種類、量、品質 - 画面構成や試作品を作る範囲 - セキュリティ、性能、可用性などの非機能要件 - 未決事項を社内で決定するまでの時間 - 要件定義後に、開発会社の選定支援まで依頼するか 発注のご相談を受ける開発会社の立場では、機能数よりも「例外的な業務ルール」と「関係者間の合意形成」に時間がかかるケースが少なくありません。たとえば、承認機能が一つでも、金額、部署、役職、申請内容によって承認経路が変わる場合は、多数の条件を整理する必要があります。 ## 要件定義の外注範囲と必要な成果物 要件定義を外注するときは、「要件定義書一式」ではなく、作成してもらう成果物を具体的に決めることが重要です。成果物が曖昧なままでは、発注者が期待する内容と、外注先が想定する作業に差が生まれます。 ### 主な作業と成果物 |作業範囲|主な成果物|確認するポイント| |---|---|---| |目的・課題の整理|企画概要、目的、成功条件|システム導入自体が目的になっていないか| |現行業務の調査|現行業務フロー、課題一覧|例外処理や手作業まで確認されているか| |導入後の業務設計|新業務フロー、役割分担|誰がいつ何を操作するか明確か| |機能要件の整理|機能一覧、権限一覧、業務ルール|対象範囲と対象外が区別されているか| |画面・操作の整理|画面一覧、画面遷移図、ワイヤーフレーム|主要な操作を関係者が確認できるか| |データ要件の整理|データ項目一覧、移行対象一覧|保存期間、入力元、移行元が明確か| |外部連携の整理|連携一覧、連携方式、データの流れ|連携先の契約や仕様を確認しているか| |非機能要件の整理|性能、セキュリティ、バックアップなどの条件|数値または判断できる条件になっているか| |運用要件の整理|運用体制、障害対応、問い合わせ対応|公開後に誰が担当するか明確か| |受け入れ条件の整理|受入基準、主要なテスト観点|完成を何によって判断するか明確か| ワイヤーフレームとは、画面に何を配置するかを示す簡易的な設計図です。完成デザインとは異なり、色や装飾よりも、情報、ボタン、入力項目、画面間の移動を確認するために使います。 すべての成果物を同じ細かさで作る必要はありません。たとえば、社内向けの小規模ツールなら、企画概要、業務フロー、機能一覧、主要画面、権限、受入条件を中心にまとめる方法もあります。重要なのは、後続の開発会社が大きな推測をせずに設計と見積もりを進められることです。 ### 発注者と外注先の役割を分ける 要件定義を外注しても、業務上の判断まで外注先へ委ねることはできません。役割分担は次のように考えると整理しやすくなります。 |発注者が決めること|外注先に依頼できること| |---|---| |導入目的と優先順位|目的と課題の整理、文書化| |予算と希望時期|現実的な進行計画の提案| |業務ルールの採否|現行業務のヒアリングと課題分析| |対象部署と責任者|会議の進行、論点と宿題の管理| |必須機能と将来機能|機能の整理、実現性の検討| |許容できるリスク|セキュリティや運用上の選択肢の提示| |要件の最終承認|成果物の作成、修正、引き継ぎ| 外注先が「どちらの運用が正しいか」を一方的に決めるのではなく、選択肢ごとの費用、利点、制約を示し、発注者が判断できる状態を作るのが望ましい支援です。 ### 要件定義の完了条件も決める 成果物の名前だけでなく、要件定義をいつ完了とするかも合意しておきます。完了条件の例は次のとおりです。 - 契約で定めた成果物がすべて提出されている - 対象範囲と対象外が明記されている - 未決事項が一覧化され、担当者と決定期限が設定されている - 主要な業務責任者が内容を確認している - 開発見積もりに必要な前提条件が記載されている - 成果物の修正回数と承認方法が決まっている - 後続の開発会社へ説明できる資料になっている 受け入れ条件を要件定義の段階で整理しておくと、開発完了時の認識違いも減らせます。納品時の確認方法は、[システム開発の検収方法｜受入テストと注意点](https://www.geek-bridge.com/column/system-development-acceptance-testing)でも詳しく解説しています。 ## 要件定義を外注する前の準備と進め方 要件定義を効率よく進めるには、完璧な資料を作るよりも、目的、現状、関係者、制約を外注先へ正確に共有することが大切です。準備不足のまま始めると、外注先が情報を集める時間が増え、重要な判断が後回しになります。 ### 依頼前に準備するもの 最低限、次の情報を用意します。未決定の項目は、無理に決めず「未定」と明記して構いません。 - システムを導入・変更したい背景 - 解決したい業務上の課題 - 想定する利用者と利用人数 - 対象となる部署、拠点、取引先 - 現在の業務手順と使用中のツール - 必要だと考えている機能 - 既存システムや外部サービスとの連携候補 - 移行したいデータの種類と保存場所 - 希望する開始時期、公開時期 - 要件定義と開発に使える予算の目安 - 社内の責任者、実務担当者、承認者 - セキュリティや法令上の制約 初回相談で何を伝えればよいか迷う場合は、[システム開発ヒアリングシート｜依頼前の作り方](https://www.geek-bridge.com/column/system-development-hearing-sheet)を使って情報を整理すると、相談先による説明内容の差を抑えられます。 ### 要件定義を進める6ステップ #### 1. 目的と成功条件を決める 最初に「何を作るか」ではなく、「何を改善したいか」を確認します。たとえば、入力時間を短縮する、二重入力をなくす、問い合わせ状況を把握するなど、導入後に確認できる状態へ落とし込みます。 売上増加のようにシステムだけでは達成できない目標を設定する場合は、利用率、処理時間、継続率など、システムに近い指標も併記します。 #### 2. 対象範囲と対象外を決める 対象業務、利用者、部署、端末、外部連携を整理します。今回対応しない業務も明記してください。対象外が決まっていないと、ヒアリングのたびに要望が増え、費用と期間を確定しにくくなります。 #### 3. 現行業務を調査する 資料だけでなく、実務担当者へのヒアリングを行います。通常の流れに加え、キャンセル、差し戻し、重複、締め後の修正などの例外処理を確認することが重要です。 現場担当者だけでなく、管理者、経理、情報システム、顧客対応など、前後の工程に関わる人の意見も確認します。ただし、参加者を増やしすぎると意思決定が遅れるため、意見を出す人と最終決定者を分けておきます。 #### 4. 導入後の業務と要件を整理する 現行業務をそのままシステム化するのではなく、不要な作業、重複入力、過剰な承認を見直します。そのうえで、必要な機能、権限、データ、画面、連携、運用条件を整理します。 この段階では、要望をすべて同じ優先度にしないことが重要です。少なくとも次の3段階に分けます。 - 必須：初回公開時にないと業務やサービスが成立しない - 重要：効果は高いが、代替手段または後日追加が可能 - 将来：利用状況を確認してから追加を判断する #### 5. 画面や試作品で確認する 文章だけでは、発注者と開発会社が異なる画面を想像することがあります。主要な画面については、ワイヤーフレームやクリック可能な簡易試作品を作り、利用者の操作順を確認します。 ただし、要件定義段階で全画面の完成デザインまで作ると、業務要件の変更によって作り直しが発生します。まずは頻繁に使う画面、複雑な入力画面、承認画面などを優先します。 #### 6. レビューして承認する 最終資料は、経営責任者だけでなく、実務担当者、管理者、情報システム担当者など、関係する立場から確認します。レビューでは、単に「問題ありません」と回答するのではなく、実際の業務例を使って操作やデータの流れをたどります。 承認時には、未決事項、前提条件、対象外、開発段階で詳細化する項目も残してください。要件定義ですべてを完全に確定させることは難しいため、未決事項を隠さず管理できる状態のほうが安全です。 ## 見積もりの見方と支援会社の選び方 要件定義の見積もりは、総額だけでなく、作業範囲、成果物、会議回数、修正条件を比較します。安い見積もりでも、業務分析や画面設計が含まれていなければ、開発段階で追加費用が発生する可能性があります。 ### 見積書で確認する項目 次の項目が具体的に記載されているか確認してください。 - 調査対象となる業務、部署、システム - ヒアリングの対象者、回数、時間 - 現地調査や業務観察の有無 - 作成する成果物の名称と詳細度 - 画面設計や試作品の対象範囲 - 外部連携やデータ移行の調査範囲 - プロジェクト管理と会議の工数 - 発注者が準備する資料と担当作業 - 成果物のレビュー回数と修正回数 - 交通費、ツール利用料などの実費 - 対象外となる作業 - 追加費用が発生する条件 - 成果物の利用権とデータの受け渡し方法 - 要件定義後の開発見積もりや引き継ぎ対応 「要件定義一式」「打ち合わせ一式」とだけ書かれている場合は、具体的な作業と成果物を質問します。質問に対して、前提と対象外を明確に説明できる会社は、プロジェクト開始後も範囲管理を行いやすい傾向があります。 ### 契約形態も確認する 要件がまだ固まっていない段階では、準委任契約（＝一定の業務遂行を依頼する契約）が使われることがあります。調査結果に応じて作業内容を調整しやすい一方、成果物の完成そのものを約束する契約ではないため、稼働時間、報告方法、上限予算を決める必要があります。 作成する成果物と範囲が明確なら、請負契約（＝合意した成果物の完成を依頼する契約）を選ぶ場合もあります。ただし、契約前に想定できなかった調査や追加ヒアリングは、別費用になる可能性があります。 どちらが常に優れているということではありません。次の条件を確認して選びます。 |確認項目|準委任契約が合いやすい場合|請負契約が合いやすい場合| |---|---|---| |調査範囲|開始後に調整する必要がある|対象が具体的に決まっている| |成果物|状況に応じて変更する可能性がある|名称と内容を事前に定義できる| |予算管理|稼働上限と月次報告で管理する|成果物単位の金額で管理する| |変更対応|優先順位を入れ替えながら進めたい|変更時に追加見積もりできる| ### 支援会社を見極めるチェックリスト 要件定義の支援会社は、資料作成能力だけでなく、業務理解、技術的な実現性、合意形成を支援できるかで選びます。 - 自社と近い業務やシステム種別を理解しているか - 経営者と現場担当者の双方から話を聞けるか - 質問だけでなく、選択肢と判断材料を提示できるか - 業務要件と技術要件の両方を扱える体制か - リスク、未決事項、対象外を明示してくれるか - 特定の製品や開発方式ありきで進めていないか - 成果物のサンプルや目次を提示できるか - 要件定義後に他社へ開発を依頼できる契約か - 編集可能なファイル形式で成果物を受け取れるか - 後続の開発会社への説明や質疑対応を依頼できるか 要件定義から開発まで同じ会社へ依頼する方法には、引き継ぎが少なく、技術的な実現性を早期に確認できる利点があります。一方、要件定義と開発会社選定を分ける方法には、成果物を共通条件として相見積もりを取りやすい利点があります。 どちらを選ぶ場合も、「開発を受注するための無料提案」と「有償の要件定義」を区別してください。無料提案は、一般に提案方針や概算見積もりを示す範囲であり、詳細な業務調査や要件定義書の完成まで含むとは限りません。 要件定義の対象範囲や必要な成果物から相談したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からお問い合わせください。 ### よくある失敗と回避策 #### 要望をすべて必須要件にする 各部署の要望をすべて盛り込むと、費用が膨らみ、重要な機能の検討時間が不足します。初回公開に必要な要件と、運用後に追加できる要件を分けてください。 #### 意思決定者が会議に参加しない 実務担当者だけで進めると、終盤に責任者から方針変更が入りやすくなります。すべての会議に参加してもらう必要はありませんが、目的、予算、対象範囲、優先順位を承認するタイミングを設定します。 #### 現行資料が正しい前提で進める 業務マニュアルや旧システムの仕様書が、現在の運用と一致しているとは限りません。資料確認に加えて、実際の担当者へのヒアリングや操作確認を行います。 #### 非機能要件を開発開始後まで決めない 利用人数、処理速度、バックアップ、権限、監査ログなどを後から追加すると、設計変更につながることがあります。詳細な数値が決まらなくても、想定利用規模と事業上の重要度は要件定義で共有します。 #### 要件定義書を作ること自体が目的になる ページ数が多くても、判断に必要な情報が見つからなければ実務では使いにくくなります。後続の設計、見積もり、受入テストで参照できるかという観点で成果物を評価してください。 ## まとめ - 要件定義の外注費用は、小規模で50万〜150万円、中規模で150万〜500万円、大規模で500万〜1,500万円以上が一般的な目安です - 期間は小規模で2〜6週間、中規模で1.5〜3か月、大規模では3〜6か月以上を見込みます - 費用は機能数だけでなく、関係者数、例外業務、外部連携、データ移行、合意形成の難しさで変わります - 見積もりでは、成果物、ヒアリング回数、修正条件、対象外、追加費用の条件を確認します - 発注者は目的、優先順位、業務ルール、予算を決め、外注先には調査、整理、文書化、技術検証を依頼します - 要件定義の完了条件と未決事項を明文化し、後続の開発会社へ引き継げる状態にすることが重要です ## よくある質問 ### 要件定義は開発会社選定前に外注できますか？ はい。要件定義を独立した支援会社へ依頼し、その成果物を使って複数の開発会社から見積もりを取る方法があります。ただし、特定の技術や製品を前提にしすぎないこと、後続の開発会社が質問できる引き継ぎ期間を設けることが重要です。 ### 要件定義費用は開発費に含まれますか？ 会社や契約によって異なります。要件定義から開発まで一括で依頼する場合でも、見積書では要件定義、設計、実装、テストなどを分けてもらうと、対象範囲と追加費用の条件を確認しやすくなります。 ### 要件定義を無料で依頼することはできますか？ 初回相談や概算見積もりまでは無料の会社もありますが、業務分析、詳細なヒアリング、画面設計、要件定義書の作成まで無料で対応するケースは限定的です。無料提案の範囲と、正式な要件定義の範囲を分けて確認してください。 ### 社内にIT担当者がいなくても要件定義できますか？ 可能です。ただし、業務上の判断まで外注先へ丸投げすることはできません。社内では、目的、優先順位、業務ルール、予算、承認を決める責任者を置き、外注先には整理、文書化、技術的な検証を依頼する形が現実的です。