見積もり

Mitch Lacey 著アジャイルとスクラムの導入と改善に特化したコンサルティング会社である Mitch Lacey & Associates, Inc の経営者です。

2012 年 1 月

Mitch Lacey 氏が、ソフトウェア プロジェクトの見積もりに関する難しさについて解説し、プロジェクトを見積もるときの 2 種類のアジャイル ソフトウェア見積もり手法の使用に関するヒントを示します。

対象

アプリケーション ライフサイクル管理; Team Foundation Server

内容

• Introduction

• 見積もりが難しい理由

• 見積もりの手法

• 測定単位としてのストーリー ポイント

• プランニング ポーカー

• 壁の見積もり

• 見積もり

• 優先順位付け

• まとめ

的創造で予測不可能な作業を見積もることは、間違いなく困難です。見積もり手法の選択にも同じように苦労する場合があります。Fred Brooks がこのことをうまく表現しています。「定量的ではない方法によって導き出され、わずかなデータによって支持され、主としてマネージャーの直感によって保証されているような見積もりを、積極的に、もっともらしく、仕事のリスクを負いながら擁護することは、非常に困難である。」

それでも、ソフトウェア プロジェクトの見積もりを事前に早く提出するように要求されます。そして、見積もりは概算であることを管理者に思い出させようといくら努力しても、たいていは最初の見積もりが約束事になってしまいます。

この記事では、プロジェクトの事前見積もりが困難な理由、アジャイル ソフトウェア見積もり手法の効果、プランニング ポーカーおよびストーリー ポイントを使用してプロダクト バックログを見積もる方法を説明します。

見積もりが難しい理由

ほとんどのプロジェクトでは、事前に見積もりを求められます。これが問題であることを理解するには、Barry Boehm が 1981 に提唱し、Steve McConnell が 1997 年に出版した『Software Project Survival Guide』で再度取り上げた不確実の円すいについて調べる必要があります。

この円すいは、すべてのプロジェクトの開始時に最も不確実性が高いことを示しています (4 ～ 0.25 倍の範囲の変動)。この変動は、1 年間と見積もったプロジェクトが、実際には 3 ～ 48 か月の範囲で終了する可能性があることを意味します。すべてのプロジェクトの開始時は、プロジェクトのことが最も不確かなときですが、同時に非常に精度の高い見積もりを提出するように要求されるときでもあります。

アジャイル方式では、できる限り短いサイクルで不確実なことを確実なことに変えようとします。これは、システムおよびその設計方法についての早期学習を最大にすることによって実現されます。そのためには、システムを通過する 1 つの完全な動作するストーリーを作成します。これを使用して設計と要件の前提を早期に洗い出すことで、より短期間で状況を確実なものにし、信頼性を高めることができます。

見積もりの手法

カウント、専門家による判定 (個人とグループ)、分解、類似、プロキシ見積もり、プランニング ポーカー、壁見積もりなど、有効な見積もり方法は多彩です。また、Cocomo II. などのツールも使用できます。これらの手法のいずれでも、見積もりの単位 (時間、日、週、月、理想的な日数、T シャツのサイズ、ポイント、またはこれらすべて) を選択する必要があります。単位を理解していないと、見積もりは何も意味しません。このすべてを考慮するのでは、見積もりに苦労するのも当然です。

アジャイル チームはプロダクト バックログの見積もりに特定の見積もり単位と手法を好みますが (ストーリー ポイントや、プランニング ポーカー)、ニーズに最も適した方法を自由に選択する必要があります。私の経験では、ストーリー ポイントで見積もりを表し、プランニング ポーカーまたは壁見積もりを使用すると最善の結果が得られます。以下では、測定単位としてのストーリー ポイント、および筆者が好み 2 つの見積もり手法であるプランニング ポーカーと壁見積もりについて説明します。

測定単位としてのストーリー ポイント

Mike Cohn は、ストーリー ポイントを "ストーリー ポイントは、ユーザー ストーリー、機能、またはその他の作業のサイズ全体を表す測定単位である。" とうまくまとめています。ストーリー ポイントは、サイズまたは複雑さを使って、あるストーリーが他と比較してどの程度大きいかを教えてくれます。Mike は、相対的なサイズの概念をチームに理解させるために "ドッグ ポイント" とよく呼びます。2 ポイントの (小さい) 犬はチワワです。13 ポイントの (大きい) 犬はグレートデーンです。これら 2 つの基準を念頭に置くと、チワワまたはグレートデーンを基準にして他の犬種のサイズを容易に判断できます。ビーグルはチワワの約 2 倍なので 5 くらいです。ラブラドールはビーグルより大きく、グレートデーンより小さいので、8 くらいです。

ストーリー ポイントの使用方法を初めて学習するときは、チームで独自の固定比較ポイントを確立する必要があります。そのためには、プロダクト バックログから、全員が小さいことに同意するストーリーと (サイズまたは複雑さに関して)、全員が大きいことに同意するストーリーを選択します。私は、小さいストーリーを 2 ポイントのストーリーにするのが好きです。そうすれば、さらに小さくすることができますから (トイ チワワが見つかった場合など)。最小の既知のストーリーを 1 ポイントのストーリーにすると、さらに小さいストーリーが必要なときに困ります。他のストーリーのサイズはこれらを基準にして決定することができます。

これらのサイズを表す値の選択に関しては、フィボナッチ数列が最適であると思います。フィボナッチ数列は、各値が前の 2 つの数値の和になっています。つまり、1 と 2 の次は 3 です。3 と 2 の次は 5 です。5 と 3 の次は 8 です。以下同じように続きます。人間は 10 を基準にすることに慣れているので、私はたとえば T シャツのサイズや指数的増加 (4/8/16/32/64/128/256 など) よりフィボナッチを好みます。その範囲を超えてしまうと、またはたとえば xs、s、m、l、xl などでは範囲内であっても、混乱してしまいます。フィボナッチ数は単純で、簡単に理解でき、相対的な見積もりを提供するという目的には十分に正確です。別の値の組み合わせを選択することもできますが、一貫性が重要であることを忘れないでください。

ストーリー ポイントは相対的な値であり、固定値ではありません。時間とポイントの間に直接的な相関関係はありません。たとえば、2 ポイントのストーリーは 12.2 時間に等しい、といったことは、どのような確かさでも言うことはできません。同じ 2 ポイントの範囲のストーリーでも、完了までに実際にかかる時間は大きく異なるからです。同様に、あるチームのストーリー ポイントと別のチームのストーリー ポイントは、どのような確かさであっても比較できません。ストーリー ポイントは、それを推定して作成したチームに固有のものであり、そのチームによってのみ理解される複雑さの程度が含まれ、それは絶対的なものではありません。

プランニング ポーカー

測定単位を選択し、スケールを設定したなら、次に見積もりを行います。ほとんどのアジャイル チームは、ストーリーの相対サイズを見積もるために、プランニング ポーカーを使用します。プランニング ポーカーがアジャイル チームに人気があるのは、類似性や専門家による判定などの主観的な見積もり方法を含む客観的な測定であるためです。プランニング ポーカーで重要なことは参加です。チームの全員が参加する必要があります。そう、全員です。機能テスト担当者が開発タスクを見積もり、開発タスク担当者が機能テストを見積もる、といったようにします。機能プロジェクト マネージャーは、開発タスクも見積もる場合があります。このようにすることで、客観的な値に、可能な限り多くの主観的な見積もりが含まれるようになります。

1 組のプランニング ポーカー カードで開始します。プランニング ポーカー カードは、インデックス カードで簡単に作成したり、トランプを代用したり、購入したりできます。Visual Studio で作成することもできます。各カードには、選択した範囲のストーリー ポイント (1、2、5、8、13 など) の値の 1 つを割り当てます。すべての参加者には、使用可能なストーリー ポイントの完全な範囲を含む "手" が配られます。

カードを配ったらゲームを開始します。

1. スクラム マスターは、プロダクト バックログの最初の項目をチームに示します。

2. チームは、そのストーリーについて話し合います。

3. 製品の担当者は、質問、前提条件、不明点、および受け入れ基準を明確にします。

4. 各チーム メンバーは、基準となる 1 つまたは複数のストーリー、またはプロダクト バックログにあるすべてのストーリーと比較して、そのストーリーの大きさを個人的に決定します。

5. 1、2 の 3 で、全員同時に自分の選んだカードを出します。

全員が同じカードを出した場合は、チームは見積もりを記録して、次のストーリーに進むことができます。

大きなばらつきがある場合は (たとえば、1 ～ 8 の範囲の値が出された場合)、時間をかけてストーリーを検討します。話し合いをまとめるため、低い値と高い値を示したメンバーに、そのように見積もった理由を説明してもらいます。ここでは、値ではなく話し合うことに価値があります。それによって、学習が行われ、仮定されていることが明らかになります。30 秒から 1 分の短い検討の後、チームは手順 4. と 5. を繰り返します。チームがストーリーの見積もりに合意するまでこれを続けます。

これは比較的簡単なことのように見えますが、いくつかの基本ルールを理解することが重要です。第 1 に、チームの全員がある程度の合意に達するまで、次のストーリーに進んではいけません。たとえば、メンバーの 1 人だけ 8 を出し、他のすべてのメンバーは 5 を出したものとします。ミーティングの進行役が次のように宣言します。「こんなところでしょうか。これについては 5 ということにして、次に進みます。」8 を出したメンバーはどうするでしょう。私の経験では、そのメンバーはチームの決定に従いますが、完全に参加することを止めてしまいます。計画は速く進むかもしれませんが、何か貴重なものが失われています。このメンバーが作業について理解できなくなるだけでなく、チームはそのメンバーによる入力と観点を失ってしまいます。また、意見が一致しなくてもかまいません。1 人だけ高い値を選択した理由について話し合うことで、貴重な理解が得られるのです。膠着状態になったと判断したら、進行役は "Fist to Five" の手法を試してみます。このようにすると、参加者に疎外感を与えることなくミーティングは驚くほど先に進むようになります。

プランニング ポーカーは見積もりをポイントで表すので、プロダクト バックログの見積もりに理想的です。ただし、スプリント バックログは時間で見積もる必要があります。そうではあっても、プランニング ポーカーはスプリント バックログの見積もりに対しても問題なく使用でき、使用されています。ただし、カードの値はポイントではなく時間数になります。簡単なルールは次のようになります。

• プロダクト バックログの見積もりは "ポイント" で行います。

• スプリント バックログの見積もりは "時間数" で行います。

プランニング ポーカーは、プロジェクトの開始時だけでなく、プロジェクトのライフサイクル全体を通して、新しい情報がわかったとき、優先順位が変わったとき、明確さが表面化したときに使用できます。

壁の見積もり

プランニング ポーカーはユーザー ストーリーを見積もる優れたツールですが、何百ものストーリーについて 1 つずつプランニング ポーカーを使用して見積もるのではたいへんな時間がかかります。見積もりも優先順位付けも行われていない何百ものストーリーを含む手付かずのバックログがある場合は、もっと短い時間で見積もりを行う手段が必要になります。

壁見積もりは、チームが 2 か 3 かや 5 か 8 かといったことを討論しなくて済むように設計されており、少なくとも最初は、連続体上で純粋に相対的に見積もりを行います。また、利害関係者は、あるストーリーが別のストーリーより少しだけ重要かどうかといったことにとらわれることなく、ストーリーの大きなグループに対して一般的な優先順位を付けることができます。

壁見積もりを行うには、最初にユーザー ストーリーをカードに印刷する必要があります。そして、チームと利害関係者を大きな空白の壁 (幅 14 フィート、高さ 8 ～ 10 フィートくらい) のある部屋に集めます。壁については 2 つのことを理解してください。

• 高さは優先順位を決定します。上にあるストーリーほど優先順位が高く、下に行くに従って優先順位は低くなります。ストーリーの優先順位の基になるのは、ROI、ビジネス価値、または単に "理由はわからないがとにかく重要" といったことでもかまいません。

• 幅は、サイズのために確保されています。左にいくほどストーリーは小さくなり、右にいくほど大きくなります (向きを逆にした方が論理的であれば、右から左に大きくなるようにしてもかまいません)。重要なのは、水平と垂直に引かれた直線を思い描くことです。チーム メンバーと利害関係者は、そのストーリーが他のストーリーとの位置関係でどこに収まるのかを各自考えます。

チームは壁を使用してすべてのストーリーのサイズを決定します。利害関係者は壁を使用してストーリーの優先順位を決定します。プランニング ポーカーと同じように相対的なサイズを使用しますが、2 つの基準ストーリーを比較に使用する代わりに、壁が基準になります。小さいストーリーですか。左に移動してください。大きいストーリーですか。右に移動してください。重要なストーリーですか。上に配置してください。今はなくても問題ないストーリーですか。下に配置してください。

ストーリーを見積もるときに利害関係者が同席する必要はありませんが、ストーリーの優先順位を設定するときはチームが部屋にいる必要があります。スクラム マスターと製品の所有者は、見積もりと優先順位付けの両方のアクティビティに出席する必要があります。

既に見積もりが済んでいるバックログがある場合は、この手法の優先順位付けセクションだけを行うことができます。製品の所有者と利害関係者から優先順位付けの済んだバックログを提供された場合は、この手法の見積もりセクションだけを行うことができます (製品の所有者は、見積もりを行った後で優先順位付けにも参加する場合があります。いずれにしても、コストは優先順位に大きく影響します)。チームの役割から始めて、このしくみを詳しく見ていきます。

見積もり

チームに未処理のプロダクト バックログを提供して、見積もりを開始します。値は関係なく、左端には最も小さいストーリーを配置し、右端には最も大きいストーリーを配置するようにチームに指示します。チームはこれら 2 つの極を基にして、壁のどこかにストーリーを配置します。この方法の利点は、2 ポイントまたは 3 ポイントのストーリーを事前に考える必要がないことです。壁の大きさに基づく純粋に相対的な方法です。ですから、大きな壁の方が便利です。

この方法が難しい場合は、1 ～ 8 ポイントの範囲で基準ストーリーを追加することにより、壁にさらに構造を提供できます。大きな基準ストーリーを作成することを気にする必要はありません。大きいものは、通常、優先順位が上がると分割されます。5 つのストーリーを識別した後、サイズと関連付けて壁に配置します (やはり左から右に向かって大きくなります)。8 ポイントより大きいストーリーのために、壁の右側には余裕を持たせます。これらのストーリーを壁に配置したら、チームに、これらの基準ストーリーを基にして残りのストーリーを壁に配置するように指示します。小さいストーリーは左に、大きいストーリーは右に置くように注意します。

ストーリーを壁に配置したら、ストーリーのサイズ間の論理的な区切りを識別します。これらの区切りを示すために、ストーリーのグループの間に垂直にテープを貼ります。やがて、壁は次に示すような状態になります。1 番目のグループに含まれるものは 2、2 番目のグループは 3、3 番目のグループは 5、最後のグループは 8 です。すべてのストーリーは相互に相対的に見積もられているので、値は問題ではありません。

ストーリーの見積もりが済んだので、利害関係者を加えてストーリーに優先順位を割り当てる必要があります。

優先順位付け

顧客や利害関係者は優先順位を決めるためにストーリーの大きさを知りたがりますが、関係のあるストーリーを見つけ、そのストーリーが済んでいることを確認することに、より注目します。利害関係者が優先順について同意しない場合、製品の所有者はこの情報を使用して最終的な優先順位を決定します。

壁について利害関係者に説明します。壁のカードは最終製品に含まれるすべての機能を反映していることを説明します。チームは既に各ストーリーの見積もりを終わり、壁のカラムに基づいてストーリーのポイント見積もりを決定できることを説明します。チーム メンバーは優先順位付けには積極的に参加しないことを全員に思い出させます。メンバーが同席するのは作業を観察し、行動、会話、特定のストーリーの優先順位が上がったり下がったりした理由を記録するためです。また、必要に応じて利害関係者からの質問にも答えます。特定の利害関係者からの回答が必要なためにチームが確実にサイズを決定できないストーリーがある場合、時間が許せばチームもストーリーについて質問できます。

テープで区切られたカラム内でストーリーを上下に移動して、すべてのストーリーの相対的な優先順位を決定するよう利害関係者に要求します。ビジネス上の優先度が高いストーリーほど、壁の高い位置に移動するよう注意を促します。以下のルールを設定します。

• ストーリーを最上位に配置する場合は、その正当な理由を示すことができるようにします。

• ストーリー間の相対的な重要性の理由について、相互に質問できます。"これを上や下に移動したい人はいますか" といった質問や、"これは動かす必要があると思います。反対の人はいますか" といった発現を自由にしてかまいません。これにより、わざわざ促進しなくても、利害関係者間の会話が進みます。

• 他の参加者が移動した場所よりさらに下にストーリーを移動する場合は、色付きの点でマークして注意を促します。

グループで優先順位付けを行う最大のメリットは、すべての利害関係者がさまざまなストーリーの優先順位をよりよく理解できることです。話し合いが長く続いて解決が見いだせない場合は、製品の所有者はカードを集め、同意できない 2 人の利害関係者を識別して、後で個人的に会う予定を記録します。

ストーリーと利害関係者の数により、この作業には 2 ～ 6 時間かかります。終了すると、壁は次に示すような状態になります。

壁はだいたい 4 つの区画に分かれます。左上のストーリーは、優先度が高くてサイズが小さいものであり、プロダクト バックログの上位になります。右上のストーリーが優先度が高く、サイズが大きいものです。これらのストーリーは、すぐに分割して、今後のスプリントに組み込めるようにする必要があります。

左下のストーリーは、小さくて優先順位の低いものです。これらは、バックログの下位に置かれます。右下のストーリーは、大きくて優先順位が低いものです。これらのストーリーは、エピックまたはテーマです。最終的には小さく分割して管理しやすいストーリーにする必要がありますが、優先順位が上がるまで待つことができます。

少し時間を取って、グループと共に風の全体を調べます。不適切な区画にあるストーリーは移動します。優先度の高いストーリーを分割する必要があり、時間に余裕がある場合は、全員が部屋にいる間に行います。

壁見積もりの最後で、リリース計画を開始します。チームのこれまでの作業速度がわかっている場合は、左上の区画のストーリーが終了するだいたいの範囲を示すこともできます。

プロジェクトの開始時には不確実なことが多くあるので、見積もりは困難です。製品の所有者とアジャイル プロジェクト マネージャーは、製品の所有者および利害関係者と話し合い、動作するソフトウェアを作成し、そのソフトウェアについてのフィードバックを統合してリリース可能な状態にすることで、早期学習の価値を最大にしようとします。しかし、アジャイル プロジェクトであっても、一連の機能がリリースできる状態になる時期についてなんらかの見積もりを提供する必要があります。

私がお勧めする 2 つの見積もり手法は、プランニング ポーカー (比較的小さいストーリーのセットに適しています) または壁見積もり (大きい未処理のプロダクト バックログの管理に適しています) です。いずれも計画の作成を始めるために必要なデータを提供し、それこそが見積もりの最終的な目標です。

参照

概念

アジャイル計画とイテレーション

チームとしての作業の開始

プロダクト バックログの作成または追加

バックログのグルーミングと見積り

1. Mike Cohn、『Agile Estimating and Planning』、36 ページ

2. Consensus decision-making: hand signals (Wikipedia)