【連載】要求工学における「利用状況」の扱いをめぐる考察：ジョブ理解に基づくマーケティングのインサイトを開発で確実に生かすには？（第1回）

マーケティング分野などでジョブ理論が注目されています。一方、Intercom社で始まり、Alan Klementによって広められたジョブストーリーと呼ばれる表現方法があります。ジョブ理論は、顧客が製品やサービスを「雇う（購入する）」理由を理解するためのフレームワークで、ジョブストーリーはその理解を深めるための一つの手法として使用できます。

ジョブストーリーとは？

ジョブストーリーは、次のような形をしているストーリーです。

When _____,（状況）

I want to _____,（望むこと）

so I can _____.（期待される成果）

例）

When：出先で次の訪問先の約束までに空き時間ができてしまった時に

I want to：ちょこっと行ける近くのジムを見つけたい

So I can：エクササイズに取り組むことで隙間時間を有効に過ごすことができる

つまり、トリガーとなる状況（Context）、動機（Motivation）、期待する成果（Expected Outcome）から成るストーリーです。

ソフトウェア開発に携わる者としては、最初にこれに出会うと（あるいは出会った際に）、よく似たものの存在に思いが至るのではないかと思います。 少なくとも私はそうで、すぐにユーザーストーリーを想起しました。

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

ユーザーストーリーは、ソフトウェア開発、特にアジャイル開発の現場では、既に広く使われているものです。 本稿を読んでくださる皆さまには、今さら説明を要さないと思いますが、後で比較する都合もありますので、推奨される一つの形をここに示します。

As a who, I want/need what [so that why].

（who）として

（what）がしたい

［それは（why）のためだ］

（who）は主語ではなく役割やペルソナ

［］内はオプション。

例）

Who：忙しくて運動不足になりがちなビジネスパーソンとして

What：利用可能なジムを見つけたい

Why：それは健康のためにエクササイズに取り組むためだ

二つのストーリーのフレームワークは似ているように見えますが、どこが共通で、どこに違いや特徴があるのでしょうか？　とても興味を持って、さっそくあれこれと考察せざるを得なかったのを覚えています。 その後も機会があれば、一つのニーズを両方のフレームワークで表現し、その後のプロセスの中での使い勝手などを比較しています。

すぐに気付く大きな違いは、何といっても「状況」の扱いでしょう。近頃、マーケティング分野で重視されている「状況」が、ユーザーストーリーの表現には含まれていないように見えます。 ビジネスとして、イノベーティブで魅力的な品質を持つ新商品の開発が期待されている中、ユーザーストーリーを使い続けていて問題ないのでしょうか？ これからはジョブストーリーということで、乗り換えた方が良いのでしょうか？

もちろん先にも述べたように、ジョブストーリーが用いられているのは、主にマーケティング領域などでの話です。しかし、マーケティングの活動は、新商品の企画プロセスやコンセプトフェーズ（Concept Phase）などと呼ぶにふさわしい活動を含むので、開発上流との重なりも大きい領域です。要求開発（要件定義）プロセスの一部であると言ってよいでしょう。

ですから、少なくとも両方のフレームワークの特性をよく理解して、マーケティングのインサイトが開発の要件定義に確実に反映されるよう、整合性のある運用を設計しておく必要がありそうです。 本稿ではそのことについて、私なりに考察したことを以下でたどり直してみたいと思います。

ジョブを適切に表現・定義することで、ジョブ理論は何をしたいのでしょうか？

注）本稿では、ジョブとは何か？（ジョブの定義）や、なぜそれを「ジョブ」と呼ぶのか、「雇用する」という表現を使うのはなぜか、などジョブ理論そのものについては解説しないことにします。書籍はもちろん、ネット上にも情報がありますので、別途それらを参照してください。

「顧客は、“なぜ”その選択をしたのか？」。もっと言えば、「顧客は、“なぜ”他にもある競合製品ではなく、わが社の製品を購入してくれたのか？（購入してくれると見込めるのか？）」。 それを理解することが重要である、とジョブ理論の提唱者クレイトン・クリステンセン（Clayton M. Christensen）は強調します。

「誰が」でも「何を」でもなく、ジョブ理論は上記したような意味での「なぜ」に重点を置くのだと。この質問に答えるには、従来のニーズ把握だけでは不十分であり、顧客のジョブ（ある特定の状況で人が成し遂げようとする進歩）を理解する方が優位性があると主張しています。 次のような分かりやすい例を、クリステンセン自身が示しています。

「私は食べる必要がある」という表明は、ほぼつねに真実である。「健康的でいたい」や「定年後に備えて貯蓄する必要がある」も同様だ。これらが消費者にとって重要なのはたしかだが、そのニーズをどのように満たすのかはぼんやりした方向性しか示されない。…（中略）…私は食事を抜かすことがある。であれば、ニーズだけではすべての行動を説明できない。逆に、まったく空腹でなくても食事をする理由はいくらでもある。

一方、ジョブは、はるかに複雑な事情を考慮する。何かを食べる必要があるという状況と、その時点で重要でないその他のニーズは、激しく変化しうる。

（文献［1］より引用）

つまり、主な違いは次のようにまとめられます。

なるほどと、思い当たることはいろいろあります。例えば、次の約束への移動中、間に合うように素早く食事を済ませたい時に、私は立ち食い蕎麦屋で食事をすることがあります。そういうとき、別に蕎麦が食べたいわけではありません。食事に要する時間が予測できるから選んでいるわけです。普通に蕎麦を食べたいなら、多分他の店に行くと思います。

このように、ある特定の（他のどれでもない）プロダクト／サービスを選び雇用（購入）するに至る理由は、その時の特定の状況で作用するニーズが集合したものなのだと分かります。その集合に属する各ニーズの優先順位は、状況次第で刻々と入れ替わっていることにも気付きます。なるほど、状況の理解なくして顧客の行動を予測することは難しい、と納得させられます。

クリステンセンは、次のような表現で「状況」に注目するように、繰り返し促しています。

「状況」は片づけるべきジョブ理論の根幹である。

ジョブの定義には「状況」が含まれる。ジョブはそれが生じた特定の文脈（コンテクスト）に関連してのみ定義することができ、同じように、有効な解決策も特定の文脈に関連してのみもたらすことができる。

ジョブを定義するのに（その解決策を見つけるためにも）状況が不可欠なのは、なし遂げたい進歩の性質が状況に強く影響されるからだ。

（文献［1］より引用）

そして、従来のマーケティング活動から、なかなかイノベーティブな製品やサービスが生まれてこない理由は、「状況」にいまだ十分に目を向けていないからだというわけです。

ジョブは日々の生活のなかで発生するので、その文脈を説明する「状況」が定義の中心に来る。イノベーションを生むのに不可欠な構成要素は、顧客の特性でもプロダクトの属性でも新しいテクノロジーでもトレンドでもなく、「状況」である。

（文献［1］より引用）

Scrum Allianceの共同創設者の一人であるマイク・コーン（Mike Cohn）は、「User Story Template: What It Is and Why It Works So Well」と題するブログの記事の中で、以下のようなことを記しています。

標準のユーザー ストーリー テンプレートについて、Rachel Daviesが考案したConnextra Formatの3つの要素を役割、目標、理由と呼ぶことにし、最終的にもっと単純に「誰が、何を、そしてなぜ」と呼ぶことに移行した（注：日本語訳は本稿の著者によるものです）。

結局、標準のユーザーストーリー形式は、次の3つの要素から構成されると言えます。

●機能が欲しい人（Who）

●対象者が望んでいること（What）

●対象者がそれを望む理由（Why）

これを5W1Hのような広く知られているフレームワークに照らしてみると、5Wのうちの残りの2つ、つまり「いつ（When）」と「どこで（Where）」が欠落していることに気付きます。それらは、ユーザーストーリーの標準雛型に、含まれなくてよいのでしょうか？　コーンは同記事の中でこの問いに対する答えも次のように記しています。

製品やシステムの要件について議論する場合は、「いつ（When）」と「どこで（Where）」の答えは、通常「今」と「製品内」になる。

つまり、分かりきっているのだから、それを省略するのが合理的というわけです。たしかに、従来の業務システムのように利用する場所やタイミングがほぼ決まっていて、利用者が直接インタラクションするような場面が念頭にあってのことでしょうから、その通りだったのでしょう。

ただし、ユーザーストーリーの形式がいつも適切であるとは限らず、その場合には別の表現方法を使用する必要性についても説明しています。その別の表現方法のいくつかの例示の中で、ここで取り上げているジョブストーリーについても次のように言及されています。

ジョブストーリーまたは機能駆動開発の機能で使用される構文の方が適している場合がある

そのようなわけで、現在においては、あまりユーザーストーリー（特にそのテンプレート）にこだわり過ぎるのは、むしろ適切な表現を阻害する結果につながってしまうこともあり、注意が必要と考えておいた方が良さそうです。 特に現在は、常時接続の通信インフラが整い、利用者が直接利用するタイミングでの「状況」だけを考えてみても、とても多様になってきているから、なおさらです。さらに、利用者のオンライン行動とオフライン行動を統合したOMO（Online Merges with Offline）戦略なども重視しなければならない時代に変化しているわけですから、それに対応できる方法論を常に工夫し続けることが肝要であると言えるでしょう。

ここまで、個々のユーザーストーリーの表現の範囲で考察してきました。それらをそのまま束ねて要件リストとしたり、プロダクトバックログの中に入れたりしてしまうような現場もあるのですが、一般にはユーザーストーリーマッピングなどの手法でストーリーを深く理解し、体系的に整理していくことになると思います。

ユーザーストーリーマッピングは、ユーザーストーリーの束を単なるリストとして扱うのではなく、ナラティブストーリー（ユーザーのジャーニー〔旅〕）を捉えた上で、その中でプロダクトがどのように価値を提供するかを探求する手法です。この手法を適用することで、開発者はユーザー視点からプロダクトを見ることができ、よりユーザーにとって価値のある機能や改善点を見つけ出すことが可能になります。

この手法の中で、ユーザーのジャーニーについては、まずは典型的なハッピーパスの把握に努めます。続いて、さまざまなバリエーションの検討（「どうなる」ゲームなどと呼んだりもします）に入ります。他のバリエーションを列挙するに当たっては、起こり得るさまざまな「状況」をどれだけ把握できているか、ということに懸かっています。

ところで、ユーザーストーリーマッピング手法の解説においては、「どうなる」ゲームで例外的もしくはレアなケースを考えてみる例を示していることが多いです。（例えば、朝起きてから出かけるまでのルーティーンにおいて、「寝坊した状況」を想定してみるなど）。しかし、考えるべきバリエーションは必ずしもそういうものばかりではありません。 特に本稿ではマーケティング的観点での好機（オポチュニティやチャンスに結びつく「状況」）を着実に捉えるに当たってのフレームワークの有効性の話をしてきています。

つまり、市場の変化、技術革新、競合他社の動向、消費者の行動の変化、新しい市場ニーズが明らかになった時、新技術が登場した時、または法規制の変更時などのケースをそれぞれ考えるような「どうなる」バリエーションです。

例えば、次のようなユーザーストーリーを考えてみることにしましょう。

As a 家族の支え手の一人として,

I want 無理なく継続可能なエクササイズ,

so that 家族と共に健康で楽しい生活を維持できるように.

無理なく継続できるためには隙間時間を活用できると良いでしょう。典型的には仕事の帰り道に駅前のジムに通うようなジャーニーマップが描けるかもしれません。

しかし、隙間時間は、例えば客先を回る合間に、いつもとは違う場所で発生するかもしれません。むしろそういう隙間時間こそうまく活用したいはずです。その状況で、近くにジムがあること、そこに置いてあるマシンや混雑状態がスマホアプリで簡単に分かれば、見つけた所望のジムを利用したいはずです。職業によってはそういう状況が頻発する人もいるでしょう。例外的どころか、その方が日常的という人たちも、マーケットの大きさとして十分にいるかもしれないわけです。

ジョブストーリーを使っていなくても、例えば上記のようにユーザーストーリーマッピングの中で、ここに例示したようなナラティブストーリー（ジャーニーマップ）を描けていれば何ら問題はないと言えるでしょう。

ジョブストーリーの表現には「状況」が含まれているため、定義したものを読めば、すぐに「状況」が把握できるようになっています。

一方、ユーザーストーリーの表現では、それ自体の中には「状況」の記述は一般に含まれません。「状況」を把握するには、ユーザーストーリーマップ（ナラティブストーリーあるいはジャーニーマップとも呼ばれる）の体系の中で、それがどこに位置付けられているかを確認する必要が出てきます。もちろん、それで「状況」把握が可能なように、バリエーションを含めた体系化が十分にできていることが前提となります。

いずれの表現を用いるにしろ、その中に次のことが確実に含まれていることを上流で検証・確認しておくことが肝要です。

企画プロセスやコンセプトフェーズで盛り込まれた「顧客は、“なぜ”他にもある競合製品ではなく、我が社の製品を購入してくれたのか？（購入してくれると見込めるのか？）」につながる「特定の状況においてこそ、切望される価値を提供する」

もちろん、その理解がデリバリーに関わるメンバーに至るまで確実に浸透していることを常に確認し続ける必要もあります。

ユーザーストーリーの表現は、それ自体の中には「状況」の記述は一般に含まれませんので、この点でちょっと不利だと言ってよいでしょう。

ところで、興味深いことに、振る舞い駆動開発（BDD：Behaviour Driven Development）あるいは受け入れテスト駆動開発（ATDD：Acceptance Test-Driven Development）といった手法の中で用いられるExampleは、次に示す3つの要素の組み合わせとして振る舞いを記述することになっています。

●状況（コンテキスト）

●アクション

●結果

これらの手法の中で最も重要な考え方がSpecification By Exampleであり、ユーザーストーリーからExampleを導きます。そのExample表現に共通していなくてはならない唯一のことが、上記要素の3つ組で表現することです。

抽象度の高いものから具体性のあるExampleまで、これらの手法を採用するなら、そのExampleの表現の中に再び「状況」が必ず表現されることになります。

既に説明がだいぶ長くなってしまったため、このことについては本連載の別の機会に述べることにしたいです。

次回は、「状況」が品質の国際規格の中でどう位置付けられているか、「品質」と「状況」がどう関係しているかについて取り上げたいと思います。

＜引用文献＞

［1］クレイトン M クリステンセン（著）、タディ ホール（著）、カレン ディロン（著）、デイビッド S ダンカン（著）、依田 光江 （翻訳）『ジョブ理論　イノベーションを予測可能にする消費のメカニズム』ハーパーコリンズ・ジャパン（2017/08発売）