改修見積もりがブレない出し方｜保守目線の5つの観点
「これ、どれくらいでできる?」——打ち合わせの途中で、そう軽く聞かれることがありますよね。 その場で「たぶん半日くらいですかね」と答えたのに、いざ手をつけたら影響範囲が広くて、テストも思ったより重くて、結局まるまる2日かかってしまった。あとから「そんなにかかるの?」と言われて、いたたまれない気持ちになる——保守運用をしていると、この「見積もりのズレ」が地味につらいところです。
見積もりが毎回ブレるのは、あなたの腕やスピードのせいではありません。多くの場合、「何を数えるか」が毎回変わっているのが原因です。今日は勢いで実装時間だけ答え、別の日は慎重にテストまで含める。基準が揺れれば、数字も揺れます。
この記事では、改修の見積もりを保守目線でブレなく出すための観点を一緒に整理します。速く見積もる方法ではなく、「毎回、同じ観点で・抜けなく数える」ための実務の型です。
結論：改修見積もりは、実装時間だけで答えず、①影響範囲の調査 → ②実装 → ③テスト・確認 → ④リリースと切り戻しの段取り → ⑤不確実性のバッファの5つに分けて出します。とくに保守目線では、「調べる時間」と「戻せる用意」を必ず数に入れるのがコツです。この2つが抜けると、見積もりはいつも実際より小さくなります。まず5項目それぞれに数字を置いてから合計する、と決めておくだけで、その日の気分に左右されにくくなります。
見積もりの単位（時間か人日か）や粒度は、現場や相手によって変わります。ここでは観点の並べ方を出発点に、自分の現場の言葉と単位に置き換えて使ってください。
何が起きているか：見積もりがブレる3つの理由
同じくらいの改修なのに、答えた数字が実際と大きくずれてしまう。その裏には、たいてい次の3つのどれかがあります。自分を責める前に、構造の問題だと知っておくと落ち着けます。
- 実装だけを数えている：「コードを書く時間」しか頭に浮かんでいない。実際には、調べる時間・テストする時間・リリースの段取りが、実装と同じかそれ以上かかることが多い。
- その場の勢いで即答している：聞かれた瞬間に「半日くらい」と口が動く。まだ影響範囲を見ていないのに数字が先に出るので、根拠がなく、あとで動かせない。
- 不確実性をゼロとみなしている：「たぶんこの辺だけ直せば済む」を前提に置く。レガシーや自分が作っていないコードほど「開けてみないと分からない」部分が大きいのに、それを見積もりに入れていない。
どれも「サボっている」わけではなく、数える枠が用意されていないだけです。枠さえ決めれば、埋めるのはそれほど難しくありません。
見積もりを組み立てる5つの観点（順番に）
見積もりは、いきなり合計を口にせず、下の5つに分けて数字を置いてから足します。慣れるまでは、5行のメモに数字を書き込むだけで十分です。
① 影響範囲の調査にかかる時間
保守の見積もりで、いちばん抜けやすいのがここです。「どこまで直せば済むかを調べる時間」を、実装とは別に数えます。
- その改修が、どの処理・どのデータ・どの裏の処理につながっているかを調べる時間。
- 自分が作ったコードか、初めて触るコードかで、この時間は大きく変わる。
- 調査してみて初めて「思ったより広い／狭い」が分かることも多い。だから調査を実装の前に置く。
「1行直すだけ」に見える改修ほど、影響範囲が読めません。調べる前に出した数字は当てずっぽうになりやすいので、まず調査ぶんを見積もりに立てる、と決めておくと安全です。どこから調べるかの順番は、既存システムの改修｜影響範囲を見落とさない調査の順番にまとめています。
② 実装にかかる時間
ここでようやく「コードを書く時間」です。多くの人が最初に思い浮かべるのがこの部分ですが、全体の一部にすぎません。
- 変更そのものを書く時間。
- 既存の書き方・命名・作法に合わせる時間（レガシーほど、周りに合わせる手間がかかる）。
- 直したことで、近くの処理も少し直す必要が出る「ついで作業」の時間。
きれいな新規開発と違い、保守の実装は「既存に馴染ませる」時間が上乗せされます。まっさらに書くより時間がかかるのが普通、と見ておくと過小評価を防げます。
③ テスト・確認にかかる時間
書いたものが正しく動くか、そして「壊していないか」を確かめる時間です。ここも実装と同じくらい、時には実装以上にかかります。
- 直した機能そのものが、意図どおり動くか確かめる時間。
- 直した近くの機能が、これまでどおり動くか確かめる時間（デグレの確認）。
- テストが用意されていない場合、手で確認する手順を組み立てる時間も含める。
テストコードがないコードだと、確認は全部手作業になります。ここを見落とすと見積もりは一気にずれます。テストのないコードに手を入れるときの進め方はテストがないコードに手を入れる前にやる安全策が参考になります。
④ リリースと切り戻しの段取り
コードができても、本番に安全に届けるまでが改修です。ここを「一瞬で終わる」と思うと、当日あわてます。
- 本番反映の作業そのもの（デプロイ、DB変更、設定反映など）。
- 事前バックアップと、問題が起きたときに戻す手順の用意。
- メンテナンス告知や、関係者への連絡が必要ならその段取り。
とくに「戻せる用意」は、忘れると一番こわい省略です。戻し方を用意する時間も、堂々と見積もりに入れてかまいません。むしろ、そこを削らないのが保守の見積もりです。
⑤ 不確実性のバッファ
最後に、「開けてみないと分からない」ぶんの余白を足します。ごまかしではなく、正直な見積もりの一部です。
- 初めて触る／作った人がいないシステムほど、バッファを厚めに取る。
- 過去に似た改修で「思ったより手こずった」経験があれば、それを根拠に足す。
- バッファは「サボりの余白」ではなく「不確実性の見える化」。相手にもそう説明できると、削られにくくなります。
自信のある部分にまでバッファは要りません。読めない部分にだけ、正直に余白を置くのがコツです。
具体例：「ボタンを1つ足すだけ」を5観点で見積もってみる
たとえば「管理画面に、CSVを出力するボタンを1つ足したい」という改修を、5つの観点に当ててみます（数字は例です。自分の現場の感覚に置き換えてください）。
- ①調査：出力したいデータがどのテーブルにあるか、似た出力処理が既にないかを調べる：0.5日。
- ②実装：ボタンとCSV生成処理を書き、既存の画面の作法に合わせる：0.5日。
- ③テスト：正しいデータが出るか、大量件数で重くならないか、他の画面を壊していないかを確認：0.5日。
- ④段取り：本番反映と、問題時にボタンを隠して戻す手順の用意：0.25日。
- ⑤バッファ：既存の出力処理の作りが読めないぶんの余白：0.25日。
「ボタンを足すだけ」の実装は0.5日でも、合計すると2日になりました。もし勢いで「半日ですね」と答えていたら、4倍のズレです。分けて数えるだけで、この差が事前に見えます。
影響：観点を持っておくと、何が変わるか
見積もりの観点を1枚持っておくと、数字が当たるだけでなく、あなた自身が楽になります。
- 「たぶん半日」ではなく「調査・実装・テスト・段取り・余白でこの内訳です」と、根拠を持って答えられる。
- あとから「そんなにかかるの?」と言われても、内訳を見せて落ち着いて説明できる。
- 見積もりが実績に近づくので、次の見積もりの精度も上がっていく。
- その日の体調や勢いに左右されず、同じ改修なら同じくらいの数字が出せる。
逆に、毎回その場の勢いで即答していると、たまたま当たった日と大きく外した日の差が大きく、そのたびに信頼がすり減ってしまいます。観点を固定するだけで、この揺れはかなり抑えられます。
明日やること：次の依頼で「5行見積もりメモ」を作る
立派な見積もり表は要りません。明日できる、いちばん小さな一歩はこれです。
- 次に来る改修の依頼を1つ選ぶ。
- メモに、①調査 ②実装 ③テスト ④段取り ⑤バッファの5行を書く。
- 各行に、いまの感覚で数字（時間か人日）を1つずつ置く。まだ調べていなくてかまいません。
- 5行を合計する。それが「分けて数えた見積もり」です。
- できれば、その場の勢いで出したであろう数字と見比べる。差が、いつも抜けていた分です。
その場で即答を求められたら、「内訳を1枚にして、あとで正確にお返しします」と一度持ち帰るだけでも、ズレはぐっと減ります。
「改修見積もり」チェックリスト
見積もりを出す前に、これだけ確認できているかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回埋める必要はありません。
まず外せない最低ラインはこの3つです。軽い改修でも、ここだけは押さえておくと大きく外しにくくなります。
- 【最低ライン】実装だけでなく、調査の時間を別に数えたか
- 【最低ライン】テスト・確認の時間を数えたか（テストがなければ手作業ぶんも）
- 【最低ライン】戻せる用意（切り戻し）の時間を入れたか
次の項目は、規模が大きいとき・初めて触るシステムのときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 影響範囲を調べる前の「勢いの即答」を、そのまま確定にしていないか
- 既存の作法に合わせる「馴染ませ時間」を実装に含めたか
- デグレ（近くの機能を壊していないか）の確認時間を入れたか
- 本番反映・DB変更・告知など、リリース当日の作業を数えたか
- 読めない部分にだけ、正直なバッファを置いたか
- 内訳を相手に説明できる形になっているか
全部に○が付かなくても大丈夫です。最低ラインの3つ——調査・テスト・戻す用意——を数に入れるだけで、いつもの「そんなにかかるの?」は、かなり減らせます。
よければ、こちらも
見積もりは、影響範囲の調査や安全な改修の段取りとセットにすると、さらにブレなくなります。次の3本を一緒に1枚にしておくと、当日とても楽になります。
- 既存システムの改修｜影響範囲を見落とさない調査の順番：見積もりの①調査を、どこから・どの順で進めるかの実務手順です。
- テストがないコードに手を入れる前にやる安全策：③テストが重くなりがちな改修を、安全に進めるための準備です。
- 技術的負債を見える化して優先順位をつける方法：見積もりが膨らむ原因＝負債を、事前に把握しておくための1枚です。
見積もりがこわいのは、数字に根拠がないからです。でも、数える観点さえ決まっていれば、根拠はメモの5行が作ってくれます。 今日は次の依頼で、①〜⑤の5行を書いて合計してみるだけで十分です。その1枚が、あなたを「そんなにかかるの?」から守る、最初の盾になります。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。