アジャイルにおけるユーザーストーリーとは？書き方例とテンプレートを解説

プロダクトを開発する時

• 使う立場（顧客：ビジネス視点）
• 作る立場（開発側：技術的な視点）

この２つの立場があります。

作り手の立場だけで開発が進められてしまうと、顧客の要望を無視した開発側が作りやすいプロダクト開発が行われる危険性があります。

ユーザーストーリーを使う事で、開発側の視点だけでなく、顧客視点を大事にしたプロダクト開発を行う事ができます。

開発するプロダクトがユーザー（または特定のペルソナ）にとって、どのような役に立つ（価値を提供する）かを示すものがユーザーストーリーです。顧客のニーズを無視して、開発者が作りたいものを作ってしまったという失敗を避けるためにもユーザーストーリーは重要なポイントになります。

また顧客との会話、意見交換が行われるユーザーストーリーに対応できる開発をするには、従来のウォーターフォール型開発ではなく、スプリントを繰り返すアジャイル開発が向いています。

この記事を読むことで、ユーザーストーリーを重視したアジャイル開発を包括的に理解する事ができると思います。

ユーザーストーリーとは

ユーザーストーリーは、ユーザー（または特定のペルソナ）の視点から開発する機能やサービスを説明した短い文章です。

ユーザーストーリーでは、ユーザーのタイプ、彼らはどんな機能やサービスを求めているか、その理由を説明します。ユーザーストーリーは、要件の簡単な説明を作成するのに役立ちます。

ユーザーストーリーの定義

ユーザーストーリーとは、

・誰にとって必要なプロダクトなのか
・ユーザー（または特定のペルソナ）が何を求めているのか
・その開発するプロダクトにより、どんな目的を果たせるのか

これらをユーザー（または特定のペルソナ）視点に立ち、かつ誰にでも理解できるわかりやすい言葉でまとめられた要件定義です。

ユーザーストーリーは、「機能やサービス」など開発すべきアイテムについて書き、「なぜそれが必要なのか」をチームは議論します。
ユーザーストーリーは、実際の製品要件を確立するための会話の出発点となります。

目的

ユーザーストーリーを作成する目的は、開発するプロダクトの機能が、ユーザー（または特定のペリソナ）に対し、どのようなニーズを満たし価値を提供するかをわかりやすく表すこと、これが目的です。

そのため顧客関係者全員が理解できるよう、専門用語は使わずできるだけわかりやすい言葉で作成します。

誰が作成するの？

ユーザーストーリーは、顧客の要望に近い立場であるプロダクトオーナー、プロジェクトマネージャー、UXデザイナーなど、より顧客視点で多角的視野で判断できる立場の人によって作成される事が一般的です。ですが、チームメンバー全員で作成することにより、理解がさらに進みます。

ユーザーストーリーを使うメリット

メリット１：より良い価値の提供

ユーザーストーリーは、誰にとってのプロダクトか焦点を絞って考えることで、ニーズを特定します。そのためプロダクトの価値が何かということも考えやすくなり、最良の価値を提供するのに役立ちます。

メリット２：コラボレーションの促進

ユーザーストーリーに取り組み始める前や、完成後など、開発メンバーとプロダクトオーナーはユーザーストーリーに関して、議論することになります。
これらの議論により、多様なビジネス視点や、技術的な視点が加わり、顧客のニーズを解決するための創造的で革新的な方法が見つかるかもしれません。

メリット３：プロダクトの構成要素を最適化する

ユーザーストーリーを提供するユーザー（または特定のペルソナ）の価値ごとに、プロダクトは段階的に構築されます。プロダクトを段階的に構築することで、迅速な実装とフィードバックを得ることが可能になります。
それぞれの機能をうまく実装することで、プロダクトが形成され、価値が高まり続けます。

メリット４：透明性を高める

ユーザーストーリーは、通常チームとステークホルダーなど関係者全員に共有されています。これは、チームメンバー、ステークホルダー間の透明性を高め、より良いコラボレーションと迅速な意思決定が可能になります。

メリット５：理解の共有

プロダクトオーナーと開発メンバーが共同でユーザーストーリーを作成、改善することで共通の理解が向上します。
以下のような共通理解が向上します。

ユーザーストーリーの作成は「機能やサービス」から考えるだけではありません。「どのような価値を提供したいのか」から考えることもできます。

「誰(ユーザーや顧客、または特定のペルソナ)」が「何を期待しているか」、それはテクノロジーとビジネスの観点から「何が実現可能か」
プロダクトオーナーが意図するものと、開発チームが理解して実装するもの

メリット６：リスク軽減

透明性を高め、コラボレーションを改善し、共有された理解を生み出すことは、さまざまなリスク軽減に繋がります。例えば、コミュニケーションリスク、技術リスク、ビジネスリスクなどのさまざまな潜在的リスクを軽減させます。

ユーザーストーリーがアジャイル開発と相性が良い理由

アジャイルでは「動作する（使用可能な）アイテムを頻繁に提供する」ことが重要です。

ユーザーストーリーは、この頻繁なリリースを可能にするための作業を構築する基盤として機能します。
またユーザーストーリーを作成することにより、プロジェクトの要点をチームが理解し、スプリントプランニングと優先度に関するタスクの整理も容易になります。

ユーザーストーリーは、複雑なタスクを小さな部分に分割することで、プロジェクトをより管理しやすくし、チームのモチベーションを高めます。

ユーザーストーリーのテンプレートと書き方

ユーザーストーリーは、実際に書かれた内容よりも、そこから生じる議論が重要であることを忘れないでください。とはいえ、ユーザーストーリーを作成するにあたって、テンプレートを使用することは、最初の一歩になるでしょう。

ユーザーストーリーのテンプレート

As [ persona ]
I can [ Feature ]
so that [ passionate why ]

「ペルソナ」として
「機能」でできる
だから「ワクワクする理由・得られる価値」

ユーザーストーリーのガイドライン｜INVEST

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

ユーザーストーリーは先程のINVESTの６つの項目に沿って書き出すと作成しやすいです。
その上で、以下の３つのポイントを抑えて書いてみましょう

ペルソナを設定

機能やサービスを開発する前に、「誰のために」を考えることは重要です。
プロダクトが、大きなビジネス価値を持ち成長するために重要なのは、ユーザーだけではありません。各カテゴリーのペルソナは、それぞれが求める機能は異なるかもしれません。

例えば、以下のようなカテゴリに関して検討します。

ニーズの確認｜そのプロダクトは、エンドユーザーにとってどのように役立つのか

それぞれのペルソナが、開発機能を使用する必要がある理由、またはそれを使うことによって得られる価値をよく理解しましょう。

「機能」は、ペルソナが機能や、サービス、プログラム、システムなどをどのように使用するかを説明します。たとえば、顧客がネイルサロンを予約できるアプリがあるとします。アプリを使用すると、次のようになります。

・ユーザーはアプリを使用して、近くのネイルサロンを探すことができます。
・行きたいネイルサロンを見つけて、予約と支払いができます。
・ネイルサロンは、ユーザーの支払いを完了すると予約を受け取ります。

これらはアプリをどのように利用し、アプリで何ができるかを示しています。

ユーザーストーリーは、何ができるかだけでなく、「それを使用したい理由」についても考える必要があります。

ペルソナが特定の機能を必要とする理由を知ることで、ユーザーがアプリをどのように使用し、アプリからどのような価値を得ているかをよりよく理解できます。

・ユーザーとして、近くのネイルサロンを探せるので、出先でも気軽に行くことができる
・ユーザーとして、支払いまで完了できるので、無駄な時間を減らせる
・ネイルサロンとして、アプリで予約支払いが確認できるので、事務作業が減りスタッフを減らすことができる

目的の明確化

ユーザーストーリーは、ペルソナの観点から、開発する機能がどのように価値を提供するかを明確にすることです。

ユーザーストーリーを通して、「誰 (ペルソナ)」が「何 (機能やサービス)」を「なぜ (価値)」求めているのかを示します。
これにより、チームは、何のためにその仕事をしているのか、それによってどのような価値が生み出されるのかを理解できます。

ペルソナにとっての価値が理解できるので、何を次に作り、何を作らないのか優先順位を決めるのを助けます。

教えてジョー！エピックとユーザーストーリーの違いとは？

下記のようなイメージです。
エピックはツールのJiraを使っている場合には、ポピュラーなのではないでしょうか。

通常は、

ユーザーストーリーが、プロダクトバックログで
タスク（サブタスク）が、スプリントバックログ

になるイメージです。

まとめ

スクラムでは、通常プロダクトバックログを使用します。

プロダクトバックログとは、開発すべき機能やサービスのリストです。このプロダクトバックログアイテムに関して、書き方の決まりはありませんが、ユーザーストーリーは、プロダクトバックログアイテムの最良かつ最も人気のある形式です。

そしてユーザーストーリーの最大のメリットは、チーム間のビジネス視点と、技術的な視点から議論が生まれることです。
これは、より良いプロダクトの構築、ひいてはより良いチーム構築にも役立ちます。