第4章 データスチュワードシップの導入
データスチュワードシップを読み始めたので覚書として残しています。
はじめに
現状調査はデータスチュワードシップや建設に限らず基本中の基本。ただ、データスチュワードシップという概念がしっかり浸透していない状況にお手は何の調査をするか?
これも想像はできる。たぶん以下のようなイメージ
何らかをトリガにビジネス部門から始まり、複数部門が取り組む
--> 効果の最大化を目指したりサイロ化を嫌いガバナンスを取り始める
--> 文化が染みつくとドメイン主導に戻る
データスチュワードシップの提唱と伝達
何かを始めるためにそれが「何」であるかを理解しておくのは当たり前すぎて、意識したことがなかった。データスチュワードシップの場合は次のことが可能になるのでデータスチュワードが誰であるかを知るべきと記載されている。
適切な担当者に案件やデータ問題を提起できる。
データ問題に対する解決策や既知の回避策を提示する。
データディクショナリ、有効値リスト、クエリ、データ品質仕様、その他有用な成果物を利用できるようにする。
データスチュワードシップの手順が守られていないとアナリストが判断した場合、データスチュワードシップの機能に連絡するよう助言する。
上記ができるようになるのは理解するが、これを理解してもらい導入展開するのは難しそう…
データスチュワードシップのメッセージ
役員説明などのために準備はしているので15分程度のものの準備はできているが、それ以外は場当たり的になってしまってる。自組織も少しずつ強化しているので、だれでも同じメッセージを出せるように準備が必要と理解。
そしてメッセージにはメタデータとデータ品質の改善という考えが必要であり、言い換えればデータスチュワードシップの中心となる3要素は以下となる。
メタデータ: データに関する文書化されたわかりやすい知識
データ品質: データからより多くの価値を引き出すことを目的とした、データに関する知識の教育
データガバナンス: データについて意思決定するためのフレームワーク
データスチュワードシップのメッセージの準備
上記に記載した通り、異なるざまざまなグループに対してプレゼンが必要となる。この準備のためのスッテプが以下
伝えるべき重要なメッセージを明確にする。
対象者を明確にする。
プレゼンテーションに必要な時間を明確にする。
対象者に合わせてメッセージをカスタマイズする。
わざわざ書いてあるけど、プレゼン準備の基本が書いてあるだけだった。
上からも下からも支持を得る
データマネジメントは変革を伴うことが多く、スポンサーシップを重要視する記述がかなりみられる。今回、上からの支持が必要となる理由としては以下が記載してあり、他で見る記載と大差ない。
企業全体への浸透
抵抗勢力への対処
資源の確保
文化の変革
一方、下からの支持が必要となる理由として以下が記載してある。こちらもよく見る記載内容であり、特筆することはなさそう。
現場の声を反映
スムーズな導入
問題の早期発見
変化への対応
組織について
組織体制
図4.2のような体制だったら非常にわかりやすい。しかし、規模が大きかったりマトリックス組織を採用していると、シンプルじゃないことが多い。
それに対しても以下のような記載がある。
ビジネスユニットとビジネス機能の違いも書いてあるが、これは名前の通り。ビジネス機能は業務遂行上のファンクション。このファンクションを束ねたりして組織にしたのがユニット。ファンクションは予算を持っていないが、ユニットは予算を持ってるはず。
そして、予算を握ってる体制ではなく、実際のファンクションに注目すべきということ。これは複雑な組織体制を持っているのを読み解くのに役立つ情報だと思った。
組織の文化
骨身に染みてわかる。これは7Sでいうところのソフトに、6バブルの振る舞いに本質があるからだと思っている。
本書では変化を起こそうとする前に現状の把握が必要であり、経営陣のサポートをもらいながらメッセージの発信が必要であると言っている。また、組織内からの反発も繰り返されるので何度も実施が必要とも述べられている。
データスチュワードの編成
第1章にあった「データスチュワードシップをデータガバナンスにどう連携させるか」の言い換えてるだけが気がする(表現は違うが図1.3や図1.5)
出発点の把握
今のご時世、全くデータを使っていないというところのほうが珍しい。そういう意味では誰かが何かしら整理しているという考えはわかる。どのような内容をつかんでおくのが良いかの詳細は以下。
今あるものを把握する: データ
どんなデータを持っているか。
そのデータはどこから来るのか。
組織のどこがソースデータの取得、ETL、レポートを担当するのか。
今あるものを把握する: メタデータ
定義を見つける。
導出方法を見つける。
メタデータはどこに保管されているのか。
メタデータをマネジメントし検証している人はいるか、またどのような手段を使っているか。
IT部門はどのようにメタデータを追跡しているか。
レガシーシステム用の利用可能なデータディクショナリはあるか。
現在のプロジェクト方法論はメタデータの取得と検証をサポートしているか。
経験上、これはかなり難しい場合がある。管理されてる組織はこの大部分が分かるようになるが、管理できていないところは何もできていな。一部出来てないとかではなく、何もない…
管理できてる/できてないが両極端になっており、管理できてないところはベテランが知ってるだけという状況だったりする。そうなると把握するだけでもかなりの労力がかかってしまう。
今あるものを把握する: データ品質
データ品質ルールの収集担当がいるか、そしてそれはどこに文書化されているか。
どのようなデータ品質の問題が提起され、文書化されているか。
データ品質の問題を解決するために 「進行中の」 プロジェクトがあるか。
現在のプロジェクト開発方法論はデータ品質のルールと問題の把握をサポートしているか。
データプロファイリングをしている人はいるか。
今あるものを把握する: プロセス
確立されているプロセスのビジネス上の理由を見つけ、文書化し正式化する。
今あるものを把握する: ツール
メタデータリポジトリ
ビジネス用語集
データプロファイリングツール
コラボレーションツール
所感
タイトルは「データスチュワードシップの導入」となっているが、導入ステップというよりは導入準備という感じ。しかしその重要性は導入に苦戦している方にも参考となる内容があると感じた。
ここにあった観点で今どうなっているかを再整理すると課題のポイントがもう少し明確になるかもしれない。
この記事が気に入ったらサポートをしてみませんか?