「お客様は常に正しい。」このモットーは小売業界でしばしば異議を唱えられますが、アジャイルプロジェクトにおいては覚えておいて損はありません。 実際、顧客満足度はアジャイルマニフェストで最優先事項として挙げられています。
アジャイル手法では、開発プロセスにユーザーフィードバックを含めるのが一般的です。 アジャイルチームはこの外部視点を歓迎し、正しい方向を進み、かつ最終的な成果物が顧客のニーズに合致するように努めます。
プロジェクトをアジャイル作業構造に分解する際、チームは顧客の視点を探ることから始めます。 これは通常、ユーザーストーリーを作成することによって行われます。
この記事では、ユーザーストーリーとは何か、書き方、メリット、デメリットなどをすべて説明します。 アジャイルプロジェクトを最初から最後まで管理できるように、アジャイルプロジェクトプランテンプレートも共有します。
アジャイルプロジェクトに堅牢なソフトウェアシステムを利用し、全てのアジャイルワークフローを一元管理したい方は、Wrikeの無料トライアルにぜひお申し込みください。
ユーザーストーリーとは？
ユーザーストーリーは、特定のユーザーのニーズの説明と、アジャイル開発ライフサイクル内でそのニーズがどのようにして満たされるかを短くまとめて記述したものです。 これらのストーリーは、エンドユーザーに焦点を当て、一般の人にも理解しやすい言葉で書かれています。
各ユーザーストーリーには短い形式のリクエストがあり、これは、1つのアジャイルイテレーションまたはスプリントで完結するもので、通常は1〜2週間続きます。 チームはストーリーポイントを使用してユーザーストーリーの複雑さを測定しますが、これは特定のリクエストにかかる時間を正確に見積もる際に役立ちます。
アジャイルのユーザーストーリーコレクション は「エピック」と呼ばれています。 エピックの管理は製品オーナーが担当しますが、ユーザーストーリーの記述については、アジャイル開発チームのメンバーであれば誰でも行えます。
ユーザーストーリーはユースケースに似ていますが、詳細ではありません。 前者は計画されたアクションアイテムの非常に簡潔な説明であり、後者には、満足条件、ユーザーが製品を使用してたどるかもしれないさまざまな経路、ワークフロー図などといった追加セクションが含まれる可能性があります。
すべてのアジャイルプロジェクトをシームレスに実行
アジャイルにおけるユーザーストーリーの歴史
アジャイルの背景を見て、ユーザーストーリーがどのように始まったかを理解しましょう。
2001年、ソフトウェア業界で働く17人の独立した考えを持つ者がアジャイルアライアンスとして集まり、アジャイルマニフェストを発表しました。 このドキュメントには12の原則があり、以下は第1の原則です。
「最優先すべきは、価値のあるソフトウェアを早期に提供し、その後も提供を継続することで、顧客を満足させることである。」
ユーザーストーリーではこの原則を拡大解釈して、エンドユーザーの重要性とその期待を満たすことを強調します。
スクラムとエクストリームプログラミングは、アジャイル手法に分類される2つのフレームワークです。
スクラム
スクラムの概念は1990年代に生まれていましたが、2002年になってようやく、マイク・コーン、エスター・ダービー、ケン・シュウェーバーによってスクラムアライアンスが設立されました。
このフレームワークでは、スクラムマスターが小グループを成功に導きます。 スクラムチームは通常、ユーザーストーリーに取り組みながら、2週間のスプリントサイクルで作業します。 これらの小さな作業単位は、スプリントや日々のスクラムミーティングの指針となります。
エクストリームプログラミング（XP）
XPの歴史も1990年代にさかのぼります。ケント・ベックによって設立され、後にウォード・カニンガムとロン・ジェフリーズによって開発されました。
アジャイルアライアンスによると、ユーザーストーリーは実際にはXPフレームワーク内で生まれたもので、プロジェクト計画では「ゲームピース 」と表現されていました。 XPは、短い作業スプリント、絶え間ないイテレーション計画、利害関係者との徹底的なコラボレーションに重点を置いており、自分が何を望んでいるのかわからない顧客に遭遇した場合に最適です。
ユーザーストーリーの例
では、ユーザーストーリーの必然的な結果について考えてみましょう。 アジャイルアプローチでは、ユーザーストーリー形式は非常にシンプルで、特定の要件の「誰」、「何」、「なぜ」を簡潔に説明します。
- 何かを欲しがっているのは誰か？
- 彼らが欲しがっているのは何か？
- 彼らがそれを欲しがっているのはなぜ か？
このユーザーストーリーテンプレートをご覧ください。このテンプレートでは、上記の3つの要素が簡潔に1文で表現されています。
「[ペルソナ] として、[アクション] をし、[利益 ] できるようにしたい。」
各ストーリーにおいて、書き手は、ユーザーペルソナ、実行したいアクション、または持ちたい能力、最終的に獲得したい利益を書き込みます。 ここで、3人の多様なペルソナに適用されたユーザーストーリー の例をいくつか示します。
例1：オンラインゲーマー
「オンラインゲーマーとして、マルチプレイヤーオプションを手に入れ、友達とオンラインでプレイできるようにしたい。」
例2：設計チームリーダー
「設計チームリーダーとして、アセットを整理し、複数のクリエイティブプロジェクトを把握できるようしたい。」
例3：eコマースの買い物客
「eコマースの買い物客として、検索をフィルタリングし、より良い商品を素早く見つけたい。」
これで、ユーザーストーリーの例がどのようなものか明確になったので、ユーザーストーリーの作成に取り掛かりましょう。
ユーザーストーリーを書くための5つのステップ
ユーザーストーリー作成に関して実用的なアドバイスが必要ですか？ 次の 5 つのステップを参考にしてください。
ステップ1：合格基準の概要
完了の定義とは、ユーザーストーリーが完了したと見なされるために満たす必要がある一連の基準です。 特定の合格基準を定義し、チェックリストとして使用します。
ステップ2：ユーザーペルソナの決定
アンケートを作成する、フォーカスグループを主催する、またはユーザーフォーラムを読むことによって、広範囲に渡ってユーザー調査を実施します。 データを分析してパターンを検索し、重要なペルソナを特定します。
ステップ3：タスクの作成
管理しやすくするために、ストーリーを分割して多数のタスクにします。 ストーリーが複雑な要件である場合は、サブタスクを追加することもできます。 詳細な説明を含めると、各タスクの必要事項に対する認識をチーム内で擦り合わせることができます。
ステップ 4：ストーリーのマッピング
ユーザーストーリーマッピングを使用して、大規模なプロセスの作業を構造化します。 この場合、ストーリーは順序付けられたステップの形になります。
ストーリーマップの作成には、手書きのメモや、インデックスカード、プロジェクト管理ソフトウェアを使用できます。
ステップ5：フィードバックのリクエスト
ユーザーや見込み客に話しかけ、彼らの望むものを見つけます。 既存の製品についての意見や、新機能についての提案があれば聞いてみましょう。 そのフィードバックをユーザーストーリーに盛り込みます。
ユーザーのフィードバックはユーザーストーリーに盛り込むことができるので、ユーザーの視点を考慮することは非常に重要です。
優れたユーザーストーリーにするには？
これで、アジャイルユーザーストーリーが完成し、レビューの準備が整いました。 アジャイルチームを招集し、 INVEST の頭字語を使ってストーリーの質を評価します。 頭文字の意味は以下の通りです。
- Independent（独立している）：対象のユーザーストーリーは、その他のすべてのユーザーストーリーから独立している必要があります。 それぞれのストーリーには相互の関連性はないため、どのストーリーから評価を行っても構いません。
- Negotiable（交渉が可能）：ユーザーストーリーには、顧客と製品オーナー間の交渉を奨励し許容できるだけの十分な柔軟性が必要です。
- Valuable（価値がある）：対象のユーザーストーリーはどのような価値をもたらしますか？ もし価値も望ましい機能も見つからない場合は、ストーリーを完成させてはいけません。
- Estimable（見積もりが可能）：効果的に時間を管理できるようにするには、ユーザーストーリーの作成にかかる時間の見積もりが可能である必要があります。
- Small（小規模）：ストーリーは、1つのスプリント内で完成できるほどの小さなものでなければなりません。
- Testable（テストが可能）：ユーザーストーリーは、品質保証基準に沿ってテストを受け、かつ、受け入れテスト（例：ベータテスト）を通じて承認を得ることができるものでなければなりません。
ユーザーストーリーがINVESTチェックリストを満たしていない場合は、書き直すかエピックから削除する必要があります。 チェックリストを満たしていれば、チームメンバーは作業に取りかかることができます。 日次アジャイルミーティングを予定し、その中で、作業の進捗を確認し、スプリント期間内でのユーザーストーリーの完成を目指して予定通りに作業が進んでいるか評価します。
大きなストーリー と小さなストーリーの比較
チームに大きなユーザーストーリーを推奨すべきか小さなものを推奨すべきか迷ってはいませんか？ 大きなストーリーは情報量が多い一方、小さなストーリーには次のような重要なメリットがあります。
- フォーカス：小さなストーリーでは焦点が絞られるため、大きなストーリーのように大量の詳細情報に圧倒されることはありません。 小さなストーリーは無駄を省けるので、チームの連携が強化され、作業が迅速になります。 常に短く簡潔に仕上げましょう！
- リスク軽減：ストーリーが大きければ大きいほどリソースがより分散されるので、アジャイルスプリントの終了までに成果物が得られない可能性が高くなります。 例えば、チームのストーリーを完成させることができるのは特定のスキルセットを持つ開発者のみという場合があります。 しかし、それらを小さなストーリーに分解すればチームメンバーの疲弊を防ぐことができます。
- 透明性：ユーザーストーリーが小さいほど、チームは進捗の確認・追跡をしっかりと行うことができます。 大きなストーリーにはさまざまな不確定要素があり、日常の簡単な打ち合わせや関係者とのミーティングの中で、プロジェクトの進行状況を伝えるのが難しくなります。
ユーザーストーリーのメリット
そもそも、なぜユーザーストーリーを書くのでしょうか？ アジャイルプロジェクトに対するメリットが多いからです。 具体例をいくつか紹介します。
- 簡易的な形式：ユーザーストーリーは、具体的で、分かりやすい言葉で書かれています。 これにより、混乱がなくなり、顧客が何を求めているのかを把握しやすくなります。
- 柔軟性と創造性の向上：ユーザーストーリーでは詳細な技術的要素は扱わないため、状況の変化に合わせて柔軟に内容を変更できます。
- コラボレーションの改善：チームメンバーが1つの目標を目指す場合、しっかりと協力して取り組み、他のプロジェクト関係者と容易に連携することができます。
ユーザーストーリーを書くことの利点はたくさんありますが、製品マネージャーは潜在的なデメリット点も考慮する必要があります。
ユーザーストーリーのデメリット
注意すべきユーザーストーリーの落とし穴をいくつか紹介します。
- 不完全なストーリー：ユーザーストーリーは意図的に口語体で表現されていますが、時にはあまりにも漠然としており、必要な詳細が省略されることがあります。
- 時間不足：優れたアジャイルストーリーを書くには時間がかかり、広範な調査が必要です。 関係者との定期的なコミュニケーションと認識の共有も必要なのですが、見過ごされることがあります。
- 狭い視野：ユーザーストーリーが1つの要件に集中しているため、規模の調整が難しくなる場合があり、チームは全体像（この場合はエピック）を見失うことがあります。
ストーリーを書き始める前に、少し時間を取って、潜在的なリスクやデメリットを明確にしておきましょう。 必ずチームと話し合って、リスクやデメリットへの対策をまとめておいてください。
Wrikeでユーザーストーリーを次のレベルへ引き上げる
ユーザーストーリーの作成方法を理解したところで、プロジェクトの分解に取り組みましょう。 Wrikeにはこれにぴったりのソリューションがあります。
Wrikeのソフトウェアでは、カスタムワークフロー、かんばんボード、事前構築済みテンプレートを使用して、簡単にアジャイル手法を実施できます。 これらの機能により、プロジェクトの迅速な開始・可視化・推進、時間追跡、タスク管理、効率的なコラボレーションが可能になります。 また、アジャイルソフトウェア開発チームがWrikeを使用すれば、製品バックログの優先、スプリント管理、レトロスペクティブを実行できます。
近い将来にプロジェクトで良い成果を上げたいとお考えですか？ Wrikeのカスタマイズ可能なテンプレートでアジャイル手法の可能性を最大限に引き出しましょう。