アジャイルな見積りと計画づくり：第2部：規模を見積もる「６章　見積りの技法」まとめ

アジャイル開発

プランニングポーカーがうまくいく理由の１つに「個人の見積りを平均した方がより良い結果を残す傾向があるという研究成果がある。グループで話しあって見積もると良い結果になるのもこれと同じだ」というのがある。私も過去の経験から１人で何かを決めるより、皆で話し合って決めた方が、良い結果を生むと感じる。また、皆で決めたことなので、「自分も賛同したことなのでやろう」という意識が非常に強くなるのもいいなと感じる。人は自分の意見には一番素直だと思います。何かを決めてチームに導入するとき、ここが一番大事だなと思っています。しかし、大きなチームや大きな組織の場合、全員で話し合い合意することは難しくなります。リーダーが最終的には「これでやる」と決めて進めていく必要があります。アジャイルチームは少人数なのでそのようなことは起こりにくいでしょう。それは楽しさの要因の１つなのかなと思いました。

目次

  • 見積りの技法
  • チームで見積もる
  • 見積スケジュール
    • ユーザストーリー、エピック、テーマ
  • 見積り技法
    • 専門家の意見
    • 対比
    • 分割
  • プランニングポーカー
    • 小規模なセッション
    • 実施のタイミング
  • プランにグポーカーがうまくいく理由

見積りの技法

  • 見積もりでも、収益逓減の法則が働くことを忘れないようにしよう。わずかな時間で考えた見積と、長時間悩んだ末に出した見積とがほとんど同じになるのもよくあることだ。
  • 見積にかける労力と正確さの関係を以下の図に示す。このグラフの曲線は、私の経験に周囲との議論の結果を加味したものであって、測定データに基づいたものではない。
  • 労力と正確さの関係への理解を深めるために、例として、去年１年間でクッキーを何枚食べたか見積もってみよう。当てずっぽうのような見積りでよければ、労力は一切不要である。上記図に当てはめると、労力の軸の一番左にいる状態になる。この段階では、見積りに正確さは期待できない。つまりまったく当たらないわけだ。労力の軸を右のほうへ移動するために、30分ほどかけて全国の平均クッキー消費枚数を調べたとしよう。こうすれば、見積りはまったくの当てずっぽうよりも大幅に改善される。もっと正確さを追求してもいい。私の友達や家族に電話をするとか、私がガールスカウトから買ったクッキーの枚数について、彼女らの証言を求めるとか。私を丸１日監視して（１ヶ月ならもっといい）、その観察結果をもとに私が１年間に食べるクッキー総数の近似値を計算することだってできるだろう。
  • 見積りにどのくらい労力を費やすのかは、見積りの目的によって変えるべきだ。ソフトウェアを調達するのに、自分で開発するとか、それとも製品を購入するかを決めたいなら、開発プロジェクトの期間が６ヶ月から１２ヶ月だという程度の見積りで十分だ。
  • 図をよく見ると、いくつかわかることがある。まず、どれだけ労力をかけても、正確さがグラフの上辺に達することはない。いかに時間をかけようとも、見積りはあくまで見積りでしかない。どれだけ作業をかさねたとしても、見積りが完璧になることはないのだ。次に、下辺近くからは、わずかな労力だけで正確さが一気に上昇する。
  • プロジェクトの計画を立てるときには、図のどのあたりを狙うかを検討しておくと良い
  • 多くのプロジェクトが、正確な見積りを求めるあまりに労力をかけすぎて、その結果、グラフの右側、つまり労力に見合った正確さが得られない領域に入り込んでしまっている。こうなってしまう原因は、物事を単純に捉えてしまう考え方にある。すなわち、予算、スケジュール、スコープは事前に確定しなくてはならず、プロジェクトの成功とは、事前に決めた厳密な計画通りのフィーチャを、予算どおり期日通りに納品することだ、という考え方である。こうした考え方は、包括的な要求仕様への捺印や、膨大な事前の分析作業、想定できる全てのタスクを網羅した詳細なプロジェクト計画書を最重要視する風潮へと行き着く。しかし、どれだけ事前作業をこなしたとしても、見積りが完璧になることはない。
  • いっぽうアジャイルチームはこれとは対照的である。彼らは図の左側に近い位置にいることを好む。アジャイルチームは、見積りから不確定要素を取り除くことが不可能だと認識している。それと同時に、少ない労力で大きな効果が得られることも承知した上で、効果的な見積りをしているのだ。
  • 労力/正確性曲線の左下の方に位置していながらも、アジャイルチームはより信頼のおける計画を立てられる。これは、きちんと動作するテスト済みのフィーチャを、少しずつ頻繁に統合して提供するという進め方のおかげだ。

チームで見積もる

  • 見積りを出すのは、チームの誰かひとりだけではない。
  • アジャイルチームは見積りを専門家に一任しない。
  • 他の誰よりも作業する当人が正確に見積もれるということはよく知られれている。それでも、見積りはチーム全体で出した方が良い。これには２つ理由がある
    • １つ目：アジャイルプロジェクトでは誰がどの作業をするのか事前にはわからないことが多い。ある作業を担当する可能性は全員にあるのだから、見積りにも全員が関与すべきだ
    • ２つ目：作業を担当するメンバーがデータベースに一番詳しいからといって、他のメンバーがその見積りに意見がないとも限らない。

見積スケジュール

  • 人は10倍以内のものならうまく見積もれる、という研究がある
  • 10倍以内からうまく見積もれるというのならば、見積り対象をその範囲に収まるようにしたい。私が使ってうまくいっている見積りスケールは、次の２つだ。
    • 1、2、3、5、8
    • 1、2、4、8
  • これらの数字にはそれぞれ理由がある。
    • １つはフィボナッチ数列だ。フィボナッチ数列は、見積り数字として最適だ。この数列は、数の増える間隔が適切に広がっていく。１と２の間、２と３の間の間隔は１。これは使い勝手が良い。同様に、３から５の間隔や５から８の間隔も見積りの数値として扱いやすい。２つ目の数列は、それぞれの数が直前の数の２倍になっている。こうした非線形の数列も、見積りのスケールにふさわしい。見積りの対象が大きくなると不確実性が増えていくという様子にうまく対応しているからだ。見積りにはどちらの数列を使ってもよいが、私はどちらかというとフィボナッチ数列をよく使う。
  • 見積りスケールの数値は、その大きさの仕事がちょうど入るバケツだと考えると良い。そして、バケツに入れる仕事は水というより砂のようなものだと考えよう。たとえば、１，２，３，５，８という数列を使って見積りをしていて、他の５ポイントのストーリーよりもほんのちょっとだけ大きいストーリーがあったとしよう。この場合の見積りは５ポイントにしておけばいい。なぜなら、５ポイントのバケツに５ポイント分よりも少し多めに砂を入れたとしても、砂がバケツからあふれることはないからだ（砂が多少盛り上がることにはなるだろう）。一方、あるストーリーの大きさを７ポイントぐらいだと思ったのなら、見積りは８ポイントにする。５ポイントのバケツに７ポイント分の砂はどうやっても入りきらないのだ。
  • 見積りに使える値、ゼロ（０）
    • まったく作業をしなくて済むユーザーストーリーやフィーチャはめったにないが、見積りにゼロを使えると便利なことも多い。それには２つ理由がある。
    • １つ目：すべてのフィーチャを10倍以内に抑えるためだ。非常に小さなフィーチャを１としてしまうと、その１０倍の大きさのフィーチャまでしか見積もれない
    • ２つ目：作業量が本当に１よりも０に近い作業を、ベロシティの算出対象に含めると不都合が生じるからだ。たとえば、現在のイテレーションで本当に小さなフィーチャで１ポイント余分にベロシティを稼いでしまったとしよう。次のイテレーションでも同じポイントの仕事ができるかというと、そうはならない。前のイテレーションで見込まれた追加の１ポイント分の作業をこなせないと、ベロシティが下がってしまう。それを防ぐには、無理をしてでも１ポイントに相当する仕事をこなすしかない。
  • ゼロを採用する以外の方法では、小さすぎるストーリーをいくつかまとめて１つのストーリーにして見積もるというやり方もある
  • 10、20、30、50、100のように、もっと大きな数を採用するチームおまる。数こと大きいが、10を基準に10倍以内に収まっているので問題ない。ただし、10から1000のような大きい数を採用する場合でも、見積りのスケールに使える数値はあらかじめ決めておくのが良いだろう

ユーザストーリー、エピック、テーマ

  • エピック
    • 一般的にユーザーストーリーの見積りは、10倍以内の範囲に収めるのが望ましいが、いつでもそうできるわけではない。何もかもを10倍以内の大きさで見積もれるようにするには、すべてのストーリーをかなり細かい単位で書かなければならない。必要かどうかまだわからないフィーチャ（投資してしまう前にコスト見積もりだけしておきたい）や、近い将来には開発予定のないフィーチャは、もっと大きな単位で見積もるユーザーストーリーを書きたいことも多い。こうした大きなユーザーストーリーをエピック（epic=叙事詩、大長編）と呼ぶ。
  • テーマ
    • また、関連するユーザーストーリーをまとめて（紙のカードに書いているならペーパークリップにたばねればいい）、１つのものとして見積りやリリースプランニングで使いたいことがある。こうしてまとめたユーザーストーリーはテーマと呼ぶ。エピックは、単体でもサイズが大きいので、エピックがそのままテーマになることも多い
  • テーマやエピックの見積りは、より明確で小さなストーリーの見積りよりも不正確になることを忘れてはならない
  • 近い将来（次の数イテレーション以内）に実装予定のユーザーストーリーは、１回のイテレーションで完了できるくらい小さくなっている必要がある。こうしたストーリーは10倍以内の範囲で見積もる。着手が数イテレーション以上先になるものは、エピックやテーマのままでよい。

見積り技法

もっともよく使われるの見積り技法は以下の３つだ。

    • 専門家の意見
    • 対比
    • 分割

専門家の意見

  • 専門家に聴くのも立派な見積り技法の１つだ。専門家は自分の勘や、受けた印象にしたがって見積りを出す。
  • このやり方は、従来型のプロジェクトはともかく、アジャイルプロジェクトではあまり役に立たない。フィーチャの開発には、１人ではまかないきれない様々なスキルが必要となる。そのため、すべてのスキルを持ち、全体を見積もれるような専門家はなかなか見つからない。従来型のプロジェクトでは、このような問題は起こりにくい。なぜなら従来型プロジェクトでの見積り対象はタスクであり、個々のタスクごとに担当者を割り当てるからだ。
  • 専門家の意見が見積り技法としてなかなか優れている点は、あまり時間がかからないことだ。
  • 開発者がユーザーストーリーを読み、いくつか質問をしたら、あとは直感で見積もりを出すだけである。こうした手法が分析的な手法より正確である、とする研究もある。

対比

  • 対比とは「このストーリーはあのストーリーより少し大きい」と考えるやり方だ。
  • 対比による見積りでは、見積り対象のストーリーと比べる。
  • 絶対的な大きさによる見積りよりも、相対的な大きさで見積もったほうがより正確な見積もりになるという研究結果もある
  • 新しく追加されたストーリーを見積もるにあｈ，いままでに見積もったストーリーのいくつかと比較するのだ。このやり方を三角測量（triangulation）と呼ぶ。三角測量と呼ぶのは、見積り対象のストーリーを他の複数のストーリーと比較することから来ている。

分割

  • 分割とは、１つのストーリーやフィーチャを、見積りやすいように小さく分けることだ。
  • あるプロジェクトで、ユーザーストーリーのほとんどが２日から５日で開発できるような大きさだとすると、そこに１００日前後の巨大なストーリーがあっても見積もることは難しい。そもそも大きなものは見積もるのが難しいのｄが、この場合はそれに加えて、他のストーリーがずっと小さいので、この巨大なストーリーと直接比較できるストーリーがないからだ。「このストーリーはあのストーリーの50倍か？」と聞くのは、「このストーリーはあのストーリーの1.5倍か？」と聞くのとはわけがちがう。
  • 解決策はもちろん、大きなストーリーやフィーチャをいくつかに小さく分割したうえで、それぞれを見積もることだ。ただし、やり過ぎには気をつける必要がある。タスクを分割しすぎると、数が多くなって見落とす危険性が高まるだけでなく、見積りでの合計でも問題が起きる。ユーザーストーリーの分割については、12章「ユーザーストーリーの分割」で詳しく紹介する。

プランニングポーカー

  • 私が色々試した結果、アジャイルチームで一番うまくいくことが分かった見積り技法が、プランニングポーカーである
  • プランニングポーカーは、専門家の意見、対比、分割のすべてを組み合わせ、楽しみながら迅速かつ信頼できる見積りを出せる
  • プランニングポーカーの参加者はチームの開発者全員である。ここで開発者というとき、そこにはプログラマー、テスター、データベースエンジニア、アナリスト、ユーザーインターフェース・デザイナなど、すべての担当者が含まれることを忘れないで欲しい
  • アジャイルプロジェクトでは、プランニングポーカーに10名以上が参加するこはまれだろう。参加人数がそれ以上になるようであれば、ポーカーのチームを２つに分割したほうがよい。分割されたチームそれぞれが独立して見積もることで、各チームの見積りセッションへの参加人数を抑えられる。
  • プロダクトオーナーはプランニングポーカーに参加はするが、見積りそのものには関与しない
  • プランニングポーカーの準備
    • まず最初に、見積に参加する全員（これを見積り担当者と呼ぶ）に一組のカードを配る。配られたカードの表にはチームで使用できる見積りポイントが1枚につき１つずつ書かれている。たとえば「０，１，２，３，５，８，１３，２０，４０，１００」という１０枚のカードだ。カードは事前に準備すること。カードの数字はテーブル越しでも大きく読めるくらい大きな文字にすること。
  • プランニングポーカーの進め方
    • まず、進行役となる人が、見積り対象のユーザーストーリーやテーマを１つずつ読み上げる。進行役に特別な権限はない。だれが担当しても良い。プロダクトオーナーの役割は、見積り担当者たちから出されるあらゆる質問に回答することだ。
    • ここで参加者全員が肝に銘じておくべきことがある。労力 / 正確性曲線（下記図）だ。プランニングポーカーのゴールは、今後絶対に問題が発生しないような精微な見積りを出すことではない。プランニングポーカーのゴールは、労力ライン上の左上のほうにある点に辿りつくこと、つまり低コストで価値のある見積りをだすことなのだ

    • プロダクトオーナーとの質疑応答が完了したら、見積り担当者は、自分がこうだと思う見積りポイントカードを選ぶ。選んだカードは全員が選択し終えるまで人には見せないようにする。
    • 全員の見積りが決定したら、一斉にカードをオープンする（「せーの」などと声をかけるとよい）。そして、参加者全員がお互いの見積りポイントを確認する
    • この時点では、人によって見積りが大きく異なって当然だ。これは歓迎すべきニュースととらえるべきだ。見解の相違から学ぶチャンスだからだ
    • 見積りが異なるのであれば、高い見積を出した参加者と低い見積りを出した参加者のそれぞれに、見積りの根拠を説明してもらう。
    • 注意を１つ。説明を求めるとき、見積もった人を非難しているようにみえてはならない。高い見積りや低い見積りを出したときに何を考えていたのかを聞き出そうとする姿勢が大事だ
    • ストーリーと見積りにつのての議論は、数分程度でかまわない。議論を終えたら、見積り担当者はそれぞれに再び見積りポイントカードを選ぶ。
    • 多くの場合、見積りは第２ラウンドで収束する。収束しなければ、ここまでの手順をふたたび繰り返す。
    • この手順のゴールは、あるストーリーの見積りポイントについて全員が合意することにある
    • 見積りセッションが４ラウンド以上になることは稀だが、プロセスを長く続けていけば、やがそれぞれの見積り値は近づいていく。だからといって、全員が同じカードを選ぶことは必須ではない。たとえば４名の見積り担当者が「５，５，５，３」という見積りポイントを選んだとしよう。このとき私なら、いちばん低い見積りポイントを選んだ担当者に、見積りを５ポイントにｓても構わないか、と確認する。繰り返しになるが、見積りでは絶対的な精度は重要ではない。妥当な労力に見合った妥当な結果を出すことが重要なのだ
    • 議論が長引くと上記図の右の方へいってしまう。議論を長引かせないために、２分計の砂時計を購入して、プランニングポーカーのセッション中にはテーブルの中央に置くのだ。砂が尽きたら、次のラウンドに進む。

小規模なセッション

  • プランニングポーカーを、チーム全員ではなく一部のメンバーだけでおこなうこともありえる。もちろん理想はチーム全員だ。しかし現実的には、一部のメンバーで行なったほうがよい場合もある。とりわけ、新規プロジェクトの開始段階でありがちな、見積もるべき項目が多すぎる状況には有効である
  • プランニングポーカーのセッションを小規模にする最善の方法は、大規模なチームを２つか３つに分割することだ。分割された各チームのそれぞれには、少なくとも３名の見積り担当者が必要である。ここで重要なのは、分割したチームの間で見積りが一貫していることだ。
  • 見積りに一貫性をもたせるためには、最初に１時間ほど費やして、全チームが一緒にプランニングポーカーを実施するとよい。そのときには１０から１２のストーリーを見積もること。その後でチームごとに別れて見積りを行う。最初に見積もった結果を、チームごとでの見積りのベースラインとするとよいだろう。おの共通のベースラインを使って各チームが見積もれるわけだ

実施のタイミング

  • プランニングポーカーを実施するタイミングには２種類ある。
    • １つ目：プロジェクトの開始前か、最初のイテレーション。ここでは、たくさんのストーリーを見積もらねばならない。最初に提示されるユーザーストーリーやテーマをすべて見積もるには、１〜３時間のミーティングを２〜３回実施することになるかもしれない。もちろん実際の所要時間は、毎回変わってくる。
    • ２つ目：イテレーションの途中で新しいストーリーを発見した場合だ。各イテレーションの終盤に、ごく短い見積りミーティングの実施をあらかじめ計画に組み入れておくことだ。これはイテレーション中に発生した作業を効率的に見積もることに最適の方法だ。しかも、今後のイテレーションで実施する作業との間で優先順位も考慮できる
    • ケント・ベックはこれとは別のやり方を提案している。新規ストーリーを入れるための封筒を壁に留めておくのだ。個人の作業時間に少し空きができたら、封筒から１つか２つのストーリーを抜き出して、個人的に見積りを出す。チームがこの方法を採用するなら、自分たちなりのルールを確立しておこう。よくあるルールは、すべてのストーリーを入れておくために、封筒を壁に留めるというのはよいアイデアだと私は思う。しかし、私が実際にやるなら、単独で見積もるのではなく、少なくとも誰かもう一人、手の空いている人を見つけて、一緒に見積もるというルールにするだろう

プランにグポーカーがうまくいく理由

  • ４つある。
    • １つ目：プランニングポーカーには複数の専門家の見解をまとめた見積りを実現する。ここでの専門家とは、ソフトウェアプロジェクトに必要なあらゆる分野から集められた職能横断型チームのことである。タスクの見積りをおこなうのにふさわしいのは、他の誰よりも彼ら自身である。ヨルゲンセンはソフトウェアの見積についての文献を徹底的にレビューしたあとで、「タスクを担当する人々こそが、見積りをおこなうべき人物としてもっとも適任である」と結論づけている
    • ２つ目：プランニングポーカーは活発な対話を引き出す。見積り担当者は同僚から、自分自身の見積り根拠の説明を求められる。これには見積り精度を改善する効果がある、とりわけ不確実性の大きい項目に対して有効である。見積について説明するよう求めると、情報の不足を補ったよりよい見積りになるという効果もある。アジャイルプロジェクトでは、往々にして、ユーザーストーリーには意図的に曖昧さを含んでいるため、この効果は重要である
    • ３つ目：個人的見積りを平均した方がよりよい結果を残す傾向があるという研究結果がある。グループで話しあって見積もると良い結果になるのもこれと同じだ。グループで話し合うことがプランニングポーカーの基礎であり、議論することを通じて個々人の見積りがならされていくのである
    • ４つ目：プランニングポーカーがうまくいく最後の理由は、それが楽しいからã