プランニングポーカーでアジャイルに見積もりしてみた

こんにちは、Kazです。2024年もよろしくお願いします。
私の所属するチームでは、3ヶ月ごとにリリース計画を、2週間ごとにイテレーション計画を建てながら開発を進めており、アジャイルな見積もり手法の１つである「プランニングポーカー」によっていつまでに何を開発するか(開発できるか)を決めています。本記事では、これまでチームでプランニングポーカーを1年ほど実践してきて実感したメリットや課題について紹介します。

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

プランニングポーカーは、ユーザーストーリーやタスクの開発規模を見積もるためのゲーム形式の見積もり手法です。チームメンバーが協力し、以下の流れで見積もりを行います。

1. ユーザーストーリーやタスクの説明
   ファシリテーター（プロジェクトマネージャーやスクラムマスターなど）が、見積もり対象のユーザーストーリーやタスクについて説明します。
2. 質問とディスカッション
   チームメンバーは見積もるために必要なこと（完了条件や前提条件など）を確認するための質問をし、必要に応じて議論して回答を出します。
3. 個別見積もり
   各メンバーはストーリーの規模をポイントで見積もり、（見積もったポイントの書かれた）カードを選びます。
4. 公開とディスカッション
   全員の見積もりが終わったらカードを公開し、メンバー間の見積もりが異なる場合はその理由を話し合います。
5. 再見積もり
   必要に応じて、見積もりを再度行います。これをチームが合意に達するまで繰り返します。

チームのやり方

ツール

プランニングポーカーは紙と鉛筆だけでもできますが、チームにはフルリモートのメンバーもいるため、「Team poker」というWebサービスを利用してオンラインで実施しています。他のツールも試しましたが、このツールは無料＆会員登録不要ですぐに使い始めることができ、メンバー間での同期もしっかり取れるのでオススメです。

https://team-poker.app/

ルール

一部カスタマイズしていますが、基本的には「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」という書籍のやり方を踏襲しています。2009年の本ですが今読んでもあまり古さを感じない内容になっていると思います。
https://amzn.asia/d/cMToJzj

主なルールを以下にご紹介します。

• 相対的な規模で見積もる
  工数（作業時間）ではなく、他のユーザーストーリーやタスクと比べた時の相対的な開発規模の大きさをストーリーポイントで見積もります。例えば会員登録のストーリーが2ptなら会員検索は3pt、会員削除は1ptといった形です。こうすることで人によるスキルの違いを吸収し作業者による属人性を排除することができます（例: スキルの高い人でも低い人でも会員登録の開発規模が会員削除の倍程度であることは変わらない）。
• 見積もり時点では担当者を決めない
  担当者が決まっていると、その人のスキルセットや作業速度に基づいた見積もりになりがちです。担当者未定のままで見積もることでより公平に評価することができます。私たちのチームではイテレーション計画の最後に各メンバーが次のイテレーションで最初に取り組むストーリーだけを決め、あとはイテレーション中の状況を見ながら柔軟に担当者を決めるようにしています。
• メンバー間の見積もりが異なる時の議論で非難をしない
  メンバー間の見積もりが異なる場合は、見積もりの大きい人、小さい人にそれぞれ理由を説明してもらってディスカッションします。この時、（1人だけ見積もりが乖離している時など）見積もりが間違っていると非難してしまうことはNGです。心理的安全性が下がって率直に自分の意見が言えないようになると、参加者全員で見積もることで精度を高めるプランニングポーカーの良さがなくなってしまいます。
• 大きすぎるユーザーストーリーは分割する
  ポイントはフィボナッチ数列の数字(1, 2, 3, 5, 8, 13, 21, ・・・)の書かれたカードから選択しますが、１つのイテレーションで収まらない大きすぎる数字になった場合はユーザーストーリーを分割して小さくします。ポイントが大きいほど見積もり精度が悪くなってしまうことと、イテレーション計画で合意した内容を完了することにコミットできなくなってしまうことが理由です。何ポイント以上を大きすぎるとするかはチームごとに異なりますが、私たちのチームでは13pt以上の場合は分割するようにしています。

プランニングポーカーを実践してわかったこと

メリット

• 潜在的な問題やより効率的なやり方に気付ける
  各メンバーが異なる視点からタスクを評価し見解を共有することで、潜在的な問題点や見落としが明らかになったり、より効果的な解決策や新たなアプローチに気づくことができます。例えば他のメンバーはデータベースを利用する想定でいたストーリーにおいて、この要件であればJSONファイルで代用可能で簡単化できるのでは？といった意見が出て大幅にポイントが減った、といったことがありました。
• 1人でやるよりバランスの取れた見積もりになる
  1人で見積もりをすると不安から必要以上にバッファをとってしまったり、期限に間に合わせるために過小な見積もりにしてしまったりと個人の傾向が反映されがちです。プランニングポーカーでは、複数の視点が組み合わさることで、これらの偏りが抑制され、より現実的でバランスの取れた見積もりになると感じています。
• 続けていくことで計画の精度が高まる
  ストーリーポイントは前述の通り、他のストーリーと比べた相対的な開発規模であるため、同じポイント数であっても誰がやるかによって実際にかかる時間は異なってきます。それでも繰り返し行なっていくと1イテレーションに完了できる合計ポイント数は安定していくため、イテレーション内でどこまで完了できるかの予測精度が上がっていきます。ただしこれはメンバーが固定されている場合に限ると思われます。
• チームワークが向上する
  特定の担当者を決めないでチーム全体で見積もりを行うことで、ストーリーに対する共通の理解と責任を共有することになります。見積もりプロセスを通して他のメンバーの誰が何をやっているかを理解できますし、イテレーション状況によっては他のメンバーの仕事を手伝うことでチームワークの向上にもつながると感じています。

課題

• 詳細に入りすぎるとストーリーポイントを決めるのに時間がかかってしまう
  ある程度設計や実装方法の議論をしなければ見積もりが出せない時があります。これは必要なことだと思いますが、あまりにも詳細に入りすぎると時間がかかり、チーム全員が参加しているためその合計時間は膨大になってしまいます。設計や実装方法の議論は見積もりをするのに最小限にするよう注意が必要です。また、私たちのチームではメンバーの1人だけが詳しく、かつ全員が知っておく必要もないものについては、1人で見積もってしまい時間を短縮しています。
• 調査・研究が必要なストーリーの見積もり精度が低い
  チームメンバーの誰も見当がつかない調査・研究が必要なストーリーの見積もり精度は悪く、見積もりと実際に費やす時間が乖離しがちです。ただ不確実性が高いものの見積もりは難しいのが当たり前で、これは他の見積もり方法でも同じことと想像しています（他に良い方法があれば教えてください）。対策としてストーリーから調査・研究部分だけを分割して先行させ、その結果を踏まえて残りの部分の見積もりをしていますが、調査・研究が必要なストーリーが多いと計画が狂いやすく現在も頭を悩ませています。
• ストーリーポイントの消化を優先し品質面が犠牲になりやすい側面がある
  合意した計画を守ることは大事なことですが、ストーリーポイントの消化を優先するがために品質面を犠牲にしてしまう問題が起きやすくなります。私たちのチームでも期限ギリギリのコードレビューをいつもより簡易に行なってしまったり、実験コードを後で再利用しやすくするための整理タスクを省いてしまうなどの問題が発生しました。対策としては品質面もストーリーの完了条件として定めておくことや、長期目標の達成を重視するよう注意することなどがあります。

まとめ

課題もありますが、プランニングポーカーは単なる見積もり手法以上のメリットがあり、小規模なチームでは非常にワークする仕組みであると実感しています。一方でメンバーが10人以上の場合など、チーム規模が大きいと全員が参加することによるデメリットの方が大きくなってしまう懸念もあります。今後チームメンバーが増えていった時の課題に向き合いながら試行錯誤していければと思います。