プランニング・ポーカーで始める楽しい見積り

こんにちは、UX統括部の横幕です。すっかり春になって、桜を眺めるのが気持ち良いですね。

最近、社内で活発に「デイリースクラム」が行われるようになりました。
日々、チームメンバーの持っているタスクの進捗を確認し合うことで、スケジュール感の共有・調整、あるいは、チームメンバー同士でタスクの振り分けを見なおしたりなどができ、チームの有機的な動きを作ることが出来るようになってきています。

さて、そんななかで、今回は、プロジェクトを進める上で、また日々のデイリースクラムをする上で重要な「タスクの見積り」についてお話しようと思います。

これが実際のPlanning Pokerです。アメリカのMountain Goat社が企画発売し、ライセンスしています。

1. 見積る前に

1-1. 計画を立てよう

タスクの見積りをする前に、何をするのか、その計画を立てていきます。

・フィーチャーを考える

フィーチャーとは、お客様に提供する機能・価値のことです。アジャイルなプラクティスでは、ユーザーストーリーと呼んだりもするようです。

新機能Aを作る
機能Bに追加機能B-2を盛り込む
機能Cを××に最適化する
…

ここで大事な事は、お客様にどんな価値が提供できるかどうか、ということです。つまり、「サーバを増強する」や「DBのスキーマを変更する」といったものはフィーチャーではない、ということです。
加えて、各フィーチャーは独立している方が良いとされます。なぜなら、予測不能な割り込み等でスケジュールがピンチになっても、フィーチャーが独立していれば、優先度がつけやすくなり、死守すべきラインを明確にしやすくなるからです。

このようにすることで、お客様からは、どれくらいの価値あるものが提供されるかが分かるようになります。
また、開発チームにとっては、開発・実装のゴールが見える化されます。
そして、ビジネスの観点からは、各フィーチャーの優先度が分かりやすくなるので、戦略が立てやすくなります。

・より詳細に

フィーチャーを決めたら、そのフィーチャーの中で「どんなことが出来るようになるのか」を決めます。
フィーチャーだけでは、実際何を実現すれば良いのかが明確になっていないため、噛み砕いて「どんなことが出来るようになるのか」を考える必要があります。
アジャイルなプラクティスでは、プロダクトバックログや、ストーリーなどと呼ぶようです。

新機能Aを作る
- ○○を出来るようにする
- ××を出来るようにする
- …
機能Bに追加機能B-2を盛り込む
- 新たに、△△が出来るようになる
機能Cを××に最適化する
- ××で正常に動かなかった機能Cが動くようになる
…

このようにすることで、お客様からは、実際に何が実現されたかを知ることができます。
また、開発チームは、具体的な動作・実装の目標が立てられます。

・タスクを作る

「どんなことが出来るようになるのか」が決まったら、細かいタスクを洗い出していきます。アジャイルなプラクティスでは、シナリオとも呼ばれるようです。

新機能Aを作る
- ○○を出来るようにする
  - DBのスキーマを決める
  - 画面を作る
  - …
- ××を出来るようにする
  - DBのスキーマを決める
  - プロシージャを作る
  - …
- …
機能Bに追加機能B-2を盛り込む
- 新たに、△△が出来るようになる
  - DBのスキーマを変更する
  - 機能Bの画面に、追加機能B-2の導線を置く
  - …
機能Cを××に最適化する
- ××で正常に動かなかった機能Cが動くようになる
  - 正常に動かない理由を調べる
  - …
…

ここで大事な事は、開発チームメンバー全員が、「どんな実装になるのか」の認識が合うようにタスクを分けるようにすることです。
Aさんはストーリーの段階で理解できたとしても、Bさんが分からなければ、「正確な見積り」ができなくなってしまいます。
なので、できるだけチームメンバー全員が納得できる粒度まで落とし込みます。

1-2. 計画を立てる時のポイント

・みんなが分かりやすい言葉にする

フィーチャー・ストーリー・タスク（シナリオ）のどの粒度でも、分かりやすく書くことは重要なポイントです。
分かりやすく書くことで、プロジェクトが、何のために、何をしているのかが見える化されるようになり、
そのために必要な調整も（プロジェクトに直接関係する人以外にも理解できることで）よりスムーズに出来るようになります。

・独立したものにする

各フィーチャーが密接に関連しあっていると、そのための調整コストが発生してしまいます。
また、スケジュールがピンチになった時に、フィーチャーやストーリーなどが密接に関連しあっていると、死守すべきラインが広くなって開発者がつらい思いをしてしまいます。
なので、出来る限りフィーチャーやストーリーなどは独立している方が良いです。

こちらは、日本マイクロソフト株式会社さんが作成されたPlanning Poker. Mountain Goat社のライセンス表記も箱の裏にあります。技術系イベントで弊社エンジニアがいただいてきたものです。いいでしょう!

2. 見積りを立てる

2-1. 見積りとは

タスクの見積りとは、そのタスクをやり遂げるのにどのくらいのコストがかかるかを数値化することです。

しかし、コストと一口に言っても、かかる時間のことや、かかるお金のこと、人数など様々な要素が含まれています。これら1つ1つを精密に計算しても良いかも知れませんが、
往々にしてそれら全部を計算し尽くす時間は無いものです。

2-2. 単位に重要な意味を与えない

そこで、工数の単位を「ポイント」で出します。
ポイントという単位に特に意味は無く、「このタスクの工数が5ポイントだから、それと比較すると、このタスクは...」と言ったような、相対的な比較に使うためのもの、ということにします。

このようにすることで、お客様やビジネスの観点からは、詳細は分からなくとも、提供されるフィーチャーがどのくらいの重要性を持っているかが分かるようになります。
また、開発チームからは、一日にどのくらいのポイントを消化していけば納品可能かを測る指標を持つことが出来るようになりますし、相対的に見積もるので、各タスクの難易度も見える化され、何処に重点的に力を注げばよいかが分かるようになります。

2-3. 見積もってみる

実際の見積りは、開発チームのメンバー全員で行います。

一人で見積ると、自分が理解していることは低めに見積もられ、理解していないことはかなり高めに見積もられてしまい、実際にかかる工数と乖離したものになってしまいかねません。
また、実は○○というハマりどころがあって、という発見があったり、思ったほど重たくない（軽くない）ことが見積りの段階で判明した、などという点でも、チームメンバー全員で見積ることは重要です。

2-4. 楽しく見積る

さて、あとはタスクに見積りの数字を当てはめていくことになるのですが、ただ単に数字を言い合うだけの黙々とした作業ではつまらないですよね。
そこで弊社のAndroid(TM)開発チームでは、「PLANNING POKER（プランニング・ポーカー）」を利用して見積りを行なっています。

PLANNING POKERとは、「?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 無限大」が書かれたカードのセットを1人1つずつ手札にして、
あるタスクに対する工数はどのくらいかを、そのカードの中から選び、全員一斉に出しあって工数感の認識合わせをするためのツールです。

以下のようなルールに基づいて工数を見積もっていきます。

あるタスクの工数のポイント数を、チームメンバーそれぞれがカードの中から選びます（まだ他のメンバーには見せない）
全員が選び終えたら、一斉にカードを出し合います
全員の出した数字が一致していたら、出した数字を、そのタスクの工数とします
全員の出した数字が一致しなかった場合、なぜその数字にしたかの理由をそれぞれ述べていきます
その理由を元に、もう一度カードを選び直します
以下、全員の数字が一致するまで1~4を繰り返します

最初に一致しない場合でも、おおよそ3回くらい繰り返すと、だいたい数字が一致するようになります。
もしそれ以上繰り返しても一致しないときは、タスクの洗い出しを見直すか、あるいは数字が近いのであれば、全員の出した数字の平均値をタスクの工数とする、という選択も可能です。

ただ、1つのタスクとして、40や100といった数字がつくようなものは、改めて「具体的に何を実現するのか」「何をすればいいのか」を掘り下げる必要があるものです。

3. 正しく見積るには

例えば、チームに初めて配属された人がタスクを見積るのは大変です。経験のない人が見積ることはなおさら大変です。
このような状況において、正しく見積もりを行うためにはどのようにしたらよいでしょうか（正しく見積もれなかったからと言って責められるようなものではありません）。

3-1. ストーリーやタスクの詳細をみんなで考える

ストーリーやタスクに書かれている言葉が、初めての人にとって抽象的すぎる場合には、より具体的に表現していくことが大切です。
みんなが分かりやすい言葉にする、というのは、簡潔にかければそれで良い、ということだけではなく、時にはより具体的に表現することも検討してみる、という柔軟性が求められています。

3-2. 分かる人に聞く

たとえば、私はまだコードレビューをするという経験がないので、コードレビューにどれだけの工数がかかるかわかりません。
チームの中で分かる人がいれば、その人の話を聞いてみてから決める、ということも、正しく見積るために重要なことです。

3-3. とりあえずやってみる

やってみて初めて、「このくらい時間・労力がかかる仕事だったのか」ということが体験できます。
体験があれば、工数の見積りもしやすくなります。

3-4. 基準を決める

あるタスクの工数を見積るとき、全員が大体同じ認識を持っていそうなタスクの工数を基準に相対的に見積ると、見積りの数字を決める理由の一助となります。
「このタスクよりは考えることが多そうだ」、「このタスクに比べると、影響範囲は小さそう」などのような話し合いがしやすくなるので、
PLANNING POKERの繰り返しも少なくなります。