【翻訳】ストーリーポイントを使うのをやめよう
はじめに
このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。
誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。
ユーザーストーリーを使うのをやめよう
ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。
おそらくNoでしょう。
ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリティをそこない、プロセスの消化不良を引き起こしてしまう不自然な材料が含まれていることを知っています。
2007年に得た一連の経験で、ストーリポイントと、ベロシティ計算をやめることで、アジリティが高まることを同僚と私は経験しました。
同様の経験が、我々に固定した期間のスプリントからフローに基づくワークフローへの変更や、朝会から頻繁なチームのやりとりを行うプロセスへの変更をもたらしました。
我々の今日のプロセス*2は、我々のアクティビティはプロセスのムダと、より良い働き方を発見する経験に気を払うものでしたので、書籍に書いてあるようなものや、広く利用されているアジャイルの方法論とは異なるものでした。
このブログでは、我々がなぜストーリーポイントとベロシティ計算をやめ、それなしでどのように仕事を成功させられるかについて説明します。
ストーリーポイントを利用していた最初のころ
私がストーリーポイントを利用し始めたのは、サンフランシスコでのエクストリームプログラミングのチームで、1999年のことでした。
私はストーリーポイントがチームのキャパシティを明らかにするのを手助けることをとても気に入っていました。
ベロシティ（一定期間内に完了したストーリーポイントの数）として計算されたそのキャパシティは、チームにいる人（特にプロダクトマネージャー、プロダクトオーナー、あるいは内部の顧客）が、彼らの持ち物の中でどのくらい仕事をこなせるのかを理解する手助けをしました。
もしタイムボックス内の完了させるべき仕事がチームのベロシティと合わなくなる時があれば、それは絶対に必要なものとあると良いものを区別する重要な決定、考慮をするタイミングでした。
ストーリーポイントとベロシティは、本当に必要な機能を明らかにし、不要な（あるいはよく繰り返されてしまうマントラである『完了しない仕事を最大化してしまう』こと）ものを除去するのに役立ちました。
私はそれから8年にわたり、世界中の社内外のプロジェクトでストーリーポイントとベロシティを使っていました。
その間、沢山のストーリーポイントとベロシティへの誤解や誤用に気づきましました。
最初は、これらの問題は教育者としてよりよい仕事が求められているサインだと解釈しました。
しかし数年経つと、ストーリーポイントとベロシティの計算は重大な欠点を含んでいることが明らかになりました。
不合理なストーリーポイントのインフレ
もっとも大きな問題の一つは、フロリダ、タンパでの巨大有名企業で気がつきました。
我々がこの会社を知ったのは2002年のことでした。ディレクター（ジムとしましょう）がサンフランシスコにやってきてXPの集中ワークショップに参加した時のことです。
ジムはそこで体験したことを気に入り、すぐにフロリダのチームに持ち帰りたいと思いました。
我々はジムの会社で、２、３の部門を含む何百人もの人と4、５年にわたる付き合いがありました。
最初のチームでは、ジムは我々の準備、トレーニング、コーチングのサービスを含むアジャイル変革パッケージを購入しました。
彼は我々のアドバイスを取り入れ、25人のチームのために素晴らしいオープンスペースを用意しました（当時の基準からすれば大きなものでした）。
我々と一緒に働くのに先立って、彼はチームにPatrick Lencioniの5つのチームの機能不全*3、について学習して議論させていました。
暖かく良い日差しのタンパに着陸すると、我々は今まで経験したことのないもっとも準備の整ったチームの1つに会いました。
2年間を早送りすると、彼のチームはスケジュールを前倒して、素晴らしいソフトウェアを管理し、ボーナスを受け取り、親会社の権威あるプロセス改善の賞を勝ち取りました。
この会社を訪れた役員たちは、日常的にこのチームのオープンワークスペースを訪れ、彼らのプロセスを学んでいました。
我々はこのチームを誇りに思いました。しかし、彼らに起きつつあったことへの準備ができてはいませんでした。
2004年のある日、ジムはより早く進められるようチームを励ましました。
彼はスクラムに精通していないにもかかわらず、「スプリント」という用語を利用します。
このチームは、イテレーションごとに平均52ポイントのベロシティがありました。
彼らのベロシティは数ポイント上下することもありましたが、基本的には安定していました。
しかしジムがチームに「スプリント」という言葉を使った数週間後、チームのベロシティは80台に跳ね上がりました！
私は誰かに何が起きたのかを尋ねました。
彼女は笑いながら私を見て、「ここでは最近、あなたがくしゃみをするとストーリーポイントが得られるの」と言いました。
評価され、私と他のIndustrial Logicの二人のコーチにトレーニングとコーチを受けた成熟したアジャイルチームが、彼らが早く進んでいるように見せるために突然ストーリーポイントでの見積もりを膨らませてしまうことがあることにとても驚き、頭を振りました。
私のストーリーポイントとベロシティへの自信は、この経験のあと侵食され始めました。
あるいは、この問題は教育不足により引き起こされたものかもしれません。
そのため、2004年にストーリーポイントを捨てるのではなく、クライアント、特にマネージャーに対して、ストーリーポイントの誤用について教育を同僚と私はより力を入れて行うようになりました。
予測可能性のために品質を犠牲にする
TDDやリファクタリングのような技術的なプラクティスは、「見積もりをする」際に落とされる第一のものです。
我々は、トレーニングをする際、これらの行動が始めから出現するとわかっています。すなわち、全ての仕事をタイムボックス（2時間）で完了させるチームはしばしば品質を犠牲にしてこうするのです。
コミットメントを届けつつ、コード品質も向上するということがどういうことかを体験することを手助けすることを通じて、長年、この一般的な問題に取り組んできました。
素晴らしいチームが最終的にどのように技術的負債がない状態を維持し、一方で安定的なベロシティ（スプリントごとに同じ数のストーリーポイントを完了すること）を維持するについて、我々は説明しました。
しかし事実としては、そのようなチームは稀で、チームのサイズ変更や、その他のプレッシャーによって安定性も一瞬のものとなってしまいます。
とても長いあいだ、私は一定のベロシティを保持することが大事だと考えていました。なぜなら、計画時にいつプロダクトやシステムが完成するのかを予測するのを助けると考えていたためです。
しかし、バーンダウンチャートを良く見せたり、見積もりを作成したり超えたりするために、品質を犠牲にしたりただ技術的負債を積み上げるチームをいくつも見てきました。
ポイントでチームを比較する
長年にわたって、複数の会社のマネージャーがこう尋ねるのを聞いてきました。「Xチームは24ポイントをスプリントでDoneにできるのに、Yチームはたったの12ポイントしかDoneにできないのはなぜでしょうか？ チームのサイズはほぼ同様なのに、この差はなぜできるのでしょうか？」
チーム特有のキャパシティのインジケーターとしてベロシティを利用するのではなく、これらのマネージャーはベロシティを成果を測定する（Jim Highsmithがベロシティがアジリティを殺す！*4と書いているように）のに利用するという思考の罠にはまっています。
ベロシティでチームを比較するなと我々が言うことはできますが、とても多くの人がこのような比較が正当だと考えてしまうことに本当の問題があります。
2005年前後から、私はこの問題に対し、ストーリーポイントの後に好きなフルーツ名をつけることで対処しようとしました。
あるチームはベロシティをオレンジで測定し、またあるチームはりんごで、あるいはキウイで、といった具合です。
そして、マネージメントの人がいつものようにベロシティでチームを比較しようとすると、「りんごとオレンジは比較できませんよ」と伝えていました。
このアプローチが、チームでベロシティを比較することを無実だ*5と明らかにしましたが、よりシンプルでミスのない方法論を見つけることはなく、ストーリーポイントの誤用を止めることにもっぱらつながりました。
ストーリーポイントの混乱：俺たちバカ？
多くのストーリーポイントの利用の正当化根拠は、人間は実際の時間での見積もりが得意ではない、というものです。
我々は仕事が終わるまでどれくらいかかるかを見積もっているのではなく、仕事の大きさを見積もっているので、ストーリーポイントは我々をよりよい見積もりをもたらしてくれると支持者は言います。
実際に、どんな尺度が利用されているかに関わらず、人間は一般に見積もりは得意ではありません。
後ほどお見せするように、チームがよい見積もりを得るのは、頻繁に見積もり直した時です。
ストーリーポイントは問題をさらに混乱させるだけです。
時間を使って見積もりをし（「いつ行く準備ができる？」とか「家に着くまでにどのくらいかかる？」といったような）て我々が成長したとしても、同じことはストーリーポイントには当てはまりません。
これらを利用するには、我々は下記について学ばなければなりません：
- それらは何か、
- どのように利用するか、
- 誤用しないようにするためのたくさんの方法
典型的なストーリーポイント教育の中には、かなりの摩擦を含んでいるでしょう。
新人は、ストーリーポイントと、それを毎回実際の時間に変換することに混乱し、やりづらさを感じるでしょう。
賢明なアジャイルのエキスパートは、全力で新人に教育します。
彼らはストーリーポイントがTシャツやフィボナッチ数列のようだと説明します。
2005年、我々の顧客の一人が、ストーリーポイントについてあまりに混乱し、NUTs(漠然とした時間のまとまり)と*6改名しました。
ストーリーポイントの誤解と誤用は、特にプロセスがチームから部署、企業へとスケールして行くときに、時間をかけて増幅されていきます。
これらの誤解と誤用を正すのは、時間と労力を要します。
ストーリーポイントとベロシティ計算は、アジャイルチームの初期で、彼らを不要に混乱させてしまう不自然なテクニックなのです。
忙しさ（Busy-Ness）会計学
先日、様々な完成の段階のある技術的なタスクでいっぱいの巨大カンバンボードのある会社を訪れました。
チームが価値あるユーザーストーリーに取り組んでいるかどうかは、その物理ボードからはわかりませんでした。
リリース計画への進捗もわからず、WEBベースのアジャイル計画ツールも、あまり役には立っていませんでした。
その代わりに、そのツールは綺麗なベロシティのチャートと、完了まで何時間必要なタスクかをレポートするものがありました。
多くのアジャイルショップは、忙しい仕事のトラッキングをするのに固執しているようです。
私の同僚Tim Ottingerは、それを「忙しさ(busy-ness)会計」と呼んでいます。
ユーザーストーリーをタスクに分解するのは、それを完了させるには何が必要かを理解するのには役立ちます。しかし、多くの時間をタスクの見積もりと、ボードやツールを利用してそれらのタスクをトラッキングすることはウォーターフォールの遺物で、多大な労力の無駄です。
アジャイルであるとは、素早く優雅に動くということです。
それは有用で、品質のあるソフトウェアを頻繁にリリースすることを意味します。
どのくらいの時間を技術的なタスクに費やしたかの忙しさ会計することを意味しません。
よりシンプルな道
2001年に、クライスラー総合補償システムプロジェクト（XPの発祥の地）で働いていた初期のエクストリームプログラマーである、ドン・ウェルズが言及していたシンプルな計画アプローチに衝撃を受けたことを思い出しました。
ドンはエクストリームプログラミングのメーリングリストからのこのメールで下記のように言及しました：
我々は完了した項目を数えています。毎週最も重要なアイテムを選んで、先週こなした数の分だけ印をつけます。見積もりに力をかけるか否かにかかわらず、先週とほぼ同じ数のアイテムができると判明しました。私たちは1週間イテレーションなので、イテレーションの計画ミーティングでブレイクダウンをします。
おそらく効果は、物事を正しいサイズに分割する方法を学んだことです。私はまだ分かっていませんが、我々は大体8個を毎週完了させられるというのがポイントです。見積もりは必要ありません。
その時は、私はドンのシンプルな計画のアプローチを試す準備ができていませんでしたが、よりシンプルなプランニング方法を求める気持ちを強くしました。
他の実験
2007年の春から、同僚と私は、ストーリーポイントとベロシティ計算に関連する、よりシンプルなソリューションを実験するための問題を十分に見ていました。
Industrial Logicでの我々の最初の実験はひどく失敗しました。
私たちはストーリーポイントの代わりに実際の時間をトラッキングしました。しかし私たちは何時間もストーリーポイントでやったのと同じことをやっていました。すなわち、見積もり時間と完了した時間、そして次の固定された長さのタイムボックスへの利用可能な時間をトラッキングすることです。
このプロジェクトは約6ヶ月間続き、プロジェクトの人々の半数以上が時間での見積もりを嫌っていると言っていました。
その夏私はワシントンDCで開催されたAgile2007会議に出席し、デイビッド・アンダーソンがオープンスペースでbirds-of-a-featherセッションでカンバンメソッドについて話しているのを聞きました。
デイビッドが述べたことをとても気に入っていて、私の会社のニーズと文化にフィットするプロセスを探し続けることにインスパイアされました。
2007年の秋、ストーリーポイントと時間の使用をやめ、私が「可変長イテレーション」と（当時）呼んでいた方法をスタートしました。
固定の長さのタイムボックスで作業することを無くし、私たちはただ行うべき重要な仕事を少し選び、完了させ、出荷する、というのを繰り返しました。
一般に、仕事を完了するまでに1日かかるか4日かかるかなどは気にしませんでした。
私たちは、固定されたタイムボックスで仕事をすることや、完成したストーリーポイントの数を追跡したりすることではなく、出荷することにフォーカスしていました。
新しいプロセスを利用して、平均で週に1〜2回出荷をしました。
我々のアジリティは、プロセスから一部神聖なものを除くことで増加しました。
アジャイルマニフェストの第一原則に則ってデリバーすることで、私たちはより良いものになりました。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
締め切りがある場合は、すべての仕事を完了するか、後のリリースまで安全に延期できる仕事を見つけるようにしていました。
我々のプランニングのセッションはとても短く、一貫したベロシティを維持したかではなく、貴重なソフトウェアを出荷したかどうかで自分たちを評価しました。
私が「可変長イテレーション」と呼んでいたものは、実際にはリーン開発のフローベースのワークフローに似ていることを知りました。
そしてリーンの用語を用いて、カロリーのないコーラのように、ストーリーポイントをムダと記述するようになりました。
直感
2008年、Industrial Logicはシリコンバレーのスタートアップ（現在はIBMが所有しています）に、社内の1つのチームがアジャイルになるように依頼を受けました。
私たちのコーチの1人は、そのチームと数週間働き、ストーリーポイントの利用を含む伝統的なアジャイルのプラクティスでコーチングしました。
当時、私たちは顧客にストーリーポイントフリーのアプローチを教えるのはまだ快適ではなかったのです。
この最初のプロジェクトが完了して数ヶ月後、その会社は全社的にアジャイルを展開するために我々が支援できるかを尋ねました。
そこで我々は、プロセスの移行をを既に終えていた最初のチームへのインタビューを含む移行計画を策定しました。
そのチームのオープンワークスペースに入ったとき、バーンダウンチャート、リリース計画、イテレーションの計画、そして日々のチームのベロシティをトラッキングしているチャートで覆われた壁が見えました。
私はこの会社の最高のプロダクトマネージャーであると評判の女性と座りました。
数分の会話の後、私は壁のポスターのいくつかを指さし、計画と見積もりでどのようなことが起こっているのかを尋ねました。
少しの間を置いた後、彼女は笑いながら私を見ました。
それから彼女はすべての物事は順調で、ストーリーポイントを利用したベロシティを測定し、イテレーションとリリースで正しい業務量をベロシティを用いてスケジューリングしていると言いました。
彼女の表現が、何かが間違っていることを示唆していました。
「確かですか？」私は尋ねました。
彼女は数秒間止まった後、「本当の答えを知りたいですか？」と言いました。
私がうなづくと、彼女は、「ベロシティの数が入ったポスターを見ましたか？ 我々はあなたがここへ来ることを知っていて、あなたに我々の良いことについて上司に言って欲しかったので、我々はこれを作りました。」と告げました。
「本当ですか？！？」私は驚いて尋ねました。「それで、実際は何をしているのですか？」
彼女はチームが2週間のイテレーションや、2ヶ月のリリースに正しい業務量を選ぶために、単に直感を利用していると説明しました。
もし彼女たちが計画を修正する必要がある場合、ただ修正するだけです。それは常にステークホルダーに知らされます。
直感による見積もりと計画づくりというアプローチはうまく言っており、ストーリーポイントやベロシティの計算は不要だと彼女は言いました。
私は彼女のアプローチのシンプルさを褒め称え、彼女がやっていたことは完全にアジャイルで、ストーリーポイントの利用はアジャイルになることに不可欠ではないと彼女に保証しました。
そして一年前に、Industrial Logicがどのようにプロダクト開発でのストーリーポイントの利用をやめたのかを説明しました。
周期的なリリース計画
多くの人は、いつソフトウェアをユーザーにリリースし、おおよそどのくらいのコストがかかるのかを知るために見積もりを行います。
プロジェクトの初期は、ほとんどのリリース計画や日付は素敵なファンタジーです。
より正確な見積もりを得るために、数日や数週間を費やすこともできるでしょう。しかし、１ストーリーごとに分析と議論を10-15分し、ざっくりと見積もってしまう方が良いでしょう。
より高い勝ちを低コストで得るため、私はチームにバーゲンハンティングをコーチングしています。
より正確な見積もりを得るために、私はチームにリリース計画にあるストーリーの周期的な（例えば２週間ごとの）再見積もりをするようコーチングしています。
時間がたつと、定期的にリリース計画の内容を再見積もりするチームはより速くなり、リリース日が近づくにつれてますます正確になる時間に基づいたの見積もりを提供します。
これは必要なもの全てを上司に提供します。すなわちリリースの範囲、スケジュール、コストを正確に予測できるということです。
このアプローチによって、ベロシティの数にまつわるゲームはなくなり、フォーカスは反復的にスコープの議論と、何をリリースするかしないかに戻ります。
私はチームに「チーム週」を利用してリリースのためのユーザーストーリーを書き、見積もることを教えます。すなわち、チーム全体が作業を完了するのにかかる時間です。
１０人のチームで２人しかその仕事ができなくても問題ではありません。ただ0.5, 1, 1.5, 2チーム週のどれかとして見積もりを提供するのです。
もしあるユーザーストーリーの見積もりが２チーム週を超過したら、私はチームにストーリーを分割して２チーム週以内で見積もれるように促します。
リスクをより良く管理するため、進化的な設計とリリース計画を合わせて考えることは有益です。
あなたの最初の初期の製品、システムのバージョンには、高い価値をもたらす機能が含まれ、最も高いリスクへの対処がなされているべきです。
そのリリース（作り出すのに１−３ヶ月くらいを要するかもしれません）は顧客へリリースする何かよりも、内部のマイルストーンかもしれません。
次のリリースでは、既存の機能に機能追加したり、新機能を追加することで、新しいソフトウェアがさらに洗練されたものになります。
そして、顧客にリリースする準備ができるまでそれを繰り返します。
いずれにせよ、チームはリリース計画にある見積もったチーム週の数が、リリースまでに残されたカレンダーの週数に合っていることを確認する必要があります。
もし不一致があれば、リリースのスコープ変更し、再考し、再計画することでチームのキャパシティと合うようにするタイミングです。
私は、このスタイルのプランニングは、ストーリーポイントを使って見積もるよりもシンプルで、あるスプリントで見積もったベロシティが当たっていないと不快に感じることもなく、結果として良い結果をもたらすとわかりました。
周期的なリリース計画は、何の価値ある機能がデリバー可能かに繰り返しフォーカスすることで、人々のリスク管理を助けます。
ストーリーポイントのポイントは何か？
ストーリーポイントとベロシティ計算は、有名な書籍で正当化され、計画のためのツールに組み込まれ、認定によって検証され、業界で広く実践されている、アジャイルのデファクトなパーツとなっています。
しかし、私が知っているベテランのアジャイル実践者のほぼ全員、何年もの間ストーリーポイントとベロシティ計算を利用していません。
アジャイルの初期には、我々はストーリーポイントにポイントがあると考えていました。
しかし、私たちは、私たちのアイデアやプラクティスが硬直化しないように注意していました。
今日では、よりシンプルで、欠陥の少ないアジャイル見積もりと計画のアプローチがあります。
現在、ドン・ウェルズが2001年にかつておすすめしたことを行う人もいます。ほぼ同様のサイズのストーリーを同じ個数、毎スプリントで行うというものです。
他の人は、スプリントではなく、周期的なリリース計画を含んだ、フローに基づいたモデルで仕事をしています。
見積もりや計画については唯一の正しい方法はありませんが、時代遅れで欠陥の多いテクニックは避けることができます。
言い換えるならば、アジャイルハッピーセットの中に何が入っているのか注意してください。
ストーリーポイント利用をやめたいものの、始めるには助けが必要な場合は、モダンアジャイル計画ワークショップをお試しください。
チャーターでのディレクションの設定、ユーザーストーリーマッピングを利用したプロダクトのディレクションの明確化、プロダクトの仮説の検証する、しないことによる業務効率化、カンバンを利用した業務の見える化と仕掛かり制限について学ぶことができ、さらには見積もりで多大な時間を浪費することなく、より良い結果を生み出すことを学ぶことができます。
最後に
このエントリーは、Recruit Engineers Advent Calendar 2017の18日目のエントリーでした。 adventar.org
*1:https://twitter.com/JoshuaKerievsky/status/942234091801403394
*2:訳註：とはいえ原文は2012年なので、その点には注意してください
*3:https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756
*4:http://jimhighsmith.com/velocity-is-killing-agility/
*5:訳註：原文は"While this approach helped to point out the fruitlessness (pun intended) of comparing team velocities" となっていて、意図的なダジャレが入っているのですがうまく訳せなかったのが心残り
*6:訳註：NUTsはNebulous Units of Timeの頭文字をとったもの
