このブログをご覧のみなさん、こんにちは。

ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラッシュドット・ジャパン デベロッパー

本家/.「The Programmers Who Want To Get Rid of Software Estimates」より

ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。

記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事を先送りにする儀式となっている。」とのことだ。

Mediumの記事で最初にリンクしているツイートは2年以上前のものだが、実際に見積がなくなるまでにはどれぐらいの期間が必要だろうか。

タイトルの通り、見積りの時間を減らしたいなら「アジャイルな見積りと計画づくり」を読んで実践するといいよ！というお話です。

なぜ見積り / 計画づくりに失敗するのか？

そもそも不確実性コーンと呼ばれるプロジェクトの段階毎の見積り誤差の関係をグラフにすると、プロジェクトの初期では 60% から 160% の誤差が生じます。つまり、見積りには不確実性があり、それは初期が最も高いのだから、最初の見積りに時間をかけるのはムダ & 無意味ということになります。

ではどう見積るか？

従来の手法では個々の規模を見積り、その規模を消化する速度から期間を算出してきました。しかし、上でも述べた通り、最初に見積りをすると規模を正しく見積れません。これは「あそこにあるビルの大きさは何 m 何 cm か？」を正確に目視で算出することは難しいのと一緒です。一方で、「あそこにある二つのビルの高さを比べた時にどちらが大きいか？　それはどの程度の差 (= 2 倍、3 倍)なのか？」はかなり簡単に算出できます。ということは、基準となる大きさを決めて、それ以外の大きさは基準の大きさの何倍なのかという相対的な見積りで全体の規模を見積る、というのはそう難しいことではありません。これはフィーチャー A は 4 時間、フィーチャー B は 6 時間、フィーチャー C は 7 時間…といったようにフィーチャーを実現するのにかかるそれぞれの時間を細かく見積り、それを合算するのではなく、フィーチャー A の大きさを 2 とすると、フィーチャー B は 3 、フィーチャー C は 3 ……といったようにフィーチャーの相対的な大きさで見積るということです。

では期間はどう算出するのか？

すべてのフィーチャーの大きさを合計したら、四十だったとしましょう。後で計算に使うので単位を設定しますが、時間とは全く異なる単位(＝時間を連想させたくない)にしたいので、ストーリーポイントとしましょう。つまり、今回のフィーチャーは全部でストーリーポイントが四十となります。これだけではどれくらいかかるのかはさっぱり分からりません。そこで、ある期間(例えば、1 週間や 2 週間など)を 1 イテレーションとして、実際に 2-3 回繰り返す作業に着手します。1 イテレーション目に消化できたストーリーポイントが 4 で、2 イテレーション目は 12、3 イテレーション目が 8 だったなら、イテレーション毎に消化できるストーリーポイント、つまり開発速度が計算できます。今回の例では (4+12+8)/3 = 8 が 1 イテレーション毎に消化ができるであろうストーリーポイントの量になり、1 イテレーションの期間が 2 週間だったので、5 イテレーション = 5 x 2 (週間) = 十 (週間)程度かかると算出できます。

そんなに待てないんだけど？

今回の例ではすべて実装するとなると十週間程度かかると算出できました。しかし、二ヶ月後 = 8 週間後にリリースしたい場合、そんなに待てないということになります。どうすれば良いでしょうか？

期間を固定するなら、他の要素を変えるしかありません。例えば、それは品質であったり、金(チーム外のリソースを引っ張ってくる、チーム外に発注する等)であったり、実装しようとしているフィーチャーを減らすことかもしれません。

基本的に品質を落とすことはありませんし、追加でお金を調達するのも難しいです。そうなると、実装しようとしているフィーチャーを減らすしかありません。ちなみに、調査によるとプロダクトのフィーチャーの 64% は、めったに、あるいはまったく利用されません。そうであれば、ユーザにより多くの価値を届けるフィーチャーから実装していけば良いとなりますよね？これは期間におさまらない予定のフィーチャー、今回の例で言えば、実装する優先順位の下から合計してストーリーポイントが 8 になるフィーチャーを捨てる、というわけではありません。実際に開発を進めていって、期間内に消化できるなら消化してしまえばいいのです。つまり、必須ではなくオプションと考えるということです。もちろん、開発を実際に進めていって、途中で優先順位を変えた結果、最初に見積っていないフィーチャーが現れるかもしれませんし、優先順位が一番下のフィーチャーの優先順位をあげなければならない事態になるかもしれません。

事前に期間まで見積りが必須なんだよ！

ここまでのやり方はプロジェクト初期の見積りに含まれる不確実性を理解し、それを数イテレーション繰り返し実施することで、正確性を高める＝不確実性を取り除いていく手法です。そのため、受託開発などで発注する人、または受注する人がチーム外におり、事前に期間の見積りをする必要があるといった場合には採用が難しいです。

ではどうすれば良いでしょうか？

ここで落とし穴として、事前にスケジュールを合意する場合だとしても、フィーチャー毎に優先順位をつけることはできるということです。まずこれを実施してみましょう。続いて、作業にバッファを積みます。これはよくやられているので、人それぞれ算出方法があるでしょうが、ここでは“ 50% の確率で終わる見積り”と“ 90% の確率で終わる見積り”の二つの値を使って計算しましょう。

まとめ

• プロジェクト初期段階で不確実性を無視したムダな“絶対見積り”をせず、“相対見積り”をする
• 提示されたフィーチャーをすべて実装するのではなく、必須のフィーチャーとオプションのフィーチャーに分けて、必須＝優先順位の高いものから実装していく

といったことをすることで、見積りにムダに時間を取られず、結果的に双方が Win-Win になれるのでオススメです。