SEの工数見積もりのやり方｜小改修を実装・試験・レビューに分ける

小改修の工数を聞かれたら、まず「どこまで終われば完了か」をそろえます。コード修正が2時間でも、試験データを作り、レビューを受けて指摘を直し、設計書を更新するなら、その分も見積もりに入ります。

作業に使う時間は人時で数え、レビュー待ちなどは引渡し日を決めるときに別に扱います。

実装が終わる時点と、作業完了の条件をそろえる

「条件分岐を一つ直す」という依頼でも、単体試験が終われば完了なのか、レビュー承認やリリース準備まで必要なのかで工数は変わります。対象機能、成果物、試験範囲、レビュー回数を依頼者へ聞き、今回どこまでを担当するかを書きます。

帳票の表示順を変えるなら、SQLの修正に加えて、同じ値が並んだときの順番、既存テストデータが使えるか、設計書の更新が必要かも作業量に関わります。まだ答えがない項目には「既存データを使う前提」などと仮定を付けておきます。

作業を五つに分け、抜けを探す

たたき台は、仕様・影響確認、実装、試験、レビューと修正、引渡しの調整の五つに分けます。案件の工程に合わせて区分を変えて構いません。担当外の作業があれば、誰に依頼するかも同じ表へ書き添えます。

試験の欄には、実行だけでなく観点の洗い出し、データ準備、結果確認も入れます。レビューには依頼資料の準備と指摘反映が必要です。別の人が行う作業を自分の工数へ二重に足さないよう、担当者を分けて記載します。

実装2時間の小改修が、合計8人時になる例

既存機能の小改修を一人で担当する、架空の例を見てみます。自分の見積もりに使う際は、類似作業の実績や今回の条件に合わせて数字を置き換えてください。

作業	見積工数	含むもの
仕様・影響確認	1.5人時	対象処理と関連箇所の確認
実装	2.0人時	コード修正と手元での確認
試験準備・実行	2.0人時	データ準備、実行、結果確認
レビュー資料・指摘修正	1.5人時	依頼資料と想定内の修正
成果物整理・引渡し	1.0人時	設計書差分、連絡、格納
合計	8.0人時	待ち時間は別に確認

実装だけなら2人時でも、表の合計は8人時です。この表は担当者本人の工数です。別の人がレビューする時間も含めてチーム全体を見積もる場合は、その人の作業として別に計上します。チームが人日で扱う場合は、1日を何時間とするかも社内の基準に合わせて換算します。

不確実性を一律の上乗せで済ませない

未調査の外部連携に、とりあえず一律で数割を足しても、作業が増える理由は伝わりません。「誰の返事待ちか」「何を調べる必要があるか」「今回の対象に含めない条件は何か」を見積もりの横に書きます。

例えば「既存の試験データを使える前提で8人時。新規作成が必要なら、内容を見て再見積もり」と伝えます。影響が大きい箇所は、調査を先に一つのタスクとして切り出す方法もあります。その時間で必ず原因まで特定できると約束せず、調査結果を受けて実装分を見直します。

レビュー後の修正をどこまで含むかも、前提の一つです。要件自体が変わったなら、追加になった作業と工数、納期への影響を伝え直します。担当者が黙って吸収すると、後続のタスクまで予定がずれてしまいます。

8人時の仕事が、翌日に終わるとは限らない

工数は人が作業する量で、納期はカレンダー上の完了時点です。8人時の仕事でも、レビュー担当者が空くのが来週なら、今日着手して明日終わるとは限りません。環境待ちや他タスクへの対応も、完成日には関わります。並行できない作業は、人数で割っても短縮できません。

伝えるときは「自分の作業は8人時。火曜にレビューを受けられれば水曜引渡し」のように、作業量と日付を分けます。締切に間に合わないなら、範囲を減らすのか、担当を増やすのか、レビュー日を動かせるのかを相談します。

終わったら合計だけでなく、ずれた理由を残す

8人時の見積もりが実績10人時だったら、増えた2人時の中身を残します。「データ準備を見積もっていなかった」と「途中で仕様が変わった」では、次に直す箇所が違うからです。元の表に実績を並べると、どの作業で差が出たかをたどれます。

残す記録は、作業名、前提、見積もり、実績、差の理由で十分です。次に同じような改修が来たら、合計時間だけをコピーせず、今回もその前提が成り立つかを見ます。

参考資料

IPA（情報処理推進機構）：見積もり手法（アーカイブ）。成果物の要素ごとに工数を積み上げる方法などを紹介しています。本稿の8人時は説明用の例であり、IPAが定めた標準工数ではありません。