ストーリー

ストーリーはユーザーと開発者の双方が一緒に効果的に仕事を行うのに十分な合意を取れる「ピジン言語」のように作用する。

─Bill Wake、エクストリーム・プログラミングの共同提唱者

ストーリーの概要

ストーリーとは、アジャイル開発においてシステムの振る舞いを定義するために使用する、主要成果物である。ストーリーは要求ではない。望まれる機能の小さい一部分を、通常はユーザー視点でユーザーの言語を使って、短くシンプルに記述したものである。それぞれが、小さく縦に切り分けたシステム機能の実装をサポートするためのものであり、それによって高度にインクリメンタルな開発が進められる。アジャイル開発におけるストーリーは、主に従来の要求仕様の代わりに使われる。また、もっと後になって、従来型の要求ドキュメントが要求されたときにそれを作成するのにも使われる。

ストーリーには、ビジネス担当者と技術担当者の両方が意図をちょうど理解できるだけの情報が記述される。これは、意図する振る舞いや影響についてもっと徹底的に議論するための焦点として作成される、「会話の約束」である。ストーリーを実装する準備ができるまで、詳細は先延ばしされる。受け入れ基準によって、実装される過程でだんだんとストーリーが明確になり、システム品質を確保するために役に立つ。受け入れ基準は、受け入れテストとして記述し、自動化することができる。このテストによって、ストーリーの記述時にも、後になってソリューションが進化していったときにも、機能が適切に実装されていると確認することができる。これはSAFeの「品質の作り込み」のプラクティスの重要な要素である。

ストーリーのもう1つの種類にイネイブラーストーリーがある。これはシステム機能を表すものではなく、調査やアーキテクチャーやインフラに関して必要な作業項目を可視化するためにチームが使用するものである。

詳細

SAFeでは、システムの機能的な振る舞いを記述するために、4階層の成果物を用意している。上位から順に、エピックシステム能力フィーチャーストーリーである。これに非機能要求(NFR)を加えたものがアジャイル要求(システムの振る舞い)成果物であり、これらを使ってシステムやソリューション意図の定義、システムの振る舞いのモデリング、アーキテクチャー滑走路の構築が行われる。

エピックやシステム能力やフィーチャーやイネイブラーでは、意図された大きな振る舞いが記述されるが、詳細な実装作業はストーリーとして記述され、このストーリーがチームバックログに含められる。ほとんどのストーリーはプログラムバックログ内のビジネスフィーチャーやイネイブラーフィーチャーをもとに作成されるが、チームのローカルコンテキストで見つかるストーリーもある。

個々のストーリーは、インクリメンタルに実装でき、ユーザーまたはソリューションにいくらかの価値をもたらす、小さな独立した振る舞いである。それぞれの反復で新しい価値を納品できるよう、機能を縦に切り分けた1つの部分である。そのため、1つの反復で完成できるよう、ストーリーを分割する(下記参照)。

ストーリーは、最初、インデックスカードか付箋に書くことが多い。物理的なカードを使用することで、チームとストーリーとユーザーの間に目に見える関係が生まれるし、チーム全員でストーリーを書くことができるようになる。また、運動感覚の要素もある。作業が可視化されるため、壁や机に配置して、順番を並べ替えたり、回したり、必要なら任せてしまうこともできる。チームは、範囲(「あら、私が引き受けるストーリーはこんなにあるのね」)や進捗(「この反復でこれだけのストーリーが完成したぞ」)を理解しやすくなる。

ストーリーは誰でも記述することができるが、チームバックログに取り入れる承認や、メインライン開発への受け入れは、プロダクトオーナーの責務である。もちろん、付箋では企業全体で大規模に使うことはできないので、ストーリーはすぐにアジャイルプロジェクト管理ツールに入れられることが多い。

SAFeにはユーザーストーリーとイネイブラーストーリーという2種類のストーリーがある。それについてこの後で説明する。

ストーリーの情報源

SAFeでは通常、図1に示すように、ビジネスフィーチャーやイネイブラーフィーチャーを分割してストーリーを作成する。

図1.  ビジネスフィーチャーをストーリーに分割する例

ユーザーストーリー

ユーザーストーリーは、必要とされる機能を表現する第一の手段である。主に、従来の要求仕様に代わるものとして使われる。(ただし、機能を理解し開発するためにストーリーを作成し、それを後でコンプライアンスや追跡可能性などのニーズに対処するドキュメントに記録することもある。)

ユーザーストーリーは、興味の対象をシステムではなくユーザーに置くという点で、価値中心であるといえる。そのため、次に示す「ユーザーの声」という表現形式が推奨されている。<ユーザーの役割>として、私は<活動>を行うことができる。それにより、<ビジネス価値>がもたらされる。

この形式で記述すると、チームは、がシステムを利用しているのか、具体的にシステムでを行うのか、それをなぜ行うのかについて、常に理解することができる。日常的に「ユーザーの声」を使用することで、ドメインにおけるチームの競争力が向上する。また、ユーザーの真のビジネスニーズをよりよく理解することもできる。図2に例を示す。

図2.  「ユーザーの声」の形式で書かれたユーザーストーリーの例

一般にはユーザーの声としてストーリーを記述するが、すべてのシステムがエンドユーザーと相互作用するわけではない。ときには、「ユーザー」がデバイス(例:プリンター)であったり、他のシステム(例:トランザクションサーバー)であったりする。この場合、図3のような形式でストーリーを記述することもある。

図3.  ユーザーがシステムである場合のユーザーストーリーの例

イネイブラーストーリー

さまざまなユーザーストーリーを実装したり、システムの他のコンポーネントをサポートしたりするには、技術機能が必要になる。チームはそれも開発しなければならない。この場合、ストーリーがエンドユーザーと直接関係しないこともある。このようなストーリーはイネイブラーストーリーと呼ばれ、他のすべてのイネイブラーと同様に、調査アーキテクチャーインフラをサポートする。この場合のストーリーは、図4に示すように、ユーザーではなく技術中心の言語で表現することができる。

図4.  イネイブラーストーリーの例

イネイブラーストーリーには次のようなものがある。

  • リファクタリングスパイク(もともとXPで定義されていたもの)
  • 開発/配置インフラの構築や改善
  • 人の介入が必要なジョブの実行(例:100万のWebページにインデックスを作成する
  • 異なる目的で必要になったプロダクト/コンポーネント設定の作成
  • 特殊なシステム品質検証(脆弱性テストなど)

もちろん、イネイブラーストーリーもユーザーストーリーと同様にデモを行う。通常は、作成した成果物を見せるか、UIやスタブやモックを使って実施する。

優れたストーリーの書き方

3つの「C」:カード(Card)、会話(Conversation)、確認(Confirmation)

XPの考案者の一人であるロン・ジェフリーズは、ストーリーの「3つのC」で高い評価を得ている。

カードは、ユーザーストーリーの意図を説明する文をインデックスカードや付箋やツールに記録したものを表す。インデックスカードを使用すると、チームとストーリーの間に物理的な関係ができる。カードのサイズがストーリーの長さを物理的に制限するため、システムの振る舞いを早すぎる段階で具体化できない。また、カードはチームが今後のスコープに関する「感覚」を得るのにも役立つ。手に10枚のカードを持つのと、スプレッドシート上の10行を見るのとでは、感覚が明らかに違う。

会話は、チーム、顧客/ユーザー、プロダクトオーナーやその他の利害関係者の間の「会話の約束」を表す。これは、意図を実装するための、より詳細な振る舞いを決定するために必要な議論である。この会話の結果として、追加の具体的な情報が、ユーザーストーリーの添付資料(モックアップ、プロトタイプ、スプレッドシート、アルゴリズム、タイミング図など)として作成されることがある。会話は、ストーリーのライフサイクルにおいて、次のようなすべての段階で行われる。

  • バックログの手入れ
  • 計画
  • 実装
  • デモ

会話の結果、共有のコンテキストが形作られるが、これは公式の文書では得られないものである。機能の具体的な例を挙げることで、要求のあいまいさが解消される。また、シナリオや非機能要求の足りない部分も会話によって明らかになる。チームによっては、ストーリーカードの確認のセクションを使って、ストーリーについて何をデモするかを記述する。

確認受け入れ基準は、ストーリーが正しく実装されたことを確認するために必要な正確な情報を示すもので、関連する機能要求や非機能要求を網羅する。図5は1つの例である。

図5.  ストーリーの受け入れ基準

アジャイルチームは可能な限り受け入れテストを自動化する。これは多くの場合、ビジネス担当者が読むことのできるドメイン固有の言語で記述し、それによってコードの「自動的に実行可能な仕様兼テスト」を作成する。自動化することでシステムの回帰テストを素早く行うことも可能になり、結果として継続的インテグレーションやリファクタリングや保守が強化される。

優れたストーリーのINVEST

優れたストーリーを書くためのポイントとして、Bill Wakeが考案したINVESTという頭字語がよく使われる。

  • I─Independent(独立している。他のどのストーリーにも依存しない)
  • N─Negotiable(交渉できる。意図を柔軟に記述したものであり、契約ではない)
  • V─Valuable(価値がある。顧客にとって価値のある、縦に切り分けた機能を提供する)
  • E─Estimable(見積もりができる。小さくて交渉可能である)
  • S─Small(小さい。1つの反復で実装できる)
  • T─Testable(テストできる。テスト方法を判断できるレベルまで理解できている)

詳細は、参考文献[1]および[2]を参照のこと。

ストーリーの見積もり

SAFeのスクラムXPアジャイルチームでは、ストーリーポイントと見積もりポーカー(参考文献[2])を使って作業を見積もる。ストーリーポイントは、以下の点を総合して表した1つの数値である。

  • 量─どれくらいの量があるか
  • 複雑さ─どれだけ困難か
  • 知識─分かっていることは何か
  • 不確定性─分かっていないことは何か

ストーリーポイントは相対的な値であり、具体的な測定単位との結びつきはない。各ストーリーのサイズ(工数)は、最も小さいストーリー(勝手に1というサイズが割り当てられる)に対する相対的な値として見積られる。SAFeでは、改変されたフィボナッチ数列(1、2、3、5、8、13、20、40、100)を使用している。これには見積もりにつきものの不確定性が反映されている(特に20、40、100などの大きい数字)[2]。

見積もりポーカー

アジャイルチームでは「見積もりポーカー」をよく使用する。ここでは、専門家の意見と類推と分解によって、短時間でできるけれども信頼性の高い見積もりを出す(他にもいくつかの手法が使われていることに注意)。見積もりポーカーのルールは次のとおりである。

  • チームメンバー全員が参加する。
  • 見積もりをするメンバーそれぞれに、1、2、3、5、8、13、20、40、100、それから「∞」および「?」という一組のカードが渡される。
  • プロダクトオーナーは、参加するが見積もりはしない。
  • スクラムマスターは、参加するが見積もりはしない。ただし、実際の開発作業に携わる場合は例外である。
  • 見積もり対象のバックログ項目ごとに、プロダクトオーナーがストーリーの説明を読み上げる。
  • 質疑応答を行う。
  • 見積もりメンバーは、それぞれ、自分の見積もりを表すカードを一人で選ぶ。
  • 全員が同時にカードをめくって、すべての参加者から見えるようにする。
  • 見積もりが高かった人、低かった人は、自分の見積もりを説明する。
  • 議論をした後で、見積もりメンバーは再見積もりのカードを選びなおす。
  • 見積もりはおそらく収束する。収束しない場合には同じプロセスを繰り返す。

設計に関してある程度の予備的な議論を行ってもかまわない。しかし、あまり時間をかけて設計の議論をしても、たいていは無駄になる。見積もりポーカーの真の価値は、ストーリーの範囲について共通の合意に至ることである。それに、これは楽しい作業でもある。

ベロシティー

チームの反復のベロシティーは、その反復で完了した(完了の定義を満たした)すべてのストーリーのポイントの合計である。ベロシティーを把握しておくことは、計画策定時に役立つし、WIPを制限するうえでも重要な要因となる。これまでのベロシティーで可能な以上のストーリーを引き受けないからである。ベロシティーは、大きなエピックやフィーチャーやシステム能力やイネイブラーを納品するのに必要な時間を見積もるのにも使われる(これらの見積もりもストーリーポイントで行われる)。

見積もりの共通初期基準

標準のスクラムにおいて、各チームのストーリーポイント見積もり(とその結果のベロシティー)は、他とは関係のないローカルの事柄である。小さいチームが自分たちのベロシティーを50と見積もっていて、大きいチームがベロシティーを12としていても、誰の問題にもならない。

ただし、SAFeの場合は、ストーリーポイントのベロシティーに共通の初期基準がなくてはならない。多数のチームのサポートを必要とするフィーチャーやエピックの見積もりを、経済的合理性に基づいて行うためである。そのためにSAFeのチームは、まず、あるチームのストーリーポイントが別のチームのストーリーポイントとだいたい同じになるようにし、場所(アメリカ、ヨーロッパ、インド、中国など)の経済状況を加味して、ストーリーポイントを費用に変換することで、作業の見積もりと優先順位付けができるようにする。結局、比較可能な「通貨」がなければ、見込みの投資に対する利益率を判断することはできないのだ。

ストーリーベロシティーの共通の初期基準を割り出す手順は次のとおりである。

  • 開発者およびテスト担当者ごとに、チームに8ポイントを与える(専任でない場合には調整する)。
  • チームメンバーそれぞれの休暇/休日ごとに1ポイントを差し引く。
  • コーディングに半日、テストと検証に半日程度かかる小さなストーリーを探す。それを「1」とする。
  • それ以外の各ストーリーについて、その「1」のストーリーに対する相対的な値で見積もりを行う。

例:3人の開発者と、2人のテスト担当者、1人のPOから構成される6人のチームがあるとする。休暇や休日はない。この場合、見積もった初期ベロシティーは5×8ポイント=40ポイント/反復となる。(注:開発者かテスト担当者の1人がスクラムマスターを兼ねている場合には、少し低めに調整する必要があるかもしれない。)

こうすることで、ストーリーポイントと理想的な開発者の1人日とを多少比較できるようになり、すべてのチームが作業の規模を共通のやり方で見積もるようになる。結果として、特定の地域のチームのストーリーポイントの費用を、管理者がかなり素早く見積もることができる。その後、意味のある方法で、今後のフィーチャーやエピックについて費用見積もりを算出する。

注:その後でチームの見積もりやベロシティーを調整しなおす必要はない。これは共通の初期基準でしかないからである。

チームはだんだんとベロシティーを向上することが多いが(これはよいことである)、実際にこの数値はかなり安定したままであることが多い。チームのベロシティーは、生産性の変化よりも、チームの規模や技術コンテキストの変化に大きい影響を受けるからである。また、必要であれば、財務計画の担当者がストーリーポイントごとの費用を少し調整することもできる。経験からいうと、これは小さい問題であり、共通の初期基準を設定しなかった場合に同程度の規模のチーム間でベロシティーが大きくばらつく方がよほど困ったことになる。それでは企業レベルになるとまるで役に立たない。経済性に基づいて意思決定をすることができないからである。

ストーリーの分割

ストーリーが小さければ小さいほど、迅速で、より信頼性の高い実装が可能になる。小さいほど、迅速にシステムを通過するため、変動や管理リスクが低減するからである。大きいストーリーを小さいストーリーに分割するのは、各アジャイルチームに必須のサバイバルスキルであり、インクリメンタル開発の技であり科学である。参考文献[1]ではストーリーを分割する10の方法が紹介されている。その項目を以下に挙げる。

  1. ワークフローステップ
  2. ビジネスルールのバリエーション
  3. 大半の労力
  4. 単純/複雑
  5. データのバリエーション
  6. データ入力方法
  7. システム品質を後回しにする
  8. 操作(例:生成、読み出し、書き込み、削除(CRUD))
  9. ユースケースシナリオ
  10. スパイクを始める

図6は、9番目の「ユースケースシナリオ」で分割する例である。

図6.  大きいストーリーを小さいストーリーに分割する例

SAFeの要求モデルにおけるストーリー

SAFeの要求モデルで説明したように、このフレームワークでは、さまざまな成果物や関係を使って、複雑なシステムの定義やテストをリーン-アジャイルに管理する。図7は、その全体像の中のストーリーの役割を示したものである。

 

図7.  SAFeの要求モデルにおけるストーリー

図7を見ると、常にではないが多くの場合にストーリーから新しいフィーチャーが作られること、ストーリーそれぞれにストーリーの受け入れテストが関連付けられることが分かる。また、XPやSAFeスクラムXPの場合には、ストーリーごとに単体テストも関連付けられていなければならない。単体テストは主にストーリーの実装が正しいことを確認するためのものである。また、単体テストは簡単に自動化できるため、テストの自動化を行うための重要な出発点となる(詳細はテストファーストのページを参照)。

注:図7ではラショナル統一プロセス言語の表記法を使ってオブジェクト間の関係を表している。0対多(0,1)、1対多(1..*)、1対1(1)などである。


さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011, 第6章 (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Cohn, Mike.User Stories Applied:For Agile Software Development.Addison-Wesley, 2004.

Last update:1 November 2015