こんにちは。GxPの門脇です。
グロースエクスパートナーズグループのリレーブログ企画7日目です。
前回の記事は「AIと働く人」と「AIと働く組織」の違い - AIフルーエンシーとトークン資本から考える、2つのAI協働でした。
まだご覧になっていない方は、ぜひそちらもチェックしてみてください！

はじめに

自分はシステムの保守運用を主に行っています。

普段はデータメンテナンスや問い合わせ対応、軽微なシステム改修などを担当しています。

改修時には工数見積もりも行っていましたが、当時担当していたのは2〜3人日程度で終わる小規模な改修がほとんどでした。

そんな新卒1年目のとき、複数画面や既存処理に影響する、それまでより規模の大きい改修の工数見積を担当することになりました。

結果は次のとおりでした。

内容	工数（人日）
見積工数	11
実績工数	20
差	+9

9人日分の大きな作業が一つ発生したわけではありません。

実際には、

既存仕様の調査に想定以上の時間がかかる
↓
調査によって、想定していなかった既存仕様や影響範囲が見つかる
↓
それらに対応するための実装が増える
↓
変更範囲が広がり、テスト対象も増える

という形で、見積もりとの差が後工程へ連鎖していきました。

最終的には、残っていた作業の一部を別の方に巻き取ってもらいました。

今回は、当時実際に作成した見積もりを振り返りながら、何を見積もれていなかったのかを整理します。

当時の見積もり

当時作成した見積もりを、業務固有の名称を省いて簡略化すると、次のような内容でした。

全体工数：11人日

承認フローから特定のステータスを除外する

├─ フロー調査・整理：2人日
│  └─ 除外後の遷移先を整理する
│
├─ 実装修正：6人日
│  ├─ 条件分岐や遷移制御ロジックの修正：1人日
│  ├─ 不要になるボタンや関連処理の削除：1人日
│  ├─ 影響範囲、修正・削除箇所の調査：2人日
│  └─ 上記の実装対応：2人日
│
├─ メール送信バッチ修正（要調査）：1人日
│
├─ 状態遷移図の作成：1人日
│
└─ 既存データの整理：1人日

当時はここまで作業を分けていたため、自分ではある程度細かく見積もれているつもりでした。

しかし今振り返ると、以下の問題点があると考えられます。

調査と実装が同じ項目の中に入っている
テストが独立した作業として存在しない
「要調査」の作業にも確定した工数を置いている
調査結果によって後続作業が増える可能性を考慮していない

と、性質の異なる作業や不確定要素を同じ確度で扱っていたことに問題がありました。

既存仕様の調査工数を十分に見積もれていなかった

見積もり前に何も調査していなかったわけではありません。

対象となる処理や既存コードを確認し、どこを変更する必要があるかはある程度調べていました。

実際、当時の見積もりにも、

フロー調査・整理：2人日
影響範囲、修正・削除箇所の調査：2人日

という項目があります。

そのため当時は、

変更する箇所が分かれば、実装工数もある程度分かる

と考えていました。

しかし、実際に作業を始めると、既存処理を理解するための調査に想定以上の時間がかかりました。

コード上で変更する箇所が分かっても、

なぜこの条件分岐が存在するのか
この処理は他の機能からも利用されていないか
特定の条件だけ既存の動きを残す必要がないか
この値を変更した場合に他の処理へ影響しないか
現在の実装と仕様書の内容に差がないか

といったことを確認しなければ、安全に変更できません。

また、コードを読んだだけでは処理の意図を判断できず、仕様書や過去の資料を確認したり、既存仕様に詳しい方へ確認したりする必要がある箇所もありました。

当初は対象箇所周辺を確認すれば実装に入れると考えていました。

実際には、変更箇所を見つけたあとに、

なぜその処理になっているのか
↓
どこから利用されているのか
↓
どこまで既存の挙動を維持する必要があるのか

まで確認する必要がありました。

つまり、当時の自分が見積もっていた「調査」と、実際に必要だった「調査」には差がありました。

見積もるべきだったのは、

変更するコードを見つけるまでの時間ではなく、そのコードを安全に変更できる状態になるまでの時間

でした。

調査で分かった複雑さが、そのまま実装工数の増加につながった

問題は、調査に時間がかかったことだけではありません。

調査を進めるほど、当初想定していなかった既存仕様や影響範囲が見つかりました。

例えば、一箇所を変更すれば終わると思っていた処理でも、

特定条件では既存の挙動を残す
別の処理から利用されているため整合性を取る
削除予定だった処理を一部だけ残す
新しい条件分岐を追加する

といった対応が必要になりました。

つまり、

調査に時間がかかる
↓
新しく考慮すべき既存仕様が見つかる
↓
その仕様に対応するための実装が増える

という形で、調査時に判明した内容がそのまま実装工数にも影響しました。

ここで当時の見積もりを見ると、

影響範囲、修正・削除箇所の調査：2人日
上記の実装対応：2人日

としています。

一見すると「調査」と「実装」を分けています。

しかし実際には、調査結果によって実装量そのものが変わります。

にもかかわらず、

調査：2人日
実装：2人日

と、両方の作業量が見えているかのように固定していました。

本来は、

既存仕様を理解する
↓
影響範囲を確認する
↓
必要な修正内容が決まる
↓
実装方法を考える
↓
実装する

という順番です。

つまり、

「変更する場所が分かっている」ことと、「その変更に必要な作業量が分かっている」ことは別でした。

タスクの粒度ではなく、「性質の違う作業」を分ける必要があった

当時も、改修全体を一つの作業として見積もっていたわけではありません。

画面や処理ごとにある程度分解していたため、自分では細かく見積もれているつもりでした。

しかし、問題は単純なタスクの大きさではありませんでした。

例えば、

ボタン関連の修正：○人日

という一つの変更にも、実際には次のような作業があります。

ボタン関連の修正

├─ 既存仕様の確認
├─ 表示条件の確認
├─ 影響範囲の調査
├─ 実装方法の検討
├─ UIの実装
├─ 関連処理の実装
├─ 正常系テスト
├─ 異常系テスト
└─ 既存機能への影響確認

これらは、単に項目名が違うだけではありません。

それぞれ見積もりの性質も違います。

例えば、

調査：調べるまで作業量そのものが分からない場合がある
実装方針の検討：既存仕様の複雑さによって変わる
実装：調査結果によって修正量が変わる
テスト：変更箇所や影響範囲が増えるほど対象も増える

という違いがあります。

当時の11人日の見積もりでは、特にテストが独立した作業として現れていません。

実装とテストをまとめて考えていたため、

調査にどのくらい時間が必要なのか
どこに不明点があるのか
実装量は何を前提にしているのか
テスト対象がどのくらいあるのか

が見えにくくなっていました。

そのため、今なら単にタスクを細かくするのではなく、

「調査」「方針検討」「実装」「テスト」のように、見積もりの性質が異なる作業を分ける

ことを意識します。

タスクを細かくする目的は、項目数を増やすことではありません。

見積もりの中に隠れている作業と、不確定要素を見えるようにすること

だと思います。

見積もり時点で分からないことを、分かった前提で扱っていた

当時の見積もりには、

メール送信バッチ修正（要調査）：1人日

という項目もありました。

今見ると、「要調査」としている時点で、どの程度の対応が必要になるのか十分に把握できていません。

それにもかかわらず、1人日という確定した数字を置いていました。

当時は、

少し調査は必要だが、おそらくこのくらいで対応できるだろう

という感覚で見積もっていたのだと思います。

理想を言えば、

既存仕様調査：○人日
実装：調査結果を踏まえて見積もり

と分けられます。

ただし、実際の業務では調査前であっても、予算や納期の都合で全体の概算工数を求められることがあります。

その場合、単純に「まだ分からないので見積もれません」で終わらせるのではなく、例えば次のように扱う方法があります。

メール送信バッチ

調査：1人日

現時点での実装見積もり：1〜3人日

前提：
- 対象バッチ内だけで修正が完結する
- 他処理から共通利用されていない

未確認事項：
- 他機能への影響範囲
- 既存データへの影響

調査完了後に再見積もりする

重要なのは、数字を出すこと自体ではありません。

その数字が、何を前提に成立しているのかを明確にすることです。

当時の見積もりでは、

メール送信バッチ修正（要調査）：1人日

という一行に、

調査
実装
不確定要素
見積もりの前提

がすべて埋もれていました。

「分からないこと」を無理に「分かった数字」へ変換するのではなく、

何が分かっていて、何がまだ分かっていないのかを整理することも、見積もりの一部

だったと思います。

調査の見積もり不足は、後工程に連鎖する

今回の改修で特に大きかったのは、調査工数の見積もり不足が、調査工程だけの問題で終わらなかったことです。

当初の見積もりでは、調査に使う時間を少なく見積もっていました。

しかし実際には、

既存仕様の調査に想定以上の時間がかかる
↓
想定していなかった既存仕様や影響範囲が見つかる
↓
対応する条件分岐や処理が増える
↓
修正箇所が増える
↓
確認すべきテストケースも増える

という形で影響が広がりました。

例えば、調査の見積もりが1人日不足したからといって、最終的な工数も1人日だけ増えるとは限りません。

調査によって新しい影響範囲が見つかれば、

調査工数の増加
+
実装工数の増加
+
テスト工数の増加

になります。

今回の11人日と20人日の差も、一つの大きな見落としによるものではありません。

前工程での小さな見積もりのずれが、後工程の作業量そのものを増やした結果でした。

今ならどう見積もるか

同じような改修を今見積もるなら、まず「どのコードを修正するか」ではなく、

その変更を完了するまでに必要な工程

を洗い出します。

例えば、次のように分けます。

1. 既存仕様の調査
   ├─ 対象コードの確認
   ├─ 仕様書・設計書の確認
   ├─ 関連処理の確認
   └─ 不明点の確認

2. 影響範囲の調査
   ├─ 呼び出し元
   ├─ 呼び出し先
   ├─ 関連画面
   ├─ バッチ
   └─ 既存データへの影響

3. 実装方針の検討
   ├─ 既存挙動を残す条件
   ├─ 修正方法
   └─ 削除・変更範囲

4. 実装

5. テスト
   ├─ 正常系
   ├─ 異常系
   ├─ 境界条件
   └─ 既存機能への影響確認

6. その他
   ├─ データ補正
   └─ ドキュメント更新

そのうえで、不確定な箇所については、

分かっていること
分かっていないこと
見積もりの前提
調査によって変わる可能性がある工数
再見積もりするタイミング

を明示します。

例えば、

メール送信バッチ

調査：1人日
実装：1〜3人日
テスト：1人日

前提：
対象バッチ内の変更だけで完結すること

不確定要素：
共通処理や他機能への影響

対応：
調査完了時点で実装工数を再見積もりする

といった形です。

もちろん、ここまで分解したからといって見積もりが必ず当たるわけではありません。

既存システムの改修では、調べるまで分からないことはどうしてもあります。

ただし、

11人日です

とだけ提示する場合と、

現時点では11人日。ただし、この部分は未調査であり、調査結果によって実装・テスト工数が増える可能性がある

と提示する場合では、同じ11人日でも意味が違います。

見積もりは数字を出すことだけではなく、

その数字の確度と、どこに不確実性があるのかを共有すること

まで含むものだと、今は考えています。

まとめ

今回の改修では、11人日の見積もりに対して、実際には20人日かかりました。

9人日の差を生んだ一つの大きな原因があったわけではなく、

調査の見積もり不足
↓
想定外の仕様・影響範囲の発覚
↓
実装量の増加
↓
テスト対象の増加

という形で、小さな見積もりのずれが後工程へ連鎖した結果でした。

この経験から、今なら次の点を意識して見積もります。

調査・方針検討・実装・テストを分けて考える
調査結果によって変わる作業を、確定した作業と同じように扱わない
不明点には前提条件や不確定要素を明示する
必要であれば、調査完了後に再見積もりする
変更箇所ではなく、変更を完了するまでの工程全体を見る

当時の自分は、

どのコードを変更するのか

を中心に見積もっていました。

しかし、既存システムの改修では、

既存仕様を理解する
↓
影響範囲を把握する
↓
実装方法を考える
↓
実装する
↓
既存機能を含めてテストする

ところまでが一連の作業です。

そして、その途中に分からないことがあるなら、それ自体も見積もり上の重要な情報です。

今回の経験から、

見積もるべきなのは「コードを変更する時間」ではなく、「その変更を安全に完了させるために必要な作業全体」だった

と学びました。