product-operations-and-governance

プロダクト運用とガバナンス

継続的なプロダクトガバナンスの仕組みを定義し、運用します。誰が何を、どのようなエビデンスに基づいて、どの頻度で決定するのか、また決定に異議が唱えられた場合やエビデンスが不足している場合にどう対応するのかを定めます。このスキルが担うのはプロダクトレベルの運用モデル、すなわちプロダクト戦略、ポートフォリオの選択、実験、導入、ライフサイクルを通じた学習をつなぐ仕組みです。経営層のガバナンスや技術的なデリバリーゲートは対象外です。

ガバナンスの境界（最初にお読みください）

このスキルが担うのはプロダクトガバナンスです。これは、インテーク、ポートフォリオレビュー、ロードマップの決定、実験のレビュー、ローンチの決定、ライフサイクル／健全性のレビューを行う継続的な仕組みです。プロダクトガバナンスでは、何を、どの順番で、どのようなエビデンスに基づいて、誰が、どの頻度でレビューしながら構築するのかを決定します。

このスキルは、以下を明示的に対象外とします。

• 経営層のガバナンス — 資本配分、組織構造、会社レベルの戦略的投資、M&A の評価。意思決定メモや経営陣の業務手法については chief-of-staff-methodology を、戦略立案フレームワークについては strategy-frameworks を参照してください。
• 技術的なデリバリーゲート — CI/CD パイプライン、リリース承認ワークフロー、デプロイのチェックリスト、インフラ変更のレビュー。リリースの仕組みについては release-engineering を、仕様策定フェーズのゲートについては spec-driven-development を参照してください。

プロダクト、経営層、デリバリーという3つのガバナンス層は、それぞれ別のものです。「この実験を承認し、ローンチレビューに進める」というプロダクトガバナンスの決定は、「決済プラットフォームに200万ドルを割り当てる」という経営判断でも、「デプロイパイプラインで統合テストに合格しなければならない」というデリバリーゲートでもありません。境界の全容については、references/discovery-brief.md を参照してください。

コアフレームワーク

2つの運用モード

このスキルでは2つのモードをサポートします。各取り組みで、どちらかを明示的に選択してください。モードによって、必要なエビデンス、レビューの形式、エスカレーションの基準が決まります。

項目	軽量モード	高保証モード
チーム規模	小規模（エンジニア15人以下、プロダクトチーム3チーム以下）	規模を問わず、規制または安全上の義務がある
レビューの形式	非同期の書面による更新。同期レビューは意見が対立する場合のみ	定足数を記録した同期レビュー
エビデンスの最低要件	仮説と、定性的なシグナルまたは単一の定量指標	統計的エビデンス、リスク分析、コンプライアンス承認
例外の追跡	チームの Wiki または意思決定ログ	再検討日を含む正式な例外台帳
エスカレーション経路	説明責任を負う経営幹部に直接報告	解決内容を記録する正式なエスカレーション経路
頻度	隔週または毎月	毎週またはリリースサイクルごと
成果物の保持	軽量（スプレッドシート、共有ドキュメント）	監査可能（バージョン管理された記録、改変不能なログ）

モードは設定の選択肢であり、成熟度の段階ではありません。規制対象外の消費者向けアプリを開発するスタートアップは軽量モードで運用します。従業員8人の医療機器チームは高保証モードで運用します。200人規模のプラットフォームチームは、ポートフォリオの一部を軽量モードで、別の一部を高保証モードで運用する場合があります。

構成可能なガバナンスパターン

単一の組織図やガバナンスモデルを押し付けることはありません。このスキルでは構成可能なパターンを提供します。選択して適応してください。

パターン	使用する場面	主な特性
単一の説明責任者	小規模チーム、単一製品	1人が決定し、レビューは助言を行います
プロダクト評議会	複数チーム、複数製品	投票／合意形成のルールが定義された部門横断グループ
段階的レビュー	リスクが多様なポートフォリオ	低リスクでは簡易に、規制対象では高い保証水準で実施します
エスカレーションを伴う権限委譲	大規模な組織	カテゴリごとに決定権を事前委譲し、例外のみエスカレーションします

どのパターンでも、同じ成果物が必要です。決定権限マップ、エビデンス基準を伴うレビュー頻度、エスカレーション経路です。templates/operating-model.md を使用して、選択したパターンと構成を記録してください。

決定権限

決定権限マップでは、各決定タイプについて次の5つの質問に答えます。

1. 誰が決定しますか？ 指名された役割（「エンジニアリング」や「リーダーシップ」ではなく、説明責任を負う具体的な担当者）。
2. 誰への相談が必要ですか？ 決定前に意見を求める必要がある役割または個人。
3. 誰への通知が必要ですか？ 決定後に通知する役割または個人。
4. どのようなエビデンスが必要ですか？ この決定タイプに必要な最低限のエビデンス基準（モードによって異なります）。
5. エスカレーション経路は何ですか？ 説明責任者が決定できない場合、または決定に異議がある場合に解決する担当者。

このスキルで対象となる決定タイプ：

決定タイプ	一般的な頻度	簡易的なエビデンス	高い保証水準のエビデンス
受付の承認／却下	リクエストごと（継続的）	問題の説明＋シグナル1件	問題の説明、遅延コスト、戦略的整合性スコア、キャパシティ確認
ポートフォリオの優先順位付け	月次または四半期ごと	根拠を伴う相対順位	遅延コスト、戦略的整合性、キャパシティモデル、リスク評価に基づく順位
ロードマップの確約	計画サイクルごと	仮説＋成功基準	仮説、実験結果または市場エビデンス、依存関係マップ、信頼区間
実験の継続／停止	実験ごと	ガードレールの確認＋定性的なシグナル	統計分析、ガードレールの検証、倫理レビュー、決定ルール
リリースの可否判断	リリースごと	準備状況チェックリスト＋ステークホルダーの承認	完全な準備状況エビデンス一式、リスク受容の承認、ロールバック計画の検証
ライフサイクルの継続／投資／収益化／終了	レビューサイクルごと	利用状況＋成果データ、チームの提案	利用状況、財務、競合、リスクのデータ、複数のステークホルダーによるレビュー

特定の製品またはポートフォリオのマップを文書化するには、templates/decision-rights-map.md を使用してください。

レビュースケジュール

6つの定期レビューが、プロダクトガバナンスのリズムを形作ります。各レビューには、目的、参加者、インプット、アウトプット、意思決定権限が定められています。

レビュー	目的	主な参加者	主なインプット	主なアウトプット	意思決定権限
受付／機会レビュー	新しい作業をプロダクトシステムに取り入れるか決定します	プロダクトリード、エンジニアリングリード、デザインリード（パターンにより異なります）	問題提起、戦略との整合性、概算規模	採択／却下／保留の決定、担当者の割り当て	プロダクトリード（または評議会の投票）
ポートフォリオレビュー	ポートフォリオ全体の順序付けとリソース配分を行います	プロダクト評議会またはリーダーシップグループ	賭けの記録、キャパシティモデル、戦略上の優先事項	優先順位付けされたポートフォリオ、リソース配分、保留事項	プロダクト評議会または説明責任を負う役員
ロードマップレビュー	ロードマップ項目の確定、調整、保留を行い、エビデンスの更新を確認します	プロダクトリード、エンジニアリングリード、主要なステークホルダー	更新された賭けの記録、新たなエビデンス、依存関係の状況	更新されたNow／Next／Later、継続／一時停止／中止の決定	ステークホルダーの意見を踏まえたプロダクトリード
実験レビュー	実験結果が続行、反復、または中止を支持するか判断します	プロダクトリード、データ／サイエンスリード、エンジニアリングリード	実験結果の報告、ガードレールレポート、意思決定の提案	続行／中止／方向転換の決定、更新された賭けの記録	プロダクトリード（サイエンスの意見を踏まえる）
ローンチレビュー	リリースの準備状況を確認し、残存リスクを受容します	プロダクトリード、エンジニアリングリード、QA、セキュリティ、サポート、マーケティング	準備状況を示すエビデンス一式、リスク登録簿、ロールバック計画	実施／見送り／延期の決定、受容したリスク	プロダクトリード（実施／見送り）；リスクの受容には役員の承認が必要な場合があります
ライフサイクル／健全性レビュー	プロダクトの健全性を評価し、継続／投資／収益回収／廃止を決定します	プロダクトリード、エンジニアリングリード、サポート、財務（高保証の場合）	利用データ、成果指標、コストデータ、競合情報	ライフサイクルの決定、投資水準の更新、廃止する場合の移行計画	プロダクト評議会または説明責任を負う役員

templates/review-cadence.mdを使用して、特定の運用モデルに合わせたレビュー周期を設定します。ロードマップレビューの進め方についてはproduct-roadmapping-and-portfolio、実験レビューの方法についてはproduct-experimentationを参照します。また、ライフサイクル／健全性レビューのエビデンスについてはproduct-lifecycle-learning（文章 — 同じウェーブのスキルで、ディレクトリはまだ作成されていません）を参照します。

エビデンス基準

意思決定の種類ごとに、最低限のエビデンス基準があります。この基準は運用モードに応じて調整されます。すべての成果物で、エビデンスは次の4つのカテゴリに分類します。

• 観測済み — 測定・検証済みで、再現可能なデータです。
• 推論済み — 明示された前提と確信度に基づき、観測済みデータから導いた結論です。
• 主張済み — まだ検証されていないステークホルダーの主張であり、前提として扱います。
• 確定済み — 撤回に伴う影響を含む意思決定であり、説明責任を負う担当者と再検討のきっかけを記録します。

必要なエビデンスが不足していても、レビューを省略する理由にはなりません。エスカレーションする理由になります。必要なエビデンスなしでレビューを進める場合は、暗黙の承認ではなく、例外記録を作成する必要があります。

例外とエスカレーション

例外記録

ガバナンス要件を免除または延期する場合は、例外を記録します。記録がなければ、その例外が新たな標準になってしまいます。

項目：例外とした内容、その理由、承認者、承認日、再検討する時期（具体的な日付または発動条件）、免除された要件に代わるエビデンス（ある場合）。

templates/exception-record.mdを使用します。

エスカレーション記録

決定を所定のレベルで解決できない場合は、エスカレーションします。証拠が不足している、関係者の意見がまとまらない、または説明責任を負うオーナーが決定できない場合が該当します。エスカレーションは失敗ではありません。ガバナンスシステムが設計どおりに機能しているということです。

項目：エスカレーションした内容、エスカレーション先、下位レベルで解決できなかった理由、解決内容、解決日、完了を示す証拠。

templates/escalation-record.md を使用してください。

読み込みガイド

現在のタスクに関連するファイルだけを読み込んでください。一度にすべて読み込まないでください。

ファイル	読み込むタイミング
references/discovery-brief.md	ガバナンスの境界、オーナーシップ、スキル間のルーティングを理解する必要がある場合
templates/operating-model.md	プロダクトのオペレーティングモデルを一から設計または構成する場合
templates/decision-rights-map.md	プロダクトまたはポートフォリオの決定権をマッピングする場合
templates/review-cadence.md	目的、参加者、入力、出力を含むレビューの頻度を構成する場合
templates/exception-record.md	ガバナンス要件の免除または延期を記録する場合
templates/escalation-record.md	ガバナンスシステムを通じたエスカレーションを記録する場合

作業方法

1. 運用モードを選択する

すべての取り組みは、軽量モードまたは高保証モードを選ぶことから始めてください。どちらかをデフォルトにしないでください。次の点を確認します。このプロダクトは規制対象、安全性が重要な領域に該当する、または外部コンプライアンス義務の対象ですか？該当する場合は高保証モードです。チームが小規模で、プロダクトが規制対象でない場合は軽量モードです。

2. ガバナンスパターンを選択する

単独の説明責任を負うオーナー、プロダクト評議会、段階的レビュー、またはエスカレーションを伴う委任権限から選択します。模倣するのではなく、適応させてください。選択内容をオペレーティングモデルのテンプレートに記録します。

3. 決定権をマッピングする

対象範囲内のすべての決定タイプについて、決定権マップに記入します。誰が決定するか、誰に相談するか、誰に通知するか、どの証拠が必要か、どこにエスカレーションするかを記載します。templates/decision-rights-map.md を使用してください。

4. レビュー頻度を構成する

各レビューの目的、参加者、入力、出力、決定権を設定します。運用モードに合わせて頻度を調整します。templates/review-cadence.md を使用してください。

5. 証拠基準を確立する

運用モードに応じて調整し、決定タイプごとに最低限必要な証拠基準を定義します。その基準を決定権マップに記録します。証拠基準は単なる努力目標ではありません。決定の前提条件となります。

6. 例外とエスカレーションを記録する

すべての例外とエスカレーションについて、説明責任を負うオーナーと再確認のきっかけを含む、日付入りの記録を作成します。例外記録により、放置による免除を防ぎます。エスカレーション記録により、ガバナンスシステムの可視性と改善可能性が高まります。

ルーティング表

必要な内容	読み込むスキル
プロダクトビジョン、North Star、競争上のポジショニング	product-strategy
戦術的な優先順位付け（RICE、MoSCoW）、意思決定ログ、仕様書	product-methodology
成果ロードマップ、戦略的な賭け、ポートフォリオの順序付け	product-roadmapping-and-portfolio
複数プロジェクトにまたがる技術的な調整、共有キャパシティ、プログラムの便益、変革の実行	technical-program-management
実験の設計、手法の選択、ガードレール、結果の報告	product-experimentation
リリース後の学び、ライフサイクルの判断、前提の更新	product-lifecycle-learning（文章 — 同じウェーブのスキル）
経営幹部向けの意思決定メモ、CoS の手法、取締役会資料	chief-of-staff-methodology
戦略計画、資本配分、OKR フレームワーク	strategy-frameworks
リリースの仕組み、デプロイパイプライン、ロールバック計画	release-engineering
仕様策定段階のゲート、受け入れ基準、タスク計画	spec-driven-development

使用しない場合

以下の場合は、このスキルを読み込まないでください。

• 経営幹部によるガバナンス。 資本配分、組織構造の判断、全社レベルの戦略的な賭け、M&A の評価については、chief-of-staff-methodology または strategy-frameworks に振り分けてください。
• 技術的なデリバリーゲート。 CI/CD パイプライン、リリース承認ワークフロー、デプロイのチェックリスト、インフラ変更のレビューについては、release-engineering または spec-driven-development に振り分けてください。
• 普遍的な組織図の押し付け。 ガバナンスのパターンは設定可能なテンプレートであり、必須の構造ではありません。ゼロから組織図を設計する依頼であれば、このスキルは適切なツールではありません。
• 継続的なシステムを伴わない単発の意思決定。 1つの意思決定を行うだけで（長期にわたる意思決定の仕組みを設計するのではなく）、意思決定ログには product-methodology を、アーキテクチャ上の意思決定には adr-authoring を使用してください。