RQ-049 調査結果 — Claude Deep Research
調査日: 2026-05-15 モデル: Claude Deep Research 対象: JTBD粒度定義の外部標準と「3軸テスト」の妥当性検証
サマリー(結論先行)
現行の3軸テストは外部ベストプラクティスと部分的整合(Partial)。
| 軸 | 外部標準との整合 | 判定 |
|---|---|---|
| 達成可能ゴール軸 | Ulwick "Desired Outcome Statement" (direction + metric + object + clarifier) および Kalbach "end state" 原則と整合 | ✓ Keep(文言強化を推奨) |
| 実行時間軸(1h〜3営業日) | JTBD 一次文献では支持されない。Ulwick 中心原則は "stable over time"。Shape Up "appetite" / Scrum sprint と同じ開発スコーピング領域 | ✗ 別レイヤーへ分離 |
| 担当役割軸 | Ulwick "Job Executor" 概念と部分整合。ソロ法人代表では識別力が低い。"Job Executor Consistency"(複数ロール混在の有無)として再定義が必要 | △ Modify必須 |
| (追加推奨) | Solution-free、Stable-over-time、Syntax、Functional/Emotional/Social の3次元網羅、Wake-up-in-the-morning Test、Job Map 分解可能性 | + Add推奨 |
提案: 3軸 → 6軸テストへアップデート(実行時間軸は Appetite レイヤーへ分離)
| # | 軸名 | 判定基準 | 依拠する外部概念 |
|---|---|---|---|
| 1 | End-State 軸 | 完了判定可能なアウトカム(Direction + Metric + Object of control)が定義できる | Ulwick ODI Desired Outcome Statement |
| 2 | Solution-Free 軸 | 解決手段(GAS/スプレッドシート等)に依存しない文言で書ける | Ulwick "devoid of solutions" |
| 3 | Stable-over-Time 軸 | 技術・法令変化で陳腐化しない | Ulwick "stable over time" |
| 4 | Syntax 軸 | Verb + Object + Contextual Clarifier の構文を満たす | Ulwick / Christensen Job Statement 構文 |
| 5 | Job Executor Consistency 軸 | 単一の Job Executor ロールで一貫実行可能(複数ロールが分断するなら別ジョブ) | Ulwick Job Map ステップ分析 |
| 6 | Job Map Decomposability 軸 | 8ステップ(Define→Locate→Prepare→Confirm→Execute→Monitor→Modify→Conclude)に分解可能で、各ステップが Main Job レベルでない | Bettencourt & Ulwick Universal Job Map |
実行時間軸(1h〜3営業日)は上記6軸を満たしたジョブを実装サイクルに割り付ける段階で別途用いる「Appetite 軸」として分離管理する。
主な調査内容
Q1: JTBD 粒度の学術・業界標準
原著者ごとの階層モデル
Anthony Ulwick(Strategyn / "Jobs to be Done: Theory to Practice" 2016)
- 粒度を明示的に「Core Functional Job → Job Steps → Desired Outcomes」の3階層で定義。Related Jobs / Emotional / Social Jobs / Consumption Chain Jobs / Purchase Decision Job を別カテゴリで添える
- Job Statement 構文: 「verb + object of the verb (noun) + contextual clarifier」
- 例: 「listen to music while on the go」「cut a piece of wood in a straight line」「monitor a patient's vital signs」
- Job Map(8ステップ): Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude(Bettencourt & Ulwick, HBR 2008)
- Strategyn は「1つの Core Functional Job 全体が概ね10〜20ステップから構成される」と明記
Clayton Christensen("Competing Against Luck" HarperBusiness, 2016)
- ジョブの定義: 「the progress that a person is trying to make in a particular circumstance」
- 粒度に明示的な階層を与えず、相対的に語る: 「Some jobs are little (pass the time); some are big (find a more fulfilling career)」
- 粒度に関する唯一の規範的言及: 「Defining the job at the right level of abstraction is critical to ensuring that the theory is useful」(具体的閾値は提示せず)
- Functional / Emotional / Social の3次元を捉えられる粒度を要請
Alan Klement("When Coffee and Kale Compete" 2016)
- 階層化を否定し「ジョブには種類はない」と主張、ジョブを「progress(進歩)」として一元化
- 必須要件は粒度ではなく「struggling moment(葛藤の瞬間)」の存在
Jim Kalbach("The Jobs To Be Done Playbook" Rosenfeld Media, 2020)
- 階層を最も明示的に体系化:
- Aspirations(願望) — イノベーションの起点には不適
- Main Job / Target Job — 「a process with a beginning, middle, and end」。粒度判定の中心
- Sub-jobs / Job Steps — Main Job をプロセスとして分解した連続ステップ
- ナビゲーション原則: 「Ask 'why?' to go up and 'how?' to go down」
- 粒度設定は「judgment(判断)」であり、「a job that you can reasonably affect(合理的に影響を与えられる粒度)」を推奨
Bob Moesta("Demand-Side Sales 101" 2020)
- 粒度における最大の落とし穴は抽象度調整の失敗
- 推奨: 1製品/サービスにつき「three to five clear JTBDs」
- 「broad enough to group large segments with similar circumstances but tight enough that you cannot fit people from different circumstances into the same 'job'」
時間軸基準(1回の実行で完結する)の支持
結論: JTBD 一次文献では時間軸での粒度基準は支持されない。
- Ulwick の中心原則は「stable over time」: 「A Job-to-be-Done is stable over time」「functional jobs ... have been trying to accomplish for years, decades and in some cases even centuries」
- Desired Outcome も同様に「devoid of solutions, stable over time, measurable, controllable, structured for reliable prioritization in a quantitative customer survey」
- 時間軸での粒度基準は Shape Up "appetite" に類似する概念だが、これは JTBD ではなく開発スコーピングの方法論
SAFe / Scrum / Shape Up との粒度対応
| 開発方法論 | 対応概念 | 備考 |
|---|---|---|
| SAFe | Epic → Capability → Feature → User Story | JTBD との直接マッピングは公式ドキュメントに存在しない |
| Shape Up | Appetite: Small Batch(1〜2週間)/ Big Batch(6週間) | "narrow down the problem definition" アプローチは Kalbach の "how?" 下方移動と整合 |
| Scrum | 6名チームで6〜9 User Story/sprint(INVEST 原則) | Cohn は Job Story を User Story の代替として推奨 |
Q2: 3軸テストの妥当性検証
「達成可能アウトカム」軸 ↔ Ulwick "Desired Outcomes"
整合。 Ulwick の Outcome Statement 構文は厳密に4要素: 「Verb (minimize/maximize) + metric + object of control + contextual clarifier」
- 依頼者の「業務完了判定可能なアウトカムが存在する」基準は "direction of improvement" 部分と「measurable, controllable」原則に適合
- ただし改善方向(minimize/maximize)と単位(time/likelihood/effort)まで明示することが望ましい
- Kalbach は「main jobs should reflect an end state」と明記し、「manage」「maintain」「keep up」「learn」のような終了状態のない動詞を避けるべきとする
「担当役割が単一」軸 ↔ Ulwick "Job Executor"
部分的整合・要修正。
- Ulwick は Job Executor を Job Beneficiary・Product Lifecycle Support Team・Buyer の3つから区別。B2Cでは同一人物が3役を兼ねるが、B2Bでは分離が常態
- 依頼者のソロ法人代表ケースでは Job Executor = Job Beneficiary = Buyer がすべて同一となり、軸として識別力をほぼ持たない
- ただし、業務分解(job step)レベルで「単一の役割が通しで実行可能か」を問うのは、Ulwick の Job Map ステップ分析と整合。複数ロールが介在するサブステップは「consumption chain jobs」や「co-job executors」の概念に近づくため、別ジョブに切り出す根拠になる
- 推奨修正: 「担当役割軸」を「Job Executor Consistency(実行者一貫性)」と再定義し、複数ロール(例: データ入力者ロール vs. 経営判断者ロール)が介在する場合は別ジョブに分解する判定軸として運用
類似の粒度判定フレームワーク
| フレームワーク | 内容 |
|---|---|
| thrv "Wake-up-in-the-morning Test" | 朝起きて「今日これをやらねば」と感じる粒度か。感じなければ aspiration か job step |
| Teresa Torres "Opportunity Solution Tree" | Opportunity → Solution → Test の4階層。"teeny tiny opportunity" に分解する原則 |
| Google Ventures Design Sprint "How Might We" | 「not so broad it generates nothing useful, not so narrow it closes off ideas」 |
| Kalbach "Why?/How?" altitude test | 上方(why?)に登りすぎていないか、下方(how?)に降りすぎていないか |
Q3: JTBD 粒度ミスの影響と管理パターン
大きすぎる/小さすぎる場合の下流影響
Bob Moesta (Re-Wired Group) の整理:
- 抽象度が高すぎる例: CEO が「Our job is to help people be more productive」→ 「you're competing with everything from coffee to meditation apps」。競合定義が破綻しペルソナ・調査スコープが拡散
- 抽象度が低すぎる例: 「build something that has too narrow a market」。市場サイズが過小で投資回収不可
Ulwick "How To Fail At Jobs-to-be-Done":
- ジョブ定義のみで止まる失敗: ジョブを知るだけでは粒度レベルでの customer needs は分からない
- Buyer の Job と User の Job の混同は B2B で頻発する典型的粒度ミス
SSOT 管理パターン(業界実態)
- GitLab(公開ハンドブック)が現時点で最も体系的な SSOT 公開実装例。JTBD Canvas を Jim Kalbach の Playbook プロセスに沿って FigJam テンプレートで管理し、製品 Stage ごとに「Validated JTBD Canvases and Opportunity Scores」ページを保持
- 更新ガバナンス(GitLab 方式): Product Management + Product Design + Engineering の合議で書き出し、Research Ops チームがリクルーティングを支援、Job Performer インタビューで検証
- Jim Kalbach JTBD Hypothesis Canvas: Playing field / Job performer / Focus job / Job steps / Success criteria の5要素で1枚キャンバスを構成。「Stick to one job performer per canvas」が運用ルール
遡及確認(Audit)手法
「Job Atomic Test」という名称は Ulwick / Christensen / Klement / Kalbach の一次文献に存在しない。以下が等価機能を果たす:
| 手法 | 概要 |
|---|---|
| Ulwick の6特性 | desired outcomes are devoid of solutions, stable over time, measurable, controllable, structured for reliable prioritization, tied to the underlying process |
| thrv の4ステップ Audit | (1) 顧客視点か、(2) 動詞+直接目的語の単純文か、(3) 解決手段を含まないか、(4) Wake-up-in-the-morning Test を通過するか |
| Kalbach の "Why?/How?" altitude test | 上方(why?)に登りすぎていないか、下方(how?)に降りすぎていないか |
| 良い動詞 / 悪い動詞(thrv.com) | 良い: determine, understand, learn, acquire, enable, ensure, optimize, create, teach, instill, develop, buy, sell, obtain, identify, detect, mitigate, diagnose, treat, cure, prevent |
Q4: 会計業務への JTBD 適用
既存事例
- Bob Moesta + Autobooks: 会計領域で最も具体的に公開された JTBD 事例。主ジョブ: 「add a simple and trackable way to get paid into an existing system」
- Strategyn 銀行/金融サービス例: 「manage daily cash flow」を Core Functional Job として、budgeting tool・低残高アラート・入金/支払いリマインダーを Outcome 単位で設計
- Reese Harper("The Advisor"): 財務領域で Ulwick 構文を厳密に適用。Job statement: 「Examine qualified retirement accounts for suitability and contributions」、対応 Outcome: 「Maximize the tax benefits I receive from qualified plan contributions」
会計業務の粒度判定(依頼者の暫定ジョブ群の評価)
Kalbach の階層と Ulwick の「verb + object + contextual clarifier」基準で評価:
| 候補ジョブ文 | Ulwick 粒度判定 | コメント |
|---|---|---|
| "Get monthly close done"(月次決算を終わらせる) | Main Job 妥当 | 終了状態あり、stable over time。改善案: 「Close the monthly books on time for the period」と書き直すと object と contextual clarifier が明確化 |
| "Reconcile bank account"(銀行照合する) | Main Job または Sub-job 境界 | 月次決算の Job Map 内の "Confirm" + "Modify" ステップに該当しうる。独立 Main Job として扱うなら「Reconcile bank transactions for the accounting period」と context を明示 |
| "Match transaction to invoice"(取引を請求書に紐付ける) | Job Step(サブ) | 単一動詞だが Ulwick Job Map の "Execute" ステップに相当。独立 Main Job として運用すると粒度が低すぎる |
| "Forecast cash flow"(資金繰り予測) | Main Job 妥当 | 終了状態あり、Strategyn 銀行事例 "manage daily cash flow" と整合。「Forecast cash flow for the next quarter」と context 追加で更に明確化 |
| "Compare budget vs. actual"(予実比較) | Main Job 妥当 | "Compare" は活性動詞、context("for the current fiscal period")を加えれば完成 |
運用推奨:
- Main Job として SSOT 登録: 「月次決算」「資金繰り予測」「予実比較」
- Sub-job(Job Step)として配下に整理: 「銀行照合」「取引と請求書の照合」「仕訳入力」を各 Main Job の Job Map ステップ(Define→Locate→Prepare→Confirm→Execute→Monitor→Modify→Conclude)にマッピング
- 各 Main Job に対し Desired Outcome(minimize the time / minimize the likelihood of errors / maximize the accuracy of...)を5〜15個ぶら下げる構造。Ulwick の理想(50〜150)には及ばないが、ソロ法人運用では5〜15が実用閾値
現行3軸テストへの具体的改善提案
維持すべき点
- 達成可能ゴール軸: Ulwick Outcome Statement の方向性・Christensen の "progress" 概念・Kalbach の "end state" 原則と整合。そのまま維持
- 担当役割軸(再定義版): ソロ業務でも、Job Executor が複数ロールに切り替わるサブタスクを別ジョブに分ける指針として再利用可能
修正すべき点
- 実行時間軸(1時間〜3営業日): JTBD 一次文献では時間ではなく "stable over time" と "discrete process with a beginning, middle, and end" が基準。時間軸を JTBD 粒度判定基準から外し、開発スコーピング(Shape Up Appetite / Sprint 単位)の判定軸として別レイヤーに移管することを推奨。Main Job 単位を月次/週次/日次の実行頻度で分類する「実行サイクル軸」に置き換える方が文献整合性が高い
- ゴール軸の文言: 「明確なアウトカムが存在する」を「Direction of improvement(minimize/maximize)+ measurable metric が明示できる」に強化
- 役割軸の文言: 「単一の役割(代表者1名)が実行できる」を「Job Executor Consistency: 単一の Job Executor ロールで一貫実行可能(複数ロールが分断するなら別ジョブ)」に変更
追加すべき点
- Solution-free 軸: ジョブ文に「GAS」「Google Sheets」「マクロ」「freee」等の解決手段名が含まれていないか。含まれていれば粒度ではなくカテゴリエラーとして書き直す
- Stable-over-time 軸: そのジョブ定義が技術変化や法令変更で陳腐化しないか。「freee の API で〜」は不可、「期末の試算表を作成する」は可
- Syntax 軸: Ulwick 形式「verb + object + contextual clarifier」または Christensen 形式「When [situation], I want to [motivation], so I can [outcome]」のいずれかに統一
- Functional / Emotional / Social 三次元軸: ソロ法人代表でも社会的次元(「顧問税理士に見せても恥ずかしくない帳簿状態を保つ」)と感情的次元(「税務調査に怯えずに済む安心感を得る」)を Related Jobs として併記することで、機能要件のみのジョブ定義よりも下流の機能優先度判断が向上(Christensen の3次元論と整合)
- Wake-up-in-the-morning Test: 朝起きて「今日これをやらねば」と感じる粒度か(thrv)。感じなければ aspiration(願望)レベルに高すぎる、または job step レベルに低すぎる
- Job Map Decomposability 軸: そのジョブを Define→Locate→Prepare→Confirm→Execute→Monitor→Modify→Conclude の8ステップに分解可能で、なお各ステップが Main Job レベルになっていないか。分解できないなら sub-job 候補
注意事項(Caveats)
- 会計・バックオフィス業務に JTBD を直接適用した学術論文(HBR / MIT Sloan 査読相当)は本調査では確認できず。一次資料は Strategyn の金融サービス事例と Bob Moesta の Autobooks / Intuit 講演事例が中心で、エビデンス階層としては実務事例レベル
- Christensen / Klement / Ulwick の三者は粒度の議論で明確に異なる立場を取る。本報告は実装フレンドリーな「Ulwick + Kalbach の階層派」を実務基準として採用
- 3軸テストの「時間軸」は JTBD ではなく Shape Up "appetite" / Scrum sprint / SAFe PI などの開発スコーピング軸と整合する。レイヤー分離の運用を強く推奨
- 「Job Atomic Test」という名称は Ulwick / Christensen / Klement / Kalbach の一次文献に存在しない。thrv の "Wake-up-in-the-morning Test" + Ulwick の6 Characteristics + Kalbach の "Why?/How? altitude test" を組み合わせた監査手順を等価機能として推奨
参照元(一次文献・最優先)
- Anthony Ulwick, Jobs to be Done: Theory to Practice (IDEA BITE PRESS, 2016)
- Lance Bettencourt & Anthony Ulwick, "The Customer-Centered Innovation Map" (Harvard Business Review, May 2008)
- Clayton Christensen, Taddy Hall, Karen Dillon & David S. Duncan, Competing Against Luck (HarperBusiness, 2016) および HBR "Know Your Customers' Jobs to Be Done" (Sep 2016)
- Alan Klement, When Coffee and Kale Compete (NYC Publishing, 2016)
- Jim Kalbach, The Jobs To Be Done Playbook (Rosenfeld Media, 2020)
- Bob Moesta & Greg Engle, Demand-Side Sales 101 (Lioncrest, 2020)
- Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021)
実務補助参照: Strategyn (strategyn.com), jobs-to-be-done.com (Ulwick Medium), Re-Wired Group (therewiredgroup.com), thrv.com, Mountain Goat Software (mountaingoatsoftware.com), Basecamp Shape Up (basecamp.com/shapeup), GitLab Handbook (handbook.gitlab.com), JTBD Toolkit (jtbdtoolkit.medium.com)