2014-03-25

なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ)

tech book

　最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

Amazon

　実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと普通にエンジニアでいつも自分が決めた締め切りとおりに終わらないけどなんでだろうとか思っている人がいたらこの本は参考になりそう。

　いつものように印象に残ったことを書いていく。

見積りの不確実性

　1章に書いてある、不確実性コーンという話は非常に面白い。不確実性コーンはプロジェクトの段階とその段階での見積りにどれくらいの誤差が出うるかについての関係を示している。それによると、プロジェクトが進まないと見積りの誤差が大きく、

初期のプロジェクト定義の段階では見積りに60%から160%に及ぶ誤差が生じる
- 20週間かかると見積もられたプロジェクトは、実際には12週間から32週間の間で終わる
要求が固まっても、まだ見積りにはプラスマイナス15%の誤差が見込まれる
- 20週間のプロジェクトで、17週から23週
詳細に設計するとようやく+10%から-5%の誤差になる

　この話は非常に参考になる話で、つまりこういうプロジェクトを始めようと決めたときにスケジュールを確定させても、実際には誤差が大きすぎるので信用しすぎてはいけないということが分かる。でも実際にはこういうことはやりがちだと思う。例えば

新サービスを作ろう、とりあえず今の段階の見積りだったら3ヶ月(12週)くらいで出来るから、○月△日に出すってことで、と決める
- 実際には2ヶ月弱から、5ヶ月弱の間くらいの精度
今の見積りだと1ヶ月で作れるんだから、お客さんにはこの日に納品できるね
- 実際には2週間から、1ヶ月半の間くらいの精度

　同じような例として、ボートと見積りの例が非常に的を得ていて面白い。

たとえば、あなたがボートの上に立っているとしよう。あなたの視点の高さが水面から9フィートの位置にあるなら、水平線までの距離は4マイルちょっとだ。ボートで旅をしようとしていて、その旅程が20マイルなら、少なくとも5回、つまり4マイルごとに計画を見直す必要がある。水平線の向こうを見ることはできないのだから、時おり立ち上がって行く手を見渡し、計画を調整しなければならないのだ。

　なので、こういう話を知っておくと、最初の精度はあまり完全に信用せず、プロジェクトを進めるごとに徐々に確定させていくほうが良いということが分かる。実際にこういう不確定なときにどうするかもこの本には書いてあって、例えば

ある期間(2週間とか)を1イテレーションとして、2~3回回してスケジュールをだいたい確定させる
- きちんと見積りをして、3回くらい回すと大体チームの開発速度がわかり、それによりスケジュールが大体算出できる
お客さんがいて、一番最初に納期を決めないといけない場合は、適切なバッファを設けて、リスクに備えておく
- フィーチャバッファ・スケジュールバッファなど

などということが書いてある。この辺りについては後で触れる。

理想時間と現実時間

　5章辺りで書かれている、理想時間と現実時間をわけて考える必要があるという話も印象に残った。理想時間とは何かをするのに割り込みなどなしにそれだけに集中した時のかかる時間であり、現実時間とはカレンダー上の時間のこと。

　見積りなどは理想時間でされることも多いが、ソフトウェア開発などにおいては、様々なオーバヘッドがあることも考慮する必要がある。これを考慮せず、理想時間として見積りが3日だから締め切りを3日後とかすると破滅することが多い。オーバヘッドには以下の様なものがある。

体調不良
会議
緊急の割り込み
etc

　さらに飛んで16章くらいにこのことに関する研究や、著者が観察や議論を重ねた見解がかかれてあり、

あるプロジェクトにフルタイムで参加したときに、そのメンバーがプロジェクトにつかえる時間は、55%から70%くらい
トヨタは極めて効率が良いプロセスで行っていたが、それでも80%程度だった

とあった。これも面白くて、人は一日8時間働くとして見積もっても、大体実質作業時間は4~6時間くらいということが分かる。

　この辺に関する見積りの解決策としては、

見積りは絶対時間で相対的なポイントでつける
1イテレーションでチーム全体で何ポイント消費できるかという速度(ベロシティ)を計測し、実際の時間を見積もる

ということが書かれてるが、このあたりのことは自分にとって新鮮な内容が書いてなかったので、今回は省く。

スケジュールとバッファ

　僕はこの本の中で17章の「不確実性に備えるバッファの計画」という部分が一番参考になった。それは見積り失敗してなぜか今すごく忙しいみたいな話に対する、一つの答えになっていたため。

　これまでに数回くらいイテレーションを回して見積りを更新して、正確さを高めていくという話をしたが、実際に数回イテレーションを回す暇なくスケジュールを決めないといけないこともある。例えば受託でお客さんがいるとそうなってしまうことも多いと思う。こういう時は特にスケジュールを遅れると損害が大きいが、しかし初期段階では60%〜160%の見積り誤差が発生する。そのようなときにどうすればよいか。

　一つの解として、見積り誤差を吸収するためにスケジュールにバッファを加えると良いと書かれている。さらに17章ではフィーチャバッファとスケジュールバッファという2種類のバッファについて書かれている。この二つをうまく組み合わせ、バッファを加えた見積りをするのが良い。

フィーチャバッファ

　フィーチャバッファとは、必須の機能とオプションの機能を選び、それらを合わせたスケジュールを作った上で、時間が足りなかったらオプションの機能の優先度の低いものからやらないという選択することで、期限に対するバッファを作れるようにしておくこと。この場合顧客には「こちらにあるフィーチャは全て実装します。うまくいけば、こちらのフィーチャも実装できるかもしれません」と言えば良いと書かれている。これは確かになるほどと言った感じで、スケジュールが遅れてもオプションの機能の実装をやめることで間に合わせることが出来るという意味でうまくバッファになっている。

　大体必須の要求を実現するために割り当てる工数は全体の70%を超えないようにすると良いと書かれていた。それ以外はオプションでスケジュールを算出しておくと良い。

　ちなみにちょっと話は違うけど、YAPC 2013のネットワークの整備の進め方の話も必須要求の決め方という意味で参考になる。1,000人超の大規模開発者イベント「YAPC::Asia Tokyo 2013」を支えたネットワークインフラ構築の舞台裏～プロフェッショナルのボランタリーが生み出したチカラ｜gihyo.jp … 技術評論社。こういう風に死守ライン、出来ればライン、遊びラインとかを決めておくと、うまくフィーチャバッファ作るときも必須要求が分かって良いと思った。

スケジュールバッファ

　スケジュールバッファとは、時間のバッファのこと。3日でできると見積もられていることを、余裕を持って4日くらいという話をした時、1日はスケジュールバッファとして見なされている。もちろんただ単にさぼるために時間を伸ばすということではない。

　この時、算出方法としてはいろいろあるのだけれど、正確さとコストのバランスがとれた見積もりをするのは二乗和平方根法が良いと書いてあった。いわゆる分散とか標準偏差とかを使うやつで、少しだけ数式出てくるけどそんなに難しくない計算で出来る。実際の計算式は209ページくらいに書いてあるので省くけど、

50%の確率で終わりそうな平均的な見積りを出す
90%の確率で終わりそうな悲観的な見積りを出す
この二つの値を使って計算する

という手順で計算できる。きちんとスケジュールバッファを作ろうとすると、大体二回見積りを作るだけでなんとなくバッファの量を見積もれるのが面白い。

ケーススタディ

　23章にケーススタディという章があるのだけれど、これも非常に良いので一度読んでみると良いと思う。ただ、この章で言っているのはアジャイルな見積りが完璧にはまったときにどのくらいうまくいくかということが書かれているように見えるので、その全ての手順を鵜呑みにするのはまずそうに思った。実際にはその中でチームの文化とよくあうものをピックアップすると良さそう。