要件定義が終わると、見積もりはだいたい増えます

2026年8月25日

「最初の見積もりより、増えています」

システム導入のお手伝いをしていると、この報告を事業者さんと一緒に受ける場面が、何度もあります。

RFPを書いて、何社かに提案していただいて、金額も比べたうえで1社を選んだ。そこまでやったのに増えるというのは、正直なところ、腑に落ちない気持ちも残ると思います。

今日は、その話を書きます。

なぜ見積もりが二段階に分かれるのか

数千万円の規模になってくると、見積もりは要件定義のフェーズと、開発以降のフェーズに分かれて出てくることがほとんどです。

フェーズ	契約と金額の決め方	金額の動き方
要件定義フェーズ	準委任契約（多くは、かかった工数で精算する形）	最初から増減する前提
開発以降のフェーズ	請負契約にすることが多い（要件定義の結果を見て金額を確定する）	当初の概算より上がることが多い

要件定義が準委任になるのは、ベンダーさんが逃げているからではありません。この工程の工数は、事業者さん側の状況で何倍にも変わってしまうからです。

業務の棚卸しがどこまで済んでいるか。今のやり方を説明できる人がいるか。資料が残っているか。それによって、同じ「要件定義」でも中身がまったく違うものになります。ここを固定の金額で請け負ってしまうと、どちらかが必ず無理をすることになる。だから、そうせざるを得ないのです。

ちなみに、この分け方は業界の場当たり的な慣習ではありません。IPA（情報処理推進機構）が公開しているシステム開発のモデル契約でも、要件定義は準委任と位置づけられていますし、見積もりは**「試算」「概算」「確定」と、段階的に精度が上がっていくもの**として整理されています。

つまり、要件定義のあとに金額が変わるのは、事故ではなく設計どおりなのです。

「準委任」には、2つの型があります

もう少しだけ、契約の話にお付き合いください。ここを知っているかどうかで、見積書の見え方が変わります。

準委任には、実は2つの型があります。2020年4月に施行された改正民法で、はっきり分けて書かれるようになりました。

• 履行割合型 — かかった工数（時間）に応じて報酬が決まる形。「増減する前提」と言われるのは、こちらです
• 成果完成型 — 「要件定義書を仕上げること」のように、成果に対して報酬が決まる形。あまり馴染みのない言葉だと思いますが、要件定義でもこの形にすることがあります

成果完成型は請負と似ていますが、同じではありません。請負は完成させる義務を負うのに対して、準委任はあくまで専門家として誠実に進める義務を負う契約です。そのうえで「成果ができたら報酬」という決め方をしているのが成果完成型、と理解していただくとよいと思います。

見積書に「準委任」とだけ書かれていても、どちらの型なのかで、あとから起きることは変わります。契約書を交わす前に、どちらの型なのかは確認しておいてください。

開発以降も、必ず請負とは限りません

もうひとつ。開発以降を請負にするかどうかも、決まりきったものではありません。

先ほどのIPAのモデル契約でも、外部設計は準委任と請負のどちらもあり得るとされていますし、作りながら優先順位を見直していくアジャイル型の進め方に至っては、開発工程も準委任を基本とした契約書が別に用意されています。

ですから「開発は請負にすることが多い」くらいに思っておいて、自分たちの契約がどちらなのかを、その都度たしかめるのがいいと思います。

昔は、増えた分を業者が飲んでいました

私が開発をしていた頃の現場には、増えた工数を業者が泣く泣く持つという空気が、けっこうありました。

一度出した金額は動かせない。でも作業は増える。だから受注する側は、最初からバッファを積んだ金額で見積もるしかありませんでした。使わなければそのまま利益になり、足りなければ持ち出しになる。事業者さんから見れば、何にいくら払っているのか分からない状態です。

その点でいうと、要件定義と開発を分けて進める今のやり方は、かなり健全になったと思っています。分からないものを分からないまま金額に押し込めるのをやめた、ということですから。

裁判の世界でも、ベンダー側の進行管理の責任と、**事業者さん側の「協力する義務」**の両方が認められるようになってきました。どちらか片方が黙って飲む前提ではなくなってきている、ということだと思います。

ただ、それでも当初の予算より増えていく状況自体は、なくなりません。

私自身、何件も支援に入ってきて、なるべく避けようとはしています。それでも完全にきれいに収まったことは、これまで一度もありません。 だからこそ難しいし、だからこそ開発は面白い、という面もあるのですが。

見積もりが増える理由は、だいたい2つです

増える理由を並べていくと、たいてい次のどちらかに行き着きます。

① 返事が遅い

決めていただく事項が止まっている間、ベンダーさんは待つことになります。待っている時間はそのまま工数に乗りますし、後ろの工程も押します。

② 最初に聞いていなかったことが、後から出てくる

「そういえば、この処理は月末だけ違うやり方をしています」「この帳票は取引先ごとに様式が違います」。要件定義の後半や、下手をすると開発が始まってから出てくることがあります。悪気があるわけではなく、毎日やっていることほど、わざわざ説明する対象だと認識されないのです。

どちらも、事業者さん側だけの責任ではありません。ただ、どちらも事業者さん側でしか手を打てない、というのが実際のところです。

ベンダーさんには、はっきり言ってもらってください

私が支援に入ったときに、ベンダーさんへ必ずお願いしていることがあります。

費用が増減しそうな話は、早めに、はっきり言ってください。

「この件、いつまでにご返答をいただけないと、今の見積もりでは対応できなくなります」——このくらい明確に言っていただいて構いません、とお伝えします。

言いにくい気持ちは分かります。お客さまに対して増額の話を切り出すのは、気持ちのいいものではありませんから。けれども、黙って持ち帰ってしまうと、最後にまとめて出てくることになります。そのときの金額のほうが、事業者さんにとってはずっと痛いのです。

途中で言ってもらえれば、事業者さん側にも選択肢があります。急いで決める。今回はやらないと決める。範囲を削る。言われた時点なら、まだ打ち手があります。

事業者さん側は、「宿題」をやりきること

一方で、事業者さん側にも役割があります。ひとことで言えば、決めるべきことを決めることです。

面白いもので、「現状はどうなっていますか」という質問には、みなさんすぐ答えられます。今やっていることですから、当然です。

止まるのは、その次です。**「今後は変えなければいけないのですが、どちらにしますか」**という質問になったとたん、返事が返ってこなくなる。

ここが、プロジェクトがいちばん詰まるところだと思っています。

意思決定の層を、厚くしておく

では、どうするか。私がお勧めしているのは、意思決定の層を厚くしておくことです。

決める人は、少ないほうがいいです。 最終的に判断する人が何人もいると、誰も決めません。

けれども、判断材料を持ってくる人は、何人かいたほうがいい。 現場の実態を知っている人、今のやり方の経緯を知っている人、数字を持っている人。その人たちが材料を揃えて、決める人が判断する。この形になっていると、返事が驚くほど速くなります。

つまり、プロジェクトチームをきちんと作って、体制を整えておくということです。担当者を1人立てて終わり、にしないことだと思います。

通常業務の片手間では、まわりません

もうひとつ、体制の話でどうしても書いておきたいことがあります。

ツールの導入やリプレイスを、通常業務の片手間で進めている方が本当に多いのです。

通常業務をゼロにするのは、現実的ではないと思います。それでも、一部を他の人に渡す、担当を組み替えるといった人員の工夫は、早いうちからやっておいたほうがいいです。

アップアップになってから調整しようとすると、これがかなり大変です。プロジェクトが忙しくなる時期は、たいてい通常業務も忙しい時期と重なりますし、そのときにはもう、引き継ぎの余力すら残っていません。

リソースを割く決断を、始まる前にしておく。 これは費用の話と同じくらい大事だと思っています。

予算は、1.2〜1.3倍で組んでおく

そのうえで、予算の話です。

当初出てきた見積もりの、1.2〜1.3倍。これを確保したうえで予算組みをしておくことを、私はお勧めしています。

多めに見ておくというより、そのくらいは動くものだと最初から織り込んでおくという感覚です。枠さえ取ってあれば、途中で増額の相談が出てきたときに「想定内です」と受け止められます。枠がないと、同じ話が「聞いていない」に変わってしまいます。

ただ、この数字は私が見てきた範囲での目安です。業種や規模、社内の準備の度合いによって変わりますし、これを超えることもあります。数字だけを鵜呑みにせず、見積もりの根拠をベンダーさんに確かめたうえで、最後はご自身の判断で決めてください。

そして、この**「見積もりはどうしても増えがちである」という事実を、いちばん最初の段階でお伝えすること。** これが、私たちのような立場の人間にとって、いちばん重要な仕事のひとつだと思っています。

「ここは上振れしそうだな」は、提案の時点で分かることがあります

私が支援に入っていると、提案書を見た段階で「ここは結構上振れしそうだな」と分かるケースが、けっこうあります。その場合は、その時点でご案内します。

ただ、正直に書いておくと、この見立てが当たっていたかどうかは、本当のところは検証できません。

A社とB社を同時に走らせて比べる、ということはできないからです。実際に見られるのは、通った1社の結果だけ。「あのときB社にしていたら、どうだったのか」は、誰にも分かりません。

それでも、提案の型ごとの傾向のようなものは、何件も見ているとなんとなく分かってきます。確かなことは言えないけれど、傾向としてはこうです——そういうご案内の仕方になります。

見積もりの話は、最後まですっきりとは片づきません。それでも、増えるという事実を最初に共有しておくだけで、同じ増額が「裏切り」ではなく「想定内」に変わります。 私が現場でやっているのは、たぶんその差を作る仕事なのだと思います。

ポイント

• 要件定義が準委任なのは、事業者さん側の準備状況で工数が何倍にも変わるから。 逃げではなく、そうせざるを得ない仕組みです
• 準委任には履行割合型と成果完成型があり、開発以降も必ず請負とは限りません。 自分たちの契約がどちらなのかは、その都度たしかめてください
• 要件定義のあとに開発の見積もりが増えるのは、珍しいことではありません。 きれいに収まった案件を、私はまだ見たことがありません
• 増える理由は「返事が遅い」と「後から出てくる」。 どちらも事業者さん側でしか手が打てません
• ベンダーさんには「いつまでに返事がないと増える」とはっきり言ってもらう。 途中で言われれば、まだ打ち手があります
• 決める人は少なく、材料を持ってくる人は複数。 意思決定の層が厚い会社は、返事が速いです
• 通常業務の片手間にしない。 人員の工夫は、忙しくなる前にやっておきます
• 予算は当初見積もりの1.2〜1.3倍で。 枠があれば「想定内」、なければ「聞いていない」になります（あくまで目安です。最後はご自身の判断で）

システムの入れ替えやRFPの進め方については、RFPの進め方とシステムの入れ替え・導入のページにも書いています。