開発の工数見積もりのやり方｜実装以外の作業を含めた分解例

「半日くらい」と答えたのに、調査やテスト、レビュー修正が残って終わらない。見積もりでは、時間を当てる前に、見積もる作業を見えるようにします。

問い合わせ管理に、必須・1〜100文字の件名を追加する架空の改修を使います。以下の時間は説明用の仮置きで、実測値や業界標準ではありません。対象コードや自分の作業記録で置き換えてください。

どこまでで終わりかを揃える

コードを書き終えるのか、テスト・レビューを終えて渡すのかで作業は変わります。最初に依頼者へ、成果物と担当範囲を確認します。

この例は「登録と一覧表示を変更し、必要な確認とレビュー対応を終え、共有の検証環境で確認してもらえる状態まで」が担当範囲です。本番反映は別担当と仮定します。実際の職場でも同じ分担になるとは限りません。

既存データの件名の扱いや、下書きにも必須条件を適用するかなど、未決仕様も残します。条件が変わり得るのに、完成日だけを一つに決めないようにします。

開発一式を五つに分ける

• 調査・仕様確認：対象処理と保存条件を把握する。登録経路、既存データ、未決仕様を確認。
• 実装：入力・保存・一覧表示を変更する。既存の構造と変更箇所を確認。
• テスト：条件と結果を記録する。確認観点、環境、データを確認。
• レビュー対応：指摘修正と再確認を終える。依頼先、必要な確認、依頼時点を確認。
• 引き渡し：次の担当者が確認を始められる状態にする。配置方法、資料、引渡先を確認。

最初から全操作を洗い出さず、「一覧に件名を表示する」のように結果が見える単位から始めます。見通せない作業は、さらに分けるか、先に調べます。

たとえば「データ対応」は、「件名のない既存データを調べる」と「必要なら対応を作る」に分けます。調査次第で不要になる作業を、確定した実装と同じ扱いにしないためです。

仮の時間に、前提を添える

既存処理をある程度確認した後の例です。数字を参考相場として使うものではありません。

「既存データの移行が必要か分からない」なら、一律に時間を多めにするより、調査して更新する条件を書きます。繰り返した作業の記録があれば、今回との違いも根拠にできます。

経験が少なく数字を出せないときは「まず対象処理と既存データを確認し、その結果で実装分を見積もりたい」と相談できます。何が分かれば見通せるかを伝えることが大切です。

合計時間と完成日は別に考える

作業が8時間分でも、今日から明日までで終わるとは限りません。別の仕事や会議、仕様回答、レビュー、環境の利用枠があるためです。

• 自分の作業時間：実装・テストに使う時間。担当者・リーダーと確認する。
• 確認待ち：仕様回答やレビューの着手待ち。判断者・レビュアーと確認する。
• 作業可能な枠：会議や別作業を除いた時間。優先順位を調整する人と確認する。
• 完了までの期間：以上を踏まえた引き渡し時点。依頼者・リーダーと揃える。

作業できる枠に内訳を置き、外部の確認が必要なところへ待ちを入れます。待つ間に別作業を進められても、レビュー指摘に依存する作業は先へ進めない場合があります。

待ちを区別すると、実装支援が必要か、仕様決定を早めるべきかを相談できます。チームの工数定義に従いつつ、待ち時間が含まれるか明記してください。

合計と前提を一緒に相談する

大きな不明点が残る数字を、そのまま外部への納期確約にしないでください。暫定の見通しか合意した計画かを揃えます。「余裕を見た」だけでは、含めた作業や条件は伝わりません。

ほかの仕事と重なるなら引き受ける条件を相談する例、割り込みで順序が変わるなら作業の優先度を扱う記事も参照できます。

分かった時点で見積もりを更新する

登録経路がもう一つ見つかった、確認環境が使えなかった、といった変化は残作業と前提へ反映します。最初の数字を守るために、必要なテストや引き渡しを見えない作業にしないようにします。

完了後は内訳と実際の作業を比べ、見落としや想定と違った条件を残します。人の速さの評価ではなく、次回何を先に調べるかの材料にします。

見積もりを渡す前のチェック

まず小さな改修を一つ選び、コード以外に何が終われば渡せるかを書いてみてください。