product-operations

プロダクトオペレーション

対象範囲

対象

• 説明責任、境界、「仕事の進め方」を明確にするプロダクトオペレーション憲章を定義する
• PM が力を発揮できる仕組みを構築する：定例、標準化された成果物、意思決定支援（意思決定そのものではありません）
• 摩擦や予期せぬ事態を減らすための部門横断インターフェース（プロダクト ↔ オペレーション／営業／CS／エンジニアリング／データ／サポート）を整備する
• プロダクトチームが適切なタイミングで適切なシグナルを得られるよう、インサイトのパイプライン（定性＋定量）を構築する
• リリース＋イネーブルメントを運用化する：リリース準備、社内コミュニケーション、トレーニング、フィードバックループ

使用する場合

• 「プロダクトオペレーションが必要です。ここでの役割と担当範囲を定義してください。」
• 「プロダクトチームが拡大しています。標準的なロードマップ／チェックインと、より良い運営リズムが必要です。」
• 「PM は調整業務に追われています。負荷を減らす仕組みを整えてください。」
• 「リリースイネーブルメントのプロセス（準備、コミュニケーション、トレーニング、フィードバック）を作成してください。」
• 「プロダクト／CS／営業全体で、繰り返し実行できるインサイト → 意思決定のパイプラインが必要です。」

使用しない場合

• 何を構築するかを選ぶ必要がある場合（prioritizing-roadmap／defining-product-visionを使用）
• 指標／OKR をゼロから定義する必要がある場合（writing-north-star-metrics／setting-okrs-goalsを使用）
• 意思決定に必要な PRD を作成する場合（writing-prdsを使用）、または実装可能な仕様書を作成する場合（writing-specs-designsを使用）
• 顧客の深い探索、インタビュー、ユーザビリティテストが必要な場合（conducting-user-interviews／usability-testingを使用）

入力

最低限必要な情報

• プロダクト組織の状況：段階、チーム構成、主な摩擦（「規模の拡大に伴い、何がうまくいかなくなっていますか？」）
• 現在の計画／リリースのリズム（あれば）：ロードマップ／OKR のサイクル、リリースプロセス、コミュニケーションの接点
• 主な関係者：プロダクト／エンジニアリング／データ／オペレーション／営業／CS／サポート、および意思決定者
• 期待する成果：プロダクトオペレーションの導入後、何がより簡単／迅速／明確になるべきか
• 制約：コンプライアンス／プライバシー、ツールの制限、リソース、スケジュール

情報不足時の方針

• references/INTAKE.mdから最大5つの質問をします。
• 回答が得られない場合は、明示的な前提を置いて進め、不明点にラベルを付けます。

出力（成果物）

Markdown 形式でプロダクトオペレーション運用システムパックを作成します（チャット内、またはユーザーの希望に応じてファイルで提供）。

1. プロダクトオペレーション憲章（ミッション、対象範囲、対象外、成功指標）
2. 運用モデル（連携モデル、RACI／担当範囲、組み込み型と集中型のアプローチ）
3. 定例＋儀式（主要なレビュー／チェックインの予定、アジェンダ＋成果物）
4. 標準成果物一式（ロードマップの更新、意思決定ログ、プロダクトの更新、ローンチイネーブルメントのテンプレート）
5. インサイトのパイプライン（情報源、分類体系、受付／トリアージ、ダッシュボード、フィードバックループ）
6. リリースイネーブルメントシステム（準備チェックリスト、コミュニケーション計画、トレーニング、ローンチ後の情報収集）
7. 30／60／90 日の導入計画（パイロット、展開、測定、反復）
8. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md
詳細なガイダンス：references/WORKFLOW.md

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

1) 受付＋課題の整理（規模の拡大に伴い、何がうまくいかなくなっているか）

• **入力：**ユーザーの依頼、references/INTAKE.md。
• **アクション：**組織の段階、主な摩擦点トップ3、関係者、既存の定例、期待する成果を明確にします。
• **出力：**状況の概要＋解決すべき主な課題（優先順位付き）。
• **確認事項：**次のような課題を1文で説明できます。「プロダクトオペレーションは、<チーム>の<摩擦>を減らし、<成果>を向上させるために存在します。」

2) プロダクトオペレーション憲章を定義する（境界＋成功）

• **入力：**状況の概要、制約、関係者。
• **アクション：**ミッション、対象範囲、対象外、成功指標の草案を作成します。プロダクトオペレーションは意思決定に情報を提供し、意思決定権はPMが保持することを明記します。
• **出力：**プロダクトオペレーション憲章（v1）。
• **確認事項：**憲章に、担当範囲、担当しない範囲、連携方法、価値の測定方法が記載されています。

3) インターフェースとオーナーシップを明確にする（コラボレーションを明示する）

• 入力： 現在のワークフロー、ステークホルダーマップ。
• アクション： インターフェース（プロダクト ↔ エンジニアリング／データ／オペレーション／営業／カスタマーサクセス／サポート）を整理します。計画、リリース、コミュニケーション、インサイトについて、RACI と「誰が何を決めるのか」を定義します。
• 成果物： オペレーティングモデル（ドラフト）＋ RACI テーブル。
• 確認事項： 「非公式なオーナーシップ」がないこと。定期的に発生するすべての意思決定／成果物に、明確なオーナーとエスカレーション経路があること。

4) 運用のケイデンスを設計する（成果物を生み出す定例）

• 入力： チャーター、RACI、現在のカレンダー。
• アクション： アジェンダ、参加者、必須の成果物を含め、最小限のケイデンス（週次／隔週／月次／四半期ごと）を定義します。
• 成果物： ケイデンスカレンダー＋会議成果物の仕様。
• 確認事項： 各定例が具体的な成果物／更新を生み出すこと。「会議だけ」のものは削除するか、再設計すること。

5) 成果物を標準化する（プロダクト業務を可視化する）

• 入力： 既存ドキュメント、ステークホルダーのニーズ、ケイデンスで生じる成果物。
• アクション： 標準的な成果物一式（ロードマップの更新、意思決定ログ、週次プロダクトアップデート、ローンチ概要、イネーブルメントバンドル）を定義します。テンプレートとオーナーを用意します。
• 成果物： 成果物ライブラリ＋テンプレート一覧。
• 確認事項： 成果物が簡潔で、繰り返し利用でき、受け手に合わせて調整されていること。

6) インサイトのパイプラインを構築する（適切なシグナルを適切な場へ）

• 入力： データソース、フィードバックチャネル、リサーチプロセス。
• アクション： インテーク／トリアージ、分類体系、適切な場（プロダクト領域のオーナー、計画サイクル、リリースの振り返り）への振り分けを作成します。ダッシュボード／定期レポートを指定します。
• 成果物： インサイトパイプラインの仕様＋バックログのトリアージ方法。
• 確認事項： 新しいシグナルにオーナーと受け入れ先があり、明確な「意思決定経路」が定義されていること（フィードバックが放置されないこと）。

7) リリースとイネーブルメントを運用に組み込む（リリース準備体制）

• 入力： 現在のリリースプロセス、成果物一式。
• アクション： 準備状況チェックリスト、コミュニケーション／イネーブルメントのワークフロー、ローンチ後の情報収集（見逃された問題、サポート負荷、学び）を定義します。リリースの段階に応じた規模にします。
• 成果物： リリースイネーブルメントシステム＋チェックリスト＋コミュニケーション用テンプレート。
• 確認事項： どのリリースについても、誰に知らせる必要があるか、何が変わるか、どう監視するか、どうロールバック／影響を軽減するかを答えられること。

8) 実装して反復する（パイロット → 展開 → 測定）

• 入力： ドラフト一式、リソース、タイムライン。
• アクション： 30／60／90 日計画を作成し、パイロット領域を選び、2～4 サイクルにわたってケイデンスを実施し、フィードバックを集めて調整します。
• 成果物： 30／60／90 日計画＋測定計画＋改善バックログ。
• 確認事項： 少なくとも 1 つの測定可能な改善目標（サイクルタイム、ステークホルダーの満足度、予期せぬ事態の減少、PM の負担軽減）を設定すること。

品質ゲート（必須）

• references/CHECKLISTS.md と references/RUBRIC.md を使用してください。
• 必ず Risks、Open questions、Next steps を含めてください。

例

例 1（規模拡大）：「PM が 6 人から 18 人に増え、混乱してきました。Product Ops の運用ケイデンスを整備し、ロードマップの更新を標準化して、インサイトパイプラインを構築してください。」
期待される成果：チャーター＋ケイデンス＋テンプレート＋30／60／90 日展開計画。

例 2（リリース＋イネーブルメント）：「ローンチのたびにサポートと営業が不意を突かれます。準備状況の確認とコミュニケーションワークフローを含む、リリースイネーブルメントシステムを作成してください。」
期待される成果：リリースの段階分け＋準備状況チェックリスト＋イネーブルメントバンドルのテンプレート＋ローンチ後の情報収集ループ。

境界の例：「次の四半期にどの取り組みを優先すべきか決めてください。」
対応：まず prioritizing-roadmap を使用し、その後、このスキルを適用して選択した計画を運用に組み込みます。