ポイント制&相対見積もりへの移行の経緯とプランニングツールを自作したお話

こんにちは、匠平@show60です。

back check 開発チームではプランニングポーカーを用いたタスクの見積もりを実施しています。

その作業を支えるべく、フルリモート勤務のチームでもオンラインでプランニングポーカーを行えるツール Okimochi Planning を作りました。冬休みの自由研究として (勝手に) 取り組んだのですが、チームで実際に約3ヶ月ほど運用し、改良を重ねて基本仕様としては問題ないものになったかと思っています。

今回は back check 開発チームが行ってきたタスク見積もりの経緯と、自作プランニングツールについて紹介させていただきます。

時間&絶対見積もりから、ポイント&相対見積もりへの移行

back check 開発チームがスクラム開発を導入した当時、チケットの見積もりはタスクの消化時間を単位として、絶対見積もりを行っていました。

この見積もり方法には2つの大きな問題があったのですが、チームのスクラム開発の成熟度向上とともに徐々ストーリーポイントを用いた相対見積もりへと移行していきました。

フィボナッチ数列を用いて不確実性を認める

大きいチケットの見積もりは不確実性が高くなります。小さいタスクが "1時間で終わるか2時間で終わるか" は見積もれるかもしれませんが、"6時間かかるか7時間かかるか" は不確実性が高すぎるため見積もりの難易度が上がります。

これを解消するため、「大きいものほど不確実が高い」を表すことができるフィボナッチ数列を見積もりに用いました。数列が "0, 1, 2, 3, 5, 8, 13 ..." という単位で上がっていくので、例えば「6時間かかりそうだな」と思った場合は、6は数列に含まれないので近接する 5 か 8 とする必要があります。

ja.wikipedia.org

フィボナッチ数列の導入により、不確実なものの見積もりは不確実であることをチームとして認めることができ、"6時間か7時間か" といった不毛な議論を防ぐことができます。

こうした非線形の数列も、見積もりのスケールにふさわしい。見積もりの対象が大きくなると不確実性が増えていくという様子にうまく対応しているからだ。

参考: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 - P75より

相対見積もりを用いてスキル差をなくす

この時点での見積もりは、「このタスクは自分なら6時間かかる」といったような見積もりを行っていました。

個人のスキル差があるため、当然見積もりの結果にも差異が出るという問題があります。特に back check ではメンバーのマルチスタックな働きを推奨し、自分が得意でない分野のタスクにも取り掛かる機会があるためこの課題は顕著に現れていました。

この解消のために、相対見積もりを導入しました。あるタスクの見積もりを決め、それと比較したときのボリュームを見積もるという方法です。このときタスクの消化時間に換算しません。

例を挙げてみます。

【前提】
・タスクA: すでに完了しているタスク
・タスクB: これから見積もるタスクで、タスクAよりも実装ボリュームが大きい
・開発メンバー1: タスクAは2時間で実装可能。タスクBはタスクAより3倍程度の大きさだと考える。
・開発メンバー2: タスクAは4時間で実装可能。タスクBはタスクAより2倍程度の大きさだと考える。

【絶対見積もりの場合】
タスクBを見積もるとき、
開発メンバー1は3倍程度と考えるため、6時間と見積もった。
開発メンバー2は2倍程度と考えるため、8時間と見積もった。

【相対見積もりの場合】
開発チームとして、タスクAを1ptと据え置いて、他のタスクはタスクAと比較して見積もるものとする。
タスクBを見積もるとき、
開発メンバー1は3倍程度と考えるため、3ptと見積もった。
開発メンバー2は2倍程度と考えるため、2ptと見積もった。

最終的にチームの見積もりとして収束させる過程において、相対見積もりではタスクの大きさだけを考慮して議論すればいいのに対して、絶対見積もりでは個人のスキル差も考慮する必要があるため複雑です。場合によっては「開発メンバー1が実装することになるだろうから6時間にしよう」と個人に依存した結果にもなりかねません。

相対見積もりを用いることで、個人のスキル差を排除し、タスクの大きさだけに注目した見積もりを実施できるようになります。

また相対見積もりは絶対見積もりと比較して見積もりがしやすいという利点もあります。

人は10倍以内のものならうまく見積もれる、という研究がある。自分の住んでいる街のことなら、いろいろな場所への相対的な距離をうまく見積もれるはずだ。 [中略] もしこれが、月面までの距離や隣の国の首都までの距離だったら、はるかに不正確な見積もりしかできない。

参考: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 - P74より

ここで重要なのは、相対見積もりのための基準を何にするかですが、back check 開発チームでは、過去に完了したタスクから適切なものをピックアップして基準チケットと据え置いています。新規参画メンバーには分かりにくいという課題も出てくるのですが、そのときは基準チケットを更新するなど柔軟に対応する姿勢を取っています。

自作プランニングポーカーツールの紹介

開発チームは基本フルリモートのため、オンラインでプランニングが可能なツールを探していました。

チームでいくつかのツールを試してみましたが、どれも痒いところにあと一歩手が届かないものばかりだったため、「なければ作れ」ということで作ってみました。

f:id:show-hei:20220331172259p:plain
okimochi planning

okimochi_planning

2022年始の冬休みの期間で作り、新年一回目のリファインメントから実際に利用を開始しました。

実際に運用してみると必要な機能が見えてきたので、ユーザー (チームメンバー) からのフィードバックを元に次のリファインメントまでに実装しておくという開発サイクルを続けました。運用開始から約1ヶ月ほどで現在の形に落ち着いています。

ファビコンが Nuxt のままだったり、デザインがシンプルすぎるなどせめてそこくらいは直してから出せよって感じなんですが、自分に "Second best tomorrow" と言い聞かせてこの場でシェアします。

基本的な使い方

  1. 「Create New Room」でプランニング用のルームを作成
  2. 作成されたルームの URL を共有し、メンバーがルームに入室できる
  3. カードを選択しポイントを見積もる
  4. 「Reveal」で全カードをオープンする
  5. 「Clear」で全カードをリセットする

ここがポイント🤘

  • Reveal されたカードはポイント数値昇順でソートしているのでカード数のカウントがしやすいです
  • 入室するが見積もりには参加しない人 (PO など) のために、Voter ボタンで切り替えることで閲覧モードにすることができます
  • Reveal されているときに入室すると、次の投票からしか参加できません (遅れずに投票しようね)

といった簡単な機能ではありますが、基本機能は備えているので、ぜひ試してみていただけると嬉しいです。

さいごに

私たち back check はリファレンスチェックを日本の採用のスタンダードにすべく日々奮闘中です。一緒に市場を盛り上げたいという仲間を募集しております。

herp.careers

herp.careers

その他のポジション もありますのでぜひこちらもご覧ください!