工数の見積もり方法｜外れたあとに直せる形にする
工数の見積もり方法を調べている人の多くは、精度を上げる技を探しています。ただ、5人から数十人のチームで進行を預かっている立場で本当に困るのは、見積もりが外れたこと自体ではなく、外れたあとに何も動かせなくなることのほうです。この記事では、見積もりの出し方をひととおり整理したうえで、幅の持たせ方、前提の残し方、実績と突き合わせて次に生かす手順までを、そのまま運用に落とせる順番で書きます。
工数の見積もりは「当てるもの」ではなく「更新するもの」
工数の見積もりを、契約書のように一度決めたら動かせないものとして扱っているチームは多くあります。決めた数字が独り歩きして、途中で状況が変わっても誰も言い出せず、締切の直前になって初めて崩れる。進行のとりまとめをしている人からは、この形の失敗をよく聞きます。
見積もりが外れる理由は、見積もった人の能力とは別のところにあることがほとんどです。着手前の時点では、仕様の細部が決まっていない、担当者が誰になるか確定していない、レビューが何往復するか読めない、他の案件が割り込む可能性がある、といった不確実さが必ず残っています。この状態で出した数字は、その時点でわかっている範囲の表明であって、将来の約束ではありません。
精度を上げる努力と、直せる形にする努力は別物
見積もりの話は、放っておくと「もっと正確に読む方法はないか」という一点に吸い寄せられます。分解の粒度を細かくする、経験のある人に見てもらう、過去の似た案件を調べる。どれも有効ですが、これらはすべて着手前にできることの改良であり、着手前にわからないことをわかるようにはしません。
一方で、外れたあとに直せる形にする努力は、着手後に効きます。途中で気づいたときに数字を更新できるか、更新したことが関係者に伝わるか、更新の理由が残るか。この3点が整っていれば、外れ幅が同じでも被害はまったく違う大きさになります。見積もりの技術に時間をかける前に、更新の仕組みが自分のチームにあるかを確かめたほうが、投じた時間は早く回収できます。
外れたときに実際に起きること
見積もりが外れたとき、現場で最初に起きるのは数字の修正ではなく、沈黙です。担当者は「もう少しで終わるかもしれない」と思いながら作業を続け、とりまとめ役は「聞くと急かしているように見える」と思って踏み込まない。この沈黙が続いた分だけ、打てる手が減ります。
2週間の作業が3週間になるとわかったとき、初日に判明していれば、担当を増やす、範囲を削る、後工程の予定をずらす、といった選択肢が全部残っています。ところが締切の2日前に判明すると、残る選択肢は「間に合わないと伝える」だけです。工数の見積もり方法を改善するときに本当に狙うべきなのは、この判明のタイミングを前に倒すことです。
数字だけを見ても原因はわからない
計画と実績の差を月末に集計して、乖離が大きい案件に印をつけている組織はよくあります。ただ、差の大きさだけを並べても、次に何を変えればよいかは出てきません。同じ40時間の超過でも、仕様が途中で増えたのか、想定していた担当者が別案件に取られたのか、単純に読み違えたのかで、打つ手はまったく別です。
差を記録するときは、必ず理由を一緒に残す設計にします。理由を後から思い出して書くのはほぼ不可能なので、気づいた時点でその場に書ける置き場所が要ります。工数の管理を表計算だけで回しているチームで、この理由が残らないのは、書く場所が用意されていないからであることが多くあります。
見積もる前に決めておくこと
工数の見積もり方法を人に説明できる形にするなら、計算の前に定義を揃える工程が要ります。ここが揃っていないと、数字は出せても比べられません。比べられない数字は、次の見積もりの材料になりません。
何を1件と数えるか
分解の粒度を決めないまま積み上げると、人によって1件の大きさが違ってきます。ある人は「ログイン画面を作る」を1件と数え、別の人は「入力欄を置く」「検証を書く」「エラー表示を作る」を3件に分ける。この状態で合計しても、合計の意味が定まりません。
粒度の目安として使いやすいのは、1件が半日から3日で終わる大きさに揃える、という決め方です。これより小さいと管理の手間が中身を上回り、これより大きいと途中の進み具合が見えません。「5日かかる作業が今どのくらい進んでいるか」を正確に答えられる人はほとんどいないので、大きい塊は分けたほうが結果的に読めるようになります。
粒度を決めたら、それを言葉にしてチームの見える場所に置いておきます。口頭で共有した粒度は、人が増えた瞬間に崩れます。
誰の時間で数えるか
人日で数えるか人時で数えるかは、どちらが正しいという話ではなく、チームで1つに決める話です。混在すると換算のたびに誤差が入ります。人日を使うなら、1人日が何時間なのかも決めておきます。8時間を1人日とする組織もあれば、会議や事務を差し引いて6時間を1人日とする組織もあります。
差し引く運用にしておくと、後で「見積もりどおりに進めたはずなのに終わらない」という現象が減ります。実際に手を動かせる時間は、勤務時間より必ず短いからです。逆に8時間で数えるなら、会議や事務の時間を別枠の工数として積む必要があります。どちらでもよいので、二重に数えたり、両方から漏れたりしない形にします。
外部の協力者が入る場合は、その人の稼働可能時間も先に確認します。週20時間の稼働で入っている人を、社員と同じ人日換算で計画に入れると、そこだけ確実に破綻します。
どこまでを工数に含めるか
見積もりが外れる原因として非常に多いのが、含める範囲の食い違いです。作る時間だけを数えて、レビュー、修正、確認待ち、環境の準備、引き継ぎの説明を入れていない。これらは案件が進むほど比率が上がるので、抜けたまま積み上げると必ず足りなくなります。
含める範囲は、チェックリストの形で持っておくと漏れません。作業そのもの、レビューと指摘の反映、動作の確認、関係者への説明と合意、資料の更新、想定される手戻り、といった項目を並べ、案件ごとに「これは要る」「これは不要」を判断します。判断した結果も残しておくと、後で差が出たときに、読み違えなのか範囲外だったのかを切り分けられます。
待ち時間の扱いも先に決めます。先方の返信待ちや外部の審査待ちは、担当者の手は空いていますが、案件としては前に進みません。これを工数に入れないなら、期間の見積もりとは別枠であることを明記します。工数と期間を同じものとして扱うと、並行作業や待ちの分でずれます。
見積もりの出し方をいくつか持っておく
工数の見積もり方法には昔からいくつかの進め方があり、それぞれ呼び名も付いていますが、名前や定義は文献や組織によって幅があります。ここでは呼び名の正しさには踏み込まず、実務でどう使い分けるかだけを整理します。大事なのは、1つの方法だけに頼らず、性質の違う出し方を2つ以上持っておくことです。
過去の実績から引き当てる
似た作業の実績が手元にあるなら、そこから引き当てるのが最も早く、最もぶれません。「前回の同じ規模の画面が4人日だったので、今回も4人日を基準に置く」という形です。
この方法が使えるかどうかは、実績が残っているかで決まります。残っていない組織のほうが多く、その理由もはっきりしていて、実績を残す作業が面倒だからです。ここを軽くする工夫については後の章で扱いますが、少なくとも「見積もりと実績を同じ単位で、同じ場所に、同じ粒度で残す」形にしておかないと、後から引き当てることはできません。単位が違うと換算が要り、場所が違うと探すのに時間がかかり、粒度が違うと対応が取れません。
実績を使うときの注意は、条件の違いを補正することです。前回は仕様が固まっていた、今回は途中で決めながら進む。前回は経験者が担当した、今回は初めての人が入る。こうした差は、そのまま数字に効きます。補正の幅を勘で決めることになるので、次の「幅を持たせる」話とつながります。
分解して積み上げる
作業を細かく割って、それぞれに時間を当てて合計する進め方です。何をするのかがはっきりしている案件では強く、また分解の過程で「これ、誰がやるんだ」という抜けが見つかることも多いので、見積もり以外の効用もあります。
弱点は2つあります。1つは、分解できるほど中身がわかっているとは限らないこと。もう1つは、細かく積むと合計が実態より小さくなりやすいことです。1件ずつ見ると「これは半日で終わる」と思えるものが並び、間の切り替えや待ちが計上されないまま合計されるためです。積み上げた合計には、後述する幅か、まとめて足す余裕分を必ず付けます。
余裕分を付けるとき、それを見積もりの中に溶かし込まないことも大事です。溶かすと、余裕がどこにどれだけあるのかが誰にもわからなくなり、削るときに何を削っているのか判断できなくなります。「作業の積み上げが30人日、不確実さの分が別途6人日」のように、分けて書きます。
似ている案件と相対で比べる
絶対的な時間を当てにいかず、「この作業は、あの作業よりやや重い」という比較だけで並べる進め方もあります。人は絶対量を答えるのは苦手でも、2つを比べるのは比較的得意なので、慣れていないメンバーからも意見を引き出しやすいという利点があります。
並べ終わったあとで、基準になる1件に実時間を当てれば、全体が時間に変換できます。基準は、チームの全員が実際にやったことのある作業を選びます。誰も経験していない作業を基準にすると、全体がまとめてずれます。
複数人で出し合って差を見る
同じ作業について複数人が別々に数字を出し、その差を見る進め方は、精度そのものより「認識の食い違いを見つける」ために効きます。片方が2日、もう片方が8日と出したなら、それは読みの差ではなく、作業範囲の理解が違っている可能性が高いということです。
この差を潰す会話は、平均を取って終わらせないことが肝心です。平均は、どちらの理解とも違う数字を作るだけで、食い違いは残ったままになります。差が大きいところだけを取り上げて、何を想定しているかを言葉にしてもらう。この時間が、見積もりそのものより価値を生むことがあります。
一点で出さず、幅で出す
工数の見積もり方法で、その日から変えられて効果が大きいのが、単一の数字ではなく幅で出すことです。一点の数字は、受け取った側が必ず約束として扱います。幅で出せば、不確実さがあること自体が相手に伝わります。
幅の作り方
作り方はいくつかありますが、実務で扱いやすいのは3つの数字を出す形です。すべてうまくいった場合の最短、順当に進んだ場合の妥当な線、想定できる問題が起きた場合の最長。この3つを、それぞれ根拠と一緒に書きます。
最長を出すとき、「起こりうる最悪」を想像で膨らませないことが大事です。膨らませた数字は説得力を失い、結局は妥当な線しか見てもらえなくなります。最長に入れるのは、「この案件で実際に起こりそうな、具体的に名前を挙げられる問題」に限ります。仕様の確認待ちが1週間伸びる、レビューが3往復になる、といった形です。
3つ出すのが重いなら、妥当な線とその上振れの2つでも十分に機能します。数を増やすことが目的ではなく、幅があることを可視化するのが目的です。
幅を相手にどう伝えるか
幅を出したとき、受け取る側が最短だけを見て予定を立てる、という現象が起きます。これを防ぐには、幅の意味を言葉で添えます。「15人日から22人日。15で終わるのは、仕様の変更が一切なく、レビューが1往復で通った場合だけです」のように、下限が成立する条件を明示します。
条件を書くと、相手はその条件を満たす側に動く余地が生まれます。「レビューを早く返せば下限に近づく」とわかれば、相手の行動が変わることもあります。幅は、責任を逃れるための保険ではなく、相手と一緒に条件を作るための材料として使います。
社外に出す見積もりで幅が使いにくい場面もあります。その場合でも、社内では幅で持っておき、外に出す数字はそこから決めた1つの値であることを、自分たちが把握しておきます。外向けの数字と内部の理解を一致させてしまうと、途中の判断材料が消えます。
幅がゼロになる瞬間を作らない
案件が進むと、幅は徐々に狭くなっていきます。仕様が固まり、担当が決まり、最初の何件かが実際に終われば、読める範囲は増えます。この過程で幅を更新していくのが、外れたあとに直せる形の中身です。
逆に、着手時に出した幅をそのまま最後まで置いておくと、幅はただの言い訳になります。1週間ごとに、残りの作業に対する幅を出し直す。狭まったなら狭まったと伝え、広がったなら理由と一緒に広がったと伝える。この更新が習慣になっているチームは、締切の直前に驚くことがほとんどなくなります。
前提と不確実さを書き残す
見積もりの数字だけを渡すと、その数字がどんな条件のもとで成り立っているかが失われます。時間が経つと、出した本人も思い出せなくなります。数字と同じ場所に、前提を残しておきます。
前提リストに書くこと
書く内容は、決まっていないこと、他人に依存すること、変わりうることの3種類です。「決済の仕様は現行と同じ想定」「デザインは9月10日までに確定する前提」「担当は経験のある2名を想定」といった具合に、短く並べます。
長い文章にする必要はありません。むしろ短いほうが読まれます。5行から10行で収まる量に絞り、絞った結果として落ちたものは、重要でなかったということです。
崩れたときに何が起きるかを添える
前提を並べるだけでは、崩れたときの影響がわかりません。それぞれの横に、崩れた場合の増分を書いておきます。「デザインの確定が1週間遅れると、全体が1週間後ろにずれる」「経験のない人が担当すると、教える時間が3人日増える」のような形です。
この一行があると、前提が崩れた瞬間に見積もりを更新する根拠がそのまま手に入ります。ゼロから計算し直す必要がなく、増分を足すだけで新しい数字が出るので、更新の心理的な負担が大きく下がります。更新されない見積もりの多くは、更新に手間がかかることが原因です。
有効期限を書く
見積もりには有効期限を付けます。「この見積もりは9月30日までに着手する前提」といった一行です。期限を切らないと、半年前に出した数字が現在の見積もりとして扱われ続けることがあります。人も状況も変わっているので、その数字はもう当てになりません。
実績と突き合わせて次に生かす
見積もりを改善する唯一の材料は、実際にかかった時間です。ここを取っていないと、何年やっても見積もりは上手くなりません。ただし、記録を取ること自体が重い作業になると、今度は記録が続きません。続く形で取ることが条件です。
記録は見積もりと同じ形で取る
突き合わせを可能にする条件は単純で、見積もりと実績の粒度・単位・置き場所を揃えることです。見積もりは作業単位で出したのに、実績は案件全体の合計しかない、という状態だと、どこがずれたのかがわかりません。
作業ごとに実績を取るのが重いなら、まとまり単位まで粗くしても構いません。粗くする代わりに、見積もりのほうも同じ粗さで出しておきます。突き合わせられない細かさより、突き合わせられる粗さのほうが役に立ちます。
記録の入力は、作業をしている場所と同じ場所でできるようにします。作業はタスクの板で管理し、時間の記録は別の表に転記する、という形にすると、転記が滞った時点で記録が止まります。よく聞くのは、記録を別管理にしたチームで2週間ほどで誰も入力しなくなる、という話です。
差の理由を3種類に分ける
見積もりと実績の差が出たら、理由を3つのどれかに分類します。読み違え、範囲の増加、外部要因です。
読み違えは、同じ作業を同じ条件でやったのに時間が違ったケースです。ここは次回の基準値を直せば改善します。範囲の増加は、途中でやることが増えたケースで、見積もりの精度の問題ではなく、変更の合意の取り方の問題です。外部要因は、待ちや割り込みなど、自分たちの外で起きたことです。
この分類をしないまま「差が出た」とだけ記録すると、全部が読み違えとして扱われ、次回から一律に数字を大きく積むようになります。積んだ結果、今度は余裕が多すぎて計画の意味が薄れます。分類は、増やすべきところだけを増やすために要ります。
週次でやること、案件の終わりにやること
週次では、残りの作業に対する見積もりを更新します。過去を振り返るのではなく、これから先を出し直す作業です。15分あれば足ります。「残りは何件で、いまの進み方だとどのくらいか」を口頭で確認し、変わっていれば数字を書き換えます。
案件の終わりには、見積もりと実績の差を作業単位で見て、大きくずれた上位いくつかだけを取り上げます。全部を検証しようとすると時間が足りず、結局やらなくなります。ずれの大きい3件から5件に絞り、それぞれ理由を1行で残す。この蓄積が、次の案件で引き当てられる実績になります。
次の見積もりに反映する
反映のしかたは、基準値の更新と、前提リストの更新の2つです。基準値は、「この種類の画面は4人日」を「5人日」に直す作業。前提リストは、今回崩れた前提を次回のリストに足す作業です。
前提リストの更新のほうが、効果が出るのが早いことがよくあります。読み違えの幅は簡単には縮まりませんが、「前回はこの確認が抜けて遅れた」という項目をリストに足すのは1分で済み、次回はその抜けが起きません。
情報処理推進機構は、ソフトウェア開発の実績データを収集して公開しており、規模や工数、期間の関係を業界横断で参照できる形に整理しています。自分たちの実績が貯まるまでの間、比較の物差しとして外部のデータを見ておくのは有効です。
ソフトウェア開発の実績データを収集・分析し、規模や工数、期間などの関係を整理して公開することで、見積もりの根拠づくりや品質向上に役立てる取り組みが行われています。 出典: ipa.go.jp
外部のデータは、自分たちの数字が極端にずれていないかを確かめる用途には向いています。ただし、そのまま自分たちの基準値にはできません。案件の性質も、含める範囲の定義も違うからです。あくまで物差しとして使い、基準値は自分たちの実績から作ります。
外れたあとに直せる形を、道具の側で用意する
ここまでの手順は、どんな道具を使っていても実行できます。ただし、道具の置き方によって、続くかどうかが大きく変わります。とりまとめる立場の人が本当に判断すべきなのは、見積もりの技法よりも、更新が続く置き場所を用意できているかどうかです。
見積もりと実績が同じ場所にあるか
見積もりは表計算、タスクはチャットや別の板、実績は勤怠のシステム。この3か所に分かれている状態は珍しくありません。分かれていると、突き合わせのたびに集める作業が発生し、その作業が面倒だという理由だけで突き合わせが行われなくなります。
同じ作業の単位に対して、見積もり、担当、状態、実績が並んでいる形が理想です。カードのような単位で作業を持ち、そこに数字を書き込める形なら、突き合わせは見るだけで済みます。ボード型のタスク管理ツールで工数を扱うときは、この「1枚に必要な情報が全部乗るか」を最初に確かめます。何ができるのかはできることにまとまっているので、いま使っている道具と項目を並べて比べると判断が早くなります。
更新のコストが十分に低いか
更新されない見積もりに価値はありません。したがって、更新に何回の操作が要るかは、機能の多さより重要な判断材料になります。数字を直すのに、別のツールを開いて、該当行を探して、書き換えて、関係者に連絡する、という手順が必要なら、更新は週に1回も行われません。
作業の板の上で数字を直せば、それを見ている人全員に伝わる。この形になっていれば、更新は数秒で終わります。工程表を1人が引き直している間、他の人はその表を見られない、という状態が起きる道具の使い方は、更新の頻度を確実に下げます。
いま使っている道具のままでよい場合
乗り換えを前提に読む必要はありません。すでに使っている道具の中で、見積もりと実績が同じ画面に並んでいて、更新が数秒で終わり、履歴が残っているなら、そのまま続けるのが正解です。道具を替えること自体に、移行と学習のコストがかかります。
たとえばカンバン形式で運用が回っていて、カードに必要な情報が乗っているなら、見積もりの列と実績の列を足すだけで済むこともあります。カンバンの運用を続けたうえで違いを確かめたいときはTrelloとの比較、担当と期日の管理を軸に組んでいるならAsanaとの比較が、それぞれ考え方の違いを並べた形で参考になります。文書とデータベースをひとつにまとめて運用しているチームならNotionとの比較、複数案件の状況を横並びで見る運用が中心ならmonday.comとの比較が近い論点を扱っています。
課題の管理とバージョン管理を一体で回している開発チームにはBacklogとの比較が、日本語での運用と価格の分かりやすさを重視して選んでいるならJootoとの比較が、それぞれ判断の材料になります。どれから見ればよいか決めかねる場合は比較の一覧から入ると、自分たちの使い方に近いものを選べます。
移行を考えるときに先に確かめること
道具を替えると決めたなら、いまの板の中身をどう運ぶかを先に確かめます。手で入れ直す前提だと、案件が動いている最中の移行はほぼ不可能です。既存のカードをそのまま持ち込める経路があるかどうかは、Trelloからの移行のように、対応している元のサービスと運べる項目が明示されているかで判断します。
社外の協力者が入るチームでは、誰がどこまで見られるかの設計も先に確認します。工数や単価に関わる数字は、案件の関係者全員に見せてよいとは限りません。権限とデータの扱いについての考え方は安全性の考え方に整理されています。運用でよく出る疑問はよくある質問に一覧があるので、導入前に自分たちの条件に当てはまるかを確かめておくと、入れたあとの手戻りが減ります。
見積もりの置き場所についての考察
工数の見積もり方法を運用に定着させられるかどうかは、技法の選択より、書き込む場所の設計で決まります。ここまでの手順を1つずつ見ると、どれも「見積もり、前提、実績、更新の履歴を、同じ作業単位に貼り付けられるか」という一点に集約されます。
道具を選ぶとき、機能の多さで比べたくなりますが、機能が増えるほど入力の場所も増え、どこに書けばよいか迷う時間が生まれます。迷いは入力の頻度を下げ、頻度が下がれば実績は貯まらず、実績が貯まらなければ見積もりは改善しません。とりまとめる立場の人が気にすべきなのは、入れる機能の数ではなく、チームの全員が同じ場所に書き続けてくれるかどうかです。
料金の考え方も、この視点で見ると判断が変わります。機能ごとにプランが分かれる設計だと、「実績の記録は上位プランでしか使えない」といった制約が、そのまま運用の穴になります。機能で絞らず、区切るのは人数とボードの数だけという設計であれば、全員が同じ機能を使える前提で運用を組めます。どの単位で区切られているかは料金で確かめられるので、いま使っている道具の制約と並べてみると、詰まっている箇所が特定できます。
ただし、ボード型のタスク管理ツールが工数の管理に万能というわけではありません。ソースコードのリポジトリを内包する仕組みを持たないものは多く、開発の課題管理とコードの履歴を一体で見たいチームには足りません。自動化や外部サービスとの連携の広さで選ぶなら、その領域を主戦場にしている道具のほうが向いています。画面の言語が日本語だけであれば、海外の協力者が入るチームでは使いにくくなります。自動で取り込める移行元が限られる場合、それ以外の道具からの移行は手作業になります。こうした制約は、選ぶ前に自分たちの条件と突き合わせておく必要があります。
最後に、見積もりを組織の評価に使わないことを付け加えます。見積もりどおりに終わったかどうかで人を評価すると、全員が確実に守れる大きな数字を出すようになり、計画の精度は下がります。見積もりは、限られた人と時間をどこに置くかを決めるための道具であって、成績表ではありません。外れることを前提に置き、外れたら直せる形にしておく。この構えができているチームは、見積もりが外れても案件が崩れません。
Q1. 工数の見積もりは、どのくらいの粒度で分けるのが適切ですか？
1件が半日から3日で終わる大きさに揃えるのが扱いやすい目安です。これより小さいと管理の手間が中身を上回り、大きいと途中の進み具合が読めなくなります。粒度は口頭で共有せず、言葉にしてチームの見える場所に置いておくと、人が増えても崩れません。
Q2. 見積もりを幅で出すと、相手に無責任だと思われませんか？
下限が成立する条件を明示すれば、逆に根拠のある数字として受け取られます。「仕様の変更がなく、レビューが1往復で通れば下限」のように書けば、相手にも条件を満たす動き方の余地が生まれます。幅は保険ではなく、条件を相手と一緒に作るための材料です。
Q3. 実績の記録が続きません。どうすれば定着しますか？
記録を作業と別の場所に置いていることが原因である場合がほとんどです。タスクを管理している板の上で、そのまま実績を書き込める形にすると入力の手間が大きく減ります。粒度も、細かく取ろうとせず、見積もりと同じ粗さまで落として構いません。
Q4. 見積もりと実績の差が出たとき、まず何を見ればよいですか？
差の大きさより先に、理由を読み違え、範囲の増加、外部要因の3つに分類します。分類しないと全部が読み違えとして扱われ、次回から一律に数字を積むようになります。案件の終わりに、ずれの大きい3件から5件だけを取り上げて理由を1行残す運用が続けやすい形です。