見出し画像

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

これまで何度か登場してきたユーザーストーリー。今回は、これを主役にしてみます。
ユーザーストーリーとは、「(ユーザーの)誰が」「何を」「なぜそれをするのか」を簡潔に記述する手法です。

ユーザーストーリーの目的と意義

  1. チームの共通認識が育つ
    ユーザー目線で、ユーザー要求を簡潔に表現することで、顧客の求めていることが明らかになり、それがチーム全員に共有されます。

  2. タスクの優先順位付け
    各タスクがどのように価値を生むのかが明確になり、タスクの優先順位付けが根拠をもって行えるようになります。

  3. 透明性が高くなる
    仕様変更の依頼がユーザーからあった場合でも、、ストーリーを見直すことで適切な判断が取れるようになります。

  4. 明確化
    複雑なタスクを分解し、シンプルに整理できるため、課題を見つけやすくなります。


誰が、いつ、どのように作るべきか?

ユーザーストーリーは、プロジェクトの初期段階にまず初案として作られます。これは、業務担当者、部署リーダーと、ステークホルダー(上司、クライアント)が一堂に会し、ワークショップ形式で作成します。

作成の基本的ルールは以下の通りです。

  1. シンプルに記述する
    定型のフォーマットを使用し、専門外の人でも理解できる平易な言葉で書きます。

  2. 定期的に確認する
    初案作成後、業務が進む過程でも、目標や内容などにぶれが生じていないか、定期的に再確認します。

ユーザーストーリーのフォーマット

「[誰]として、[何を]したい。それは[なぜ]か。」
誰として: 利用者の役割(例:顧客、スタッフ、管理者)
何を: 達成したい具体的な行動やタスク
なぜ: その行動の目的や価値


ユーザーストーリーの良い例と悪い例

良い例

「チームリーダーとして、新しいプロジェクトの進捗状況リアルタイムで把握したい。なぜなら、遅れを防ぎ、早めに対策を講じるためだ。」

この例では、誰が(チームリーダー)、何を(進捗状況の把握)、なぜ(遅れの防止)が明確になっています。

悪い例

「プロジェクト管理を改善する。」

この例では、誰が、何を改善するのか分かりません。また、その理由も書かれていません。


ユーザーストーリーの重要な基準:INVEST

ユーザーストーリーを的確に作成するためには、次の6つの基準(INVEST)を満たす必要があります:

I(Independent:独立性)
そのタスクは他のタスクに依存せず、単独で取り組める。
N(Negotiable:交渉可能)
一度決めたから変更は一切できないということではなく、適宜調整が可能。V(Valuable:価値がある)
そのタスクが成果や価値を生む仕事である。
E(Estimable:見積もり可能)
作業量が推定可能で、リソース計画を立てられる。
S(Small:小さい)
実行可能かつ短時間で完了できるタスクである。
T(Testable:テスト可能)
成果の達成基準が明確である。


日常業務への応用例とINVESTの適用

営業チームの効率化

「営業スタッフとして、1日に5件の潜在顧客に連絡を取りたい。それは、売上目標を達成するためだ。」

Independent: 他の業務と独立して完結。
Negotiable: 「5件」という具体数は必要に応じて調整可能。
Valuable: 売上目標の達成に直結する活動。
Estimable: 1件あたりの所要時間を見積もりやすい。
Small: 1日単位で管理可能なタスク。
Testable: 連絡を取った件数とその結果で確認可能。


新人教育の改善

「新入社員として、最初の1週間で基本業務を習得したい。それは、早く業務に慣れ、チームに貢献するためだ。」

Independent: 他の教育計画との依存関係がない。
Negotiable: 基本業務の範囲は進捗や状況に応じて調整可能。
Valuable: 新人が早期に戦力化。
Estimable: 1週間という具体的な期間。
Small: 習得内容をさらに小さな単位に分割。
Testable: カリキュラムの学習完了が確認できる。


専門用語は排除しよう

悪い例1:システム開発

「バックエンドエンジニアとして、リアクティブなノンブロッキングI/Oモデルを実装したAPIゲートウェイが欲しい。そうすれば、スループットを最適化しつつレイテンシを最小化できるから。」
→ 「リアクティブ」「ノンブロッキングI/O」「スループット」など開発部門以外の人ではわからない内容になっている。

良い例1:システム開発

「システム管理者として、データのやり取りを迅速にできる仕組みが欲しい。そうすれば、システム全体がよりスムーズに動き、利用者を待たせることが減るから。」
→ 理由: 専門用語を排除し、目的や成果を簡潔に説明しています。


悪い例2:マーケティング

「マーケティング担当者として、リードスコアリングアルゴリズムを実装して、MQLのコンバージョン率を上げたい。そうすれば、トップオブファネルからボトムオブファネルへの流れを最適化できるから。」
→ 問題点: マーケティングに詳しくない人には、「リードスコアリング」「MQL」「ファネル」などの用語が意味不明。

良い例2:マーケティング

「マーケティング担当者として、重要な見込み顧客を自動で判別できるツールが欲しい。そうすれば、本当に必要な人に集中してアプローチできるから。」
→ 理由: 誰にでもわかる言葉で、価値も明確です。

専門用語を避け、簡単で共通理解可能な言葉を選ぶことで、全ての関係者がプロジェクトに貢献できるようになります。
特に非専門家が多い場では、シンプルで親しみやすい言葉が成功の鍵です。


ユーザーストーリーの後工程への影響

よくできたユーザーストーリーは、後工程にも大きな影響を与えます。

  • 設計工程:
    必要な機能がユーザー視点で明確になり、スムーズに設計が行えます。

  • 実装工程:
    開発者が目的を正しく理解し、顧客ニーズにあった開発ができます。

  • テスト工程:
    これ自体がテストスクリプトになります。

  • 運用工程:
    ユーザーが求めた価値が提供でき、顧客満足度が向上します。


ユーザーストーリーをシンプルかつ明確にすることで、関係者全員が共通の目的に向かって進める環境が整えられます。
良いストーリーはプロジェクト全体をスムーズに進行させる基盤となり、手戻りリスクを減らす効果があります。


いいなと思ったら応援しよう!