システム開発見積もりの読み方：人月商売の罠と正しい発注術

概要

「システム開発の見積もりが来たが、妥当かどうかわからない」「なぜこんなに高いのか、説明を聞いても納得できない」——こうした悩みを持つ社長は多いです。見積書には専門用語が並び、金額の根拠が不透明。この記事では、システム開発の見積書の読み解き方と、騙されないためのポイントをお伝えします。

システム開発の見積もりはなぜわかりにくいのか

そもそも、なぜシステム開発の見積もりはわかりにくいのか。

理由1：「人月」という謎の単位

システム開発の見積もりでは、「人月（にんげつ）」という単位が使われます。

1人月 = エンジニア1人が1ヶ月働く工数
単価は80万〜150万円が相場

「5人月」と書かれていたら、400万〜750万円。

でも、なぜ5人月なのか、根拠がわからない。

理由2：作業内容が抽象的

見積書に書かれている作業内容は、こんな感じです。

要件定義：1.5人月
基本設計：2人月
詳細設計：2人月
開発：5人月
テスト：2人月
導入・移行：1人月

それぞれの内訳が書かれていても、何をどれだけやるのかがイメージできない。

理由3：比較ができない

見積もりを複数社に取っても、項目の分け方が違う。

A社は「設計」と「開発」を分けているが、B社は「製造」で一括。金額を単純に比較できません。

見積書を読み解く3つのポイント

騙されないために、見積書のここを見てください。

ポイント1：人月単価をチェックする

まず、人月単価を確認します。

見積書に「5人月 × 100万円 = 500万円」と書かれていれば、単価は100万円。

相場との比較：

エンジニアのレベル	人月単価の相場
ジュニア（経験1〜3年）	60万〜80万円
ミドル（経験3〜7年）	80万〜120万円
シニア（経験7年以上）	120万〜150万円
PM・コンサルタント	150万〜200万円

単価が相場から大きく外れていたら、理由を確認しましょう。

ポイント2：工数の根拠を質問する

「なぜ5人月なのか」を質問してください。

良い回答： 「この機能はこれくらいの複雑さがあり、過去の類似案件から見積もると○人月です」

悪い回答： 「経験則です」「こんなものです」

根拠を説明できない見積もりは、信用できません。

ポイント3：「バッファ」の有無を確認する

多くの見積もりには、「バッファ（余裕）」が含まれています。

これ自体は悪いことではありません。不確実性があるプロジェクトでは、バッファは必要。

問題は、バッファが明示されていないこと。

「実際には3人月で終わるが、リスクを見込んで5人月で見積もる」——これが隠されていると、発注側にはわかりません。

質問すべきこと： 「この見積もりに、バッファ（予備費）は含まれていますか？」

人月商売の構造的な問題

ここで、人月商売の構造的な問題をお伝えします。

問題1：時間をかけるほど儲かる

人月商売では、工数が増えるほど開発会社の売上が増えます。

効率的に終わらせる → 売上が減る
時間をかける → 売上が増える

インセンティブが逆なのです。

もちろん、すべての開発会社が意図的に工数を膨らませているわけではありません。でも、構造的に「効率化する動機が弱い」のは事実です。

問題2：成果に責任を持たない

人月商売では、「○人月働きました」が成果物です。

システムが現場で使われるか、ビジネスに貢献するかは、契約上の責任範囲外。

**「納品したら終わり」**という構造が、使われないシステムを生み出します。

問題3：見積もりと実績の乖離

見積もり時点では、正確な工数はわかりません。

結果、

見積もりより早く終わる → 開発会社は追加提案して工数を埋める
見積もりより遅れる → 「追加費用が必要」と言われる

どちらにしても、発注側が損をする構造です。

こんな見積もりには要注意

具体的に、注意すべき見積もりのパターンを紹介します。

要注意1：「一式」が多い

「開発一式：500万円」

内訳がなく、「一式」でまとめられている見積もりは危険。何が含まれているかわかりません。

要注意2：項目が細かすぎる

逆に、項目が細かすぎる見積もりも注意。

○○機能の設計：0.3人月
○○機能の開発：0.5人月
○○機能のテスト：0.2人月
△△機能の設計：0.4人月
……（延々と続く）

細かく見せることで「ちゃんと計算している」感を出していますが、実際には合計を決めてから逆算していることも。

要注意3：「お値引き」が大きい

定価：800万円お値引き：△200万円 お見積額：600万円

大幅な値引きは、最初から高く設定している可能性があります。値引き額ではなく、最終金額の妥当性で判断してください。

要注意4：保守費用が不明確

開発費用だけでなく、保守費用も確認してください。

月額保守費：○万円
障害対応：別途
機能追加：都度見積もり

「保守費用を払っているのに、何かあるたびに追加請求される」というトラブルは多い。何が含まれて、何が含まれないのか、明確にしておきましょう。

正しい発注の仕方

では、どうすれば正しく発注できるのか。ポイントを整理します。

ポイント1：複数社に見積もりを取る

最低3社には見積もりを取りましょう。

比較することで、相場感がわかります。

ただし、金額だけで選ばないこと。対応の速さ、コミュニケーションの質、提案の有無も重要な判断材料です。

ポイント2：「何を実現したいか」を伝える

「こういうシステムを作ってほしい」ではなく、「こういう課題を解決したい」「こういう状態を実現したい」と伝えてください。

手段ではなく、目的を伝える。

そうすれば、開発会社から「それならこういう方法もありますよ」という提案が出てきます。

ポイント3：成果にコミットしてくれるか確認する

「納品したら終わり」なのか、「成果が出るまで伴走してくれる」のか。

これは大きな違いです。

質問してみてください。「システムが現場で使われなかったら、どうなりますか？」

ポイント4：小さく始められるか確認する

いきなり大きな投資をするのはリスクが高い。

「まず小さく始めて、うまくいったら拡大する」ができるかどうか、確認してください。

BANSOU CTO™の料金体系との比較

最後に、人月商売とBANSOU CTO™の料金体系を比較します。

項目	人月商売	BANSOU CTO™
課金方式	工数（人月）× 単価	月額 + レベニューシェア
成果責任	なし（納品で完了）	あり（収益化まで伴走）
インセンティブ	工数を増やすほど儲かる	成果を出すほど儲かる
初期費用	数百万〜数千万円	月5万円 × 2ヶ月
追加開発	都度見積もり	月額に含む
リスク	発注側が負う	双方で分担

BANSOU CTO™のメリット

成果にコミット：レベニューシェアだから、成果を出すインセンティブがある
初期費用が安い：最初の2ヶ月は月5万円だけ
追加開発込み：「ちょっとした修正」で追加請求されない
リスク分担：成果が出なければ、私たちの報酬も少ない

まとめ：見積もりの「根拠」を確認せよ

システム開発の見積書を見たら、以下を確認してください。

人月単価は相場と比べてどうか
工数の根拠を説明できるか
バッファは含まれているか
保守費用は明確か
成果にコミットしてくれるか

「なんとなく高い気がするけど、よくわからない」——その直感は正しい可能性があります。

わからないことは、質問してください。

説明できない見積もりは、信用できません。

次に取るべきアクション

「見積もりを取ったが、妥当かどうか判断できない」

そんなとき、セカンドオピニオンとしてご相談ください。

30分の無料相談で、見積もりの妥当性を一緒に検討します。

株式会社IIWAYO｜BANSOU CTO™ 社長の思考を、収益を生む仕組みに変える。