プランニングポーカーのルールと進め方 | Toolsbase

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

プランニングポーカーは、アジャイル開発チームがユーザーストーリーの見積もりを行うための合意形成手法です。チームメンバー全員が同時にカードを出すことで、特定の人の意見に引きずられることなく、独立した判断を集約できます。

2002年にJames Grenning氏が考案し、Mike Cohn氏の著書『Agile Estimating and Planning』（2005年）で広く知られるようになりました。今日では、世界中のスクラムチームやカンバンチームで最も広く使われているストーリーポイント見積もり手法です。

さっそくセッションを始めたい方は、無料オンラインプランニングポーカーツールをご利用ください。アカウント登録不要ですぐに使えます。

なぜ「ポーカー」なのか

通常の会議で見積もりを行うと、最初に発言した人やチーム内の上級者の意見に他のメンバーが引きずられる「アンカリング効果」が発生します。プランニングポーカーでは、カードを伏せた状態で同時に公開することで、この認知バイアスを排除します。ポーカーの手札のように、全員が宣言する瞬間まで自分の数字を隠しておくわけです。

プランニングポーカーの歴史と背景

James Grenningによる考案（2002年）

プランニングポーカーは、2002年にJames Grenning氏が発表した論文「Planning Poker or How to Avoid Analysis Paralysis while Release Planning」で初めて提唱されました。Grenning氏が抱えていた問題意識はシンプルなものでした。「従来の見積もり会議では、一人のエキスパートの直感がそのままチーム全体の見積もりになってしまう」というものです。

彼の洞察は明快でした。もし全員が独立して数字を決め、同時に見せれば、チームが持つ知識の幅が一瞬で明らかになる。最高値を出した人と最低値を出した人が、ほぼ必ず何らかの重要な観点に反応しているはずで、その理由を言語化させることに本当の見積もりの価値がある、というものでした。

Mike Cohnによる普及（2005年）

Mike Cohn氏が『Agile Estimating and Planning』にプランニングポーカーを取り上げたことで、この手法は世界中のスクラムチームに広まりました。Cohn氏はフィボナッチ数列ベースのカードセットと結びつけ、ストーリーポイント見積もりの実践的な文脈に位置づけました。出版後、プランニングポーカーはスクラムのデファクトスタンダードとなり、Scrum Guideこそ言及していないものの、多くのスクラムコーチが標準的なプラクティスとして教えるようになりました。

デジタル化の波

2010年代以降、リモートワーク・分散チームの普及に伴い、物理的なカードデッキはオンラインツールへと進化しました。現在では多数のオンラインプランニングポーカープラットフォームが存在し、当サイトのプランニングポーカーツールもその一つです。物理的な場所に集まらなくても、同時公開と議論の仕組みをそのままデジタルで再現できるようになっています。

基本ルール

カードの数列

プランニングポーカーで使用するカードは、修正フィボナッチ数列が一般的です。

カード	意味
0	作業不要（すでに完了している等）
1	最小の作業
2	小さな作業
3	やや小さい作業
5	中程度の作業
8	やや大きな作業
13	大きな作業（分割を検討）
21	非常に大きな作業（分割が必要）
?	判断できない（情報不足）
☕	休憩が必要

数列の間隔が広がっていく理由は、大きなタスクほど見積もりの精度が下がるためです。「13か14か」を議論するのは時間の無駄であり、「13か21か」という粒度で十分です。

参加者の役割

役割	参加	責務
プロダクトオーナー（PO）	ストーリーの説明	ストーリーの背景と受け入れ条件を説明する
スクラムマスター（SM）	進行役	議論のファシリテーション、時間管理
開発チーム	カードを出す	見積もりと根拠の説明
ステークホルダー	オブザーバー	質問への回答（カードは出さない）

見積もりのカードを出すのは実際に作業を行う開発チームのみです。POやマネージャーが見積もりに参加すると、暗黙のプレッシャーが生じるため避けるべきです。

見積もりスケールの比較：修正フィボナッチ vs Tシャツサイズ vs その他

チームによって使うカードセットは異なります。代表的な見積もりスケールを比較してみましょう。

修正フィボナッチ（最もポピュラー）

カード例： 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

多くのスクラムチームでデフォルトとして使われるスケールです。最大の強みは「大きくなるほど間隔が広がる」設計で、複雑なストーリーほど不確実性が高いという現実を自然に反映しています。

向いているチーム： ストーリーポイントに慣れたスクラムチーム、ベロシティ管理と連動させたいチーム。

弱点： 「5ポイントとはどのくらいか」という基準ストーリーが確立されていないと、新メンバーが迷いやすい。

Tシャツサイズ

サイズ例： XS, S, M, L, XL, XXL

数値ではなくサイズ感で表現するスケールです。「これはSか、Mか」という問いかけは直感的で、プロダクト探索フェーズやロードマップ計画など、まだストーリーの粒度が粗い段階でも使いやすいのが特徴です。

向いているチーム： プロダクト探索フェーズ、ロードマップの優先順位付け、数値見積もりに抵抗があるチーム。

弱点： ベロシティ計算に直接使えないため、後から数値にマッピングする必要があります。

2のべき乗

カード例： 1, 2, 4, 8, 16, 32

各カードが前の倍になる、シンプルな倍数スケールです。「前回の倍の複雑さ」という感覚を持つエンジニア寄りのチームにフィットします。

向いているチーム： エンジニアリング文化が強く、倍数のロジックが直感的に分かるチーム。

弱点： 16と32の差が非常に大きく、「大きい」と「巨大」の中間を表現しにくい。

スケール選択の指針

シナリオ	推奨スケール
一般的なスクラムチーム	修正フィボナッチ
ロードマップ・プロダクト計画	Tシャツサイズ
エンジニアリング重視のチーム	2のべき乗
時間見積もりが必要な場合	プランニングポーカーではなくタイムボックスで対応

最も重要なのは、チームが同じスケールを継続して使うことです。スケールが一貫していれば、スプリントをまたいでベロシティを比較できます。スケールの変換が必要な場合はストーリーポイント計算機をご活用ください。

進行手順

ステップ1: ストーリーの説明（2〜3分）

プロダクトオーナーがユーザーストーリーを読み上げ、背景と受け入れ条件を説明します。

ユーザーストーリー:
「ユーザーとして、注文履歴をCSVでダウンロードしたい。
 過去の購入を家計簿アプリに取り込むためだ。」

受け入れ条件:
- 過去1年間の注文を対象とする
- CSV形式で日付・商品名・金額・ステータスを含む
- ダウンロードボタンは注文履歴ページに配置する

ステップ2: 質問と議論（3〜5分）

開発チームがストーリーに関する質問を行います。ここでの目的は、ストーリーの不明点を解消することであり、実装方法の詳細を決めることではありません。

よくある質問の例：

「注文数が1万件を超える場合のパフォーマンス要件はありますか？」
「CSVのエンコーディングはUTF-8固定ですか？」
「フィルター（期間指定等）は必要ですか？」

ステップ3: カードを同時に出す

質問が終わったら、各メンバーがカードを選び、スクラムマスターの合図で同時に公開します。

Aさん: 5
Bさん: 5
Cさん: 8
Dさん: 13

ステップ4: 差異がある場合の議論（2〜5分）

カードの値が大きく異なる場合（通常、最高値と最低値の差が2段階以上）、最高値と最低値を出した人がそれぞれ理由を説明します。

Dさん（13）: 「大量データのCSV生成は非同期処理が必要で、
              ジョブキューの実装が追加で必要になると思います」

Aさん（5）:  「既存のレポート機能のCSV生成を流用すれば、
              新規実装は最小限で済むと思います」

この議論を通じて、チーム全体がストーリーの複雑さを共有し、見落としていた考慮点が明らかになります。

ステップ5: 再投票と合意

議論後に再度カードを出します。2回目で合意に至らない場合は、以下のいずれかを選択します。

多数決で決める: 5が2人、8が2人なら、間を取って8にする
ストーリーを分割する: 合意できないのはストーリーが大きすぎる兆候
スパイク（調査タスク）を設定する: 技術的な不確実性が高い場合

分散・リモートチームでのプランニングポーカー

リモート環境でのプランニングポーカーは、通信ラグ・ノンバーバルコミュニケーションの欠如・参加者の離脱といった独自の課題を抱えています。対面と同等の質を維持するための実践的な方法を紹介します。

ツールの選び方

オンライン専用のプランニングポーカーツールを使うことで、最も重要なメカニズムである「同時公開」をデジタル環境でも確実に実現できます。チャット投票やアンケートツールを流用すると、他の人の回答を見てから自分の答えを変えることができてしまい、プランニングポーカーの本質が損なわれます。

選ぶ際のポイント：

全員が回答するまで非表示の同時公開機能
URLを共有するだけで参加できる（参加者のアカウント登録不要）
未回答者が分かる参加者リスト
タイムボックス用のタイマー
過去の見積もり履歴の参照機能

セッション開始前のグランドルール

対面では自然に成立している「発言の順番を守る」「全員が集中する」といった暗黙のルールは、オンラインでは明示的に取り決める必要があります。

議論中はカメラをオンにする
発言しないときはマイクをミュートする
質問はチャットに書いてから口頭で補足する
投票中は別の作業をしない

タイムゾーンをまたぐチームへの対応

3つ以上のタイムゾーンにメンバーが分散している場合、リアルタイムのセッションに参加すること自体が負担になります。現実的なアプローチとして以下が有効です。

オーバーラップ時間を活用する: 両タイムゾーンが重なる2時間の窓を探してセッションを設定する。
事前の非同期リファインメント: 共有ドキュメントで事前に質問を集めておくことで、ライブセッションを大幅に短縮できる。
非同期投票の活用: シンプルなストーリーは各自の都合の良い時間に投票し、決まった時刻にファシリテーターが結果を公開する方式も選択肢のひとつ。

リモートの「場」を活性化させる工夫

オンライン会議での認知的疲労はリアルよりも高くなります。場のエネルギーを保つために：

ファシリテーターをローテーションする: 全員が持ち回りでファシリテーターを経験することで、チームの主体性が育つ。
素早い全会一致を称える: 一発で全員が同じ数字を出したときは、積極的に褒める。ポジティブな空気を積み重ねることが大切。
45〜60分ごとに休憩をとる: ☕カードが出たら素直に従う。
長い技術的議論はブレイクアウトルームへ: 2人が深い技術論を始めたら別室に移動してもらい、残りのメンバーは別のストーリーの投票を進める。

スプリント計画との連携

プランニングポーカーは通常、スプリント計画の数日前に行われるバックログリファインメント（バックロググルーミング）で実施します。2つのセレモニーの関係を理解することで、双方の効果を最大化できます。

スクラムサイクルの中でのポジション

プロダクトバックログ → バックログリファインメント → スプリント計画 → スプリント → レビュー → レトロスペクティブ
                              ↑
                 プランニングポーカーはここで実施

バックログリファインメントがプランニングポーカーに最適な理由：

ストーリーがまだ変更可能: 見積もりの結果、ストーリーが大きすぎる・曖昧すぎると分かれば、スプリント計画の前に分割・修正する時間がある。
コミットメントのプレッシャーが低い: スプリントに取り込むかどうかはまだ決まっていないため、チームは正直に見積もれる。
スプリントに1〜2回実施できる: バックログを継続的に整備することで、常に見積もり済みのストーリーがプールされた状態を維持できる。

スプリント計画が前提とすること

スプリント計画会議は「選択してコミットする」場です。見積もりをその場で初めて行う場ではありません。バックログリファインメントをスキップしてスプリント計画で見積もりを始めると、会議が長くなり、チームが十分に理解していないストーリーにコミットするリスクが高まります。

ベロシティによるスプリント容量の算定

ストーリーの見積もりが終わったら、チームの過去のベロシティを使ってスプリントに取り込める量を決めます。ベロシティとは、直近3〜5スプリントの完了ストーリーポイントの平均値です。

ベロシティ計算機を使えば、チームのローリング平均を計算し、次スプリントの適切なコミット量を設定できます。「今回だけ無理をする」ことは長期的に避けるべきで、持続可能なペースを守ることが重要です。

見積もり済みバックログを前提にしたスプリント計画の流れ

見積もりが完了したバックログがある場合、スプリント計画は以下のような流れになります。

スプリントゴールの確認（5分）: POがスプリント全体のテーマを説明する。
ストーリーの選択（20〜30分）: ベロシティ（容量）を超えない範囲でバックログの上位ストーリーを選ぶ。
タスクへの分解（30〜45分）: 選択したストーリーを具体的な開発タスクに落とし込む。
コミットメント（5分）: 選択したスコープが1スプリントで達成可能かチームが確認する。

リファインメントで見積もれなかったストーリーがスプリント計画に持ち込まれた場合、シンプルなものはその場で簡易見積もりを行い、複雑なものは次のスプリントに回す判断も重要です。

オンラインでの実施

オンラインツールの利点

カードの同時公開が確実にできる（画面越しだとタイミングが合わない問題を解消）
結果の自動記録と集計
タイマー機能による時間管理
非同期での実施も可能

オンラインで注意すべき点

対面と比べてコミュニケーションの情報量が減るため、以下を意識します。

カメラをオンにする: 表情やリアクションが議論の質を高める
チャットを活用する: 口頭での議論と並行してチャットで補足する
タイムボックスを厳守する: オンラインは議論が長引きやすい
ファシリテーターの役割が重要: 発言の偏りを意識的に調整する

効果的な議論のコツ

タイムボックスを設定する

1つのストーリーに費やす時間を制限します。推奨は最大5分です。5分で合意できない場合は、ストーリーの定義自体に問題がある可能性が高いです。

「?」カードを活用する

情報不足で判断できない場合は、無理に数値を出さず「?」カードを使います。「?」が出たら、まず不足している情報を特定し、その場で解消するか、後日調査する旨を記録します。

基準ストーリーを常に参照する

議論が発散しそうになったら、基準ストーリーに立ち返ります。

「基準ストーリー（ユーザープロフィールの電話番号追加 = 3ポイント）
 と比べて、このストーリーはどのくらいですか？」

全員の意見を引き出す

声の大きい人だけが議論をリードしないよう、スクラムマスターは意識的に発言の少ないメンバーに意見を求めます。特に新しいメンバーの視点は、チームが当たり前だと思っている前提を見直すきっかけになります。

よくある課題と解決策

課題1: 見積もりセッションが長すぎる

症状: 2時間のセッションで10ストーリーしか見積もれない。

解決策:

1ストーリーの制限時間を設ける（5分）
事前にストーリーを共有し、質問を事前に集めておく
小さなストーリー（明らかに1〜2ポイント）はまとめて見積もる
1回のセッションは最大90分に制限する

課題2: いつも同じ人が最高値・最低値を出す

症状: 慎重なAさんがいつも最高値、楽観的なBさんがいつも最低値。

解決策:

過去の見積もりと実績を振り返り、どちらが実態に近いかをデータで示す
見積もり後に「何が含まれていて何が含まれていないか」を確認する
基準ストーリーとの比較を徹底する

課題3: POが見積もりに介入する

症状: 「それ、5ポイントもかかるの？3で終わらない？」

解決策:

POの役割はストーリーの説明と質問への回答であることを明確にする
見積もりはチームの判断であり、POが変更すべきものではないことを合意する
見積もりが高い場合は、スコープの調整（受け入れ条件の削減）で対応する

見積もり精度の測定と改善

プランニングポーカーの価値は、セッション自体ではなく、そこから生まれる学習ループにあります。計測なしでは、見積もりが改善しているかどうかも、系統的なバイアスが発生しているかどうかも分かりません。

基本指標：見積もりと実績の比較

スプリント終了後に、完了した各ストーリーの見積もりポイントと実際の複雑さを比較します。「実際の複雑さ」は主観的ですが、「今のチームの知識でこのストーリーを見積もり直したら何ポイントになるか」を問うことで近似できます。

ストーリー	見積もり	実績（振り返り）	比率
CSV出力	5	5	1.0
決済連携	8	13	1.63
ユーザーオンボーディング	13	8	0.62
検索サジェスト	3	3	1.0

比率が1.0を常に上回る場合は過小見積もり傾向、1.0を下回る場合は過大見積もり傾向があります。

ベロシティのトレンド分析

スプリントごとのベロシティを追跡します。健全なベロシティグラフは比較的安定しており、自然な変動幅は±20%程度です。大きなスパイクや急落は診断シグナルです。

急落: 予想外に難しいストーリーがあったか、計画外の作業が発生した。
急上昇: 見積もりが水増しされていたか、今スプリントの作業が例外的にシンプルだった。

ベロシティ計算機を使うと、トレンドを可視化し異常値を早期に発見できます。

キャリブレーション（定期的な再調整）

4〜6スプリントごとに、以下のキャリブレーションセッションを実施することを推奨します。

直近20〜30件の完了ストーリーの見積もりと実績を抽出する。
特定のストーリー種別（インフラ、UI、外部連携など）に系統的なズレがないか確認する。
ズレが顕著な種別の基準ストーリーを見直す。
チームが1や2をほとんど使わない、あるいは常に13以上になるなら、スケール自体の再調整を検討する。

計測してはいけないこと

個人の見積もり精度: 誰のカードが最も正確だったかを個人レベルで追跡してはいけません。見積もりはチームの活動であり、個人スコアリングは心理的安全を破壊します。
合意の速さ: 素早い全会一致が必ずしも良いわけではありません。ゴム印的な「なんとなく合意」になっていないか注意が必要です。

見積もり精度が向上しているサイン

最高値と最低値の差が縮まってきた（チームの共通理解が深まっている）
「?」カードが減ってきた（ストーリーがリファインメントで十分に整備されている）
スプリントをまたいでベロシティの分散が小さくなってきた
レトロスペクティブでの「なぜズレたか」の議論が短く、建設的になってきた

レトロスペクティブとの連携

スプリント終了後のレトロスペクティブで、見積もりの振り返りを行うことで精度が向上します。

振り返りのポイント

完了したストーリーの見積もりと実際の複雑さを比較する
大きくズレたストーリーについて原因を分析する
見積もりの前提が間違っていなかったかを確認する
次回の見積もりに活かすべき学びを共有する

ただし、「見積もりが外れた」ことを責める場にしてはいけません。見積もりは予測であり、外れることは自然です。目的はチームの学習であり、個人の評価ではありません。

よくある質問（FAQ）

ストーリーポイントとプランニングポーカーの違いは何ですか？

ストーリーポイントは「単位」、プランニングポーカーはその単位を決める「プロセス」です。ストーリーポイントは一人の担当者が見積もる形でも使えますし、プランニングポーカーはTシャツサイズなど別のスケールでも実施できます。実際には、プランニングポーカーが最もポピュラーなストーリーポイント見積もり手法であるため、両者は密接に結びついて語られることが多いです。

1回のセッションで何ストーリーを見積もれますか？

準備が整ったストーリーを対象に、60〜90分のセッションで10〜20ストーリー程度が目安です。ストーリーの整備が不十分だと1件に時間がかかります。90分で8件を下回る場合は、セッション前のストーリー準備（リファインメント）に投資するとよいでしょう。

プロダクトオーナーはカードを出してよいですか？

出さないのが原則です。POの役割はストーリーの背景と受け入れ条件を説明し、チームの質問に答えることです。POがカードを出すと、その数字が暗黙の権威を持ち、チームの見積もりをアンカリングするリスクがあります。特にPOが上位の管理職を兼ねている場合は注意が必要です。

2回投票しても合意に達しない場合はどうすればよいですか？

2回試みても合意できない場合は、以下の3つのどれかを選びます。（1）高い方の見積もりを採用して先に進む、（2）ストーリーを小さな単位に分割する、（3）スパイク（タイムボックスで実施する調査タスク）を設定して技術的不確実性を解消してから再見積もりする。「議論を続けても収穫が少ない」と判断したら、決断してセッションを前進させることが大切です。

カンバンチームもプランニングポーカーを使えますか？

使えます。プランニングポーカーはスクラムを前提に設計されていますが、カンバンチームのバックログリファインメントにも同様に適用できます。スクラムではベロシティ計算にストーリーポイントを使いますが、カンバンではサイクルタイムの予測や優先順位付けに役立てることができます。

大規模チーム（10人以上）でのプランニングポーカーはどうすればよいですか？

10人以上のチームでは、2グループに分けてそれぞれ見積もりを行い、結果を比較する方法が有効です。あるいは、サブチームごとに代表者を決める「代表投票制」も選択肢です。多様な視点を残しつつ、議論が発散しないようにするのがポイントです。

スパイクとは何ですか？

スパイクとは、見積もりに必要な情報を得るために設けるタイムボックス型の調査タスクです。技術的に不明な点が多くてストーリーを見積もれない場合、「スパイク（例：〇時間で調査）」をスプリントに入れ、完了後に改めてストーリーを見積もります。スパイク自体はストーリーポイントではなく時間（時間数）で管理するのが一般的です。

どのくらいの頻度で基準ストーリーを見直すべきですか？

チームメンバーが大きく入れ替わったとき、採用技術スタックが変わったとき、あるいは見積もりと実績のズレが系統的に発生し始めたときが見直しのタイミングです。目安として4〜6スプリントに1回、軽いキャリブレーションセッションを設けると健全です。

まとめ

プランニングポーカーは、チーム全員の知見を引き出し、見積もりの精度と共通理解を同時に高める手法です。同時にカードを出すことでアンカリング効果を排除し、最高値と最低値の議論を通じてストーリーの理解を深めます。

見積もりスケールの選択、スプリント計画との連携、そしてレトロスペクティブを通じたデータ駆動の改善を組み合わせることで、チームの見積もり力は着実に向上していきます。

次のセッションをすぐに始めたい方は、無料オンラインプランニングポーカーツールをお試しください。ベロシティ計算機と組み合わせることで、データに基づいたスプリントコミットメントが実現できます。