【2025年版】【図解】データガバナンスとは？PdMが最初に決める「責任・基準・変更権限」完全ガイド（テンプレ付）

会議で「このアクティブって誰基準？」と聞いた瞬間、空気が固まる——数字はあるのに決め切れない。その原因はルックやSQLではなく、決め方が決まっていないことにあります。
結論：データガバナンスとは、数字の“意味”と“決め方”を統一する仕組み（責任・基準・変更権限）で、PdMが5分で意思決定できる状態をつくることです。

1. データガバナンスの正体：なぜ必要か（ねらい→やること→効く場面）

ねらいは「同じ定義で同じ判断を再現」すること。やることは①責任の明確化（誰が決める）②基準の明文化（何をどう決める）③変更の手順（いつどう変える）の3点だけ。効く場面は、優先順位付け、PRDレビュー、リリース判定、採用面接の説明など“決める”全てです。

価値と短期運用の全体像はここが基礎です。課題解決型PdM 完全ガイド／価値提供型PdMの設計図で全体像がつながります。

2. まず覚える4つの書類：ポリシー／標準／手順／ガイドライン

「ルールの紙」を1枚に混ぜると混乱します。役割が違うからです。最小単位で下記の区別をつければOK。

【用語の使い分け（そのまま貼ってOK）】
ポリシー：守る“原則”。例）定義の最新版は1つだけ。変更は承認制。
標準（スタンダード）：測定・命名・権限などの“基準”。例）Ahaはイベントsave_success。
手順（プロシージャ）：誰が何をいつやるかの“手順”。例）定義変更は申請→レビュー→承認→反映→告知。
ガイドライン：判断を支える“考え方”。例）週次は先行指標のみ、遅行は四半期で評価。

3. 役割の最小構成：オーナー／スチュワード／カストディアン／利用者

大人数は不要。PdM現場なら4役で十分回ります。RACIを決めれば責任の押し付け合いが消えます。

【RACIテンプレ（コピペ）】
対象：Aha達成率の定義
Owner（責任/R）：PdMリード
Steward（運用/A）：データ担当（定義カード更新）
Custodian（保全/C）：エンジニア（計測実装）
Consumer（利用/I）：CS・Biz（活用と問い合わせ）
承認権限：Owner→Stewardの2者で可決（代替：プロダクトオーナー）

4. 「変更できる道」をつくる：申請→レビュー→承認→反映→告知

ガバナンスは“固める”ことではなく、“正しく変えられる”こと。変更フローをテキストで固定しておきます。

【変更フロー（最小）】
1) 申請：Notion/フォーム「用語名・現行定義・変更理由・影響範囲・希望日」
2) レビュー：Stewardが整合性チェック（計算式・イベント・ダッシュボード）
3) 承認：OwnerがGo/No-Go。代替案は日時付きで提示
4) 反映：定義カード→クエリ→ダッシュボード→PRD断片の順に更新
5) 告知：Slack #release-data に“変更差分と施行日”を投稿（雛形下）

【Slack告知テンプレ】
対象：Aha達成率（save_success）
変更：未ログの体験を除外（連続成功の重複排除）
施行：2025-09-01 00:00
影響：TTV集計の母数変更→PRD断片を更新済み（KRは差分で評価）

5. メタデータ（用語・計算式）を1か所に：定義カードの作り方

「この数字って何？」が消える核心が定義カードです。目的は“最新版が1つだけ”になること。シート/Notionで始められます。

【定義カード（列の見本）】
用語｜説明（体験ベース）｜計算式/SQL｜イベント名｜所有者（RACI）｜施行日｜最終更新
Aha達成率｜初回の価値を体験した比率｜count(distinct user_id where event=save_success)/count(distinct user_id)｜save_success｜Owner=PdM R / Steward=Data A｜2025-09-01｜2025-09-01

計測の並べ方はKPI設計と運用ガイドが最短です。

6. 品質ガードレール：壊れたら“止める→直す→再開”

美しいDWHより“止血”の速さが効きます。最低限の検知とルールだけ先に決めておきます。

• 必須イベント欠損：save_success・resume_openedが0なら日次集計を停止し告知。
• 重複・異常：同一ユーザーの連続成功は1回に集約／TTVが負の値は除外。
• バージョン管理：定義の施行日を保持。比較は“差分（+pp/−分）”で読む。

7. PRDと接続する：非スコープ→基準→評価（1枚断片の雛形）

定義を作って終わりではなく、毎週の意思決定に直結させます。PRD断片は“線引き→基準→評価”の順で1枚に。

【PRD断片（貼るだけ）】
非スコープ：定義のない数値を会議に持ち込まない
基準（標準）：Aha/TTV/D1は定義カードに紐づく版のみ採用
評価（KR）：Aha +5pp／TTV P50 −2分／翌日活性 +4pp（旧比）
撤退条件：Aha +3pp未満 × TTV悪化 → 旧版へロールバック

8. 成功の測り方（先行指標）：ガバナンスが“効いている”状態

「導入したつもり」で終わらせないために、先行KPIを決めておきます。数字は相対でOKです。

• 定義の合意時間：提起→承認までの中央値が1営業日以内。
• PRDレビュー時間：1件あたり10分以内（説明ではなく判定）。
• 指標の差分把握率：週次でAha/TTV/D1の差分（+pp/−分）が“即答”できる。
• 巻き戻り頻度：定義変更が原因の再計測が月1回未満。

9. 導入ロードマップ（14日版）：ゼロからでもここまで

大規模な仕組みは不要。2週間で“回る最小”を形にします。必要なのはテキストと習慣だけです。

1. Day1-2：ポリシーと標準を1枚化（本文の雛形でOK）
2. Day3-4：RACI決定（Aha/TTV/D1・集計クエリ・ダッシュボード）
3. Day5：定義カード（20語）を作成・公開
4. Day6：変更申請フォーム（Notion/Googleフォーム）を整備
5. Day7：Slack #release-dataを開設（告知テンプレ固定）
6. Day8-9：品質チェック（欠損・重複・異常）を自動化 or 手動点検
7. Day10：PRD断片を更新し、会議台本を配布
8. Day11-12：テスト変更を1件まわしてみる（申請→反映→告知）
9. Day13-14：ふりかえり→ポリシー/標準の改訂

10. よくある誤解と直し方

• 誤解：「ガバナンス＝締め付け」。
  → 直し方：“正しく変えられる”ための道（変更フロー）が本体。迅速化が目的。
• 誤解：「専用ツールがないと無理」。
  → 直し方：最初はシート/Notionで十分。最新版が1つあれば回る。
• 誤解：「全部の指標を一気に定義」。
  → 直し方：Aha/TTV/D1の3つから。残りは週次で追加。

FAQ（見えるブロック）

Q. まず何から始めればいいですか？

A. 本文の「ポリシー/標準/手順」を1枚にまとめ、RACIと変更フォームを先に作るのが最短です。

Q. 売上やNPSを毎週の会議に入れなくて大丈夫？

A. 週次は先行指標（Aha/TTV/D1）で判定し、遅行は四半期レビューに分離してください。

Q. 小さなチームでも意味がありますか？

A. むしろ小規模こそ効果が大。定義の“最新版1つ”と変更の“道”ができれば、議論の迷いが消えます。