見積りのためだけじゃなかった！ プランニングポーカーが開発チームとプロダクトにもたらす8の恩恵
開発部の土岐です。今日が誕生日で割り切れない数の歳になりました。
さて、これまでの幾度か弊社アプレッソで「アジャイルへの取り組みを始めてるよ！」ということを紹介して参りました。
2016年7月現在、DataSpider Servistaの次バージョン、4.1の開発プロジェクトが本格化し、実際にアジャイルな開発に取り組んでおります！ と自信満々に言ってみたものの、本格的なアジャイルに取り組むのは初めての我々。「ヒヨコードでピヨピヨしている」状態ではありますが、日々悩み議論しながらいろいろなことにチャレンジしています。
ということで今後、その取り組みを具体的に紹介していこうと思います。
今回はアジャイル的な見積りの技法、「プランニングポーカー」についてです。
プランニングポーカーとは？
▲使用しているプランニングポーカー
現在のDSS4.1プロジェクトでは、ユーザーストーリーの見積りをすべてプランニングポーカーで行っています。これまでの弊社のプロジェクトでは、一般的な見積りと同様に開発担当者が「人日」などの工数で見積り、それをリーダーがレビューして見積りとする、というのが一般的でした（それがすべてではないですが）。今回はそれを大きく変えたわけです。
プランニングポーカー自体の詳細についてはネット上でいろいろな方の記事があるので、そちらを参照していただくのがオススメです。
ざっくり説明すると、プロジェクトチーム全員（プロダクトオーナー、QAも含めて)がこのプランニングポーカーを持って参加します。全員がそのストーリーの「ポイント」を見積りカードで提示し、話し合いを経て全員の一致でポイントを決定します。この繰り返しによって見積りを行っています。
カードのポイントは「1」「2」「3」「5」「8」「13」・・・・という数値になっています。この数値は皆さんご存じフィボナッチ数列です。この数列は必要以上に細かい数値の違いに議論が集中しないというメリットがあります。
ちなみにここで見積もる「ポイント」は「工数」とは異なり、「ストーリーの相対的な規模」を表したものです。この違いはとても重要です。とても重要です。とても重要です・・・が、今までの感覚とかなり違うのでチーム全員が飲み込めるまで時間がかかりました・・・。イテレーションを進んできて、ようやくその意義がしっくりきているところです。このトピックは面白いのですが詳細に書くと長くなるので、改めて別の記事ででも取り上げたいと思います。
ちなみに↑のプランニングポーカーは、Surviveplus.netさんのPlus Programming .net Planning PokerのPDFを使わせていただき、印刷して作りました。 最初はカードが手元に無かったので付箋でやってたのですが、カードでやるとゲーム感が高まりテンション上がります。
Surviveplus.netさんありがとうございました！
プランニングポーカーで見積ってみる！
▲カードを出し合って見積り！
幾度かこのプランニングポーカーでの見積りをやってきて、新しい技法なので最初は戸惑っていたのですが、徐々に慣れてきて一定の流れが出来てきました。
ざっくりと流れを書くとこういう感じです。
プロジェクトマネージャー(PM)「このストーリーは××を○○するというストーリーです。（ホワイトボードに書いたりしながら）このような機能をイメージしてます。△△の詳細については決っていないので検討が必要です」
メンバー「××については仕様の方針が決まってますか？」
～ いろいろストーリーに関する説明
PM「皆さんイメージは出来ました？」
メンバー「はーい」
PM「いっせーのせ！」
～ 全員カードを提出
PM「えーっと、"5"が一番多くて、"3"の人、"8"の人が居ますね。"8"を出したAさんはどういう理由で"8"ですかね」
Aさん「これはGUIの修正が必要で、その部分は画面仕様も含めて悩みどころが大きくて規模としては大きくなると思います」
Bさん「あーなるほど。そうすると自分も8かな？」
Cさん「自分は3を出したんですけど、他の開発のときに使ったあの機能を取り込めばいいと思うのでそこまで大きくはならないと思うんですよね」
Dさん「QAの立場からみて、経験上このコンポーネントは結構テストが大変で、不具合が出やすいんですよ。なのである程度大きくみておいた方がいいんじゃないかな～」
Eさん「なるほど～じゃあ自分ももう少し大きくしようかな・・・」
～ いろいろ会話
PM「ではこのストーリーはポイント"8"で良いでしょうか？」
メンバー「OKです！」
～ ポイントを記述する
PM「では次のストーリーは～」
というので次々と見積りをやってストーリーにポイントを付けていきます。
なお↑の流れではPMが話の流れを見計らってポイントを提示して、全員の同意を得て決定しています。通常ならポイントを決定するときは、カードを何度も出し直して全員の数値が揃うまで出す、というのが通常のプランニングポーカーのやり方のようです。ただ、それをやると時間がかかりすぎてしまうようだったので、現在はざっくりと議論が終息してきたところで、大きな反論がなければ提示したポイントにするという方法を取っています。この辺は試行錯誤中です。
プランニングポーカー良い！
ということで試行錯誤しながら導入をしてみて、端的に言うと「とても良かった」と私は思ってます。これは他のメンバーに聞いても同じようです。
正直なところ、私はとても疑い深い人間で、人から言われたままやるのを嫌がる天の邪鬼な人間であり、自分には邪気眼とかの秘められた能力があるのではないかと今でもたまに思うという中二病的な人間です（中二病は本旨には関係ないですが）。
「全員一致で決める？ そりゃ理想はそうだろうけど、それをやる意味って本当にあるの？ なんかスピリチュアルでユニティでピースでラブみたいなそういう胡散臭いもんなじゃないの？」
とか失礼なことを思っていましたが・・・違いました！ アジャイルさん、失礼なこと思ってすいません！
プランニングポーカーには、開発チームとプロダクトに確実に恩恵をもたらす現実的で具体的な効果があります。
ということで、その恩恵について1つずつ解説していこうと思います。
1. 「見積り」がゲームになって楽しい！
▲見積りポイントについて喧々諤々の議論を闘わせるチーム
一番分かりやすいのがこのポイントです。「見積り」という"作業“が皆でワイワイ楽しむ”ゲーム“になります。
前述した通り、これまでの弊社での見積りは、開発者が個別に工数を見積もっていくという孤独な作業でした。分からないことがあったら自分でいろいろな人に相談しつつ、PCの前でうんうん唸って悩みながら、でも「決めなきゃいけない・・・」という焦燥感に駆られ、絶望の果て工数を叫ぶ作業・・ってこれは大袈裟過ぎますスイマセン！ しかしここまでネガティブではないですが、「孤独」であり「作業」であったことは確かです。
プランニングポーカーによる見積りでは、関係者もレビュアーも全員その場に居るので、分からないことはその場で解決できます。 さらに「あ、この人はこのポイントを出すんだ」「お、これは皆意見が一致してるね」「そんな視点もあるのか～」など驚きと発見のある楽しいゲームになります。
まあでも正直なところ、「さあ明日見積りだ！ ワクワクして眠れないなぁ」というほどの楽しさではないです。しかし「ちょっとワイワイやってみようか」っていう憂鬱さの無いMTGであることは確かです。
ということで、まずはこの「楽しさ」を前提としつつ、次からが本番です。
2. 全員の「参加感」が凄い！
関係者に仕様を説明するMTGは皆さんやったことがあると思います。
準備した資料を駆使してデモを行い、「質問ありますか？」と聞いたところ
シーン・・・
よく見る光景ですね。自分も説明を受ける立場だったとすると、
- よく分からないところあったけど自分が実装するわけじゃないから
- 他に詳しい人が意見しないから自分が意見するのは恥ずかしくて
- 早くMTG終わらせて昼ご飯食べたいなぁ
こんなことを考えて「ま、いっか」となることがあります。（ありますよね？）
プランニングポーカーの一番重要なところは「必ず全員が自分のポイントを出さなければならず、そのポイントについて理由を説明しなければならない」というところにあると思います。
このことは「“見積り可能である"と判断するまで十分な情報を得る必要がある」ということとイコールになります。
つまり、参加者全員が「見積るにあたって十分な情報がある」と判断するまで、ストーリーに関する議論をする必要があります。
実際にプランニングポーカーをやってみて以下のようなことがありました。
PO「このストーリーは～というものです。質問ありますか？」
メンバー「うーん大丈夫かな・・・」
PO「ではカードを出してください」
メンバー「・・・あ、ちょっとまってください、あそこって仕様決まってますか？」
メンバー「あそこについてはどこまで詳細に落ちてますか？」
などとカードを出す段階になって急激に議論が深まったということがありました。
単なる仕様説明のMTGに「自分でポイントを見積り、そのポイントについて説明する」というフローを設けることによって、全員の「参加感」がまったく変わってくるのです。
これを認知心理学的には「建築中のマンション」理論と言い・・・・ませんし、そんな理論は存在しませんが、何かそんな心理学の理論とかありそうな気がしますね（雑）。
まあとにかく、プランニングポーカーの導入によって、参加者の意識は確実に変わります。これは確かです。
このことは、さまざまなメリットをもたらします。
3 ヒアリングしなくても情報が自然に集まってくる！
前述のメリットによる効果が大きいところがここです。飲み会とかでもそうですが、知らない人と「さあ、話しましょう！」と言ってもなかなか人は口を開けないものです。しかし「共通の話題」があると一気に話は深まります。
ここでの「共通の話題」は「何ポイントと見積るか？」です。具体的な方向に話題をフォーカスすることによって、メンバーから情報が自然に集まってきます。
具体的によくあるのが、ポイント提示後に皆で議論をしているときです。
「同じ仕様で実装した画面があって、あれは凄く大変だった。だからポイントは大きめの方が良いだろう」
「同様の実装があのモジュールにある。なのであそこを共通化すれば実装は楽なはずなのでポイントは少なくなるはず」
「修正自体は簡単そうだけど、影響が大きい機能なので慎重に動作確認が必要。テストのボリュームも大きくなるはず」
「この部分はあの人が実装したのでちょっと聞いてみてからポイントを判断した方がいいかも」
など、さまざまな観点で「そのストーリーの規模」についての有益な証言が多く出てきます。プロジェクトを進めていく上で非常にこのメリットは大きいと思います。
4 全員が手軽に直接情報を「知る」ことができる！
見積りから仕様策定、実装まで1人が担当すると、よくあるのが「あれはあの人の担当だからよく分かりません」という「他人の仕事」状態。これは経験された方は多くあると思います。これにより、誰かが休むとプロジェクトが止まったり、仕様ミスがプロジェクト終盤によって見つかったりという弊害があります。
それを防ぐための仕組みはアジャイル開発の中ではいろいろあるのですが、プランニングポーカーも非常に有益な武器になります。
このプランニングポーカーの段階では「そのストーリーを誰が実装・テストするか」というアサインは決めていません。ここも重要なポイントです。
プランニングポーカーをやっているときは全員が当事者です。全員がストーリーに対して見積りが可能な十分な情報を得ることが求められます。そして、誰でもそのストーリーの実装・テストが担当できるように全員に情報が行き渡ります。
wikiなどでドキュメントを頑張って書いて「情報共有！」って頑張るよりも、当社比で10倍くらい手軽で直接的に情報を共有することができるのであります。（もちろんドキュメントはドキュメントで大切ですよ！）
ちなみにここで議論したことは凄く重要な情報なので、議事録として残すかどうかはちょっと悩みどころです。まあだいたい自分が忘れても誰かに聞くと「あ、あのときはこういう話で～」と意外と覚えているものなのでとりあえず無しでやっています。全員が忘れてしまった場合はその程度の情報だったということで！
5 ストーリー自体が適正かを自然にチェックできる！
実際に議論していくと「まだポイントを決定できない」という結論になることがよくあります。殆どの場合、ポイントが決定できない要因はストーリーが「INVESTの原則」に添っていないことです。
アジャイル開発において、ユーザーストーリーは「INVESTの原則」に添うのが適正である、とされています。
INVESTの原則は以下です。
- Independent(独立している)
- Negotiable(交渉可能である)
- Valuable(ユーザ価値を提供する)
- Estimable(見積り可能である)
- Small(小さい)
- Testable(テスト可能である)
堅苦しくストーリーをこの原則に沿っているかどうかをチェックするのはなかなか骨の折れる作業です。しかし、プランニングポーカーの中でこのチェックを自然に会話の流れの中でやることができます。
例えば以下のような会話が出てきたときは怪しい兆候です。
「このストーリーはややこしいなぁ。複数のストーリーが合わさってない？」
→Independent(独立している) ではない
「このストーリーは詳細機能が決まってるけどもっと良いやり方あるんじゃないかな。ストーリーを一度考え直さない？」
→Negotiable(交渉可能である) ではない
「これって本当にユーザーに価値があるの？ 一度POで再検討した方がいいんじゃないかな？」
→Valuable(ユーザ価値を提供する) ではない
「このストーリーは抽象的過ぎて見積り難しいなぁ。もう少し具体的な仕様にした方がいいんじゃない？」
→Estimable(見積り可能である) ではない
「全員がこの大きいポイントを出すっていうことはストーリーが大きすぎるよね。分割できないかな？」
→Small(小さい) ではない
「このストーリーはテストを作るのが難しいなぁ。こういうストーリーにした方がいいんじゃない？」
→Testable(テスト可能である)ではない
このようなとき、一度見積りを出すのを中断します。そして「プロダクトオーナーに聞く」「別に仕様検討MTGを開く」「ストーリーを分割してから再見積をする」など、より適正なストーリーにするための方策をその場で決めたりします。
6 プロダクトの品質を保つ意識を持って見積りを行える
このMTGは必ず、テストを行うQAも参加します。そのため、開発寄りになることはなく、「品質保証」という観点も必ず見積りの議論の中に入れて行えます。
ただ「簡単な修正だから」という理由でポイントを低く見積もることは必ず異議が唱えられます。「開発」と「テスト」の双方の観点を併せて、見積りのポイントを一致する必要があります。
7 新規参加メンバーの「教育」も行える
プロジェクトに参加するメンバーは、プロダクトに関する知識の多い少ないは関係なく必ずこのプランニングポーカーに参加してもらっています。
そのため新規参加メンバーは、ポイントを選ぶとき凄く悩むようです（当たり前ですが！）。しかし悩んで出したポイントで「この部分が分からなかったので・・・」と説明すると、「それについてはこうこうで」ということで自然にプロダクトに関する知識の共有・教育を行うことができます。
なかなか「ここを教えて欲しいんですけど」と開発中に聞くのは抵抗があるとは思いますが、プランニングポーカーの中で「全員が一致して見積りポイントを出す」という目的のために自然に共有が行えるのは凄く効果的だと思います。
8 チームメンバーの相互理解が深まる！
ということでいろいろな観点で書いてきましたが、やはり一番重要なのは人間同士の関係。なかなか「理解しましょう」と言ってもすんなりできないのが人間であります。
飲み会などでのコミュニケーションも重要ですが、やはり今やっているプロジェクトの中でその人が何をやろうとしているのか、何を大切としているのか、ということを知ることがプロジェクトの成功のための必要な要素です。
プランニングポーカーでは全員に判断と発言の必要があるので、誰かが場を支配することなく、それぞれのメンバーが持っている知識や観点、大切にしている価値観などが分かってきて、チームの相互理解が高まります。
終わりに
「見積り」のための手法として導入した「プランニングポーカー」。一見「見積り」という目的を達成するために面倒くさい作業をしているように見えましたが、実際は
見積り＋ヒアリング＋情報共有＋品質向上＋チーム感向上＋教育＋α=プランニングポーカー
という非常に大きなメリットのあるものでした。開発チームとプロダクトをより改善する方法として、今後も導入して磨き上げてみたいと思います。
この記事を読んで気になった方がいればぜひ試してみてください。「見積り」のイメージが変わることは間違いありません！
ということで、今後もアジャイルの取り組みをいろいろ紹介していきたいと思います。以上、土岐からでした！
