アジャイル開発についてはそれなりに調べているはずなのだが、いろいろ謎がある。具体的には Velocity、Story Point、User Story の出典は何なのか、という点である。
アジャイル開発についての一般書籍や概説を読むと必ず出てくる概念なのだが、これらの概念はすべての原点である「アジャイルソフトウェア開発宣言」はもちろん、最も普及しているアジャイル開発手法「スクラム」の定義が書かれている「スクラムガイド」にも見ることはできない。もうひとつの主要なアジャイル開発手法の原典である「エクストリームプログラミング」には「ストーリー」が出てくるが、定義された用語というより抽象的概念の説明に使われているだけだったりする。
主要文献で触れられていないためか論文でもほとんど触れられているものを見たことない。そのため、たまに一般書を読んでいると当たり前のように Velocity に言及され、戸惑ってしまう。
なぜ、原典が気になるかと言えば、こういった用語は言及する人によって微妙に色付けされて説明されるからである。オブジェクト指向とは何か、について10人の開発者に聞けば、ほぼ同じだが微妙に異なる説明をされるのと同じことだ。
で、今回のエントリはいろいろ調べてみましたという話。
まず Velocity については Agile Alliance の用語解説 に起源が書かれていた。
起源
「ベロシティ」は、アジャイル言説におけるコンセプトが本格的に現れるのではなく、一定の期間をかけて練り上げられるものであることを示す最良の説明のひとつかもしれません。初期のテキスト（"Planning Extreme Programming "など）でも、一般的に "個々のベロシティ "を測定することに好意的でした。"Story Point "が、"理想的な週次サイクル"に取って代わり、最も広く使われる見積もり単位になりました。このような変化は、メーリングリストやユーズネット、その他の場で議論され、いつ定着したのか正確に示すことは難しく、振り返って初めてわかるものです。
2000年：「ベロシティ」という用語は、エクストリーム・プログラミングに比較的遅れて追加された。
2002年：スクラムコミュニティが「ベロシティ」を測定する習慣を取り上げる。
該当の項目にはYahoo グループの該当のコンテンツへのリンクが張られているのだが、残念ながらリンク切れになっていてもはやたどり着けない（Internet Archive でも見つからない）。
ちなみに ChatGPT や Google Bard に聞くと「Mike Cohn」が発案者だと出てくるのだが、発案者ではなくおそらく最初に書籍で Velocity という概念を詳細に説明した人だと思われる。Google Books で検索すると 2004年の書籍「User Stories Applied: For Agile Software Development」内で Velocity という概念を詳細に扱っている。（日本ではむしろ2005年に出た「Agile Estimating and Planning（日本語版：アジャイルな見積りと計画づくり ）」で知られているかもしれない）
同書ではこのように書かれている。
Once an iteration length has been selected, the developers will estimate how much work they'll be abel to do per iteration.We call this velocity.
（イテレーションの長さが決まれば、開発者たちはイテレーションごとにどのくらいの働きができるのかを計測するだろう。我々はそれを velocity と呼んでいる）
Velocity の計測単位として Story Point を挙げられることが多いが、意外なことに起源はさらに古い。
起源
「見積りはどのような単位で表現すべきか」は、アジャイルコミュニティにおける長年のトピックです。初期のエクストリームプログラミングの実践者にとっての専門用語においては、「理想的な時間」とラベル付けされ「負荷係数」によって調整された期間として表現された見積りに強く固定されたままでした。
2000年の前あたりから「ガミー・ベア」という妙な用語が広まり、その後より中立的な「ストーリーポイント」という用語が普及しました。
しかし、エクストリームプログラミングの創始者の間でさえ、完全なコンセンサスはありませんでした。
1999年：ユーザーストーリーを見積もるための「ストーリーポイント」の代替となる単位「ガミー・ベア」が、ロン・ジェフリーズによって初めて言及される（後に、ジョセフ・ペリーヌ率いるXPプロジェクト発案であると明かされました）。
2003年："Nebulous Units of Time"（NUTs）という用語が、"story points "に代わるものとしてJoshua Kerievskyによって作られる。
Story Point はあまりはっきりした概念ではなく、人日を使いたくない人たちのための代替用語のように見える。「User Stories Applied: For Agile Software Development」内は次のように定義されている。
One team may decide to define a story point as an ideal day of work (that is, a day without any interruptions whatever-no meetings, no email, no phone calls, and so on). Another team may define a story point as an ideal week of work. Yet another team may define a story point as a measure of the complexity of the story. Because of the wide variety of meanings for story points, Joshua Kerievsky has suggested that story points represent Nebulous Units of Time, or NUTs.
My preference is to treat a story point as an ideal day of work.（あるチームは、Story Point を理想的な仕事の一日（会議、電子メール、電話など一切中断のない一日）と定義するかもしれない。別のチームは、Story Point を理想的な1週間の仕事と定義するかもしれない。また別のチームは、Story Point をストーリーの複雑さの尺度として定義するかもしれない。Story Point の意味は多種多様であるため、Joshua Kerievsky は、Story Point を漠然とした時間の単位と呼ぶことを提案している。
私の好みは、ストーリーポイントを理想的な1日の仕事として扱うことである。）
個人的には人日の方がわかりやすいと思うが、おそらくそこには日々の雑務が含まれていたり、能力差が反映されないという固定的な印象があり、その点に違和感を持っていることに起因しているのかもしれない。呼び方を変えたところでその問題が改善しているようには見えないのだが。
Story Point については「How Story Points turned to the dark side」と言う記事が面白い。
では User Story はどうだろうか。
User Story については前述のとおり「エクストリームプログラミング」の中で言及されており、これが起源のようだ。
この本は当時も買ったし、新しい版も読み返しているが新しい概念というより単なる単語のように使われており、具体的な定義があるようなものには読めない。むしろ、現代的には、User Story Template に沿ったものと解釈した方が良いように思う*1。これは「As a… I want to… So That…」という形式で要求をまとめる手法で、次の３項目に従い要求を文章化する。
- 誰の立場からの要求か
- どのような意図で要求しているのか
- 何を達成したいのか
しばしば、User Story はユースケースと同一視されるが、どの文献を見ても過剰なまでにユースケースとは異なる概念であることが強調される。User Stroy とユースケースの違いについては「ユーザーストーリーとユースケースの比較」という記事が詳しい。
たしかにどちらも要求/要件定義のためのツールと言う観点では同じでありながら、User Story は要求そのものなのに対し、ユースケースは要件の整理に焦点があてられているので違うものではある。
しかし、あまりにもそこが強調されているのは、ユースケースの過去の失敗に対し（ウォーターフォールに対するように） User Story はそんな重いものではないよ、と言いたいだけなのではと思わなくもない。
それにしても、Story という名前が付いていながら、User Story と Story Point の Story が指すもの、指す単位が異なるのはどうなのか。ここら辺の曖昧さも、アジャイルコミュニティでは主要なプラクティスとして言及されながら、スクラムガイドに採用されない理由のひとつなのかもしれない。
*1:User Story Template の発案者は Dan North だと思われる。
