ユーザーストーリーガイド - 影響力のある製品のためのアジャイル要件の作成

ユーザーストーリーは、エンドユーザーの体験を可視化するアジャイルソフトウェア開発の基盤となる概念です。これにより、長々とした技術仕様書から、共同作業を促進し、開発の取り組みがユーザーのニーズと確実に一致することを保証する、簡潔で価値主導型のナラティブへと焦点が移ります。これは最終的に、アジャイルチームがフォーマット、コラボレーション、柔軟性、モメンタムに関する問題を回避するのに役立ちます。

このガイドでは、ユーザーストーリーについて包括的に解説します。基本概念や作成手法から、高度な応用例やベストプラクティスまで網羅し、チームが影響力のある製品を生み出すための力を提供します。

主な内容：

• ユーザーストーリーとは
• ユーザーストーリーの例
• ユーザーストーリーの書き方
• Adobe Workfrontでユーザーストーリーを作成する

ユーザーストーリーは、エンドユーザーや顧客の視点から特徴や機能をとらえる開発ツールです。アジャイルチームは、ユーザーストーリーを付箋やインデックスカードに書き、ホワイトボードやデジタルカンバンボードに記録して進捗を監視します。

ユーザーストーリーの目的は、各要件を簡潔かつ正確に記述することです。技術的な詳細に焦点を当てるのではなく、ユーザーストーリーはチームが最も重要なこと、つまりエンドユーザー体験に集中し続けます。

ユーザーストーリーは、Kent Beck氏の1999年の著書「エクストリームプログラミング」で初めて登場しました。2001年には、Ron Jeffries氏が、カード、対話、確認からなる「3Cフレームワーク」をユーザーストーリーに追加することで、ベックの概念を拡張しました。

Bill Wake氏は2003年にINVESTチェックリストを作成し、チームが説得力のあるユーザーストーリーを書くための覚えやすい一連のガイドラインを提供しました。この頭字語を考案したのはWake氏ですが、Mike Cohn氏の2004年の著書『User Stories Applied：For Agile Software Development（アジャイルソフトウェア開発のためのユーザーストーリー実践）』によってこのチェックリストは広く知られるようになりました。

ユーザーストーリーは、開発者の間で注目を集めるようになっても、意図的に非公式なものにとどめられていました。これらは、計画や議論を容易にするために、インデックスカードや付箋に記載されます。見た目はまったく重要ではありません。その代わりに、ユーザーストーリーは本質と機能を重視します。

今日では、開発者は実用的なユーザーストーリーを書くために、INVESTの頭字語に従っています。

• 独立している：各ユーザーストーリーは他のストーリーから独立しているべきです。これにより、ストーリー間の重複や依存を最小限に抑えつつ、任意の順序でユーザーストーリーに取り組むことができます。独立したユーザーストーリーでは、柔軟な優先順位付け、開発、納品が可能です。また、独立したユーザーストーリーは、計画の複雑さを軽減します。
• 交渉可能である：ストーリーは厳格な契約ではなく、議論の出発点です。詳細は、プロダクトオーナーと開発チームの間の共同作業を通じて洗練されていきます。これらのストーリーは反復的であり、チームがより多くの情報を収集するにつれて変更されるべきです。交渉可能なユーザーストーリーは、継続的な対話を促進し、最善の解決策の創出を可能にします。これにより、特定の実装方法への時期尚早なコミットメントを防ぎます。
• 価値がある：構築中のプロダクトの目標は、エンドユーザーに価値を届けることにあります。ストーリーに価値がなければ、時間をかけるに価値はないでしょう。価値のあるユーザーストーリーは、開発努力が意味のある成果に集中することを保証し、ユーザーやビジネス目標に貢献しない機能の作成を回避します。
• 見積もり可能である：ユーザーストーリーの規模を大まかに見積もることができなければなりません。これにより、作業の優先順位付けとスケジュール設定を効果的に行うことができます。見積もり可能なユーザーストーリーは、計画立案、優先順位付け、予測を容易にします。ストーリーの見積もりができない場合は、さらに対話を重ねるか、分割する必要があることを示唆しています。
• 小さい：ユーザーストーリーは、開発者が単一のイテレーション内（通常は3日間以内）でコーディングとテストを完了できるほど小さく設定します。これにより、作業の安定した流れが促進され、迅速なフィードバックが可能になり、リスクが軽減され、進捗状況がより可視化されます。
• テスト可能である：すべてのユーザーストーリーは、ユーザーにリリース可能か、あるいは変更が必要かを判断する明確な基準を備えている必要があります。テスト可能なユーザーストーリーは、チームが「完了」したことを認識するのに役立ち、実装された機能が期待通りに動作することを証明できるようにします。これは品質保証を支援します。

3CプロセスとINVEST基準は、共生関係にあります。対話段階は、ストーリーが交渉可能かつ見積もり可能であることを確保するために重要です。確認段階は、テスト可能性の側面に直接対応します。また、カードは、焦点を絞った生産的な対話を促進できるほど小さく、かつ独立したものを表現するべきです。プロダクトチームは、3Cの共同作業段階において、INVESTを品質チェックリストとして活用できます。

ユーザーペルソナを定義する

汎用的なユーザーではなく、具体的なユーザーペルソナを使用することは、ユーザーストーリーの影響力と明確さを大幅に高めます。ペルソナとは、プロダクトを利用する可能性のあるさまざまなユーザータイプを特定するために、ユーザー調査に基づいて作成された架空の人物像です。ペルソナは、チームが共感を築き、ユーザーの動機、行動、目標に対する深い理解を得るのに役立ちます。

ペルソナを作成する際、チームはアンケート調査、インタビュー、フォーカスグループを通じて、ユーザー調査を実施することが一般的です。一度定義されたこれらのペルソナ名は、ユーザーストーリーの「［ペルソナ名］として」の部分で一貫して使用されるべきです（例：単に「マネージャーとして」ではなく「マーケティングマネージャーのサラとして」とする）。この具体性により、ストーリーが十分に理解されたユーザーセグメントのニーズに真に焦点を当てていることが保証されます。

ユーザーストーリーの主要要素

適切に作成されたユーザーストーリーは、通常、3つの核心的な要素を中心に構成され、それはしばしば簡潔な文の構造で表現されます。

• 役割：この要素は、ユーザーのアイデンティティまたはペルソナを定義します。ユーザーの動機と重視する関心事を捉えることは極めて重要です。この段階で、明確に定義されたユーザーペルソナを活用することは、共感を生み、影響力のあるストーリーを作成する上で非常に効果的です。
• 目標：この部分は、ユーザーがプロダクトまたは特定の機能を通じて達成しようとしていることを説明します。実装方法やUI要素を詳細に記述するのではなく、ユーザーの意図と望ましい成果を記述することに焦点を置くべきです。
• 利点：この重要な部分では、ユーザーが掲げられた目標を達成したい理由を明確に述べます。これは、ユーザーのニーズを駆り立てる価値、利点、または動機を強調し、機能をより大きな目的に関連付け、開発努力を正当化します。この部分は、システム要件ではなく、必ず真のビジネス価値またはユーザー価値を記述することが極めて重要です。システム要件に焦点を当てると、真のニーズが見落とされる可能性があるためです。

ユーザーストーリーは汎用性が高く、ユーザーニーズを理解することが不可欠なあらゆるプロダクトまたはサービスに適用できます。

Eコマースの例：「ユーザーとして、お気に入りアイテムを1つのリストで管理できるように、ウィッシュリスト機能がほしい。」

受け入れ基準には以下が含まれる可能性があります。

• ユーザーは商品ページからウィッシュリストに商品を追加できる。
• ユーザーは自身のウィッシュリスト内のすべてのアイテムを表示できる。
• ユーザーはウィッシュリストからアイテムを削除できる。

モバイルアプリの例：「コミュニティユーザーとして、凍結した道路について自分のネットワークに通知したい。そうすれば、他のドライバーが私と同じようなニアミスを経験せずに済む。」

受け入れ基準：

• アプリは、ユーザーの音声コマンドを認識して、新しい投稿を開始できること。
• アプリは、投稿内容を読み上げてユーザーに確認を求めること。
• アプリは、投稿を公開するかどうかをユーザーに確認すること。
• 通知がネットワーク上の友人に送信されること。

異なるユーザータイプ向けの例：ユーザーストーリーを特定のユーザーペルソナに合わせて調整することで、その効果が高まり、開発チームが共感しやすくなります。

• 融資担当者として：「融資担当者として、潜在顧客が当社のウェブサイト上で融資申し込みを行える機能を提供し、融資申込件数を増やしたい。」
• 潜在顧客（融資申込者）として：「潜在的な顧客として、特定の融資を申請する前に十分な情報に基づいた判断ができるよう、貸し手のウェブサイトで金利と申請手続きを確認できる必要がある。」
• エンジニアリングマネージャーとして：「エンジニアリングマネージャーとして、コード品質を確保し、機能のタイムリーなマージを実現するため、2段階のPRレビュープロセスを効果的に追跡するためのワークフローを確立したい。」

不適切なユーザーストーリーの例

ユーザーストーリーは誰が作成すべきでしょうか？

ユーザーストーリーは、通常、プロジェクトの計画段階で作成されます。しかし、機能が追加されたり、要件が変更されたりする際には、ユーザーストーリーを編集または追加することが必要になる場合もあります。

技術的には、誰でもユーザーストーリーを作成できますが、通常、プロダクトオーナーがこれらを作成および管理する責任を負います。プロダクトオーナーは、プロダクトのビジョンを担当しているので、最初のユーザーストーリーを作成します。プロジェクトを通じて、開発チームのメンバーもユーザーストーリーに貢献できます。特に、大規模な技術的ステップを管理しやすいストーリーに分割する必要がある場合に有効です。

関係者（顧客や経営陣など）がユーザーストーリーに貢献することも珍しくありません。ただし、通常、プロダクトマネージャーが最終的な決定権を持ちます。

ユーザーストーリーの本質は、簡潔さにあります。開発チームにとって有用かつ明確なユーザーストーリーを作成するため、以下の9つのステップに従ってください。

1. ユーザーペルソナを特定する：ユーザーが誰であるかを理解します。調査（アンケート、フォーカスグループ）を実施して、主要なユーザーセグメントを代表する詳細なペルソナを作成します。
2. ユーザーニーズを収集する：関係者とのディスカッション、ユーザーインタビュー、フィードバック分析を通じて、これらのペルソナが達成したいことを特定します。
3. 価値を定義する：それぞれのニーズに対して、ユーザーが得るベネフィットまたは価値を明確に表現します。これは、優先順位付けと、ストーリーに取り組む価値があることを保証する上で極めて重要です。
4. 共同作業と議論を行う：ストーリーの初期草案を開発チームおよび関連する関係者と共有します。ここで、疑問点が提起され、前提条件が検証され、詳細が具体化されます。
5. INVEST基準を適用する：ストーリーをINVEST原則に対して評価します。それは、独立している（Independent）、交渉可能である（Negotiable）、価値がある（Valuable）、見積もり可能である（Estimable）、小さい（Small）、テスト可能である（Testable）という基準を満たしていますか？満たしていない場合は、ストーリーを洗練させるか、分割してください。
6. 受け入れ基準を定義する：ストーリーが完成し、期待を満たしていることを確認するための、具体的でテスト可能な条件を、共同で作成します。これは、理想的には実装開始前に実施すべきです。
7. 工数を見積もる：開発チームは、必要な工数（ストーリーポイントを使用するなどして）を見積もります。ストーリーの見積もりが困難な場合、さらに明確化または分割が必要であることを示唆しています。
8. 優先順位を付ける。プロダクトオーナーは、価値、工数、依存関係、および戦略的目標に基づいて、プロダクトバックログ内でストーリーの優先順位付けを行います。
9. 定期的に精緻化する：アジャイルな仕事の本質は、共同作業と反復にあります。フィードバックとデータに基づいてユーザーストーリーを調整し、最終的により高品質なプロダクトを生み出します。新しい情報が得られたとき、または優先順位が変更されたときは、通常バックロググルーミングの際にこれらを更新します。

ユーザーストーリーの書き方を知ることは有益ですが、これまでに一度も書いたことがない場合は、敷居が高いと感じるかもしれません。優れたユーザーストーリーの例をいくつか見てみましょう。

ユーザーストーリーの利点

大規模なプロジェクトを小さなユーザーストーリーに分解することで、チームは複雑なプロジェクトに容易に取り組めるようになります。また、ユーザーストーリーはアジャイル開発チームにも以下のような利点をもたらします。

• シンプルなフォーマットで混乱を解消する：ユーザーストーリーは簡潔で技術的ではないため、幅広い人々が理解しやすくなっています。この単純化されたフォーマットにより複雑さを排除し、ユーザーのニーズについて全員が明確に理解できるようにします。
• ユーザーに焦点を当て続ける：ユーザーストーリーは、開発者が機能そのものよりも、ソリューションの究極の目的であるエンドユーザーを支援することに、より集中するのに役立ちます。
• 共同作業を可能にする：ユーザーストーリーは、ユーザーのニーズを明確にすることにより開発プロセスを効率化することで、チームメンバーの共同作業を大幅に容易にします。
• 創造的なソリューションを推進する：ユーザーストーリーはソリューションを規定するのではなく、ニーズに焦点を当てます。これにより、開発者は既存の枠組みに捉われずに考え、ユーザーのニーズを可能な限り最善の方法で満たす、より革新的なソリューションを生み出す自由度を得ます。
• 柔軟性を高める：ユーザーストーリーは非常に柔軟性が高く、ソリューションやユーザーのニーズについて理解が深まるにつれて調整することができます。これにより、アジャイルチームは変化に適応し、状況の移り変わりに合わせて進化することが可能になります。
• モメンタムを生み出す：ユーザーストーリーは小規模で実践可能であるため、漸進的な開発を可能にし、チームに絶え間ない成功の実感をもたらします。開発者は自身の進捗と成果をリアルタイムで確認できるため、チームのモメンタムにさらに拍車がかかります。

ユーザーストーリーを活用すれば、開発チームは大規模なプロジェクトを管理可能なタスクに分解できます。これにより、混乱が排除され、アジャイルチームがエンドユーザーにとって価値のあるソリューションを確実に生み出すことができます。

準備が整ったら、ユーザーの期待を超えるソリューションを探求しましょう。Workfront を利用すれば、目標が可視化され、チームは作業の優先順位付け、進捗状況の追跡、結果の測定を効率的に行うことができます。これはオールインワンソリューションであり、ユーザーストーリー、スプリントの進捗、バーンダウンチャートを、すべてダッシュボード上で直感的に確認できます。

Adobe Workfrontの詳細については、今すぐ概要動画をご覧ください。