記事一覧に戻る
費用・見積もり

システム開発の見積もりはどう作られているか|実工数の積み上げと、赤字になる典型パターン

2026年9月4日 約4分で読めます
この記事の結論

システム開発の見積もりは、過去の実工数の蓄積をもとに積んでいます。利益が減る典型は、見積もりに入っていない機能開発をしてしまうことです。予算の絶対額が小さいほど赤字になりやすく、逆に工数が余りそうなときは機能改善を提案しています。

見積書に並んでいる金額が、どういう根拠で出てきたものなのか。発注する側からは、いちばん見えにくい部分だと思います。この記事では、FUNBREWが見積もりをどう作っているか、どういうときに読み違えるのか、そして工数が余ったときに何をしているのかを書きます。開発会社側の内情ですが、知っておくと見積書の読み方が変わります。

見積もりは、過去の実工数から積んでいる

見積もりは基本的に、これまでの案件で実際にかかった工数をもとに積んでいます。機能ごとの定価表があるわけでも、その場の感覚で出しているわけでもありません。似た機能を過去にどれくらいの時間で作ったか、という実績の蓄積が根拠です。

だから、経験のない領域は精度が落ちる

この作り方には裏返しがあります。過去に作ったことのある機能は精度が高く、初めて扱う領域は精度が落ちるということです。開発会社に得意分野があるのは、単に技術の好みの問題ではなく、見積もりの精度そのものが違うからでもあります。

他社が作ったシステムの引き継ぎのように、中身を見るまで規模が分からない案件では、調査を先に行ってから見積もることになります。この考え方は手を入れるより作り直した方が早いと判断するときにも書きました。

バッファーは積まない

見積もりに余裕分を上乗せする、いわゆるバッファーは積んでいません。理由と、その代わりにどう対応しているかは「これは追加費用です」と言われるのはどこからかに書いていますので、ここでは繰り返しません。実工数から積むという方針と、バッファーを積まないという方針は、同じ考え方から来ています。根拠のない数字を金額に入れない、ということです。

読み違えて利益が減る、典型のパターン

見積もりに入っていない機能を作ってしまう

いちばん多いのは、これです。見積もりに無い機能開発を行なってしまうことで利益が減ります。

悪意のある要求で起きるわけではありません。進めるうちに必要性が見えてきたもの、会話の流れで「ついでに」と入ってきたもの、こちらが良かれと思って足したもの——そういうものの積み重ねです。ひとつひとつは小さくても、合計すると見積もりの前提が崩れます。

予算の絶対額が小さいほど、赤字になりやすい

同じ「見積もりから少しはみ出す」でも、影響の大きさは案件の規模によって違います。予算の絶対額が低いほど、赤字になりやすいというのが実感です。

総額が小さい案件では、はみ出した分を吸収する余地がありません。数日分の作業が増えるだけで、案件全体の採算が変わります。規模が小さいほど融通が利かない、という構造がここにあります。この点は小規模なシステム開発で契約書は必要かでも触れています。

工数が余ったら、どうなるのか

そもそも、想定より早く終わることはあまりない

「見積もりより早く終わったら安くなりますか」というご質問をいただくことがあります。正直に書くと、想定より早く終わることはあまりありません。

余りそうなときは、機能改善を提案している

理由は単純で、工数が余りそうな場合には、機能改善などを積極的にご提案しているからです。浮いた時間をそのまま返すのではなく、使い勝手を良くする方向に回しています。

これを聞いて「返金してほしい」と思われるかもしれません。ただ、実際のところ発注側にとっては、同じ金額で完成度が上がることになります。当初の仕様を満たしただけの状態と、細かい使い勝手まで詰めた状態とでは、納品後の満足度が変わります。値引きよりこちらの方が価値がある、と考えています。

もちろん、余った分を別の機能に充てたいというご希望があれば、そのご相談も可能です。何を優先するかは発注側の判断です。

発注側は、見積書のどこを見ればよいか

  • 金額より、含まれている作業の範囲 —— 同じ機能名でも、どこまでやるかで金額は変わります。安い見積もりが手抜きとは限らず、範囲が違うだけということもあります。
  • その会社が経験のある領域かどうか —— 実績のある領域ほど見積もりの精度が高くなります。
  • 調査が必要な案件かどうか —— 既存システムの改修や引き継ぎでは、調査を経ないと確度の高い金額は出ません。最初の金額が概算である場合、その旨が説明されているかを見てください。
見積書で気になる項目があれば、遠慮なく「これは何の作業ですか」と聞いてください。実工数から積んでいるので、その項目が過去のどういう作業に相当するのかは説明できます。説明できない項目が入っている見積書は、どの会社のものであれ確認した方がよいと思います。

まとめ

FUNBREWの見積もりは、過去の実工数の蓄積をもとに積んでいます。定価表も、感覚での上乗せもありません。そのため、経験のある領域ほど精度が高く、初めて扱う領域や中身を見るまで規模が分からない案件では、調査を挟むことになります。

利益が減る典型は、見積もりに入っていない機能開発をしてしまうことです。特に予算の絶対額が小さい案件では、はみ出した分を吸収する余地がないため、赤字になりやすくなります。

逆に工数が余りそうなときは、機能改善を積極的にご提案しています。同じ金額で完成度を上げる方が、値引きより価値があると考えているためです。お見積もりのご相談はお問い合わせよりどうぞ。

よくある質問
システム開発の見積もりは、何を根拠に作られているのですか。
FUNBREWでは、これまでの案件で実際にかかった工数をもとに積んでいます。機能ごとの定価表があるわけでも、その場の感覚で出しているわけでもなく、似た機能を過去にどれくらいの時間で作ったかという実績の蓄積が根拠です。
開発会社に得意分野があるのはなぜですか。
見積もりの精度が違うためでもあります。過去に作ったことのある機能は実績から積めるため精度が高く、初めて扱う領域は精度が落ちます。既存システムの引き継ぎのように中身を見るまで規模が分からない案件では、調査を経てから見積もることになります。
開発会社が赤字になるのはどういうときですか。
見積もりに入っていない機能開発をしてしまうときです。進めるうちに必要性が見えたもの、会話の流れで入ってきたものの積み重ねで前提が崩れます。特に予算の絶対額が小さい案件では、はみ出した分を吸収する余地がないため赤字になりやすくなります。
見積もりより早く終わったら、費用は安くなりますか。
想定より早く終わることはあまりありません。工数が余りそうな場合には機能改善などを積極的にご提案しているためです。値引きではなく、同じ金額で完成度が上がるという形になります。別の機能に充てたいご希望があれば、そのご相談も可能です。
見積書のどこを見ればよいですか。
金額そのものより、含まれている作業の範囲です。同じ機能名でもどこまでやるかで金額は変わるため、安い見積もりが手抜きとは限らず範囲が違うだけということもあります。気になる項目は「これは何の作業か」と確認してください。

この記事をシェア

お見積もりのご相談

含まれる作業の範囲まで含めてご説明します。概算の段階からご相談いただけます。

最新情報をお届けします

IT活用のヒントやお役立ち情報を定期的にお届けします。

あわせて読みたい

「費用・見積もり」に関連する記事です。

まとめ記事

【2026年版】システム開発の費用相場まとめ|種類別・規模別に徹底解説

関連記事

費用・見積もり
2026年9月4日

値下げを受け入れた開発会社に何が起きたか|相見積もりで安くさせた先にあるもの

相見積もりで値下げを受け入れた結果、開発会社側で何が起きたのか。工数が苦しくなり最上の提案ができなかったという自社の経験から、発注側が価格差をどう見ればよいかを書きました。

費用・見積もり
2026年9月4日

システム開発の支払いはなぜ着手金から始まるのか|3回に分ける理由と、止まった案件のその後

システム開発の支払いを着手・中間・完了の3回に分ける理由と、開発会社が工数を先に持ち出すという構造。そして途中で止まった案件がほとんど再開されないという実際を、開発会社側から書きました。

開発
2026年8月26日

見積もりを何パターンも依頼する前に|開発会社が見積もりを作るときにしていることと、詰めすぎた見積もりの落とし穴

条件を変えた見積もりを何本も依頼すると、開発会社は無償で要件定義を進めることになります。見積もりの精度がどう決まるのか、詰めすぎた見積もりが発注側にどう跳ね返るのかを解説します。

システム開発
2026年4月30日

システム開発の着手金ガイド|相場・支払いタイミング・トラブル防止の注意点

システム開発の着手金(先払い)の相場は開発費の30〜50%が目安。支払いタイミング・分割パターン・トラブル防止のポイントを発注者向けに解説します。

相談のハードル、下げました

まずは気軽にご相談ください

「まだ具体的に決まっていない」「とりあえず話を聞きたい」でも大丈夫。プロトタイプを見ながら、一緒にアイデアを形にしていきましょう。

相談無料 オンライン対応 1週間でプロトタイプ