新しいダッシュボードができた朝、「CSの数字と違う」「会計と合わない」で会議が止まる——原因は“速さの基準”が決まっていないからでした。
結論：データ統合は「全部を速く」ではなく、「先行指標だけを速く」運ぶ設計です。Aha/TTV/翌日活性は分〜時間、営業・会計は時間〜日で十分。優先順位と遅延許容（Latency SLO）を先に決めれば迷いは消えます。
- 1. なぜ統合が要るのか（ねらい→やり方→失敗と直し方）
- 2. 優先順位は「3レーン」で考える（つながる文章）
- 3. 遅延許容（Latency SLO）テンプレ（つながる文章）
- 4. キー設計：MDMと“リンクテーブル”が土台（つながる文章）
- 5. パイプライン設計：ETLかELTか（つながる文章）
- 6. 監視とSLO：止める→直す→再開（つながる文章）
- 7. スキーマ変更の“契約”を作る（つながる文章）
- 8. PRD断片＆RACI（コピペで運用開始）
- 9. コピペ素材（テンプレ一式）
- 10. 7日ロードマップ（ゼロから導入）
- 11. よくある落とし穴と回避策
- FAQ（見えるブロック）
- 関連記事
- 統合運用テンプレ（PDF）
1. なぜ統合が要るのか（ねらい→やり方→失敗と直し方）
ねらいは、意思決定を5分で終わらせる“ひとつの現実”を作ること。やり方は①先行指標レーンだけ低遅延 ②その他は遅延許容で設計 ③IDはMDMで一意の三本柱。失敗は、全系統をリアルタイム化しようとすること。直すなら、Aha/TTV/翌日活性の3枚に必要な最短データだけを分単位で流し、他は日次で十分と線を引きます。
意思決定と価値づくりの両輪はここが基礎です。課題解決型PdM 完全ガイド／価値提供型PdMの設計図で全体像がつながります。
2. 優先順位は「3レーン」で考える（つながる文章）
統合は“全部リアルタイム”が正解ではありません。流すべき速さは目的で決まります。まずは現場の意思決定に直結する先行指標レーンを最速に、それ以外は遅延許容で線引きします。これで“遅いからダメ”の議論が止まり、運用コストが下がります。
【3レーンの優先順位】
① 先行指標レーン（超優先）：Aha/TTV/翌日活性 → 分〜時間
② 営業・CSレーン（重要）：リード/面談/チケット → 時間
③ 会計・経営レーン（遅行）：売上/請求/会計 → 日（翌営業日で可）3. 遅延許容（Latency SLO）テンプレ（つながる文章）
「どのくらい遅くて許されるか」を宣言すると、設計は一気に楽になります。以下の表をそのままPRDと運用設計に貼ってください。合意のない“なんとなく遅延”を撲滅できます。
| 用途 | 対象 | 許容遅延（SLO） | 備考 |
|---|---|---|---|
| プロダクト運用 | Aha/TTV/D1 | ≤15分 | 分粒度の入替判断に使用 |
| 営業/CS | 面談予約/問い合わせ | ≤2時間 | 在庫やアサインに影響 |
| 会計/経営 | 売上/請求/原価 | 翌営業日 | 正確性優先・遅行でOK |
4. キー設計：MDMと“リンクテーブル”が土台（つながる文章）
統合の4割はIDの話です。主IDは内部UUID、外部IDはリンクテーブルで多重に保持。表記揺れや重複はMDMの基準で解消し、可逆にたどれるよう“由来”を残します。これでダッシュボードの“同じ人が二人に見える”が消えます。
【基本形】
users (user_id UUID, ... )
master_links (user_id, source_system, source_id, confidence, updated_at)
events (user_id, event_name, props..., ts)
-- 外部システムのIDは master_links に集約。主IDは users.user_id のみ。5. パイプライン設計：ETLかELTか（つながる文章）
結論は「先行指標レーンはELT寄り、その他はETLでも可」。まず生データ（Raw）を安全に貯め、Stagingで最小整形、Feature/BIで指標を作ると巻き戻しが効きます。施行日と版の注記を残すことが将来の改訂に効きます。
- Raw：元データをそのまま。削らない、変えない。
- Staging：型/タイムゾーン/デデュープだけ最小の整形。
- Feature：Aha/TTV/D1など“意思決定の素材”を作る。
- BI：ダッシュボード用。施行日で系列分割。
6. 監視とSLO：止める→直す→再開（つながる文章）
“速いけど壊れている”は最悪です。遅延と欠損の監視をSLOで管理し、逸脱したら止血→修復→再開。Aha/TTV/D1の精度が守れないなら、あえて遅くする判断も正解です。
rule slo_aha_ttv_d1_delay: <= 15m
rule slo_sales_delay: <= 2h
rule slo_finance_delay: EOD+1
alert if delay > SLO or required_events_missing
action: pause_aggregation() → backfill() → annotate("施行日") → resume()7. スキーマ変更の“契約”を作る（つながる文章）
列の追加・削除で毎回炎上しないために、「変更は申請→レビュー→承認→施行→告知」。施行日と影響幅をSlackに残し、ダッシュボードは前後で分割表示。これで過去比較の混乱を防げます。
【告知テンプレ（#release-data）】
対象：events.resume_opened に from_notification 追加
施行：2025-09-02 10:00
影響：翌日活性の分解（通知/その他）可。既存指標の定義は不変。
対応：PRD断片と定義カードを更新済み。8. PRD断片＆RACI（コピペで運用開始）
運用で迷わないための“1枚”。非スコープ→基準→評価を宣言しておくと、週次会議が判定会になります。
【PRD断片】
非スコープ：全データのリアルタイム化／外部IDを主キーに採用
基準：先行指標はSLO≤15分。IDは内部UUID＋master_links。施行日はダッシュボードで分割。
評価（KR）：Aha +5pp／TTV P50 −2分／翌日活性 +4pp（前週比）
撤退条件：SLO連続逸脱×先行指標悪化 → パイプライン段階を1つ戻す
【RACI】
Owner（R）：PdMリード
Steward（A）：データ担当（SLO監視/施行日管理）
Custodian（C）：エンジニア（パイプライン実装/修復）
Consumer（I）：CS/Biz/Finance（利用・フィードバック）9. コピペ素材（テンプレ一式）
そのままNotion/Sheet/BIに貼れる素材です。明日から回せます。
【遅延許容表（Sheet列）】
用途｜対象｜SLO（許容遅延）｜監視式｜アラート先｜施行日｜最終更新
【データマップ表】
表名｜ソース｜主キー｜外部キー｜更新頻度｜SLO｜担当（R/A/C/I）
【Slack定型文】
本日のSLO：Aha/TTV/D1 ≤15m達成、Sales ≤2h達成、Finance EOD+1達成。
変更：events.resume_opened に from_notification 追加（施行=9/2 10:00）。10. 7日ロードマップ（ゼロから導入）
完璧主義を捨て、“回る最小”を7日で形にします。施行日とSLOが肝です。
- Day1：3レーン/SLOを合意（本文のテンプレを貼る）。
- Day2：MDMリンク表の運用開始（users/master_links）。
- Day3：Aha/TTV/D1のFeatureテーブルを作成（ELT）。
- Day4：監視ジョブ（遅延/欠損）→Slack通知。
- Day5：PRD断片/RACIを配布、会議台本にSLO項目を追加。
- Day6：スキーマ変更の申請→承認→施行のリハーサル。
- Day7：初回レビュー→入替/撤退をログ化、施行日縦線をBIに。
11. よくある落とし穴と回避策
- すべてをリアルタイム化：コスト高＆品質悪化。3レーン/SLOで線引き。
- 外部IDを主キーに採用：仕様変更で破綻。内部UUID＋link_tableへ。
- 施行日なしの改修：過去比較が壊れる。必ず縦線と注記を。
- MDMなしの統合：同一人物が二重計上。先にMDM（代表ID）を固める。
Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。
FAQ（見えるブロック）
- Q. どこまでリアルタイム化すべきですか？
- A. 先行指標レーン（Aha/TTV/D1）だけ≤15分。他は2時間〜翌営業日で十分です。
- Q. ETLとELT、どちらが良い？
- A. 先行指標はELTで巻き戻し可能に、その他はETLでもOK。Raw→Staging→Feature→BIの順を守れば迷いません。
- Q. 数字が部署で食い違います。
- A. MDMの代表IDと定義カードの“最新版ひとつ”を参照し、施行日で系列分割してください。
統合運用テンプレ（PDF）
遅延許容表／データマップ／PRD断片／SLO監視／Slack定型文を1ファイルに。
PdM初心者のための仕事大全【保存版】 ／
PdMキャリア戦略：ゼロイチ〜スケールの実務
特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）
コメント