最終更新: 2026/06/22 18:56
commonid: rq-049-result-geminitype: research-resultstatus: archived

RQ-049 調査結果 — Gemini Deep Research

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

サマリー（結論先行）

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

軸外部標準との整合判定
達成可能ゴール軸ODI（Ulwick）の Desired Outcomes と完全一致✓ Keep
実行時間軸純粋JTBD学術理論では直接支持なし。Shape Up「Appetite」として有効△ Rename推奨
担当役割軸ソロ開発では役割で境界線が引けない。Alan Klement「Job Story」の Context に書き換えるべき△ Modify必須
（新規追加）階層（Altitude）軸の追加を推奨 — Main Job / Sub-job の位置づけを明示+ Add推奨

提案: 3軸 → 4軸 JTBD ゲートウェイへアップデート

現行3軸テストアップデート後「4軸JTBDゲートウェイ」依拠する外部概念
1. 達成可能ゴール軸1. 成果（Outcome）軸 — 完了判定可能かつ技術手段（GAS等）を含まない表現かODI の Desired Outcomes
2. 実行時間軸2. 実行スコープ（Appetite）軸 — 1h〜3営業日で完結するサイズかShape Up の Appetite
3. 担当役割軸3. 状況・依存（Context & Dependency）軸 — 特定トリガーで始まり外部待ち時間なしに一気通貫で処理できるかAlan Klement の Job Stories（Who→When）
（新規追加）4. 階層（Altitude）軸 — Main Job か Sub-job か。Why/How 問いで上位ジョブとの関係が確認されているかUniversal Job Map / Kalbach

主な調査内容

JTBD 階層モデル（Kalbach）

4レベル分類:

  1. Aspirations（願望） — 「財務的に自由になる」等。マーケティング向け、製品開発の起点には広すぎる
  2. Main Job（Big Job） — 「個人事業の月次財務状況を正確に把握する」。明確な始まり・中間・終わりを持つプロセス
  3. Sub-job（Job Step） — Main Job を完了するために順立てて実行される個別ステップ。「銀行口座の取引履歴を収集する」等
  4. Micro-job — 従来の「タスク」に近い粒度。JTBDの文法で記述されるもの

粒度調整ヒューリスティック（Kalbach Why/How テスト）:

  • 広すぎる場合: 「どのように(How)それを行うのか？」→ Sub-job へ下りる
  • 狭すぎる場合: 「なぜ(Why)それを行うのか？」→ Main Job へ遡る

実行時間軸について

純粋なJTBD学術文献では時間基準は直接支持されない（ジョブは「特定のテクノロジー・ソリューション・時間的制約から独立して安定しているもの」）。しかし実務的には Shape Up の Appetite（許容期間） の概念と強くリンク。ユーザーの3軸テストはJTBDの抽象的な課題定義をShape Up的な解決空間へ橋渡しするメカニズムとして機能。

担当役割軸について（ソロ開発コンテキストの注意）

Alan Klement: 静的なペルソナ（「代表取締役として」）に基づいてジョブを定義することは、行動の真の動機を覆い隠すリスクがある。1人法人では全ジョブを代表者1名が実行するため「Who」軸では境界線を引けない。

推奨: 役割軸を 「コンテキスト境界（Context Boundary）軸」 として読み替える。

  • 「特定の状況（トリガー）から始まり、外部（税理士・銀行・取引先）からの返待ちや別システムへの物理的な移動などの分断を挟まずに一気通貫で処理できる一連のプロセスか？」という状況的な連続性を問うテスト

会計業務への適用と分解基準

業務JTBD での位置づけ判定
月次決算Main Job（Big Job）— 複数コンポーネントが絡み合う段階的プロセス実行時間軸には適合しない（大きすぎる）
銀行照合Sub-job — 月次決算を構成する Sub-job の一つ。独立したインプット・アウトカムが明確3軸テストに適合する適切な粒度
資金繰り予測Main Job〜Sub-job の中間文脈による
予実管理Main Job の可能性が高い分解検討が必要

Sub-job分解基準（Decomposition Criteria）:

  1. Boundary condition（インプット・アウトカム境界）: 外部からの固有インプットがあり完全に独立したアウトカムが出力されるポイント
  2. Exception logic（例外処理の分岐点）: ハッピーパスと例外処理フローが別の認知負荷と解決策を要求するポイント
  3. Handoff / Wait time（依存による待機）: 外部要因による物理的な時間差が発生するポイントでジョブを分割

遡及確認（Audit）手法

手法概要
Why/How テスト（Kalbach）「なぜ(Why)？」で上位ジョブへ、「どのように(How)？」で Sub-job へ接続できるか確認
Universal Job Map マッピング既存ジョブをUlwickのプロセスモデル（定義・場所の特定・準備・確認・実行・監視・修正・結論）のどのフェーズに属するかマッピング
Jargon Kill Switch「GAS」「スプレッドシートを開く」「APIを叩く」等の技術ジャーゴンが含まれていないかスクリーニング

類似の粒度判定フレームワーク: Granularity Gate（5次元）

次元内容
Actor（実行者）現行の役割軸に類似
Context（状況・文脈）そのジョブはどのような特定の状況で発生するか
Workaround（代替手段）理想的な解決策がない現在、ユーザーはどうしているか
Outcome（期待成果）現行の達成可能ゴール軸に完全一致
Evidence（証拠）実際のユーザー行動やインタビューでそのジョブの存在を裏付けるデータは何か

参照元

  1. Strategyn — The Innovation Process (Ulwick ODI): https://strategyn.com/outcome-driven-innovation-process/
  2. Tony Ulwick — ODI is JTBD Theory in Practice: https://jobs-to-be-done.com/outcome-driven-odi-is-jobs-to-be-done-theory-in-practice-2944c6ebc40e
  3. Jim Kalbach — What is JTBD: https://experiencinginformation.com/2020/12/29/what-is-jobs-to-be-done/
  4. Basecamp — Principles of Shaping (Shape Up): https://basecamp.com/shapeup/1.1.chapter-02
  5. Tony Ulwick — JTBD Original Framework: https://strategyn.com/jobs-to-be-done/
  6. Alan Klement — Replacing User Story With Job Story: https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27
  7. GitLab Handbook — Financial Planning & Analysis: https://handbook.gitlab.com/handbook/finance/financial-planning-and-analysis/
  8. Numeric — Bank Reconciliation Best Practices: https://www.numeric.io/blog/bank-reconciliation