もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

ジョブ理論を活用する難しさについての雑記

プロダクトマネージャーの方々であれば、「ジョブ理論」を一度は耳にしたことがあると思います。

 

自分は以前、クレイトン・M・クリステンセン教授が著した書籍「ジョブ理論」を読んだ学びと、UX DAYS TOKYO 2018のJim Kalbach氏のJobs To Be Doneのワークショップにて得た学びを、こちらのスライドにまとめました。これが結構ご好評をいただいていました。

speakerdeck.com

 

こちらを先日少しアップデートしてツイートしたところ、興味を持っていただいたギルドワークスの@yohhatu さんからお声がけいただき、ジョブ理論の活用についてお話させていただきました。

 

この記事では、そのお話の中で盛り上がった「ジョブ理論を活用する難しさ」について備忘録的に書いていきます。

 

そもそもジョブ理論とは

↑のスライドをご参照ください(・∀・)

よろしければ感想をツイートしてください(・∀・)

 

その1:ジョブを見つける、評価する難しさ

書籍「ジョブ理論」の中で、ジョブは主にインタビューや観察にて見つけるとされています。つまり主に定性データを元にジョブを見つけていく必要があります。

個人的な考えですが、この定性データ分析には人間の思い込みやバイアスが大きく影響します。つまりインタビューで出てきたいくつかのジョブ候補に対して、フラットな評価が非常に難しいと考えています。

例えば、既に多くの時間をかけてある程度自信のある仮説ができてきた中で、その仮説に全く当てはまらないジョブ候補が出てきたときに、無意識のうちに「これはレアパターンだ」と捨ててしまうリスクがあります。これが定量データだと数字で顕在化するので無視しにくいのですが、定性データは分析・整理の過程でいくらでもバイアスを潜り込ませることができるので、より無視してしまうリスクが高いと思っています。無意識のうちに無理やり「既定路線」に着地させようとしていないか、自分自分を客観的にチェックする必要があります。

 

また、定性データを元に定めたジョブが本当に正しいのかどうかを、定量データと合わせて評価する必要があります。数字で効果が出ていないのであれば、そのジョブが間違っている可能性を疑わなくてはいけません。

この評価プロセスをUXデザイナー・UXリサーチャー・データサイエンティスト・エンジニアなどと協力してやっているPMの方も多いと思います。そのように複数人で定性分析と定量分析を分担している場合、ジョブを定義するに至った細かいコンテキストを全員で共有できていないと、正しい評価ができないリスクがあります。

 

例えばインタビューで得たインサイトとして

  • 忙しくて英語学習に時間をかけたくない
  • とりあえず最低限の会話ができるようになれればいい

で、それを元にジョブを『隙間時間の学習だけで英語が上達する』と定義したとします。

インサイトを把握した上で定量データで測るべき(=最大化すべき)指標を考えると、[上達率÷学習時間]、または[基準レベルに至るまでの期間の短さ]になるはずです。短時間で一定レベルまで上達することを望んでいるので。

ただこのインサイトを知らないでジョブの定義だけ知っている場合、学習時間、または上達率、もしくはその両方を指標とし、かつ基準を設けずに「とにかく多い方がいい」と評価しようとしてしまうかもしれません。こうなるとデータの取り方も変わり、PMがこのギャップに気づかないと正しく評価できなくなります。

 

少し極端な例でしたが、言いたいのはジョブを一言で定義してしまうと細かいコンテキストが失われてしまうので、ジョブの定義には最新の注意を払うべきだし、コンテキストも合わせて言語化し共有するべき、ということです。「そんなの簡単」と思われる方も多いかもしれませんが、ある程度大きい組織の場合、相当気合入れて伝えまくらないと、結構難しいと思っています。

 

 

その2:ジョブを組織に定着させる難しさ

特に既存プロダクトのリニューアル時にジョブ理論を活用する場合に注意する必要があるのですが、ジョブの解決と売上やユーザーの増加が必ずしも直接リンクするとは限りません。例えば、ライトユーザーにはなくヘビーユーザーだけが持つジョブを定義し、それに基づいてプロダクトリニューアルを進めた場合、短期的にはライトユーザーが離脱し、ユーザー数や売上を落とすことにつながります。プロダクト開発チームは長期的にはヘビーユーザーのLTVが上がるので問題ないと考えていますが、セールス部門やマーケティング部門はそうとは限りません。

ありがちなのは、評価制度の基準が目の前の数字になっている場合、プロダクト開発チームがいくら「長期的にはプラス」と言ったところで、短期的にでも数字が落ちることは許容されない可能性があります。

 

これに対するアプローチは組織状況によって様々ですが、個人的にはやはり泥臭くジョブ定義までのコンテキストと仮説の確からしさを伝えまくるしかないと思っています。そこには信頼貯金も必要になってきます。場合によっては評価制度を変えにいくところまでやる必要があると思います。でも難しいですよね…

 

その3:ジョブを正しく維持する難しさ

ジョブが一度見つかったら終わり、ということはありません。外的要因(市場や競合、社会の変化)によって、ジョブが変わる可能性は大いにあります。この変化が例えばAppleバルミューダのようなわかりやすい変化であればいいのですが、最も恐ろしいのは静かな変化によりゆっくりユーザーが離れていく状況です。

しかし、一度ジョブを見つけて明確な成果(売上やユーザー数)が出るようになると、気づけばジョブの解決そのものではなく目の前の数字ばかり追うようになってしまいます。「ジョブを解決しているから数字が伸びている」という因果関係において、「果」が伸びていれば「因」であるジョブの解決もできている、と見做してしまいます。人間はわかりやすいものが大好きなので。

そして気づいたら急に数字が伸びなくなり、慌ててジョブの再確認をしたら、既により魅力的な代替品で解決できている事実に気付いてピンチ…みたいなことが起こり得ます。日本のメーカーはこのように失敗してきたのかなと思います。

 

なので一度ジョブを見つけて成功軌道に乗ったからといって、ジョブを見つける活動をやめてはいけません。常にユーザーと接点を持ってジョブを見直し続ける必要があります。

 

 

終わりに

つまり言いたいのは、ジョブ理論は素晴らしい理論であることに間違いはないのですが、「この通りやればOK」のような便利フレームワークではなく、またジョブを見つけたからといって全てがうまくいくわけでもなく、うまく活用するにはそれなりの経験やスキル、信頼貯金や組織を動かす力が求められるし、時には泥臭いこともしながら進めていかなければならないよね、ということです。

 

特に何の希望もないオチになってしまいましたが、頑張っていきましょう。

逆にうまく活用できている事例をご存知の方がいれば、ぜひ教えてください。

またご意見、ご質問のある方もTwitterでご連絡ください。

【スポンサーリンク】