dogfooding

ドッグフーディング

対象範囲

対象

• プロダクトチームが実際のユーザーと同じようにプロダクトを使う、ドッグフーディングのサイクルを設計して実施する
• プロダクトがクリエイター向けの場合、「クリエイターとしてのコミットメント」を設定する（例：ポッドキャストを公開する、ワークフローをリリースする、週次レポートを実行する）
• 問題を「なんとなく」ではなく、再現可能な成果物として記録する：ログ、重大度、判断、担当者、そして対応状況

使用する場面

• 「プロダクトチーム向けに、ドッグフーディングのプログラム／スプリントを設定してください。」
• 「もうすぐリリースです。毎日プロダクトを使い、最も大きな課題を確実に解消できるようにしてください。」
• 「これはクリエイター向けに作りました。ワークフローを理解するために、チーム自身がクリエイターになる必要があります。」
• 「社内ベータ版の計画と、週次ドッグフーディングレポートのテンプレートを作成してください。」

使用しない場面

• 市場の需要を検証したい、または顧客は誰か／課題は何かを明らかにしたい場合（まずディスカバリーを行ってください）
• 代理の参加者なしでは、プロダクトチームが現実的にワークフローを再現できない場合（例：規制対象の職種、ハードウェアの制約）
• ユーザーリサーチの代替を求めている場合（ドッグフーディングは外部からのユーザーフィードバックを補完するものであり、置き換えるものではありません）
• 唯一の目標が「すべてを QA する」ことである場合（QA／テスト計画を使用してください。ドッグフーディングの対象は体験＋価値＋現実的なワークフローです）

入力

最低限必要な情報

• プロダクトの概要＋対象ユーザーのペルソナ（誰向けか、どのような仕事をするか）
• ドッグフーディングの対象となる主要なワークフローを1～3個（エンドツーエンド）
• 期間＋頻度（例：1週間のスプリント、1日20分、週次トリアージ）
• 参加者（役割）＋必要な「クリエイターとしてのコミットメント」
• 環境上の制約（本番環境かステージング環境か、データ／プライバシーの制約、アクセスの制約）

情報不足時の対応

• references/INTAKE.mdから最大5つの質問をしてください。
• 回答が得られない場合は、明示的な前提を置いて進め、不明点にラベルを付けてください。2つのスコープ案（簡易版と詳細版）を提示してください。

成果物

Markdown形式のドッグフーディングパックを作成します（チャット内、または希望があればファイルとして作成）。

1. コンテキストの概要（プロダクト、ペルソナ、ワークフロー、制約、期間）
2. ドッグフーディング憲章（目標、参加者、ルール、頻度、定義）
3. シナリオマップ＋ルーティン（日次／週次のタスク＋「クリエイターとしてのコミットメント」）
4. ドッグフーディングログ＋トリアージボードの仕様（フィールド、重大度スケール、判断ルール）
5. 週次ドッグフーディングレポート（インサイト、判断、リリース済みの修正、次の実験）
6. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md

ワークフロー（7ステップ）

1) ドッグフーディングの目標を設定する（バグだけでなく体験を重視）

• 入力： プロダクトの概要、望ましい成果、references/INTAKE.md。
• アクション： 今回のサイクルにおける「成功」の定義を決めます（例：「チームが回避策を使わずに10分以内でワークフローAを完了できる」）。制約（環境、データ、アクセス）を設定します。
• 成果物： コンテキストの概要＋明確な成功基準。
• 確認事項： 成功基準は測定可能で、実際のワークフローの成果に結び付いていること（「気分がよくなる」ではありません）。

2) 代表的なシナリオ＋「クリエイターとしてのコミットメント」を定義する

• 入力： 対象ユーザーのペルソナ＋ワークフロー。
• アクション： 実際のユーザーの目標を反映したシナリオを3～8個作成します。プロダクトがクリエイター向けの場合は、公開頻度を定義します（例：「各PMが毎週1つの成果物を公開する」）。
• 成果物： シナリオマップ＋ルーティン計画。
• 確認事項： 少なくとも1つのシナリオが、「ゼロから作成→リリース／公開」までのエンドツーエンドであること。

3) 記録システムを設定する（ログ、重大度、トリアージ）

• 入力： 既存のツール（Jira／Linear／Notion／Sheets）または「なし」。
• アクション： ドッグフーディングログのスキーマ、重大度スケール、トリアージルールを定義します。問題をシナリオやワークフローの手順に関連付けるラベル／タグを決めます。
• 成果物： ドッグフーディングログ＋トリアージボードの仕様。
• 確認事項： どの問題も、「再現手順＋期待される結果と実際の結果＋証拠」が明確で、再現できること。

4) 毎日のドッグフーディングセッションを実施する（時間を区切る）

• 入力： シナリオマップ＋ルーティン。
• アクション： 各参加者が1日に1〜2個のシナリオを実行し、つまずきをすぐに記録して、証拠（画面、ログ、タイムスタンプ）を添付します。「使用した回避策」も記録します。
• 出力： 毎日のログエントリー＋随時更新する「主な課題」リスト。
• 確認事項： エントリーには具体的な再現手順が記載され、ワークフローの完了への影響度に基づいて優先順位が付けられています。

5) 毎週トリアージを行い、判断・割り当て・集中力を守る

• 入力： ログ＋主な課題。
• アクション： トリアージを実施します。重複項目をまとめ、分類（バグ／UX上の負債／不足／ドキュメント）し、担当者を割り当て、「今すぐ修正／予定に組み込む／修正しない（理由を添える）」を決定します。シナリオマップが現実的でなかった場合は更新します。
• 出力： 優先順位付きバックログ＋判断メモ。
• 確認事項： 上位3〜5件の課題が、妨げられている、または遅くなっているシナリオに直接対応しており、担当者と次のアクションが決まっています。

6) リリースサイクル：再度ドッグフーディングを行って修正を検証する（リリース禁止ゲート）

• 入力： 「今すぐ修正」項目＋リリース計画。
• アクション： 修正ごとに、シナリオを最初から最後まで再実行します。シンプルなゲートを適用します。「選択した環境で、隠れた回避策を使わずにシナリオを完了できること。」
• 出力： 検証済み修正のリスト＋回帰。
• 確認事項： ゲートの基準はシナリオの完了であり、チケットをクローズしただけではありません。

7) 報告＋品質ゲート＋次のサイクルの計画

• 入力： 最終ログ＋トリアージの結果。
• アクション： 週次レポートを作成します。references/CHECKLISTS.mdを実施し、references/RUBRIC.mdで評価します。リスク／未解決の質問／次のステップを追加し、次のドッグフーディングサイクルで重点的に取り組む内容を提案します。
• 出力： 最終ドッグフーディングパック。
• 確認事項： レポートには判断（何を変更したか）が記載され、証拠に基づく学びが示されています（単なるバグ一覧ではありません）。

品質ゲート（必須）

• references/CHECKLISTS.mdとreferences/RUBRIC.mdを使用します。
• リスク、未解決の質問、次のステップを必ず含めます。

例

例1（クリエイター向けプロダクト）：「ポッドキャスト制作ツールを開発しています。チーム全員が毎週短いエピソードを1本公開するドッグフーディングプログラムを作成し、週次レポートのテンプレートも用意してください。」
期待される内容：「アイデア→エピソード公開」のシナリオ、クリエイターのコミットメント、ログのスキーマ、トリアージの頻度、公開に結び付いたリリースゲート。

例2（B2Bワークフロープロダクト）：「AI会議メモツールを対象に、『記録→要約→共有→アクションアイテム』に焦点を当てた2週間のドッグフーディングスプリントを設定してください。」
期待される内容：シナリオマップ、毎日のルーティン、重大度の尺度、トリアージのルール、週次レポート、検証済み修正のリスト。

境界例：「まだ開発していないこのアイデアをドッグフーディングしてください。」
回答：ドッグフーディングには使用可能な成果物が必要です。まずディスカバリーとプロトタイプ／ユーザビリティテストを提案し、最初から最後まで実行できるものが用意できてからドッグフーディングスプリントを実施します。