DMMA

このポストについて データ基盤移行について書かれた各社の技術ブログなど見かけることがありますが、割とさらっと書かれていることが多いように思います。 本当はいろんな面で苦労があり、記事に表れていない辛さや工夫などがあるはず。 ということで今自分が経験している普通の会社の普通のデータ基盤移行について、詳しく記事にしてみようと考えました。 何回かに分けてデータ基盤移行のいろいろな側面を、うまくいったこともいかなかったことも含めて書いていきます。 とはいえ現在進行形なので、全編書き終わるのはかなり先になりそうです。 移行の背景 組織 まずイメージしやすいよう、どういった組織におけるデータ基盤移行なのかについて軽く触れておきます。 社員規模: 〜100名 web 系の B2C ビジネス データチームの構成 マネージャ: 1名 (データエンジニアリングの経験はほぼない) データエンジニア: 2 -> 3名 (途中で採用) 中小のベンチャー？企業ではありますが、意思決定プロセスは JTC 感があります。 私はデータエンジニアのポジションとなっており、その視点からの話であることにご留意ください。 小さい組織ということで私は移行の計画から設計、開発その他のあらゆるフェーズに中心的に関わっています。 どこもそうだと思いますが、人員的にはまあまあきびしい。 よくある中小 IT 企業のよくあるデータ基盤移行の話だと思っていただきたく。 大企業ではないのでそこまでちゃんとはしていません。 (ちなみに自分のブログで本件を記事にしていいかは上長に確認の上、OK をもらっています) 旧データ基盤 一連のポストでは移行前のデータ基盤のことを「旧データ基盤」と表記するものとします。 旧データ基盤は AWS 上で構築されており、アーキテクチャについて簡単に挙げると storage: S3 ETL: Glue Job, Athena SQL engine: Athena workflow orchestration: MWAA のようになっていました。 旧データ基盤の開発・運用側 (データエンジニア) としても、また社内の利用者側としてもいろいろと問題が挙がってきてはいました。 しかしそれをうまく集約・言語化できていないという状況でした。 そんな中でエライ人の鶴の一声で移行しようぜ！ということになり、データ基盤の移行を検討することに相成りました。 移行計画を考えるにあたり まず考えたこと データ基盤の移行は組織におけるデータマネジメントにおいて重要な位置づけとなるはず。 したがって単なる技術スタックの置き換えというスコープで考えるのはもったいないです。 組織のデータマネジメントの未来を想定して、戦略を持って開発・運用を進めるべきであると考えました。 そのためにはイシューを明確化しないといけません。 でもどの抽象度レベルで？ ボトムアップの戦術策定 まずは現場感覚、ボトムアップでの課題を明らかにすることを考えました。 本来は後述する戦略レベルから先に考えるべきですが、実際に目に見えている課題があり、取り組みやすかったというところで戦術のレベルから考え始めています。(良し悪しはある) 現状のアーキテクチャと運用では戦略策定への対応が難しいため、せめてそのための地ならしとして今見えている課題に対応できる状態にしたいというのもありました。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第15章「データマネジメント成熟度アセスメント」について。 データマネジメントの導入において重要な役割を果たしそうなので早めに確認しておきたかった。 以降、特に注釈のない引用は DMBOK2 第15章からの引用とする。 データマネジメント成熟度アセスメントとは データマネジメント成熟度アセスメント (DMMA: Data Management Maturity Assessment) はその名の通り、組織のデータマネジメントのレベルの評価に基づくプロセス改善の取り組みのこと。 能力成熟度アセスメント (CMA: Capability Maturity Assessment) というものがあり、それのデータマネジメント版が DMMA。 CMA では 成熟度モデルは進化の観点から定義され、それにはプロセスの特性を表すレベルが使用される。組織がプロセスの特性を理解すると、組織は成熟度を測り、その能力を向上させるための計画を立てることができる。(中略) 新しいレベルに上がる度にプロセスの実行はより一貫性を増し、予測可能な状態となり、信頼性が高くなる。 レベルは通常0~5の6段階で表される。 DMMA は 全体的なデータマネジメントを評価するために使用したり、単一の知識領域や、単一のプロセスに焦点を当てて使用したりできる。どのような点に焦点を当てたとしても、DMMA はデータマネジメント業務の健全性と有効性について、業務と IT の視点のギャップを埋めるために役立つ。 組織が DMMA を実施する理由は、規制への対応、データガバナンス、プロセス改善、etc. DMMA の第一のゴールはデータマネジメント活動の現状を評価することであり、それにより改善計画を立てることができるようになる。 アセスメントレベル 以下はアセスメントレベルの概要。 データマネジメントの各知識領域 (ex. データガバナンス、メタデータ管理、etc.) ごとにレベルが評価される。 level 0: 能力が欠如した状態 データマネジメントの取り組みがない level 1: 初期／場当たり的な状態 限られたツールセットを用いた一般的なデータマネジメント ガバナンスは低レベル データ処理は一部の専門家に依存し、役割や責任は部門別に定義されている level 2: 反復可能な状態 組織は一元化された共通ツールを使い始める 役割は明確化されており、一部の専門家のみに依存しない level 3: 定義された状態 拡張可能なプロセスの導入と制度化 組織全体である程度統制されたデータの複製 データ品質全体の総体的な向上 組織的なポリシー定義と統制 level 4: 管理された状態 新しいプロジェクトやタスクから得られる結果が予測され、リスクの管理が始まる データマネジメントに成果に対する評価尺度が含まれる データマネジメント用の標準ツールが集中管理計画とガバナンス機能に組み合わされている level 5: 最適化された状態 活動の成果は十分予測可能に 組織は継続的な改善に重点を置く 十分理解された評価尺度を使ってデータ品質とプロセスが管理・測定される 次のように各知識領域ごとに可視化することができる。 現状ランクと求められるランクの乖離が大きいところが組織にとってのリスクとなる。 ...