スクラム開発のストーリーポイントを時間見積りにしない理由

本稿はJCB Advent Calendar 2023の12月11日の記事です。

JCBデジタルソリューション開発部 DXテックG JCB Linkチームの岩本です。
本日はスクラム開発におけるSP(ストーリーポイント)の見積りについて解説します。
まずはSPについての知識のおさらいです。

スクラム開発の見積りにはSPを用いる

ご存知の方も多いと思いますがおさらいです。
SPには下記の特徴があります。

  • 基準となるプロダクトのSPを定め「相対評価」で見積る
  • Sprintごとの消化SPが予測できる(理想ベロシティ)
  • バックログ全体のSP÷理想ベロシティ=開発完了時期 の予測ができる

「相対評価」でのSP見積り方法

もう少し知識のおさらいにお付き合いください!
前述の通りスクラム開発では基準となるプロダクトのSPを定め「相対評価」で見積ります。
スクラム開発未経験の方のために、SPの見積り方法をわかりやすく折り紙で例えてみます。

基準が折り紙の鶴SP”5”であれば、紙飛行機は構造も簡単で、折る数も少ないのでSP”3”というように難易度や複雑性から相対評価をします。
実際の見積りの際にはDevチームがプランニングポーカーという手法を用いて決定します。(やり方はまた次回にでも!)

SP見積りで陥りやすい「時間見積化」

SPで見積りをするにあたり、下記のようなパターンに陥ることが多くあります。
例えば、前Sprintにおいて開発したあるプロダクトの見積りが8SP。開発実績が16時間かかったとします。
すると1SPあたり2時間と計算できるのですが…
この方法で見積りをしてしまうと、スクラム開発やSP見積りのメリットを阻害する原因になりかねません。

なぜ時間見積りにしないのか

さて、いよいよ本題「スクラム開発のストーリーポイントを時間見積りにしない理由」です!

Devチームの成長が観測できない!

スクラム開発では1Sprintで消化できるSPをベロシティと呼び、チームの状況を把握するためのバロメーターにもなります。
ベロシティが上昇している場合、Devチームの開発量増加、カイゼン効果によるチーム成長などを読み取ることができます。
またベロシティが下降している場合、Devチームが開発に集中できない、見積りを適切にできていないなど、課題が潜んでいる可能性を読み取ることができます。
一方、もしSPを時間換算した場合…
Sprint稼働が120時間、1SP2時間計算のチームはどれだけSprintをこなしてもベロシティは60のままとなってしまいます。
つまりSPを時間見積りした場合、ベロシティは稼働時間に比例するのみとなり、チームの状況を把握できなくなります。
成長・カイゼンを続けてくれるDevチームのため、そして課題の早期発見のためにも適切にベロシティを出したいところです!

見積りはズレが生じるもの…ならば開発時間を確保する!

どんなに一生懸命見積りをしても実績はズレが発生することは多いですよね…
時間見積りの場合にはタスクレベルでの時間算出をする必要があり時間を要しましたが、相対評価では簡易的に見積りが可能になります。
時間をかけてもズレが発生してしまうのであれば、Devチームにはとにかく開発作業に集中してもらいどんどんプロダクトを生み出してもらおう!
という思想がスクラム開発にはあります。

時間見積りは属人化の原因になりかねない!

スクラムのDevメンバには幅広くスキルを会得し、スキルの横断化が求められます。
そのためには経験のないタスクにも積極的に挑戦していく必要があります。
一方でSPを時間見積りしている場合、Devメンバは見積もった時間以上の工数を要してしまいそうな初挑戦タスクには着手しづらくなってしまいます。
それにより高スキルが求められるタスクは属人化してしまい、チーム内の知見の偏りや開発者としての成長阻害の原因となってしまいます。
見積り時点では相対評価を行い、積極的に難易度の高いタスクに挑戦する、そしてそれを助け・賞賛し合えるチームが卓越したチームに到達できます。

おまけ : さらに早く・簡易に見積りをする改善案

とはいえ、スクラム開発に従事していると基準SPとの相対評価が難しい場面に遭遇することは多々あります。
例えば画面系プロダクトで基準SPを作った場合、DB系プロダクトの相対評価は基準との関連をイメージすることが困難であるといったことが挙げられます。
私が過去に参画したスクラムチームではカイゼン活動を通してその解決法を編み出していたので紹介します。

1. 基準となるプロダクトのSPを決めます。
2. バッチ系、API系、DB系と複数分野のプロダクトを1つずつ選びます。(簡単なものがおすすめ)
3. 1の基準SPを元に、2で選んだ各分野のSPを見積り、分野ごとの基準SPとします。(ここで事前準備完了!)
4. 見積り対象のプロダクトに当てはまる技術分野の基準SPを元にして相対評価の見積りをする。

といったものです。
見積りをさらに簡単に、かつ基準SPとの相対評価のブレを少なくしようというカイゼン案でした。
皆さんのチームでもぜひカイゼン活動を利用して、チームに合った手法を確立しましょう!

終わりに

スクラム開発での見積り方法。そしてなぜ時間見積りをしないのかについてご紹介しました。
スクラムチームの成長・カイゼンや、これからスクラムを始めようという方々の参考になれば幸いです。

最後になりますが、JCBでは我々と一緒に働きたいという人材を募集しています。 詳しい募集要項等については採用ページをご覧下さい。


本文および図表中では、「™」、「®」を明記しておりません。 Google Cloud, GCPならびにすべてのGoogleの商標およびロゴはGoogle LLCの商標または登録商標です。 記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。

©JCB Co., Ltd. 20︎21