Bugatti Veyron by M 93
Bugatti Veyronという車（上図）は信じられないほど速く走る車です。まるでボンネットの下に1000頭以上の怒れる馬がいるかのように、時速60マイルまで2.5秒もかからずに加速します。直線であれば、時速254マイルも出るでしょうし、スーパースポーツエディションの場合の最高速度はなんと時速268マイルです。
一方で、Land Rover Defenderという車（下図）はそれほど速く走れず、平均的な車より遅いでしょう。ボンネットの下の馬は大人しく、もし思い切ってDefenderで時速60マイルまで加速しようとしたら、少なくとも18秒はかかってしまうでしょう。
屈強なLand Rover Defenderは、速度を出すために作られてはいません。 Land Rover Defender by Shelka04
Bugatti Veyronが、地味なLand Rover Defenderとは速度の異なる次元にいることは明らかです。Bugatti Veyronがウサギなら、Land Rover Defenderはまさしく亀です。では、ウサギと亀のおとぎ話のように両者を競わせたとしたら、一体どちらが勝つでしょうか？ 当然Bugatti Veyronが常に勝つに決まっていると思うでしょう。
しかし、もし競技がオフロードレースだとしたらどうでしょうか。舗装された道路ではなく、泥の上を走るレースです。確かにBugatti Veyronは驚異的な車ですが、オフロードは確実に専門外です。
他方で、Defenderは間違いなく舗装路よりもオフロードのほうが得意です。オフロードレースでは、屈強なDefenderがスーパーカーの類を周回遅れにするでしょう。おとぎ話と同じように、カメがウサギに勝利するのです。
スーパーカーとオフローダーのレースは、Cから始まるある単語の重要性を示すよい事例でもあります。そのある単語とは、「コンテキスト（Context）」という単語のことです。コンテキストとは、誰が、何を、いつ、どこで、なぜ行うのかについて考えることです。
コミュニケーションにおいてコンテキストは非常に重要です。コンテキストがなければ、私たちは重要な詳細を見逃してしまうかもしれません。結果的に、本当に必要だったのはLand Rover Defenderなのに、Bugatti Veyronを作ることになってしまうでしょう。
何かをデザインしたり、構築したりする上でコンテキストは欠かせません。しかし、私たちが要件を伝えるためにますます頼りにするようになったユーザーストーリーは、あまりにも何かが足りていないことが多いです。
重要な情報を「〜として、私は〜できるように、〜したい。」という形でまとめたテンプレートは、自分たちの仕事をそれぞれのユーザーの機能に細かく分けるために、世界中のアジャイルチームが使っています。
この記事では、コンテキストを用いて、ユーザーストーリーを成長させる方法を紹介していきます。すべての重要なコンテキストを加えることで、ユーザーの要件を正確に把握することができます。まずはその前に、現在見られるユーザーストーリーの問題点をまとめましょう。
ユーザーストーリーの問題点
ユーザーストーリーは、現在ではアジャイル開発において人気が高まりつつあるスクラムと同じ意味で使われています。しかし、実際はアジャイルソフトウェア開発の前身であるエクストリームプログラミング（XP）から生まれたものです。エクストリームプログラミングは次のように提唱しています。
「ユーザーストーリーは、システムにしてもらいたいことを顧客が書いたものです。利用シナリオと似ていますが、UI以外についても表現している点で利用シナリオとは異なります。技術的な専門用語を使わずに顧客の知っている語彙を用いて３行以内で書きましょう。」
つまりユーザーストーリーとは、顧客が求める製品についての短い物語です。ユーザーストーリーでは必ずしもフォーマットに従う必要はなく、ただ専門用語を用いずに短く書けばいいのです。
問題は、現在ではユーザーストーリーがあまりに形式化されてしまっている点にあります。チームは要件を簡潔にしようと、「〜として、私は〜できるように、〜したい」といった形に要約します。しかし、まとめる過程で本質やストーリーのコンテキストも一緒に失われてしまうのです。次の例を見てください。
編集者として、私は何か変更を加えられるように、ドキュメントを開きたい。
一見このユーザーストーリーは正しいように見えるでしょう。ユーザー（編集者）、機能（ドキュメント）、タスク（変更を加える）が示されているからです。 しかし、問題なのは情報が少なすぎて参考にならないという点です。このユーザーストーリーには、すべての重要なコンテキストが欠けています。
編集者とは、正確にはいったい誰なのでしょうか？ 彼らはこの製品を使用した経験がありそうでしょうか？ どのような種類のデバイスを使用している可能性が高いでしょうか？ この製品をどこで、 いつ使用するのでしょうか？ それらの変更を行う動機は何でしょうか？
優れたアジャイルチームは、これらのような問いに答えようとするでしょう。これらはユーザーストーリーに含まれているべき情報です。ユーザーストーリーに含めないと、これらの追加情報は簡単に失われてしまうでしょう。
私の意見としては、現在のユーザーストーリーのテンプレートは簡潔すぎます。１つの重要な強みには、１つの重要な弱みが伴うものです。簡潔過ぎるためストーリーがあまりに開かれていて、解釈できないことが非常に多いです。ではユーザーストーリーのテンプレートを広く捉え過ぎることなく、コンテキストの情報を追加するにはどうしたら良いでしょうか？ 一緒に見ていきましょう。
「誰が」のコンテキストを加える
現在のユーザーストーリーのテンプレートは、ユーザーが誰なのかについて手がかりは与えてくれます。しかし、「編集者」、「管理者のユーザー」、あるいはあまりに包括的な「顧客」といったラベルだけではほぼ解釈できません。 コンテキストの情報がほぼ提供されず、ユーザーはすべて同じグループに還元されてしまうのです。
この場合、ペルソナという非常に便利なUXツールを用いることで、探しているコンテキストの情報を入手することができます。
ユーザーの種類をまとめたペルソナの例
私は以前、ペルソナがいかに優れているかについて記事を書いたことがあります（ なぜぺルソナにはまだ効果があるのかとペルソナを最大限に活用する方法をご覧ください）。
ペルソナとは、上図のような、要素を簡潔にまとめた架空のユーザー代表です。実際のユーザーとして扱わない限り、ペルソナは架空の情報でしかありませんが、ペルソナは事実に強く基づいて作られています。たとえばペルソナには、編集者の特徴やニーズ、要件などがまとめられているでしょう。
ペルソナは、ユーザーに関するこれらの重要な詳細情報をチームに伝えるのに役立ちます。こうした情報を考慮に入れることは、優れたユーザー体験をデザインする際に重要です。 ユーザーストーリーにおいてペルソナを参照することで、チームはユーザーや、ユーザーが使用するだろうコンテキストについてはるかに多くの情報を得ることができます。いくつかペルソナができたら、ユーザーストーリーにそれらを反映しましょう。
「ペルソナ」のような「ユーザー」は……
結果、私たち独自のユーザーストーリーは次のようになるかもしれません。
編集者のMargaretは……
Margaretは編集者というユーザーグループのペルソナです。もちろんペルソナを考えていなければ、これらの参照情報を追加することはできません。しかし、最小限で実行できるペルソナについての記事でも述べたように、ペルソナの作成は非常に価値のあるタスクであるだけでなく、想像以上に早く簡単に済みます。
「どこで」のコンテキストを加える
ペルソナを活用すれば、ユーザーストーリーにおけるユーザーが「誰なのか」について、コンテキストを提供することができます。では、「どこで」の点についてはどうでしょうか？ ユーザーや彼らと製品のインタラクションに対して、環境が与える影響は非常に大きいです。 周囲は騒々しいでしょうか？ 邪魔が入る可能性は高いでしょうか？ ユーザーは屋内にいるのでしょうか？ それとも屋外にいるのでしょうか？
ユーザーストーリーのテンプレートにもう少し情報を追加すれば、この重要な環境についてのコンテキストを含めることができます。
「ペルソナ」のような「ユーザー」は「環境」で……
先ほどの例は、このように始められるかもしれません。
編集者のMargaretは仕事中に……
こうすれば、Margaretのようなユーザーは仕事で何か困ったことが生じたら助けを求めるだろう、とチームは知ることができるでしょう。あるいは、彼または彼女は、もしかしたら電話の呼び出しや、他の社員の電話によって自分のタスクから気が散っているのかもしれないという予想もできます。
「何を」のコンテキストを加える
伝統的なユーザーストーリーのテンプレートにある「私は〜したい」という部分は、ユーザーが「何を」求めているのかについてのヒントにはなりますが、ユーザーがタスクを実行するために「何を」使っているのかについてはほとんど言及されていません。デジタル製品はラップトップからデスクトップやモバイル、タブレット、それらの間のあらゆるものまで、ますます多くのデバイスとアクセスできるようになっています。
たとえ最終的に機能が複数のデバイスで働く必要があったとしても、ユーザーストーリーの中で特定のデバイスに絞ることは有益です。そうすることでチームはコンテキストを作成しやすくなり、そのデバイスはタッチスクリーンで動かすのかマウスで動かすのかといった、デバイスの特徴についても考慮しやすくなります。
ユーザーストーリーのテンプレートに少し情報を追加すれば、この重要な「何を」というコンテキストを含めることができます。
「ペルソナ」のような「ユーザー」は「環境」で、 「タスクの理由」ができるように、「デバイス」を使って「何かを」したい。
私たちのユーザーストーリーは、次のようになります。
編集者のMargaretは仕事中に、変更を加えることができるように、自分のラップトップを使って、ドキュメントを開きたい。
これで、ユーザーストーリーのコンテキストが増えました。今や私たちは、Margaretのようなユーザーが仕事中に、ラップトップを使っていることを知っています。したがって彼または彼女は、マウスかトラックパッドを使っている可能性が高いでしょう。複数のモニターを使用しているかもしれません。これらの事項はユーザーストーリーをデザインし評価するうえで考慮すべきものです。
「なぜ」のコンテキストを加える
ユーザーストーリーのテンプレートに最後に追加するのは、「なぜ」に関する事項です。そもそもなぜユーザーはこのタスクを実行しようとしているのでしょうか？ この問いは、伝統的なテンプレートにある「〜できるように」とは少し異なります。というのも、この問いはタスクの動機に関わるもので、ユーザーの全体的な目標ではないからです。
たとえば、編集者は記事を公開するために早くドキュメントを開いて変更を加えたいとします。この重要な情報は「ドキュメントに変更を加えるために」と述べただけでは伝わらないでしょう。「なぜ」という情報も、より広範なユーザージャーニーを組み立てる際に役に立つものです。たとえば、ドキュメントを開くことは、ドキュメントを公開するという、より大きな目的の一部であることがわかります。
ユーザーストーリーのテンプレートに最後の部分を追加することで、「なぜ」というコンテキストを含めることができます。
「ペルソナ」のような「ユーザー」は「環境」で、 「タスクの理由」ができるように、「デバイス」を使って「何かを」したいです。そうすれば、「ユーザーの目標」になります。
私たちのユーザーストーリーの例は、最終的にはこうなります。
編集者のMargaretは仕事中に、変更を加えることができるように、自分のラップトップを使って、ドキュメントを開きたいです。そうすれば、ドキュメントを公開する助けになります。
今や私たちはユーザーストーリーのコンテキストについて非常にたくさんのことを知ることができます。チームは簡素なユーザーストーリーだけでなく、ユーザーについて多くのことを知っているので、その機能をデザインし、評価することができ、最終的には提供しやすくなっているでしょう。
ユーザーストーリーテンプレートの改善版
ユーザーストーリーのテンプレートに、「誰が」、「どこで」、「何を」、「なぜ」実行するのかというコンテキストを追加しました。私たちのテンプレートは最終的に次のようになりました。
「ペルソナ」のような「ユーザー」は「環境」で、 「タスクの理由」ができるように、「デバイス」を使って「何かを」したいです。そうすれば、「ユーザーの目標」になります。
私たちが例としてきたユーザーストーリーは、解釈の余地が非常に広いものから始まりました。
編集者として、私は変更を加えることができるように、ドキュメントを開きたい。
たくさんのコンテキストを加えて改善したものが以下のものです。
編集者のMargaretは仕事中に、変更を加えることができるように、自分のラップトップを使って、ドキュメントを開きたいです。そうすれば、ドキュメントを公開する助けになります。
お気づきでしょうか？ エクストリームプログラミングのガイドラインが勧めるように３行以内に収まっています。簡素ではない、事実に即したユーザーストーリーを得ることができました。
もちろん、アジャイルは本質的に柔軟な開発です。ユーザーストーリーに何もかも含めようとする必要はありませんし、厳格にこのテンプレートを守る必要もありません。
たとえば、ある特定のデバイスのためだけにデザインしていたり、ある特定の環境に対してのみデザインしていたりする場合、ストーリーをいちいち変えて、これらの詳細をストーリーに加えなくてもいいかもしれません。
