ユーザーストーリーとは何ですか？

ユーザーストーリーとは何ですか？

ユーザーストーリーとは、あるユーザーが仕事の一部として行うか、行わなければならないことを記録したメモです。各ユーザーストーリーは、ユーザー視点から自然言語で書かれた短い説明で構成されています。従来の要件定義とは異なり、ユーザーストーリーはシステムが提供すべきものではなく、ユーザーが何を必要としているかに焦点を当てます。これにより、解決策についてのさらなる議論の余地が生まれ、顧客のビジネスプロセスに本当に適合するシステムの実現が可能となり、運用上の問題を解決し、何よりも組織に価値をもたらす結果が得られます。

3Cの概念

3Cとは、優れたユーザーストーリーの3つの重要な側面を指します。この概念は、ユーザーストーリーの共同発明者であるロン・ジェフリーズによって提唱されました。現在、ユーザーストーリーについて話す際には、通常、これら3つの側面から構成されるタイプのユーザーストーリーを指しています。

1. カード – ユーザーストーリーはカードとして記述されます。各ユーザーストーリーカードには、ストーリーの内容を思い出させるために必要な最小限のテキストを含む短い文が記載されています。
2. 対話 – 要件は、ソフトウェア開発プロジェクト全体を通じて、顧客と開発チームとの継続的な対話によって発見され、洗練されます。重要なアイデアや意思決定は、ステークホルダー会議の過程で発見され、記録されます。
   
3. 確認 – また、ユーザーストーリーの受入基準とも呼ばれます。要件の議論の過程で、顧客は分析者に自分が何を望んでいるかだけでなく、作動するソフトウェアが受け入れられたり拒否されたりする条件や基準についても確認します。その定義されたケースが確認事項として記録されます。確認は、対応するユーザーストーリーの作業の正確性を検証することに焦点を当てており、統合テストではありません。
   

ユーザーストーリーをどう特定するか？

ユーザーストーリーはステークホルダーとともに特定すべきであり、できれば対面での会議を通じて行うべきです。ユーザーストーリーは、事前要件分析プロセスではなく、要件発見プロセスです。従来の要件収集アプローチでは、システムアナリストは顧客のニーズを理解し、システムの要件仕様を詳細に作成しようとします。しかし、ユーザーストーリーのアプローチはそれとは異なります。文書化プロセスではなく、ユーザーストーリーの特定はノート取りに近いプロセスです。ユーザーとの対話の中で、彼らの問題やニーズを聞き、理解し、同時にそのニーズをユーザーストーリーとして記録します。これらのユーザーストーリーが要件の源となります。詳細は、必要に応じてタイムリーに補完され、プロジェクト開発プロセス全体を通じてチームに「ちょうどよい」要件の参照を提供します。

ユーザーストーリーによるビジネスプロセスのマッピング

BPMNは、ビジネス分析およびモデル化において最も強力なツールの一つです。プロセス改善に使用できるだけでなく、以下の手順を通じて、自動化を目的としたプロセスからユーザーストーリーを特定することもできます：

1. 単純に、BPMNビジネスプロセス図を使ってユーザーのワークフローをモデル化する。
2. ユーザーと共にプロセスモデルを確認する。
3. そして、問題のビジネス活動を分析し、自動化が必要なプロセスに関連するユーザーストーリーを特定する。これは、ビジネスプロセスからユーザーストーリーへのマッピングとも呼ばれます。

ユーザーストーリーの書き方

ユーザーストーリーを書く際には、以下の形式（または少なくとも、書いた内容が以下の文に合致していることを確認）で、ユーザーの声を意識して書くようにしましょう：

～として、私は～を達成したい。なぜなら、～だから。

例：～として、私は顧客、私は商品が到着したときにSMSを受け取る、そうすることで私は取りに行きなさい.

場所：

1. <役割>実装されるシステムとやり取りして目標を達成する人物、システム、サブシステム、またはその他のエンティティを表します。その人物はシステムとやり取りすることで価値を得ます。
2. <ビジネス目標>ユーザーがシステムとやり取りすることで達成できる期待を表します。
3. <ビジネス価値>システムとのやり取りの背後にある価値を表します。

これはルールではなく、以下の点を考慮することでユーザーストーリーについて考えるのを助けるガイドラインです：

1. ユーザーストーリーは誰か、または特定の当事者（例：顧客）に価値をもたらします。
2. ユーザーストーリーはユーザーのニーズを満たします（例：商品到着時にSMSを受信する）
3. このユーザーストーリーを実装する理由があります（例：顧客が購入した商品を取りに行ける）

各ユーザーストーリーは誰かに価値をもたらすべきです。しかし、ときにはビジネス目標を読むだけで価値が明らかである場合があります。価値を文の一部として記述するのは面倒です。そのような場合は、単に省略します。以下にいくつかの例を示します：

顧客として、クレジットカードを使って支払いを完了したいオンライン購入でクレジットカードを使えるようにしたい.

ユーザーとして、友人の名前を入力して検索したい名前で友人を見つけられるようにしたい.

ユーザーストーリーの書き方に関わらず、二つの点を常に意識する必要があります。第一に、ユーザーストーリーはユーザーの視点から書かれるべきです。第二に、記述は「ちょうどよい」程度に保ちましょう。ソフトウェア開発プロジェクトの初期段階で詳細を多めに記述しないようにしてください。後で開発者が設計や実装に使えるように、ユーザーストーリーを精査・詳細化する機会があります。

ユーザーストーリーのライフサイクル

広義には、ソフトウェア開発プロジェクトの全期間を通じて、各ユーザーストーリーには6つの主要な状態があります：

1. 保留中 – ユーザーとプロジェクトチームとのコミュニケーションを通じて、ユーザーストーリーが発見されます。この段階では、ユーザーストーリーはユーザーのニーズの簡単な記述以上のものはありません。要件の詳細な議論も、システムの論理も、画面設計もまだ行われていません。実際、今のところユーザーストーリーの唯一の目的は、このユーザーストーリー（カード）に記載されたユーザーの要望について、将来の議論を思い出させるためです。将来的にこのユーザーストーリーが廃棄される可能性もあります。
2. ToDo – 異なるステークホルダー間の議論を通じて、今後数週間で対応するユーザーストーリーが決定され、スプリントと呼ばれる時間枠に配置されます。このようなユーザーストーリーは「ToDo」状態にあるとされます。この段階ではまだ詳細な議論は行われていません。
3. 検討中 – ユーザーストーリーが「検討中」の段階にあるとき、エンドユーザーは要件の確認および受入基準の定義のために開発チームと連携します。開発チームは要件や決定事項を会話メモとして記録します。UXスペシャリストは、提案された機能を視覚的なモックアップでユーザーに事前に確認させ、体感できるようにするためのワイヤーフレームやストーリーボードを作成することがあります。このプロセスはユーザーエクスペリエンスデザイン（UXデザイン）と呼ばれます。
   
4. 開発中 – 要件が明確化された後、開発チームはユーザーの要望を満たすための機能を設計および実装する。
5. 確認中 – 開発チームがユーザーストーリーを実装すると、最終ユーザーによってそのユーザーストーリーが確認される。ユーザーは、テスト環境または部分的に完成したソフトウェア製品（時折「アルファ版」として知られる）にアクセスできるようになる。機能の確認は、ユーザーストーリーの詳細化時に記載された確認項目に基づいて行われる。確認が完了するまで、ユーザーストーリーは「確認中」とされる。
6. 完了 – やがて、機能が完了したことが確認されると、ユーザーストーリーは「完了」状態とみなされる。通常、これがユーザーストーリーの終わりである。ユーザーに新たな要件がある場合、それは新しい機能に関するものか、または完了したユーザーストーリーの改善に関するものである。その場合、チームは次のイテレーション用に新しいユーザーストーリーを作成する。

ユーザーストーリーの詳細化 – いつ、なぜ行うのか？

ユーザーストーリーが従来の要件収集手法と異なる重要な点は、問題と解決策の特定を、ソフトウェア開発プロジェクトの異なる段階で実施する2段階に分ける点である。ソフトウェア開発プロジェクトの初期段階で問題とユーザー要請の概要が明らかになる一方、システム要件の詳細は設計および実装の開始直前にのみ明らかになる。このアプローチの利点は以下の通りである：

1. 要件が実装直前に詳細化されるため、最新のユーザーのニーズに応じられる。初期段階ですべてを決定するのではなく、そうした形で対応できる。
2. 問題と解決策の両方が詳細に議論されるため、適切な要件をより簡単に特定できる。従来のアプローチでは、プロジェクトの初期段階ですべての要件の詳細を事前に明らかにする必要があるため、「事前要件」は時間とともに変化する可能性があり、分析作業の多くが無駄になる。
3. 一方で、無効であることが判明したユーザーストーリーは簡単に廃棄できる。事前の調査や文書作成に多くの時間を費やすことなく済む。

ユーザーストーリーを効果的に使うには？

他の多くのソフトウェア開発手法と同様に、ユーザーストーリーを適切に活用すれば、品質の高いソフトウェアシステムを生み出し、顧客からの信頼と満足を得られる。ユーザーストーリーを使用する際には以下の点に注意が必要である：

1. ユーザーストーリーの記述は簡潔に保つ。
2. ユーザーストーリーを書く際は、最終ユーザーの視点から考える。
3. （UML）ユースケースはビジネス目標を表す。ユーザーストーリーをユースケースの下にグループ化できる能力により、ユーザーストーリーがビジネス目標を満たしていることを確認できる。言い換えれば、同じシステム目標を共有していることになる。これにより、ユーザーストーリーをより管理しやすく、スケジューリングや優先順位付けを行うためのポータブルな枠組みとなる。
4. 開発を開始する前に確認項目を定義する必要がある
5. 実装前にユーザーストーリーの見積もりを行い、チームの作業負荷を管理下に置く。
6. 要件は最終ユーザーと協議して得るものであり、最終ユーザー単独または開発チームだけが決定するものではない。最終ユーザーとの良好な関係を維持することは、双方にとってWin-Winの状況を生む。
7. 最終ユーザーが何を望んでいるかを理解するため、常にコミュニケーションが重要である。

Visual Paradigm は、以下のすべてのツールを提供していますアジャイルソフトウェア開発、以下のものを含むUMLユースケース図ツール, （アジャイル）ユーザーストーリー, スプリント, ストーリーボード と ワイヤーフレーム UXデザイン用、タスク管理ツール など