見出し画像

失敗しないData Intelligenceプロジェクト体制の考え方

はじめに

歴史的にデータカタログの導入プロジェクトの多くが失敗してきており、一方で、昨今の企業環境では全社的なメタデータ管理とデータガバナンスを確立し、エンタープライズ・データインテリジェンスを実現することが益々重要性を高めています。かつての失敗の多くがプロジェクト体制の未確立や運用組織変革の失敗によるものだとされていますが、今後複雑性を増す大企業組織においてこの問いにどう対応していくべきでしょうか。本ブログでは、データインテリジェンス成功のためにプロジェクト体制と組織変革をどう考えると良いか、掘り下げて記載します。※前提として、売上規模5,000億円以上のエンタープライズ組織を想定して書いていますが、基本的には個別事象であることも多く、全ての企業にはパターンが当てはまらないことをご理解いただけますと幸いです。

目指す青写真

まず、データインテリジェンスの最終像を考えます。多くのデータ統合プロジェクトでは、クラウド・データウェアハウスを中心に、ETL、BIツールなど様々なシステムを用意するでしょう。データは源泉にあたる事業部やそれに紐付くIT部署の管理下にあるシステムから収集した後、それらデータの活用を行う部署である別の事業部や本社機能が利用するシステム(やサイエンティスト)が活用できるよう、データ供給の流れを作ります。

データ統合のシステム的な絵

この時、データの流れとセットで、メタデータ(データのデータ)を届ける必要があります。メタデータがあることで初めてデータは二次利用が可能な状態になります。しかしながら、データは物理的な実態でありシステムを接続すれば収集が可能であるのに対して、多くのメタデータは論理的な存在、つまりデータの作成者やデータが発生した業務自体に詳しい人間の脳内にのみ暗黙知として存在します。そして、何故そのデータが生まれたか、どう運用されていたかというメタデータを知ることでしか、データの信頼性を担保できません。

データ統合のシステム絵に加えて、人間・部署、業務フローの流れの絵を追加


メタデータをどういった風に組織に入力させていくか、を業務設計することが重要になります。ツール導入の際にはこうした観点に注意し、部署を跨いでリソースの調整が行えるプロジェクトのオーナーを選出する必要があります。多くの場合は執行役員が該当しますが、CDOやCIOが転職入社の場合、実行チームとの距離が存在する場合もあります。実行チームの一員ながら、社内政治力の強いプロパー社員によるリーダーシップが推進の鍵を握ります。

上記の絵に加えて、プロジェクトオーナーの立ち位置を記載

導入時のプロジェクト体制

データインテリジェンスツール(=データカタログ)は、DWHやETLツールと密接な関係にありますが、本質は業務アプリケーションであることを忘れないでください。それも、今まで業務の存在していなかったメタデータ管理・データガバナンスを対象にするものです。だからこそ、会計業務に経理が存在しているように、メタデータ管理・データガバナンスにもデータスチュワードが必要であり、組織体制の影響を真剣に考える必要があります。多くの「データカタログ」と名乗る製品はこの観点を意識して設計されていないことにも注意が必要です。

まず、DWH・ETL・BIツールとの接続を考える必要があり、ここにはインフラ担当の助けが必要です。しかし、あくまで業務アプリケーションの実装であるため、基本的にはインフラ担当ではなくユーザー部署がプロジェクトオーナーとなることが必要です。この時、データインテリジェンスツールのユーザー部署はデータ分析者ではなく、データ管理者(データのCoE部署)とデータオーナー/スチュワード(データ生成背景に詳しい事業部)であることに注意してください。データ分析者は、メタデータのユーザーではありますが、データインテリジェンスツール自体のユーザーでない場合もあります。(昨今のアクティブメタデータの思想にも通じます。)プロジェクトオーナーとしては、専業でメタデータ管理・データガバナンス実装のミッションを持ったデータ管理者(データのCoE部署)が適任です。もし、企業にまだこうしたミッションを持つ部署がない場合、プロジェクト体制に必要なヘッドカウントが割けず成功は困難を極めます。

プロジェクト体制の絵
プロジェクト体制の例
アンチパターンのプロジェクト体制の絵(IT・エンジニアだけでは推進できません)

運用体制とフェーズ分け

会計ツールを導入したら会計が終わるわけではないように、データインテリジェンスツールを導入してもデータインテリジェンスは完成しません。メタデータ管理・データガバナンス業務を持続的に行うフィールドが整ったと考えるべきでしょう。また、前述の通りデータインテリジェンスプロジェクトの直接のユーザー部署はデータ分析者自体ではなくデータ管理者とデータオーナー/スチュワードなので、クイックウィンの定義としては「メタデータ管理・データガバナンス業務が、用意した体制とツールを通して運用が周りそうかどうかを見極めること」に主眼をおくべきでしょう。同時に、その際に最終的なメタデータのユーザーであるデータ活用部署にとって優先度が高い事柄(メタデータ項目)からスコープを絞りプロジェクトのフェーズを切ることが重要です。また、メタデータ管理・データガバナンスの業務運用に関しては、誰が(Who)どのタイミング(When)でどこに(Where)何を行う(What)かを設計することが必要です。

運用体制の図
運用フェーズの分割例

発展した形(データメッシュとの関わり)

統合データ基盤で運用するデータ種類がある一定ラインを超えて大きくなると、今度はデータ管理者(データのCoE部署)のリソースの問題に直面します。例えば、数十を超える基幹システムのデータを一元に統合しているような場合、或いは統合された後のデータマートが数百を超えて活用されている場合、データ管理者(データのCoE部署)での業務負荷を考え、組織を次のステージへの最適化していくことを検討できるでしょう。メタデータ管理・データガバナンス業務の運用を行う時、ボトルネック要因として大きいのは部署間の距離による戦略(データのCoE部署=全体最適)と実行(事業部署=個別最適)の分離であるため、この段階でデータ管理者(データのCoE部署)の業務と人的リソース、またこれまで培った全社最適の視点/知見を、徐々に源泉事業部と活用事業部へ分散させていくことが必要です。これはそれら事業部へメタデータ管理とデータガバナンスを部分的に移管していくことを意味しますが、この手段を用いることで今までボトルネックになっていた部門間の齟齬を削減し戦略と実行を一致させることができ、全社データ活用を次のステージへと進めることができます。こうした考えはData as a Productの思想に通じ、Zhamak Dehghani氏が提唱するData Meshで中心的な考え方として位置付けられています。前提として、よほどトップダウンで組織変革と実行力を強制できる企業(日本大企業の大半はこれに当てはまりません)を除いては、まずは中央での統合データ管理プロジェクト(物理統合)により組成される組織に相乗りする形でデータインテリジェンスプロジェクト(論理統合)にも取り組むことで、メタデータ管理とデータガバナンスのノウハウとマインドセットを一部のリーダー社員に醸成し、その後そうしたリーダー社員を兼務などによる事業部への派遣を行い、全社最適(戦略)と分散管理(実行)を両立させる(連邦型)のを実現させるのが現実的です。

組織内部の人事異動の画像
組織フェーズの分割例

終わりに

昔からデータカタログと言われるツール群は「DWH間の検索を抽象化し統一したポータル」というイメージが強くありました。実際のところ、データカタログは「メタデータ管理・データガバナンスを最大限自動化するための業務アプリケーション」である側面がより重要です。(多くのデータカタログプロジェクト失敗はこの側面が無視されている事による弊害から起きていました。)また、ここでいうメタデータやデータガバナンスは意味定義の管理やアクセスガバナンス(権限管理)ではなく、「データサイエンティストがデータを活用(分析モデルを作成し、モデルをデプロイし、モデルが導出する示唆を活用する)するために必ず確認が必要な全ての情報(簡単なダッシュボード作成も、既存システムの付加価値増強も、AIによる発展的なモデル活用も、基本的には全て同じ活用フローをたどります。)」であることを再認識する必要があります。これは、使おうとしているデータが元々はどういったアプリケーションから生成されているデータで、その後誰が整備したデータで、既にどういった活用数・事例があるか、誰に聞けば詳しい情報が手に入るか、といった人間系の情報がメインディッシュであり、これをデータリネージやデータ品質情報と組み合わせて確認することで、データを信頼し活用に進むことを可能にします。少し前から話題になっているデータファブリックもデータメッシュも、揃ってメタデータやデータガバナンスが重要だと指摘しますが、誰もそれを既存組織でどう実行していくか具体的なプラクティスを話していません。実際のところ、つまり、それはデータインテリジェンスであり、データインテリジェンスは人間系が絡むものであり、人間系は大企業であれば組織の複雑性に影響を受けるので、組織的なアプローチを取れるリーダーと経営陣が、自社が置かれているフェーズを意識して、変革していく必要があるということに他ならないのです。

参考リンク

Data Mesh: Delivering Data-Driven Value at Scale by Zhamak Dehghani
https://www.amazon.co.jp/Data-Mesh-Delivering-Data-driven-Value/dp/1492092398

Data Management at Scale: Modern Data Architecture with Data Mesh and Data Fabric by Piethein Strengholt
https://www.amazon.co.jp/Data-Management-Scale-Modern-Architecture/dp/1098138864/

DAMA-DMBOK: Data Management Body of Knowledge by DAMA Internationalhttps://www.amazon.co.jp/DAMA-DMBOK-Data-Management-Body-Knowledge/dp/1634622340

And all the knowledge Quollio Technologies has developed.


この記事が気に入ったらサポートをしてみませんか?