Jobs to be Doneフレームワークの正しい使い方

よくある誤用 — ペルソナの言い換えになっている

プロダクトチームがJTBDを導入するとき、最も多い失敗は「ジョブ」を単なる属性の書き換えとして扱ってしまうことです。たとえば「30代のマーケティング担当者は、レポート作成を効率化したい」というジョブ・ステートメントをよく見かけますが、これは年齢と職種というペルソナ属性に「効率化したい」という一般的な願望を貼り付けただけで、JTBDが本来問うている因果構造を含んでいません。Clayton Christensenが提唱したJTBDの出発点は、顧客が製品やサービスを「雇用（hire）」する背景には、特定の状況で生じる進歩（progress）への欲求があるという考え方です。誰であるかではなく、どんな状況に置かれ、何を成し遂げようとしていたかが主語になります。

原典が示す因果構造

Christensenが著書『Competing Against Luck』で紹介したミルクシェイクの調査は、この違いを説明する代表例としてよく引用されます。同じミルクシェイクという商品でも、朝の通勤中に「長い運転を退屈させず、片手で腹持ちさせる」ために買われる場合と、夕方に子どもへのご褒美として買われる場合とでは、顧客が期待する体積・粘度・提供速度がまったく異なるというものです。ここでの「ジョブ」は年齢や性別ではなく、状況（朝の通勤／夕方の外食後）と、そこで達成したい進歩（退屈しのぎと満腹感／子どもを喜ばせる）の組み合わせで定義されています。属性ではなく状況と進歩を主語に置く、これがJTBDの核です。

ジョブ・ステートメントの正しい書き方

実務でよく使われる型は、状況・動機・期待する結果の3要素を明示する形式です。

状況（When...）: いつ、どんな文脈で
動機（I want to...）: 何をしたい／進めたいのか
期待する結果（So I can...）: それによって何を得たいのか

例:
When 週次の定例会議までに複数チームの進捗をまとめる必要があるとき、
I want to 各ツールに散らばったデータを1画面で確認したい、
So I can 会議前の資料作成にかかる時間を減らし、議論の準備に時間を使いたい。

この形式にすると「レポート機能が欲しい」という機能要望と、「会議前の準備時間を減らしたい」という進歩への欲求を区別できます。機能要望はソリューションの一案にすぎず、同じジョブに対して複数の解決策があり得ます。

Tony UlwickのOutcome-Driven Innovationとの違い

JTBDの実務展開にはいくつかの流派があります。Tony Ulwickが提唱するOutcome-Driven Innovation（ODI）は、ジョブを構成する「望ましい結果（desired outcome）」を定量的に測定可能な文で分解し、重要度と現状の満足度のギャップでスコアリングする点に特徴があります。Christensenの定性的な因果理解に対し、Ulwickの方法はより定量調査に寄せた運用と言えます。どちらを採るかはチームが持っているデータと意思決定のスタイル次第であり、優劣で語れるものではありません。もっとも、ODIは大規模な定量調査を前提とするため、初期段階のプロダクトでいきなり導入するのは負荷が大きく、まずは定性的なジョブ・ステートメントの整理から始めるチームが多いのが実情です。

JTBDが効く場面、効かない場面

JTBDが強く機能するのは、既存の使われ方の背後にある動機を掘り下げ、代替手段との競合構造を把握したい場面です。「自社製品は何と競合しているのか」を問うと、同業他社だけでなくExcelや手作業、"何もしない"という選択肢まで競合として浮かび上がることがあります。これは機能比較の表では見えない気づきです。一方で、UIの細部の使い勝手や操作フローの改善のように、すでに使うと決めた後の体験を最適化する場面では、JTBDよりもユーザビリティテストや行動ログの分析の方が直接的に効きます。ジョブは「なぜ雇用したか」を説明しますが、「雇用した後どう感じたか」までは説明しません。JTBDを万能の分析フレームとして持ち出すこと自体が、もう一つの誤用です。

次に読む

ジョブ・ステートメントの元になる発言を集める具体的な手順はユーザーインタビューの設計と実施で解説しています。ジョブの理解をポジショニングに接続する方法はポジショニングと差別化の戦略を参照してください。