「ストーリーポイント神話」を考える

はじめに

アトラシアン社のJira Softwareでは、ユーザーストーリーの見積もりの単位には、

• 時間単位の絶対見積もり
• ストーリーポイントでの相対見積

の両方を選択可能です。

ですが、Jira上の課題として作成したタスクの進捗のトラッキングは作業に用いた工数の時間単位で行うため、課題タイプの「サブタスク」にはストーリーポイントを設定できないという仕様があります。

この仕様の是非については論を避けますが、Jiraに限らずアジャイル開発について様々な方とやりとりをして感じるのは、「スクラムをはじめとするアジャイル開発のプロセスでは、見積もりに『ストーリーポイント』を用いて相対見積を使うものである」という認識の存在です。

もちろんストーリーポイントを用いて相対的なサイズを 用いる見積もり手法には、過剰バッファーや、理想日と実作業日の差異、不確実性への対処、コミットメントと進捗管理の分離など、ソフトウェア開発での見積もりについての問題に対応する上で様々なメリットがあります。

筆者も、「アジャイルサムライ」を始めとする書籍やアジャイル開発のコミュニティーでストーリーポイントの用いた相対見積もりの魅力に触れ、そしてアジャイアル開発の案件の中でそれを実践する中でサービスをローンチに導いた経験があります。*1

しかし、スクラムを始めとするアジャイル開発の中でストーリーポイントの存在があまりに大きいゆえに、アジャイル開発のフレームワークを論じる上でそれは所与のものとされ、意味の希薄化や教条主義化が発生しているのではないか、というのが筆者の問題意識です。

実際、筆者はこのエントリーを調べるに当たって様々なアジャイル開発についての文献をあたりましたが、ストーリーポイントの由来にふれないまま、ストーリーポイントの概念を所与のものとしてあつかう文献を複数確認しました。

本エントリーは、「ストーリーポイント」がアジャイアル開発の歴史の中でどういう文脈付けをしてうまれ、そして今日にいたるのかを示しながら、ストーリーポイントのメリットとデメリットについて明らかにするものです。

ストーリーポイントとは

アジャイルマニフェストの発起人であり、世界で初めてのエクストリームプログラミング(XP)のチームにコーチとして関わったとされる、Ron Jeffries氏は、ストーリーポイントの由来について、以下のように述べています。 (このツイートの記述については、id:kdmsnrに情報を提供いただきました。)

either i invented story points or i was there when it happened. story points are thinly obfuscated TIME, no more and no less.

— Ron Jeffries (@RonJeffries) 2013年3月1日

訳すなら、「ストーリーポイントは時間の湾曲表現であり、それ以上でもそれ以下でもない」といったところでしょうか。

その上で、彼が著者の一人である「XPエクストリーム・プログラミング導入編」ではストーリーポイントについて以下のように示しています。

さて、どうしたらいいのか教えてあげよう。私たちは、簡単なポイント制を使ってストーリーの難易度を見積もる。このポイントの呼び方はチームのネーミングルールに従ってもらって構わない。このポイントを完全作業週(perfect engineering week)と呼ぶチームもある。ただし、この呼び名を使うのがよくないと考えるチームもある。完全週数を実際の週数(結局はこれが私たちが使える時間だ)にあわせようとして、結局自分たちにプレッシャーをかけすぎることになるというのが理由だ。また「グミペアー」と呼んでいるチームもある。いや、本当に。あなたは「ストーリー見積単位」とか、「ドル」と呼ぶほうがいい、と思うかもしれない。Ronの今週のお気に入りは、ただの「ポイント」という呼び名だ。

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

そして日本では「アジャイルな見積もりと計画づくり」の著者として知られるMike Cohn氏が「User Stories Applied: For Agile Software Development」の中でストーリーポイントを取り上げるなどして、XPに限らずアジャイル開発全般にストーリーポイントというものが広まっていきます。

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

もっともXPにおいてはプラクティスとしてストーリーポイントによる見積もりは取り込まれず、Kent Beck氏とCynthia Andres氏は「エクストリームプログラミング」の第2版において、ポイントによる見積もりについて以下のように述べています。

第1版では、もっと抽象的な見積りモデルを紹介した。ストーリーのコストに1、2、3 という「ポイント」をつけていたのである。大きなストーリーは計画する前に分割する必要があった。ストーリーの実装が始まったときに、1 週間で達成できるポイント数をすばやく把握するのである。だが、今では実時間で見積もるほうが私の好みだ。そのほうができるだけ明確で、直接的で、透明性のあるコミュニケーションがとれるからである。

エクストリームプログラミング

このような価値観の相違の中で、ソフトウェア開発のフレームワークとしてのスクラムは見積の単位に対して言及することを巧みに回避しており、「スクラムガイド」の中にはストーリーポイントについての言及はありません。

ストーリーポイントによる見積のメリット

もちろん、ストーリーポイントによる相対見積は、以下のようなソフトウェアの見積もりに関する処方箋として、きわめて有効です。

• 理想日と実際に作業に使える時間の差異の吸収
• 全体の規模を出すときの累積誤差と、その結果としての過剰バッファーの問題
• 不確実性コーンへの対処
• コミットメントと進捗のトラッキングの分離
• チームの生産性を示す

最後に「チームの生産性を示す」をメリットとして示しました。

新しくメンバーが集まり、チームが結成されたとき(タックマンモデルの「形成期」「混乱期」)、チームはステークホルダーに対し、個人の集まりから集団が形成されて、 チームとして機能していることをステークホルダーに対してアピール する必要があります。この際に指標として有効なのはストーリーポイントの累積値としてのベロシティーです。またチームが新しく作られたときの チームを取り巻く様々な不確実性へ対処することを考えると、 組織がアジャイル開発に初めて取り組むときには、ストーリーポイントによる相対見積はプラクティスとして極めて有効です。

ストーリーポイントによる見積のデメリット

タスク駆動の現場との相性の悪さ

ITサービス運用の現場やインフラの構築・運用に関わる現場など、 タスクが、現場で行う実作業と密接に結びつく場合があります。 このような場合は、時間単位での見積のほうが手法として 適しています。

ゴールにたどりつくまでの方法論の欠如

もちろんバックログ個々は独立性をもち、それ単独でストーリーとして 完結していることが望ましいため、個々のバックログに対する ポイントの見積の総和がスプリント全体での見積となるのが理想的です。

それはバックログをスプリントのスコープに入れる時点で開発チームのメンバーが密にコミュニケーションし、バックログを開発チームが十分に咀嚼しているから可能になることです。

その視野が抜けた状態でのストーリーポイントの見積もりは、ウォーターフォールの案件でWBS上にタスクに対して見積もった工数を集計する見積手法と大差ありません。

生産性ありき

Jeffries氏の言及にもあるように、もともとストーリーポイントとは、現実の時間軸と、 週40時間労働の中で作業に使うことのできる理想時間とのずれに対応するために、 時間を単に抽象化したものでした。

しかし、ストーリーポイントによるベロシティーが示すものは、 どれだけ成果物としてのソフトウェアを 生産することができたかという「量」であり、工場のラインの産出量を 管理するようなテイラー主義に陥る危険性をはらんでいます。

ストーリーポイントの長所の一つは、コミットメントと進捗を管理することの分離にあります。ですがストーリーポイントによる進捗をチームの評価基準とした途端に、未来のストーリーポイントがコミットメントとして扱われ、ストーリーポイントによって計測される生産性そのものが目的になってしまいます。

もちろんストーリーポイントのメリットとしてあげたように、 チームの形成期においてまず目指すべきは、チームが安定してソフトウェアをリリース できるようになること、そしてその産出量としてのベロシティーを、ビジネスサイドの期待に答えることのできるレベルまでひきあげることです。

しかしチームが安定してからは、どれだけタイムリーに施策をデリバリーできたかを 占めるリードタイムや、デリバリーしたことによって生み出したビジネス面のインパクトなど、複数の視点を組み合わせてマネジメントするべきであり、ストーリーポイントはその一要素であるということを認識すべきです。

ストーリーポイントに関する批評を読み込むうえでは、上記のようなポイントを抑える必要があります。

poohsunny.hatenablog.com

まとめ

ストーリーポイントがこのような課題を抱えてしまうのは、 「ストーリー」が本来持つべき実現する課題に足しての抽象度と、 着手する「タスク」が持つべき作業としての具体性を吸収できるレイヤー構造を 持っていないためです。

「スクラム現場ガイド」ではストーリーの構造に対して、

• エピック
• テーマ
• ストーリー
• タスク

という四階層を示しています。

エピックとは長編、指輪物語のような壮大な物語のことだ。エピックのスコープは巨大だ。「ドキュメントのユーザーインターフェイスを再構築する」はエピックだ。

テーマとは大きなエピックに含まれる中心的なアイデアだ。「ドキュメントエディタのメニューバー再構築する」はテーマであり、エピック「ユーザーインターフェイスを再構築する」の一部となる。

ストーリーはテーマの中の1つのイベントだ。「編集メニューを差構築する」ストーリーは「ドキュメントエディタのメニューバーを再構築するの」*2 テーマに含まれ、このテーマは「ユーザーインターフェイスを再構築する」エピックに含まれる

タスクはストーリーを実現するのに必要なアクションだ。個々のタスクをすべて実施すれば、ストーリーが完成し、出荷可能になる。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

ストーリーポイントの長所で示したように、過剰バッファーや、理想日と実作業日の差異、不確実性への対処、コミットメントと進捗管理の分離に対して、ストーリーポイントによる見積は今日でも有効です。

その上で、タイムボックスの中でタスクを一個一個着実に消化する先にストーリーのリリースがあるということを踏まえ、相対見積と作業時間による見積もりを適切に使い分けていくことが、ソフトウェア開発には必要です。

*1:アジャイルの魂2015収録「アジャイル開発の現場で働いてみて」http://shop.manaslink.com/items/1817694

*2:原文ママ