ユーザーストーリー | 例とテンプレート

ユーザーストーリーは、「ペルソナ + ニーズ + 目的」としてよく表される開発タスクです。

Max Rehkopf Max Rehkopf
Browse topics

ユーザーストーリーは簡潔に言えばソフトウェアのシステム要件であると思われがちですが、実際はそうではありません。

アジャイルソフトウェア開発で重要なのは、人を第一に考えることです。ユーザーストーリーでは、実際のエンドユーザーを中心に考えます。ストーリーでは、開発チームとその作業に関連するコンテキストを伝えるため、技術的な用語の使用を避けます。ユーザーストーリーを読んだチームは、自分たちが何のためにどのような仕事をしているのか、そしてそれによってどのような価値が生み出されるのかを理解できます。

ユーザーストーリーはアジャイルプログラムの主要な要素であり、ユーザーを重視し、コラボレーション、創造性、製品の総合的改善を推進する日常業務のフレームワークの構築に役立ちます。

アジャイルのユーザーストーリーとは

ユーザーストーリーは、アジャイルフレームワークの最小作業単位です。これは機能ではなく、ソフトウェアユーザーの視点に基づく最終目標です。

ユーザーストーリーの目的は、作業によって特定の価値をカスタマーに提供する方法を示すことです。「カスタマー」は、従来のように外部のエンドユーザーを指すとは限りません。内部の利用者やチームの同僚を指す場合もあります。

ユーザーストーリーとは、目指す成果を簡潔に記述したものです。詳細は記載されません。要件は、チームで合意された後に追加されます。

ストーリーは、スクラムやカンバンと同様にアジャイルフレームワークにぴったりと適合します。スクラムでは、ユーザーストーリーがスプリントに追加され、スプリントの期間にわたって「バーンダウン」されます。カンバンチームはユーザーストーリーをバックログに取り込み、ワークフローを適用します。ユーザーストーリーをこのように処理することで、スクラムチームによる見積もりとスプリント計画が改善され、予測の精度とアジリティが向上します。ストーリーにより、カンバンチームは進行中の作業 (WIP) の管理方法を学び、ワークフローをさらに改善できます。

ユーザーストーリーは、エピックやイニシアチブなど、より大きなアジャイルフレームワークのビルディングブロックでもあります。エピックは一連のストーリーに分割される大きな作業項目であり、複数のエピックがイニシアチブを構成します。これらの大きな構造により、(店舗の) 開発チームの日常的な作業を、エピックやイニシアチブに組み込まれた組織目標の達成につなげることができます。

エピックとイニシアチブの詳細を見る

アジャイルのエピック、ストーリー、テーマ | アトラシアンアジャイルコーチ

ユーザーストーリーを作成する理由

アジャイルになじみのない開発チームにとって、ユーザーストーリーは追加のステップのように感じられるかもしれません。大きなプロジェクト (エピック) を一連のステップに分割するだけでよいのでは、と思う人もいるでしょう。しかし、ストーリーはチームに重要なコンテキストを提供し、タスクとそれがもたらす価値を関連付けます。

ユーザーストーリーには、以下のような重要なメリットが数多くあります。

  • ストーリーはユーザーに焦点を当てます。ToDo リストのおかげで、チームは実行する必要があるタスクに集中できます。一方、ストーリーをまとめることによってチームは実際のユーザーが直面している問題の解決に集中できます。
  • ストーリーはコラボレーションを実現します。最終目標を定義することで、ユーザーに最善のサービスを提供し、目標を達成する方法をチームが協力して決定できます。
  • ストーリーはクリエイティブな解決策を生み出します。ストーリーにより、最終目標の達成に向けた最善の解決策をチームが冷静かつクリエイティブに考えられるようになります。
  • ストーリーは勢いを生み出します。ストーリーを 1 つずつクリアすることで、開発チームは小さなチャレンジと成功を味わうことができ、それが勢いにつながります。

ユーザーストーリーの処理

作成されたストーリーは、ワークフローに統合します。通常、ストーリーはプロダクト所有者、プロダクトマネージャー、またはプログラムマネージャーによって作成され、レビュー担当者に送信されます。

スプリントまたはイテレーション計画ミーティング中に、チームはスプリントで処理するストーリーを決定し、各ユーザーストーリーで必要とされる要件と機能について話し合います。それにより、ストーリーを技術と創造性によって実現できるようになります。合意された要件は、ストーリーに追加されます。

このミーティングのもう 1 つのステップが、複雑さや完了までの所要時間に基づくストーリーのスコア決定です。チームは T シャツサイズ、フィボナッチ数列、またはプランニングポーカーを使用して適切な見積もりを行います。ストーリーは 1 つのスプリントで完了できる規模にする必要があります。そのため、各ストーリーの詳細を決定するチームは、指定された完了期間を超過するストーリーがあれば必ず分割します。

ユーザーストーリーの作成方法

ユーザーストーリーの作成時における考慮事項は、次のとおりです。

  • 「完了」の定義 — 一般的に、ストーリーは規定されたタスクをユーザーが完了した時点で「完了」しますが、その条件を必ず定義する必要があります。
  • サブタスクまたはタスクの規定 — 完了する必要がある具体的なステップと、各ステップの責任者を決定します。
  • ユーザーペルソナ — 対象者を確認します。エンドユーザーが複数いる場合は、複数のストーリーの作成を検討します。
  • ステップの順序付け — 大きなプロセスの各ステップに対するストーリーを作成します。
  • フィードバックの確認 — ユーザーと話をして、問題やニーズを直接聞き出します。カスタマーからストーリーを引き出せれば、ストーリーを推測する必要がなくなります。
  • 所要時間 — 所要時間は扱いにくい事項です。多くの開発チームは、所要時間について話し合うこと自体を避け、独自の見積もりフレームワークに頼っています。ストーリーは 1 つのスプリントで完了できる必要があるため、完了まで数週間または数か月かかる場合はより小さなストーリーに分割するか、独立したトピックとみなす必要があります。

ユーザーストーリーが明確に定義されたら、必ずチーム全体に対して可視化します。

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

ユーザーストーリーの多くは、以下のような構造のシンプルな文で表されます。

「私が [ペルソナ] なら、[希望] を実行することで [目標] を達成したい。」

詳細 : 

  • 「ペルソナ」: 作業の対象は誰ですか? 人の肩書きだけではなく、ペルソナを考慮する必要があります。この作業の対象は Max です。チームで、Max について共通の理解を持つ必要があります。Max に何度もインタビューをするのが理想です。この人物がどのように行動し、考え、何を感じるのかを理解します。Max の気持ちになって考えます。
  • 「希望」: ここには、使用される機能ではなく、使用する人の意図を記載します。この人物は実際に何を望んでいるのでしょう? この文には、実装される機能が記載されているべきではありません。ユーザーの望みではなく、UI の一部が記載されている場合、焦点がずれています。
  • 「目標」: 今すぐ何かをしたいという希望は、より大きな目標の達成にどのようにつながるのでしょう? どのような総合的メリットを達成しようとしていますか? 解決すべき大きな問題は何でしょう?

たとえば、ユーザーストーリーは次のようになります。

  • 私が Max なら、友人を招待することでこのサービスを一緒に楽しみたい。
  • 私が Sascha なら、自分の作業を整理することでもっと状況をコントロールできていると感じたい。
  • 私がマネージャーなら、同僚の進捗を把握することで成功と失敗をより正確にレポートできるようになりたい。

この構造は必須ではありませんが、完了の条件を定義するのに役立ちます。ペルソナが希望する価値を得ることができれば、ストーリーは完了します。チーム独自の構造を定義し、それに従うことをお勧めします。

アジャイルユーザーストーリーの概要

ユーザーストーリーは、開発チームメンバーが日常的な作業を行う理由とその背景を記述したもので、一般的にペルソナ + ニーズ + 目的として表現されます。チームが何を実現しようとしているのかだけでなく、その理由や背景も理解することが、プロセスを円滑に進める上で重要です。

まず、次のプロジェクトか、最も急を要する大きなプロジェクト (エピックなど) を評価します。それをより小さなユーザーストーリーに分割し、開発チームとともに精査します。ストーリーがチーム全体に公開されたら、作業を開始できます。

Up Next
Estimation