見積りの時間を減らしたいなら「アジャイルな見積りと計画づくり」を読もう

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

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

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

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

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

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

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

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

ではどう見積るか?

従来は個々の規模を見積り、その規模を消化する速度から期間を導出してきた。しかし、上でも述べた通り、最初に見積りをすると規模を正しく見積れない。「あるビルの大きさは何mか?」を正確に算出することは難しいのと一緒。

一方、「2つのビルの高さを比べた時にどちらが大きいか? それはどの程度の差(=2倍、3倍)なのか?」はかなり簡単に算出できる。ということは、基準となる大きさを決め、それ以外の大きさは基準の大きさの何倍なのかという相対的な見積りで全体の規模を見積る、というのはそう難しいことではない。

これはフィーチャーAは4時間、フィーチャーBは6時間、フィーチャーCは7時間…といったようにフィーチャーを実現するのにかかるそれぞれの時間を細かく見積り、それを合算するのではなく、フィーチャーAは2、フィーチャーBは3、フィーチャーCは3…といったようにフィーチャーの相対的な大きさで見積るということである。

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

すべてのフィーチャーの大きさを合計したら、40だったとしよう。後で計算に使うので単位を設定するが、時間とは全く異なる単位にしたい(=時間を連想させたくない)ので、ストーリーポイントとする。つまり、今回のフィーチャーは全部でストーリーポイントが40というわけだ。

これだけではどれくらいかかるのかはさっぱり分からない。そこで、ある期間(例えば、1週間や2週間など)を1イテレーションとして、2〜3回繰り返し実際に作業に着手してみる。1イテレーション目に消化できたストーリーポイントが4、2イテレーション目は12、3イテレーション目が8なら、イテレーション毎に消化できるストーリーポイント、つまり開発速度が分かる。今回の例では(4+12+8)/3=8が1イテレーション毎に消化ができるであろうストーリーポイントの量になり、1イテレーションの期間が2週間と仮定すると、5イテレーション=5×2週間=10週間程度かかると算出できる。

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

今回の例ではすべて実装するとなると10週間程度かかると算出できた。しかし、2ヶ月後=8週間後にリリースしたい場合、そんなに待てないということになる。

どうすれば良いだろうか?

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

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

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

今までのやり方はプロジェクト初期の見積りに含まれる不確実性を理解し、それを数イテレーション繰り返し実施していき、正確性を高める=不確実性を取り除いていく手法になる。

そのため、受託開発などで発注する人がチーム外におり、数回イテレーションを回す時間もなくスケジュールを決めないといけない場合には採用できない。

どうすれば良いだろうか?

事前にスケジュールを合意する場合でも、フィーチャー毎に優先順位をつけることはできるはずだ。まずこれを実施しよう。

続いて、作業にバッファを積む。これはよくやられているので、人それぞれ算出方法があるだろうが、ここでは“50%の確率で終わる見積り”と“90%の確率で終わる見積り”の2つの値を使って計算する。

まとめ

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

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