データガバナンスを推進するための組織づくり

データガバナンスを推進するためには、どのような人をアサインし、どのような組織を構築すると良いでしょうか？まずは、中心的な役割を担うデータアーキテクトとデータスチュワードに求められるスキルについて整理してみましょう。

データアーキテクトに求められるスキル

ITの知識に加え、データアーキテクチャ設計やメタデータ管理などのデータマネジメントに関する専門的知識、データモデリングなどの専門的技術が求められます。特に、業務要件をデータ構造に落とし込むことや、全社のエンタープライズデータモデルの設計、開発時のデータモデルのレビュなど、データモデリング技術はあらゆる場面で必要になります。

また、これらの技術以外に、データマネジメントを各部門へ伝えて理解を得るためには、その必要性を論理的に説明できる力や、部門間の利害対立を解消するためにも粘り強い交渉力が必要になります。データマネジメントは、データを利用したい他の部門のために施策を実施するような場面もあるため、その理解を得ることが重要になります。

データスチュワードに求められるスキル

自部門内のデータに対する説明責任やデータ要件を具体化することが求められるため、現状業務知識は必須になります。データマネジメントに関しては、基本的な概念と必要性が理解できていればよいです。しかし、データアーキテクトと同様に、このデータマネジメントの必要性を各部門へ伝えて理解を得るとともに、決められたガバナンス規約に従って業務現場やIT開発のプロジェクトをガバナンスしていく必要があります。よって、論理的に説明できる力や交渉力などのヒューマンスキルも求めれます。

どのような人をアサインすればよいか？

データアーキテクトは、IT部門からアサインされることが多いです。ガバナンス規約の策定や運用は、これまで携わることのなかった業務であるため最初は専門家の手を借りることになるかもしれません。一方で、データアーキテクチャの設計、エンタープライズデータモデルの策定、データモデリングのレビュなどは、従来のシステム開発の延長線でできると思われます。

難しいのは、データスチュワードです。理想的には、担当業務に詳しいことはもとより、日頃から業務を通じて現行のデータに課題を感じおり、それらをどうにかしたいという思いがある方を業務部門から任命するのが相応しいと考えます。例えば、部門を横断してSCMの計画調整を行っている方や、経営企画として各事業部門の業績を横並び比較しているような方は適任です。おそらく、データが標準化されていないことやコードが統一されていないことに対する問題も肌で感じていることでしょう。このような方々に明確な役割が与えられることで、全社視点でガバナンスをしつつ、自部門の利害が絡む難しい局面でも適切な落としどころを検討するのではないでしょうか。

データアーキテクトは、データ標準化やコード統一のやり方などは提示できても、業務や各部門の事情まで理解しながら考えることは難しいです。データスチュワードとタッグを組んでガバナンスを推進していく必要があります。

組織の構築はどうすればよいか？

よく論点になるのは、データアーキテクトやスチュワードを専任し専門組織を作るかどうかです。10年ぐらい前までは、DWHやMDMシステムの開発や運用保守の一環として、プロジェクトの中にDA（この場合はデータアドミニストレータ）チームのような形でデータマネジメントの機能を持たせるやり方が一般的でした。しかし、DX推進に伴い、データは全社規模で利活用されることが多くなり、永続的にデータの整合性や品質を担保できるように組織化を考えていく必要が出てきました。

データガバナンスには、全社単位でデータマネジメントの戦略を立案し、ガバナンス規約を策定し推進する機能と、業務領域単位でプロジェクトに対してガバナンスを実行する機能が必要になります。

まず前段の機能ですが、こちらは「データガバナンスオフィス」や「データマネジメントセンター」などのような形で全社組織として物理組織化されることが多くなってきました。組織目標と作業タスクが定義され、実施内容がモニタリングされ評価されることにより、責任が重くなるもののそれなりの権限を持って、しっかりと他の部門と連携しながら組織的に活動を推進していくことができるようになります。そのため、IT部門と業務部門から人をアサインして組織化します。

では、業務領域単位でのガバナンス機能はどうでしょうか？こちらは、論理的な組織になると思われます。通常、システム開発を行う際、IT部門と業務部門がアサインされて一過性の組織としてプロジェクトが発足します。データの標準化やコード統一などであれば同じ考え方が適用されます。メタデータの登録やデータ品質管理、アクセス権管理などプロジェクトが終了してからも体制を維持し続ける必要がある場合は、問い合わせ窓口と作業実行者をアサインします。領域別のデータスチュワードは、各部門に所属した状態で、現業に加え、このような作業も職務として割り当てられます。

以上、かいつまんでのご説明になりますが、データガバナンスの組織を考える上で参考になりましたでしょうか？DXを推進するのであれば、データマネジメントだけではなく、データ利活用を各部門に働きかける役割を持つチームも含めて、全社の推進組織を考える場合もあります。そのあたりのお話は機会があれば、ブログでお伝えしたいと思います。