ペルソナかJobs-to-Be-Doneか
Jobs-to-be-doneは、ユーザーの問題とニーズに重点的に取り組むものだが、適切に作成されたペルソナには、それと同じ情報が含まれていて、さらに行動や態度に関する詳細情報も入っているものだ。
はじめに
ペルソナは長い間、ユーザー中心デザインプロセスにおける有益なツールであり続けてきた。しかし、近年、顧客のニーズに焦点を当てる新しい手法、Jobs-to-be-done（訳注：「ジョブ理論」とも呼ばれている）が、一定の注目を集めるようになってきている。
定義：Jobs-to-be-done（JTBD）とは、ユーザーが製品を「雇用する」（hire）（すなわち、利用する）とき、彼らはそれを具体的な「ジョブ」（job）のために（すなわち、特定の成果を得るために）利用している、という考え方にもとづくフレームワークのことである。そこでのある製品に対する「ジョブ」のセットというのは、ユーザーニーズの包括的なリストを意味する。
JTBDという枠組みの流行によって、一部には、ペルソナを使うのはやめるべきだという意見もある。もっと有益な手法としてJTBDが出てきたから、ということだ。しかし、この見解のベースになっているのは、ペルソナの目的は主にユーザーのデモグラフィック属性を表現することである、という根本的な誤解である。この見方からは、良質なペルソナには不可欠で、インタラクションデザインや製品戦略に本当に必要な指針を与えてくれる、行動に関する検討事項が抜け落ちてしまっているからである。
Jobs-to-Be-Done：機能ではなく成果を重視するのに適したツール
Jobs-to-Be-Doneというフレームワークは、フィールド調査やインタビュー、ディスカウントユーザビリティテストのような、定性的なユーザー調査から得られたユーザーのニーズを視覚化する。そこでは、顧客がどんな目的のためにあなた方の製品を「雇用」するかが特定されることになる（そして、理想通りにいけば、そのユーザーたちが「解雇」（fire）しようとしている他社製品があるのかどうかも発見されることになる）。製品チームにこうした点についての理解があれば、新たな視点で、ユーザーにとっての核になる問題やニーズの本質について考えられるし、そうした中心的ニーズを最適な形で解決できるデバイスの機能についても考えることが可能である。
JTBDというフレームワークは新しいものだが、製品とのインタラクションに必要なコンテキストやゴール、ステップに焦点を当てた、タスク分析やユースケースのような確立された手法と類似したところも多くある。JTBDと伝統的なシステム分析手法の違いを最もよくあらわすのが、ユーザーのタスクが正確にはどういうもので、どうすれば彼らがそれを達成できるかについての指示が、JTBDのほうがずっと少ない、ということだ。タスク分析やユースケースの目的は、ユーザーがおこなう必要のある（そして、既存のソリューションによって結果的にバイアスをかけられてしまっていることが多い）典型的なアクティビティを、その製品で処理する最適な方法を知ることにある。しかし、JTBD手法では、望ましい成果や、そうした典型的なアクティビティがユーザーが本当に求めている成果に達する手段なのかどうかが焦点になってしまうからである。
たとえば、伝統的なタスク分析によって、配送ドライバーが毎日の配送ルートでの配達先間の経路がわかる道順を頻繁に印刷する必要があることが発見されたなら、デザインチームは、ドライバーたちができるだけ楽に道順の書式設定と印刷ができるように集中して取り組むだろう。しかしながら、JTBD重視手法では、配送ドライバーの「ジョブ」（すなわち、運転中に道案内してもらうこと）に焦点が当てられ、その問題に対するソリューション（たとえば、音声ガイダンスつきのGPSシステムを提供するなど）を探すことになるのである。
つまり、JTBDというフレームワークが示唆しているのは、革新性や良質なデザインは、顧客の「真の」ニーズを見極め、そのニーズに対応している既存の製品に邪魔されないソリューションを作り出すことから生まれる、ということだ。しかしながら、製品を改善する戦略としての抜本的な革新は、コストもリスクも高くつく可能性がある。
「人々は6ミリ径のドリルを買いたいわけではない。彼らが欲しいのは6ミリ径の穴である」というTheodore Levittの有名な言葉をJTBDの支持者はよく引き合いに出すが、JTBD というフレームワークは、製品の機能の一覧を重視する代わりに、以下のように成果について考えることをデザイナーに強いる。その製品を「雇用した」目的であるところのジョブをユーザーが（楽しく、そして楽に）達成できるだろうか。このソリューションによって、既存のソリューション以上の成果を提供できるのか。
JTBD手法は、フォーマットや成果物を具体的に規定していない。しかし、ほとんどの場合、“片づけるべきジョブ”（job-to-be-done）が文章形式で定義され、そこにはユーザーがやらなければならないことと、なぜ、あるいは、どこでそれをやるのかといった、重要なコンテキスト情報が記されている。そして、最後になるが、JTBDの記述には、成功するための機能基準（このジョブを成功させるための明確な客観的要件）と、成功するための感情基準（これは、ユーザーの個人的な感情の基準と、自分が他者からどう見られるだろうかの想像、といった社会的な検討事項にさらに分解できる場合もある）の描写もある。
良質なペルソナはデモグラフィック属性以上の働きをする
JTBDの登場によってペルソナが無意味なものになってきている、という主張は、ペルソナというのはそもそも顧客のデモグラフィック属性を描写したものだ、という誤った思い込みにもとづいていることが多い。デモグラフィック属性は行動や態度に関するデータは提供してくれないので、製品やデザインの意思決定をする際には厄介だからだ。マーケティングや広告に関する意思決定には適していることが多いのだが。
実際には、ペルソナの意図はユーザーを豊かに描写することにあり、ペルソナとは単なるデモグラフィック属性や個人情報以上のものだ。ほとんどの精巧に作られたペルソナには以下のような多くの情報が含まれている：
- デモグラフィック属性（年齢や婚姻関係、収入など）
- 個人情報（略歴、写真、名前など）
- 態度や認知に関する情報（そのペルソナのメンタルモデルや問題点、達成する必要のあるタスクについての感情に関する情報など）
- その製品を利用する目的と動機
- その製品を利用するときにそのペルソナがどう振る舞う傾向にあるかに関する行動的情報
ここにデモグラフィック属性や個人情報が含まれているのは、主に2つの理由からである：
- 製品チーム内でユーザーに共感を持てるようにするため
- 彼らのことをチームに記憶してもらいやすくする工夫として
残念ながら、ペルソナの多くは（実際には、ペルソナのふりをしたマーケティングセグメントなわけだが)、デモグラフィック属性や個人レベル以上に掘り下げたものにはなっていない。ペルソナは“片づけるべきジョブ”に比べて意思決定の役に立たない、とばかにされることが多いのは、このことが理由なのである。
適切に作成されたペルソナは、豊富な内容の行動的特徴や態度に関するデータ、メンタルモデルに関する知見を主にベースにしている。そのため、ユーザーの行動の背後にある「理由」を発見するために、現実のユーザーを対象にした定性的な調査が必要になる。内容の充実したこういうペルソナには、その製品の使用時にユーザーが達成しなければならない具体的な目的に関する情報が通常、含まれることになる。結果、そうした目的は、“片づけるべきジョブ”で定義される情報にそのまま該当することになる。
Jobs-to-Be-Doneは共感を誘わない
ペルソナがもともと現実のユーザーの描写を重視している主な理由として、機能や要件のリストを機械的にチェックするという思考から離れて、ユーザーにとってのそのエクスペリエンスの「あり方」に焦点を当てたい、というのがある。JTBDにも、ユーザーの目的に関する感情的・社会的なコンテキストについての重要な検討事項が含まれてはいる。しかし、そうした要素をユーザー全体というベースの中で一般化してしまうため、ユーザーについてのコンテキストである、という肝心の感覚が失われ、デザインチーム内で共感を生み出す機会を逃してしまうのである。
ペルソナはユーザー間の優先順位づけに役に立つ
以下のようなシナリオを想像してみよう。あなたは人気の生産性向上デスクトップアプリケーションの新バージョン開発チームのメンバーである。最近、競合他社が革新的な製品によってその市場に参入してきた。そこで、あなた方の会社の上層部は今のアプリケーションのデザイン変更をすることで、そうした新製品と市場で競いたいと考えている。その際、既存顧客や潜在的な顧客にインタビューをして、どんな“片づけるべきジョブ”が彼らにとって重要であるかを見つけ出すのは有益ではある。しかし、これらのグループ間の鍵となる差異というのもまた注目に値する。なぜならば、白紙の状態からデザインをやり直すことにして、新規ユーザーに適したやり方で、“片づけるべきジョブ”を解決しようとすれば、忠実な既存客のワークフローを大幅に変更することになるだろうからである（その結果、既存客の生産性に悪い影響を及ぼす可能性もある。その製品について学び直すことが彼らには必要になるからだ）。長年使われてきた機能のデザインを完全に変更してしまうと（あるいは、JTBDのフレームワークでよく推奨されるように、その課題に対して今までとまったく異なる革新的なソリューションを作り出してしまうと）、既存のユーザー基盤を損いかねないのである。
UX実践者は、さまざまなタイプのユーザー間で、デザインの検討事項のバランスをとる必要がある。ユーザーのタイプが違えば利害が対立することは多いからだ。たとえば、ドリルを買った人の“片づけるべきジョブ”は皆、同じで、物に穴を開けることであるわけだが、その人がプロの建築業者なら、関心があるのはドリルの耐久性だろう。その一方、家に何枚か絵をかけたいような人が気にするのは値段かもしれない。この2つの検討事項はお互い対立している。したがって、もし我々がこうしたユーザー同士を区別（そして、優先順位づけ）せずにこのジョブに対処しようとすると、おそらく、いかに革新的であっても、十分ではないソリューションを考え出してしまうことになるだろう。
“片づけるべきジョブ”が同じでも、ユーザーグループが変われば要件が変わってくる可能性はあるが、逆もまた真である。つまり、1つのユーザーグループ（ペルソナ）がさまざまなコンテキストのさまざまな仕事にその製品を「雇用する」可能性もあるのだ。たとえば、私は出張旅行にも休暇の旅行にも、同じ飛行機予約サイトを利用している。こうしたタイプの違う移動のJTBDは最終的には異なったものとなるので、それぞれの検討事項も非常に異なるものになるはずだ。しかし、どんな状況のために私がそのサイトを使っているにせよ、システムがどう動くかについてのメンタルモデルや態度に関する特徴、行動に関する特性については同じものを利用することになる。渡航先がNN/gのUXカンファレンスであっても、インカの道を歩くためのペルーであっても、だ。私の行動や態度は「一部の」ユーザーには類似しているだろうが、違うクラスターのユーザーとはかなり異なっている可能性が高い。我々がペルソナを複数作る理由がこれだ。ユーザー同士を区別する鍵になる要素をじっくり検討するためなのである。そうすれば、ペルソナ間でニーズのバランスを取り、ペルソナ同士の優先順位づけをおこなうことが可能になるからである。
ペルソナとJobs-to-Be-Doneは両立する
JTBDがペルソナに完全に取って代わるという反論は多いが、実際のところ、この2つはかなり両立する。組織のニーズと、チームがすでに利用しているのがペルソナなのか、JTBDなのかに合わせて、両者を補完的に利用することは可能だからだ。たとえば、“片づけるべきジョブ”の中心的な情報をペルソナに組み込めばよい。
組織がすでにJTBDを採用しているのなら、そこでおこなった同じ作業をペルソナでもおこなう必要はない。すなわち、各々のペルソナに当てはまる既存の“片づけるべきジョブ”を該当のペルソナの生成物に引用して、そのJTBDの機能や感情の成功基準をそのペルソナ固有の差別化情報として使えばよい。
もしあなた方の組織がすでにペルソナを使っているのに、効果的なペルソナの鍵である、目的や行動に関する情報が充実していないというなら、JTBD的な情報によって、ペルソナの生成物を補強するところから始めるとよい。つまり、ペルソナの目的を単にリストアップする代わりに、この情報を“片づけるべきジョブ”というフォーマットにすることを考え、次のように自問すればよい。このユーザーが達成しようとしていることは何か。そうしたジョブを（機能的にも感情的にも）成功させるための鍵となる検討事項とはどんなことだろうか、と。
ペルソナの作成に対して組織内で多くの抵抗があるが（たとえば、上層部から賛同を得ることに対して問題がある、懐疑的な同僚がいるなど）、ユーザー中心データを製品デザインに反映させるためのリソースも意欲もあるなら、JTBDは有益な代替手段となりうる。JTBDはビジネス関係の文献で多くの支持を得ている、新しく人気のある手法なので、皆も興味をもつだろうからだ。そして、ペルソナプロジェクトへの賛同が後になって得られた場合にも、こうして生み出されたJTBDは（上述のように）ペルソナと組み合わせていつでも利用が可能なのである。
要約
どんなデザインのユーザビリティも、誰がユーザーで、何を彼らはおこなう必要があるのか、という2つの変数に照らして評価することになる。だからこそ、ユーザビリティ調査の有効性のためには、ユーザーを代表するような人をテスト対象者としてリクルートし、代表的なタスクを実行してもらうことが非常に重要だ。あるデザインはあるカテゴリーのユーザーにとっては素晴らしいものかもしれないが、別のカテゴリーのユーザーには全然だめということもありうるので、不適切なユーザーでテストしてしまうと、実際の利用に関する情報がテスト結果から何も得られなくなってしまうからである。それとまったく同じ理由から、ターゲットオーディエンス、および、彼らのゴールの両方を我々は特定する必要がある。そうすれば、不適切なユーザーのためにデザインをしたり、不適切な機能を作り出すことはなくなる。UXのプロセスを成功させるためには、ユーザーとタスクの両方が必要なのである。
ペルソナとはシンプルなデモグラフィック属性やマーケティングセグメント以上のものである。ペルソナにはユーザーの目的やニーズ、問題点、期待に関する情報が豊富に含まれているが、こうした情報は物語のかたちを取ることでデザインチームの共感も誘ってくれる。“片づけるべきジョブ”は具体的なユーザーニーズを明確に表現するのに役立つ方法を提供してくれるが、こうした情報は適切に作成されたペルソナではすでに表現済みなのである。
