本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。

また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。

ここから本文です。

ストーリーポイント再考

私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。

もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及しているにもかかわらず、バックログアイテムをユーザーストーリーにすることは一般的なスクラムのプラクティスです。

少なくとも限られた範囲では正しいでしょう。ストーリーの一般的な使い方については別のところで書きました。ここでは「ストーリーポイント」について説明します。XP では、ストーリーはもともと時間で見積もられていました。そのストーリーを実行するのにかかる時間です。私たちはすぐに「理想的な日数 (Ideal Days)」と呼ぶことにしました。私たちは理想的な日数に「負荷係数」をかけて、実際の実装時間に換算しました。この負荷係数はだいたい3になる傾向がありました。つまり、理想的な日数分の仕事をこなすのに実質3日かかるということです。

私たちは、見積もりを日単位で話し、通常は「理想的な」という言葉を省略して使っていました。その結果、ステークホルダーは、1日の仕事を終わらせるのにどうして3日もかかるのか、あるいは逆の視点から目を向けて、なぜ3週間で50「日」の仕事ができなかったのか、と混乱することが多くなりました。そこで確か、私たちは「理想的な日数」を単に「ポイント」と呼ぶようにしました。つまり、1つのストーリーを3ポイントで見積もると、完了までに約9日かかるということです。ポイントというのは、あるイテレーションに要する作業量を決めるのに使うだけだったので、20ポイントくらいと言えば誰も反対はしませんでした。

私が名前を変える提案をしたかもしれません。もしそうだったとしたら、いまは申し訳なく思っています。この話題に関する私の現在の考えを、同僚の Simon に宛てたメールから紹介しましょう。

あなたは (ストーリーポイントを) 発明したことを本当に後悔していますか？それとも相対的なサイズを正しく理解していない場合に誤用されることを嘆いているだけですか？

私は次のように返答しました。

確かにその誤用は嘆かわしい
「いつ完了するか」を予測するために使うのは、せいぜい弱い考えだと思う
実績が見積もりと比較してどうなのかを追跡するのは、せいぜい無駄だと思う
見積もりやベロシティの質でチームを比較するのは有害だと思う

もう少し深く考えてみましょう。

「アジャイル」のアプローチの中には、計画を立てやすくするために、チーム間でストーリーポイントを正規化することを推奨しているものがあります。これは表面的には十分に理にかなっているように見えますが、チーム同士を比較するという罠にはまりやすく、実際に組織がそうしてしまうことがあまりにも多いです。

比較

まず第一に、たとえ「同じように見える」としても、それぞれのチームにはそれぞれのスキルがあり、それぞれの環境で仕事をしています。だから、同じように見える2つのストーリーを見て、一方のチームが2ポイントだと言い、もう一方のチームが6ポイントだと言ったとしても、それはあまり面白くないし、チームを比較するのに役立つ方法ではないことは確かなことです。

そのような状況を目の当たりにしたあなたや私は、好奇心を持ってその状況に臨むでしょう。まず比較できるほどその状況が似ているかどうかを確認し、次に高い見積もりを出したチームに、私たちが提供できる何らかの手助けが必要かどうかを探ります。それ自体はいいことです。暗に、あるいは明示的に「遅い」チームが劣っているとか、何かしくじっているとかを結論づけることは、非常に悪いことなのに、残念ながらよくあることです。

2つのチームが何かを生み出しているとき、多くのマネージャーにとって、それらを比較することは抗いがたい誘惑だと思います。これはストーリーポイントという概念を捨て去るほどの抗いがたい誘惑だと私は思います。そして、可能であればストーリーを見積もるという概念さえも捨て去るでしょう。より少ない見積もりで仕事をする方法については、また別の記事で触れることにしましょう。

追跡

多くのマネジャーにとって、見積りの存在は「実績」の存在を意味します。見積りと実績を比較し、見積りと実績が一致することを確認することを意味します。もし一致しない場合は、もっとうまく見積もることを学ぶべきだと意味します。

私にとって、リアルアジャイル (Real Agile) で重要なことは、次にやるべきことをいくつか選び、それを迅速に実行することです。重要な問題は、最も価値のあることを見つけ、それを素早く実行することです。それらを迅速に行うには、価値の高いものを小さく切り出し、迅速に反復 (イテレート) することに尽きます。ストーリーのコスト見積もりは、あまりその役には立ちません。

見積もりの存在によって経営陣が価値のボールから目を離し、代わりに見積もりを改善することに集中するようになると、真の価値を迅速に提供するという中心的な目的から注意がそれてしまいます。

このことから、ポイントであれ時間であれ、見積もりは避けるべきだと私は考えています。

プレッシャー

見積もりと実績の問題に関連するのは、「もっと」という経営陣の自然なプレッシャーです。チームがどんなに成果を上げていても、それだけでは十分ではありません。もっと、もっと、もっと。

価値を提供する最善の方法は、もっと、もっと、もっと、ではなく、小さな価値のあることを頻繁に行うことです。ストーリーを見積もるのではなく、「十分に小さいもの」に切り詰めれば、常に価値を提供しながら、スムーズな流れができます。

より多くのことに集中することは、価値を高める邪魔になります。チームはより速く進めようとして、コードの品質やテストに手を抜くことになります。やがて、より多くの不具合をリリースするようになり、不具合を修正するための再作業が増えるためにスピードが落ち、コード品質が急速に低下するためにさらにスピードが落ちます。事態はますます悪化し、プレッシャーは増大し、間をおかず惨事へと至ります。

見積もりは少なくとも不当なプレッシャーの適用に関与しているので、私は見積もりを避けたいのです。

さらに言いましょう。イテレーションやスプリントのプランニングは完全に止めた方がよいでしょう。次の数週間の予算を埋めるために仕事をするのではなく、次にすべきいくつかの最も重要なことのリストを持つために仕事をするのです。

完了の予測

必要不可欠な機能のリストを作り、それについてしばらく考え、次のリリースを決定するのは一般的なやり方です。次の質問は、もちろん、「いつまでにすべて完了するのか？」です。

答えは誰にもわからない、です。私たちは、わからないことを改善するために多くの仕事をできますし、入札を待っている大きな契約があるときなど、ある分野やある時期においては、それを行う価値はあります。しかし、社内外の顧客のためにソリューションを開発するビジネスをしている場合、私たちは頻繁に少量の価値を提供するのがベストであり、いつまでも未来に先送りするようなビッグバン的なリリースを待つべきではありません。

顧客に対する次のリリースの近い日を選び、そのリリースにできるだけ多くの良いものを詰め込む方がはるかに良いのです。ストーリーポイントであれ、グミベアであれ、あるいは時間であれ、見積もりは素早いリリースの邪魔をします。可能な限り、見積もりを避けるのがベストだと私は思います。

スライス

では、ストーリーの見積もりが嫌いなら、何が好きなのかという疑問が湧いてくるでしょう。私はストーリーのスライシングが好きです。これは、大きなストーリーを小さなストーリーにスライスすることであり、それぞれのストーリーは可能な限り高い価値を持ちますが、それを完成させるのに必要な時間はごくわずかです。理想的には1日以内、ほんの2、3時間です。

ここでは、スライスする際に何らかの見積もりが必要なのかどうかについて、あなたと屁理屈をこねるつもりはありません。もしあなたやあなたのチームが、頭の中で見積もりをして誰にも言わないのであれば、見積もりに関する問題は、それがストーリーポイントであれ時間であれ、発生しそうにはありません。そして「たぶん十分小さい」と「たぶん十分小さくない」の違いを知ることは、「3日」と「1日」の違いを知ることと同じではありません。

さらにコツがあります。私は小さなストーリーを手に入れるとスライス、見積もり、トリミングでそのことを紹介しました。Neil Killick から学んだことです。「1回の受け入れテストが必要になるまでストーリーをスライスしてください。少し練習すれば、適切なサイズにできます。」

もちろん、見積もりに関する他の記事もあります。ページの一番上にあるリンクをクリックすれば、これまで知りたかったこと以上のことが書かれています。

未来の予測

しかし … 製品リリースにかかる時間を知る正当な必要性があり、そのために見積もりは必要ではないのでしょうか？そうかもしれませんが、ストーリーの見積もりは必要ないでしょう。おそらく、ストーリーレベルまで要件を落とし込むことはないでしょうし、もしあったとしても、それはあまりにも膨大でほとんどが無駄になってしまうでしょう。

もちろん、やらなければならないのであれば、やればいいです。私ならこうする、あるいはこうすべきだという私の理論は、単なるアイデアに過ぎません。最終的には、自分たちの状況で成功するために必要なことは何でもやるしかありません。しかし、私にはもっとよいと思うことがあります。

最初に、次のリリースのために重要な機能を1つ、あるいはいくつか考えます。それが解決する問題は何か、それを解決するのに役立ちそうなソフトウェアは何かについて話し合います。少しでも助けになりそうな最もシンプルな機能について話し合います。すべてを解決する必要はありません。多くの場合、ちょっとした手助けができれば、それでモノゴトが動き出すのに十分なのです。

2番目に、期限を決めましょう。それまでに良いものを作れそうだと思えるような期限を考えましょう。期限を決めて仕事に取りかかります。

3番目に、重要な機能をスライスして実装します。かなり簡単に1日以内にできるはずです。次の最も重要な部分だけに取り組みます。最初の機能を、ほんのわずかなフリルまで埋め尽くそうとしてはいけません。「このちょっとしたことを1つだけやれば、顧客であるジャックはこれを実際に使うことができる」と考えるような心境になるようにします。そして、そのちょっとしたことをやってジャックに試してもらいます。私たちは価値の継続的提供にできるだけ早く移行したいのです。

私たちがやっていることの価値を目に見えるものにし、プロダクトオーナーや他のステークホルダーが、それを世に出すのを待ちきれなくなるようにしたいのです。そうすれば … ストーリーの見積もりの有無にかかわらず、私たちは正しいことをしていることになります。

まとめ

まぁ、もし私がストーリーポイントを発明したのだとしたら、いまとなっては少し後悔しているでしょう。ストーリーポイントは頻繁に誤用され、ストーリー見積もりをまったく使わないことで多くの落とし穴を避けることができると私は考えています。もし、あなたのチームや会社に大きな価値をもたらしていないのであれば、無駄であるという理由でやめることをお勧めします。一方、どうしてもストーリーの見積もりが好きなら、そのまま続けてほしい！