コンサルタントとして働くことの最大の喜びの一つはいろいろなアイディアを試してみてからことが上手くいくように自分が一番好きな方法を適用することができることです。この記事では私が効果的だと思うユーザ・ストーリーの（開発工数）見積もりテクニックの詳細について述べています。
２乗の法則
もともと私はユーザ・ストーリーを1、2、3、4とか小、中、大、特大といった風に見積もっていました。この場合、中は小の2倍の大きさ、大は中の2倍の大きさ、といったことを意味していました。ところが、（開発の）計画の段階になると正しく解釈されたことがなかったようです。そんな時、ある人に２乗の法則を使ってみることを勧められました。途端、業務担当者も理解できるようになったのです。彼らは8が1よりもかなり大きいということを知っていたのです。(1、2、3、4より)1、 2、 4、 8の方がより効果があると思います。ストーリーが大きくなればなるほど未知のリスクが含まれているものです。２乗の法則は大きなストーリーに含まれるリスクを強調してくれるのです。
４つの値
ある時、1、2、4、8を見積もりの値として利用しているプロジェクトに参加していました。最初の2回分の見積もり会議が終わった頃5%にも満たないストーリーが1と見積もられ、30%位が2と見積もられていました。そこでプロジェクト・マネージャは自分がラクをするために1という見積もりを廃止することにしました。すると、その後の見積もり会議で面白いことが起きたのです。突然5%のストーリーだけが2と見積もられるようになり、多くのストーリーが4と見積もられるようになりました。開発担当者たちが意識的に規模を変更したとは思えません。しかし、開発担当者たちは懐疑的な気持ちになり調節したのです。何人かの開発担当者は全てのストーリーが最小の規模で開発できる位に簡単であると伝えようとしました。いくつかのプロジェクトでこのような状況を経験した後、私は最低でも4つの（見積もりの）値を使うようになりました。そして、最大でも4つの値です。要するにただの見積もり以上の何ものでもないのです。もし見積もりに過剰な精度を要求したらなぜ見積もりを間違えたのか考えることに終始してしまうでしょう。大雑把なアイディアを得ることが大切なのです。それに頼っていかなければならないような厳密な計画ではありません。
平均や選択肢にない値は不要
4つの値によって精度を追求するあまり見積もりに無駄な時間を費やすことはなくなります。時には2より大きいけど4より小さいと感じるストーリーもあるでしょう。でも、3と見積もってはいけません。3を使わなければならない理由なんてどこにもないのです。そのストーリーには2ではない量のリスクか未知なるリスクが含まれているのです。従って4になるのが当然なのです。平均をとったり（見積もり規模の）選択肢にない値を利用することは間違いなく（そして不必要にも）チームやステーク・ホルダーに混乱をもたらします。さらにプロジェクト全体の観点から見れば選択肢にない数値を使ったところで大きな違いにはなりません。シンプルにしておくべきです。規則通りにやりましょう。
別々に投票する
他人の影響を受けるのが人情というものです。技術リーダがあるストーリーが2であると言えば、チーム内の他のメンバはそれに従うものです。このような理由から私は各チーム・メンバが別々に見積もりを投票する方法がいいと思います。紙切れを用意してみんなの準備が整うまで誰にも見せないようにすればこれは実現できます。各自の見積もりをジャンケン方式(RPS)で出し合うやり方も私が好きな方法です。私達の見積もり会議では全員が見積もりできるまでストーリーについて話し合い、その後グー・チョキ・パーを出し合うようにそれぞれの見積もりを出し合います。"見積もりを出し合う"というのは、1だと思えば指1本を、2だと思えば指2本を、4だと思えば指4本を出すという意味です。8を出したければ必要があれば両手を使えばいいのです。
一番大きい見積もりを選ぶこと
注意していても、開発担当者たちはついつい苦労をかけて見積もりをするもののようです。ある開発担当者が1日で開発できると思えば指1本を出します。不幸にもその開発担当者がこのストーリーを任されなかったとすると、他の2あるいは4と見積もったメンバがこのストーリーを担当することになるのです。私はいつもメンバが出した見積もりの中で一番大きな見積もりを採用することにしています。インチキだと思われるかも知れません。しかし現実にそれぞれのメンバは別々のリスクを考え、ひょっとすると最大の見積もりを出したメンバは他のメンバが考えなかったリスクについて正確に見積もったということも考えられるのです。
一番大きい見積もりを採用することには別の利点もあります。もし小さい見積もりを採用するとしたらそれより大きい見積もりをしたメンバはなぜそのような見積もりとなったのかを話し合うことになります。チーム内で経験の少ないメンバにとってこの話し合いは不愉快なものとなるかも知れません。開発言語や開発ツールの利用経験が浅いので、そのようなメンバはどうしたら素早く終わらせることが出来るのか分からないのです。そのようなメンバの考えは自分たちのスキル・レベルに応じた考え方をしているのです。なぜ高い見積もりになったのかという話し合いが嫌で正直な見積もりを出すことに不愉快な思いをすることになるというのはとても不幸なことです。
高い見積もりと低い見積もりのどちらを採用するのかを話し合うということは結局見積もりを引き上げることに繋がるか、自分たちの見積もりを引き下げることでそのような高い見積もりを出した開発担当者に不愉快な思いをさせることになるのです。いずれにしろもう少し長い時間をかけて話し合いをすることになりますが、特に何も得るものないのです。結局問題は残るのです。開発速度*の追跡結果を元に各イテレーションでどれだけのストーリーを完成させなければならないのは分かっているはずです。従って、例え見積もりが"太りすぎ"ていても開発速度はなるべきようになるので結局のところ計画には何ら影響を与えないのです。
要するに、一番大きい見積もりを採用することで見積もり会議の時間を抑えることができます。もしあるストーリーの見積もりが8だと思うメンバがいればそのストーリーについて話し合っているときにいつでも8を出すと宣言することが出来るのです。見積もりに大きな隔たりがあると思うメンバがいない限り話し合いを続ける意味はないのです。結局最終的には8になるのです。
隔たりの大きい見積もり
見積もりの際に、チーム全体がストーリーの規模について合意するというのは稀なことです。先にも述べたように、私は常に一番大きい見積もりを採用することでこの問題を解決します。ところが、大きな隔たりが誤解を表していることもあります。このような理由から見積もりに2段階以上の差が生じた場合には常に追加的に話し合いをすることになります。(例えば、もしあるメンバが1を出し、他のメンバが4を出した時には説明してもらう必要があります）。大きな隔たりについて話し合うことで一番大きな見積もりの採用が多発することを防ぐことにもなります。
不十分な情報
時には見積もりが決まらないまま会議を終えることもあるでしょう。そのような場合、納得のいかない見積もりを出すことよりはもっと情報を求める方が賢明です。8という見積もりはそのストーリーが大きなものだということを暗示していますが、それは4の2倍の時間が掛かるだろうということです。従って、明白になっていないストーリーを安易に8と見積もりのは止めましょう。なぜなら、それは4と見積もられたストーリーを2つ完成させるのと同じだけの時間が掛かってしまうということを意味しているからです。見積もり会議の目的は全てのストーリーを見積もることではないのです。十分な情報が提供されているストーリーについて見積もりを提示するのが目的なのです。
積極的に参加させる
楽しんで見積もり会議に臨む人はいません(失礼、少なくても私の周りにはいません)。私が過去に参加したプロジェクトでは読むのが一番速い人がストーリーを読み上げ、開発担当者がその分野のエキスパート(専門家)に質問をします、その後で開発担当者が見積もるのです。開発担当者が専門家に質問をしていない間、通常ですと専門家は自分たちのノート・パソコンで他のことをしています。最初のうち、これは彼らが時間を有効利用するいい方法だと考えていました。でも、違ったのです。その後参加したあるプロジェクトで、マネージャは自分たちの番が来たら全員にストーリーを読ませるために部屋を巡回することを私達に対して指示しました。その途端、専門家は集中するようになりました。自分達がストーリーを読む番のときにぼーっとしているように見られたくないからです。みんなが積極的に参加することで会議はとても有意義なものになったのです。
豚と鶏の例え話
豚と鶏の例えで言えば、ハムと卵を出すレストランでは豚は仕事に打ち込んでいるが、鶏はただ参加しているだけです。
しばしば、開発担当者は豚で業務担当者は鶏の集まりだから業務担当者は開発担当者の見積もりに口出ししてはいけないと耳にします。これは悪い比喩だと思います。これはまるで低品質な製品のせいで技術担当チームではなく業務担当チームがクビにされるようなものです。勿論、業務担当者も仕事に打ち込んでいることだと思います。しかし、業務担当者が見積もりの邪魔をするというのは利益相反なのです。
業務担当者は次のイテレーションでどんな機能が完成するのかを知りたいだけなのです。次に何が見積もられる必要があるのかを知りたいのです。業務担当者はコードを書かないので、適切な見積もりには貢献できません。(実際の見積もりに)関与させられるほど、彼・彼女らが現実的な見積もりを手にすることが難しくなるのです。優れた専門家は会議で質問に答えることはしますが、与えられたストーリーの見積もり結果に対して何かしらを主張することは決してありません。
見積もりをするグループの規模
いろいろな規模のチームがあります。(6名以下の)小さいチームでは全員が見積もり会議に参加するのがいいと思います。様々な視点があることによって方向性が固まり、見積もりに貢献することになります。しかし、ある人数を超えると効果が減少すると思います。大きなチームでは全てのストーリーの見積もりに全員が参加する必要はありません。見積もりなのです、6人の(見積もりの)精度は15人の精度と変わらないでしょう。もしあなたのチームが6名より多いのなら見積もりの際には小さなグループに分割することを提案します。たいてい私の場合はどんなストーリーの見積もりであっても最低で3名のメンバがいるといいと思います。しかし6名より多くのメンバは不要です。
追加されたストーリー
ストーリーは2つの方法で追加されます。新しい機能の要求とストーリーの分割です。私は追加されたストーリーについてはその優先度に応じて見積もりを遅らせることにしています。そのストーリーが次のイテレーションで完成させなければならないものならば、大抵は早急な見積もりを必要としています。一方でそのストーリーがいくつか先のイテレーションまで手を付けなくていいものならば、見積もり会議を開く必要性が生じるまで見積もりを遅らせることには意味があります。打ち合わせ会議で決めた見積もりの方がより信頼性が高いということに気が付きました。それはみんなが見積もりだけに集中している環境から出された数値だからです。分割によって追加されたストーリーにはさらに複雑です。それは既に一度見積もられているようなものなのです。前回の見積もり結果は無視して新たに見積もることを強く提案します。あるストーリーが大きなリスクを抱えていたのかあるいは不確定なために分割する必要が生じたのか、いずれにしても元の見積もりは現実的ではないのです。元の見積もりは無視して下さい。
ノート・パソコン禁止
開発担当者はノート・パソコン禁止です。ストーリーの一覧を印刷して全員に配布しましょう。あるいは一覧をプロジェクタで投影しましょう。しかし、決して開発担当者にノート・パソコン上のストーリーを読ませてはいけません。ノート・パソコンは往々にして開発担当者の気を散らし、会議の目的を忘れさせます。価値ある見積もりを得ることです。
参加は必須
これはとても重要な提言になります。通例ではチーム外部の開発担当者は見積もり会議に参加させないべきであるとされています。これは見積もり会議に参加した全ての開発担当者がそこで見積もられる何らかのストーリーを担当する可能性があるということです。もしある開発担当者があるストーリーの見積もりで不愉快な思いがするのであれば、私はその人にそのストーリーを任せることに不愉快な思いをします。もちろん、例外があります。私は新しいチーム・メンバにはたいてい見積もり会議への参加を依頼する前に1週間の時間を与え予習してもらうようにしています。しかし一般的には見積もり会議への参加を拒む開発担当者はより大きな問題を抱えているという合図を送っているのかもしれないのです。
陳腐化する見積もり
チーム編成は変化し、プロジェクトも変化し、不規則にイベントが発生します。理由が何であれ見積もりは陳腐化する可能性があります。陳腐化した見積もりは誰の役にも立ちません。開発担当チームは陳腐化した見積もりを守るためにプレッシャーを感じます。業務担当者は計画された速度でストーリーが完成していくことを期待します。何で見積もりが陳腐化するのかは問題ではありません。問題なのは陳腐化した見積もりはもはや現実的ではなく、計画も信頼には値しないということです。12-24週の間に見積もりが陳腐化しなかったプロジェクトに参加したことがありません。精密でない情報に基づいて計画を立てるより見積もりが陳腐化したということを事実として認めた方がいいでしょう。このような理由から私は12週間以上経過した見積もりは全て再検討することを提案します。もしかしたらその見積もりはまだ正しいかもしれません、しかし、新しい情報について開発担当者に話し合わせる機会を与えることは間違いなく業務上有益なことなのです。
えさを使う
これが一番簡単な提案になります。見積もり会議には高級なお菓子を差し入れましょう。科学的に糖分は幸福間と関連があり、幸福感は協調を生みます。これが見積もり会議を前向きなものにする一番簡単で安上がりな方法なのです。高級なというのが鍵であることを覚えておいて下さい。普段からチーム・ルームにあるようなお菓子を差し入れても少しも刺激的ではありません。私の直近のプロジェクトでは会議があると記憶していたときは必ずパン屋へ行き新鮮な焼き立てのクッキーの詰め合わせを買ってました。
謝辞
これらのアイディアは具現化し発展させることに協力していただいたBrent Cryder氏, Dennis Byrne氏, Fred George氏, Joe Zenevitch氏, Mike Ward氏, そしてSean Doran氏に感謝します。他のリストと同じように私のリストからも多くの貢献者の名前が漏れています。そのことをお許し下さい。
筆者について
Jay Fields氏はThoughtWorksで勤務するソフトウェア開発者であり、コンサルタントです。革新的なソリューションの発掘とそれを発達させることに情熱を注いでいます。直近の成果はDomain Specific Language領域におけるもので、専門家が自らドメイン・ロジックを記述できるようにするアプリケーションを開発しました。さらに開発者によるテストやソフトウェア・テストを通じてソフトウェアの設計を発達させること全般にとても興味を持っています。
*開発速度：それまでに完了した(ストーリー)ポイントの数をイテレーション数で割った値。例えば、5回のイテレーションで20ポイントを完了させたのならその開発速度は4になる。4という開発速度では1つのイテレーションで見積もりの合計が4になる分量のストーリーを完成させると予想できる(例えば、4と見積もられた1つのストーリーか、2と見積もられた2つのストーリーか、4と見積もられた1つのストーリーなど)。
コンサルタントとして働くことの最大の喜びの一つはいろいろなアイディアを試してみてからことが上手くいくように自分が一番好きな方法を適用することができることです。この記事では私が効果的だと思うユーザ・ストーリーの（開発工数）見積もりテクニックの詳細について述べています。
原文はこちらです：http://www.infoq.com/articles/agile-estimation-techniques
（このArticleは2008年6月30日に原文が掲載されました）