モノレポか分離か。データ基盤の責務から考える
はじめに
この記事は、データパイプラインとその利用側（ダッシュボードや可視化ツールなど）を同じリポジトリで管理すべきか、それとも分離すべきかについて、責務設計の観点から私なりに整理したものです。
この議論はよく「CIの組みやすさ」や「ディレクトリ構成の好み」として語られがちです。ただ個人的には、本当に考えたいのはそこではないと思っていまして、その話をできればと思います。
repo設計の前に考えたいこと
「モノレポが良いか、マルチレポが良いか」という問いは、議論の入り口としてはわかりやすいのですが、実は問いの立て方として少しずれているように感じています。
CIの組みやすさ、ディレクトリの切り方、変更の追いやすさ。これらはどれも大事な実務的な関心ですが、判断の軸というより、どちらかというと「結果として出てくるもの」ではないでしょうか。
私が気にしたいのは、「データ基盤がそもそも何を責務として持つべきか」という点です。
つまり、これはrepo設計の話というより、「責務設計の話」として捉えた方が整理しやすいかと思っています。
データパイプラインって何者？
少し立ち止まって、データパイプラインの位置づけを確認しておきます。
データパイプラインは、単にダッシュボードの裏側ではありません。その出力は複数の利用者に、異なる形で使われることが多いです。
- ダッシュボードで可視化したい人
- CSVやExcelで納品物として欲しい人
- 部門固有のKPIとして使いたい人
- 経営層が別の前提で参照したい人
こういう状況を考えると、パイプラインの役割は「特定画面に最適化された実装」よりも、「複数利用に耐えるインターフェース」に近い気がします。
そう考えると「パイプラインと利用側をどう管理するか」という問いは、「インターフェースをどこで定義し、誰が守るか」という問いに読み替えられるかもしれません。
モノレポの本当の問題はどこか
モノレポを批判するとき、よく「見通しが悪くなる」「リリースが連動して面倒」といった話が出てきます。ただ、私はそれはあまり本質的な問題ではないと思っていて、もう少し別のところが気になっています。
ここからは、モノレポ運用で起こりやすい問題を5つに分けて整理します。
■依存の方向がだんだん逆転してくる
本来、データパイプラインとデータプロダクトの依存の方向はシンプルなはずです。
- パイプラインがデータ契約を定義する
- 利用側はその契約を参照する
ところがモノレポにすると、利用側の都合でパイプラインの定義が少しずつ歪んでいきやすい印象があります。
- ダッシュボードの表示都合で中間モデルの命名が決まる
- 一時的な画面仕様で列が追加され続ける
- 本来は利用側で吸収すべき整形処理が上流に逆流する
こういった「責務の流れ込み」が積み重なると、パイプラインがインターフェースというより「個別要求の受け皿」になっていきます。
こうなると、パイプラインは特定の可視化環境向けに専用化されていき、汎用性が下がります。結果として、複数のツールや用途に対応しにくくなったり、どれか一つの利用側の都合に引きずられすぎる状態になりやすいです。
■レビューがなんとなくで通りやすくなる
同じPRにSQLモデルの変更とダッシュボードの変更が同居すると、ちょっと困ったことが起きます。
- データ品質を見れる人はUIの妥当性を十分に見れない
- UI・可視化を見れる人はdbtモデルの粒度やテストの妥当性を見れない
結果として、誰も全体には責任を持てないまま「まあよさそう」でLGTMが押されやすくなります。一つにまとまっている方が安心に見えますが、実際にはレビューの責任が分散して曖昧になりやすいです。
■変更のテンポがそもそも違う
データパイプラインと可視化側では、変更の望ましいリズムがそもそも違います。
- パイプラインは品質保証や後方互換を大事にするので、慎重に変えたい
- 可視化側は業務要望に応じてサクサク試行錯誤したい
この2つを同じリポジトリ・同じレビュー導線に載せると、どちらかのペースにもう片方が引きずられてしまいます。責務が違うだけでなく、望ましい開発リズム自体が違うというのは、結構大きい話だと思っています。
また、Gitの履歴の意味も混ざります。パイプライン変更のコミットは「データ定義の変更履歴」で、可視化変更は「表現や業務要望の調整履歴」です。これが混ざると「なぜこの列が変わったのか」「意味の変更か表示都合か」が後から読みにくくなります。監査や障害解析の場面でも、変更の意図が種別ごとに分かれている方が状況を追いやすいです。
■デプロイと障害の単位が違う
一つのリポジトリに置いても、壊れ方は根本的に異なります。
- パイプラインの変更は、データ破壊・欠損・定義変更として現れる
- 可視化側の変更は、表示崩れ・集計軸の誤解・文言の不整合として現れる
障害の検知方法も、復旧手順も、そもそも責任者が違います。同じリポジトリに同居していても、運用上は別種のシステムです。ならば最初から管理単位も分けた方が、設計と実態が一致しやすいと思っています。
■テスト文化がそもそも違う
dbt側とフロントエンド・可視化側では、テストで保証したいものが違います。
- dbt側は、スキーマテスト・データテスト・リネージ確認が中心
- 可視化側は、UIテスト・スナップショット・受け入れ確認が中心
同じCIに乗せても、保証の対象がすれ違います。「同じリポジトリにあるから一緒に品質保証できる」という期待は、実際には成立しにくいです。それぞれの保証モデルが違うことは、「契約をどこに置くか」という話にも直結してくるのですが、それは後の節で触れます。
モノレポが向いているケースもある
ここまで書いてきたのですが、モノレポを全面否定したいわけではありません。
向いているケースもあると思っていて、たとえば、
- dbtの出力を参照するのが単一チームに閉じている
- 用途が限定されていて、ほとんど変化しない
- MLOpsの評価パイプラインのように、消費先がほぼ固定されている
こういう状況では、パイプラインと利用側が実質的に同じ責務圏内に収まっているので、無理に分けなくても破綻しにくいかと思います。
ただ、ここで気をつけたいのは言い方で、「モノレポが正しい」ではなく、”責務境界がまだ単純だから成立している”という状態だと捉えた方がよいかもしれません。
分離が必要になってくる条件
では、どういうときに分離を考えるとよいか。私なりの軸は一つで、
「利用主体と利用形態が増えるほど、責務は分けた方が自然になってくる」
という感覚です。
- ビジネス側も参照する
- 経営層も見る
- 複数部門が同じデータを違う文脈で使う
- ダッシュボード、帳票、分析、外部連携など複数の経路がある
こうなると、利用側ごとの事情をすべてパイプライン側に持ち込むのは不自然になってきます。
「同じデータを使うから同じ場所にある方が自然」という発想は直感的ですが、むしろ逆で、同じデータを複数主体が使うからこそ、「共通の基盤責務と個別の利用責務を切り分ける必要が出てくる」ように思います。
分離のコストも正直に
分離がいいと言いたいわけですが、コストがあることも正直に書いておきます。
- UIや可視化側の変更とパイプライン変更の同期が難しい
- 複数リポジトリ間で変更の整合性を取る必要がある
- リリース粒度がずれる
- チーム内の運用ルールが弱いと崩れる
分離は自然にうまく回る設計ではなく、「チームの管理能力を前提にした設計」だと思っています。このコストを無視して「責務分離が正しい」とだけ言っても、現場ではあまり役に立ちませんよね。
ただ、このコストを下げる実務的な工夫として、複数リポジトリで論理的に分けつつも、開発環境では必要なリポジトリを同一環境にクローンして扱う、という整理は有効だと感じています。「責務は分けるが、開発体験は断絶させない」を両立するイメージです。
それでも分離を選ぶ理由
分離は面倒ですし、同期コストも増えます。それでも分離を選ぶ理由は、単純に便利だからではありません。
「データ基盤を特定利用の都合に引きずられない、責務の明確なインターフェースとして保ちたいから」です。
「同時に変更できる」ことと「同時に変更すべき」ことは別の話です。モノレポのよく言われる利点の一つに「一つのPRで全部変えられる」があるのですが、それは管理上の便利さであって、設計上の正しさとはまた別だと思っています。「上流変更と下流変更を毎回セットで出さないと成立しない」状態は、むしろ契約が弱い状態のサインかもしれません。
契約はどこに置くか
分離すると、自然に「では利用側は何を信頼すればいいの？」という問いが出てきます。
人間が書くデータカタログや仕様書は、正直なところ保守され続けにくいです。誰かがパイプラインを変えても、文書の更新が追いつかないことはよくあります。静的なドキュメントだけを信頼の中心に置くのは少し危うい気がしています。
代わりに、契約の源泉として機能しやすいのは、
- 「dbt YAML」（スキーマ定義・カラム意味・テスト定義）
- 「dbtのテスト結果」（実行に結びついた定義）
だと思っています。これらは実装と常に同期していますし、誰かが変更を加えればテストが落ちることで整合性の崩れを検知できます。
可視化側も「なんとなくこういう意味だろう」で使うより、dbt YAMLとテスト結果を参照して「何が保証されているか」を確認する方が、長期的には安全ではないでしょうか。
文書で仲良く連携するより、「実行可能な定義とテスト結果を契約にする」方が、責務を分けたまま整合性を保ちやすいと思っています。
AIエージェント時代はむしろ境界が重要になってくる
最後に、少し現代的な話を。
最近はAIエージェントにコード修正や自動化タスクを任せる場面が増えてきていますが、このとき「責務境界が明確なほど、エージェントの動作が安全になる」と感じています。
リポジトリが混在していると変更の意図が横滑りしやすく、「どこまで変えてよいか」をエージェントに伝えにくいです。一方、インターフェースが明確で、dbt YAMLとテスト結果が契約として整備されていれば、エージェントも「何が変わったら契約違反か」を判断しやすくなります。
人間にとってもAIにとっても、分離された境界と実行可能な契約は、設計の安定性を上げてくれると思っています。
まとめ
今回は、データ基盤のモノレポ・分離の判断を責務設計の観点から整理してみました。
判断基準は管理のしやすさよりも、「データパイプラインを特定の利用側に引きずられない、責務の明確なインターフェースとして維持できるか」だと思っています。そしてその境界を支える契約は、人間の仕様書よりも、dbt YAMLとテスト結果のような実行可能な定義に置いた方がよいのではないかと考えています。
一言でまとめるなら、
利用者には向き合うべきだが、利用者の都合に責務まで明け渡してはいけない。
データ基盤の設計に携わっている方の参考になれば嬉しいです。
現在、dbtに関する書籍も執筆中です。dbtの基本から実践的なノウハウまでをまとめていますので、ご興味のある方はこちらもご覧ください。
Discussion