システム開発の外注見積を読む——内訳で確かめる工程と前提条件

人月単価を横に並べて比べる。外注先を選ぶとき、多くの発注側がまずそこから始める。しかし、単価が安い方を選んだはずなのに、完成してから総額が想定を大きく上回っていたという経験は珍しくない。問題は、見積の「内訳」を読まずに「単価」だけを比べることにある。

人月単価が同じでも総額が変わる理由

単価が同じ2社の見積でも、含まれる工程の範囲が違えば総額は変わる。よくある例を挙げると次のようなものだ。

• 要件定義工程が別費用として切り出されている
• テスト工程（単体・結合・UAT）のどこまでを含むか明示されていない
• プロジェクト管理費が「管理工数○人月」として別項目になっている
• 本番環境へのリリース・切り替え作業が含まれていない

発注側が「開発」と思っている範囲と、受注側が見積に含めた範囲がずれていることは多い。前提の食い違いが、後から追加費用として積み上がっていく。

「安い見積は、工程を狭く切り取った見積かもしれない」という視点を持つと、内訳の読み方が変わる。

内訳で確かめる三つの工程

見積書を受け取ったとき、少なくとも次の三つが独立した項目として明示されているかを確認したい。

要件定義　開発工程の前に、何を作るかを固める工程だ。ここが含まれていない見積は、要件が曖昧なまま開発が始まるか、後から別途費用が発生することを意味する。要件の整理を発注側が担う前提になっている場合は、社内でその工数を確保できているかを先に確かめておく必要がある。

テスト工程　単体・結合・ユーザー受け入れテスト（UAT）の区別があるかを見る。UATを発注側が担う前提の見積もある。その場合、社内の工数が別途かかる。規模の大きい案件ではテスト設計書の作成まで含まれているかどうかも、確認しておきたいポイントになる。

プロジェクト管理　進捗管理・報告・調整の工数。「PM込み」なのか「開発者が兼務する前提」なのかで、プロジェクト運営の質に差が出やすい。この工程が見積に含まれていない場合、実質的に発注側がPM役を引き受けることになる。情報システム担当の有無によってそのリスクの大きさが変わる点については、情シスをアウトソースするとき——常駐・非常駐の違いと、社内に残す仕事でも整理している。

複数社の見積を比べるときの視点

2社以上から見積を取る場合、工程の範囲と前提条件を揃えることが先決になる。確認すべき軸を挙げると次のようになる。

1. 開発の開始点（要件定義から始まるか、設計から始まるか）
2. テストの最終工程（UATまで含むか、単体テストのみか）
3. 本番リリース・切り替え作業の有無
4. 保守・運用の取り扱い（契約に含まれるか、別契約か）

これらが揃っていない状態で金額を比べても、安い方が本当に安いかどうかは判断できない。揃っていない部分は担当者に確認を取り直してから比較した方が、後から調整が少ない。

プロジェクトの規模が大きくなるほど、この「前提の確認」に時間をかける意味が増す。基幹システムの刷新のような案件では、見積を比べる前段階として要件整理に別途コストをかけることもある。その判断基準については基幹システム刷新でコンサルを使うかどうかに整理した。

---

見積の内訳を読む作業は、単価の比較よりも地味で手間がかかる。しかし、外注後に「想定外のコスト」として問題が浮上するのは、たいてい内訳を確認せずに発注を進めた案件だ。発注前に内訳の読み合わせをする時間を取ることが、後工程の摩擦を減らす。外注の範囲と社内の役割分担を最初に明確にすることが、結果として費用の見通しを安定させる。工程の切り分けから整理したい場合は、しぼるのようなDX伴走支援を活用する選択肢もある。