はじめに
みなさんこんにちは！
サイボウズ株式会社でデータエンジニアをしている松田です！
普段は社内のデータを一箇所に集約した「全社横断データ基盤」の運用・活用を担当しています。
最近私は、データ基盤に関する外部の勉強会等へ参加するようになり、データ基盤のアーキテクチャについて考える時間が増えました。
そして、様々な企業のデータ基盤を開発・運用した際にアーキテクチャについて思っていたことや、学んだことを振り返ってみました。
みなさんも普段の業務で以下のようなことを思ったことはありませんか？
- データ基盤をもっとユーザーが使いやすいものにしたいが、どうしたらいいかわからない
- データ基盤を運用しているが、今の運用方針であっているのか迷っている
本記事では上記のような思いを抱えたデータエンジニアの皆さんに向けて、私が前職などで携わってきた企業の開発・運用現場で経験したことを例に、データ基盤のアーキテクチャの適性や失敗談をまとめてみました。
データ基盤のアーキテクチャとは
本ブログで私はデータ基盤のアーキテクチャを以下のように定義しました。
「社内のデータに関する様々な要件を整理し、それらを満たすことができるシステムやデータを設計すること」
似たような言葉で「データアーキテクチャ」という言葉があります。
もしかしたら同じものとして捉える人もいれば、データ基盤のアーキテクチャはデータアーキテクチャの一部と捉える人もいるかもしれません。
細かくは私も勉強中ですが、今回はあくまで「データ基盤のアーキテクチャ」という表現で記載させていただきます。
データ基盤のアーキテクチャのスタイル
データ基盤のアーキテクチャのスタイルは大きく分けると「中央集権型」「分散型」の2種類と考えています。
それぞれの特徴を下記にまとめました。
中央集権型
中央集権型は、すべてのデータを一箇所に集約して、統制された環境で管理・活用する設計です。従来のデータ基盤はこのアーキテクチャを採用している組織が多いのではないでしょうか？
メリット
-
データの一貫性が保たれる
たとえば、営業部とマーケティング部が同じ顧客データを使っているので、情報の食い違いが起きにくいです。 -
ガバナンスが効きやすい
IT部門がアクセス権限や利用ルールを一括管理しているため、誰がどのデータを利用できるか把握できます。
デメリット
-
柔軟性に欠ける
現場から「このデータを追加してほしい」と要望があっても、対応に時間がかかってしまうことがあります。 -
初期構築・運用コストが高い
データレイクやETLの仕組みを整えるのに数千万円かかるケースもあり、導入まで半年以上かかることもあります。 -
ボトルネックが生まれやすい
データの取得や加工をIT部門に依頼する必要があり、申請が集中すると対応が遅れて業務に支障が出ることもあります。
「統制と効率」が強みですが、「柔軟性とスピード」には課題が残る印象です。
分散型
分散型は、各部門やチームがそれぞれのニーズに応じてデータを管理・活用する設計です。
最近では「データメッシュ」などの考え方もあり、再注目されています。
メリット
-
柔軟性が高い
たとえば、マーケティング部がSNSデータを自分たちで収集・分析して、すぐに施策を改善できるような動きが可能です。 -
スピード感のある意思決定が可能
営業部が自部門のデータをリアルタイムで見ながら、即座にアプローチ方法を変えることができます。 -
スケーラビリティが高い
新規事業部が独自のデータ基盤を構築しても、既存のシステムに影響を与えずに拡張できます。
デメリット
-
データの一貫性が保ちにくい
同じ顧客でも、部門ごとに違うIDや名前で管理されていて、後から統合しようとするとかなり手間がかかります。 -
ガバナンスが複雑になる
部門ごとに管理方法が違うため、セキュリティポリシーの統一や監査対応が難しくなります。 -
重複投資のリスクがある
似たような分析ツールを複数部門がそれぞれ導入していて、結果的にコストが無駄になっているケースもあります。
「現場主導の柔軟なデータ活用」ができる一方で、「全社的な統制」には工夫が必要です。
ここで気をつけていただきたいのは、分散型とまとめていますが、集中管理するものがゼロということではありません。
あくまで分散管理できるものは各ドメインに任せて、集中管理するものは必要最低限にしようということです。
データ基盤構築現場での体験談
中央集権型に適した企業
中央集権型に適した企業の特徴を私が今まで経験したことをベースに整理してみました。
以下のどちらかに当てはまる企業は中央集権型を選択するケースが多かったです。
1. データに関する厳格な社内ルールが設定されている
企業全体でデータの扱いに慎重な企業には分散型よりも中央集権型が適していると思います。
厳格なデータ管理のために、事業部やグループ会社間で直接データを共有することや、連携可能なデータに厳しい制限がかかっていることも少なくないでしょう。
個人情報の管理規定(社内での制約だけではなく、ユーザーから情報を取得する際に許可を取れているかなど)、クラウド環境のリージョンの指定、データ管理者の所在、社内業務の承認方式、テナントの種類など様々な制約を考慮する必要も出てきます。
これらの制約を満たし全社横断でデータ活用をするためには、企業内でデータを一箇所に集約し、データガバナンスを効かせることに優れた中央集権型が適していると考えられます。データだけではなく、データを利用のための承認フローの集約も大切なポイントだと考えています。
私がデータ基盤開発に携わった企業では、データ基盤のアーキテクチャを選定する上でデータガバナンスに関する要件を最優先事項となることがほとんどでした。
2. トップダウン型または階層型の意思決定構造
意思決定のフローが経営層から現場に向かって流れる企業も中央集権型適していると考えています。
意思決定をする際に必要な情報が中央のデータ基盤に集約されていることで、経営層のデータへのアクセスが容易になり、早く正確に経営方針を判断することができます。
各部署からの報告資料などに、現場判断で作成された独自のデータフォーマットやそれらを使用した分析結果を使用することが減り、データの整合性(企業内で用いる「売上」や「契約日」などを定義しやすい)が保たれます。
部署によって報告に使われる言葉の定義が違うだけではなく、集計方法の違いや、可視化ツールのばらつきなどは一度起きてしまうと整理するために膨大な時間を要することになり、データ活用の障害となっているケースも実際の開発現場で経験してきました。
上記のように中央集権型のアーキテクチャに適した企業のポイントを整理しましたが、実際に運用に乗せてみると運用前には想定できなかった課題が見つかることも多々あります。
私のこれまで失敗談を一部紹介させてください。
固まってしまったデータ基盤
グループ横断のデータ基盤を作成するために、あるグループ会社のデータを一箇所に集約したデータ基盤を構築しました。
アーキテクチャを選定した理由は、データガバナンスを効かせることが第一要件だったからです。
グループ内のデータを中核企業のデータ基盤へ統合したのですが、集中させた結果社内の多種多様な依頼に対応しきれず活用が進まなくなってしまいました。
以下は当時活用促進のために抽出した課題の一部です。
- データ量が多すぎてワークフローが始業時間までに終わらない
- 各企業のデータソースの更新頻度がバラバラで集計に影響が出ている
- メタデータ(データカタログ)の整理ができておらず、結局サイロ化が解消されていない
- データガバナンスを効かせるために1つのDWHに集約したが、集めただけになってしまっていてガバナンスが効いているのか評価ができていない
- 処理能力を上げるために、DWHを他のSaaSサービス等へ移行をしたいが、載せ替えの規模が大きくコストがかかりすぎる。現状維持するしかない。
上記の通り、データガバナンスを効かせるためという理由で、中央集権型のアーキテクチャを選択したのですが、結果的に分散型で構築したほうがよかったというケースもありました。
また、同じグループ内でも企業文化の違いがあり、データ基盤を統合したからといって活用が進むとは限らないということを忘れてはいけません。
この企業のデータ活用を促進すべく行った改善は、まずグループ全体で比較したいデータ(当時は営業部門のみ)だけを中央のデータ基盤へ集約し、その他のデータは子会社単位で管理する方法への変更です。データガバナンスを効かせたいという要件は重かったのですが、中央のデータ基盤で効かせる必要性があるのかを再度確認し、子会社単位で活用できるようにポリシーを見直したことで、一部のデータを柔軟に活用できるようになったことがとても大きなポイントでした。
分散型に適した企業
分散型に適した企業群の特徴を私が今まで経験したことをベースに整理してみました。
以下のどちらかに当てはまる企業は分散型のデータ基盤を選択するケースが多かったです。
1. スタートアップ
急成長するスタートアップ企業には分散型が適していると考えられます。各部署が責任を持ってデータを管理することで、データの収集・分析のスピードが向上し、迅速な意思決定ができるようになります。
また、企業規模や事業の拡大、組織編成や、人の入れ替えなどが他の企業よりも頻繁に起こる可能性が高いため、中央集権型ではこの柔軟性に対応できない場合が多いです。部署ごとにデータチームへ依頼し、対応を待っている間に、さらに追加で別の依頼が発生してしまうこともあるでしょう。
2. ボトムアップ型の意思決定構造
中央集権型との大きな違いがこの意思決定構造ではないかと私は考えています。ボトムアップ型の企業では、社内風土や部署同士の関係性がフラットなことが多く、現場手動で進めていくことが大事になります。部署レベルの知見や立案~実行のプロセスに適したデータモデルの構築や分析手法を採用することもでき、柔軟な業務遂行に適しています。
また、部署ごとが責任を持ってデータを管理することで、メタデータの整備も中央集権型と比べて容易になることが多いです。各部署ごとに生み出されるデータに関して、どのように生成され、何に使われているのかを把握しやすくなり、他部署への共有もスムーズになります。
分散型のアーキテクチャについても経験したことを下記にまとめてみました。
分散しすぎたデータ基盤
ベンチャー企業でのデータ基盤導入時に、分散型のアーキテクチャで構築することになりました。
企業規模として5、60名程度でこれから幅広く事業を拡大していきたいという話も出ており、導入技術の選定も各事業部ごとに自由に行える環境でした。
データチームとしては個人情報など機密性の高いものの管理についてドキュメントを作成し、それに沿って運用してもらいました。今思い返すと、ガバナンスも含めて運用ルールをもっと細かく定めておけば良かったと後悔しております。運用フェーズに入り、部署ごとに自走できる状態で、当初は活発に活用されていたのですが、運用を始めて半年ほど経ってから、データチームへの依頼が増えてきたのです。
以下依頼内容の一部です
- 同じようなテーブルやレポートがたくさんある
- 他部署のデータがわかりづらい
- 他部署のデータを紐付けたいが、何をキーにしたらいいのかわからない
- データの閲覧権限が部署移動後も残ってしまっている
このプロジェクトでは大きな反省が2つあります。
1つ目は、このようにスピード感と柔軟性を意識しすぎた結果、データの品質が担保できない状態を作り出してしまいました。データチームとしてデータの品質に関するドキュメントやルール整備を行うべきだったということ。
2つ目は、このプロジェクトのネクストステップとして、経営層が毎日確認できるようデータを集約することが決まり、最初は中央集権型で構築し、運用で慣れてきたら分散型に少しずつ切り出す方法を取るべきだったということ。
現場の意思を尊重するということを重視しすぎて、その後のフェーズを想定できていませんでした。
上記にまとめた依頼一覧の中で、当時特に多かったものは、他部署のデータやモデルが理解できないというものでした。部署ごとに独自のデータマートを作っており、データカタログ自体はあったのですが、他部署の人が見ても言葉の定義がバラバラで利用しづらい状況になっていたのです。
分散型のデータ基盤のアーキテクチャの実用例は中央集権型と比べてまだまだ少なく、事前に気をつけるべきポイントを洗い出しきれていなかったことも大きな要因だったと考えています。
アーキテクチャを振り返ってみて
ここまで、データ基盤のアーキテクチャについて、中央集権型と分散型に分け、私自身の経験を交えながら整理してきました。
どちらのアーキテクチャにもメリット・デメリットがあり、企業の文化や意思決定のスタイル、データガバナンスの方針によって適した形は異なります。
当初は理想的だと思った設計でも、運用フェーズでの課題は必ず出て来ると思っています。
だからこそ、定期的な振り返りと改善、そして現場の声を取り入れた柔軟な対応が重要だと考えています。
みなさんも自社のデータ基盤をアーキテクチャという視点で振り返ってみてください！
Discussion