優れたユーザーストーリーで、WhyとWhatを表現しよう！
書き方編：プロダクトマネージャーの視点
こんにちは、VMware Tanzu Labs のプロダクトマネージャー(PM)のWataruです。
Tanzu LabsではLean XPでアジャイル開発を行なっていく際に「ユーザーストーリー」を使っています。PMの方だとユーザーストーリーと聞くとVelocityやMVPみたいなキーワードを想像される方もいらっしゃると思いますが、今回は「ユーザーストーリーを使ったチーム内のコミュニケーション」にフォーカスを当てて、
の3部作をお届けします！それぞれPM・デザイナー・エンジニア、と異なるロールからユーザーストーリーを紹介しているので、その視点の違いも楽しんでいただけたらと思います。
ユーザーストーリーを使う目的
開発手法によらず、どんなチームでも「開発者が何を作るか理解する」必要はありますよね？その方法はさまざまで、要件定義書や設計書などに記載して伝える、メールやチャットで伝える、口頭で伝える、など色々方法はあると思います。
我々Tanzu Labsではその手段として「ユーザーストーリー」を使っています。「ユーザーストーリー」とは、プロダクトのビジョンを実現するための戦略を日々の開発作業に変換したものであり、ユーザーが受け取る価値とその実現方法について記しています。
なので、1つのストーリーについて開発が完了すると、プロダクトは必ずユーザーに何かしらの価値を与える形で更新されることになります。アジャイル開発では、「画面」や「モジュール」単位で開発を進めるのではなく、「ユーザー価値」単位で仕事を進めることで、小さく早く変化に柔軟に対応できるようになります。
では、実際にどのように書くのか見ていきましょう。
ユーザーストーリーの書き方
Tanzu Labsで書いているユーザーストーリーは大きく2つのパートで構成されています。
① Why
読んで字の如く「なぜ」を表現するパートです。なぜこのストーリーが必要なのか、それを以下のような形式で表現します。
ペルソナは○○が欲しい（I want to ○○）
何故ならXXだからだ（Because xx）
そうすることによって△△になる（so that I can △△）
書き方としては、主語に「ペルソナ」（＝ターゲットとしているユーザー像）を持ってきますので、事前にペルソナを定義してチームで認識を合わせておく必要があります。そのペルソナが何を求めているか、それは何故なのかそれを分かるように記述します。先にも書いた設計書などで仕様を明確にする場合、「何を作るか」のみが書かれていることが多いのではないかと思います。それに対してユーザーストーリーは「何のために作るか」を明確にすることを大切にしています。
プロダクト（ソフトウェア）というものはエンジニアの指先から生まれます。その実際の作り手であるエンジニアが「なぜ」を理解しているかしていないかはとても大きな違いで、「なぜ」を理解していると決めきれていないことをエンジニアが発見してPMやデザイナーに確認してくれたり、場合によってはもっと良い方法（もしくはここはこんなに頑張らなくてもこうしておけば良くない？ということ）を発見してくれることもあります。
②What = Acceptance Criteria（受入基準）
Tanzu Labsの場合、ユーザーストーリーの書き手はPMかデザイナーです。PMは主に「機能ストーリー」と呼ばれる機能的なユーザー価値についてのストーリーを書き、デザイナーは主に「デザインストーリー」と呼ばれるUI/UX目線でのユーザー価値についてのストーリーを書きます。
Acceptance Criteriaはどういう状態になったらストーリーをAccept（受け入れ）するかの基準を書くパートです。エンジニアの方が「できたよー」としても、この基準を満たしていないとPM/デザイナーが判断した場合はReject（却下）ということになり、不足部分について再度対応してもらうことになります。
Acceptance Criteriaは以下のような形式で表現します。
ペルソナが○○の場合（Given ○○）
XXした時（When xx）
△△になる（Then △△）
Givenには「ログインしている」「XX画面にいる」などの前提条件を書きます。Whenは主にユーザーが行うアクション、例えば「保存ボタンを押した時」「電話番号を入力し終わった時」などですね。そしてThenにはその結果を記します。「△△が登録される」「◆◆画面に遷移する」「エラーメッセージが出る」など。それぞれ複数の条件やアクションや結果がある場合には、And でつないでいくつか書いていきます。
これが基本形式ですが、条件分岐（例えば、ラジオボタンで「はい」と選んだら次のラジオボタンを、「いいえ」と選んだらテキストボックスを出したいなどの時）はIf 〜 Then 〜という形式を使うこともあります。
実際には色々なパターンがありますが、どういう状態を実現したいかをエンジニアに伝えることが出来ることが重要です。
優れたユーザーストーリー
ユーザーストーリーに正解はないですが、Tanzu Labsではなるべくこういうことを意識しようというヒントのようなものがあります。
頭文字を取って「INVEST-A」になるので、1つずつ簡単に説明していきます。
- Independent（独立している）：他のユーザーストーリーに依存せずにこのストーリー単体で完結していること。そうすることで簡単に優先順位の変更やAccept/Rejectが出来ます。
- Negotiable（交渉可能である）：エンジニアやデザイナーに伝えた際に、Feedbackがあれば適宜変更できること。ガチガチに固まってない余白がある、という感じかなと思います。
- Valuable（価値がある）：ユーザに取って価値があること。「価値」って聞くと重いですが、エラーチェック1つだって立派な価値です。
- Estimable（見積可能である）：ここは誤解を生みそうですが、工数を出せる、とは違います。他のストーリーと比べて相対的に大きいか小さいか、それを判断するだけの情報が書かれている、ということです。
- Small（小さい）：個人的にはこれはすごく大事です。LEANに立ち戻るキーワードだなぁと思うことは多々あります。ただ、小さければ小さいほど正義！というわけでもなく、ユーザ価値とチーム状況を鑑みて、これくらいのサイズがちょうどいい、をチームで探し出すことが肝要です。
- Testable（テスト可能である）：Acceptance Criteria（受入基準）が明確であるということ。我々はXPのPracticeでもあるTDDを採用しているので、テストができるかはとても重要です。
- Actionable（行動可能である）：これは最近足されたもので、エンジニア陣が、このストーリーを完結させるために「何をすべきか分かる」ということ。技術的にも受入基準的にもクリアでなくてはいけません。
毎ストーリーごとにこれを全て照らし合わして確認しているかというと、それはしていません。ただ、「ユーザに価値あるよね？」「大きすぎないかな？」「どうやってAcceptする？」などは結構気にしていますし、エンジニアからの質問でもよく出てきます。自分がつい見落としがちだなと思う点があれば、意識してみるとより優れたユーザーストーリーが書けるかなと思います。
最後に
ユーザーストーリーを書く目的や書き方について紹介してきましたが、究極的には「みんなの頭の中が揃えばなんでもいい！」と思っています。そのためにはコミュニケーションが不可欠で、そのコミュニケーションを促進し、共通理解を可視化しておくものがユーザーストーリーだと思います。「書き方」を紹介はしましたが、それに縛られすぎず、チームにとってベストな表現方法を探していってみてください。
以上、ユーザーストーリー書き方編でした！
