クラウド型のDWH(データウェアハウス)サービスや、ETLツールの普及によってデータ分析基盤の構築は容易になりました。

また扱いやすいツールの誕生によって、現在では非エンジニアでもデータを分析・活用できるようになりつつあります。

しかしこれらのツールを活用してデータの活用を浸透させるには、データエンジニア主導でデータ分析基盤全体を管理していく、データマネジメントが欠かせません。

データマネジメントは、アメリカのデータエンジニアによって17の領域にカテゴリー化されています。(データマネジメント知識体系ガイド 第二版

そのなかのひとつ、データ分析基盤全体の設計に関わる項目が本記事のテーマ「データアーキテクチャ」です。

本記事ではデータアーキテクチャの構築方法、その際に押さえておきたいポイントを解説します。

データアーキテクチャとは

データアーキテクチャとは、データに対するビジネスサイドのニーズから必要なデータ要件を洗い出し、それを満たすシステムやデータの流れを設計することです。

データアーキテクチャを主導する役割をデータアーキテクトといいます。

データアーキテクチャなしに、ユーザーの求めるままにデータ分析基盤を導入してしまうと、

  • 同じデータを複数のデータベースで管理してしまい無駄が生じる
  • データの管理者が明確でないためデータの品質が低下する
  • データの増加によるシステムの拡張を管理しきれない

など、長期に渡って安定的にデータを運用するのが困難になります。

しかしデータアーキテクチャを実施すれば、データの量や質が変化しても安定して運用でき、データ品質の低下にも強くなります。

データアーキテクチャの役割

データアーキテクチャの役割は、データに対するビジネスサイドのニーズと、自社のデータが結びついたデータ分析基盤の設計図となることです。

「ビジネスサイドのニーズと、自社のデータが結びついている」とは、「データの変化(削除・編集)がどのビジネスに影響するのか」が適切に管理できていることを指します。

データが収集され、ビジネスサイドで活用されるまでのデータの流れ(データフロー)を明確に設計し、それに沿った最適なデータベース・システムの配置が可能です。

データアーキテクチャとデータメッシュとの関係性

データアーキテクチャに関連し、近年データエンジニアの分野で「データメッシュ」のワードが注目されています。

従来のデータ分析基盤は、データベースをエンジニアが管理する中央集権型のデータアーキテクチャが主流でした。

データメッシュとは、データアーキテクチャのパターンのひとつで、中央集権型アーキテクチャの課題に対応するために考えられた分散管理型のデータアーキテクチャです。

くわしくは以下の記事で解説しているため、この機会にぜひご覧ください。

データメッシュとは?活用する魅力や4原則、必要性を解説

データアーキテクチャの設計に必要な要素と成果物

データアーキテクチャの設計は下記の4つの要素に分けて考える必要があります。

  • ビジネス
  • データ
  • アプリケーション
  • テクノロジー

このうち、「アプリケーション」「テクノロジー」の2つは、「データ」の要件を満たす具体的な技術要件と言い換えられます。そのため大きく「ビジネス」と「データ」の2つに分けて考えられます。

この2つの観点からデータの要件を洗い出し、データモデルとデータフロー図という成果物にまとめるのが、データアーキテクチャの最終的なゴールです。

エンタープライズ・データモデル

具体的なデータの流れをデータフロー図にまとめる前段階として、データベース全体を大まかに設計してエンタープライズ・データモデルを作成します。

エンタープライズ・データモデルは、実際にシステムを実装する際のことはあまり意識しません。データベース全体の構造が、ひと目でわかるようなモデルであることが理想的です。

まずはデータを必要とするビジネスサイドの部署・部門を書き並べ、彼らがアクセスしているデータベースを線でつないでみる簡単なモデルから始めるのが有効でしょう。

複雑化した現状のモデルをなるべく管理しやすく、シンプルなモデルに再構築していく作業を通じてエンタープライズ・データモデルが作成できます。

データフロー図

大まかに策定したエンタープライズ・データモデルを具体化したデータフロー図を作成します。データアーキテクチャの実装とは、正確にはデータフロー図の実装を指します。

データのフロー(流れ)のとおり、

  • データがどこで収集され
  • どのデータベースに格納され
  • どこへ運ばれていくのか

を詳細に書き出していきます。

データフロー図の書き方に決まりはありませんが、一般的にはER図を利用するのがよいでしょう。

ER図を例にしますが、各エンティティの横に追記するような形で、ビジネス要件・データ要件を書き入れていきます。

たとえば法的観点では、「個人情報は利用終了後ただちに削除する必要がある」というビジネス要件があります。しかしそのデータを引き続き参照したいセールス部署にとっては、データが削除されてしまうと必要なデータ要件を満たせません。

そこで個人情報の一次データは法務の要件に従って削除しつつ、氏名などのデータをカットした二次データを作ります。セールス部署には二次データを参照してもらうなど、各部署の要件を満たせる具体的なデータフローを設計していきます。

データアーキテクチャを構築する前に社内データの全体像を把握しよう

データアーキテクチャの構築は、理想的なデータベース全体を概観できるモデルがあること、そのモデルを具体化したデータフロー図という成果物がゴールです。

しかし現実には、ゼロからデータアーキテクチャに基づいてデータベースを実装することはありません。大なり小なり、すでにデータを利用している現状の改善からスタートするのが一般的になります。

先述のデータメッシュのように、パターン化されたアーキテクチャは存在しますが、それを無理やり自社に当てはめようとすると既存アーキテクチャとのズレが大きく、既存業務が混乱し、実装に失敗してしまう可能性があります。

現状のデータ基盤を効果的に改善するには、ビジネスサイドのニーズを吸い上げるとともに、社内のデータベースの全体像を把握し、既存のアーキテクチャを活かすような改善を目指すことが有効です。

データアーキテクチャを構築するまでの手順

先述のエンタープライズ・データモデルとデータフロー図に基づき、データアーキテクチャを実装していく具体的な手順を確認します。

以下の手順に沿ってアーキテクチャを構築し、データマネジメントが行き届いた理想的なデータ分析基盤の土台を構築していきましょう。

またデータアーキテクチャの構築・改善は、データエンジニアチームのみの取り組みではなく、組織体制にも変化を求める取り組みになります。

どのようなステップでデータアーキテクチャを改善していくかは、経営層や各部門のトップにも共有しておく必要があるでしょう。

現状のデータベース設計に関するドキュメントの収集

先述のとおり、まずは現状のデータベースの全体像を把握します。

ただし闇雲にデータベースの構造を書き出すのは、効率的な進め方とはいえません。データベースの構造や、データベース内の依存関係をドキュメントにまとめるのが有効です。

一度データフロー図を作成していれば、それを参考に変化した部分を追記するだけで済みます。

しかしデータアーキテクチャを初めて構築する際は、各データベースを開いてどのようなデータが存在して、どのようなフローになっているかを地道に調べていく必要があります。

場合によっては、ビジネスサイドの各部門でのデータの扱いもヒアリングし、漏れなくデータの全体像を把握していきましょう。

業務上で必要なデータ要件の抽出

データベースの全体像が把握できたら、ビジネスサイドのデータユーザーにヒアリングを行い、必要なデータ要件を洗い出します。

ヒアリングして得られたデータ要件は、前の工程で作成した現状の全体像に書き込みます。各データベースに格納されている、それぞれのデータに求められる要件を明確にします。

またデータ要件を書き込み明確にしていく過程で、「収集はされているが実際は誰も活用していないデータ」の存在も明らかになるかもしれません。

誰も活用していないデータは「結局何のためのデータかわからず、後になると消すに消せない」「データベースの運用コストを上げてしまう」などの不便を発生させます。

タイミングを見極めてデータを整理すると良いでしょう。

データベースの全体像に、ユーザーが求めるデータ要件が加わることで、現状の保有データとビジネスサイドのニーズとの結びつきに対する理解が深まります。

データアーキテクチャの設計

次は明確になった現状のデータアーキテクチャをふまえ、改善されたアーキテクチャを設計するステップです。

先述のエンタープライズ・データモデルとデータフロー図の作成が、本章の工程に該当します。

具体的な手順はすでに解説したとおり、まずは改善後のアーキテクチャを大まかにまとめ、エンタープライズ・データモデルを作成。

作成したモデルに基づいて、データ要件を漏らさずデータフロー図に落とし込んでいきます。

組織体制の構築と実行

スケールアップが前提のデータ基盤を少数のデータエンジニアのみで、管理・運用していくのは有効ではありません。

ビジネスサイドの責任者にも協力を仰ぎつつ、各データの責任者を決めるなど、設計したデータアーキテクチャを運用する組織体制の構築が必要です。

このとき参考にしたいのが先述のデータメッシュの4原則のひとつ、「プロダクトとしてのデータ」です。

単にデータを収集されたまま基盤に取り込めばデータに対する責任が果たされるのではなく、そのデータが活用されていくことを意識して使いやすいデータを提供する「プロダクトとしてのデータ」を実現する組織体制を作ることでアーキテクチャの円滑な運用にも役立ちます。

組織体制にも関わるデータマネジメントはこちらの記事でも触れています。

ぜひこの機会にご覧ください。

データマネジメントとは?必要性や成功に欠かせない前提条件、参考事例を解説

データアーキテクチャを構築する際のチェック項目

高度なデータアーキテクチャを構築するには、「変化に強いアーキテクチャか」という観点をもつことが重要です。

データニーズが変化するなか、現状の改善に主眼をおいた場当たり的な改修を実施すると、いずれデータアーキテクチャの改善が必要になってしまうからです。

企業が取り扱うデータ量は増加の一途を辿っており、取り巻く環境の変化に応じて社内のデータニーズは絶えず変化します。その変化に対応していくためにも、本章で紹介する項目を確認してください。

膨大なデータを扱う場合は分散型アーキテクチャを活用する

増え続けるデータ量にも対応できる高いスケーラビリティを備えたデータアーキテクチャを構築するひとつの手は分散型のアーキテクチャを取り入れることです。

代表的な分散型アーキテクチャのデータメッシュでは、データの管理責任をエンジニアから各部署・部門に移管することで、データ品質を落とさず膨大なデータを扱えるように設計されています。

今後、より多くのデータを取り扱いたいと考えている企業は、部分的にでも分散型のアーキテクチャを取り入れてみてはいかがでしょうか。

非エンジニアでも使えるツールの導入を検討する

ユーザーのニーズの変化に対するボトルネックは、ユーザーの欲しいデータに対して準備を担うデータエンジニアが絶対的に不足してしまうことです。

しかし冒頭の導入分で述べたように、近年は非エンジニアでも扱いやすいツールが登場しています。ツールをアーキテクチャに組み込むことで、データエンジニア不足のボトルネックを解消できます。

たとえば、非エンジニアでも利用できるツールのひとつにETLツールがあります。

従来ETLはエンジニアが膨大な工数をかけて構築していましたが、現在はETLツールにより画面上の設定のみで誰でも構築可能になりました。

ツールを活用してエンジニアに依存しないデータ活用ができるようになると、ビジネスサイドはアイデアを思いついたらすぐデータを分析・活用できるようになります。時代の変化に素早く対応するためにも、非エンジニアでも使えるツールの導入を検討してみてください。

まとめ

最適なデータ分析基盤に欠かせないデータの設計図、「データアーキテクチャ」の役割や作り方の手順を解説しました。

データアーキテクチャの構築は地道な作業が多く、中長期に渡る取り組みになります。しかしデータ運用の効率を大きく高める効果があるため、ビジネスにデータを活用していきたい企業にとっては欠かせないステップです。

自社のデータ運用に課題を感じている企業の担当者の方は、ぜひデータアーキテクチャの構築を検討してはいかがでしょうか。

弊社はデータ分析基盤の総合支援サービスtrocco®を提供しています。分散型アーキテクチャに欠かせない各部署・部門主導の「セルフサービス型データ基盤」を強力にサポートするツールです。

データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご覧ください。

trocco® ライター

trocco®ブログの記事ライター データマネジメント関連、trocco®の活用記事などを広めていきます!