スクラムにおけるユーザーストーリー：知っておくべきことすべて

目標は明確だ。顧客に高い付加価値を提供する製品を開発したい。チームメンバーや利害関係者が満足する結果を得たい。しかし、どうやってこの目標を達成するのか？どうすれば、製品のすべての要件を小さなステップで徹底的に満たすことができるのだろうか？ 

Agileでは、ユーザーストーリーがそのための効率的なツールであることが証明されている。ユーザーストーリーは、最初のアイデアから販売準備の整った製品まで、段階を追ってあなたを導いてくれる。ユーザーストーリーとは何か、どのように作成するのか、そしてどのようにユーザーストーリーから利益を得ることができるのかを紹介する。

Agileにおけるユーザーストーリーの定義は、ユーザーの視点から見た製品の要求を記述するものである。言い換えれば、ユーザーストーリーは、製品がどのような特徴や機能を持つべきかを伝えるものである。そのため、ユーザーのニーズを議論・検証し、共通理解のもと実装に取り組むための中心的なツールとなる。 

ユーザーストーリーは、チームメンバー、利害関係者、顧客が理解し、話す普遍的な言語を提供する。実際には、これは、誤解の余地をほとんど残すことなく、顧客が望む製品の理解を深めるためにユーザーストーリーを使用できることを意味する。 

いくつかのユーザーストーリーをまとめてユースケースとする。 ユーザーストーリーの起源はAgileソフトウェア開発にある。

ユーザーストーリーは、顧客やユーザーの視点から作成されるプロジェクトの結果に対する要求や希望を記述する。アジャイルなユーザーストーリーは、このような基本構造を持つ：

WHO (役割）を望んでいる。 何 (目標／願望） なぜだ (付加価値）か？

ユーザーストーリーの個々の構成要素を詳しく見てみよう：

WHO (USER)

WERのプレースホルダーには、顧客やターゲットグループの典型的な代表者を記入する。ユーザーAgileストーリーのWHOをどの程度詳細に記述するかは、ユーザーストーリー自体やプロジェクトの進捗に依存する。従って、意味のあるユーザーストーリーを作成するために十分詳細に記述すること。

なに

ここにユーザーの希望を置く。ユーザーが何を期待し、何を必要としているかを自問することができる。製品がまだ開発初期段階であれば、ユーザーがどのような機能を期待しているのか、経験に基づいて仮説を立てることができる。すでに同じような製品を市場に出している場合は、その製品に対するフィードバックから期待する機能を導き出すこともできる。

なぜ（付加価値）

ユーザーにとって機能が重要な理由を示すのは、その付加価値です。したがって、「なぜ」を追求することで、顧客の要求をどれだけ理解しているかを正直に振り返ることができます。なぜなら、顧客が要望するからといって、要求をユーザー ストーリーに含めるのは簡単ですが、顧客がそれを必要とする理由を理解して初めて、要求を実現するための背景が見えてくるからです。そのとき初めて、顧客の提案や要望が実際のニーズを効率的に満たしているかどうか、あるいはより賢い方法があるかどうかを問うことができるのです。例を見てみましょう。 

顧客がサイクリング用のレインケープを欲しがっている。したがって、「レインケープ」という要件を含めることができる。あるいは、なぜレインケープが必要なのかを顧客に尋ねることもできる。顧客が「濡れたくないから」と答えたとしよう。 

つまり、必ずしもレインケープを提供する必要はないということです。屋根付きの自転車を提供することもできます。重要なのは、顧客のニーズや問題、つまり濡れないようにするということが解決されることです。「なぜ」を理解すればするほど、より良いユーザー ストーリーを作成できます。

Agileにおけるユーザーストーリー（例）とは何か？

これで、Agile ユーザーストーリーの個々の構成要素がわかった。Agileユーザーストーリーの例は次のようになる： 

として お客様 私はそうしたい。 安全なパスワード***,*** 私の顧客データが守られるように。

以下がその内容である。顧客” ユーザー、“安全なパスワード” 関数と”顧客データが守られるように 付加価値である。 

スクラムでユーザーストーリーを扱うとき、受け入れ基準を追加する。受け入れ基準は、ユーザーストーリーが受け入れ時に満たすべき技術的要件を記述する。言い換えれば受け入れ基準は、ユーザーストーリーが価値を生み出すために必要な要件である。

バックログにおけるAgileユーザーストーリーの意味はもっと区別できる。なぜなら：バックログでは、ユーザーストーリーは要求を記述するだけでなく、特別な階層タイプを表すことができる。この3つの階層タイプがある：

叙事詩だ： エピックとは、製品の機能領域を広く定義したもので、その具体的な範囲はまだ不明確かもしれない。

特徴だ： フィーチャーとは、叙事詩における特定のパフォーマンス特性のことである。

ストーリーだ： ストーリーは、技術的なAgileユーザーストーリーと機能内のユーザーストーリーである。

これらの階層タイプはスプリント内で実装することができる。これらはユーザーに具体的な利益をもたらす。 

アジャイルプロジェクトマネジメントで役に立つユーザーストーリーを書くためには、すべてのステークホルダーとの詳細な話し合いが重要である。これらによって、ターゲットグループと作成する製品について包括的な理解が得られるはずだ。そこから、例えばペルソナを導き出すことができる。 

加えて、いわゆる インベスト基準説得力のあるユーザーストーリーを作るためだ：

独立系だ： ユーザーストーリーは他のユーザーストーリーから独立していなければならない。つまり、ストーリーの実装は、他のストーリーが事前に実装されていることを前提にしてはならない。これは、いつでもユーザーストーリーの優先順位をつけたり、バックログから削除できるという利点がある。 

自転車の例をもう一度見てみよう。顧客がもう濡れないように、雨よけの代わりに自転車のサドルに小さな屋根を取り付けることにしたとしよう。これがユーザーストーリーになる。しかし、屋根をつけるためには、まず屋根を取り付けることができる、より安定したサドルを開発しなければならない。それは別のユーザーストーリーだ。両ストーリーは互いに積み重なる。これはまさに防ぐべきことだ。

もちろん、あるユーザーストーリーを他のユーザーストーリーより先にやらなければならないのは、やむを得ない場合もある。しかし、一般的なルールとして、他の20のユーザーストーリーを最初に実装しなければならないユーザーストーリーは避けること。

交渉可能だ： ユーザーストーリーの作成には時間がかかることがありますが、完成したからといって変更できないものではありません。つまり： プロダクト・オーナー ステークホルダーと開発者は、常に一緒に議論し、ユーザーストーリーを洗練させるべきである。 

貴重なものだ： アジャイルプロジェクトマネジメントにおけるユーザーストーリーの結果は、顧客にとって付加価値がなければならない。

推定可能だ： 説得力のあるユーザーストーリーによって、開発チームはそれを実装するためにどれだけの労力がかかるかを見積もることができる。

小さい： ユーザーストーリーは、1スプリントで実現できるほど「小さな」ものでなければならない。

テスト可能だ： スクラムにおけるユーザーストーリーはテスト可能でなければならない。これが、実際に実装できるかどうかをチェックする唯一の方法である。

もしあなたがAgileでユーザーストーリーを書くことに慣れていなければ、余計な作業のように思えるかもしれない。しかし、ユーザーストーリーはチームにタスクの重要なコンテキストを提供し、各タスクの重要性をより明確にする。

基本的に、これがユーザーストーリーの利点だ：

ユーザー重視である： ユーザーストーリーは、問題指向のToDoリストのようなものだ。あなたのチームはそれを使ってタスクを管理し、ユーザーのニーズを満たす方法を正確に知ることができる。

ホリスティックな協力だ： ユーザーストーリーは、関係者全員に、物事がどこで進んでいるかを一目で示す。こうすることで、全員が協力し合い、ユーザーが特に高い付加価値を受け取る方法を何度も決定することができる。 

創造的な解決策だ： Agileソフトウェア開発でユーザーストーリーを作成する クリエイティブな結果 .なぜなら、最終製品に最適な解決策について、チームに批判的に考えさせるからだ。

一貫した成功： 各ユーザーストーリーは小さな挑戦である。そのため、チームは各ストーリーの後に小さな成功を祝うことができる。これは開発プロセス全体を通してモチベーションを高める。

ユーザーストーリーは、アジャイルチームの作業において重要なツールである。ユーザーストーリーは、誰のために何をなぜ開発するのかを何度も詳細に示す。これは、ターゲットグループに合わせた高品質の製品を作るのに役立つだけでなく、プロセス全体を通してチームのモチベーションを維持するのにも役立つ。 

アジャイル・ワーキングというマクロ・レベルで成功するためには、組織全体がアジャイルに考え、機能する必要がある。これを支援するために、私たちは著名な専門家たちと協力して以下のものを作成した。 プロジェクト・スカジャイル 設計されている。これは、様々なウェビナーで、アジャイル変革に正しくアプローチする方法を示している。トレーニングは無料だ。気軽に見てみよう！

振り返り用の質問をもっとバリエーション豊かにしたい場合は、こちらの記事をご覧いただきたい： 初心者とプロのための54の新鮮な回顧的手法 (マリオ・カート・レトロ、マラソン・レトロ、イーロン・マスク・レトロなど）。

ちなみに、チームメンバーのアジャイル mindset を持続的に開発する最良の方法の 1 つは、アジャイルヘルスチェックを実装することです。弊社の 無料Team-Health Checkコンストラクション・キット は、あなたが適切な質問をするのに役立ちます - ぜひクリックしてみてください。