概要
ZenHubでスクラム開発を行う際の見積もり方法を記載した記事です。
どのような考えで、見積もりを行うかをまとめます。
対象読者
- ZenHubを使い始めた方
- スクラム開発について概要レベルの知識をお持ちの方
以前私が書いた ZenHubで始めるスクラム開発 を読んで概要を理解していれば問題ないかと思います。
ストーリーポイントとは
こちらの記事 でも書きましたが、ストーリーポイントとは課題の大きさを表す数値です。
ZenHubでは「Estimate」という名前で定義されています。
利用出来る数値は 1, 2, 3, 5, 8, 13, 21, 40 になります。
これらは時間を表している訳ではなく、単純に課題の大きさを表している数値です。
時間見積もりではない理由
先程も書いた通り、ZenHubのインターフェースは時間ではなくストーリーポイントで見積もる前提で作られています。
課題見積もりの際に単位として時間を利用すると何が問題かを解説します。
時間見積もりは人によって大きな差が出てしまう
例えばこんな課題があったと仮定します。
## Doneの定義（完了要件）
- Googleアカウントを利用して登録・ログインが可能になっている事
## 利用技術
- Ruby on Rails
ある開発者Aさんがこの機能は8時間で出来ると見積もったとします。
AさんはRubyやRuby on Railsでの開発経験も豊富で、さらにGoogleアカウントを利用したログイン機能（俗に言うソーシャルログイン）を行った経験があります。
同じチームにBさんという技術者がいます。
BさんはPHPでの開発経験はありますが、Rubyは今回が初です。当然Ruby on Railsも触った事がありません。
担当がBさんとなったとして、Bさんはこの「Googleアカウントでログインする機能」を8時間で作れるでしょうか？
Aさんは開発経験も豊富なのでおそらくこの8時間という見積もりはそれなりに正しいのでしょう。
しかしその正しさが有効なのはAさんが自分で見積もった課題を自分自身で行った場合のみです。
AさんとBさんの例は極端な例かもしれません。
しかし同じRubyエンジニアでも、「Rubyが出来る」、「Railsが出来る」等と一括りにする事は不可能です。
そもそも「出来る」の定義は人によって異なります。
ここまで極端ではないにせよ、時間見積もりは人によって大きなバラツキが出てきます。
これが時間見積もりを使わない1つ目の理由です。
時間見積もりは属人化を作る原因となる
最初の例で分かった方も多いと思いますが、時間見積もりを正確な物にする為には、以下の条件のどれかを満たす必要があります。
- 必ず見積もった本人がその課題を担当する
- チーム全員のスキルレベルが限りなく近い状態のチームを作る
2 はまず不可能だと言って良いでしょう。
エンジニアのレベルは個人個人でバラツキがあるのが当然で、同一程度のスキルのメンバーだけで構成するチームを長期間維持するのは現実的に不可能です。
しかし 1 の方法を取ると、基本的に見積もった人がその課題の担当者に固定されてしまうので、課題の属人化を招きます。
これが2つ目の理由です。
そもそも正確な時間見積もりは不可能である
全く同じ技術を使ってシステム要件も全く同じ。
このような状況を何度か繰り返せば正確な時間見積もりが出来るかもしれません。
しかし、現実的にそんな事はあり得ないと言えるでしょう。
同じRailsでもバージョンによって微妙に使い方は異なります、例え上級者であったとしても「学習コストが0」のプロジェクトは存在しないと思いますし、システムの要件は作るサービスによって大きく変わってきます。
「正確な時間見積もりが出来る」という考えは現実的ではありません。
これが3つ目の理由です。
ストーリーポイントによる相対見積もりを使う理由
先程の例に出した時間見積もりは「絶対見積もり」と呼ばれる手法です。
対してストーリーポイントを使った見積もりは「相対見積もり」と呼ばれます。
これはある基準となる課題にポイントを付けて、その課題と比較して、今の課題が何ポイントか？を導き出す方法です。
以下の例で説明しましょう。
現在地は東京駅です。
ここから池袋駅まで移動します。距離は約10kmです。
ここにかかる工数を時間で見積もって下さい。
※ 参考資料として山手線の路線図を見せる。
※ ググればすぐ分かるとかいうツッコミはなしでお願いします
時間を使った「絶対見積もり」では以下のような結果となりました。
Aさんは25分と見積もったBさん16分は見積もった
結構なズレが出ています。
原因はAさんは山手線を利用する事を想定していましたがBさんは丸の内線を使う事を想定していた為です。
さらに言うと、AさんとBさん以外に、もっと大勢の開発者がいたりすると、そもそも電車ではなくタクシーやバスを使うと言う人も現れるかもしれません。
そうすると、各人の見積もりはさらにバラバラになる事が予想されます。
このように時間見積もりは、持っている知識（この場合は東京の交通事情）やどのような技術を用いるか（この場合は交通手段）によって大きくバラツキが出ます。
ではストーリーポイントを使った「相対見積もり」で先程の東京駅から池袋駅までの工数を見積もってみましょう。
説明文は下記になります。
現在地は東京駅です。
ここから池袋駅まで移動します。ここにかかる工数をストーリーポイントで見積もって下さい。
参考までに東京駅から品川駅までの距離をストーリーポイント 2 と考えます。
※ 参考資料として山手線の路線図を見せる。
利用出来る数値はZenHubで使える 1, 2, 3, 5, 8, 13, 21, 40 とします。
この場合、多くの人が東京 → 品川間の距離が 2 とするなら、その2倍程度離れている、東京 → 池袋間の距離は 5 と見積もる事が出来るでしょう。
しかも、「どのような交通手段を使うか」や「東京にどのような路線が走っているか」の知識に依存しないで見積もりを行う事が出来ます。
このようにストーリーポイントを使った「相対見積もり」では人の知識や能力に依存しないで見積もりを出す事が可能になります。
ストーリーポイントを使った「相対見積もり」の具体的な方法
ここからは具体的な方法について説明します。
基準となる課題とストーリーポイントを決めておく
よくある例だと基準となる課題を1つ決めて、それを基準値に考えていますが、基準となる例は複数出しておいても良いと思います。
例えば下記のような形です。
ユーザーの名前を取得する機能。
# Doneの定義
- ユーザーIDから名前を取得して、画面に表示させる。
# 補足
- DBのテーブル構造は確定している
- ユーザーIDはCookieから取得可能
- 対象のユーザーの名前が登録されていない場合等の例外パターンに関してはここでは考慮しなくて良い
- 画面のデザインに関してはここでは考慮しなくて良い、どんな画面での良いのでとにかくユーザーの名前が表示されていれば良い
ユーザーのパスワードをリセットして新しいパスワードに変更する機能
# Doneの定義
- ユーザーのパスワードが変更されている事
- 新しいパスワード設定時にメールによる認証が行われている事
- パスワードは8文字以上、20文字以下で大文字小文字のアルファベットと1から9の数値を許可する事
# 補足
- DBのテーブル構造は確定している
- メール送信用の関数は既に存在してテストも十分に行われている
- メールアドレスにメールが送れなかった場合等の例外パターンは考慮しなくて良い
- 画面のデザインに関してはここでは考慮しなくて良い
ユーザーがクレジットカードで商品を購入する機能
# Doneの定義
- 任意の商品をクレジットカードで購入出来る事
- 購入した商品の情報はMyページから閲覧出来るようになっている事
- 管理サイト側でもユーザーが購入した商品を閲覧出来るようになっている事
# 補足
- Myページやクレジットカードの登録機能は既に存在している
- 「ユーザーが購入した商品」を表すDBテーブルは存在しないので設計を行う必要がある
- 管理サイトには「ユーザー情報を閲覧する機能」が存在しないのでここで作成する必要がある
- クレジットカードが不正だった場合等のエラーパターンは考慮しなくて良い
このように複数の例があると見積もりを行う際に迷いが少なくなります。
中にはチームの誰もがやった事がない未知の技術を調査する必要があるタスクも存在します。
このような手法を スパイク（技術的検証） と言いますが、このような課題は見積もりが非常に困難です。
その場合は以下のような手法を取ると良いでしょう。
-
方法1
チームのベロシティ（1スプリントあたりの生産量）から算出する- チームのベロシティ平均が
100と仮定する - チームの人数が5人と仮定する
- 2週間のスプリントでスパイクにはスプリントの半分を費やすと仮定
-
100の半分は50でこれを開発者の人数で割ると10になる 利用出来るポイントで一番近いのは8なので8を採用する
- チームのベロシティ平均が
-
方法2 決め打ちでポイントを定義する
- 未知の技術を使った課題は一律
13にする等
- 未知の技術を使った課題は一律
（参考）ストーリーポイントに関する15個のよくある質問と答え
プランニングポーカー
ポイントで見積もる際に利用される手法です。
詳しくは こちらの記事 等をご覧頂ければと思いますが、ざっくり言うと、全員が一箇所に集まって、ポイントが書かれたカードを持ち一斉に出し合う手法です。
ポイントが大きくズレた場合は一番大きな数値を出した人と一番小さな数値を出した人の意見をそれぞれ聞いて、全員で認識を合わせた後に再度見積もりを行います。
課題1つにはあまり時間をかけるべきではありません。
リモートワークのメンバーがいる場合は下記のようにブラウザでプランニングポーカーが出来るツールがあるので、それを利用すると良いでしょう。
ちなみに私は普段リモートワークですが、スクラムのMTGがある日だけは現場に出向いています。（2020年4月以降リモートワークが広がった関係で今は全てリモートでやっています）
このあたりはチームにあった方法を取ってもらえれば良いと思います。
最近ZenHubにプランニングポーカーの機能が実装されました。
非同期でプランニングポーカーを利用出来るので非常に使い勝手が良く、こちらを利用しています。
Doneの定義を明確にしておく
これはかなり重要です。
プランニングポーカーをやっていても見積もりがズレる事はありますが、その原因はDoneの定義が曖昧な為起こります。
どのような条件を満たしたらその課題が完了になるか？をしっかりと明記しておきましょう。
全ての課題が満たすべき条件として「普遍的なDoneの定義」を定義しておく事をオススメします。
例えば以下のような形です↓
- テストコードが書かれていてテストをパスしている事
- 2名以上のレビュアーに承認をもらっている事
原則としてDoneの定義を満たしていれば、それ以上の事はやる必要はありません。
例えば課題をやっている最中に他の改善点を見つけたとしても、それは別の課題として提起して、そこではやらないようにする事が重要です。
そうしないと人によって、見積もりと作業量のバランスが異なってしまうので、この点は徹底する事をオススメします。
（参考）Doneの定義のサンプル
注意点
ストーリーポイントの見積もりを採用する際の注意点です。
開発者もそうですが、マネージャークラスもこの点を理解しておく必要があります。
ストーリーポイントを過信しない
この記事 でも紹介したように「Velocity tracking」や「Release report」を使えば、ある程度リリース予測日を立てる事は可能です。
しかしだからと言って、「この日に必ずリリースしなければいけない」と思うのは誤りです。
ストーリーポイントは時間の見積もりよりも、人によってズレにくいというだけで、正確な数値ではありません。
それに課題は開発期間中どんどん増えていく傾向にあるので、「Release report」の数値は状況に応じて変わってきます。
また「Velocity tracking」に関しても、開発者が病欠や退職等で変化する可能性があります。
あくまでも参考情報の1つとして捉えましょう。
システム開発において「正確な見積もり」を行うという事はそもそも無理だと私は思います。
このあたりを理解していない管理者がスクラムチームを支配しているとスクラムが崩壊する可能性が一気に大きくなります。
（参考）【スクラム入門】認定スクラムマスターの俺が正しいスクラムの理論をまとめる
ベロシティをチームの評価に利用する
ベロシティが上がってくる事は一般的には良い事ですが、これを元に厳密な評価を下す事は辞めましょう。
ベロシティが低下すると「怠けている」等と叱責するのは論外です。
チームの心理的安全を阻害するので絶対に辞めましょう。
ベロシティを上げる方法は簡単で開発者が結託して、毎スプリント毎に少しずつ多めに見積もるようにすれば良いのです。
しかしそんな事を開発者がやりだしたら「ストーリーポイント」に対する信憑性は一気になくなってしまいます。
そうなっては本末転倒です。
おわり
以上がストーリーポイントを用いた見積もり方法になります。
この考え方はZenHubに依存した考え方ではないので別のツールでも応用出来ると思います。
最後まで読んで頂きありがとうございました。