【2025年版】【図解】データアーキテクチャの基本｜Raw→Staging→Feature→BIの設計と責任分担（テンプレ付）

夜のレビュー。グラフは「改善」を示すのに、CSは現場感覚と合わないと言う。エンジニアは「SQLは合ってる」と首をかしげ、会議は静かに長引く——。
結論：Raw→Staging→Feature→BIの4層を“役割で分け”、施行日とSLOを明記するだけで、数字の迷子は止まります。PdMは「どの層の責任か」を即答できる設計にしましょう。

意思決定と価値づくりの両輪はここが基礎です。課題解決型PdM 完全ガイド／価値提供型PdMの設計図で全体像がつながります。

1. なぜ“4層”なのか（ねらい→やること→失敗と直し方）

ねらいは、定義変更や品質事故があっても“巻き戻せる道”を確保し、Aha/TTV/翌日活性の判定を5分で終えること。やることは①Rawは触らない ②Stagingで最小整形 ③Featureで意思決定の素材化 ④BIは見せ方だけの分業。失敗は、Stagingで凝り過ぎたり、BI側で定義を増殖させること。直すなら、定義はFeatureに一本化、BIは施行日の縦線と注記だけに絞ります。

2. 4層の定義（図解の代替テキスト＋責任）

【層の定義と責任（貼るだけ）】
Raw：生データ。削らない/変えない/追記のみ。責任=データ基盤（C）
Staging：型・TZ・デデュープ（30秒）等の最小整形。責任=データ基盤（C）
Feature：Aha/TTV/D1など定義カードを実装した“素材”。責任=データ担当（A）
BI：ダッシュボード。施行日で分割し、差分表示。責任=PdM（R）

R=Responsible（実行）/A=Accountable（最終責任）/C=Consulted（協議）/I=Informed（共有）

3. RACIテンプレ（役割を1枚で固定）

“誰が直す？”が曖昧だと止血が遅れます。プロダクトの定例にそのまま貼れるRACIを置いておきます。

4. 命名規約とディレクトリ構成（迷子ゼロ）

人が検索でき、機械が並べられることを最優先に。意味のある桁はIDに埋め込まない。施行日をファイルやテーブル注記に持たせます。

datasets/
  raw/events_yyyy_mm_dd.parquet
  staging/events_clean_yyyy_mm_dd.parquet
  feature/aha_d1_ttv_daily_v1_3_effective_2025_09_02.parquet
  bi/four_cards_dashboard_v1_3.json

5. データ契約（Schema/施行日/変更告知）

“列が増えた/消えた”で毎回炎上しないために、変更は必ずテキストの契約に従います。施行日はダッシュボードで前後を分割。

【変更契約（短文化）】
申請：対象テーブル/列・理由・影響・施行日
レビュー：Rawは不変、Stagingは互換性維持、Featureは定義カードに準拠
承認：PdM（A）/データ担当（A）/エンジニア（C）
告知：Slack #release-data に差分と影響幅（+pp/−分）

6. SLO（遅延許容）と監視（“速くて正しい”の線引き）

“速いほど良い”は罠。先行レーンは≤15分、営業/CSは≤2時間、会計は翌営業日が目安。逸脱時は止める→直す→再開。

rule four_cards_refresh <= 15m
alert if delay>SLO or required_events_missing
action: pause() → backfill() → annotate("施行日") → resume()

7. バックフィル/ロールバック手順（貼るだけ）

事故時は“正しく戻れる道”が命。以下を運用ドキュメントに固定します。

8. “毎日4枚”への接続（Aha/TTV/D1/新規比率）

BIで定義を増やさないのがコツ。Aha/TTV/D1/新規比率はFeature層で確定させ、BIは差分と施行日だけにします。

feature/aha_d1_ttv_daily （列）
d｜aha_users｜active_users｜aha_rate｜ttv_p50_sec｜ttv_p95_sec｜d1_rate｜new_user_ratio｜effective_from

Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。

9. 会議10分台本＆Slack定型文（読み上げで終わる）

説明会をやめ、判定会に。差分→品質/SLO→入替宣言を読み上げ、PRD断片に反映します。

【10分台本】
[00-02] 先週差分：Aha +pp／TTV −秒／D1 +pp（施行日またぎは分割）
[02-04] 品質/SLO：欠損0・四枚SLO≤15分達成
[04-07] 変更：Feature v1.3 施行（重複集約）。影響 −1.1pp
[07-10] 入替宣言：撤退/継続/新規 → PRD反映

【Slack #release-data】
対象：feature.aha_d1_ttv_daily v1.3 施行=2025-09-02 10:00
差分：save_success を30秒デデュープ。TTVの負値除外。
影響：Aha −1.1pp（以降は新定義）。BIは施行日で系列分割。

10. 14日ロードマップ（ゼロから導入）

完璧主義を捨て、“回る最小”を2週間で形にします。道具は既存で十分です。

1. Day1-2：4層の定義とRACIを合意（本文テンプレを貼る）。
2. Day3：Rawの保存方針（不変/追記）を宣言。
3. Day4-5：StagingでTZ/型/デデュープ（30秒）を実装。
4. Day6-7：FeatureでAha/TTV/D1/新規比率を確定（定義カード準拠）。
5. Day8：BIで“毎日4枚”を1画面に、施行日縦線と注記。
6. Day9：SLO監視（≤15分）と欠損検知→Slack通知。
7. Day10-11：バックフィル/ロールバックの手順を演習。
8. Day12-13：PRD断片に「非スコープ→基準→評価」を反映。
9. Day14：初回レビュー→入替宣言→5行ログで記録。

11. よくある落とし穴と回避策

• BIで定義を増やす：見える場所に定義が増殖。定義はFeatureに一本化。
• Rawを“きれい化”：巻き戻せなくなる。Rawは不変・追記のみ。
• 施行日なしの更新：過去比較が壊れる。必ず縦線と注記を。
• 役割の曖昧さ：RACIで責任を固定。事故時の止血が速くなる。

FAQ（見えるブロック）

Q. ELTとETL、どちらが良い？

A. 先行指標を速く回すならELT寄り（Raw→Staging→Featureで巻き戻し可）。その他はETLでも十分です。

Q. 小さなチームでも4層は必要？

A. 必要です。ディレクトリと命名のレベルでも“層の分離”は再現できます。巻き戻しの道が増えます。

Q. 事故時に会議をどう運用？

A. “止める→直す→再開”を台本化し、BIは施行日で系列分割。以降の期間だけで評価してください。