ユーザーストーリー

ソフトウェア開発と製品管理において、ユーザーストーリーとは、ソフトウェアシステムの機能についての非公式な自然言語による説明です。エンドユーザーまたはシステムのユーザーの視点から書かれ、インデックスカード、付箋紙、または特定の管理ソフトウェアでデジタル的に記録される場合があります。^[1]製品によっては、クライアント、ユーザー、マネージャー、開発チームなど、さまざまな利害関係者がユーザーストーリーを書く場合があります。

ユーザーストーリーは境界オブジェクトの一種です。ユーザーストーリーは意味づけとコミュニケーションを促進し、ソフトウェアチームがシステムとそのコンテキストについての理解を文書化するのに役立ちます。^[2]

• 1997 年: Kent Beck がデトロイトのChrysler C3 プロジェクトでユーザー ストーリーを導入しました。
• 1998年: Alistair CockburnがC3プロジェクトを訪れ、「ユーザーストーリーは会話の約束である」というフレーズを生み出した。^[3]
• 1999年：ケント・ベックがエクストリームプログラミング（XP）^[4]と計画ゲームにおけるユーザーストーリーの使用法を紹介した書籍「エクストリームプログラミング解説」の初版を出版した。
• 2001年:ロン・ジェフリーズはユーザーストーリー作成のための「3つのC」方式を提案した: ^[5]
  • カード（または多くの場合は付箋）は、概念を保持するための有形の物理的なトークンです。
  • 会話は、利害関係者（顧客、ユーザー、開発者、テスターなど）の間で行われます。会話は口頭で行われ、多くの場合、ドキュメントによって補足されます。
  • 確認により、会話の目的が達成されたことが保証されます。
• ^{2001年: ロンドンのConnextra [6]}のXPチームがユーザーストーリー形式を考案し、その例を他のチームと共有した。
• 2004年：マイク・コーンは、カードの使用法を超えてユーザーストーリーの原則を一般化した著書「ユーザーストーリーの応用：アジャイルソフトウェア開発向け」^[7]を発表しました。マーティン・ファウラーによると、この本は現在このトピックの標準的な参考文献と考えられています。 ^[8]コーンは、レイチェル・デイビスをユーザーストーリーの発明者として挙げています。^[9]デイビスはコネクストラのチームメンバーでしたが、発明はチーム全体の功績だと考えています。^[要出典]
• 2014年：2005年の最初の論文^[10]と2008年のブログ投稿^[11]を経て、 2014年にジェフ・パットンはユーザーストーリーマッピング技術を発表しました。これは、体系的なアプローチでユーザーストーリーの識別を改善し、ストーリーを構造化して相互依存性をよりよく可視化することを目的としています。^[12]

ユーザー ストーリーは、開発中のシステムの機能に影響を与えるために、ユーザーまたは顧客によって、またはユーザーまたは顧客のために作成されます。一部のチームでは、製品マネージャー (またはScrumの製品所有者) が、ユーザー ストーリーの作成と製品バックログへの整理を主に担当します。他のチームでは、誰でもユーザー ストーリーを作成できます。ユーザー ストーリーは、関係者との話し合いを通じて、ペルソナに基づいて作成することも、単純に作り上げることもできます。

ユーザー ストーリーは、いくつかの形式またはテンプレートのいずれかに従う場合があります。

最も一般的なのは、以下に示すConnextraテンプレートです。 ^{[13] [7] [14]} Mike Cohnは、「so that」節はオプションであるが、それでも役立つことが多いと示唆しました。^[15]

<役割>として私は<能力>を発揮できるので、<利益を得る>

クリス・マットは、「価値の追求」がソフトウェアを成功裏に提供するための第一歩であると示唆し、次のような代替案を提案した。^[16]

<役割>として<利益を得る>ために、私は<目標/願望>を持つことができます

5W1Hに基づいた別のテンプレートでは次のように規定されています。^[17]

<誰が> <いつ> <どこで>、私は <なぜ> なので <何を> 欲しいのか

セキュリティを向上させるためによく使用されるテンプレートは、「悪意のあるユーザーストーリー」または「悪用ユーザーストーリー」と呼ばれ、サイバー攻撃で発生する可能性のあるシナリオを検討するためにハッカーのように考える方法として使用されます。これらのストーリーは、ユーザーストーリーに見られる典型的なペルソナではなく、アプリケーションを侵害または損傷しようとする攻撃者の視点から書かれています。^[18]

不満を抱く従業員として、会社に損害を与えるためにユーザーデータベースを消去したい

上映クイズ（壮大な物語）

人事マネージャーとして、私は、採用候補者を機能マネージャーに送るべきかどうかを判断するためのスクリーニングクイズを作成したいと考えています。^[19]

クイズの思い出

マネージャーとして、私は既存のクイズを閲覧して、何を用意しているかを思い出し、今必要なポジションに既存のクイズを再利用または更新できるかどうかを判断したいと考えています。^[19]

限定的なバックアップ

ユーザーは、バックアップドライブが保存する必要のないものでいっぱいにならないように、バックアップしないフォルダーを指定できます。^[20]

エクストリームプログラミングの 計画ゲームなど、多くのアジャイル開発方法論の中心的な部分であるユーザーストーリーは、ソフトウェア製品に組み込む可能性のある内容を説明します。ユーザーストーリーは、顧客 (またはScrumの製品所有者) によって優先順位が付けられ、システムにとって最も重要なものを示し、開発者によってタスクに分割されて見積もられます。見積り方法の 1 つは、各タスクにフィボナッチ数列1、2、3、5、8、13 から選択されたストーリーポイントの数を割り当てることです。最も単純なタスクには 1 のスコアが与えられ、より複雑なタスクにはより高いスコアが与えられます。

ユーザー ストーリーを実装する直前に、開発者はそれについて顧客と話し合う機会を持つ必要があります。短いストーリーは解釈が難しい場合があり、ある程度の背景知識が必要になる場合や、ストーリーの作成後に要件が変更されている場合もあります。

ユーザー ストーリーは、これらの会話に基づいて詳細を追加して拡張できます。これには、メモ、添付ファイル、受け入れ基準などが含まれます。

マイク・コーンは受け入れ基準を「プロダクトオーナーがストーリーを完了したものとして受け入れるためにストーリーが何をしなければならないかについてのメモ」と定義しています。^[21]これらはユーザーストーリーの境界を定義し、ストーリーが完了して意図したとおりに機能しているかどうかを確認するために使用されます。

受け入れ基準に含めるべき適切な情報量は、チーム、プログラム、プロジェクトによって異なります。中には、「ユーザーはすでにログインしており、すでに自分の情報を一度編集している」といった「先行基準」を含めるものもあります。^{[この引用には出典が必要です]}受け入れ基準を典型的なアジャイル形式であるGiven-When-Thenで記述する人もいます。また、顧客や利害関係者から収集した元の要件から箇条書きを単純に使用する人もいます。^[21] ストーリーが完了したとみなされるためには、すべての受け入れ基準を満たす必要があります。

ユーザーストーリーの使用がソフトウェアの成功や開発者の生産性を向上させるという確かな証拠はありません。しかし、ユーザーストーリーは、過度の問題構造化なしに意味付けを促進し、成功につながります。^[22]

ユーザー ストーリーの制限は次のとおりです。

• スケールアップの問題: 小さな物理カードに書かれたユーザー ストーリーは、維持が難しく、大規模なプロジェクトに拡張するのが難しく、地理的に分散したチームにとっては面倒です。
• 曖昧、非公式、不完全：ユーザーストーリーカードは会話のきっかけとして考えられています。非公式であるため、さまざまな解釈が可能です。簡潔であるため、機能を実装するために必要なすべての詳細が記載されているわけではありません。したがって、ストーリーは正式な合意に達したり、法的契約書を作成したりするのには適していません。^[23]
• 非機能要件の欠如: ユーザー ストーリーにはパフォーマンスや非機能要件の詳細が含まれることはほとんどないため、非機能テスト (応答時間など) が見落とされる可能性があります。
• 必ずしもテクノロジーの構築方法を表す必要はありません。ユーザー ストーリーはビジネスの観点から記述されることが多いため、技術チームが実装を開始すると、技術的な制約により、個々のストーリーの範囲を超える作業が必要になる場合があります。ストーリーを小さなストーリーに分割すると、この問題を解決できる場合があります。また、「技術のみ」のストーリーが最も適切な場合もあります。これらの「技術のみ」のストーリーは、顧客/利害関係者に実証できる価値を提供していないとして、ビジネス ステークホルダーから異議を唱えられる可能性があります。

多くのコンテキストでは、ユーザー ストーリーは、オントロジー、セマンティクス、および組織上の理由から、グループで使用され、まとめられます。イニシアチブは、特定のスケール アジャイル フレームワークではプログラムとも呼ばれます。さまざまな使用法は、機能に関して製品所有者としてのユーザーの視点から見るか、タスク編成に関して会社の視点から見るかなど、視点によって異なります。

考えられるあらゆる種類のユーザーストーリーのグループ化に「エピック」と「テーマ」というラベルを使うことを提案する人もいますが、組織管理では、強力な構造化と作業負荷の統合のためにそれを使用する傾向があります。たとえば、Jira は階層的に整理されたto-do リストを使用しているようです。このリストでは、to-do タスクの最初のレベルを「ユーザーストーリー」、2 番目のレベルを「エピック」(ユーザーストーリーのグループ化)、3 番目のレベルを「イニシアチブ」(エピックのグループ化) と名付けています。ただし、イニシアチブは製品管理開発に常に存在するわけではなく、粒度をさらに 1 つ追加するだけです。Jira では、(追跡目的で)「テーマ」が存在し、固定階層のさまざまな部分の項目を相互に関連付けてグループ化できます。^{[24] [25]}

この用法では、Jira はテーマの意味を組織の観点から変えます。たとえば、テーマ「xyz」の開発にどれだけの時間を費やしたかなどです。しかし、テーマの別の定義は、共通の意味単位または目標を形成するユーザー向けのストーリー、エピック、機能などのセットです。製品の設計と開発のスタイルごとに異なるアプローチが存在するため、共通の定義はおそらくありません。この意味で、ハード グループや階層を一切使用しないことを提案する人もいます。^{[26] [27] [28] [29] [30] [31]}

複数のエピック、または密接に関連する多数の非常に大きなストーリーは、テーマとしてまとめられます。エピックの一般的な説明は、多数のスプリント、またはスケールされたフレームワーク (リリース トレインまたはソリューション トレイン) を必要とする膨大な作業です。

複数のテーマ、叙事詩、物語が階層的にグループ化されている。^[32]

オントロジーや意味関係によってグループ化された複数のテーマまたはストーリー。

ストーリーマップ^[33]は、製品の全体像を示す物語の流れに沿ってユーザーストーリーを整理します。この手法は、非常に詳細なユーザーストーリーが溢れかえり、製品の主な目的の実現を妨げるリスクに対処するために、2005年から2014年にかけてジェフ・パットンによって開発されました。^[要出典]

ユーザーストーリーマッピング^[34]では、ユーザーとのワークショップを使用して、まず主要なビジネス活動を特定します。これらの主要な活動には、複数の種類のユーザーまたはペルソナが関与する場合があります。

次に、これらのビジネス アクティビティに関与する個々のユーザーの主なタスクを特定することで、水平方向の横断的なナラティブ ラインが描画されます。このラインはプロジェクト全体にわたって維持されます。より詳細なユーザー ストーリーは、ユーザー ストーリーの実践で通常どおり収集されます。ただし、新しいユーザー ストーリーはそれぞれ、ナラティブ フローに挿入されるか、またはメイン タスクに垂直に関連付けられます。

水平軸は製品目標の範囲に対応し、垂直軸は個々のユーザーのニーズに対応します。

このようにして、全体像を失うことなく、大規模なシステムでも記述することが可能になります。

ストーリー マップは、製品バックログを 2 次元のグラフィックで簡単に視覚化できます。マップの上部には、ストーリーがグループ化されている見出しがあり、通常は「エピック」(大きな粗いユーザー ストーリー)、「テーマ」(関連するユーザー ストーリーのコレクション^[35] )、または「アクティビティ」と呼ばれます。これらは、ユーザーのワークフローまたは「システムの動作を説明する順序」に基づいて識別されます。垂直方向では、エピックの下に、実際のストーリー カードが割り当てられ、優先順位で順序付けられています。最初の水平行は「歩くスケルトン」^[36] で、その下は複雑さが増すことを示しています。^{[37] [説明が必要]}

ユーザージャーニーマップ^[38]は、単一のユーザーカテゴリの全体像を示すことを目的としています。その物語の流れは、単一のユーザーが目的を達成するために実行する必要があるフェーズとアクションの時系列に焦点を当てています。

これにより、一連のユーザーストーリーを超えてユーザーエクスペリエンスをマッピングできます。ユーザーからのフィードバックに基づいて、ジャーニー全体にわたる肯定的な感情と否定的な感情を特定できます。マップ上で摩擦のポイントや満たされていないニーズを特定できます。この手法は製品のデザインを改善するために使用され、^[39]参加型アプローチでユーザーを関与させることができます。^[40]

ユースケースは、「システムと1人以上のアクターの間の一連の相互作用の一般的な説明であり、アクターはユーザーまたは別のシステムのいずれかです。」と説明されています。 ^[41]ユーザーストーリーとユースケースにはいくつかの類似点がありますが、それらの間にはいくつかの違いがあります。

ケント・ベック、アリスター・コックバーン、マーティン・ファウラーらは、c2.com wiki（エクストリームプログラミングの本拠地）でこのトピックについてさらに議論した。^[43]

• カンバンボード
• ペルソナ（ユーザーエクスペリエンス）
• シナリオ（コンピューティング）
• 使用事例

• Daniel H. Steinberg、Daniel W. Palmer、『Extreme Software Engineering』、Pearson Education、Inc.、ISBN 0-13-047381-2。 
• Mike Cohn、『User Stories Applied』、2004 年、Addison Wesley、ISBN 0-321-20568-5。 
• Mike Cohn、「Agile Estimating and Planning」、2006 年、Prentice Hall、ISBN 0-13-147941-5。 
• ビジネスアナリストの時間
• Payton Consulting「ユーザーストーリーとIEEEの要件の違い」