XP創始者、Ron Jeffries氏による「ストーリーポイントの再考」
株式会社インテグリティス代表の木村です。（Twitterではけいと呼ばれています。）
最近は受託開発の他、クライアント企業様への内製エンジニアリングチームの立ち上げとコーチングを事業として取り組み始めました。
アジャイル開発における「ストーリーポイントとベロシティ」について考える機会があったので、色々調べてみました。
スクラムの文脈で見積もりの単位としてよく使われる「ストーリーポイント」ですが、元々はXPが起源でした。
XPの創始者の一人であるRon Jeffries氏は2019年5月23日、自身のサイトにて「Story Points Revisited（ストーリーポイントの再考）」と題し、ストーリーポイントに対する考えを述べています。
なにかと誤解があったり、スクラム開発の現場で疑問が生まれることも多い「ストーリーポイント」や「ベロシティ」という概念ですが、Ron Jeffries氏の記事を要約しながら整理をしていきたいと思います。
Ron Jeffries氏の主張
結論から言うと、Ron Jeffries氏は以下のように述べています。
ストーリーポイントは、XPのアイディアであり、スクラムのアイディアではない
もし自分がストーリーポイントを発明したのだとすれば、今になって少し後悔している。
ストーリーポイントは頻繁に誤用されている
ストーリーポイントによる見積もりを全く使わないことで多くの"落とし穴"を避けることができる。もしチーム・会社に多くの価値をもたらさないのであれば、無駄なのでやめるべきだ
一方で、ストーリーポイントでの見積もりが好きだという人は、ぜひ続けてください
ストーリーポイントの発祥
XPにおいて、「ストーリー」は元々時間で見積もられており、それは「Ideal Days（理想的な日数 / 理想時間）」と名付けられました。
「アジャイルな見積もりと計画づくり」にも紹介されていますが、「Ideal Days」とは、「なにかをするための時間のうち、周辺的な作業の時間を差し引いたもの」のことです。あるストーリーのピュアな実装の時間が１日として、実際にはデリバリーまでの周辺作業やコミュニケーションなどを含めると、おおよそ３日を費やします。この例での１日の方を「Ideal Days（理想日数）」と呼びました。
それは結果として、「１"Days"の仕事なのに３日もかかるのか」「３週間で５０"Days"の仕事ができないのか」、というように、しばしばステークホルダーの困惑を招きました。
そこで、Jeffries氏らは「Ideal Days」のことを、「ポイント」と呼び替えるようになったのです。
ポイントは「イテレーションでどれだけの作業を行うか」を決めるために使うだけなので、そのことについて誰も反対することはありませんでした。
ストーリーポイントの誤用について
「嘆かわしいのは、相対サイズによる見積もりが理解されずに誤用されることですか？」
この質問にJeffries氏は以下のように答えています。
確かに誤用は嘆かわしい
「いつ終わるか」を予測するために使うには弱い考えだと思う
見積もりと実績の比較をすることはせいぜい無駄でしかないと思う
見積もりの精度やベロシティでチームを比較するのは有害だと思う
Jeffries氏はいくつかのトピックに分けて、ストーリーポイントに関する意見を述べました。
Comparing - 比較 -
一見比較可能に見えても、それぞれのチームにはそれぞれのスキルがあり、それぞれの環境で仕事をしている。あるストーリーに関して一方のチームが「２点」だと言い、もう一方のチームが「６点」だと言っても、チームを比較するのに有効でないことは確かである
「遅い」チームが劣っている / 何か失敗していると結論づけるのは非常にまずいことであるが、残念ながらよくあることである
２つのチームがものを作るとなると、多くのマネージャーにとって、両者を比較したいという誘惑に駆られる。そうなってしまうくらいなら、ストーリーポイントという概念もストーリーを見積もるという概念も、可能な限り捨てた方がよいと思う
Tracking - トラッキング -
多くのマネージャーにとって、見積りの存在は「実績」の存在を意味し、見積りと実績に乖離がある場合はもっと上手に見積りをするべきだと考えるものである
「リアルな」アジャイルで重要なことは、最も価値のあることを見つけ、それを迅速に実行することである。早くやるということは、価値の高いものを小さく切って素早く反復することに帰結し、そこにはストーリーのコストの見積りはあまり役に立たない
見積りに焦点があたってしまうことで、「真の価値を迅速に提供する」という中心的な目的から逸れてしまう。よって、点数であれ時間であれ、見積りそのものを避けるべきである
Pressure - プレッシャー -
「見積りと実績の関係」に関連して、経営陣から「もっと」という自然なプレッシャーがかかることがあるが、価値を提供する最善の方法は、「もっと」ではなく、「小さな価値あることを頻繁に行うこと」である
ストーリーを見積もるのではなく、「十分に小さいこと」にスライスすれば、常に価値を提供する、スムーズな流れになる
「より多く」にこだわると、価値の増大の邪魔になり、「より多くのことをしなければならない」というプレッシャーが高まると、必ずと言っていいほど悪い結果になる。（コード品質やテストの手抜き、欠落の出荷、修正と手直し、プレッシャーの負のループ・・・）
見積りは不当なプレッシャーの適用に関与しているので避けたい
さらに言えば、イテレーションやスプリントプランニングを完全に避けたいとも思う。我々は数週間の予算を埋めるために仕事をするのではなく、次にすべきいくつかの最も重要な事柄のリストを持つために仕事をするのである
Predicting Done - 完了予測 -
「いつ完成するのか」という問いの答えは、「誰にもわからない」である
この「わからない」状態の改善のために我々は多くの作業を行うことできる。そして、ある分野やある時期において（入札を待つ大きな契約がある場合など）は、それを行う（予測をする）価値がある場合もある
しかし、社内外の顧客のためにソリューションを開発するようなビジネスを行っている場合、我々は頻繁に少量の価値を提供することがベストであり、「ビッグバン」のようなリリースを待つべきではない
顧客に提供する次のリリースの期日を間近に設定し、そのリリースにできるだけ多くの良いものを詰め込む方がはるかに良く、ストーリーポイントやグミ・ベア、あるいは時間などの見積もりは、その妨げになる
Slicing - スライシング -
ストーリーポイントでの見積りが嫌いなら、何が好きなのかという質問が来る。私は、ストーリーのスライシングが好きだ。これは、大きなストーリーを小さなストーリーにスライスすることで、それぞれができるだけ高い価値を持ちながら、ごく短い時間、理想的には1日以内、あるいは2時間程度で終わらせるプラクティスである
スライスする際に何らかの見積もりをしなければならないかどうかについて議論する気はない。単に頭の中で見積もり、誰にも言わないのであれば、それがストーリーポイントであれ時間であれ、今言っているような見積もりの問題は生じないだろう。しかし、「３日」なのか「１日」なのかを知ることよりも、「十分に小さくスライスされているかどうか」を知ることの方がシンプルで価値があるはずだ
コツとしては、「ストーリーを、受け入れテストが1回で済むまでスライスする」ことだ。少し練習すればちょうどいいサイズになる
Predicting the future - 未来予測 -
しかしながら、製品リリースにどれくらい時間がかかるかを知る正当なニーズがあり、そのために見積りが必要なこともあるだろう。そうだとしても、「ストーリー」の見積りは必要ないかもしれない。おそらくストーリーレベルまで要件を落とし込むことはないだろうし、もしそうだとしても、それらはかさばりすぎてほとんど無駄になってしまうだろう
もちろん、やる必要があるのであればやるといいが、もっと良い方法もあるかもしれない
まず、次のリリースのための重要な機能を１つか２つ考える。それが解決する問題は何か、それを解決するのに役立つソフトウェアは何か、少しは役に立つかもしれない最も単純な機能はなにか、ということを話してみよう。私達は全てを解決する必要はなく、多くの場合、ほんの少しの手助けができればそれで物事はうまくいく。（MVPを十分に小さくする）
まとめ
ストーリーポイントって結局なんのためにあるの？
「イテレーション（スプリント）計画」のためです。
過去の実績値（ベロシティ）から、「過去の実績がこんな感じだから、おそらく次のスプリントはこんくらいいけるだろう」という予測のみに使われます。
しかしながらJeffries氏は、「（多くの場合）完了予測をすることにさほど大きな価値はなく、それどころか誤用や弊害も多いので、そのくらいなら使わないほうがよい」というポジションを取っています。
ストーリーポイントでの見積りがイケてないなら、どうすればいいの？
Jeffries氏は「ストーリーを十分に細かく、２時間〜１日くらいの粒度までスライスすることができればそれで十分なんじゃない？」と言っています。
とにかく、価値を小さくスライスして、頻繁にデリバリーすることにフォーカスすべきであるという考え方のようです。
予測ができないなら、リリース計画はどうすればいいの？
リリースのための「機能リスト」を捨てて、本質的に解決したい問題はなんなのか、それを最小の手数でシンプルに解決する手段はなにか、ということを考える、つまり十分に小さいMVPの定義をして、リリースのバッチサイズを小さくするアプローチが推奨されています。
要は、大層な「リリース計画」が必要なくらいの大きいバッチサイズでの開発をしなくても、最も優先度の高い価値から小さくスライスして、価値がスムーズに流れるような開発をしていれば問題ないのではないでしょうか、ということみたいですね。
作りたい物の機能リストを羅列して、それがいつできるのかという見積りからリリース日を決めて開発を行うという従来型の発想からは、大きなパラダイムシフトが必要そうです。
個人的な感想
「予実分析」や「ベロシティの推移」を出すことは業務改善のヒントになったり、よいバロメーターになることもあるので、私自身は見積り自体の否定をすることはありませんが、それによる誤用や弊害も多いことは実感として非常によくわかります。
「価値のある小さいものを頻繁にリリースする」というアジャイルの中心的な価値は、常にチーム全員の認識として持っておきたいものだな、と再認識しました。
また、「ベロシティを上げる」とか「ベロシティを安定させる」といった発想は多くのスクラム開発の現場に溢れていて、間違った部分最適化を招いているケースをよく観測します。
ベロシティを目標指標とすることは完全にアンチパターンなので、この辺は強く啓蒙していきたいなーと思いました。
完全に余談ですが、Jeffries氏は別の記事で、以下のようなことを言っています。
どんなフレームワークやメソッドが組織によって形式化されているかは関係なく、どのAgile開発者も以下の方法で働くべきである：
・稼動している、テストされた、動く、統合されたソフトウェアを2週間ないし毎週生産すること。完全に機能するバージョンを新規で毎日、1日2回、それ以上の頻度で製作できるまでスキルを築くこと。
・そのソフトウェアのデザインをきれいに保つこと。成長するにつれて、デザインが複雑で粗悪になりがちである。意識的にこの傾向に抵抗し、逆転させること。常に小さな継続的なステップでリファクタリングすれば、進捗率は可能なかぎり安定し、堅実なものになる。
「価値のある小さいものを頻繁にリリースする」ために、開発スキルもしっかりと磨いていきたいところですね。
最後に、自分の好きな「アジャイル宣言の背後にある原則」を置いておきます。
動くソフトウェアこそが進捗の最も重要な尺度です。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
宣伝
最近は会社として、企業様への内製化支援コンサルティング / コーチングをはじめました。
今まで外注業者に開発をお願いしてきたけど、開発を内製化したい
自社でDXチーム・プロダクトチームを組成したい
開発チームになにかしら課題がある
今のチームのやり方でいいのか心配
アジャイル開発やプロダクトマネジメントについての知見がほしい
スクラムマスターや開発メンバーがほしい・足りない
もし以上のような課題があれば、なにかお力添えできるかもしれません。
情報交換でも雑談でもよいので、もし少しでも気になって頂けた場合は、shun.kimura@integritis.ioかTwitterのDMまで連絡もらえると嬉しいです。
読んで頂いてありがとうございました。
この記事が気に入ったらサポートをしてみませんか？