「この項目を追加するのに、どれくらいかかりますか」。画面を見て「半日くらい」と答えたものの、調査、テスト、レビュー後の修正が残り、思った日に終わらない。見積もりで困るのは、時間を当てること以前に、見積もる作業が見えていない場面です。
まず、調査・実装・テスト・レビュー対応・引き渡しへ分けます。そのうえで、自分が手を動かす時間と、回答や確認を待つ時間を区別し、前提と不明点を添えて相談します。
ここでは、問い合わせ管理に必須・1〜100文字の件名を追加する架空の改修を使います。作業時間の数字も説明のための仮置きであり、実測値や業界標準ではありません。自分の経験や対象のコードを確認して置き換えてください。
先に「どこまでで終わりか」を揃える
「件名を追加する」の終わりが、コードを書き終えることなのか、テストとレビューを終えて引き渡すことなのかで、作業は変わります。最初に依頼者へ、成果物と担当範囲を確認します。
この例では、「登録と一覧表示を変更し、必要な確認とレビュー対応を終えて、共有の検証環境で確認してもらえる状態まで」を担当すると仮定します。本番反映は別担当です。実際の職場でも必ずこの分け方になるわけではありません。
また、既存データの件名をどう扱うか、下書きにも必須条件を適用するかなど、仕様に未決事項があるなら記録します。条件が変わる可能性を隠して、完成日だけを一つに決めないようにします。
実装以外も、成果が見える作業へ分ける
「開発一式」を、終わったかどうか説明できる単位にしてみます。
| 作業 | 終えたときに分かること | 見積もる前に確認すること |
|---|---|---|
| 調査・仕様確認 | 対象の処理と保存条件が分かる | 登録経路、既存データ、未決仕様 |
| 実装 | 入力・保存・一覧表示の変更がある | 既存の構造と変更箇所 |
| テスト | 条件と結果の記録がある | 確認観点、環境、データ |
| レビュー対応 | 指摘の修正と再確認が終わる | 依頼先、必要な確認、依頼時点 |
| 引き渡し | 次の担当者が確認を始められる | 配置方法、資料、引渡先 |
最初から細かい操作をすべて洗い出す必要はありません。「一覧に件名を表示する」のように、変更結果が見える単位から始めます。それでも見通しが立たない行は、さらに分けるか、先に調査する対象です。
たとえば「データ対応」が曖昧なら、「件名のない既存データを調べる」と「必要なら既存データへの対応を作る」を分けます。調べた結果、対応が不要になるかもしれない作業を、確定した実装と同じ扱いにしないためです。
既知の作業には幅を、不明点には確認方法を置く
次は、既存処理をある程度確認した後の仮の見積もりです。数字を参考相場として使うための表ではありません。
| 内訳 | 仮の作業時間 | 前提・更新条件 |
|---|---|---|
| 追加調査と仕様の整理 | 1〜2時間 | 登録経路が把握できる範囲 |
| 入力・保存・一覧の実装 | 3〜5時間 | 既存の部品と検証方法を使える |
| テストと結果の整理 | 2〜3時間 | 利用する環境とデータが用意済み |
| レビュー修正と再確認 | 1〜2時間 | 変更方針の大きな見直しがない |
| 引き渡しの準備 | 1時間 | 本番反映は担当範囲に含まない |
| 合計 | 8〜13時間 | 既存データへの追加対応は別途確認 |
合計は、仮置きした各作業の最短と最長を足したものです。統計から求めた確率や、一定の確率で収まる範囲ではありません。前提が崩れた場合は、この範囲を超えることもあります。
「既存データの移行が必要か分からない」なら、その不明点を一律に多めの時間へ埋め込むより、調査して見積もりを更新する条件を書きます。逆に、繰り返し行った作業の記録があれば、その記録と今回の違いを根拠にできます。
経験の少ない作業で時間を出せない場合は、「まず対象処理と既存データを確認し、その結果を見て実装分を見積もりたい」と相談できます。数字を即答できることより、何が分かれば見通せるかを伝えることが大切です。
作業時間を足しても、完成日にはならない
仮に作業が8時間分あっても、今日から明日までで終わるとは限りません。別の担当作業、会議、仕様の回答待ち、レビューを受けられる時点、環境の利用枠があるためです。
自分が作業できる枠に内訳を置き、外からの確認が必要なところへ待ちを入れて考えます。レビュー待ちの間に進められる別作業があるかもしれませんが、指摘の内容に依存する作業は先へ進めないこともあります。
| 区別 | 例 | 相談する相手 |
|---|---|---|
| 自分の作業時間 | 実装やテストに使う時間 | 担当者・リーダー |
| 確認待ち | 仕様の回答、レビューの着手待ち | 判断者・レビュアー |
| 作業可能な枠 | 会議や別作業を除いた時間 | 優先順位を調整する人 |
| 完了までの期間 | 上記を踏まえて引き渡せる時点 | 依頼者・リーダー |
待ち時間を工数へ混ぜずに示すと、「実装を手伝えば早まるのか」「仕様を先に決める方が効果があるのか」を話しやすくなります。チームで工数の定義が決まっている場合は、その定義に合わせつつ、待ちが含まれているか明記してください。
見積もりは、前提ごと相談する
見積もりを伝えるときは、合計と同じくらい前提が重要です。先の架空例なら、次のようにまとめられます。
件名追加は、調査・実装・テスト・レビュー修正・引き渡し準備で、作業時間を仮に8〜13時間と見ています。 既存の登録処理を使い、本番反映は別担当という前提です。件名のない過去データへの対応が必要かは未確認なので、追加調査の結果で更新します。 完成日は、仕様の回答時点とレビュー枠を確認して決めたいです。既存データの扱いが分かった時点で、改めて内訳を共有します。
大きな不明点が残る場合、この数字をそのまま外部への納期確約にしないよう、暫定の見通しか、合意した計画なのかも揃えます。「余裕を見ておきました」の一言では、何を含めているのか伝わりません。
ほかの仕事と重なるなら、引き受ける条件を相談する例が役立ちます。割り込みによる順序の変更は、作業の優先度を扱う記事で整理できます。
調査で分かったら、その時点で見積もりを更新する
作業中に登録経路がもう一つ見つかったり、確認環境が使えなかったりしたら、残作業と前提を更新します。最初の数字を守るために、必要なテストや引き渡しを見えない作業にしないようにします。
終わった後は、内訳と実際の作業を比べ、「見落とした作業」「想定と違った条件」を残します。人の速さを評価する表にするより、次回何を先に調べればよいかに注目すると、見積もりの材料として使えます。
まずは手元の小さな改修を一つ選び、コード以外に何が終われば渡せるかを書き出してみてください。見積もりは、その作業と不明点を、相手と一緒に見えるようにするところから始まります。
