要件定義 費用の相場と内訳【2026年版】見積もり前の確認点

はじめに

「要件定義だけで数十万円以上の見積もりが来たが、この金額は妥当なのか」。システム開発を外注するとき、多くの担当者が最初に迷うのがこの点です。要件定義は目に見える成果物が文書中心のため、何にいくらかかっているのかが分かりにくい工程です。複数の開発会社から見積もりを取っても、作業範囲や成果物の前提がそろっていなければ、金額の高い・安いを比べることもできません。社内で予算の承認を得る場面でも、金額の根拠を説明できないと話が進みにくくなってしまいます。

要件定義の費用を下げようとして、ヒアリングやレビューを削る判断をしてしまうことがあります。しかし、関係者の意見を集める時間が不足すると、開発が始まってから要件の追加や変更が重なり、結果として総額が上がりやすくなります。金額の大小だけでなく、何に工数が使われているかを読み解くことが大切です。

要件定義は「何を作るか」を関係者全員で合意する工程であり、ここが曖昧なまま進むと後工程で修正が重なり、開発費と納期が膨らみます。要件定義の費用は、開発全体の手戻りを減らすための投資として見積もりを読むことが大切です。

本記事では、要件定義の費用の相場を公的機関のデータをもとに整理し、開発費に占める割合、内訳と計算例、金額が増減する要因、見積もりを依頼する前に確認したい項目を解説します。後半では、要件定義の進め方や要件定義書に書くべき内容、よくある失敗パターンもまとめています。発注前に見積もりの妥当性を判断したい担当者の参考になれば幸いです。

ソフトウェア開発における要件定義とは？

要件定義とは、開発するソフトウェアが「誰の、どんな課題を、どう解決するか」を文書化し、開発者と依頼者の間で合意を取るプロセスです。費用の対象は、この合意づくりの作業量です。

要件定義が扱う主な項目は以下のとおりです。

項目	内容
業務要件	業務上の目的・背景・制約条件
機能要件	実装すべき具体的な機能一覧
非機能要件	パフォーマンス・セキュリティ・拡張性など
UI/UX要件	画面レイアウトや操作性の方針
インフラ要件	サーバー・クラウド・ネットワーク構成など

要件定義 費用の相場と開発費に占める割合

要件定義の費用は規模や難易度で大きく変わるため、目安には開発全体に対する割合を使います。

IPA（情報処理推進機構）のソフトウェア開発データ白書2018-2019 情報通信業編と製造業編では、新規開発の実績データから、要件定義の工数は基本設計から総合テストまでの開発5工程に対して約1割程度と整理されています。期間では、要件定義を含む6工程の月数に対し、要件定義の月数は中央値で情報通信業編が15%程度、製造業編が22%程度です（2026年9月24日確認）。

工数より期間の比率が大きいのは、要件定義が関係者との調整や確認待ちを伴い、作業を分担して短縮しにくい工程であるためと考えられます。この割合を使うと、開発費の規模から要件定義費用の目安を逆算できます。

開発5工程の費用（税抜）	要件定義費用の目安（税抜・約1割で換算）	想定される規模感
300万円	約30万円（税抜・開発5工程の約1割）	小規模な業務ツール・社内システム
1,000万円	約100万円（税抜・開発5工程の約1割）	複数部門で使う業務システム
3,000万円	約300万円（税抜・開発5工程の約1割）	外部連携が多い基幹寄りのシステム

割合はあくまで中央値付近の目安です。難易度や体制によって、次のように上下します。

条件	比率が上がりやすい	比率が下がりやすい
難易度	業務ルールが複雑、例外処理が多い	既存の業務をそのままシステム化する
発注側の体制	担当者が兼任で、決定者が不在	専任担当と決裁者が打ち合わせに参加する
開発会社の体制	業務コンサルを含めて依頼する	発注側で業務整理を済ませて依頼する

1割を大きく下回る見積もりは成果物の範囲が狭い可能性があり、大きく上回る場合は業務改善の検討まで含まれていないかを確認します。

要件定義 費用の内訳と計算例

要件定義の費用は「作業ごとの工数 × 単価」で算出するのが一般的です。以下は前提を置いた計算例で、単価は計算を示すための仮の値であり、相場を示すものではありません。 見積書の単価に置き換えて読んでください。

前提: 2部門が利用する業務システム、画面15程度、会計ソフトとのCSV連携1件、1人月=20人日、仮単価=1人日5万円（税抜）

作業	主な内容	工数	金額（税抜・仮単価1人日5万円）
ヒアリング	経営層・現場・情報システム担当への聞き取り	4人日	20万円（税抜・仮単価）
業務整理	現状と改善後の業務フロー作成	4人日	20万円（税抜・仮単価）
機能要件	機能一覧、画面一覧、入出力の定義	5人日	25万円（税抜・仮単価）
非機能要件	性能、権限、セキュリティ、バックアップ	2人日	10万円（税抜・仮単価）
成果物作成	要件定義書、画面イメージの作成	4人日	20万円（税抜・仮単価）
レビュー・合意	関係者レビュー、修正、最終合意	3人日	15万円（税抜・仮単価）
合計	—	22人日（約1.1人月）	110万円（税抜・仮単価）

見積書では合計金額より先に工数の配分を見ます。ヒアリングやレビューが極端に少ないと、後から要件が追加されるおそれがあります。また、同じ22人日でも単価が変われば金額は変わるため、複数社を比べるときは工数と単価を分けて確認すると差の理由が分かります。

費用が増減する5つの要因

同じ規模でも、要件定義の費用は発注側の条件で変わります。5つの要因に自社の状況を当てはめてください。

要因	費用が増える条件	費用が減る条件	自社の状況
関係者数	部門・拠点が多く、意見調整が必要	利用部門が1つで担当者が明確	□
既存資料	業務マニュアルや現行仕様書がない	業務フロー図や画面キャプチャがある	□
外部連携	会計・販売・外部サービスとの連携が多い	単独で完結する	□
非機能要件	高い可用性や厳しいセキュリティ基準がある	社内利用で一般的な水準で足りる	□
意思決定速度	決裁者が打ち合わせに参加せず、持ち帰りが多い	その場で決められる担当者がいる	□

自社で改善しやすいのは既存資料と意思決定速度です。業務の流れを箇条書きで残し、決裁者が要所の打ち合わせに出るだけでも工数を抑えられます。

開発方法別の要件定義コスト比較

要件定義の負担は、開発アプローチによっても変わります。

開発方法	要件定義の工数の傾向	要件の確かめ方	対応の柔軟性
スクラッチ開発	大きい（仕様を文書で細かく固める）	要件定義書・設計書のレビュー	自由度が高い
パッケージ導入	中程度（フィット＆ギャップ分析が中心）	標準機能と業務の差分確認	既定機能の範囲内
ノーコード開発（Bubble）	小さくしやすい（画面を作りながら確認）	動く画面のプロトタイプで確認	カスタム対応可

ノーコード開発では画面を動かしながら要件を確認できるため、文書だけで認識をそろえる負担を減らせます。当社では、Bubbleで主要画面のプロトタイプを作り、関係者に操作してもらいながら要件を固める進め方を支援できます。

見積もり依頼前のチェックリスト

依頼前に次の6項目を整理しておくと、見積もりを同じ前提で比較できます。

確認項目	整理しておく内容	確認
目的	システム化で解決したい課題と、達成したい状態	□
対象業務	システム化する業務の範囲と、今回は対象外とする業務	□
予算上限	要件定義と開発を合わせて使える予算の上限	□
決裁者	要件を最終決定する人と、合意の取り方	□
成果物	要件定義で受け取る文書・画面イメージの種類	□
変更管理	要件定義後に変更が出たときの判断手順と費用の扱い	□

予算上限と成果物を先に伝えると、見積もりの前提がそろい、金額の比較がしやすくなります。 開発工程を含めた見積書の読み方は、アプリ開発の見積もりの費用内訳と比較ポイントで解説しています。

なぜ要件定義が重要なのか？

ソフトウェア開発において要件定義が重要視される理由は主に3つあります。

1. 仕様のブレを防いでコスト超過を防止する：後から機能の追加や削除が発生するたびに、追加費用と工期延長が生じます。要件定義で合意を取っておくと、後戻りを減らせます
2. 関係者の認識を統一する：開発者・発注者・現場ユーザーが同じゴールを共有することで、各工程での確認コストが下がります
3. トラブル時の基準になる：「当初の合意内容と異なる」という紛争が起きた際、要件定義書が判断の根拠になります

要件定義の進め方（5ステップ）

要件定義は以下の流れで進めるのが一般的です。期間は中小規模の場合の目安です。

1. ヒアリング（1〜2週間）：業務課題、解決したい問題、利用するユーザー像を経営層・現場・IT部門から洗い出します
2. 業務分析（1週間）：業務フロー図やユーザーストーリーで「誰がどう使うか」を明確にします
3. 要件整理（1〜2週間）：機能を「必須」「あれば良い」「スコープ外」に分類し、予算調整に備えます
4. 要件定義書の作成（1週間）：機能要件・非機能要件・画面一覧・制約条件を文書化します
5. レビューと合意形成（1週間）：関係者全員でレビューし、正式に合意します

規模によっては1〜2か月かかることもあります。

要件定義書に書くべき内容

要件定義書に最低限含めるべきセクションは以下のとおりです。見積もりで「成果物」を確認するときの基準にもなります。

1. プロジェクト概要：目的・背景・対象ユーザー・プロジェクトスコープ
2. 業務フロー図：現状の業務の流れと改善後のフロー
3. 機能要件一覧：各機能の概要・入出力・処理条件
4. 非機能要件：応答速度・同時接続数・セキュリティ基準・可用性
5. 画面一覧：主要画面の一覧とワイヤーフレーム
6. 制約条件：使用技術の制限・法令要件・既存システムとの連携
7. スケジュールと体制：担当者・確認フロー・マイルストーン

稼働後の問い合わせ対応や改修の範囲も、この段階で決めておくと運用費を見通しやすくなります。保守契約の考え方はシステム開発の保守費用の相場と内訳を参考にしてください。

要件定義でよくある失敗パターン

1. ヒアリング対象が経営層だけ：現場担当者の意見を聞かずに要件を固めると、完成後に「使いにくい」という声が出やすくなります
2. 非機能要件を後回しにする：「表示が遅い」「同時アクセスで止まる」は非機能要件の見落としが原因のことが多くあります
3. 要件書を一度作ったら更新しない：開発途中の要件変化に備え、変更管理のルールを設けて要件書を最新に保ちます
4. 「なんとなく」の合意で進める：曖昧な合意のまま進めると、終盤で大きな認識ズレが発覚します。正式な合意手続きを経ることが大切です

要件定義の品質を上げる4つの工夫

1. プロトタイプを早期に作る：動くものを見せながら要件を固めることで、認識ズレを減らせます
2. ユースケースで議論する：機能リストでなく実際の業務シーンで議論すると、実用性が高まります
3. 関係者全員で合意形成する：経営層・現場・IT部門の3者から意見を集めて要件を固めます
4. 変更管理ルールを最初に決める：開発途中の要件変更にどう対応するかを事前に決めておきます

よくある質問（FAQ）

Q1. 要件定義はどのくらいの期間をかけるべきですか？

中小規模では1〜2か月が一つの目安です。IPAの白書2018-2019では、要件定義の月数は6工程の中央値で15〜22%程度です。

Q2. 要件定義の費用相場はいくらですか？

一律の金額はありません。IPAのデータでは工数が開発5工程の約1割程度のため、開発費1,000万円なら約100万円（税抜）が目安です。

Q3. 見積もりに「要件定義一式」としか書かれていない場合は？

作業ごとの工数と成果物の一覧を出してもらい、抜けている作業がないかを確認しましょう。

Q4. ベンダーに丸投げするのは可能ですか？

要件定義の主体は発注側です。業務知識や経営判断は発注側がインプットし、ベンダーは整理と文書化を支援します。

Q5. 要件定義書はどのくらいのページ数が必要ですか？

規模によって大きく変わります。ページ数より、決定事項が明確か、曖昧な表現を残していないかが重要です。

Q6. アジャイル開発でも要件定義は必要ですか？

必要です。プロダクトバックログやユーザーストーリーの形で要件を整理します。

仕様書の書き方と種類は仕様書とは？書き方・種類・無料テンプレートを完全解説【2026年最新】で解説しています。

まとめ

要件定義の費用は、システムの規模・難易度・発注側の体制で変わるため、一律の相場では判断できません。IPAのソフトウェア開発データ白書2018-2019では、要件定義の工数は開発5工程の約1割程度とされており、開発費の規模から目安を逆算できます。

見積もりの妥当性を確かめるときは、合計金額だけでなく、ヒアリング・業務整理・機能要件・非機能要件・成果物作成・レビューの工数配分を確認しましょう。関係者数、既存資料、外部連携、非機能要件、意思決定速度の5つの要因を自社に当てはめると、金額の理由が読み解けます。依頼前には、目的・対象業務・予算上限・決裁者・成果物・変更管理の6項目を整理しておくと、複数社の見積もりを同じ前提で比べられます。

要件定義の費用を抑えたい場合も、削るべきはヒアリングやレビューではありません。発注側で既存資料を集め、決裁者の参加日程を先に押さえるなど、工数が増える要因を減らすことが近道です。見積もりを受け取ったら、この記事の計算例やチェックリストと照らし合わせ、前提の違いを開発会社に質問してみてください。回答の内容から、その会社の進め方も見えてきます。

当社では、要件がまだ漠然としている段階から、業務の整理とBubbleによるプロトタイプ作成を通じて要件を固める作業を支援できます。「要件定義の見積もりが妥当か分からない」「どこまで社内で準備すべきか知りたい」という場合も、無料相談で状況を伺い、進め方を一緒に整理します。