要件定義の費用相場｜外注するときの見積の見方と抑える5つの方法

要件定義の費用は「人数×期間×人月単価」で決まり、小規模なら数百万円、基幹システム級なら数千万円規模まで開く、というのが計算上の見方です。見積を受け取ったら、金額の大小ではなく、対象範囲・工数と単価・成果物・打ち合わせの回数・追加対応の条件という5項目を確認すると、妥当性を判断できます。

この記事では、システム導入を検討する企画担当者や、見積を比較するITコンサルタントに向けて、費用の考え方、規模別の相場の見方、見積の内訳の確認項目、費用を抑える方法、外注先の比較ポイントを整理します。数値は2026年10月時点で確認できた公的資料と、編集部の実務知見にもとづきます。

要件定義にかかる費用の考え方

要件定義の費用は、作業の対価として支払う人件費が中心で、人月単価に必要な人月を掛けた金額が基本形です。要件定義は、ユーザーが実現したいことを整理し、システムの機能や条件として確定させる工程です。

要件定義書とは何かと費用の関係

要件定義書は、決めた内容を文書にしたもので、どこまで細かく書くかが費用に直結します。業務要件、機能要件、非機能要件を一覧にするだけなら作業量は抑えられますが、画面・帳票・データの項目まで定義する場合は工数が大きく増えます。

要件定義書の項目や書き方は、Web開発における要件定義書の書き方と、要件定義書のフォーマット・書き方の解説記事で整理しています。見積を読む前に、どの粒度の文書を受け取りたいかを決めておくと、金額の比較がしやすくなります。

費用が変わる3つの要素

費用を動かす要素は、対象の規模、関わる範囲、ユーザー側の参加度の3つです。

• 対象の規模：画面・機能・帳票の数が増えるほど、整理して文書にする作業が増えます。
• 関わる範囲：関係する部署の数、既存システムとの連携数、データ移行の有無で、ヒアリングと調整の量が変わります。
• ユーザー側の参加度：発注側の担当者が要求の整理に関わるほど、手戻りが減ります。IPA（情報処理推進機構）の分析では、ユーザー担当者が要求仕様に関与している案件で要求仕様が明確だった割合は約71%、関与していない案件では約34%でした（IPA「設計レビュー・要件定義強化のススメ」2017年3月、2.2.1項）。

3つ目は、発注側が自分たちで動くほど外注費の増加を抑えやすいことを意味します。具体的な方法は、費用を抑える5つの方法の章で扱います。

費用相場の見方

要件定義だけの費用を公的に集計した統一の相場表は、編集部が確認した範囲では見当たらないため、工数から逆算して妥当性を見るのが現実的です。逆算の手がかりとして、IPAの分析では、要件定義から総合テストまでの総工数に占める要件定義の工数比率は中央値で約6.3%でした。ただしこの値は、ユーザー側の要件定義工数を含まず、要件定義を別契約で先に進めた案件も含まないため、過小評価の可能性があるとIPA自身が注記しています（IPA「設計レビュー・要件定義強化のススメ」2017年3月、2.2.1項）。開発全体の見積に対する要件定義の割合は、下限の目安として見てください。

人月単価は、依頼先の職位で変わります。編集部の実勢目安（週5稼働）では、コンサルタントが月120万円程度、シニアコンサルタントが月150万円程度、マネージャーが月180万円程度です。上流フェーズ（戦略策定・要件定義）は下流の運用・保守より単価が高くなる傾向があります。開発ベンダーの人月単価はこの目安と一致するとは限らないため、見積の単価欄は別途確認してください。

次の表は、人月単価を月120万円と仮置きした計算例です。体制と期間は編集部が計算のために置いた仮の規模感であり、実際の見積額を保証する数値ではありません。

小規模システムの場合

小規模システムは、1つの部署が使う業務ツールのように、画面数が限られ外部連携がほとんどない案件で、仮置きの計算では数百万円規模になります。画面や機能の一覧と、主要な業務フローを書けば要件が固まるため、期間は1〜2か月が目安です。

注意したいのは、小規模でも「何を作らないか」を決めていないと、後から機能が増えて費用が膨らむ点です。要件定義書に、対象外とする機能を明記してもらうと、追加費用の線引きがしやすくなります。

中規模システムの場合

中規模システムは、複数の部署が関わり既存システムとの連携がある案件で、仮置きの計算では1,000万円前後になります。ヒアリング先が増えるため、期間は3〜4か月ほどかかります。

この規模では、業務の現状整理に使う時間が費用の大きな部分を占めます。現行の業務フローや画面の一覧が発注側で用意できているかどうかで、見積の差が出やすくなります。

大規模・基幹システムの場合

大規模・基幹システムは、全社の業務や多数のシステム連携、データ移行を含み、仮置きの計算では数千万円規模になります。期間は半年以上になることが多く、要件定義を開発とは別の契約として先に発注するケースも珍しくありません。

要件定義は、IPAと経済産業省の「情報システム・モデル取引・契約書」でも、成果物の完成を約束する請負ではなく、作業の遂行を対価とする準委任型と整理されています（IPA「情報システム・モデル取引・契約書」解説資料、2025年、スライド60）。また、見積の精度は試算、概算、確定と段階を追って上がる多段階の考え方が示されています（同資料、スライド53）。大規模案件では、最初の見積を確定額と受け取らず、段階ごとに見直す前提で契約を組むのが一般的です。

見積の内訳を確認する5つの項目

見積の妥当性は、対象範囲・工数と単価・成果物の種類・打ち合わせの回数・追加対応の条件の5項目を見れば判断できます。総額だけで比べると、含まれている作業が違うために、安く見える見積ほど後から費用が増えることがあります。次の表で、各項目の確認ポイントと、見積書に書かれていない場合のリスクを整理します。

対象範囲

対象範囲は、どの業務と機能を要件定義に含めるかを文章で確認する項目です。見積書に「基幹システム要件定義一式」とだけ書かれている場合は、対象とする業務、連携する既存システム、データ移行の検討を含むかを、依頼先に質問してください。

要件定義は準委任型の契約になることが多く、決められた範囲の作業を行うことが対価の根拠になります。範囲が広がれば作業が増えるため、範囲の記載がそのまま費用の上限を決めます。

工数と単価

工数と単価は、職位ごとの人数と期間、人月単価に分けて書かれているかを確認する項目です。「担当者2名、2か月」と書かれていても、2名が同じ職位とは限りません。職位ごとの単価の違いは大きいため、内訳を出してもらってください。

フリーランスのコンサルタントに依頼する場合は、準委任契約で月額単価に稼働率を掛けて報酬を決める形が一般的です。要件定義を担うコンサルタントの単価の見方は、要件定義フリーランスの案件と単価で整理しています。

成果物の種類

成果物の種類は、要件定義書のほかに何が納品物として含まれるかを確認する項目です。業務フロー図、機能一覧、画面の概要、非機能要件の一覧のうち、どれが含まれているかで、受け取る文書の粒度が変わります。

たとえば、機能一覧だけの成果物と、画面ごとの入出力項目まで書かれた成果物では、必要な作業量が数倍違うことがあります。後工程の設計や開発の見積を取る際に、そのまま使える粒度かを見て判断してください。

打ち合わせの回数

打ち合わせの回数は、ヒアリングと定例会議が何回、どの参加者で含まれているかを確認する項目です。要件定義は、依頼先がユーザー側の関係者から話を聞いて進める工程のため、打ち合わせの回数がそのまま工数に反映されます。

決裁者や各部署の代表が毎回出席できるかも、費用に影響します。出席者が揃わず確認が先送りになると、期間が延びて人件費が増えるためです。見積の前提として、発注側の参加者と日程の想定を共有しておくと、見積のずれを防げます。

追加対応の条件

追加対応の条件は、仕様変更や追加依頼が出たときの費用の決め方を確認する項目です。再見積を行う条件、追加分の単価、変更を受け付ける期限が書かれているかを見てください。

IPAの分析では、要求仕様が明確なグループの不具合の発生件数は、規模の目安であるファンクションポイント千点あたりの中央値で約2.4件、明確でないグループでは約6.5件でした（IPA「設計レビュー・要件定義強化のススメ」2017年3月、2.2.1項）。要件が曖昧だと後工程で手戻りが増えやすいため、追加対応のルールを最初に決めておくことが、総額を抑える近道です。

費用を抑える5つの方法と注意点

費用を抑えるには、依頼先に渡す前の準備を発注側で進めて、依頼先の作業量そのものを減らすのが有効です。次の5つの方法を、順番に確認してください。

1. 目的と優先順位を社内で決める：システムで解決したい課題を1〜3つに絞り、機能を「必須」「あると良い」「将来対応」に分けます。入力は社内の要望の一覧、出力は優先順位をつけた機能の一覧です。
2. 範囲を段階に分けて発注する：最初は業務整理と主要機能だけを要件定義し、詳細は次の段階で確定させます。IPAのモデル契約でも、見積精度に合わせて契約を分ける多段階の考え方が示されています。
3. 現状の資料を先に渡す：現行の業務フロー、画面の一覧、帳票の見本を整理して渡します。入力は社内にある既存資料、出力は依頼先の現状把握にかかる時間の短縮です。
4. 打ち合わせの運営を決める：決裁者の出席、議題の事前共有、決定事項の記録担当を決めます。確認の先送りが減り、期間の延長を避けられます。
5. 既存の成果物を再利用する：過去の要件定義書や、同種のシステムの文書を共有します。新しく書く部分が減ります。

注意点は、要件定義の工数を削りすぎないことです。IPAの分析では、要件定義の工数比率が高い案件（中央値6.3%以上）は、要件定義書の密度が約2倍だったとされています（IPA「設計レビュー・要件定義強化のススメ」2017年3月、2.2.1項）。費用を削った結果、要件が曖昧なまま開発に進むと、後工程の手戻りで総額が増える場合があります。個別の判断が必要な場合は、専門家への相談をおすすめします。

外注先を選ぶときの比較ポイント

外注先は、金額ではなく、要件定義の実績・契約形態・見積の開示・担当者の経験・開発との分離の5つの観点で比べるのが基本です。見積の安さだけで選ぶと、成果物の粒度や範囲が合わず、後から費用が増える場合があります。

開発を請ける会社に要件定義も任せると、要件定義の段階で開発の仕様が固まるため、後から他社と見積を比較しにくくなる場合があります。要件定義を分けて発注し、開発の見積を複数社から取る方法は、費用の透明性を高める選択肢です。

担当者の経験は、見積の金額と同じくらい重要です。要件定義の経験が浅い人が担当になると、ヒアリングに時間がかかり工数が膨らむ場合があります。コンサルタント側から見た参画条件は、要件定義の経験が浅くてもフリーランスになれるかを扱った記事で整理しています。担当者の経験を確認するときの目安になります。

まとめ｜費用の根拠を確認して依頼する

要件定義の費用は、人数・期間・人月単価の掛け算で決まるため、見積では総額より内訳の根拠を確認することが大切です。

• 費用は規模、関わる範囲、ユーザー側の参加度の3要素で変わります。
• 相場は工数から逆算し、人月単価の仮置きで計算例を作ると比較しやすくなります。
• 見積は対象範囲、工数と単価、成果物、打ち合わせの回数、追加対応の条件の5項目で確認します。
• 費用を抑えるときは、発注側の準備を進めつつ、要件定義の工数を削りすぎないようにします。
• 外注先は金額だけでなく、実績、契約形態、見積の開示、担当者の経験、開発との分離で比べます。

数値は2026年10月時点の確認内容です。実際の費用は案件ごとに異なるため、複数の依頼先から見積を取り、内訳を質問したうえで判断してください。

出典・参考情報

1. 独立行政法人情報処理推進機構（IPA）「設計レビュー・要件定義強化のススメ」（2017年3月31日）（2026-10-12参照）：要件定義工数比率、ユーザー関与と要求仕様の明確さ、不具合密度
2. IPA「システム開発の健全化に向けて 「情報システム・モデル取引・契約書」から読み解く」（2025年4月）（2026-10-12参照）：要件定義の契約類型、多段階契約と見積精度
3. 編集部の実勢目安（週5稼働のコンサルタントの月額単価、2026年8月時点）：計算例の人月単価の根拠

本記事のデータは2026年10月12日時点の情報に基づきます。最終更新日：2026年10月12日。