はじめに
スクラム開発において、ストーリーポイントという単位でタスクの見積もりを行います。
今回の記事では、アジャイル開発における見積もりの方法と登場する独自の概念についてまとめます。
ユーザーストーリーとは
アジャイル開発においてはタスクの内容を示す概念として、ユーザーストーリーが使われます。
アジャイルにおいて重要視されるのは「人」であり、ユーザーストーリーではエンドユーザーを中心に考えます。
一般的には下記のテンプレートでユーザーストーリーを記述します。
<ユーザーの種類>として、
<達成したいゴール>をしたい。
なぜなら<理由>だからだ。
このストーリーには関係する作業を全て細かく書く必要はなく、あくまでざっくりとした内容で構いません。
制約条件や仕様等はユーザーストーリーの補足として別途記述することが一般的です。
大切なのは、ストーリーをみた関係者がなんのことを言っているかすぐに思い出せることです。
そして、人を重視するアジャイル開発においては、思い出した内容についてメンバー間で議論しましょう。
このように、無駄な詳細化を避けつつ、顧客や関係者との会話に役立つのがユーザーストーリーです。
また、後述するようにアジャイル開発においては見積もりを行う際にもユーザーストーリーが重要な役割を果たします。
いいユーザーストーリーの条件
- スケジュール可能な単位であること
- 他のストーリーに依存していないこと
- エンドユーザーからみた価値が書かれていること
Ron Jeffries氏によると、ユーザーストーリーは以下の3つのCで評価できると言われています。
- Card: カードに書ける程度の大きさであること。見積もりやメモ等も一緒に書く。
- Conversation: ストーリーについての議論ができること。エンドユーザーの視点での価値があること。
- Confirmation: ストーリーが完了したかどうかを確認できること。テストが書けること。
エンドユーザーから見た価値を提供できるリリース可能な単位でストーリーを記述します。
また、いいユーザーストーリーを作るための基準として、「INVEST」という基準があります。
- Independent: 他のストーリーに依存していない
- Negotiable: 議論可能である
- Valuable: エンドユーザーにとって価値がある
- Estimatable: 見積もりが可能である
- Small: スケジュール可能な単位である
- Testable: テストが可能である
上記のように、あくまでチームとステークホルダーの議論のための道具であり、全員がわかる用語で記述することが重要です。
技術的な詳細はできるかぎり避け、ビジネスの視点で記述することが重要です。
見積もりの目的
アジャイルサムライの中には見積もりの目的として以下の引用が書かれています。
「ソフトウェア見積りの主目的は、プロジェクトの結果を予言することではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。」 — Steve McConnell、『Software Estimation: Demystifying the Black Art』
つまり、見積もりというのは不完全なもので、プロジェクトの初期であればあるほどその不確実性は高く、プロジェクトが進むにつれ、ようやく完了させる見込みが出てくるものです。
端的に言えば、前もって正確に見積もることは不可能です。ただ、それでも私たちは、このプロジェクトをやり遂げられそうなのかを判断する必要があります。
見積もりにおいてはいつ終わりそうなのか?以前に自分たちのゴール、プロジェクトのゴールを再確認し、そのゴールに対する現在地を先に確認します。
アジャイル開発においては、プロジェクトの初期段階での概算見積りを信用しません。その代わり、何かを作る時にはそれがどれくらいかかったかを計測して、次回の見積もりに活かすというアプローチを取ります。これによってゴールと現在地の距離、過去に計測したスピードから、プロジェクトの進捗を予測します。
具体的には、次のようなことを行います。
- ストーリー()それぞれを相対的な基準で見積もる
- ポイントをもとにして進捗を追跡する
大切なのはストーリーの規模を見積もり、期間は導出するということです。
例
アジャイルサムライに記載のわかりやすい例は以下の通りです。
チョコチップクッキーを1枚食べるのに10秒かかるということがわかっていたとする。このとき、クッキーを7枚とか14枚平らげるのに(1杯だけなら牛乳を飲んでもいいよ)どれぐらいかかるだろうか?さあ、君の見積りは?
人間は、このような相対的な見積もりをうまく予測できる傾向にあるそうです。
ストーリーポイントの目的
アジャイル開発では、見積もりと実績を比較して計画を修正していくことが重要ですが、例えば3日かかると見積もったタスクが4日かかってしまった場合、その差をどう扱うかが問題になります。
ほかのタスクを同様に1.33倍に見積もるんでしょうか?つまりもともと5日かかる予定だったタスクは6.66日かかると見積もるんでしょうか?
こうした見積もりの数値の再調整を避けるために、見積もり結果の数値の単位には意味を持たせず、ただポイントとして扱います。
- 1pt: 楽勝
- 3pt: やれないことはない
- 5pt: ちょっと大変
相対的な見積もり
基準となるタスクを決め、それと比較してストーリーを見積もっていきます。
利用するストーリーポイントとしてはフィボナッチ数列がよく使われます。また、プランニングポーカーと呼ばれる手法を使って、チーム全員が見積もりに参加することが一般的です。
ストーリーポイントの計算
まずは基準となるストーリーを決めます。このストーリーを1ポイントとして、他のストーリーと比較していきます。
1ポイントのストーリー以外にも、いくつかのストーリーを基準として、それぞれのストーリーに対してポイントを割り振っておくといいかもしれません。
私のチームで取り組む場合は3つほどのストーリーを基準として事前に話し合いました。
プランニングポーカーにあたっては、各メンバーがストーリーに対してポイントを提示し、その理由を述べます。
ここで、細かい数字の差に固執せず、大まかな見積もりを行うことが重要です。
議論を行うべき場面は、基準に対してストーリーの大きさの認識がメンバー間で異なる場合です。
例:
Aさん: この3ポイントのストーリーを基準とすると、このタスクよりは重たいので5ポイント
Bさん: いや、このタスクは3ポイントのストーリーよりは軽いと思うので2ポイント
この例では、AさんとBさんの見解が異なるため、議論が必要です。基準となるストーリーの認識か、ストーリーに対する認識のどちらかにずれがあるため、チーム内でこのずれを解消するための議論が必要です。
ストーリーポイントの利用
ストーリーポイントを活用することで、チーム全体のベロシティ(速さ)を計測することができます。
チームとしてストーリーポイントをどれだけこなせるかを計測し、次のスプリントの見積もりに活かすことができます。
たとえチーム内で実力に差があったとしても、担当が変更になった際に見積もりを再度行うことなく、ストーリーポイントという規模は変わらないため、チーム全体の進捗を把握しやすくなります。
疑問
- 人によって知識量が違うので、Aさんだととても軽いストーリーだが、Bさんから見ると作業量が多いということがある。この場合、どちらの見解を採用すべきか?
- 調査を別のストーリーにしてしまう。
- そもそもAさんのベロシティ(キャパシティ)が高いと考えて、ストーリーポイント自体は変えない。
- 初めて作る時は大きいストーリーポイントを設定したが、その際に将来に備えた設計をしていて、今回は簡単に変更できる。
- タスクの大きさ自体は変わらないので、ストーリーポイントは変えない。
- チームのベロシティが向上したと考える。
優れた見積もりを作成するために
見積もりというのはもちろんできる限り正確に行いたいものですが、見積もりの値を顧客との約束としてしまうと以下のような結果を招くことがあります。
- 作業完了後に見積もりを大幅に超えてしまった。次からは二度と誤らないように大きいバッファを積んでしまおう。
- チームが見積もりを誤ることのないように、慎重に再検討をしよう。その結果見積もりにかける時間が膨大になってしまった。
つまり、見積もりを正確に行うには信頼と安心に基づいた環境や、事前の情報を自由に共有できること、学習と改善を目的に議論できることなど、見積もりの数値を約束ではなく、予測の結果として扱える環境を用意することが重要です。
スプリント計画の目的は次のスプリント向けに「ちょうどいい」計画を立てることであり、チームにとって厄介な問題でないことを確認する必要があります。
チームのフォーカスはあくまでもスプリントによって達成される「成果」であるべきです。
前提としてスクラムは複雑な問題の解決を目的とした手法のため、スプリントの中で学習すること、改善することを含んでおり、自身の成長やチームの成長を完全に予測した計画を立てることはできないという認識を持つことが重要です。
まとめ
- ストーリーポイントは見積もりの単位であり、見積もりの目的はプロジェクトの進捗を予測することである。
- ストーリーポイントは相対的な見積もりの基準であり、チーム全体のベロシティを計測する。
- 「計画」という結果そのものが大切なのではなく、「議論して計画する」プロセスが重要
- チーム全体で見積もり、その結果を次回以降に活かすのが目的なので、計画に完璧を求めすぎない。
