さて、今日は「私のやり方紹介」シリーズ第二弾！

ちなみに前回は「マシュマロチャレンジ」を取り上げました。

passionate-po.hatenablog.com

今回は社内のスクラム勉強会で取り上げた「相対見積もりとプランニングポーカー」のワークショップについてまとめます。

ソフトウェア開発の見積もりは営業とエンジニアとのコミュニケーションの中で、

「なんでこんなにかかるんだ？」
「これ本当にやる意味あるの？」
「やりたいことは本当にこれ？違うやり方のほうが工数かからないけど、効果はあるんだけど・・・」

など、時に衝突の原因となり、その結果

「(エンジニアは/営業は)よくわからない。わかってくれない。」

という確執を生んでしまいます。

そこで、私は営業、エンジニア合同で行ったスクラム勉強会の中で「相対見積もりとプランニングポーカー」というテーマを取り上げました。前半は座学、後半はワークショップというスタイルで行った後半のワークショップについて、

同じような課題を持つ方が自分でやってみることができる！

ということを目的に共有します。

プランニングポーカーとは

　プランニングポーカーとは「1,2,3,5,8,13,21…」といったフィボナッチ数列で並んだカードを使って、ストーリーポイントを見積もっていく手法です。その手法は

準備

プランニングポーカーに使うカードを用意します。

　私は江端さんなどが運営されているここで買いました！

Agile Goods-Scrum専門店

手順

メンバー全員に「1,2,3,5,8,13,21」を１セットずつ配る
プロダクトバックログを決める
「基準となるアイテム」を決める
「基準となるアイテム」を"2"と見積もる
他のアイテムを見積もる

というもので、見積もり自体は

「せーの」で同時に数字を出す
「なぜをその数字を選んだのか」をディスカッション
「せーの」で再度数字を出す

を繰り返して、見積もりをすり合わせていきます。

詳しくは Ryuzeeさんや川口さんのまとめが大変参考になります！

www.ryuzee.com

kawaguti.hateblo.jp

私の適用場面

今回、私がワークショップに取り入れた理由は

「相対見積もり」という考え方を理解する
エンジニアが見積もりをどう考えて行っているかを理解してもらう
個々の経験値や熟練度によらない見積もりを意識してもらう
対話によってズレが埋まっていく体験をしてもらう

ということを持ち帰ってもらうためです。

そのため、今回はエンジニアのみでなく、営業もチームに入ってもらいました。

導入の方法

このワークショップの目的の一つに"相対見積もり"を理解してもらうということがありました。そのため、前半は座学をやり、よくあるこの図を使ったり、

f:id:HirokiHachisuka:20180922222108p:plain

ケーススタディーを伝えました。

しかし！やって見たことがある方はわかると思いますが、これが・・・

難しい！伝わりづらい！理解に個人差が生まれる！

ということで、

「実際にやってみましょう！」

ということで、ワークショップに導入しました。

準備とチーム分け

まずは、物の準備です。私が用意したのは

プランニングポーカー用カード

　- 前述のこれ　　Agile Goods-Scrum専門店

付箋とペン

　- ディスカッション時のやりとりを忘れないように書き留めてもらうため。

説明用のスライド

　- ワーク中に何をしていたか忘れないように出しておくもの

たったこれだけです。

そして、次に気にしたのが"チーム編成"です。この時は計14人ということで、4チーム(3+3+4+4)としました。

このチーム編成の時のポイントとして考えていたのが

営業と開発を完全にMIX
普段あまり関わりがなさそうな人同士を同じチームに
各チームのリーダーとして最も新人や最も若いメンバーをおく。

これにより、

仲間内での適当感の排除
若手をフォローする先輩たち
若手がリーダーという状況から真面目に参加せざるを得ない

という構図を作りました。

テーマを発表

そして、「何について見積もるか」のテーマを発表します。

ここが一番のポイントです！

普段エンジニア同士で行う場合は

「このサービスを作るなら・・・」「Twitterクローンだと・・・」

などのリアルな開発ネタがしっくりくると思います。

ところが今回は営業も参加しています。どうでしょうか？

このようなネタだと

「わからない」「つまらない」

ということで、会が破綻してしまうでしょう。

そこで、今回のテーマは

全員が共通で理解できるもの
共同作業を伴うもの
タスクにバリエーションがあり、チームごとに個性が出そうなもの
タスクの中でも解釈によって、工数がバラバラになりそうなもの
仕事感が少ないもの

を選ぶことが重要です。

そこで私は

「このチームでBBQ(日帰り)をする」

というテーマにしました。

何回かこのテーマをやりましたが、この時点で、軽く盛り上がります。

「あ、俺食材は釣りで集めたい！釣り！」「かまどでピザを焼きたい！」「まったり星を眺めたい」

などなどすでに大きそうなアイテムが聞こえてきますw そして、実際のアイテムの書き出しに入ります。

説明とプロダクトバックログ作り

テーマ発表と同時に手順を説明しました。

まずは各自で付箋に黙々とやりたいことを書く：5分

　- この時に「〇〇をしたい」という形式に統一しました。　- ユーザーストーリーの形式に近づけたいのと、見積もるにあたり、単位を統一したいからです。

やりたいことを集めて優先順位をつける = プロダクトバックログの作成： 5分

　- この前段でプロダクトバックログについての会も終えていたので、「プロダクトバックログ」という単語をあえて出しました。　- やってない場合は「やりたいことリスト」と言ったりしてます。

簡単そうなタスクを1つ決めて、ストーリーポイントを"2"とする：1分

　- ここで相対見積もりの考え方を改めておさらいし、理解を促しました。

優先度が高いものから「せーの」でカードを出す
ズレた場合は話し合う
再度「せーの」でカードを出す。

　- ここでルールを決めました。

　　(1)カードを出すまでは何を出すか匂わせない

　　(2)一人の発言によらないようにみんなで話すことを心がける

　　(3)多数決ではない。少数決でもない。

　　(4)忖度はナシw

という説明を行い、スタートです！

ワーク開始！

　あとは時間が許す限り、基本的には各チームを見守ります。そして、時折、ちょっかいを出します。

特に序盤は

みんなが大きな数を出す = 「タスクが大きすぎるので、イメージつかないのでは？分割してみては？」
見積もりの差が大きい = 「前提条件はどんなイメージ？しっかりチームで揃ってますか？揃ってなければ定義してみては？」
そのタスクが大きいか小さいかわからない = 「基準と比べるの忘れてない？近しいものを議論した時のメモを確認してみては？」

という形で、戸惑いそうな場面をアシストします。

そして、波に乗ってきて、自分たちで分割したり、前提条件を決め始めたら、今やっていることは何かを伝えます。

例えば・・・

「タスクが大きすぎて分割するのって、実際の開発でもよくありますよね？」「前提条件を決めることって、要件定義そのものですよね？」「"カレーを作る"の手順を書き出してるのって、設計ですよね？」

などなど。

そうこうしていると白熱したまま時間がやってきます。

ふりかえりと理解の時間

最後に、必ずふりかえりを行うようにします。

というのも、ワーク中は頭の中が「BBQ！BBQ！BBQ！」でいっぱいなので、中にはこれをなんのためにやっているのか見失う人もいます。

それだけ集中して楽しんでくれているということでそれも成功の証ですが、最後に目的どおりに学びを持ち帰ってもらうためにしっかりふりかえります。

ここから先は個人差や時間にもよると思いますが、この時は、

付箋を使って自由に振り返る
チームで共有
チームリーダー(最年少)がみんなに発表

という方法をとり、発表時にはワークの途中に挟んだような

みたいな解説を入れました。

そして、最後に用意していた「相対見積もりとは？」という資料を改めて読み合わせて1.5h終了という感じです。

このワークのポイント

このような感じで、プランニングポーカーのワークショップをやってみたのですが、私が思うポイントは以下です。

見積もりはエンジニアだけのためじゃないので、営業や企画職を織り交ぜるのがオススメ
ワークのテーマは以下を満たすものがオススメ　- 全員が共通で理解できるもの　- 共同作業を伴うもの　- タスクにバリエーションがあり、チームごとに個性が出そうなもの　- タスクの中でも解釈によって、工数がバラバラになりそうなもの　- 仕事感が少ないもの
全部をはじめに説明しても理解できないので、ワークの中でつまずいていたら、助け舟を出す
最後に「なぜやったのか？何をしたのか」を伝えて現実に引き戻す

あとはチームの特性を生かして準備をしっかり行うのが大事だと思います。