見出し画像
Photo by hiharasns0608

私たちがスクラムにおける見積もりをやめた理由と見積もりの現在地

イチロウ株式会社

はじめに

イチロウ株式会社でエンジニアリングマネージャーを担当している nkns です。
情報発信やっていくゾ！ということで初回はスクラムにおける「見積もり」というテーマで記事をしたためました。
＊本記事での「見積もり」とは、「作業量の見積もり（サイズ）」を指します）。
私自身、エンジニアリングマネージャーやスクラムマスターとして様々なチームに関わってきた中で、たくさんの見積もりを取り巻く問題や議論に参加し、うまくいったこともあれば、そうはいかなかったこともあります。そのような経験から、「スクラムにおける見積もり」というテーマで1度、2024年現在時点での考えをまとめたくなりました。
ご一読いただければ幸いです。

見積もりのアンチパターン

書籍で触れられている、あるいは組織内で発生する見積もりのアンチパターンとはどのようなものでしょうか。ざっくりと列挙すると・・・

  • 見積もりがいつの間にかコミットメント（リリースの約束）になる

  • 「作業量」に対しての見積もりが「自分が実装したら」という「時間」の見積もりになる（相対的見積もりと絶対的見積もりの話）

  • ベロシティ（実際に消化できた作業量）が経営指標として使われる

  • どれだけスプリントを重ねたとしても見積もりとベロシティが合ってこない

  • そもそも見積もりに時間がかかりすぎる

  • （心理的に不安だから）（見積もりがコミットメントになっているので）バッファを込めた見積もりになる→さらに見積もりとベロシティの乖離が酷くなる

ほんの一例ではありますが、私の経験を列挙しました。
特に経験上多かったと感じるのは、「作業量」ではなく「時間」の見積もりになることや見積もりがいつの間にかコミットメントになることだったと記憶しています。

＊スクラムでは絶対的な見積もりではなく、相対的な見積もりが推奨されています。
ここで見積もりの精度についても触れておきたいと思います。『エッセンシャル スクラム』『アジャイル見積りと計画づくり』といった書籍では「必要以上に精度を追い求めてはならない」と語られています。以下の図は書籍に載っているものになります。

どれだけ見積もりを精緻に行ったとしても、100％にはならないのでほどよいところで止めるのが吉であることがわかります。

見積もりから発生した組織的問題

イチロウでは1年ほど前まで見積もりを行っていました。当時を知るエンジニアの方の話をまとめると、

  1. スクラムを始めようとなった際に見積もりも同時に採用した

  2. 最初は見積もりのポイントが安定しないことが続いたがやがて安定した

  3. 安定がずっと続くわけではなく、扱う開発の粒度によってポイントのバラツキが大きくなり、ベロシティが不安定になる時期があった

  4. バラツキを抑えるために1ptの定義に変更を加えた（このときは1ptの作業量を減らした）

  5. 1ptの作業量を減らしたので全体のベロシティが下がった

  6. ベロシティが下がったことについて指摘が入った

  7. （見積もりどうしよう・・・のフェーズへ）

となります。1ptの作業量が大きすぎる場合、見積もりのサイズをコンパクトにするという手段は良さそうです。問題はスクラムを実践している関係者全員に見積もりの考え方が浸透していないことにあると感じました。さらに指摘が入る1つの布石として、ベロシティの消化ptについて「今Sprintは◯◯pt消化できました！」とアピールしていたことも、周囲の関心がベロシティに向きやすかったかもと当人は振り返っていました。
ちょうど、この時期に私が入社したこともあり、見積もりはなくても良いと組織内で結論付け、イチロウにおけるスクラムから見積もりが消えたのでした。

スクラムにおける見積もりの歴史的経緯について

そもそも、「スクラム」やその中の「見積もり」とはどのような歴史を歩んできたのでしょうか。すべてを網羅できているかは怪しい点もありますが、時系列順でまとめたものが以下となります。（スクラムガイドは2009年以前も公開されていたと思われますが、Webで閲覧できるものは2009年が最新でした。ご了承ください。）

特に大きな転換となったのが、
2019年：XP（エクストリームプログラミング）の創始者の1人によって「Story Points Revisited（ストーリーポイントの再考）」という記事が投稿される
2020年：スクラムガイド更新（「見積もり」という文言が消える）
の出来事であり、「見積もり」というテーマに照らし合わせると、2020年のスクラムガイド更新が該当します。2017年版のスクラムガイドでは英語版で「estimate」という単語は9箇所ありましたが、2020年版では0となっています。これは日本語版においても同様で、2020年版のスクラムガイドでは「見積もり」という単語は0となっています。
少し時を戻して、2019年。XP（エクストリームプログラミング）の創始者の1人、Ronald E Jeffries によって「Story Points Revisited（ストーリーポイントの再考）」という記事が投稿されます。詳しくは、リンク先の記事に譲りますが、

  • ストーリーポイントという考え方はちょっと後悔している（一方で、それほど後悔しているわけでもないともあります）

  • いつ完了するかを予測するのは弱いアイデアである

  • 実際と見積もりの比較を追うのは無駄だと思う

  • ストーリーポイントがもしチームに多くの価値をもたらさないのであれば、やめるべきだ

という主旨のことが述べられています。
この記事とスクラムガイドの更新がどのように結びついているのかは定かではありませんが、時系列で見ると記事を受けての更新とも受け取れます。
このような流れで、2020年のスクラムガイドからは「見積もり」という言葉が削除されました（と私は推測しています）。

参考資料：https://scrumguide-ja.kdmsnr.com/

見積もりは正しい？それとも間違っている？

では、「見積もり」その手段としての「ストーリーポイント」は正しいのか、間違っているのかはどのように判断するべきなのでしょうか。
完全に私個人の意見となりますが、以下のように考えています。

  • 見積もりが有効なシーンはたしかに存在する

    • チームビルディングとしてのプランニングポーカー

    • 作業量に対するおおよその認識をチームで統一する必要がある

    • などなど…

  • 一方で、厳密に見積もりを行おうとすると弊害のほうが大きくなってくる

    • 冒頭のアンチパターンに記載したような現象の発生が該当

一切の見積もりを行わない反対の状況も考えてみたいと思います。そのときに発生しそうな問題として、

  • 機能がいつリリースされるのかが職種感で共有されない（エンジニアだけが感覚を持っている状態）

    • （連鎖して）、中長期のプロダクトロードマップが立てられない

  • エンジニア間であっても、誰がいつタスクを完了状態にできるのか不透明

などでしょうか。そのほかにも色々とありそうです。
ふんわりとした解釈でたいへん恐縮ですが、私としては「どちらも正しい。ただし、状況による」というのが結論になります。

イチロウではどのように考えているのか

厳密な見積もりを運用するには投下するコストも大きく、そのリターンが十分かというとそうでもないと結論づけ、「ざっくり見積もり」に着地しております。
ざっくり見積もりとは・・・

  • おおよその完了・リリース時期を期間で表明する

という方法になります。とある機能開発を行いたいとなった場合、PO / PdM はエンジニア（開発チーム）へ「だいたいどれくらいですかね？」「松竹梅だとどうなりますかね？」とコミュニケーションを行います。それに対して開発チームは「1スプリントあれば」「2~3スプリントくらいになるかもしれない」と回答します。もちろん、これはコミットメントではなく、プロダクトバックログの優先順位付けを行うためのものです。
コミットメントについてはスプリントゴールが該当し、スプリントプランニングの中で決めるようにしています。弊社では、開発チームとPdMが議論を重ね、次のスプリントゴールを決定するというプロセスで行っております（スプリントゴールはどのように運用されるべきなのかについても現在思案しているところでして、またの機会に譲りたいと思います）。
弊社代表である水野もこの運用方法について同意しており、スクラムを全社的に運営している状態を担保するに至りました。1年ほど前からゆるやかに変更を重ね、ここまで来ましたが現状大きな問題はなく、スプリント毎にプロダクトが前進している状況は作れているのかなと感じております。

正解かはわからない、しかし決断は必要

ここまで、「見積もり」というテーマで書き進めてきましたが、正直なところ私自身、日々模索・試行錯誤を繰り返しています。これまで合計で15~20ほどのスクラムチームで仕事をしてきましたが、1番大切だと思うことは「スクラムとはあくまで1つのフレームワークであり、スクラムガイドや書籍のとおりに習うだけでなく、チームとのフィット感を見るべきである」という考え方です。
私たちのスクラムチームに課題がないわけではありません。エッセンシャルスクラムに書かれているアンチパターンには、「プロダクトオーナーとスクラムマスターは避けるべき兼業である」という話が紹介されていますが、現在、イチロウではプロダクトオーナーとスクラムマスターは私が兼業していますし（なんなら、エンジニアリングマネージャーも！）、レトロスペクティブでは必ずチームから何かしらの問題提起があります。決して完璧ではないのが実情です（POとSMの兼業については特に？さすがに？問題だと思っているのでPOの採用頑張っています・・・！）。
私がスクラムマスターとして意識していることは「守破離」の考え方です。型を守るフェーズである守があり、ときには守を破り、破へと向かう。ときに離れることもあるかもしれません。教科書どおりであることはチームのフェーズによっては大事だと思います。一方で、教科書どおりによって発生する問題があるのだとしたら、教科書は破られて然るべきだと考えます（破り方は要注意）。あくまでチームに起こっている問題に目を向け続けることを意識しています。

さいごに

ここまで長文を読んでいただきありがとうございます。
どちらも正しく、あるいはどちらも間違っているような書きっぷりとなりましたことをお許しください。私なりにスクラムとかれこれ7~8年ほど向き合ってきた一旦の結論と受け取っていただけると嬉しく思います。
見積もりやストーリーポイントという考え方はウォータフォール開発、人月の神話などが通説だとされていた当時からするときっととてつもなく画期的なものだったのだと思います。先人たちの知恵の結晶の上に今の私たちの開発があるのだと思います。
Let's Scrum!!!
ありがとうございました。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

イチロウでは、新しい仲間を積極採用中です！

イチロウは今後の組織拡大を見据え、積極的にメンバーを募集しています。業務内容から会社のカルチャーまで、カジュアル面談でお話してみませんか？
▷求人票：https://herp.careers/v1/link
▷企業PR動画(1min)：https://x.gd/7zw6d