サブタイトル：UXデザイナーがユーザーストーリーを作成するために
この記事は『CRESCO Advent Calendar 2020』 2日目の記事です。
こんにちは！エクスペリエンスデザインセンター所属のカツメです。
アジャイル開発やサービスデザインにおける「ユーザーストーリー」について、部門のメンバーに共有しようと資料をまとめていたのですが、集めた情報がもったいないなぁと思ったのでエンジニアブログに投稿してみます。誰かのお役に立てますように！
目次
ユーザーストーリーとは、顧客やユーザーができるようになりたいことをまとめたアジャイルソフトウェア開発手法で作成する文章です。
開発時の要件定義を関連づけるために使用されるもので、開発手法のエクストリーム・プログラミング（XP）で生まれた「ストーリー」が「ユーザーストーリー」と発展していき、今ではスクラムやカンバンなどの開発方式でも広く使われています。
ユーザーストーリーは誰でも書くことができますが、ステークホルダー（顧客、ユーザー、開発者、テスターなど）の話し合いであったり、ペルソナに基づいて作成されたりします。
PM（プロジェクトマネージャー）が作成する場合や、スクラム開発だとPO（プロダクトオーナー）が主に作成しプロダクト・バックログ（作業計画）に整理する責任を負っています。
サービスデザインの分野では、デザインリサーチとインサイトやアイデアなど開発に活用できる情報を結びつけるためにUXリサーチャーやUXデザイナーがユーザーストーリーの作成に関わっていきます。
エクストリーム・プログラミング（XP）の考案者の1人であるKent Beck氏はソフトウェア開発においての大きな問題は、要件定義のプロセスに起因するものと考えました。
同じ要件定義書を読んでも読む人によってイメージが異なり、合意して開発を進めたのに佳境に入ってから違う理解をしていたことに気づく・・・
そういった問題に対して彼は完璧な要件定義書を作ることをやめました。
ステークホルダーが集まって「ストーリー」を語ることにしたのです。
解決しようとしている問題（ストーリー）についてカードに書き、早めに見積ることでビジネスと技術の観点から解決にたどり着くためにどうするかの会話ができ、何を作るかについて意見を一致させることができると考えました。
その後、考案者のうちの別の1人である Ron Jeffries氏により「3C」という「ユーザーストーリー」を3段階で発展させる方法が考案されました。「3C」とは3つの単語、Card（カード）、Conversation（会話）、Confirmation（確認）の頭文字です。
- Card（カード）
カードはストーリーの置き場所のことです。ストーリーはカードに書きます。 - Conversation（会話）
カードに書かれたストーリーだけでは詳細がわかりません。詳細は会話をします。 - Confirmation（確認）
カードに書かれたストーリーについて詳細に会話をしたとしても、認識の違いがあるかもしれません。正しく実装されているか、完了しているかの受入基準を確認します。
ユーザーストーリー は、作成者からの一方的な「ユーザーストーリーができたら開発チームに連携する」といった工程のための中間成果物ではありません。
ユーザーストーリーができた時点がスタートでそこから会話をし共通理解を築いていくためのものです。つまり、要件やタスクでもありません。
さて、ここで開発における「ユースケース」とは違うのだろうか・・・？という疑問がでてきますよね。
ユースケースは、一つのタスクを達成するためのユーザーとシステムとのやりとりを詳細に書いていきます。ユーザーが目標に達成する可能性のあるすべての方法を書き、またユーザーが目標を達成できないことや途中でうまくいかなくなる可能性のあるすべてのことを書くため、ユーザーストーリーより詳細です。
ユースケースを書くのは要件や機能仕様を定義するチームや担当者です。開発チームとをつなぐ情報になります。
ユーザーストーリーは、システムが何を提供すべきかではなくユーザー（顧客）が何をしたいかに焦点を当てていて、詳細は書きません。ユーザーストーリーは誰でも書く可能性があります。チーム間をつなぐ情報ではなく、それをもって会話することを目的としています。
誰によって作成されるのか、そもそもの用途や書く内容もそれぞれ別物だということがわかりました。
アジャイル開発における「ユーザーストーリー」について理解はできますが、サービスデザインの分野でどう活用されているのかが気になるところです。
ユーザー調査の分析結果をもってUXリサーチャー（UXデザイナー）が率先してユーザーストーリーの定義を行っていくと良いようです。そもそもユーザー視点で書かれているものがユーザーストーリーなので、ユーザー調査から作成するというのは当然の事でしょうか。
ペルソナやユーザーシナリオなどをセッションに持ち込んで、ステークホルダーとユーザーストーリーを作成する場合もあります。
HCD（人間中心設計）プロセスやデザイン思考においてユーザー調査は重要ですが、残念ながら調査のフェーズがない場合もあります。その場合は既存のサービスや製品からログ分析、VOC（ボイス・オブ・カスタマー）などできるだけ多くの情報を収集しユーザーに共感・深い理解をしていきステークホルダーとともにユーザーストーリーを作成します。
さて、会話を始めるための「ユーザーストーリー」とは具体的にどのように書けば良いのでしょうか。
エクストリーム・プログラミング（XP）をいち早く導入した企業「Connextra」でテンプレート（ストーリーカード）が生まれました。必要な機能を書き出すのではなく、「Who（誰が）、What（何を）、Why（なぜ）」について考えられるようなテンプレートです。
[ ユーザー／顧客 ] として、
私は [ これこれの結果を得る ] ために、
[ これこれ ] をしたい。
How（どのように）はストーリーには含まれません。これは会話の中で決めていく要素になります。
開発方式によってそれぞれの固有のフォーマットがありますが、エクストリーム・プログラミング（XP）の手法を取り入れたスクラム開発では以下のようなフォーマットになっています。
[ ユーザー／顧客 ] として、
[ 達成したいゴール ] をしたい、
なぜなら[ 理由 ] だから。
What（何を）、Why（なぜ）の順番が違うだけで含まれている要素は同じです。話し合いの中で開発しないストーリーも出てくるため、この時点で詳細に書く必要はありません。
従来の要件定義書の作成プロセスとは違うため、形式に捉われて正確に書くことに重点を置くのではなくステークホルダーがいつでも内容を思い出せるような状態にしておくことが重要です。
初期の段階ではやりたいことが明確にわからずユーザーストーリーを書き始められない場合があります。そういった時は最初にエピック（大きなストーリー）から書きはじめ、会話をしながらストーリーに分割していく方法をとるとよいでしょう。
また、ユーザーや顧客が考えるストーリーの「完了」と開発チームが考える「完了」とは違うため、ストーリーが「完了した」とみなす受入基準を記載します。
ユーザーストーリーを記述していく上で、Bill Wake氏が考案した優れたユーザーストーリーのガイドラインがあります。それぞれ単語の頭文字をとって「INVEST」と言われています。
- Independent（独立している）
どんなスケジュールを組んでも実行できるよう、独立していることが望ましい。 - Negotiable（内容が交渉できる）
詳細は会話をして作成していくため、交渉ができるものである。 - Valuable（価値がある）
機能について書かれているのではなく、顧客にとって価値があるものになっている。 - Estimable（見積もりができる）
正確でなくてもよいが、優先順位づけやスケジュールが立てやすいものである。 - Small（小さい：1つのイテレーションにおさまる範囲）
ストーリーが大きいと把握するのが難しかったり、見積もりがしにくいため適切な大きさである。 - Testable（テストできる）
ストーリーが達成されているか確認することができること。受入条件が明確であること。
前章で書きましたが、ユーザーや顧客視点での受入基準のことです。
そのほか、以下のポイントに気をつけます。
- IT専門用語を使わない
- 誰もが理解できるようにする
- シンプルで短い言葉を使う
- UIやアルゴリズムを定義しない
- ユーザーの視点で書く
ユーザーストーリーを作成したあとに詳細な会話をすることが前提のため、最初から大量の文章を書かなくてもよい点はメリットです。
ユーザーの視点での「ストーリー」があることで、ユーザーが直面している問題の解決に集中することができます。
「機能中心」な機能ありきでの設計ではなくユーザーの価値やビジネスの観点も含まれているのも良いです。結局どんな価値が提供できたのだろうか？と疑問に思うプロダクトがリリースされることを避けられるのではないでしょうか。
そして、会話をすることで「共通認識」ができるのでチームが協力して達成する方法を検討することができます。
技術的な要件の把握には向いていません。
パフォーマンスやユーザビリティなど非機能要件の詳細が含まれていることがほとんどないため、どのように動作するのか、非機能テストなど見落とされる可能性があります。
ユーザビリティであればUIの観点で、受入基準にウェブアクセシビリティの基準としてW3Cの達成基準を用いたりしてもよさそうです。同様にUXの観点ではユーザーストーリーだけでは不十分なため、例えば「ユーザーがタスクAを完了するまでに、大きなユーザビリティ上の問題に遭遇しない」などを受入基準に入れるとよいようです。
ストーリーを完結に書きすぎてコンテキストが失われてしまうことがあるようです。そんな時はペルソナが役に立ちます！
ペルソナとは実際のリサーチをベースにした典型的なユーザー像のことです。ユーザーストーリーにおいてペルソナを参照することで、完結な文章でもコンテキストについての多くの情報を得ることができます。
また、スケッチ、ストーリーボード、モックアップなど他のもので補完したり、チームが共通理解を得られるようにツールなど柔軟に取り入れるとよさそうです。
（ストーリーボードについてはこちらの記事を参照ください）
■クレスコエンジニアブログ：絵が描けなくても大丈夫！ストーリーボード活用！
小さなストーリーに分かれることによって全体像を見失ったり一貫性を失った寄せ集めのシステムになる可能性もあります。そんなときは全体像と開発計画について把握することができるストーリーマッピングというテクニックを利用するとよいでしょう。
（ユーザーストーリーマッピングについては、以下の記事を参照ください）
■クレスコエンジニアブログ：来年のキミとボクへ〜Advent calendarネタ探しジャーニー
ユーザー調査、コンセプト作成、設計、ユーザーテストなどUXデザイナーの役割は多岐に渡りますが、UXデザイナーとして私たちがアジャイル開発における「ユーザーストーリー」付近にからむには以下のようなパターンがあると考えました。
（リサーチャー、デザイナーなどはっきりとした区切りがない場合もあります。）
- 前述したユーザーリサーチ結果をストーリーにする
- ストーリーをもって会話する際にUX部分を定義する
- プロダクトオーナーのユーザーストーリー作成のサポート
- UIに関連するバックログ作成
- プロトタイプ作成
アジャイル開発での短いイテレーションの中でUXデザイナーが関わっていくのには工夫が必要ですが、「人」を中心に考えるアジャイル開発で「人」の体験の設計図を描くデザイナーが活躍できないはずがありません。
ひとつのプロジェクトを遂行するにあたって、プロジェクトマネージャー、プロダクトオーナー、リサーチャー、UXデザイナー、UIデザイナー、エンジニアなど様々な役割の人々がいます。
ターゲットの市場について話したい人、収益の影響について考える人、どこでエラーを起こしそうか考えている人、便利で使いやすいインターフェースを設計するために誰が何を行いたいのか話したい人、システムの構築について考えている人・・・
全員同じドキュメントを見ていても、それぞれが話す内容が異なってきます。
「共通認識」をするために会話をすることはユーザーストーリーを使うアジャイル開発だけではなくウォーターフォール開発でも非常に重要です。
当たり前のことですが、システム開発以外でもコミニュケーションを取ることは生産性や品質の向上に、また働く環境にとって、そして顧客の価値や企業の利益にとっても重要です。
私たちクレスコはクライアントの要求をただシステムという形にするのではありません。エンドユーザーにとっての価値やクライアントの利益についてコミュニケーションをとりながら共に考え、社会にとっても価値のあるものを創造していきたいと考えています。
最後に宣伝となりますが、クレスコでは「共通認識」をしながらチームビルディング、アイディエーション、コンセプトの策定、新しい顧客体験価値の創造などの支援を行なっています。
サービスデザインとアジャイル開発を使用し、仮説構築と仮説検証を支援することも可能です。
■出典・参考
「ユーザーストーリーマッピング」：(著)Jeff Patton
「This is Service Design Doing サービスデザインの実践」：(著)マーク・スティックドーン, アダム・ローレンス,マーカス・ホーメス, ヤコブ・シュナイダー
「エクストリームプログラミング」：(著)Kent Beck, Cynthia Andres
wikipedia：User story
wikipedia：スクラム (ソフトウェア開発)
The Scrum Guide™
ATLASSIAN Agile Coach
XP123
