Q. 要件定義の後に見積もりが上がった！これは普通？要件定義が別料金な理由と増額の見極め方

最初に聞いた見積もりをもとに社内で予算を取ったのに、要件定義（＝作るものの中身を文章で決める工程）が終わったら、開発の見積もりが大きく上がっていた。しかも、その要件定義自体にも費用がかかっている。「話が違う」と感じるのは、とても自然なことです。

先に結論をお伝えします。要件定義の後にシステム開発の見積もりが変わること自体は、珍しいことではありません。最初の金額は「中身が決まる前の目安」で、要件定義はその中身を決めるための独立した仕事だからです。ただし、増額が妥当かどうかは「最初の見積もりの前提から、何が変わったのか」で判断できます。そして、開発の契約を結ぶ前の今は、範囲を絞る・段階に分けるなど、発注者が打てる手がいちばん多いタイミングでもあります。

この記事では、Q&A形式で「なぜ上がるのか」「なぜ要件定義は別料金なのか」「増額をどう見極め、どう返すか」「次からどう防ぐか」を順に解説します。

短い回答：見積もりが要件定義の後に変わるのは普通。ただし「理由の説明」は求めてよい

要点を3つにまとめます。

• 最初の見積もりは「目安」：要件が決まる前の金額は、どうしても幅のある推定になります。要件定義で中身が具体的になれば、金額が上下するのは自然な流れです
• 要件定義は「それ自体が仕事」：業務の聞き取り、整理、要件定義書の作成には、専門家の時間がかかります。開発とは別の工程として契約するのは、公的なモデル契約でも示されている考え方です
• 増額には「前提との差」の説明が必要：「最初の見積もりの前提」と「要件定義で決まったこと」を並べ、どこが変わって、いくら増えたのかを説明してもらうのが、発注者として当然の確認です

「普通のことだから黙って受け入れる」でも、「約束が違うから認めない」でもなく、中身を確かめたうえで、範囲と金額を一緒に調整するのが現実的な進め方です。

なぜ最初の見積もりは要件定義の後に変わるのか

最初の見積もりは「見えていない部分」を想定で埋めている

最初の相談の段階で、開発会社が知っているのは、打ち合わせ1〜2回分の話と、いただいた資料くらいです。画面がいくつ必要か、例外的な処理がどれだけあるか、どのシステムとつなぐか、といった細部は、まだ誰にも分かっていません。

開発会社は、分からない部分を「似た案件ならこのくらい」という経験で埋めて金額を出します。要件定義で業務を詳しく聞いていくと、この想定よりも中身が多かったり、複雑だったりすることが分かります。これが、増額のいちばん多い理由です。もちろん、想定より少なくて済み、金額が下がることもあります。

公的なモデル契約でも「要件定義までの見積もりは確定ではない」とされている

システム開発の契約について、IPA（情報処理推進機構）が公開しているモデル契約書（＝契約書のひな型と解説）でも、この考え方が示されています。

📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」

同モデル契約書の解説では、見積もりの時期とリスクの関係を踏まえ、工程ごとに個別の契約を結ぶ「多段階契約」と、曖昧さがある段階の見積もりを要件が明確になった段階で見積もりなおす「再見積り」の考え方を採用したと説明されています。さらに、システム化の方向性・システム化計画・要件定義の各段階の見積もりは「確定見積」ではなく、画面や帳票などを決める外部設計（＝画面や操作の仕様を決める工程）の段階で確定見積が可能と考える、という整理も示されています。

つまり、要件定義の後に見積もりを出しなおすのは、手順としてむしろ想定どおりということです。同じ解説では、発注者側にはできるだけ早く要件を確定することが正確な見積もりに必要だと認識すること、開発会社側には見積もりの精度を高める取り組みと十分な説明責任が求められることにも触れています。増額の説明を求めるのは、発注者の正当な確認だと考えてよいでしょう。

なお、このモデル契約書は、対等な交渉力を持つ民間大手企業と開発会社の取引などを前提にしたひな型です。中小企業の案件にそのまま当てはめるものではなく、考え方の参考として捉えてください。

なぜ要件定義は開発と別料金なのか

要件定義は「作る」前の「決める」仕事

要件定義で開発会社が行うのは、たとえば次のような作業です。

• 現場の担当者への聞き取り、今の業務の流れの整理
• 例外処理や「たまにあるケース」の洗い出し
• 画面・帳票・データ・外部連携の一覧づくり
• 速さや安全性など、機能以外の条件（非機能要件）の確認
• 要件定義書としてまとめ、発注者と読み合わせて合意する

これらは、どれも経験のある人が時間をかけて行う仕事です。開発の契約が結ばれる保証がない段階でこの作業を無償で行うと、開発会社にとっては回収できないリスクになります。そのため、要件定義を独立した有償の工程として扱う会社は多くあります。

要件定義は「準委任」で契約されることが多い

もう一つの理由は、契約の形です。システム開発の契約には、大きく分けて次の2つがあります。

契約の形	ざっくりした意味	向いている工程
請負（うけおい）	決まった成果物を完成させて納める	作るものが具体的に決まっている工程
準委任（じゅんいにん）	専門家として適切に作業を行う（完成までは約束しない）	作るものがまだ決まっていない工程

先ほどのIPAのモデル契約書の解説では、要件定義の段階は発注者の業務要件がまだ具体的に確定しておらず、開始時点では発注者自身にとっても成果物を具体的に想定できないため、請負にはなじみにくく準委任が適切、という考え方が示されています。モデル契約書は、超上流工程（＝構想・計画・要件定義など開発前の工程）の重要性を明らかにするため、要件定義を独立した段階とし、契約の類型を準委任型としています。

また同じ解説では、中小企業のように社内体制が十分でない場合でも超上流工程の重要性は変わらず、企画・要件定義の段階と開発の段階を別の契約にすることが望ましい、とも述べられています。「要件定義が別料金」なのは、開発会社の都合だけでなく、発注者にとっても「決まっていない状態で大きな金額を確定させない」ための仕組みと捉えることができます。

なお、請負と準委任では責任の範囲や支払いの考え方が異なります。自社の契約書でどちらになっているか、どういう責任分担かといった個別の判断は、弁護士などの専門家に確認してください。

要件定義書は発注者の手元に残る「資産」

要件定義に費用を払うと、成果として要件定義書が手元に残ります。これは開発の見積もりの土台であり、社内で「何を作るか」を説明する資料にもなります。

モデル契約書の解説では、工程ごとに契約を分けることで、工程ごとに異なる開発会社に分割して発注することも可能になる、とも触れられています。ただし、要件定義書を他社に見せてよいか、どう使ってよいかは、契約の内容（権利の帰属や秘密保持の条項）によって変わります。使い方を考えている場合は、契約書を確認しておきましょう。

増額が妥当かを見極める4つの視点

では、目の前の増額が「中身が見えてきたことによる自然な増額」なのか、それとも「もう少し調整できる増額」なのか。次の4つの視点で確認します。

視点1：最初の見積もりの「前提条件」と今を並べる

まず、最初の見積もりに書かれていた前提条件（＝この条件なら、この金額という想定）を探しましょう。見積書の備考欄や提案書に「画面数◯程度」「既存システムとの連携は含まない」「データ移行は別途」などと書かれていることがあります。

その前提と、要件定義で決まった内容を横に並べると、どこが変わったのかが見えてきます。

増額の理由の例	妥当性の考え方
要件定義で要望が追加された（機能・画面が増えた）	追加した分の増額は自然。その要望が本当に必要かを見直す余地がある
前提条件が変わった（連携先が増えた、データ量が想定より多い等）	前提との差として説明できれば自然。前提が書かれていなかった場合はよく話し合う
業務の複雑さが見えてきた（例外処理・承認ルートが多い等）	最初の段階では見えにくい部分。どの業務が増額の要因かを具体的に聞く
機能以外の条件が具体化した（速さ・安全性・バックアップ等）	必要な水準かを確認する。水準を下げられる部分がないか相談できる
理由が特に説明されない・一律に増えている	内訳と根拠の説明を求める段階

視点2：増えた金額を「項目ごと」に分けてもらう

「総額が◯割増えた」だけでは判断できません。機能ごと、工程ごと（設計・開発・テスト・移行など）に、最初の見積もりと今の見積もりの差を出してもらいましょう。

項目ごとに分かれると、「この機能のためにこれだけ増えている」と分かり、次の「どう返すか」を考えやすくなります。

視点3：その増額は「自社が決めたこと」によるものか

要件定義の打ち合わせで「これもあったほうがいい」と自社側から要望を足していくと、それだけで金額は上がります。議事録を見返し、増額の要因のうち自社の要望で増えた部分がどれだけあるかを確認しておくと、社内への説明もしやすくなります。

自社が何も足していないのに大きく増えている場合は、最初の想定を率直に聞いてみましょう。

視点4：比べられる材料があるか

要件定義書ができると、それを土台に他の開発会社の意見を聞くこともできます（前述のとおり、使い方は契約の内容を確認のうえで）。金額の比較だけでなく、「この要件ならこういう作り方もある」という別の視点が得られることもあります。

「増額の説明を求められるのは、こちらとしても助かります。『この部分はこういう理由で増えました』と説明できれば、何を削れば予算内に収まるかも一緒に考えられますから」

予算を超えたときの具体的な対処法

増額の中身が分かったら、次は「どう返すか」です。開発の契約を結ぶ前の今なら、選べる手はたくさんあります。

対処1：必須と「あれば嬉しい」に分け直して範囲を絞る

要件定義で出てきた要望を、あらためて「これがないと業務が回らない」必須と、「あれば便利」に分け直しましょう。開発会社に「予算◯◯円に収めるとしたら、どの範囲なら作れますか」と聞くのも有効です。

必須と「あれば嬉しい」の仕分けは、最初の相談の段階から準備しておくと、こうした場面で役立ちます（準備のしかたは作りたいシステムを開発会社にどう伝える？初めての発注で準備したい5つのことで紹介しています）。

対処2：段階に分けてリリースする

全部を一度に作るのではなく、「第1段階は必須機能だけで使い始め、第2段階で残りを足す」という進め方もあります。最初の投資を抑えられ、使ってみてから必要な機能を見極められます。

ただし、後から足す機能のために最初の設計で配慮が必要な場合もあります。「段階に分けると、合計費用はどう変わるか」もあわせて聞いておきましょう。

対処3：作り方を変える案を出してもらう

同じ目的でも、作り方によって費用は変わります。たとえば、一部の機能に既存のサービス（SaaS）やパッケージを使う、管理画面は見た目より実用性を優先する、帳票の種類を絞る、といった選択肢です。「目的はこれなので、もっと費用を抑えられる別のやり方はありますか」と相談してみましょう。

対処4：再見積もりの根拠を書面でもらう

最終的に合意する見積もりには、前提条件と「含まれないもの」を明記してもらいましょう。次の段階でまた金額が動いたときに、何が変わったのかを確認するための物差しになります。

対処5：社内の決裁者に「なぜ変わったか」をセットで説明する

社内で予算を取り直す必要がある場合は、「開発会社に言われたから」ではなく、「最初の前提と比べて、この部分が増えた。そのうちこの部分は削れるが、この部分は業務上必要」という形で説明すると、決裁者も判断しやすくなります。視点1・2で作った比較表が、そのまま説明資料になります。

注意したいこと

• 契約前に開発を始めてもらわない：「早く進めたいから」と、金額が決まらないまま開発に着手してもらうと、後で費用の扱いがあいまいになり、トラブルになりやすくなります。IPAのモデル契約書の解説でも、契約締結前の開発着手がトラブルにつながるケースがあることが指摘されています
• 値下げだけを求めて品質や安全性を削らない：テストやセキュリティ対策を削ると、完成後に大きな手戻りや事故につながることがあります。削る対象は「機能の範囲」から考えるのが基本です
• 要件定義を省いて費用を浮かせようとしない：要件定義を軽くすると、そのぶん開発中の仕様変更や追加費用が出やすくなります。要件定義の費用は、後の手戻りを減らすための費用とも言えます
• 増額を一方的に「不当」と決めつけない：まずは前提との差を確認しましょう。説明を聞いたうえで納得できない点が残る場合や、契約上の扱いで判断に迷う場合は、弁護士などの専門家に相談してください

次の発注で「話が違う」を防ぐ3つの備え

最初の見積もりが「どの段階の金額か」を確認する

見積もりを受け取ったら、「これは確定の金額ですか、それとも要件定義の後に変わる可能性のある目安ですか」と聞いておきましょう。目安であれば、どのくらいの幅で動く可能性があるかもあわせて確認します。

社内の予算は「幅」と「予備」を持って取る

最初の見積もりの金額ぴったりで社内の予算を確定させると、少しの増額でも決裁のやり直しになります。要件定義の後に見直す前提で、幅を持たせたり、予備費を確保したりしておくと、慌てずに済みます。

要件定義と開発を分けて契約し、区切りで判断する

要件定義を独立した契約にすると、要件定義が終わった時点で「この金額なら進める」「範囲を絞る」「いったん立ち止まる」を判断できます。区切りごとに判断の機会があることは、発注者にとっての安全装置になります。

発注者がやることチェックリスト

• ☐ 最初の見積もりに書かれていた前提条件（画面数・連携・移行など）を確認した
• ☐ 要件定義で決まった内容と前提条件を並べ、変わった点を洗い出した
• ☐ 増額を機能ごと・工程ごとに分けて説明してもらった
• ☐ 増額のうち、自社の要望で増えた部分を議事録で確認した
• ☐ 要望を「必須」と「あれば嬉しい」に分け直し、予算内に収める案を相談した
• ☐ 段階的なリリースや別の作り方の案を聞いた
• ☐ 合意する見積もりに前提条件と「含まれないもの」が書かれていることを確認した
• ☐ 要件定義書の権利や使い方について、契約書の内容を確認した

開発会社への質問例

• 「最初の見積もりと比べて、どの機能・どの工程で、いくら増えたのかを一覧で見せていただけますか？」
• 「増えた部分のうち、最初の見積もりの前提と違っていたのはどこですか？」
• 「予算を◯◯円に収めるとしたら、どの範囲なら作れますか？後回しにできる機能はどれですか？」
• 「必須機能だけで先に使い始め、残りを第2段階にした場合、合計の費用と期間はどう変わりますか？」
• 「この見積もりは確定の金額ですか？この後の工程で変わる可能性があるのは、どんな場合ですか？」

まとめ：増額は「前提との差」で確かめ、範囲と段階で調整する

要件定義の後に見積もりが変わるのは、システム開発ではよくあることです。最初の見積もりは中身が決まる前の目安であり、要件定義は中身を決めるための独立した仕事だからです。公的なモデル契約でも、工程ごとに契約を分け、要件が明確になった段階で見積もりなおす考え方が示されています。

一方で、増額を黙って受け入れる必要はありません。

• 最初の見積もりの前提条件と、要件定義で決まったことを並べる
• 増額を項目ごとに分けて説明してもらう
• 必須と「あれば嬉しい」の仕分け、段階的なリリース、別の作り方で調整する
• 合意する見積もりに前提条件と「含まれないもの」を書いてもらう

開発の契約を結ぶ前の今は、発注者が選べる手がいちばん多いタイミングです。増額の理由を開発会社と一緒に確かめて、予算と中身のバランスが取れた計画に整えていきましょう。

あわせて読みたい関連記事