アジャイルな見積りと計画づくり：第2部：規模を見積もる「８章 ストーリーポイントと理想日」まとめ

私も私のチームも、見積り技法は理想日による見積りに近いなと思った。どんどんずれるのでその都度修正するが、ストーリーポイントのような基準がないので、いつまでたってもズレ補正がきかない。

目次

• ストーリーポイントと理想日
• ストーリーポイントの長所
• ストーリーポイントは職能横断的な作業の進め方を促進する
• ストーリーポイントによる見積りは長持ちする
• ストーリーポイントは純粋に大きさだけをあらわす
• ストーリーポイントで見積もるほうが早い
• 僕の理想日と君の理想日は違う
• 理想日の長所
• 理想日はプロジェクト関係者に説明しやすい
• 理想日は導入しやすい
• 私のお勧め

ストーリーポイントと理想日

サイズを測るうえで、ストーリーポイントと理想日にはそれぞれ利点がある。この8章では、どちらを使うかを判断するときに役立つ要素をいくつか紹介していく。

ストーリーポイントの長所

まず、ストーリーポイントによる見積りの重要なポイントを説明する。検討する内容は次の５つだ。

• ストーリーポイントは職能横断的な作業の進め方を促進する
• ストーリーポイントによる見積りは長持ちする
• ストーリーポイントは純粋に大きさだけをあらわす
• ストーリーポイントで見積もるほうが早い
• 僕の理想日と君の理想日は違う

ストーリーポイントは職能横断的な作業の進め方を促進する

• アジャイルなチームが成功する理由の１つは、チームが個々のメンバーの専門分野を超えて職能横断的に機能していることだ。
• 専門分野以外の作業も分担する機能横断型チームを結成した当初は、自分の専門分野へのこだわりをすぐには捨てられないメンバーがいることも珍しくない。メンバーが、自分のことを「なによりもまずプロジェクトメンバーであって、そのうえでスペシャリストとして貢献している」と考えることが出来るようになれば、プロダクトに好影響をもたらす。すなわち「私はテスターであり、いまはナパプロジェクトの仕事をしている」ではなく「私はナパプロジェクトのメンバーとして、テスターをやっている」と考えられるかどうかだ。些細な違いに見えるかも知れないが、この考え方の違いは大きい。
• ストーリーポイントでの見積りは、チームが職能的に仕事を進めていくことを促進する。ストーリーポイントの見積りは、必要な作業全体という大掴みなレベルでの議論になる。これが、理想日での見積りになると、各分野の専門家グループそれぞれが「自分たちの作業」に必要な日数を考えて、それを合計することになりがちである。たとえば、あるストーリーにプログラマは3理想日必要で、データベースエンジニアは1理想日、テスターは2理想日かかるといった場合、見積りはこれらを合計した6理想日になる。
• ストーリーを見積もるときにどう議論したかが、ストーリーを開発する方法に大きな影響を与え続けることになってしまうのだ。

ストーリーポイントによる見積りは長持ちする

• ストーリーポイントは理想日よりも見積りの「賞味期限」が長い。
• 理想日による見積りはチームが経験を積むにつれて変化してしまう。
• ベロシティを計測すれば、この問題を解決できると思うかもしれないが、現実はそううまくはいかない。むしろ、こなせる作業量が増えてもベロシティは変化しないのだ。たとえば、先ほどのプログラマがチーム唯一のプログラマで、１イテレーションの長さは１週間だとしよう。最初のアプリケーション開発の見積りは５理想日だった。このプログラマはカレンダー上の日数と理想日とが一致するような環境で働いているとしよう。この場合、最初のアプリケーションはイテレーション初日に着手し、5日目に完了することになる。このイテレーションのベロシティは5ポイントだ。彼は数ヵ月後には同じサイズのアプリケーションを5つ開発できるのだ。とういことは、1イテレーションの間に同規模のアプリケーションを5つ開発できるのだ。するとやはりこのイテレーションでもベロシティは5ポイントだ。最初のイテレーションの5倍の作業をこなしているにもかかわらず、ベロシティは変らないのだ。チームが新しい技術や業務分野に挑戦しているようなプロジェクトなどでは、この問題が深刻な影響を与えることになる。
• 注意しておくが、ストーリーポイントであれ理想日であれ、サイズが変化した場合には見積りの数値を更新しなくてはならない。サイズが変化するのは、たとえばフレームワークを利用することになった場合などだ。しかし、チームが経験を積み、なにかの作業が熟達したことによって見積りが変わってしまうのは、理想日だけだ。

ストーリーポイントは純粋に大きさだけをあらわす

• ストーリーポイントは純粋な大きさのみを測定する値だが、理想日はそうではない。
• 理想日を大きさの測定に使うこともできるが、欠点もある。７章「再見積もり」で説明したように、開発者のスキルが変化すれば理想日の見積りも変化してしまう。ストーリーポイントではこうしたことは起きない。ストーリーポイントとは大きさそのものである。よって、大きさが変化しない限りはポイントも変らない。これは大きさを測定するうえで理想的な性質である。
• ストーリーポイントが純粋な大きさの測定値であることの２つの利点
  • １つ目：ストーリーポイントは対比で見積もれるという点だ。これまでの研究で「これはあれと近い」と相対的な大きさで見積もるほうが、絶対的な大きさで見積もるよりもよい結果になることがわかっている。いっぽう理想日での見積りでは、どうしてもカレンダーの日付でどれだけかかるかを考えてしまう。
  • ２つ目：ストーリーポイントが純粋な大きさの計測という抽象的なものであれば、現実時間と比較しようとは思わない点だ。理想日で見積もっていると、チームはどうしても現実の日数と比較してしまう。10日間のイテレーションで8理想日分のストーリーしか完了できなかった理由を考えてしまうのだ。

ストーリーポイントで見積もるほうが早い

• ストーリーポイントで見積もるチームは、理想日で見積もるチームよりも短い時間で見積もれる傾向がある。

僕の理想日と君の理想日は違う

• あるストーリーについて、あなたは自分なら3理想日で開発できると考えているかもしれない。いっぽう私は同じストーリーの開発に5理想日かかると考えるかもしれない。あなたも私もおそらく正しい。であれば、お互いが合意に至るにはどうすればよいのだろうか？実装を担当するのがあなたなので、あなたの見積り（3理想日）を採用するというのは１つの落とし所だろう。しかし、それは間違いかも知れない。実際にストーリーを開発しようとした時にあなたの手が空いていなければ、私がそのストーリーを担当するかもしれないのだ。私が担当したら予定よりも遅れてしまうことになる。なぜなら、ストーリー見積りはあなたの見積りで3理想日になっているが、私の見積りでは5理想日かかるからだ。理想日で見積もるチームの多くではこの問題は無視されているが、このことが問題にならないのは、チームのメンバー全員がほぼ同じスキルであるとか、常にペアプログラミングをしているなど、生産性の違いを平均化できる場合に限られる。

理想日の長所

• 理想日による見積りの重要な2つのポイント
  • 理想日はプロジェクト関係者に説明しやすい
  • 理想日は導入しやすい

理想日はプロジェクト関係者に説明しやすい

• 理想日の考え方はとても直感的だ。
• 理想日とは「他の作業をせず、これだけに取り組んだ時に完了までにかかる時間」だ。理想日は直感的なので、だれでもすぐに理解できる。したがってプロジェクトチーム以外の人へも説明しやすい。
• ストーリーポイントを採用した場合は、プロジェクトの部外者に（最初はプロジェクトメンバーにも）、規模の見積りという考え方を説明しなければならない。しかし、これはチャンスでもある。ストーリーポイントの説明をするということは、同時にプロジェクトで採用する見積りと計画づくりの概念と手法を説明することでもあるのだ。不確実性コーン、少しずつ計画を正確にしていくこと、ベロシティの継続的な測定が計画の信頼性を高めることといった考え方を伝える絶好の機会なのだ。

理想日は導入しやすい

• 理想日は説明しやすいだけでなく、導入もしやすい。
• ストーリーポイントによる見積りでは、最初のいくつかのストーリーの見積りでチームに難しさを感じさせたり、不安を抱かせたりすることがある。ストーリーポイントでは「１日を９時〜１７時までとする」といった基準もなければ、最初は比較対象にできる、すでに見積り済みのストーリーもない。チームはいくつかのストーリーを見積もって、自分たちなりの基準を見つけなければならない。
• さいわい、大抵のチームは最初の見積りを素早く、きわめて素早くこなすことができる。１時間もあれば、ストーリーポイントを数年間使い続けてきたかのように、自然と使えるようになる。それでも、最初のいつくかのストーリーの見積りでは不安を感じることだろう。

私のお勧め

• 私のお勧めはストーリーポイントだ。
• 純粋な規模の見積りであることから得られる様々な利点は、採用と根拠として説得力がある。ストーリーポイントによって、チームが得意分野を越えて職能横断的に作業を進められるようになることはとても大きな利点だ。チームの視点が「僕の作業が3理想日で、君の作業が2理想日だから、あわせて5理想日だね」といったものから「だいたいこのストーリーはあのストーリーと似ているから、5ポイントにしよう」へと変わることの影響も大きい。私のストーリーポイントとあなたのストーリーポイントは同じものだが、理想日はそうではない。これもまた大きな利点だ。スキルや経験の異なる開発者同士では、作業の規模なら合意できるが、所要時間については合意できないからだ。
• ストーリーポイントにも欠点はあるが、ほんのわずかである。たしかに、理想日のほうが導入は簡単だ。しかし、ストーリーポイントに感じる不透明さと不便さは一時的なものにすぎないし、プロジェクト関係者への説明では、間違いなく理想日の方が有利である。とはいえ、自分たちが日々使うものの採用根拠が「関係者への説明のしやすさ」というのもおかしな話だ。また、理想日の理解のしやすさが問題を招くこともある。組織によっては、現実日を理想日に近づけるようなプレッシャーをかけられると、現実日で見積もっているのに、それを「理想日」と呼ぶことになりかねない。そうなると「1理想日」は「プロジェクトの作業に6時間、他の作業に2時間費やした1日」になってしまう。
• 私自身も、チームに最初は理想日で見積もってもらうことがある。そうするのはたいてい、規模の見積りと期間の見積りを分けることの利点をチームが受け入れられない場合だ。人によっては、見積りには即座に日付で答えるやり方に慣れすぎていて、いきなりストーリーポイントを使うのが難しいことがある。私はこうした場合は、チームの見積りに最初は理想日を採用する。しかしできるだけ早いタイミングで、次のような質問を繰り返すようにしている。「このストーリーは、5分前に見積もったストーリーに比べてどのくらい大きいですか？」「では、このストーリーはさっき見積もったやつよりちょっと小さいということでしょうか？」といった質問である。こうした質問の意図は、議論の抽象度を上げて、ストーリーの相対的な大きさに付いて話し合うようにしていくためである。画面のデザインに何日、ストアドプロシージャにどれだけ、HTMLを書くのにどのくらいかかるとか、といった具体的な議論から離れて抽象的に議論すると、理想日を使いながらも、見積りと日数とを分けて考えられるようになってくる。