job-stories

ジョブストーリーの専門家

概要

Jobs-to-Be-Done（JTBD）フレームワークを使ってジョブストーリーを作成します。役割に焦点を当てる従来のユーザーストーリー（「ユーザーとして……」）とは異なり、ジョブストーリーは状況、動機、望ましい結果に焦点を当てます。この転換により、実際のユーザーの状況に根ざした要件が生まれ、ユーザーがどのような人かについての思い込みが入り込む可能性も低くなります。

形式は When [situation], I want to [motivation], so I can [outcome]. です。役割を取り除き、状況を説明することが重要なのは、同じ人でも状況が異なればニーズも異なり、同じ状況にいる人々は共通のニーズを持ち、役割が抽象的なラベルである一方、状況は観察・検証できるためです。

主な機能

• JTBD発見キャンバス — 機能的・社会的・感情的なジョブ、ペイン、ゲインを洗い出し、それぞれをジョブストーリーの要素に対応付けます。
• ストーリーの作成 — 具体的で、ソリューションに依存せず、ベネフィットを重視した状況、動機、結果を記述します。
• 品質チェック — 6つのINVEST基準を適用し、各ストーリーについて結果を重視した受け入れ条件を6～8件作成します。
• 変換とファシリテーション — 従来のユーザーストーリーをジョブストーリーに変換し、ストーリー作成ワークショップを実施します。

使用する場面

• 機能の定義 -- ユーザーの状況に根ざして、何を、なぜ作るのかを明確にする必要があるとき。
• バックログの作成 -- ユーザーの成果に焦点を当てた作業項目をバックログに追加するとき。
• 要件ワークショップ -- 関係者と協力して「完了」の状態を定義するとき。
• デザインブリーフ -- 機能の背景にある状況や動機をデザイナーに伝えるとき。

使用しない場面

• ビジネスの背景を含む戦略的なバックログ項目が必要な場合は、代わりに wwas/ を使用してください。
• ユーザーストーリー形式にすでに慣れているチーム向けに、簡潔なストーリーが必要な場合。
• 作業が純粋に技術的で、ユーザーが直接関わる状況がない場合。

まず確認すること

ジョブストーリーを作成する前に、以下の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 状況／きっかけ — 「When」がストーリー全体の軸になります。状況が曖昧だと、ペルソナ形式のストーリーを装ったものになります。
• 根底にあるジョブと動機 — 「I want to」の背景にある機能的・社会的・感情的なジョブです。これがないと、ストーリーはニーズではなくソリューションを記述してしまいます。
• 望ましい結果／進捗 — ユーザーが到達しようとしている「so I can」の部分です。結果を重視した受け入れ条件の基盤となります。
• ユーザー調査の情報源 — インタビュー、観察、サポートデータに基づくものか、それとも推測かを確認します。根拠がなければ、状況が作り上げられ、現実を反映しない可能性があります。

中断ルール：出力に最も影響する2～3項目だけを質問してください。ユーザーが「とにかく下書きを作って」と言った場合は作成を進め、成果物の冒頭に前提を列挙してください。

クイックスタート

When [situation], I want to [motivation], so I can [outcome].

1. JTBD発見キャンバスを実施する（または調査結果を活用する）ことで、ジョブ・ペイン・ゲインのクラスターを見つけます。
2. 各クラスターについて、When／Want／Soの形式でジョブストーリーを1つ作成します。
3. INVESTを適用し、SmallまたはIndependentの基準を満たさないストーリーは分割します。
4. 各ストーリーに、観察可能で結果を重視した受け入れ条件を6～8件追加します。

参考資料

タスクに合った参考資料を読み込んでください。このファイルは簡潔に保ち、必要に応じて詳細を参照してください。

• references/job-stories-playbook.md — 全手順：JTBD発見キャンバスのテンプレートと、キャンバスからストーリーへのマッピング、フォーマットの詳細、記述品質の表、INVESTの表、ストーリーカードのテンプレート、受け入れ基準のガイドライン、実例、トラブルシューティング、成功基準が含まれます。ストーリーを作成または改善するときに読んでください。
• references/jtbd-guide.md — JTBDの理論、ジョブストーリーとユーザーストーリーの比較、状況を発見する手法、ストーリーの分割方法が含まれます。フレームワークを理解したり、使用するストーリー形式を決めたりするときに読んでください。
• references/red-flags.md — ジョブストーリーでよくある問題を、悪い例・良い例と見つけ方とともに解説します。ストーリーをスプリント計画に進める前に読んでください。
• assets/job_story_template.md — すぐに使えるジョブストーリーカードのテンプレートです。ストーリーの下書きに使用してください。

範囲と制限

対象範囲： JTBDの「When/Want/So」形式を使ったジョブストーリーの作成、INVEST品質基準の適用、成果に焦点を当てた受け入れ基準の記述、既存のユーザーストーリーからジョブストーリーへの変換、ストーリー作成ワークショップの進行、ジョブストーリーとJiraバックログ項目の統合。

対象外： ビジネスコンテキストを含む戦略的なバックログ項目（wwas/に引き継いでください）、プロダクトのアイデア創出と機会の発見（discovery/brainstorm-ideas/に引き継いでください）、詳細な技術仕様、UXリサーチとユーザーインタビューの手法。

制限： ジョブストーリーは、チームが実際のユーザーリサーチ（インタビュー、観察、サポートデータ）を利用できる場合に最も効果を発揮します。ユーザーのコンテキストがなければ、実態を反映していない状況をチームが作り出してしまう可能性があります。ユーザーの状況に直接結び付かない純粋な技術作業やインフラ作業では、この形式はあまり自然ではありません。ジョブストーリーとユーザーストーリーは相互に補完するものであり、作業の種類に応じて両方の形式を使うチームもあります。

統合ポイント

統合	方向	受け渡される内容
wwas/	補完	WWASは戦略的な「Why」のコンテキストを補い、ジョブストーリーは状況に応じた「When」のコンテキストを加えます。必要に応じて両方を使ってください
summarize-meeting/	ミーティング -> ストーリー	発見に関する会話やリファインメントのセッションから、ジョブストーリーの参考となる状況が得られます
../jira-expert/	ストーリー -> Jira	完成したジョブストーリーは、構造化された説明を含むJiraチケットになります
discovery/brainstorm-ideas/	アイデア -> ストーリー	検証済みのプロダクトアイデアを、バックログ用のジョブストーリーに分解します
execution/brainstorm-okrs/	OKR -> ストーリー	チームの目標によって、ジョブストーリーが結び付くべき成果が定まります
execution/prioritization-frameworks/	ストーリー -> 優先順位付け	スプリント計画に向けて、RICEなどのフレームワークでジョブストーリーを評価します