3社から見積もりを取った。A社300万、B社200万、C社150万。稟議を通しやすいのはC社だ。社内の決裁ラインにも収まる。「同じものを作るなら安いほうがいい」。その判断は一見合理的に見える。
ただ、僕がこれまで見てきた中で、最初の見積もりが安かったプロジェクトほど、最終的な支出が膨らむケースが多かった。安い見積もりには安い理由があって、その理由が後からコストとして返ってくる。
安い見積もりの構造を理解する
見積もりが安い理由は、大きく3つに分かれる。
ひとつ目は、要件の解像度が低いまま概算を出しているケース。「だいたいこのくらいでできます」という見積もりは、着手してから追加費用が発生しやすい。150万で始まったプロジェクトが、追加要件と仕様変更で250万になるのは珍しくない。
ふたつ目は、工数を削るために品質を犠牲にしているケース。テストを省略する、セキュリティ対策を後回しにする、コードの保守性を考えない。短期的にはアウトプットが出るけれど、運用が始まってからバグ対応や改修に手間がかかる。年間の保守費用が開発費の20-30%に達することもある。
みっつ目は、経験の浅い技術者をアサインしているケース。人件費が安い分だけ見積もりも安くなるけれど、開発期間が延びたり手戻りが増えたりして、結果的に工数が膨らむ。
どのパターンでも、最初の見積もりが安いだけで、プロジェクト全体の支出は安くならない。
「使われないシステム」の隠れコスト
見積もりの話よりもっと深刻なのは、作ったけど使われないシステムの問題だ。
中小企業庁の調査によると、導入したITシステムを十分に活用できていない企業は40%を超える。300万円で作ったシステムが使われなければ、300万円のサンクコストに加えて、月々のサーバー代、保守契約、そしてスタッフが二重管理を強いられる時間コストが積み上がっていく。
なぜ使われないか。多くの場合、開発前の段階で「本当にこれが必要か」の検証が足りていない。仕様書と見積もりだけで進めて、完成品を見てから「思ったのと違う」と気づく。でも、もう300万円は支払い済み。使い続けるか、追加費用をかけて改修するか、あるいは別のシステムに乗り換えるか。どの選択肢もコストがかかる。
費用対効果を測るときの3つの視点
システム開発のコストを正しく評価するには、見積もり金額だけでなく、3つの視点で見る必要がある。
まず、トータルコスト。初期開発費だけでなく、1年目のサーバー費用、保守費用、社内の運用人件費を含めた年間の総支出を計算する。150万のシステムでも、保守に月5万、サーバーに月2万かかれば年間84万の追加支出が発生する。3年で見れば150万+252万=402万になる。
次に、削減できるコスト。今の業務にかかっている人件費や外注費がどれだけ減るか。月に20時間のExcel作業を自動化できるなら、時給換算で年間60-80万円の削減になる。
最後に、機会損失。システムがないことで逃している売上や、対応できていない顧客がいるなら、その金額も判断材料に含める。ここは正確な数字が出にくいけれど、「売上の何%に影響しうるか」というレベルで見積もるだけでも判断の質が変わる。
この3つを並べたとき、「安い見積もり」を選ぶことが本当に合理的なのか。多くの場合、答えはNoだと思う。
「高い」が正解とも限らない
誤解してほしくないのは、「高い見積もりなら安心」という話ではないこと。高い見積もりにも、不要な工数が含まれていたり、過剰な技術選定をしていたりするケースはある。
金額の高低ではなく、「何にいくらかかっているか」の内訳が明確かどうかが判断基準になる。見積もりを受け取ったら、次の4点を確認してみてほしい。
工数の内訳が機能ごとに分かれているか。テストやセキュリティ対策の工数が含まれているか。追加費用が発生する条件が明記されているか。保守運用の費用と範囲が記載されているか。
この4点が曖昧な見積もりは、金額に関係なく避けたほうがいい。
本投資の前にリスクを分散する
ここまで書いてきた問題の多くは、開発に着手する前の段階で軽減できる。やり方は単純で、本開発の前にプロトタイプを作ることだ。
7日間で動くデモを作って、実際に触ってみる。「この機能は確かに必要だ」「こっちは思ったほど使わないかもしれない」。そういう判断を、10-20万円のデモ費用で得られる。300万円を一括で投じるのと、まず20万円で検証してから残り280万円を判断するのとでは、リスクの構造がまったく違う。
安い見積もりに飛びつくのでもなく、高い見積もりを鵜呑みにするのでもなく、判断の精度を上げるために小さな検証を先に入れる。それが「安物買いの銭失い」を避ける、一番確実な方法だと僕は考えている。