エンジニア向け!ユーザーが「やりたいこと」を見つけるJobs To Be Done(JTBD)入門と実践ツール
はじめに:機能開発の「なぜ」を深く理解する
ユーザー中心開発を意識する中で、「ユーザーのニーズを満たす機能を作っているはずなのに、なぜかあまり使われない」「ユーザーは本当にこの機能を求めているのか」といった疑問を感じたことはないでしょうか。プロダクト開発において、単に「何を」作るかだけでなく、「なぜ」ユーザーはそれを使いたいのか、その根底にある欲求や目的は何なのかを理解することは極めて重要です。
プログラミングスキルが高いエンジニアの皆様にとって、仕様通りに機能を実現することは得意な領域かもしれません。しかし、その仕様が本当にユーザーの課題を解決し、価値を提供できるものなのかを見極めるためには、より深いユーザー理解が求められます。
そこで本記事では、ユーザーの真のニーズ、「やりたいこと(Job)」に焦点を当てる「Jobs To Be Done(JTBD)」フレームワークをご紹介します。そして、このJTBDを理解し、日々の開発業務に活かすための考え方と、実践をサポートするツールについて解説します。
Jobs To Be Done(JTBD)とは何か
Jobs To Be Done(JTBD)は、ユーザーが特定の製品やサービスを「雇う(Hire)」のは、何か特定の「仕事(Job)」を片付けたいからだ、と考えるフレームワークです。ここで言う「仕事(Job)」とは、単なるタスクではなく、ユーザーが人生や仕事において達成したいと願う、より根本的な目的や欲求、あるいは困難な状況からの脱却といったものを指します。
例えば、ユーザーがドリルを買うのは、単に「穴」が欲しいからではなく、「壁に棚を取り付けて部屋を整理したい」「家族の写真を楽しみたい」といった、より大きな目的を達成するためです。ドリルは、その目的を達成するための「穴を開ける」という仕事を片付けるために「雇われた」ツールと見なせます。
JTBDは、ユーザーを特定の属性(年齢、性別、職業など)で捉えるペルソナとは異なり、ユーザーが置かれた「状況(Situation)」、「動機(Motivation)」、「期待される結果(Outcome)」に焦点を当てます。これにより、「どのような状況で、どのような動機から、どのような結果を得るために、ユーザーはその製品/サービスを利用(または利用しようと)するのか」という「なぜ」を深く掘り下げることができます。
エンジニアにとってJTBDが役立つ理由
JTBDの考え方は、特にエンジニアにとって以下のような点で非常に有用です。
- 機能開発の意義を理解できる: ユーザーが解決したい「ジョブ」を理解することで、開発する機能がそのジョブ達成にどのように貢献するのか、その意義を明確にできます。単なる仕様実装ではなく、ユーザー価値創造としての開発に意識を向けやすくなります。
- プロダクトの方向性を定めやすい: ユーザーのジョブを軸に考えることで、次にどのような機能が必要か、既存機能をどう改善すべきかといったプロダクトのロードマップ策定や優先順位付けに役立ちます。
- チーム内の共通理解を促進: チーム全体でユーザーのジョブを共有することで、共通の目的意識を持って開発に取り組むことができます。デザイナーやプロダクトマネージャーとの連携もスムーズになります。
- イノベーションのヒントを得られる: ユーザーが既存の方法でジョブをうまく片付けられていない「ペインポイント」を特定することで、全く新しい解決策(イノベーション)を生み出すヒントが得られます。
JTBD実践の基本的な進め方
JTBDを実践するには、いくつかのステップがあります。ここでは、エンジニアが一人でも、またはチームでも取り組める基本的な流れをご紹介します。
-
ユーザーの「ジョブ」に関するインサイトを収集する:
- ユーザーはどのような状況で、どのような課題に直面しているか?
- その課題を解決するために、現在どのような方法を使っているか?
- その方法に満足しているか、不満な点は何か?
- ジョブを片付けた後に、ユーザーはどのような状態になりたいと願っているか?(機能的な側面だけでなく、感情的、社会的な側面も含む)
- これらの問いに対する答えを、ユーザーインタビュー、アンケート、ユーザー行動データの分析、サポートへの問い合わせ内容分析などを通じて収集します。
-
収集したインサイトを整理し、「ジョブ」を定義する:
- 収集した断片的な情報から、ユーザーが達成しようとしている主要な「ジョブ」や、それを阻害している要因(ペインポイント)を特定します。
- 特定の状況と動機、期待される結果を組み合わせた「ジョブステートメント」を作成すると、ジョブをより明確に定義できます(例: 「〜という状況のとき、〜したいので、〜できる製品/サービスを雇う」)。
-
定義した「ジョブ」に基づいて開発や改善を検討する:
- 特定されたジョブが、現在のプロダクトでどの程度達成できているか評価します。
- ユーザーがジョブをより良く片付けられるようにするために、どのような機能や改善が必要かアイデアを発想します。
- 洗い出されたアイデアや機能を、ジョブの重要度やペインポイントの深刻さに基づいて優先順位付けします。
- ジョブの観点から、既存のユーザーストーリーやプロダクトバックログを見直し、必要に応じて修正します。
JTBD実践に役立つツールと手法
JTBDの実践自体は特定の高価なツールを必要とするものではありません。むしろ、ユーザーと向き合い、彼らの言葉や行動を深く観察・分析するための手法と、それを効率化・可視化するための汎用ツールが中心となります。
1. インサイト収集をサポートするツール
-
ユーザーインタビューツール:
- Zoom, Google Meetなどのビデオ会議ツール: リモートでのユーザーインタビューに必須です。録画機能を使えば、後からチームで内容を振り返るのに役立ちます。
- テープ起こしツール(例: Notta, AmiVoiceなど): インタビュー音声をテキスト化することで、情報整理や分析の効率が格段に向上します。無料または安価で利用できるサービスも増えています。
- アンケートツール(例: Google Forms, SurveyMonkeyなど): 広く浅くユーザーの状況や既存の解決策への満足度などを把握するのに役立ちます。JTBDの初期段階で、どのようなユーザーにインタビューすべきかのアタリをつけるためにも使えます。
-
行動データ分析ツール:
- Google Analytics, Amplitudeなどの定量分析ツール: ユーザーがプロダクト内でどのような行動をとっているか、どこで離脱しているかといった客観的なデータは、ユーザーが「やりたいこと」を達成できているか、あるいはどこでつまづいているかのヒントになります。
- ヒートマップ・セッションリプレイツール(例: Hotjar, Contentsquareなど): ユーザーが画面上でどこを見ているか、どのように操作しているかといった定性的な行動データを視覚的に把握できます。ユーザーがスムーズに目的を達成できているかを確認するのに役立ちます。
2. インサイト整理・「ジョブ」定義をサポートするツール
-
オンラインホワイトボードツール(例: Miro, FigJam, Muralなど):
- 収集したインタビューのメモ、アンケート結果、行動データのインサイトなどを一箇所に集約し、可視化するのに非常に適しています。
- 付箋機能を使って、ユーザーの発言や観察結果を書き出し、関連するもの同士をグルーピングしたり、時間軸に並べたりすることで、ユーザーの状況や動機、ペインポイントを構造的に整理できます。
- テンプレート機能を利用して、JTBDキャンバス(ユーザーの状況、ジョブ、ペインポイント、ゲインなどを整理するフレームワーク)を作成し、チームで共同編集しながらジョブを定義する作業を進めることができます。オンラインでのブレインストーミングやワークショップにも役立ちます。
-
マインドマップツール(例: XMind, Coggleなど):
- ユーザーの主要なジョブを中心に置き、それに関連するサブジョブや、ジョブを達成する上での様々な要素(状況、動機、感情、ペインポイント、ゲインなど)を枝分かれさせて構造的に整理するのに役立ちます。思考を発展させながら情報をまとめる際に有効です。
-
ドキュメント・情報共有ツール(例: Notion, Confluence, Google Docsなど):
- 定義したジョブステートメント、ジョブ分析結果、関連するユーザーインサイトなどをドキュメントとしてまとめ、チーム内で共有・蓄積するための基盤となります。これらの情報が共有されることで、エンジニアを含む開発チーム全体がユーザーの「やりたいこと」を共通認識として持つことができます。
3. JTBDを開発に組み込むためのツール
- プロジェクト管理ツール(例: Jira, Asana, Trelloなど):
- 定義したジョブや、それに基づいて検討された機能アイデア、改善点をタスクとして登録し、開発プロセスに組み込みます。
- ユーザーストーリーを記述する際に、「一人のユーザーとして、あるジョブを達成するために、特定の機能を利用したい」といったJTBDの視点を取り入れることで、よりユーザー価値に焦点を当てたバックログを作成できます。
実践のヒント:エンジニアがJTBDを始めるには
デザインやUXの専門知識が少ないエンジニアでも、JTBDの考え方を日々の業務に取り入れることは可能です。
- 小さなステップから始める: まずは自分が担当している機能や開発中のプロダクトについて、「この機能は、ユーザーのどのようなジョブを片付けるためにあるのだろうか?」と考えてみましょう。
- ユーザーの声を意識的に聞く: サポートに寄せられる問い合わせ内容、ユーザーレビュー、営業担当からのフィードバックなどに耳を傾け、「なぜ」ユーザーはそのような状況に置かれているのか、何に困っているのかを深掘りしてみましょう。
- チーム内で共有する: JTBDについて学んだことをチームメンバーに共有し、ユーザーのジョブについて話し合う時間を持つことを提案してみましょう。オンラインホワイトボードを使って、みんなでジョブを書き出してみるのも良いスタートになります。
- 既存ツールを活用する: 新しいツールを導入する前に、現在チームで使っているツール(オンラインホワイトボード、ドキュメントツール、プロジェクト管理ツールなど)をJTBDの視点でどう活用できるか検討してみましょう。
まとめ
Jobs To Be Done(JTBD)フレームワークは、ユーザーの表面的なニーズだけでなく、その根底にある「やりたいこと」や解決したい「ジョブ」を理解するための強力な考え方です。エンジニアがこの視点を持つことで、単なる仕様通りの機能実装から一歩進み、ユーザーに真の価値を届けるプロダクト開発に主体的に関わることができるようになります。
JTBDの実践には、高価な専用ツールは必ずしも必要ありません。ユーザーと向き合う姿勢と、それをサポートするインタビューツール、オンラインホワイトボード、ドキュメントツールといった汎用的なツールを組み合わせることで、十分に実践可能です。
ぜひ、本記事でご紹介したJTBDの考え方とツール活用方法を参考に、ユーザーの「なぜ」を深く理解し、プロダクト開発の質を高める一歩を踏み出してください。