はじめに
フューチャー Advent Calendar 2025 1日目です。
2024年ごろから、データガバナンス/データマネジメントに取り組むことが増えてきました。AI-ReadyやAIエージェントReadyなデータガバナンスとは何であって、何でないか？という問いかけをしつつ、日々のデータ標準化や対応方針をどう行うべきかを策定しています。2024年はデータ基盤を構築する際にデータガバナンスをどのくらい気にすべきか という記事を投稿しましたが、1年の差分でAIが完全に中心に来ました。4月に公開したデータマネジメント設計ガイドライン もそのあたりを反映したいところです。
さて、11月になぜアーキチームは設計や実装のパターンを絞りたいか？ 背景にある思考と技術選定のジレンマという記事を会社ブログに寄稿して色々な反応をもらいました。そこでデータガバナンスとアーキテクチャ設計の関係性について、日々思うところをまとめたいと思います。
データガバナンスを考えることと、アーキテクチャ設計は似ている？
データガバナンスとは、データ資産を戦略的に管理・活用するための仕組みやルールや体制のことを指します。基本的に個別領域（各システムや部門/部門など）というよりは、それらを横断して考えます。組織やシステムには境界がありますが、業務的な効果を出そうとすると境界を横断したデータ分析が必要になってくるからです。例えば、Salesforceなどにある商談情報などの顧客情報を、製造計画、製品開発、調達、管理会計など各部門のデータと組み合わせ、今までできなかった分析を行うことに価値があります。部門内に閉じた分析であれば、従来に存在するシステム内である程度対応ができたので、データガバナンスっていうほど重厚なものは優先度が低いという整理でした。
システムのアーキテクチャ設計も、基本的に個別の各機能の開発には深く立ち入りません。もちろん、どのような業務的な課題を解決するために存在するかは理解が必要ですが、各機能でどのDBテーブルのどのカラムにどのようなSQLでアクセスして...といった詳細設計には立ち入りません。その代わり、すべての機能にきょうつする全体としての方針を立て、性能/可用性/セキュリティ/拡張性/運用性... といった非機能に責任を持ちます。
つまり、どちらも「全体」としての「方針」を決め、「統制」「移譲」するかに関心があります。もちろん、実際に方針を明文化して強制するか、推奨だけ出して実際に判断は各担当者にお任せするかなど濃淡はあります。そういった打ち出し方にも色々あるよね、というところもデータガバナンスとアーキテクチャ設計で類似のところです。どちらも構造を考えたり、統制を考えるからですね。
ジレンマ
双方が直面せうるジレンマは、統制をどこまで強くするかと、スピードのトレードオフです。「はじめに」に上げたガバナンスとアーキ設計の記事のどちらにも類似の記述をしました。
- ルールを厳しくすると長期的にはメリットがあるが
- データ利活用のハードルがあがり、ビジネスのスピードが落ちる
- システム開発の自由度が下がり、学習コストの増大やデリバリーが遅延する懸念
- 中央側がボトルネックになりがち
- ルールを緩めすぎると短期的にはメリットがあるが
- 将来的にはデータのサイロ化や、使われないダッシュボードやテーブルが増大し、自縄自縛の懸念
- 設計・実装方式がバラバラなため、学習コストが高く影響範囲の見極めが大変な運用しにくいシステムに
- 各担当者、各領域のスキルセットで揺れ幅が大きくなる
アーキテクトの役割の1つに、「ITガバナンス、システムガバナンス」があると思えば、これらの類似性は至極当たり前であるとも言えます。どちらも、今のスピードを犠牲にしてでも、将来的な破綻を防ぐために、あえて制約を設ける仕事であるためです。上手く存在意義を伝えないと現場からは、必要悪と言うか嫌われ役と言われればまだしも、不要じゃない？と言われかねない立場です。
仮説とFit & Gap
コンサルタントとして質の良い仮説の立案ができるかどうかは、ジュニアからミドル・シニアへ成長するための必須スキルです。どのような方針を決めるかにも共通点があります。まず、以下の原則と流れで進めることが多いです。
- 最初から完璧な方針は存在しない
- とは言え、方針がなにもないと始まらないので、仮説ベースで作る必要がある
- 仮方針が現実的に機能するかを検証し、仮案にフィードバックしFit & Gapを埋める
最初は「エイヤ」でデータガバナンスやアーキテクチャの全体方針を打ち出します。それを各個別領域やサブシステム/機能設計開発に適用できるか確認します。方針が何も無いと現場からしても、設計するための拠り所がないため、思考の精度が落ちてしまいます。適度な制約は思考を深くすることに役立ちます。
反発が合ったとしても、それが「わがまま」なのか（このパターンは出会ったことがあまりないですが）、「妥当」なのか見極めます。だいたいにおいて反発がある時点で「妥当」なことが多く、むしろ現場が「我慢」して受け入れていることが多いです。方針に反発するのも時間・体力が必要なものですし、おそらく中央の方針に反発することを推奨するような教育や文化を持つことはあまりないためです。そのため、反応のないことがすなわちOKではなく、自分たち側からヒアリングしにいくことが最低限やるべきことです。
できれば、自分たちが策定した方針で、実際にデータ利活用の業務運用やシステム開発をすべきです。それによって、おそらく過剰/過小なルールであったり、説明の文面がよろしく無いこと、整合性が無い点が浮き彫りにできます。このあたりの抽象・具体の検証をなくして、実効性のあるルールを作ることはできません。
もし、自分たちでの運用や開発ができなければ、別の部門/チームに検証をお願いすることになります。αテスター、βテスターの依頼です。それなりにドキュメント類のクオリティーを高めてからでないと機能しないため、慎重に依頼すべきですし、依頼者側に不満を溜め込むことが多く、適切なお題や期間設定など含めてかなり大変です。しかし、達成できればかなりルールに自信を持つことができるため、今後の展開の説得力を増すこともできます（基本的に、現場は実績がない方法を適用させようとする、テスター扱いを嫌うためです）。
まとめると、「抽象度の高い方針」と「具体的な個別対象」を行き来しながら、少しずつ今ベストな統制の精度を高めていくサイクルが、データガバナンス設計者とアーキテクトで共通しています。
ルールを機能させるのは、結局「人」と「文化」であること
どんなにバランス感がある立派な方針を作っても、受け手側の成熟度が追いついていなければ機能しないという点です。これくらい知っておくべき、という思考は当然あるのですが、現実としてそうなっていないのであれば、ルールなのか現実をどうにかする必要があります。
組織の成熟度への依存
良い塩梅だと思ったデータガバナンスや、モダンなアーキテクチャ方針を打ち出しても、現場メンバーの熟練度やリテラシーが不足していると、ポカンです。あまりにも斜め上に振り切ると、「よく分からないことを言い出したぞ」とやんわり無視されるリスクがあります。また、当然ですが組織が保守的であれば、新しい方法を受け入れる余地は少ないでしょう。
教育とナレッジマネジメント
そのため、データガバナンス担当もアーキテクトも、本質的な業務ではないはずの 「学習支援」や「教育」に多くのリソースを割くことになります。
- スキルの底上げ: 方針を理解し実践できるレベルまで、メンバーのスキルを引き上げる。勉強会を開催など
- ナレッジマネジメント: ベストプラクティスを言語化し、誰でも参照できるようにする。Wikiなど
文化醸成と情報発信
さらに、「なぜそのルールが必要なのか」を浸透させるための文化的アプローチも欠かせません。
- インセンティブ設計: ルールを守ることで「開発が楽になる」「評価される」といったメリットを感じさせる
- 社内外への発信: テックブログや登壇などで「自分たちはこういう方針を目指している」と発信する。経営層など企業のマネジメント層の意思があることや、後ろ盾があることも重要です
社外に向けて発信することで、社内のエンジニアに「うちは先進的なことをやろうとしているんだ」という誇りや自覚（良い意味での外圧）を与えることができます。この「情報発信の重要性」も、両者に共通する大きな要素です。
方針だけ立てて、「後はよろしく」ではなく、本気度を伝えること。響かない人には響きませんが、熱は伝播するものです。
スキルセットと視座
スキルセットの点でも、両者は似ているように感じます。
- 抽象化能力: どちらも具体的な事象（個別領域）を抽象化して、モデル（全社方針やPJ方針）に落とし込む能力が求められます
- データフロー設計: アーキテクトにとっても、データがどう流れるかはシステム設計での要です。魂かもしれません
- データアーキテクチャ: データマネジメントの知識は、現代的なシステムアーキテクトには必須の知識です。システムがデータ基盤に全くデータ連携しないことは、今や考えにくいです
アーキテクトはデータガバナンスの視点を持つべきですし、データガバナンス担当者はアーキテクチャの視点を持つべきだと思います。データガバナンス方針を立てたとして、対象システムがその方針を実現することが不可能なアーキテクチャであれば、絵に書いた餅です。
個別システムとしても、そこで生み出したデータを最大限に活かすことの重要度は、AIの登場で増しています。ガバナンス要求を達成できるシステムアーキテクチャを採用すべきですし、ガバナンス要求が無かったとしても全社視点で将来の要求を予測して、実際に対応するかどうかは別として、「受け身」を取れるように考慮しておくべきでしょう。
さいごに
「データガバナンス」の人と、「アプリ/インフラのアーキテクチャ」の人は、役割上、体制図では分かれていることが多いでしょう。しかし、扱っている課題の構造は類似しています。
- 全体最適・個別最適のバランス
- 現場のスピードを殺さず、どう長期的な目線で統制を効かせて、良い状態を作り出すか
- 仮説を作る力と、仮説検証のサイクルをどう回すかの段取り力
お互いの知見は、そのままもう一方の領域に流用できる可能性が高いです。今、データガバナンスやアーキテクチャ設計に関わりが無い方も、どちらか片方にチャレンジするとその先のキャリアが広がるかもしれません。すでにどちらかを経験している方は、別の一方の未知がすでに開いているかもしれません。