運用保守の仕事をしていると、「見積」を作る場面が出てきます。
新しい作業の工数見積、追加案件の見積、リプレースプロジェクトの見積——。特にリーダーや責任者の立場になると、見積の精度が、プロジェクトの成否やチームの負担を大きく左右します。
そして、この見積、失敗すると影響が大きい。見積を誤ると、チームが疲弊し、赤字になり、品質が落ちます。
私は19年の運用保守の中で、たくさんの見積を作り、失敗も経験してきました。今回は、その経験から学んだ「見積で失敗しないための考え方」を解説します。
見積が失敗する典型パターン
まず、見積が失敗する典型的なパターンを見ておきましょう。
1. 楽観的すぎる
「これくらいでできるだろう」と、うまくいく前提で見積もってしまう。実際には想定外のことが起きて、工数がオーバーする。
2. 「見えない作業」を見落とす
実作業だけを見積もって、準備、確認、調整、報告といった「見えない作業」を計算に入れない。結果、想定より時間がかかる。
3. テストや余裕を削る
スケジュールや予算に合わせるために、テスト工数やバッファを削ってしまう。これが、後で品質問題や炎上を招く。
4. 過去の実績を踏まえていない
「今回はこれくらい」と勘で見積もり、過去の似た作業の実績を参照しない。だから、毎回見積がぶれる。
これらを避けることが、精度の高い見積への道です。
考え方①：「見えない作業」を必ず計算に入れる
見積で最も見落としがちなのが、**「見えない作業」**です。
作業には、実際に手を動かす「見える作業」の他に、たくさんの「見えない作業」があります。
- 事前準備（環境確認、資料作成、段取り）
- 確認・テスト（作業が正しくできたかの確認）
- 調整・コミュニケーション（顧客、チーム、ベンダとのやり取り）
- 報告・ドキュメント作成（作業記録、報告書）
- 手戻り・トラブル対応（想定外のことへの対応）
これらを計算に入れないと、見積は必ず不足します。
私が意識しているのは、「実作業の時間だけでなく、その周辺の作業も含めて見積もる」ことです。特に、確認・テスト・報告は、実作業と同じくらいの時間がかかることもあります。
考え方②：テスト工数は、絶対に削らない
これは、私が失敗から学んだ、最も大切な教訓です。
見積で、テスト工数を削ってはいけません。
見積が予算やスケジュールをオーバーしそうなとき、真っ先に削られがちなのがテスト工数です。「テストを減らせば、納期に間に合う」という誘惑にかられます。
でも、テストを削ると、その代償は後でやってきます。本番で不具合が続出し、その対応に、削ったテスト工数の何倍もの時間がかかる。しかも、顧客の信頼も失います。
だから私は、見積の段階で、テスト工数をしっかり確保します。「後から削られないよう、最初から必要な工数を計上する」——これが、品質を守る現実的な方法です。
テスト工数を守ることは、結果的に、プロジェクト全体の工数を抑えることにつながります。「急がば回れ」です。
考え方③：バッファ（余裕）を必ず持つ
見積には、バッファ（余裕）を必ず持たせます。
どんなに精度の高い見積を作っても、想定外のことは起きます。トラブル、手戻り、追加要望——。これらに対応するための余裕がないと、少しのズレでスケジュールが破綻します。
私は、見積に一定のバッファを含めるようにしています。「すべてが順調にいった場合の工数」ではなく、「多少のトラブルがあっても対応できる工数」で見積もる。
ただし、バッファを過大にすると、見積が高くなりすぎて、競争力を失います。適切なバッファの量は、作業の不確実性によって調整します。不確実性が高い作業ほど、多めのバッファを持たせます。
考え方④：過去の実績を参照する
見積の精度を上げるには、過去の実績を参照することが有効です。
「勘」で見積もるのではなく、「過去に似た作業がどれくらいかかったか」を基準にする。これで、見積のぶれが減ります。
そのためには、日頃から「どの作業に、どれくらいの時間がかかったか」を記録しておくことが大切です。実績データが蓄積されると、見積の精度が上がっていきます。
私のチームでは、主要な作業の実績工数を記録し、見積の際に参照するようにしています。「前回、同じような作業に〇時間かかった」というデータがあると、説得力のある見積が作れます。
考え方⑤：不確実な部分は「幅」で伝える
見積を提示するとき、不確実な部分は「幅」で伝えることも大切です。
すべてを断定的に「〇時間です」と伝えると、その通りにいかなかったときに、信頼を失います。
不確実性が高い部分は、「〇〜〇時間（調査の結果によって変動します）」のように、幅と条件を添えて伝える。これで、後のトラブルを防げます。
また、見積の前提条件を明記することも重要です。「〇〇が事前に完了していること」「△△の情報が提供されること」といった前提を明記しておくと、前提が崩れたときに、見積の見直しを正当に主張できます。
見積は「約束」でもある
最後に、見積に対する私の考え方を伝えます。
見積は、単なる「数字の予測」ではありません。**顧客やチームに対する「約束」**でもあります。
「この工数でやります」と見積を出したら、それは約束になります。だから、いい加減な見積を出すと、その約束を守れず、信頼を失う。
だからこそ、見積は真剣に、誠実に作る。楽観的な希望ではなく、現実的な予測で。テストや余裕を削らず、品質を守れる工数で。
誠実な見積を積み重ねることが、顧客との信頼関係を築き、チームを守ることにつながります。私は、そう考えています。
まとめ
運用保守の「見積」で失敗しないための考え方をまとめます。
- 「見えない作業」を必ず計算に入れる（準備、確認、調整、報告）
- テスト工数は、絶対に削らない（削ると後で何倍もの代償）
- バッファ（余裕）を必ず持つ（想定外に対応できる工数で）
- 過去の実績を参照する（勘ではなくデータで）
- 不確実な部分は「幅」で伝える（前提条件も明記）
見積は、プロジェクトの成否とチームの負担を左右する、重要なスキルです。
そして、見積は顧客やチームへの「約束」でもあります。楽観的な希望ではなく、現実的で誠実な見積を心がけることが、信頼を築き、チームを守ることにつながります。
コメント