アジャイル開発のユーザーストーリーとは？作成する3ステップを解説

「アジャイル開発を取り入れてるからユーザーストーリーを作ってはいるけど、本当にアジャイル開発にはなってないな」「そもそもなんでユーザーストーリーがアジャイル開発に必要なんだろう」

こんな悩みや疑問をお持ちではないだろうか。

筆者の場合は、以前の職場でユーザーストーリーを作っものの、それがその後の開発プロジェクトに生かされないといった経験があった。そのため、「アジャイル開発においてユーザーストーリーって意味あるのかな」と疑問に思ったことが数多くあった。

この記事では、そんな同じ悩みや疑問を持っている方のためにアジャイル開発におけるユーザーストーリーについて、以下の観点から詳細に解説していく。
・どういう定義か
・どういう目的があるか
・どんなメリットがあるか
・ユーザーストーリーの例と作り方
・効果的なユーザーストーリーに含まれる要素
・ユーザーストーリーのテンプレ
・ユーザーストーリーの効果的な使い方
・ユーザーストーリーを作るのは誰なのか

それではさっそくみていこう。

１　ユーザーストーリーとは＝ユーザ視点で「ソフトウェアで実現したいもの」を書いた短い文章

ユーザーストーリーとは以下のようなものだ。
・ユーザー視点で書かれた「ソフトウェアで実現したいもの」
・短く表現された文章

まずは、YouTubeの様な動画公開サイトの例を用いて、何がユーザーストーリーで何がそうではないのかを示す。

以下のようなものはユーザーストーリーに該当する。これはユーザー視点で書かれていて、なおかつ記載も簡潔である。

逆に、以下のようなものはユーザーストーリーではない。これは、ユーザー視点で書かれていないためだ。

また、以下のようなものもユーザーストーリーとしては適切ではない。なぜなら、記載が詳細すぎるためだ。

２　ユーザーストーリーがなぜ必要か＝必要なものを必要な時に必要なだけ分析できる状態を作るため

２−１　ウォーターフォールには２つのリスクがある。

そもそもユーザーストーリーは、ウォーターフォールが抱えている課題を解決するものとして位置付けるとわかりやすい。

ウォーターフォールでは要件や仕様の詳細を決めるのはプロジェクトの初期段階と決まっていた。そのため、「何ヶ月も先に開発するであろう物」全てについて、「必要になるであろうこと」を予想して詳細に分析する必要があった。

ここには、以下２つのリスクが存在している。
・何ヶ月か後に、本当に全ての要件を実現する必要があるかわからない（未来に対する不確実性）
・初期に行う分析の詳細さが、本当にこの後必要になるかわからない（足りないかもしれないし、詳細すぎるかもしれない）

例えば、企業のサステナビリティレポートの作成ツールを作っていた時のことだ。当時は、全ての要件をプロジェクトの最初に決めていた。

そのプロダクトでは、ユーザを管理者と作業者の二つの権限で管理することを想定していた。また、ざっくりと以下のツールの使われ方を想定していた。
・４月に、前の年度の定量的なデータを集める（管理者が作業者にデータの登録を依頼する）
　例）電気の使用量、水の使用量など
・上記のデータをもとにレポートを作る。（管理者と作業者の両方が行える）

そのため、要件定義の段階で「レポート作成機能」について管理者・作業者のそれぞれが行える操作を分けて考えていた。具体的には、レポートの章立てを変更できるのは管理者だけで、章の中身を作成・変更できるのが作業者という分け方をしていた。

しかし、プロジェクトが進み潜在顧客の業務への理解も深まってきたところ、レポートの作成は管理者だけが行えれば良いことが判明した。

この様に、プロジェクト開始当初に想定していた機能の形が、プロジェクトの進行と共に変化することはよくある。今回の例では要件が変わっただけだが、そもそもその機能はいらないという話になることだってある。

２−２　アジャイルのユーザーストーリーで、ウォーターフォールのリスクを解消する

ウォーターフォールがプロジェクトの初期で全部の要件を固めることから、以下の様なリスクがあった。
・何ヶ月か後に、本当に全ての要件を実現する必要があるかわからない（未来に対する不確実性）
・初期に行う分析の詳細さが、本当にこの後必要になるかわからない（足りないかもしれないし、詳細すぎるかもしれない）

これに対応するために、アジャイルだと要件を最初に全部細かく決めることはしない。その代わり、要件の大枠をユーザーストーリーで把握するまでにとどめる。その目的は以下を実現するためだ。
・必要なものを
・必要な時に
・必要なだけ分析できる状態を作る

そのため、「詳細に内容を詰めすぎない」ことが重要であり、個別のユーザーストーリーを「短く表現された文章」にする意識が大切だ。

３　ユーザーストーリーを特定するメリット３つ

この章ではユーザーストーリーを特定することによるメリットを以下の３つに分けて説明する。
・無駄な分析や文書化の工数が削減できる
・要求の変更に対して強い
・発注者と受注者で認識を合わせやすい

３−１　無駄な分析や文書化の工数が削減できる

まず、「無駄な分析や文書化の工数が削減できる」が挙げられる。

これは、ユーザーストーリーの目的である「必要なものを必要な時に必要なだけ分析できる状態を作る」と大きく関連している。

最初に要求を洗い出す際に、全ての要求を丁寧に分析するのではなく、ユーザーストーリーという形である程度漠然としたものに留めておく。そうすることで、プロジェクトの初期の段階で過剰に検討・文書化する工数を省くことができる。

一般的に、１行もプログラムを書かずに、全ての要求を開発で必要になるレベルで分析して定義することは不可能だ。実際、開発が進むにつれて、以下のようなことはよく発生する。
・要件定義で決められた内容が抽象的すぎて、その情報だけでは開発できない
・ある機能の要件定義の場合分けに不足があり、追加で当該パターンの要件を検討が必要になる

つまり、最初に全ての要求を綿密に分析し要件として定義するのは不可能である。そのため、要件定義、設計、開発でフェーズを分けてしまって、開発の期間を遅らせるよりも、どんどん開発を進めて都度必要な要件を必要なレベルで詰める方が生産性が高い。

３−２　要求の変更に対して強い

次に、「要求の変更に対して強い」が挙げられる。

これも、ユーザーストーリーの目的である「必要なものを必要な時に必要なだけ分析できる状態を作る」と大きく関連している。

そもそも「要求の変更に対して弱い」という状況を分解すると以下のような状態が考えられる。
・要求リストは変更されない前提でプロジェクトの計画が立てられている
・要求リストの全てに対して、既に詳細な分析を実行してしまっている

一つ目の状態であれば、要求変更によって、プロジェクトの計画が大幅に狂ってしまうか、良くても計画の立て直しに相当な工数がかかることになる。

二つ目の状態であれば、変更要求によって、単純に分析の工数が無駄になってしまうことになる。

ユーザーストーリーという形で要求をある程度漠然としたものに留めておく。そのことによって、必要なものを、必要になった時に、必要なだけ分析するのでこれらの状態になる可能性が少ない。

３−３　発注者と受注者でコラボレーションを産むきっかけになる

最後に、「発注者と受注者でコラボレーションを産むきっかけになる」が挙げられる。

ユーザーストーリーは今後の開発物の大枠を決めるものである。そのため、網羅的にリストアップする必要がある。また、ユーザストーリーを特定できるのは、発注者であるビジネス側の担当者だ。

そのため、開発チーム（受注者）が発注者の開発プロジェクトへの関与を積極的に促すことができるチャンスである。ここで一緒にユーザーストーリーを特定する作業をすることで、受注者と発注者（開発者とビジネス担当者）が、率直に意見を言いやすい環境を作れる。

これをプロジェクトの最初の段階でできることに特に大きな意味がある。

４　【サンプル付き】ユーザーストーリーを作る３ステップ

この章では、ユーザーストーリーの作り方を以下の３ステップで紹介する。
・ペルソナの認識を合わせる
・いろんな図を書く
・とにかく書き出す

４−１　ペルソナの認識を合わせる

まずはなんといっても作業をする全員でペルソナの認識を合わせる必要がある。

例えば八百屋の例で言えば、こんなペルソナがあり得るだろう。

４−２　いろんな図を書く

次はとにかくたくさんの図を書く。例えば、フローチャートやシナリオ、プロセスフロー、システム概要図などを書いていく。

これらはシステムが動作した際に必要なモノをロールプレイ的に想像するのに役立つ。これらは次のステップでとにかく網羅的にユーザーストーリーを書き出すためのとっかかりになるモノだ。

今回は試しに、ペルソナの困りごとに関するユースケース図と、現在の平日と休日の夜の食事に関する行動をシーケンス図で表してみた。

４−３　とにかく書き出す

上記のペルソナやさまざまな図をもとにストーリーを書きだすのがこのステップだ。

まずは、粒度や原則などは気にせずとにかく出し切ってみる。その後に、洗練させていくという流れでやるのが良いだろう。

筆者が作ってみたのは以下の様なストーリーだ。

５　ユーザーストーリーはその後こう使われる

この章では、ユーザーストーリーがプロジェクトを通してどのように活用されるかを大きく以下の２つのフェーズに分けて解説する。
・プロジェクトの初期段階
・イテレーション中（プロジェクトで開発が始まってから）

５−１　【プロジェクトの初期段階】各ストーリーに見積もりをして優先順位づけする

プロジェクトの初期段階においては、作ったユーザーストーリーは以下の２つの目的で利用する。
・プロジェクトの完了目安を把握するため
・予算や締切などの制約をもとに、開発の優先順位を決定する

プロジェクトの完了目安を把握する
まずは、ストーリーが出揃ったらそれに対して見積もりを行う。この際、見積もりは精緻に行うのではなく、ざっくりと相対的な見積もりを行う。よく使われるのはストーリーポイントだ。

例えば、地元の八百屋さんがシステムを開発しようとしてる場合は以下のようになる。

この表では合計のストーリーポイントが１００になっている。例えば、ストーリーポイント５のものを開発し、リリースできる状態にするのに１スプリント（開発サイクルのこと）かかると仮定しよう。さらに、このチームでは１スプリントを２週間としていたとしよう。その場合は、このプロジェクト全体を完了するまでに２０スプリント、４０週間必要になることがわかる。

予算や締切などの制約をもとに、開発の優先順位を決定する
次に行うのはストーリーに優先順位をつけることだ。

前のステップで、プロジェクト全体で必要なスプリント数が把握できた。しかし、大抵のプロジェクトでは、「必須」以外の「あったらいいな」レベルのものも含めると、プロジェクト期間内に全てのストーリーを完成させることはできない。

そのため、ストーリーに優先度をつけて重要なものから順に対応していくのだ。

例えば先ほどの地元の八百屋さんの例で言えば、以下のような優先度づけを行うことができる。

５−２　【イテレーション中】ストーリーをリリース可能な状態にするために必要なだけ詳細を分析する

プロジェクトで開発が動き始める段階（イテレーション中）では、順次ユーザーストーリーをリリース可能な状態に変更していく。そのために、内容を詳細に分析し、要件を決めていく。

ここでいう、分析の対象になるストーリーは以下のどちらかである。
・そのイテレーションでリリース可能な状態にしようとするストーリー
・次のイテレーションで開発が始まるストーリー

６　良いユーザーストーリーに含まれている６つの要素

ユーザーストーリーには決まった形式というものは存在しない。なぜなら、ユーザ視点で簡潔な言葉で書かれてさえいればOKだからだ。

しかし、良いユーザーストーリーには次の６つの要素が含まれている。その６つの頭文字をとってINVESTと呼ばれる。

独立している（Independent）
ストーリー間で依存関係がない状態のことだ。これによって、優先度やトレードオフを検討しやすくなる。依存関係があると優先度をつける際に、単純な機能のビジネス的な価値だけでは判断できなくなる。

例えば、以下はこの原則に反している。

ユーザーとして、SNSアカウントでのログイン後、友達と共有したい記事をタイムラインに投稿したい。なぜなら、友達と情報を共有するのが楽しいからだ。

以下のストーリーが混在しているからだ。
・記事の投稿ができる
・記事を投稿すると友達と共有できる
・SNSログインができる
・SNSログインをすると友達と自動で繋がれる

交渉可能である（Negotiable）
実現方法が具体的に指定されておらず、ある程度融通がきく状態のことだ。

例えば、以下はこの原則に反したストーリーの例だ。

タスク管理アプリの利用者は、チームリーダーにタスクにアサインされた時に、メールで通知を受け取れる。

「メール」という限定的な方法論を指定しまっているのがよくないポイントだ。以下のようにするとより良くなる。

タスク管理アプリの利用者は、チームリーダーにタスクにアサインされた時に、アサインされた事実をすぐに把握できる

価値がある（Valuable）
ユーザーにとって価値がある状態になっていることだ。あくまでもビジネス的に価値がある状態を意識する必要がある。

例えば、以下はこの原則に反してテクノロジー寄りの表現でストーリーを書いた例だ。

機械学習を導入し、レコメンドエンジンを実装する

以下のようにするとより良くなる。

自分がよく見る動画に似ているかつ、サイト全体でもよく再生されている動画を教えてもらえる

見積もりができる（Estimable）
作業量を推定可能である状態のことだ。なぜなら、作業量が推定できないストーリーは完了までの期間が想定できず、結果としてプロジェクト全体のスケジュールに悪影響を及ぼしてしまう。

例えば、以下はこの原則に反したストーリーの例だ。

ウェブサイトを構築する。

小さい（Small）
短時間で完了できるサイズである状態のことだ。これは一つ上の見積もりができるかと大きく関連している。なぜなら作業単位が大きければ大きいほど、作業内容が想像しづらく、開発工数のぶれも大きくなるからだ。

例えば、以下はこの原則に反したストーリーの例だ。

管理者として、サイトの全てのデータをバックアップ・復元できるようにしたい

なぜなら、バックアップと復元の両方の大きな機能が1つのストーリーにまとめられているからだ。

テストできる（Testable）
期待される動作が明確になっている状態のことだ。例えば、以下はこれに反している例だ。

管理者として、ウェブサイトのロード時間が「速い」ことを確認したい。

「速い」という基準が曖昧であり、具体的な秒数や基準が不明なためテストができないからだ。これが「ページのロードが1秒以内」であればこの原則をクリアしていることになる。

７　ユーザーストーリーのテンプレ：「誰が」「何をしたいのか」「その理由は〜〜だからだ」

この章では、ユーザーストーリーのテンプレを紹介する。

前章で、ユーザーストーリーに決まった型はないと述べた。その上で、良いユーザーストーリーが含んでいるべき６つの原則を紹介した。しかし、原則が６つだと案外多くて困惑しているかもしれない。

そこで、以下のテンプレを使ってみて欲しい。「誰が」「何をしたい」「その理由は」という流れで文章を書くだけだ。

このテンプレの利点は「誰が」「何を」「なぜ」という重要な３つの視点が入っている点だ。これで状況がより鮮明になるので、ユーザーストーリーを見るだけでもプロジェクトないで認識を共通化しやすい。

しかし、その反面記述が多少冗長になってしまうという欠点もある。

そこで、タイミングによってストーリーの書き方を柔軟に切り替えることをお勧めする。

プロジェクトの初期段階でストーリーを洗い出すタイミングでは、原則も何も考えずに網羅的に出し切ることに専念すると良いだろう。

そして、イテレーション中などのストーリーを分析するタイミングになったら、このテンプレや原則を意識した書き方にして精緻化していくというやり方もあり得る。

８　ユーザーストーリーは開発チームがビジネスの担当者を巻き込んでおこなう

ユーザーストーリーを作る際は、開発チームはビジネスの担当者を積極的に巻き込んで行うべきだ。

一般的に開発チームがユーザーストーリーを作成することが多い。しかし、発注者やビジネス側の人には積極的に関わってもらう必要がある。なぜなら、ストーリーを一番理解しているのは発注者やビジネスの担当者だからだ。

そのため、ビジネスサイドの人からストーリーをどんどん引き出していく必要がある。その際に使えるのが、４章でも紹介した手順だ。特に、いろいろな図を書くことをお勧めしたい。これによってより具体的なシステムの利用イメージが持てるため、いろんな角度からストーリーを抽出することができる。

まとめ

アジャイル開発におけるユーザーストーリーについて以下の観点に基づいて説明してきた。
・どういう定義か
・どういう目的があるか
・どんなメリットがあるか
・ユーザーストーリーの例と作り方
・効果的なユーザーストーリーに含まれる要素
・ユーザーストーリーのテンプレ
・ユーザーストーリーの効果的な使い方
・ユーザーストーリーを作るのは誰なのか

筆者はユーザーストーリーは開発プロジェクトの無駄を大きく省いてくれる有効な手段だと確信している。

そのため内容がボリューミーなので一発で理解するのは難しいかもしれないが、何度も読み返して知識を自分のものにして欲しい。

この記事が読者の方のアジャイル開発の習熟に寄与できると嬉しい。