開発工数の見積もり精度を共通言語化する

STORES というお店のデジタル化をサポートする会社でプロダクトマネージャー（PM）をやっている sako (@hamsako) です。

「この機能作るのに、工数どれくらいかかります？」

プロダクト開発界隈だと週に1回は聞く/言う言葉だと思います。

このとき、聞かれた側の頭の中では

（期待されてる回答工数の粒度は？）
（期待されてる精度は？）
（何人がかりを想定？）
（詳細な仕様も把握していないぞ）
（間に合わなかったらやばいやつなら多めに積まないと）

みたいなことがグルグルして、

「すぐには答えられないですね」

という回答に行き着くことがほとんどです。
（それに対して「超ざっくりでいいんで！」と追い打ちをかけ、
「ほんとにざっくりですよ？」と前置きして回答した工数が
いつのまにかコミットした扱いになってるところまでがお約束です）

この不毛なやり取りをやめたくて、わたしたちのチームでは見積もりについて次のような取り決めをしているので紹介します。

見積もり時のポリシーを定義する

バッファを見積もりに入れない

特に根拠のないバッファはブラックボックス化され「悪い意味での余裕」を生み出します。
内製でプロダクト開発をしているのであれば価値提供を最速化したいという共通認識は持てるはずなので、この「バッファを盛る」ということをやめ、想定よりも工数がかかっている場合や追加タスクが発生した場合はそれに応じた必要十分な工数を追加し、都度スケジュールへの影響をアップデート・共有するようにします。

予定通りに終わらないことを覚悟する

ではなぜバッファを積みたい意識が働くのかというと、「遅延 → 怒られる」という小学校時代から刷り込まれた防御反応があるからです。
プロダクト開発は毎回 新しい状況 で 新しいもの を作ります。未知の落とし穴もあるし、そもそもどれくらいかかるかの見積もりなんて不可能、という認識を持ってください。
というのを社内ステークホルダーとも握っておくのがPMの役割の1つです。

なおここで言う見積もりは社内で参照されるものと定義しています。
とはいえ、お客様や社外のステークホルダーにリリース予定を伝える必要があることもあります。その際は社内での見積もりとは分けて、バッファを持った期日を別で宣言することは否定していません。

見積もりレベルを定義する

見積もりの精度は、そのときの状況によってムラがあります。そのムラを、「概算」「ざっくり」「適当」といった言葉を使うよりも、伝える側・伝えられる側で認識を合わせるために、見積もりのレベルを定義して共通言語化しておきます。
なお、わたしたちはアジャイル開発手法であるスクラムを採用しており、それを踏まえた表現となっています。

Lv. 1 「ちゃんと見てないけど◯◯ヶ月くらいじゃない？」

エンジニア（EMやリード開発など、一定その領域に知見がある人を想定）に聞いて即答して欲しいときの精度です。過去の類似案件を参考にしたりします。
想定利用タイミング：聞く方も、詳細な要求・要件、PRDも作成していない状態で会話するとき。来期に向けて数十個あるバックログの優先順位を整理したいときなど。

Lv. 2 「大きく分けて◯段階での実装が必要で、それぞれにストーリーポイント◯◯くらいかかるとして◯◯スプリント = ◯◯ヶ月かかりそう」

Lv. 1と比較して、その実装に必要な処理をいくつかに分解した上での見積もりを行ったものです。場合によってはプロトタイピングをしながら解像度を上げ、その見積もり精度も上げます。
Lv. 1からLv. 3の間に位置する精度レベルなので、明確な基準はなく「Lv. 1よりも精度は高いけど、Lv. 3までは行かない」くらいの認識でOKです。
想定利用タイミング：プロジェクト着手前 〜 プロジェクト初期段階

Lv. 3「Issue（チケット）にして、ストーリーポイント見積もって、直近のベロシティから試算すると◯◯スプリント = ◯◯ヶ月かかりそう」

実際に対応予定のチームで、その機能をリリースするまでのタスクを洗い出し、それぞれのタスク精緻化を行い、ストーリーポイントを見積もり、そのチームの直近のストーリーポイント処理実績（ベロシティ）で割って算出します。
注意すべきは これでも見積もり精度としては100%ではない ということです。繰り返しになりますが、プロダクト開発は毎回新しい状況で新しいものを作ります。Lv. 3の見積もりを行ったあとにも実装中に新しいタスクの追加が必要なことは当然に発生しえます。
想定利用タイミング：プロジェクト着手中 〜 リリース完了まで

まとめ

ちなみに全ての案件でLv.1 〜 Lv. 3の見積もりすべてを行う必要はありません。
また「むかしチョット開発経験あるよ」くらいのPMが見積もりを行うこともたまにありますが、そのときは「見積もり精度 Lv. 0 です」なんて言うことで相手の期待値を最低レベルまで下げることもできます笑

『More Effective Agile』では、その開発案件が "手間はかかるけど道筋が見えているもの" を「煩雑系」、"探索的で未知の領域であるもの" を「複雑系」「混沌系」と定義しています。
この「複雑」「混沌」な案件の見積もりにおいて、社内コミュニケーション疲れを起こさないためにも、ぜひ見積もり精度のレベル分け、共通言語化を取り入れてみてください。