見積書を見ていて「要件定義費」の金額に違和感を覚える方は少なくありません。まだプログラムは1行も作られていない段階なのに、要件定義だけで数十万円から、規模によっては数百万円が計上されていることがあるためです。「設計図を作るだけでこの金額なのか」と感じるのは自然なことだと思います。
本記事は連載第3回として、要件定義費が高く見える理由を整理します。結論を先に言えば、要件定義は「成果物の見えにくい作業」であると同時に、後工程の手戻りや追加費用を抑えるための投資でもあります。その内訳を理解すると、金額の意味が読み取りやすくなります。
まず結論
- 要件定義費は「まだ動くものがない費用」に見えるため高く感じられますが、後工程の手戻りを減らすための費用でもあります。
- 見るべきなのは金額だけでなく、ヒアリング、業務整理、機能一覧、画面・帳票整理、非機能要件、要件定義書などの成果物です。
- 要件が固まっていない案件では、開発費と要件定義費を分けて見積もる方が、相見積もりの前提をそろえやすくなります。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 作業範囲 | 何を整理する費用か | 業務・機能・画面・データ・非機能 |
| 成果物 | 何を受け取れるか | 要件定義書、画面一覧、業務フローなど |
| 発注方法 | 開発と一体か分離か | 比較したい場合は分離も検討 |
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
この連載での位置づけ
- 前に読む記事：連載第2回：人月単価と工数
- 次に読む記事：連載第4回：保守費・運用費
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
要件定義とは何をする工程か
要件定義は、「何を作るか」を言葉と図にして確定させる工程です。発注側が頭の中で描いている「やりたいこと」を、開発できる粒度まで具体化していく作業だといえます。具体的には次のような作業が含まれます。
- 現状の業務のヒアリングと整理（誰が・いつ・何をしているか）
- 解決したい課題と、システムで実現したいことの言語化
- 必要な機能の洗い出しと、優先順位づけ
- 画面・帳票・データのおおまかな整理
- 連携が必要な既存システムやサービスの確認
- 非機能要件（性能、セキュリティ、運用）の確認
- 要件定義書としての文書化
これらは、プログラムを作る前の準備に見えますが、実際には関係者へのヒアリング、論点の整理、意思決定の支援といった、人の手間と専門性がかかる作業です。費用の多くは、この作業時間に対するものです。
なぜ要件定義費は高く見えるのか
要件定義費が高く見える背景には、いくつかの理由があります。
| 高く見える理由 | 実際に起きていること |
|---|---|
| 成果物が「動くもの」でない | 文書・図が成果物のため価値が見えにくい |
| 上流担当者の単価が高い | 要件定義はSE・コンサル層が担当することが多い |
| 工数がまとまってかかる | ヒアリング・整理・合意形成に時間がかかる |
| 後工程の費用が読めない | 要件が固まる前は開発費が概算にとどまる |
「動くものができていないのに高い」と感じるのは、成果物が文書や図であるためです。しかし、この段階で要件が言語化されているかどうかが、後工程の見積精度と手戻りの量を大きく左右します。
要件定義をあいまいにしたときに起きること
要件定義を簡略化して開発に進むと、費用を前倒しで抑えたように見えても、後工程で次のようなことが起きやすくなります。
- 作ってから「思っていたものと違う」となり、作り直しが発生する
- 仕様が固まっていないため、開発中の仕様変更が増える
- 追加費用の議論が頻発し、当初見積との差が大きくなる
- 完成の定義があいまいなため、検収の段階で認識がずれる
つまり、要件定義費は「先に払う費用」ですが、後工程の手戻りや追加費用を抑えることにつながる側面があります。要件定義の進め方や成果物の形は、システム開発の要件定義テンプレートも参考になります。
要件定義を分けて見積もる意味
要件定義を開発と切り離して、独立した契約・見積として進める方法もあります。これは「要件定義フェーズ」「企画・設計フェーズ」などと呼ばれます。分離するメリットは次の通りです。
- 要件が固まってから、開発費を精度高く見積もれる
- 要件定義の成果物を持って、複数の開発会社に相見積もりを取れる
- 要件定義の結果、進め方や規模を見直す判断ができる
一方で、要件定義を担当した会社にそのまま開発を依頼するケースも多く、その場合は引き継ぎコストが抑えられます。どちらが適しているかは、社内に要件をまとめられる人がいるか、複数社で比較したいか、といった条件によります。要件定義書がそろっていれば、相見積もりの比較もしやすくなります（相見積もりの比較方法）。
要件定義の進め方の型
要件定義は、おおまかに「現状を聞く → 論点を整理する → 合意する」という流れで進みます。最初に現状の業務やお困りごとをヒアリングし、次にやりたいことを機能や画面の単位に整理し、最後に「この範囲・この優先順位で進める」という合意を文書として残します。この流れがあることで、開発に入ってから「言った・言わない」のずれが起きにくくなります。要件定義費は、この一連の整理と合意形成にかかる作業への費用だと捉えると、内容が理解しやすくなります。
発注側が関わるほど精度が上がる
要件定義は開発会社に任せきりにするものではなく、発注側の関与が精度を左右します。実際の業務を知っているのは発注側であり、現場の事情や例外的な処理は、ヒアリングを通じてしか言語化できません。会議への参加、資料の提供、社内での確認の段取りなど、発注側がどの程度関与するかを最初にすり合わせておくと、要件定義の質と、その後の開発の手戻りの少なさにつながります。要件定義費を「丸投げの費用」ではなく「一緒に整理する費用」と捉えると、関与の意味が見えてきます。
要件定義費の妥当性を判断する観点
要件定義費が高いか妥当かを発注側が判断するには、費用の絶対額よりも「何を、どのくらいの作業量で進めるのか」を確認することが出発点です。次の観点を見ると判断しやすくなります。
| 確認観点 | 見るべきこと |
|---|---|
| ヒアリング回数・時間 | 何回・何時間のヒアリングが含まれるか |
| 参加者・担当役割 | SE・コンサル等の誰が担当するか |
| 成果物の種類と量 | 要件定義書、画面一覧、業務フロー図など |
| 承認・レビューの回数 | 発注側が確認・承認する機会がどのくらいあるか |
| 期間 | 要件定義にどのくらいの期間を見ているか |
これらが見積書または補足説明で示されていれば、費用の根拠が読み取れます。たとえば「ヒアリングが数回で数週間の作業量」を前提にした費用と、「関係部署をまたぐ複数回のヒアリングと整理が含まれる費用」では、同じ金額でも内容が異なります。
要件定義で受け取るべき成果物
要件定義が完了したときに、発注側が手元に持てる成果物は何かを確認しておくことが大切です。一般的に、次のような成果物が含まれます。
- 要件定義書：システムが実現すべき機能・非機能要件をまとめた文書
- 業務フロー図：現状と将来の業務の流れを図示したもの
- 画面一覧（ワイヤーフレーム）：必要な画面とその概要
- 機能一覧：優先順位や対応工程と合わせた機能のリスト
- 非機能要件シート：性能・セキュリティ・可用性などの要件
これらの成果物が手元に残ることで、開発会社に相見積もりを取る際の共通仕様書として使えますし、開発途中での仕様確認の基準にもなります。受け取れる成果物を事前に確認しておくことは、要件定義費の意義を具体的に理解することにもつながります。
発注前チェックリスト（要件定義費）
- 要件定義費が、開発費と分けて記載されているか
- 要件定義の成果物（要件定義書、画面一覧など）が示されているか
- 要件定義に発注側がどう関与するか（ヒアリング回数など）が分かるか
- 要件定義の結果を持って、他社にも見積を取れる形になっているか
- 要件定義費に含まれる作業と、含まれない作業が区別されているか
- 要件が固まった後の開発費が、概算か確定かが分かるか
- 要件定義で受け取れる成果物（要件定義書・画面一覧・業務フロー図等）が示されているか
- 要件定義のヒアリング回数・想定期間が説明されているか
- 発注側が承認・確認するタイミングが明確になっているか
開発会社に確認する質問
- 「要件定義では、どのような成果物を受け取れますか」
- 「要件定義に、私たちはどの程度関与しますか（会議やヒアリングの回数）」
- 「要件定義の成果物を使って、他社にも見積を取ることはできますか」
- 「要件定義の後、開発費はどの精度で出せますか」
- 「要件定義の途中で、進め方や規模を見直す判断はできますか」
相談前に整理しておくとよい情報
- 解決したい課題と、システム化で実現したいこと
- 現状の業務フロー（手作業、Excel、既存システムなど）
- 関係する部署・担当者と、意思決定の決裁ルート
- 想定している予算の幅と、判断の優先順位（コスト・納期・品質）
- 連携が必要な既存システムやサービス
これらを整理しておくと、要件定義の初回ヒアリングが効率的になり、要件定義費そのものの妥当性も検討しやすくなります。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. 要件定義は省いて、いきなり開発を始められませんか。
A. 始めること自体は可能ですが、要件があいまいなまま進むと、作り直しや仕様変更が増え、結果的に費用や納期が膨らみやすくなります。要件定義費は先に払う費用ですが、後工程の手戻りや追加費用を抑える投資の側面があります。
Q. 要件定義だけを別の会社に頼むことはできますか。
A. 可能です。要件定義を独立させると、その成果物を持って複数の開発会社に見積を依頼できます。一方、同じ会社に通しで頼むと引き継ぎの手間が省けます。社内で要件をまとめられるか、複数社で比較したいか、といった条件で選べます。
Q. 要件定義に、発注側はどのくらい関わる必要がありますか。
A. 現場の業務を知っているのは発注側のため、ヒアリングや確認に一定の関与が必要です。関与の度合いを最初にすり合わせておくと、要件の精度と、その後の開発の手戻りの少なさにつながります。
まとめ
要件定義費は、成果物が文書や図であり、上流担当者の作業時間が中心となるため、相対的に高く見えやすい費用です。ただし、要件をこの段階で言語化しておくことは、後工程の手戻りや追加費用を抑えることにつながります。要件定義を開発と分けて見積もるか、同じ会社に通しで依頼するかは、社内体制と相見積もりの方針によって選べます。次回は、開発費だけで判断したときに見落としやすい「保守費・運用費」を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
