naisei.dev › システム開発の見積が高すぎると感じたら

システム開発の見積が
高すぎると感じたら

業務システムの開発を相談したら、見積が数百万円で返ってきた。 規模感が分からず、この金額が妥当なのか、何を削れば下がるのかも判断できない。 そういう状態の方向けに、金額がどう積み上がっているのかと、 見積書のどこを見れば判断できるのかを整理しました。

なぜ数百万円になるのか

システム開発の見積は、ほとんどの場合「何人が、何ヶ月関わるか」で決まります。 機能の数や画面の数から直接計算されているわけではありません。

国内の受託開発では、技術者1人が1ヶ月作業する単価（人月単価）が おおむね80万〜150万円程度で見積もられることが一般的です。 会社の規模や技術者の階層によって上下します。

つまり、2人が3ヶ月関わる規模の案件なら、それだけで500万〜900万円になります。 この数字は理不尽なものではなく、人件費・社会保険・オフィス費用・営業費用・ 案件が想定通りに進まなかったときのリスク分を積み上げた結果です。

見えにくいが、確実に工数を食っているもの

発注側が「画面を作るだけでしょう」と考えている部分の外側に、実際の工数の大半があります。

• 要件定義。何を作るかを決める打ち合わせと文書化。ここだけで全体の2〜3割を占めることがあります
• テスト。正常に動くかだけでなく、想定外の操作をされたときに壊れないかの確認。実装と同等の工数がかかります
• ドキュメント。設計書・操作マニュアル・引き継ぎ資料
• プロジェクト管理。進捗管理・会議・報告。これも人月として計上されます
• リスクバッファ。仕様変更や想定外の事態に備えた余裕。見積に含まれていなければ、後から追加請求という形で現れます

見積書で最初に見るべき3か所

総額だけを見ても判断できません。次の3点を確認すると、その見積が何を意味しているのかが見えてきます。

1. 工数（人月）と単価が分かれて書いてあるか

「一式 450万円」としか書かれていない見積は、比較も交渉もできません。 「何人が何ヶ月」と「1人月あたりいくら」が分かれていれば、 削るべきなのが工数なのか単価なのかを判断できます。

分かれていない場合は、内訳の提示を依頼してください。断られるなら、それ自体が判断材料になります。

2. 保守費が年額でいくらか

ここが最も見落とされます。初期費用に目が行きますが、 保守費は毎年かかり続けます。

一般的には初期費用の10〜20%程度が年額の保守費として設定されます。 初期500万円なら、年50〜100万円。5年で250〜500万円です。 つまり5年総額で見ると、初期費用と同じくらいの金額が保守に乗ってきます。

そして確認すべきなのは金額そのものより、その保守費で何をしてくれるのかです。

• 障害が起きたときの復旧だけか、機能追加も含むのか
• OSやライブラリの更新対応は含まれるか
• 問い合わせの応答時間はどの程度か
• 年に何時間まで、といった上限があるか

3. 追加開発の単価

運用を始めれば、必ず「ここを直したい」が出てきます。 そのときの単価が決まっていないと毎回見積もりからやり直しになり、 小さな改修が数十万円になって、結局手を付けられなくなります。

「軽微な変更は保守費の範囲内」の線引きがどこにあるかを、 契約前に具体例で確認しておくことをおすすめします。

「高い」と感じる原因は3種類ある

同じ「高い」でも、原因によって打ち手がまったく違います。

A. 予算とのズレ

見積は妥当だが、こちらが出せる金額と合っていない状態です。 この場合、値引き交渉をしても限度があります。 削るべきなのは金額ではなく、作る範囲です。

B. 要件が膨らんでいる

打ち合わせの中で「あれもできたらいい」が積み重なり、 本来の目的から離れた機能まで見積に入っている状態です。 これが一番よくあり、そして一番削れます。

「これが無いと業務が回らない機能」と「あったら便利な機能」を分けて、 後者を全部外した見積を出し直してもらってください。 半分近くまで下がることがあります。

C. 相場を知らない

実は妥当な金額なのに、比較対象がないので高く感じている状態です。 この場合は相見積もりを取るのが唯一の解決策です。 ただし、各社に同じ条件を渡さないと比較になりません。 要望をまとめた1枚を作って、同じものを配ってください。

削れるもの・削れないもの

テストと要件定義を削ると、その分は必ず後から運用のトラブルとして返ってきます。 削減の交渉をするなら、機能の数を減らす方向でお願いするのが健全です。

発注を見送った方がいいサイン

• 要件をほとんど聞かれないまま見積が出てきた。何を作るか決まっていないのに金額が出るのは、後から追加請求になる前提か、テンプレートを当てはめているかのどちらかです
• 「何でもできます」と言われる。できないこと・向かないことを説明しない相手とは、後で揉めます
• ソースコードの権利が発注側に来ない。契約書を確認してください。権利が渡らないと、その業者以外は改修できなくなります
• 保守費の内容が「別途相談」のまま。運用開始後に主導権を失います
• 引き継ぎ資料が見積に含まれていない。担当者が変わった瞬間に、誰も触れないシステムになります

それでも予算に合わないときの選択肢

作る範囲を絞って、段階的に進める

一番おすすめできる方法です。 一番困っている業務ひとつだけを先に作り、動かしてみてから次を考えます。 全体を一度に設計すると、使われない機能に金額を払うことになりがちです。

既製のサービスで足りないか、もう一度確認する

標準的な業務であれば、月数万円のサービスで済む可能性があります。 開発を検討する前に、「既製品では何が足りないのか」を具体的に書き出してみてください。 書き出せないなら、まだ既製品で足ります。

内製化する

AI開発ツールが実用になったことで、以前より現実的な選択肢になっています。 ただし万能ではありません。向いている条件はかなり限定的です。

向いている場合

• 業務の独自ルールが多く、既製品に合わせると運用が壊れる
• 社内に、自分たちの業務を言語化できる人がいる
• 作った後も少しずつ変えていきたい
• 月額固定費を長期的に減らしたい

向いていない場合

• 標準的な運用で足りている（素直に既製サービスを使う方が安く、速く、安全です）
• 社内に誰も面倒を見る人がいない
• 止まると即座に困る業務で、24時間のサポート窓口が必要
• すぐに使い始めたい（内製でも設計と実装の時間はかかります）