「この機能、どれくらいで終わりますか？」
開発チームに投げられる質問のなかで、いちばん答えにくいのがこれではないでしょうか。
正直に「分かりません」と言えば無責任に聞こえ、勢いで「2週間です」と答えれば、その数字だけが独り歩きしてしまう。
テックリードの見積もりが難しいのは、計算が難しいからではありません。
難しいのは、まだ分かっていないことの量を、分かっていない相手にどう伝えるかという一点。
私自身もテックリードを目指して学んでいる立場ですが、ここは技術より先に言葉の設計が要る領域だと感じています。
見積もりは予測ではなく「目標が現実的か」の判定
最初に、見積もりの目的そのものを置き換えておきたいところ。
『Software Estimation: Demystifying the Black Art』の著者スティーブ・マコネルは、見積もりの第一の目的はプロジェクトの結末を予言することではないと述べています。
目的は「その目標が、コントロールして到達できる程度に現実的かどうかを判定すること」。
この定義は、見積もりを巡る会話の空気を変えてくれます。
予言だと思っている限り、外れた瞬間に「見積もりが甘かった」という犯人捜しが始まる。
判定だと捉え直せば、目標と現状のギャップを一緒に見る作業へと性格が変わります。
テックリードが最初に握るべきは、この見積もりの定義そのもの。
数字を出す前に、何のための数字なのかをそろえておかないと、後の会話が全部すれ違います。
不確実性のコーン：早い時期の数字は「16倍の幅」を持つ
見積もりの精度は、時間とともに勝手に上がるものではありません。
分からなかったことが分かっていくから、結果として幅が縮んでいく。
これを図にしたのが不確実性のコーン（Cone of Uncertainty）です。
構想段階での見積もりは、上振れ方向にも下振れ方向にも 4 倍ずれうる、とされています。
つまり幅としては最大で 16 倍の開き。
「3か月」と言った瞬間、それは「3週間から1年」を意味しかねない、ということになります。
Software Development's Cone of Uncertainty（Construx）
ここで大事なのは、コーンが自動的に狭まる保証はないという点。
要求も解決策も曖昧なまま作り続ければ、幅は開いたまま終盤まで残ります。
狭めるのは時間ではなく、調査・試作・意思決定という具体的な行動。
だからこそ「いつ狭まるか」ではなく「何をすれば狭まるか」を提示するのが、テックリードの仕事になります。
点ではなく幅で答える
不確実性を伝える最も実務的な方法は、単一の数字をやめることです。
「2週間」ではなく「短くて 8 日、長くて 20 日」と幅で言う。
幅で言うと頼りなく聞こえる、と心配になるかもしれません。
ですが幅は、自信のなさではなく情報量の少なさを表す指標。
「調査が終われば幅は 12〜16 日まで縮められます」と続ければ、相手は待つ価値のある調査だと理解できます。
幅と一緒に添えたいのが、その幅を生んでいる要因のリストです。
外部 API の仕様が未確認、既存コードの影響範囲が未調査、そんな箇条書きが 3 つあれば、幅の正体が可視化される。
会話の焦点が「なぜそんなにかかるのか」から「どれを先に潰すか」へ移るのです。
役割としての意思決定の重心は、こちらでも整理しています。
期限が先に決まっているときの伝え方
現実には、期限が動かせない場面のほうが多いはず。
そのとき「間に合いません」とだけ返すのは、判断材料としては役に立ちません。
マコネルの定義に立てば、見積もりは目標が現実的かの判定でした。
判定の結果が「現実的ではない」なら、何を削れば現実的になるかまで示すのがセットになります。
スコープ・品質・人数・期限のうち、動かせるものはどれか。
この 4 つを並べて「期限を守るなら、この機能は次の版へ回す形になります」と置けば、相手は選べる状態になる。
ここで避けたいのが、静かに品質だけを削るという選び方です。
テストを薄くして間に合わせた分は、負債として後から利息つきで返ってきます。
削るなら見えるところを削り、削った事実を記録に残しておきたいところ。
テックリードが管理職とどう違うのかは、この判断の置き場所にも効いてきます。
最後に
見積もりの技術は、精度を上げる技術ではなく不確実性を扱う技術でした。
目的は予言ではなく、目標が現実的かどうかの判定。
構想段階の数字は最大 16 倍の幅を持ちうるので、点ではなく幅で答え、幅を生む要因を並べて見せる。
期限が動かないなら、スコープ・品質・人数・期限のどれを動かすかを相手に選ばせる。
数字を守ることより、数字の意味をそろえることが先に来る仕事だと感じます。
以上です。
コメントを残す