前書き
プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか？」だ。厳しいところだと「何日に納品してくれるのか？」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。
見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。
なぜ見積もりをしないといけないのか？
見積もりをしなければならない理由はいくつもある。
一つは投資判断である。そのプロダクトや機能の開発にどれくらいの金銭的なコストがかかるかを計算し、それに見合う価値が得られるかどうかを判断するためには、時間的な見積もりが必要になる。「どれくらいかかるか分かりません。できた時が終わる時です」ではそもそも開発をスタートすることも任せられない。
他にも期間があらかじめわかっていれば、マーケティングキャンペーンの準備はいつから始めればいいか分かったり、あるいは人員をさらに投下した方がいいかどうかを判断したりすることに使える。どれくらい時間とコストかかるかが分からなければ他の計画を立てることができなくなる。これらの重要な理由があるため、僕たちは自分の作業の見積もりをしなければならない。
なぜ見積もりは難しいのか
なぜ見積もりは難しいのか？それはあまりにも不確実性が多いからだ。
- やったことがないことはどれくらい時間がかかるか分からない
- もしかしたら予想外のタスクがあるかもしれない
- 使うフレームワークや技術の習得にどれくらい時間がかかるか分からない
- ハマりポイントがあるかもしれない
- バグが出たときのその発見と修正にどれくらい時間がかかるか分からない
- チーム開発なら他の人の開発速度が分からない。自分が何を担当するかも分からない。
まだまだたくさんあるだろう。そもそも自分が開発する対象を最初に完全に理解していることも稀だ。本当に分からないことだらけで見積もりなんてやりたくない。でも必要だから見積もりをさせられているにすぎない。
さらに見積もりを困難にさせていること
不確実性が多いことが見積もりを難しくさせているという話をした。だがそれでも、タスクを分解して、過去の知識をフル動員して、現実的な仮定を立てることで、僕たちは見積もりをすることができる。できるのだが、ここにもう一つ、見積もりを困難にさせるものがある。
それは**「見積った日が締め切りになる」**という事実だ。
「１週間で終わると思います」と上司に言ってしまったら、金曜日に夜遅くまで残業をしてでも終わらせなければならない。納期であれば何がなんでも必ずその日までに納品しなけらならなくなる。
このせいで僕たちは１週間くらいで終わるだろうと見積っても、気軽に「１週間で終わると思います」と言えないのだ。
不確実性の高い状況から生み出される見積もりは「１週間で終わる」という結論は出せない。見積もりで出せるのは「１週間で終わる可能性が最も高いが、50~200%くらいのばらつきがある」だ。
見積もりの実態と、求められている見積もり(締め切り)の不一致が、見積もりを難しくしていると私はいつも思う。
見積もりの手法
見積もりの困難さは、不確実性と認識の不一致にあるとしたが、それぞれに向き合うための誠実な姿勢はどんなものがあるだろうか？
まず、不確実性を対処する手法としてアジャイル開発で使われる「ストーリーポイントとベロシティ」による見積もりを紹介したい。
ストーリーポイントとベロシティ
ストーリーポイント
タスクを絶対的な評価で見積もることは、不確実性のために難しい。だから相対的な評価で見積もってしまおうというのがストーリーポイントである。
作業Aを５ポイントとしたとき、その２倍かかりそうな作業Bは10ポイントにする。作業Bほどはかからないが作業Aよりも難しい作業Cは7ポイントにする。みたいな感じだ。
人は絶対評価よりも相対評価の方が精度が高いと言われている。遠くに見えているビルの高さが何メートルか言い当てるのは難しいが、その隣にある小さなビルに比べて何倍大きいかを見積もることは誰でも正確にできる。
この方法で洗い出したタスクにポイントをつけていき、その合計ポイントがそのプロダクトであったり機能の完成までの見積もりになる。
ベロシティ
ストーリーポイントだけではその数字に意味はない。見積もりをする理由は意思決定であったり他の計画に利用するためであったので、「時間」に変換しなければならない。
それを可能にするのがベロシティだ。
実際にタスクをやってみて、１ポイントあたりどれくらいの時間がかかるのかを計測するのである。
１つの機能開発のストーリーポイントを８０ポイントと見積もり、８ポイントのタスクをこなすのに１日かかったとすると、機能開発は１０日で終わるだろうというふうに推測することができる。
バーンダウンチャート
「合計ストーリーポイント」「完了したストーリーポイント」「残りストーリポイント」を時系列で折れ線グラフに表示したものをバーンダウンチャートと呼ぶ。
順調に進んでいるプロジェクトであれば、残りストーリポイントは負の直線になり、その直線を伸ばしてx軸と重なるところがプロジェクト完了予定日時になる。
進捗を確認したり共有する上で、一眼でわかる可視化をすることは重要である。
不確実性を織り込んだ見積もりの提供
「見積もり」が「締め切り」になってしまうことが見積もりを困難にさせていることを述べた。
「締め切り」にされてしまうため、僕たちは自衛のために見積もりの正確性を犠牲にして過度なバッファを載せることになる。１週間で終わると思うが、念のため２週間と伝えておく。しかしこれは誠実な対応なのだろうか。
伝え方を変えるというのも一つの手段だと思う。
「完成は2週間後です」と伝えるよりも、それよりも「全体の完成は4日~10日かかると見積もりました。最初の3日でこれだけの成果が出る見込みがあります。」と伝え、かつ現在の進捗を確認する方法としてバーンダウンチャートを共有する。こちらのほうが、自分の持っている正確な情報を伝えている点と、見積もりは不確実なものであることを認めている点でより誠実であると私は思う。そして重要なのは見積もりは常に修正していくことだ。プロジェクト初期は最も不確実性が高いことを認め、知識を得ていく過程で再見積もりを行うことで不確実を下げていく。正確になっていく見積もりを意思決定者と共有しておく。
再見積もり
2日かかると見積もったタスクが3日かかってしまった場合、よくやってしまうのは「なぜ見積もり通りにいかなかったのか？」を考えてしまう。そして次のタスクはスケジュールに間に合わせるための「努力」をしてしまう。スケジュール通りに行っていないときに速度を上げるための「努力」が犠牲にするものは経験上大きい。時間がないから保守性のないコードが生まれる。バグを見つけても放置される。価値のある機能を思いついても無視される。
僕たちはこんな「努力」はしたくない。だったら「３日かかるタスクを２日と間違って見積もってしまった」と考えるべきである。見積もりを修正するべきである。今回、想定よりも1.5倍かかってしまったタスクと類似したタスクのストーリーポイントを1.5倍して再見積もりを行う。見積もりをより正確にするための修正を行う。
最後に
今回は、見積もりに対する考え方の共有と、アジャイル開発で使われるストーリーポイントによる見積もりを紹介しました。
もちろん読者各位が置かれている環境はそれぞれ異なるため、今回記事に書いた手法や考え方が適用できない環境もあると思います。
それでも少しでも参考になった方がいれば幸いです。
それでは。