ユーザーストーリーとは｜ビジネスサイドのための IT 用語集

 ユーザーストーリーとはユーザーストーリーはシステムにしてほしいことを、利用者の視点で短く整理した記述です。誰として、何をしたいか、何のためかの3点を示す形式が一般的で、付箋やカード、開発管理ツールの作業1件として管理されます。たとえば次のとおりです。
地域担当の営業マネージャーとして、地域ごとの月次売上を比較したい。支援が必要な地域を特定するためです。
最初の記述では画面構成や表示項目を必要以上に固定しません。重要な制約は早めに確認し、詳細は開発開始が接近するにつれて、開発チームとの会話や例で具体化します。
要件定義書が要件の全体を文書化するのに対し、ユーザーストーリーは要件を計画しやすい規模に分割した単位です。1件は通常は1人で数日かかり、1回の開発期間に複数件含まれる程度が目安とされています。
建築なら間取り図の代わりに、朝の混雑を避けるため洗面台を2か所にしたいと要望し、配置は設計者と相談する進め方に近いです。
 なぜ必要か要件を最初に長い文書で網羅すると、確実になったという錯覚が生じやすいうえ、詳細を書き足しても、開発を開始してから認識の違いが明らかになる場合があります。詳細の一部は開発前に変化するか、開発されないこともあります。
ユーザーストーリーは長い仕様書の代わりに会話を中心にした要件の伝え方として考案され、短い期間の反復で開発するアジャイル開発で広範に使用されています。詳細を先送りするため、ストーリーには次の3つの要素がすべて必要とされています。
カード: 何の話かを示す短い記述
会話: 利用者の目的、例外、業務の規則を、意思決定できる人と開発チームが対話して具体化すること
確認: 完成と判定する条件。完成条件、受入条件とも呼び、完成したものを確認する受入テストの項目になる
 効果計画と優先順位の判断を件単位で実施できる。未開始のストーリーは詳細と優先順位を後から変更できる
画面の案ではなく目的で議論できる。目的が記述できない機能は必要性を再検討する合図になる
完成条件があればできたかどうかを開発チームと事業側が同じ基準で判定できる
 コストとリスク会話での詳細の具体化に、意思決定できる人の時間が必要。アジャイル開発の枠組みであるスクラムでは、開発する候補を優先順に列挙した一覧をプロダクトバックログ、その順序の責任者をプロダクトオーナーと呼ぶ。プロダクトオーナーは1人で、組織全体がその決定を尊重する前提
全体像を把握しにくい。一覧が長いと範囲や費用を確認しにくいため、利用者の行動の流れの順にストーリーを配置するストーリーマッピングなどで補完する
テストを自動で実行する仕組みであるテスト自動化の費用が必要。機能が増加するたびに過去の機能も再確認するため、小さな単位で追加する開発ではテスト自動化がほぼ必須
記録とバックログの維持が必要。仕様が変更されるたびに、完成条件、テスト、判断の理由を更新する。更新しないと改訂前の条件で完成を判定するおそれがある。バックログの詳細化も継続的な作業
記述できる人材が必要。要件分析の経験者が習得しやすいため、担当できる人がいなければ育成か採用が必要
 要件定義書がなくてもユーザーストーリーで開発してよいか機能の単位としてはユーザーストーリーで開発できます。ただし事業の目的、対象範囲の大枠、遵守すべき条件は、ストーリーとは別に用意する必要があります。ストーリーは要件を計画のために分割する単位で、全体を示す役目がないためです。スクラムでは目標とするプロダクトの将来の状態をプロダクトゴールとしてバックログに含め、バックログの各項目はそれを実現する内容として列挙します。
次の場合は開発前に別の記録や調査を用意します。
法令、監査、社内規程で、要件の文書を提出または保管する必要がある
既存システムの機能をそのまま新システムへ引き継ぐ。要件定義の前に現行システムを調査し、仕様を明確にする必要がある
複数の部署が関与する。関係する部署が最初に対象と対象外を記録して合意する
優先順位を決定する人が未定。担当と権限を先に定める
該当せず、使い方を確認しながら開発したい業務の機能なら、範囲と費用を最初から固定せず開発する選択もできます。
 どこまで記述すれば開発を開始してよいか開始直前のストーリーは1回の開発期間で完成でき、完成条件を具体的に説明できる状態を目安とします。先の予定のストーリーは優先順位が低いほど粗いままでも問題ありません。
 合意と確認冒頭の例では売上の計上日と契約日のどちらで月を決定するか、地域への帰属は営業所と顧客のどちらの所在地か、売上のない地域をどう表示するかを開発チームと事業側が開発前に合意します。合意した内容は次のような完成条件にします。説明用の例です。
選択した月の地域別売上が合意した集計規則と一致する
担当外の地域の売上は表示されない
売上のない地域は0円と表示される
開始の可否は次の3点で確認します。
誰のどの目的かを1文で説明できる
完成条件を具体的に記述できる
開発チームの見積もりで、1回の期間以内に終了できる。規模の判断は開発者の責任で、他システムの変更待ちやデータ準備の未完了がないことも条件になる
 スプリントと分割スクラムの固定の開発期間をスプリントと呼び、長さは1か月以内です。開発とテストに数週間を超えてかかる大きなストーリーは、一般にエピックと呼ばれ、可能なら分割します。分割は画面と集計処理のように技術の層だけで分割せず、利用者が結果を確認できる単位にします。冒頭の例が1回の開発期間で完成できないなら、1か月分の一覧、月ごとの推移、前年同月との比較の順に分割します。
スクラムではスプリントの対象とする項目は開発者がプロダクトオーナーとの相談を通じて選択します。
 性能や安全性のような条件はどこに記述するか全体にかかる条件は個別のストーリーに分散させず、全ストーリーに共通する品質の基準である完成の定義に記載します。特定の機能にだけ関係する条件は、そのストーリーの完成条件に記述します。
性能、安全性、停止してよい時間のように、機能ではなく性質に関する条件を非機能要件と呼びます。設計の選択肢を限定する制約として、ストーリーの形で記述できます。求める人と目的を記載しないと、後から理由が分からなくなるおそれがあります。たとえば既存のデータベースを使用するとだけ記録すると、別のデータベースを作成するおそれがあります。
完成条件はそのストーリーの振る舞いを確認する基準です。スクラムでは完成の定義を満たさない項目は公開も、スプリントの成果を確認するスプリントレビューでの提示もできません。個別に記述すると条件を記述しなかったストーリーが条件を満たさないまま完成するおそれがあります。同時に利用する人数、個人情報の管理、停止してよい時間帯のような全体の条件は、機能ごとには確認できないため、システム全体での確認を別に計画します。
 よくある誤解 1文記述すれば仕様になる記述された1文は要件そのものでなく、会話の合図です。要件は会話や例、規則、テストを通じて明らかになります。合意した振る舞いは完成条件に記述し、判断の理由はストーリーから参照できる形で記録します。
 機能一覧をストーリーの型に変換すれば十分要件文書の章立てから機械的にストーリーを作成するのは、典型的な失敗です。画面やボタンだけの項目はストーリーではなく、目的が記述されていなければ、形式だけの機能一覧です。調査や技術的な改善のように、ストーリーの形にしないほうが明確な項目は、ストーリーにしなくても問題ありません。
 誰としての欄に利用者と記述すれば利用者の視点になる誰としての欄に利用者とだけ記述した例は、利用者も目的も曖昧な不十分な例として示されています。冒頭の営業マネージャーのように、利用者を具体的に記述します。プロダクトオーナーは利用者ではないことが多いため、事業側の担当者の視点だけで記述すると、実際の利用者の目的が欠落することがあります。