コードを書けないSIerのための簡易で高精度な開発工数見積もり法
この記事では公共やインフラ系大企業の総予算1億～10億程度のシステム開発の現場を見てきた私が自分のために使っている「Solufa式開発工数見積もり法」を紹介します。顧客に提出する正式資料ではなく、開始時点でそのプロジェクトがどの程度予算や納期を超過するかをわずかな手間で予測するために役立ちます。
大規模開発になるほど見積もりはズレる、しかも悪い方に
ベストセラー書籍「BIG THINGS」によると大規模システム開発では
- 予算か納期を超過：91.5%
- そのうち、予算が50%以上超過：18%
- 予算が50%以上超過した場合の平均超過率：447%
こんなに見積もりを外してなぜ経営が成立するかというと、大企業は開発で出した赤字を運用で取り戻す「プリンター・トナー方式」みたいな稼ぎ方が出来るからです。あるいは大昔に構築した自治体や社会の基幹システムが生み出す莫大な運用利益を新規プロジェクトに投資して節税や配当抑制しているケースもあります。
とはいえ、クラウドやAIなど時代の変化に伴って運用で出せる利幅が減り、大手SIerも開発時点から利益を出す高ROI経営が求められるようになってきたのを感じているはずです。PMに選ばれたあなたも、出来れば自分のプロジェクトで予算超過・納期延長・品質未達は避けたいでしょう。
その最初の関門が受注時点での見積もり書作成です。かつてはどの案件でも分厚い詳細設計書を作る部署があって緻密な見積もりを作っていたようですがWebの発展で案件数自体が爆増したことと、アジャイル開発の悪いところだけ取り込んだキメラ型ウォーターフォールの流行により設計・開発の経験がないプロパーが少人数で要件定義・設計・見積もりを行わざるを得なくなったと私は分析しています。
受注時点でプロジェクトの失敗が確定する原因を分解しましょう。
1番の原因は、外した見積もりを前例としてまた使うこと
社内の過去プロジェクトの資料を探してきてそれをテンプレートにしていませんか？そしてその過去資料は実績値による補正がない受注時点でのデータのままになってませんか？見積もりを外したプロジェクトの見積もりをテンプレートにしたらまた失敗するのは当然です。でも実績値は社内共有ストレージのプロジェクトごとにバラバラな深い階層に埋もれていて集計が困難だからどうしようもありません。
2番目の原因は、システムの複雑さに関係なく総予算が決まっていること
要件定義して、設計して、見積もりを顧客に提出して交渉し受注金額が決まる、という当たり前に見えるフローは「PoC」とか「今回はアジャイルで」みたいな単語が出る案件ではほぼ確実に成立しません。客先担当者の決裁権限や自治体の予算などシステムに直接関係ない要因で受注金額が最初に決まるのです。数千億円で超巨大だとか、ミッションクリティカルな案件はさすがに違うかもしれませんが私は直接見たことがないのでわかりません。
予算が先に決まっている場合の見積もりは雑になりがちで、前例の見積もりを参考に総予算からクラウドなどの固定費を引いたあと、実装する機能の難しさの比率を決めて工数を割り当てます。決済は一番難しいから15、ログインは社内フレームワークそのまま使えるから2、みたいな係数を出して残った予算を配分するだけ。月100万とかで割れば人月数も出ます。
3番目の原因は、「時間さえあれば一人で作れる」レベルの技術者が関与しないこと
コードを書けないプロパーでも、大抵みな応用情報くらいは持っていてさらに外部からコンサルを一人入れて要件定義から見積もりの作成をするパターンが王道でしょう。最近はAIを使えるし、内々で決まっている外注先企業（協力会社というのが正しい）にも手伝ってもらえます。
それでも見積もりを外す理由は、コンサルや協力会社のエンジニア含めて誰も自力で作れないせいで機能が一つ増えるごとのコミュニケーションコストと連結複雑度を想像できないからです。日本人しか使わないシステムでも顧客や営業は気軽に多言語対応を追加しますがそれに対して見積もり作成チームは解像度の高い反論ができません。AIに聞いても正しい問いを立てられないので出力されるのは一般論だけです。
大勢で緻密な詳細設計や見積もりを作らなくなり、仕様が刻一刻と変化するキメラ型ウォーターフォールで未来を見通すには「最悪自分一人で全部作ればいいか」と腹を括れるレベルのエンジニアが必要なのです。しかしそんな人材はあなたの手札にありません。
経験者に5分雑談をするだけで精度が上がるSolufa式実績人数面積見積もり法
ここで紹介するのは、過去の見積もり書ではなく「実際にプロジェクトにいた人数」をベースにする方法です。正式な資料は全く保守されてないか都合よく編集されるため信頼できませんが、それに比べたら人の記憶ははるかに正確です。「あのとき何人くらいいた？」という質問には資料より実態に近い答えが返ってきます。
手順1：似ているプロジェクトの経験者を探す
まずアプリ側（フロントエンド/バックエンド）とインフラ側それぞれで、ざっくり以下の観点で構成が似ている社内の過去プロジェクトを特定します。
- 業務ドメイン（ECなのか業務システムなのか等）
- 技術スタック（クラウド環境、フレームワーク）
- 外部連携の数（決済、認証、他システム連携）
- ユーザー規模感
高精度で一致する案件はないので体感で6〜7割似ていれば十分です。
手順2：時系列で「そのときチームに何人いたか」を聞く
そのプロジェクトに最初から最後まで関わっていた人を2〜3人見つけて雑談の流れでヒアリングしてください。
「プロジェクトの開始から終わりまで、だいたい何月頃に何人くらいチームにいましたか？覚えている範囲でいいです」
調査して後日返答してもらうと資料を参照されて逆に精度が落ちるので、5分程度の雑談で聞き出せた情報で十分です。可能なら工程ごとの人数を聞けると集計時に補正しやすいです。
手順3：グラフにプロットして面積を計算する
横軸を月数、縦軸を人数として聞き取った情報をプロットします。複数人から聞いた場合は中央値を取ります。5〜10点あれば十分です。
人数
12 |
10 | ●───●
8 | ／ ＼
6 | ／ ●───●
4 | ● ＼
2 | ／ ●
0 |●────────────────────────────
0 2 4 6 8 10 12 14 16 18 (月)
点を直線で繋いでグラフの下の面積を計算します。長方形と三角形に分割して足し合わせるだけで面積がそのまま「総人月数」になります。
上の例だと、ざっくり計算して約120人月といった具合です。
手順4：アプリとインフラで分けて積算する
アプリ側とインフラ側では人月単価や人数の推移カーブが違うでしょう。
- アプリ側：中盤に増えて、納期後もピークが延長されやすい（開発とテストが並行しがち）
- インフラ側：初期と末期に山ができやすい（環境構築と本番移行）
それぞれ別々にヒアリングしてグラフを作り、単価を掛けて合算します。
アプリ側：80人月 × 100万円 = 8,000万円
インフラ側：40人月 × 120万円 = 4,800万円
手順5：固定費を加算して総額を出す
クラウド利用料、ライセンス費用、外部サービス利用料などの固定費は過去プロジェクトの資料から引用します。これは見積もり書でも実績でも大きくは変わらないはず。
人件費：12,800万円
固定費：2,200万円（AWS、SaaS連携等）
─────────────────
合計：15,000万円
なぜこの方法で精度が上がるのか
見積もり書ではなく実績を使っている
過去の見積もり書は「こうなるはずだった」という願望です。一方「実際に何人いたか」は結果です。炎上して人を追加投入した事実も想定より少なく済んだ事実も、すべて反映されています。
記憶は「実働」を反映する
正式な工数管理では「0.5人月アサイン」と書かれていても実際にはフルコミットしていたり、逆にほとんど稼働していなかったりします。人の記憶に残っているのは書類上の数字ではなく実際に一緒に働いていた人数です。
複数人に聞くことでバイアスが減る
一人の記憶には偏りがあります。開発者は開発フェーズを詳しく覚えていて、PMは全体を俯瞰して覚えている。複数人の証言を重ねることでより実態に近い数字が浮かび上がります。
この見積もりの使い方
この方法で出した数字は根拠を説明できないから顧客に提出する正式見積もりには使えません。しかしPMとして受注前に「このプロジェクトは本当に予算内で終わるのか」を判断するための物差しにはなります。
- 正式見積もり：1.2億円
- Solufa式見積もり：1.5億円
- 差分：3,000万円（25%超過の可能性）
この差分が見えていれば受注交渉の段階でスコープを調整したり、リスクバッファを積んだ提案ができます。それでも世の中には炎上を防げない案件であふれていますが、結末が見えている分早期から覚悟を決めてトータルダメージを減らせるはずです。
まとめ
- 過去の「見積もり」ではなく「実績人数」を前例にする
- 経験者に「何月頃に何人いた？」と聞くだけ
- グラフにして面積を出せば総人月になる
顧客や上司に提出する見積もり書は前例を踏襲して無難にこなし、自分が指針とする資料にSolufa式を使うと良いでしょう。91.5%が失敗する世界で、あなたのプロジェクトが残り8.5%に入るための第一歩です。
Discussion