RQ-049 調査結果 — ChatGPT Deep Research

調査日: 2026-05-15 モデル: ChatGPT (GPT-4o) Deep Research 対象: JTBD粒度定義の外部標準と「3軸テスト」の妥当性検証

サマリー（結論先行）

現行の3軸テストは外部ベストプラクティスと部分的整合（Partial）。

提案: 「4+1 軸」へのアップデート

主な調査内容

Q1: JTBD 粒度の学術・業界標準

統一世界標準はない — 共通点は「階層がある」こと

文献を横断すると、JTBD の粒度に単一の世界標準命名法はない。ただし共通しているのは「階層がある」こと。

• Christensen 系: job は「特定の状況で成し遂げたい progress」。HBR 論文でも jobs には "little" も "big" もあると説明。ジョブサイズに固定の時間閾値を置くより、何の progress を、どの circumstance で、何をもって done とみなすか が先に来る
• Moesta (Re-Wired Group): 良い JTBD は高すぎても低すぎてもダメ。too high だと製品カテゴリのように広すぎ、too low だと「2〜3人にしか当てはまらない」局所タスクになる。1つの製品や市場理解で扱うべき JTBD は 3〜5個程度の「ジャギッドな中間」 に在る。job は会社ではなく人に属し、しかも person-specific ではなく moment-in-time specific
• Klement 系: 高レベル job とそれを支える smaller jobs を区別して feature 設計に落とし込む。Main Job 自体と、その job を解くための設計レベルの小さなジョブは意識的に分けられている
• Ulwick / Strategyn 系: core functional job を起点に、job executor を定義し、job を discrete process steps に分解する job map を作り、各 step について desired outcomes を集める。Strategyn 流の粒度モデルは概ね core functional job → job map steps / sub-process → desired outcomes
• GitLab (業界実装): Main Job は clear end state を持つ timeless functional goal、Small Jobs は workflow/process に近い粒度、Micro-jobs は small tasks。後年の業界実装であり、Christensen や Moesta の原典そのものの世界標準語彙ではない

時間軸基準の支持について

「1回の実行が1時間〜3営業日」という発想は、JTBD 文献全体で見ると部分的には支持されるが中核基準ではない。

• Cockburn の use case 研究が「同じ目標に関する相互作用が、トリガーから目標達成または放棄まで続く」とするため、1 execution instance を完結単位で捉えるという考え方に近いものがある
• ただし JTBD 原典は時間よりも 安定した progress / solution-agnostic / right level of abstraction を重視。実行時間そのもので JTBD の否を決めるより、成果の独立性、価値の完結性、状況の一貫性、desired outcomes の一貫性 で判断するほうが文献には近い
• 実務的には時間軸は 分析単位の appetite として有効。Shape Up は raw idea を評価するときに appetite = time budget を置き、fixed time, variable scope でプロジェクトを整形する。Scrum も Product Backlog Item を 1 Sprint で Done できる粒度まで碎く。時間で切ること自体は業界で一般的だが、それは job discovery の理論軸ではなく delivery planning の運用軸

SAFe / Scrum / Shape Up との粒度対応

• JTBD は基本的に problem space、Epic / Feature / Story は solution space、Use Case は interaction space と見なすのが最も整合的
• SAFe の Epic / Feature / Story は JTBD そのものではなく、JTBD に応えるためのソリューション階層
• Scrum 文脈では、JTBD は Product Goal や複数 PBI を束ねる上位の discovery lens として扱うのが自然。ユーザーストーリーの粒度と JTBD を同一視しないほうが安全
• Use Case の user-goal level は3軸テストのうち完了判定可能と 1 execution で閉じるにかなり近く、JTBD の sub-job や execution instance に最も近い外部フレーム
• Shape Up は JTBD と直接対応する標準ではないが、「どの問題にどれだけ賭けるか」を決める delivery-scoping の規範として参考になる。あくまで ソリューション bet の粒度管理 であって、JTBD 自体の粒度定義ではない

Q2: 3軸テストの妥当性検証

「達成可能アウトカムが存在する」軸 ↔ ODI desired outcomes

整合。 Strategyn は customer needs を「customers use to measure success when getting the job done」という metrics として定義しており、desired outcome statement は measurable, stable over time, solution-agnostic であることが重要だと説明している。Salesforce の Trailhead も JTBD の共通原則として measurable outcomes を挙げている。「終わったかどうか判定できる」は JTBD/ODI で言う成功条件を言語化できることとほぼ同義。

ただし外部標準に寄せるなら、単に「達成可能ゴールがある」だけでなく、どの desired outcomes で達成を測るか まで踏み込むと精度が上がる。ODI では1つの core job に対して多数の outcome metrics を集め、job map の各 step で成功を分ける。つまり "done" の有無だけでなく「どうすれば better/faster/cheaper になったと言えるか」まで出せるか を追加すると研究と ADR の品質が上がる。

「担当役割が単一である」軸 ↔ Job Executor

部分的整合・要修正。

• Strategyn は job executor を「core functional job を行う人」とし、buyer・installer・maintainer などは別の立場として分けている。GitLab も Job Performer は職種そのものではなく、特定 job を実行する役割であり、必要なら related job performers を別に記録するとしている。「一つの job の主語は誰か」を固定するのは、むしろ外部標準に近い
• 注意すべきは、Moesta が明言するように jobs are held by people, not companies だという点。自社の開発担当が1人だからといって、その1人で customer job を定義してしまうと本来の JTBD から外れる
• ソロ開発・個人事業の文脈では、役割軸を customer-side の primary job performer と internal-side の accountable owner に分けるのが安全。前者はジョブの主語、後者はその JTBD を研究・設計・実装する責任者
• 内部向けには「単一人員で通し実行できる」よりも、「外部承認待ちや役割切替なしで一つの認知フローとして完遂できる」と定義したほうが使いやすい。Strategyn の related jobs / other actors の考え方と GitLab の related job performers の整理に沿った実務的拡張

既存の類似フレームワーク

• 調査した範囲では、あなたの3軸テストと同一構造の既成フレームワークは見当たらなかった。ただし近縁なものは明確にある: JTBD 側では solution agnostic / stable over time / measurable outcomes が質の高い job 定義の軸であり、Cockburn の use case では same goal / trigger-to-goal completion が境界ルール
• 現行3軸テストは「文献そのまま」ではなく、複数ベストプラクティスの合成 と説明するのが最も正確。合成の質自体は悪くない。完了アウトカムと役割の一体化は use case / JTBD の橋渡しとして有効で、時間軸だけを JTBD 本体から分離すれば、かなり説得力が増す

Q3: 粒度ミスの影響と管理パターン

大きすぎる / 小さすぎる場合の下流影響

• JTBD が大きすぎると Moesta の言う「too high」に落ち、誰にでも当てはまりそうで、実は何を優先すべきか決められない状態になる。下流では research question が広がりすぎて interview が拡散し、desired outcomes がぼやけ、機能要件は「何でも入る」方向に膨らむ。過大粒度は discovery と prioritization の両方を曖昧にする
• JTBD が小さすぎると Moesta の「too low」の問題が起き、適用対象が極端に局所的になる。Klement が user stories を批判する理由の一つも、implementation と motivation/outcome が結びつきすぎて context を見失うことだった。GitLab の Main Job / Small Jobs / Micro-jobs の区別を借りれば、micro-job を Main Job と誤認すると、リサーチは局所改善に閉じ、機能開発はチケット工場化しやすい

SSOT 管理パターン（業界実態）

• 業界実践は 「中央リポジトリ + タクソノミー + 共有ビュー + 検証済みアウトプット」 に収斂
• Dovetail は research repository を centralized database と定義し、raw data, docs, reports, observations, insights を一箇所に集約し、metadata / version control / taxonomy / tag key themes / project lead / source of truth を整備することを推奨
• GitLab の実践は JTBD を FigJam canvas で作成し、検証済みのものを Handbook page として管理し、さらに Validated JTBD Canvases and Opportunity Scores へつなぐ構成。ファイル形式は固定されていないが、パターンとしては canvas 原本、共有ハンドブック / wiki、優先度や outcome score の一覧を分け、どれが下書きでどれが validated かを区別するのが有力
• 更新頻度についても、外部標準は固定 cadence より継続追加 + 検証時更新に寄っている。job 自体は stable に保ちつつ、outcomes / evidence / status を更新する設計が文献整合的

遡及確認（Audit）手法

実務上の audit 手順は次の5問で十分:

1. その job は verb + object (+ clarifier) で表現され、solution-specific ではないか
2. 主 job performer は1人に定まるか
3. job map として離散的な steps を描けるか
4. 成功を測る desired outcomes を置けるか
5. delivery に落とすときは Scrum / Shape Up の timebox に収まるか

これらのうち最初の4問が JTBD 監査、最後の1問が運用監査。特に Strategyn の worksheet は job steps は solution agnostic で distinct structure を持つべきだと明示しており、GitLab も no AND/OR, clear end state, broad enough to allow innovation を強調している。

Q4: 会計・バックオフィス業務への JTBD 適用

既存事例

• Re-Wired Group の Autobooks 事例: invoice・payments・accounting・financial reports を扱う integrated platform に対して JTBD を適用し、見込み客の job/timeline に応じて3種類のデモに作り替えた結果、lead conversion が倍増し、close time が半減したと報告。「同じ会計プロダクトでも、顧客は異なる job で hiring する」ことを示す直接的なケース
• Strategyn の金融サービス例: 顧客のメイン job を「manage daily cash flow」として捉え、cash flow を理想的にどう管理するか、その各 step で何をもって成功とみなすかを明らかにして、新しい checking account に付随するツールや支援を設計。バックオフィス系 JTBD が「機能名」ではなく「継続的な財務進捗の管理 job」として表現しやすいことを示している

会計業務の粒度判定

分解基準のまとめ（GPT推奨）:

• 独立した完了判定が複数あるなら split
• time horizon が違うなら split
• 主 job performer や関連 actor が変わるなら split
• desired outcomes の束が変わるなら split
• 逆に言えば、1つの statement に対して1つの job map と1組の主要 outcomes が素直に引けるなら、その粒度はかなり良い

現行3軸テストへの具体的改善提案

維持すべき点

• 達成可能ゴール軸: ODI の desired outcomes と直接つながるため、「この job が終わったと判定できるか」はそのまま残してよい
• 担当役割軸: customer-side の primary job performer と internal-side の accountable owner を分けて使うなら維持価値がある。特にソロ開発では owner が1人であること自体より、handoff なしで通せる認知フローを見る 実務基準として活きる

修正すべき点

• 実行時間軸: 「JTBD 妥当性軸」から外し、「運用アペタイト軸」に改名するのが最重要。理由は JTBD 文献の中核は時間ではなく安定した progress / solution agnostic / measurable outcomes / right abstraction だから。「この単位は JTBD として正しいか」と「この単位は今のリサーチ/設計/実装サイクルに載るか」を分離した方が、理論的にも運用的にも明瞭

追加すべき点

外部標準との整合性を高めるには、少なくとも次の2点を追加すべき:

1. 安定・非解決策軸: job statement が products, features, screens, tools に依存せず、時間が経っても成立するかを確認
2. 抽象度適正軸: Moesta の「too high / too low」を避け、Strategyn のいう core job と discrete steps が引ける水準に置けているかを見る

必要なら第三に job map / desired outcomes 監査 を追加し、steps と outcomes を素直に引ける job だけを SSOT の validated JTBD に昇格させる運用がよい。

参照元

1. Clayton Christensen Institute, Jobs to Be Done Theory — christenseninstitute.org
2. Clayton M. Christensen et al., "Know Your Customers' Jobs to Be Done", Harvard Business Review, 2016
3. Bob Moesta / Re-Wired Group, What is the Jobs To Be Done framework? — therewiredgroup.com
4. Re-Wired Group, Diagnosing the Autobooks Demo + Sales Process — therewiredgroup.com/case-studies/autobooks/
5. Alan Klement, Designing features using Job Stories, Intercom, 2013
6. Alan Klement, Replacing The User Story With The Job Story, jtbd.info, 2013
7. Strategyn, Build Your Job Map — strategyn.com
8. Strategyn, Understanding Customer Needs: The JTBD Approach — strategyn.com
9. Strategyn, Jobs-to-be-Done Examples and Applications — strategyn.com
10. Alistair Cockburn, Structuring Use Cases with Goals, 1995/1999
11. Basecamp / Ryan Singer, Shape Up, 2019 — basecamp.com/shapeup
12. Scaled Agile, Epic; Features and Capabilities — scaledagileframework.com
13. Scrum Guides, The 2020 Scrum Guide — scrumguides.org
14. GitLab Handbook, Jobs to be Done at GitLab — handbook.gitlab.com
15. GitLab Handbook, Anatomy of a JTBD Canvas — handbook.gitlab.com
16. Dovetail, What is a Research Repository? — dovetail.com
17. Mercury, How to build a month-end close process — mercury.com
18. QuickBooks, What is Bank Reconciliation? — quickbooks.intuit.com
19. Fathom, What is cash flow forecasting? — fathomhq.com
20. Tipaliti, Budget Versus Actual: Understanding Budget Variances — tipaliti.com
21. CFO.com, Metric of the Month: Cycle Time for Monthly Close — cfo.com