Jobs To Be Doneの使い方

こんにちは、@yuichielectricです。現在、サイボウズでkintoneのプロダクトマネージャをやっています。このエントリは[Product Manager Advent Calendar 2016](http://qiita.com/advent-calendar/2016/productmanager)の12/17のエントリです。

私は3ヶ月前にプロダクトマネージャになったばかりで、プロダクトマネージャに必要なスキルや考え方について絶賛勉強中です。
その中で、Jobs To Be Doneという考え方が気になったので、本エントリでは

 - Jobs To Be Doneとはどういう考え方なのか
 - Jobs To Be Doneをどのように使うと良いのか

について、調べた情報をまとめてみたいと思います。

# Jobs To Be Doneとは

Jobs To Be Doneについては、tannomizukiさんの[「ペルソナ」を捨てて、JTBD（Jobs-To-Be-Done）モデルでターゲット顧客を定義せよ](http://tannomizuki.hatenablog.com/entry/2015/01/17/121251)というエントリでも言及されていまるミルクシェイクの例がわかりやすいです(これ自体は「[イノベーションへの解](https://www.amazon.co.jp/exec/obidos/ASIN/4798104930/myblogsite0b-22/)」からの引用です)。

> あるファストフード企業がミルクシェイクの売上を改善したいと思った。
> ミルクシェイクの購入者属性を整理し、同一の属性を持つ人を対象に、重めがいいか軽めがいいか、フルーツ味かチョコレート味か、など、どんなミルクシェイクが理想的か尋ねた。調査はうまく進み、特定したターゲットの好みをもとに製品を改善したが、売上は全く改善しなかった。
> 
> そこで別のチームが再び調査を行った。調査チームは店舗で来客を一日中観察した。すると早朝にミルクシェイクを買う客が多いことに気がついた。早朝の購入者になぜミルクシェイクを買ったかを尋ねると、
> 
> - 長い車通勤の間に片手で手間なく飲める
> - 一気に飲めないので暇つぶしになる
> - 腹持ちが良い
> 
> といった理由だとわかった。
> 
> この調査結果をもとに製品開発を再度行ったところ売上を改善することができた。

ここで重要なのは、早朝にミルクシェイクを購入しているのは「長い通勤時間で暇つぶしをしたい」という課題を解決するためだという点です。この解決したい課題のことを"Job To Be Done(以下JTBD)"と呼びます。プロダクトやサービスを開発する際には、この問題を解決する事にフォーカスすることで、人々に求められているサービスを作り出すことができる、というのがJTBDモデルの考え方です。

では、このJTBDモデルを自分たちのプロダクトに使おうと思った場合、どのようにJTBDを突き止めて、それをどう使ったら良いでしょうか。

# JTBDをどのように突き止めるか

JTBDを明確にするには、解決したい課題の機能的な側面だけではなく、感情面やその課題が発生する状況を **詳細に** 把握することが非常に重要になってきます。

例えば、冒頭のミルクシェイクの例だと課題の機能的な側面としては、"お腹が空いているので朝ごはんに何かが欲しい"といったものですが、感情面では"これから長い通勤時間を一人で過ごさなければならない。退屈だから何か暇つぶしになるようなものが欲しいなあ。でも、こんな朝早くからミルクシェイクを片手に通勤してるのを会社の同僚に見られたら恥ずかしいな"といった具合です。

こういった情報を多数のユーザーヒアリングや観察を通じて集めていき、共通のパターンを探っていきます。

このパターンを突き止められれば、例えば

 - より長持ちするように粘り気の強いミルクシェイクを作る
 - 他の人から見たらミルクシェイクを飲んでいると思われないような、大人っぽいデザインのパッケージにする

といった対策を取ることで、朝の通勤時間の暇つぶしをするというJTBDを持っている人にとってより魅力的なソリューションになる可能性が出てきます。

# JTBDをどのように活用するか

こういったJTBDを使ったサービス開発の方法論をもう少し具体的に落とし込んだものを調べてみた所、メンタルモデルダイアグラムからJTBDを洗い出す手法を紹介しているこちらの[A Practical Model for Jobs To Be Done (JTBD)](https://experiencinginformation.wordpress.com/2016/10/23/a-practical-model-for-jobs-to-be-done-jtbd/)というエントリが参考になりました。
このエントリは[デザイニング・ウェブナビゲーション](https://www.amazon.co.jp/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%8B%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%A6%E3%82%A7%E3%83%96%E3%83%8A%E3%83%93%E3%82%B2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3-_%E6%9C%80%E9%81%A9%E3%81%AA%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9A%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9%E3%81%AE%E8%A8%AD%E8%A8%88-James-Kalbach/dp/4873114101/ref=sr_1_fkmr0_2?ie=UTF8&qid=1481977853&sr=8-2-fkmr0&keywords=Jim+Kalbach)や[Mapping Experiences](https://www.amazon.co.jp/Mapping-Experiences-Complete-Creating-Blueprints-ebook/dp/B01F9Y6B9K/ref=sr_1_fkmr0_1?ie=UTF8&qid=1481977853&sr=8-1-fkmr0&keywords=Jim+Kalbach)の著者であるJim Kalbachさんによるものです。

このエントリでは次の4つの手順でJTBDを突き止め、活用していく手法が紹介されています。

> 1. Understand the market
> 2. Design for the market
> 3. Talk to the market
> 4. (Re)define markets

ここからはこの4つのステップをまとめてみます。

## Understand the market

このエントリでは、ユーザーヒアリングや観察を行って得られたデータを次の6つにカテゴライズします。

 - 機能的な側面
 - 感情的な側面
 - 周りの人との関係性の側面
 - 課題が発生する状況
 - 課題を解決するモチベーション
 - 課題を解決するために望ましい成果

そして、これらのデータをメンタルモデルダイアグラムやカスタマージャーニーマップの形で表現し、どのJTBDが解決すべき領域かを可視化していきます。

## Design for the market


このようにして得られたJTBDから、今度は解決策を検討していきます。そこで、解決すべきJTBDをジョブストーリーという形式にまとめます。

ジョブストーリーは[Replacing The User Story With The Job Story](http://alanklement.blogspot.jp/2013/09/replacing-user-story-with-job-story.html)というエントリで紹介されている手法で、JTBDを簡潔に表現するための方法です。

![](https://experiencinginformation.files.wordpress.com/2016/10/b63f0-better-user-story.png?w=710)

この形式でJTBDをまとめた後、デザインスプリントやブレインストーミングを行って、どういった解決策をとるべきか、検討していきます。

## Talk to the market

マーケティングやヘルプドキュメントなどでもJTBDを使って効果的にメッセージを伝えることができます。

例えば、MURALというプロダクトではヘルプドキュメントをJTBDの構成で記載しています。

![](https://experiencinginformation.files.wordpress.com/2016/10/jtbd-help-desk.jpg?w=710)

## (Re)define markets

顧客セグメントも例えばユーザーの住んでいる地域や年齢、家族構成などといった属性でセグメント分けするのではなく、その人が持っているJTBDでセグメント分けすることで、より効果的な経営戦略を立てることができるようになります。

# JTBDをより良いものにするために

このようにJTBDを突き止めて、それを解決するためのサービスを提供しても、うまくいかないこともあります。その場合はJTBDの理解がまだ浅い可能性があります。

その際に重要になってくるのが、契約してくれたユーザーや、解約してしまったユーザーへのヒアリングを詳細に行うことで、ユーザーのJTBDの理解を更に深めることです。

この辺りの話は、[Doing SaaS Cancellation Interviews (the Jobs-to-be-Done Way)](http://www.extendslogic.com/business/jobs-to-be-done-cancel-interviews/)というエントリが非常に具体的で参考になったのですが、長くなってしまったのでまた後日まとめてみようと思います。

# 最後に

まだまだ実際に自分のプロダクトでこれらの手法を試していないので、正直うまく理解できていない部分や、実行しようとしたときの難しさがまだわかっていない部分も多いのですが、何か参考になる部分があれば幸いです！

# 参考
 - [Competing against Luck](https://www.amazon.co.jp/dp/B01BBPZIHM/): クリステンセンさんによるJTBDについて書いた本。今年出たばかりで最近の実例や、JTBDを企業の中でどう使っていくかといった話に言及されている。
 - [ジョブ理論　イノベーションを予測可能にする消費のメカニズム] (https://www.amazon.co.jp/gp/product/B0746JCN8B/) (2017/08/14追記) 上記の"Competing against Luck"の日本語訳が出たようです。 
 - [Combining Mental Model Diagrams and Jobs To Be Done](https://experiencinginformation.wordpress.com/2016/12/11/combining-mental-model-diagrams-and-jobs-to-be-done/): Jim KalbachさんによるメンタルモデルダイアグラムとJTBDをあわせて使う手法の実例を紹介したエントリ。題材としてGoToMeetingを扱っている。