この記事はWHITEPLUS Advent Calendar 2021の24日目の記事です。
はじめに
こんにちは、株式会社ホワイトプラスのエンジニアの山内です。
私が所属しているチームではスクラムという開発手法を運用しています。
この記事ではスクラムの「見積もり」を行う上では切っても切り離せない「SP:ストーリーポイント」についてご紹介したいと思います
背景
今年の半ばから、ありがたいことにチーム内でスクラムマスターという役割を担当することになりました。
これまでは開発メンバーとしてある意味受動的に参加していたスクラムイベントでしたが、 スクラムマスターとして自身がイベントの準備やファシリテートを行っていく中で理解しているつもりだった「SP」が正しく理解できていないことに気が付きました。
そのため「見積もり」に関わる方にSPについて知ってもらう機会になればと思い自身が学んだことの備忘録を記事にさせていただきました。
見積もり
SPについて考える前に「見積もり」が抱えている問題について知っておく必要があります。
見積もりと言えば一般的には「必要な人数と作業時間」の算出を指します。
PJ全体の開発に掛かる時間が300時間と仮定すると
・チームメンバーが6人の場合 => 1人あたりの作業時間が50時間
・1人が1日のうち開発に割ける時間が5時間の場合 => 10日間
・バッファを1日とるとおよそ11日で開発が完了することが予測出来ます。
ただ、書籍「人月の神話」で語られる通り時間と人数をそのまま変換することは現実的ではありません。
例えば、作業を均等に分散させることを優先してしまうと1人で作業をする方が効率が良い場面ではデメリットになってしまいます。
そしてそういったケースはプログラムを書く上では往々にして発生します。
また時間と人数の変換はメンバー全員が同じスキル・作業効率を有している前提で成り立つ話です。 実際はメンバーによって業務知識にバラつきがありますし、得意としている技術領域も違います。
故に作業内容が同じでもメンバー間で完了までに掛かる時間に差が生まれてしまいます。
さらに客観的にも見積もりには誤差が起きやすいことが証明されています。
以下が見積もりの不確実性を客観的に示した「不確実性コーン」と呼ばれる図です(知った口で説明していますが自分も最近知りました)
↓こちらの記事から引用
企画時の見積もりには上下で最大4倍の振れが発生する可能性があることを示しています。 これは企画段階で見積もった11日が実際には3日間〜1ヶ月に変化する可能性があることになります。 開発プロセスが進み開発内容が具体化していくにつれて上下の振れが収束していきます。
以上から見積もりを正確に出すことが困難であることが分かります。
このままでは「正確な見積もりは難しいんだ!」とただ嘆いているだけの記事になってしまうので
次に↑で挙げた属人化や振れ幅を抑えるためのSPについてご紹介します。
SPとは
「ストーリーポイント」と呼ばれ相対見積もりの作業量を示す指標になります。
前述した例では時間と人数で見積もっていましたが、
私達のチームでは純粋な作業量(SP)で相対見積もりを行います。
「開発Aの作業量が 1 だから、もう少し作業が増える開発Bの作業量は 2 だよね」
これが相対見積もりです。
「そんなアバウトな測定で良いの?」「不確実性増してない?」と心配されそうですが以下のような3つのメリットにがあります。
- 時間・人ではなく作業量にフォーカスすることで属人的な見積もりの差を無くすことが出来る
- 見積もりはチーム全員で行うため、1人で見積もりを実施するよりも全員の認識が揃えられた状態で見積もることが出来る
- 相対的な見積もりのため、従来に比べて素早く見積もることが出来る(素早く変化に対応できるアジャイル開発と相性が良い)
また見積もったSPを1スプリント(1週間)でどれだけ消化できたかを確認することで
前回は1週間で30SP消化できた => 120SPのPJは4週間で完了できそう!
↑のように実績から時間に変換することができます。
つまり
1人で0から工数を算出するより、チーム全員の実績ベースで工数を算出するほうが属人化も振れ幅も抑えられてスピードも上げることが出来る
というのがSPを採用している理由になります。
具体的な見積もり方法
私たちのチームではプランニングポーカーと呼ばれる方法で見積もりを実施しています。
1 2 3 5 8 13 21...これらのフィボナッチ数をSPと見立てメンバー全員で各タスクごとに数字を割りあてていきます。
メンバー間でSPに差異が生じたら、そのSPを選んだ理由を発表してもらいSPが揃うまで全員で議論をしていきます。
例)
Aさん「フォームに生年月日を追加する開発を見積もります、せーのっ」
Aさん「1」
Bさん「1」
Cさん「2」
Dさん「3」
Aさん「チーム内でSPが分かれたので意見を聞いていきます」
Bさん「1を選んだ理由は既存の仕組みを流用することが出来るのでうんぬんかんぬん。。。」
普段からこのような流れでSPを決めています。
またチーム内では見積もり時の指針として各SP毎の基準を定めています、興味がある方は読んでみてください。
まとめ
今回ご紹介したSPの見積もりは変化が早くスピード感を重視する開発手法に非常にマッチしていることが分かりました。
またベロシティ(スプリント毎に消化できたSP)が安定しているほど見積もりの精度が高いと判断できるため、 スクラムマスターとして不安定なときは改善を行いベロシティを安定させることに努めていきたいと思います。
最後まで読んでいただきありがとうございました、こちらの記事が何かの参考になれば幸いです。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています!
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。
どんな会社か気になった方はオウンドメディア「ホワプラSTYLE」をぜひご覧ください。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください。