【要約】１年目に工数見積もりで失敗したときの話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
新卒エンジニアが、既存システムの規模の大きい改修において、大幅な工数超過に直面した。
- ・見積もり11人日に対し、実績20人日を要した。
- ・調査不足が実装やテストの工数増大を招いた。
- ・不確定要素を確定値として扱った。
- ・テスト工程が独立した作業として考慮されていなかった。
// Approach
著者は、作業の性質に基づいて工程を再定義し、不確実性を管理する手法を提案している。
- ・工程を「調査」「検討」「実装」「テスト」に分離する。
- ・「要調査」項目に対し、調査と実装の見積もりを分ける。
- ・前提条件や未確認事項を明文化する。
- ・調査完了後に再見積もりを行うプロセスを組み込む。
// Result
この手法により、見積もりの目的を「数字の提示」から「リスクの共有」へと転換させている。
- ・調査結果による工数変動を事前に許容できる。
- ・変更を安全に完了させるための全工程を網羅できる。
- ・不確実性を隠蔽せず、ステークホルダーと共有できる。
Senior Engineer Insight
> 既存システムの改修では、コードの変更以上に「仕様の理解」にコストがかかる。本記事の「作業の性質で分ける」という視点は、リスク管理として極めて実戦的だ。不確実性を前提条件として明示する姿勢は、開発現場の信頼性を高める。スケーラビリティのあるチーム運営には、この「不確実性の管理」が不可欠である。