みんなで見積もれ!アジャイルな見積もり手法「プランニングポーカー」のやり方

B!

mofmof inc.のエンジニア兼代表の原田です。

システム開発に関わったことがある方であれば、きっと「見積もり」の難しさについてはご存知のことと思います。業界全体でも多くの見積もり手法が生まれ、より効率的により正確に見積もれるようにしようと奮闘していることと思います。

今回は、いくつか存在する中の1つ、アジャイル開発で頻繁に用いられている「プランニングポーカー」という見積もり手法について紹介と解説をしていきます。

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

簡単に箇条書きすると以下のような特徴があります。

  • 一人ではなくチームで見積もる
  • 相対見積もり
  • 専用のカードを使用する

なぜプランニングポーカーが良いのか

ソフトウェアの納期見積もりは、星占いレベルのものであると思う

引用: ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ

ぼくはこの言葉が好きで、良く社内研修の場でも用いている言葉です。

一般的な感覚では、見積もりはある程度正確に計算出来る性質のものである、という認識があると思います。しかし実は、システム開発においてはこれが成り立ちません。

なぜなら、システムをどのように作るか?(つまり要件)は、非常に複雑で、かつ作り手の解釈によって大きく変わってしまう曖昧さを排除出来ないからです。

システム開発よる見積もりのブレ具合については、この「不確実性コーン」という図が有名です。この図ではプロジェクト初期の見積もりでは、最大4倍のズレが起こりうることが示されています。

不確実性コーン

引用: プロジェクトの本質とはなにか 日経クロステック(xTECH)

その難しさに対抗して、少しでもマシな見積もりをするための1つの手段として、プランニングポーカーがあります。あくまでも「少しでもマシにする」ためであり、完璧で正確な見積もりをする手段ではありません。

チームで見積もることにより、考慮漏れを顕在化させ、相対的に見積もることで正確さを向上させ、出来るだけ時間をかけずに見積もることが出来るのが、プランニングポーカーです。

プランニングポーカーは何を解決するか

プランニングポーカーは以下のことを解決する方法です。

  1. 見積もり担当者と実装担当者とのギャップを埋める
  2. 一人で見積もりするよりも早く正確に見積もれる

よくあるケースとして、システム開発(あるいは機能開発)のオーダーがあった場合、担当しているエンジニアの1人が主観で見積もることが多いです。

例えば、エンジニアAさんが10日で出来ると見積もったとして、開発を担当するエンジニアBさんは実装に20日かかってしまったとする。すると、Aさんは「実装が遅すぎるのでは?」Bさんは「ムチャクチャな見積もりしやがって…」と互いの思惑が食い違う結果になってしまいます。

プランニングポーカーは、誰か一人が見積もりを担当するのではなく、開発に関わる全員で見積もり、そのときに見積もりに差異があれば、必ず認識を揃えるために議論を行います。このような仕組みから、見積もり担当者と実装担当者の間でのギャップを埋めることが出来ます。

このプロセスを挟むことにより、複数人の頭を経由させて、考慮漏れを顕在化させ、より効率的な作り方を発見することが出来るので、一人で見積もりするよりも早く正確に見積もることが出来ます。

プランニングポーカーのやり方

  1. ユーザーストーリーの一覧を洗い出す
  2. ユーザーストーリーの中から基準となるストーリーを決めて、1pt もしくは3ptを割り当てる
  3. ユーザーストーリーの1つずつ読み以下を繰り返す
    1. ストーリーの詳細をヒアリングする
    2. ストーリーが大きすぎる場合は分割する
    3. 全員で見積もって、各自プランニングポーカーのカードを裏返しに場に出す
    4. 全員同時にカードを表にする
    5. チームでそれぞれの意見を聞いて妥当な数字で合意して決める。特に一番大きい数字と一番小さい数字の意見を聞く

ユーザーストーリーの一覧を洗い出す

まずはユーザーストーリーを洗い出します。ユーザーストーリーとは、ユーザーにとっての価値を言葉で表現したもので、機能リストやチケットとは異なりますが、開発者が実装するときの1単位となる点は同じです。

ユーザーストーリーは、「〇〇は、△△することが出来る。なぜならば□□だからだ」というフォーマットに従って記入していきます。

最初から全て網羅して洗い出すのは難しいものなので、必ず漏れや追加がある前提で進めます。

今回は見積もりの話なので詳細は省きますが、詳しくはこのスライドに読むと分かりやすいと思います。

ユーザーストーリー駆動開発で行こう。 from toshihiro ichitani

基準となるユーザーストーリーを決める

ある程度洗い出しが出来たら、次はその中から基準となるストーリーを選択します。このとき、出来るだけ見積を担当する全員がどのように実装するのかイメージが出来て、かつ小さめのものを選ぶのが適切です。そしてそのストーリーに1ptもしくは3ptをつけます。

1ptか3ptかはどちらでも良いのですが、そのストーリーより小さいものが存在し得ると考えられるのであれば3pt、そうでなければ1ptをつけます。

ストーリーポイントとは何か

この1ptや3ptといったもののポイントとは、ストーリーポイントと呼ばれているものです。誤解されがちですが、ストーリーポイント=工数ではありません。工数(作業に要する時間)ではなく、ストーリーポイントという概念に変えることで、実装者ごとのスキル差を吸収して見積もりを出来るようになります。

例えば、1ptで見積もられたストーリーがあり、スキル差のあるAさんBさんがいるとして、Aさんが実装したら1時間、Bさんが実装したら3時間かかると見積もっていたとしても、両者が提示するポイントは同じ1ptになります。これが3ptだったとしても同じで、Aさんは3時間、Bさんは9時間かかると見積もっても、提示する見積もりは同じ3ptになります。

従って、プランニングポーカーによる見積もりの場では、工数の概念を用いずに行います。出来るだけ「これをやったら何時間かかりそう」というような言葉を使用しないように注意しましょう。

プランニングポーカー専用カードを使用する

まず、プランニングポーカー専用のカードを準備しましょう。Amazonで販売されているものもありますし、自作するでも十分です。

この専用のカードは、フィボナッチ数列(もどき)になっていて、「0, 1/2, 1, 3, 5, 8, 13, 20, 40, 100, ∞, ?」という数字が書かれています。

システム開発における見積もりは、複雑さと曖昧さとの戦いです。見積もり単位が大きければ大きいほど、複雑で曖昧なものになるので、大きい数字になるほど数字幅が粗くなるフィボナッチ数列(もどき)が、その特性をよく表すことが出来ます。

単位が多すぎて複雑で曖昧なユーザーストーリーを、そのままの状態で精緻に見積もろうとしても不毛なので、40や100のように、とりあえず粗くて大きい数字を割り当てることを強制して、ムダに時間を費やしてしまうことを避けることが出来ます。

基準となるユーザーストーリーと比較して見積もる

いよいよ見積もりが始まります。

基準となるストーリーと比較して、見積もり対象のストーリーがどの程度大変なのかを見積もっていきます。1ptのストーリーより、3倍くらい大変そうなら3pt、5倍くらい大変そうなら5ptという具合です。

各自見積もったらこのようにカードを裏返しに場に出し、全員出し切ったら、全員同時に表にひっくり返します。

表にしたカード

最初裏返しに出す理由は、他の人の見積もりに影響されないようにするためです。特にリーダークラスのエンジニアがいた場合、その人の見積もりが正しいはず、というバイアスがかかりやすくなってしまうためです。

各自の見積もりを確認して、バラツキがあれば、それぞれの見積もりの理由を議論して確認し、全員が納得できる数字で合意して決めます。特に一番大きいポイントと一番小さいポイントの人の意図を引き出すと、各々の見えているものの違いを発見しやすくなります。

ときおり、経験が浅めなエンジニアが出す見積もりが、全体と乖離する傾向が見られるときがありますが、罪悪感を感じる必要もありませんし、感じさせないように配慮しましょう。実装のイメージがついていなかったり、楽に実装出来る方法を知らなかったり、ということが顕在化されただけです。むしろそれもプランニングポーカーの利点の1つです。

この手順を繰り返し、最初に出したユーザーストーリーの一覧全て、あるいは今回のリリースに含む範囲全てを見積っていきます。

大きすぎるユーザーストーリーは分割する

この方式で見積もっていると、ときおり、40ptや100ptなどとても大きなポイントをつけざるを得ないストーリーが出てきます。これは、そのストーリーの実装ボリュームよりも、複雑で曖昧であることを表しています。

このまま実装したのでは、実際との乖離があまりに大きくなってしまうリスクがあるので、小さいストーリーに分割していきます。分割する単位としては、実装のイメージが出来るだけクリアになる粒度まで小さくします。

例えば、「求人管理することが出来る」というストーリーがあるとしたら、

  • 求人を掲載できる
  • 応募出来る
  • 応募者一覧を管理できる
  • 応募者に合否を出せる
  • 求人を非公開に出来る

などのように、ストーリーを分割して、その一つ一つに対して見積もることで、比較的正確な見積もりに近づけることが出来ます。

どの程度のポイント数なら分割すべきかは、チームによって適切な基準を設けるべきですが、mofmof inc.では概ね13pt以上のポイントは分割すべきという基準でやっています。

なぜ相対的に見積もるのか

プランニングポーカーの特徴の1つが相対見積もりです。一般的な見積もり手法では、機能一つ一つを分析して、工数を積み上げしていく絶対見積もり方式を取られていることが多いですが、実は絶対見積もりより相対見積もりの方が正確性が高くなるという研究結果があるようです。

研究調査によると、人間は相対見積りならうまくこなせるらしい、たとえば、目の前に岩が転がっていたとしよう。このとき、片方の岩がもう片方の岩に対してどれぐらい大きいかは、非常に正確に見積もれるそうだ。

引用: アジャイルサムライ-達人開発者への道

例えば、この牛の体重はどれくらい?という質問への回答は、よほど普段から牛への関心を払っている人でなければ回答が難しいのではないかと思います。

この牛の体重は?

では、この左の牛の体重が600kgだとしたら、右の牛の体重はどの程度でしょうか?

もう1頭の牛の体重は?

このケースでは、多くの人が比較的正確に見積もりを出すことが出来るのは想像に難しくないでしょう。一方の牛の体重が分かっていれば、もう一方の牛の体重は視覚的情報だけでも、そこそこな精度で見積もれるのです。

見積もった後どうするか?

このように見積もった結果、例えば「トータル100ptでした」と分かったとしても、相対見積もりの尺度のままでは、それが一体どのくらいの期間を要するのかを知ることが出来ません。

そこで、これを知るために、実際に開発をスタートさせてみます。2週間〜1ヶ月程度やってみて、消化できたポイント数を基準として期間を割り出します。例えば2週間で10ポイント消化出来たとしたら、100ptを消化するには、20週間必要になる計算が出来ます。

チームで消化ポイントはそのときの状況により大きく変わってきます。例えばプロジェクト始動直後は消化ポイントが上がりにくかったのが、慣れと同時に上がってくるケースもありますし、増員により消化ポイントがあがるケースもあります。

今回は詳しくは述べませんが、チームのアウトプット能力を可視化するために「ベロシティ」という平均の消化ポイント数を計測します。アジャイル開発において、計画は状況によって柔軟に変更していくべき性質のものなので、このベロシティに合わせて計画を随時見直していきます。

まとめ

mofmof inc.では新入メンバー向けの研修題材として、プランニングポーカーについてもワークショップ形式で教えています。普段使用しているスライドは公開されていますので、良かったら参考にしていただければと思います。

見積の精度やスピードに悩んでいる方は、ぜひ一度プランニングポーカーに挑戦してみてください。