第3章 スチュワードシップの役割と責任
データスチュワードシップを読み始めたので覚書として残しています。
各役割と責任の詳細はそれぞれの記載を読むのが良いが、全体的な理解はデータスチュワードシップRACIマトリックスの策定にRACIマトリックス例が書いてあり理解に役立った。
はじめに
第2章で複数のスチュワードが出てきて、その責任について言及していたが、ここでは果たすべきタスクが説明されている模様。
実際に本書で記載されている体制を構築するかについては各組織の状況次第となるため、本書でも"注記"として"悪jまで推奨される体制"としている。
データスチュワードシップ評議会
データスチュワードシップ評議会とは
あまり詳細な記載はないが、以下のようなものと理解した。
データの専門家が集結
全体最適な視点での意思決定
一貫性と標準化の促進
コミュニケーションのハブ
問題解決の促進
データスチュワードシップ評議会のメンバー構成
ビジネス機能主導型データスチュワードシップの場合:
すべての適切なビジネス機能を代表する1人以上のビジネスデータスチュワードで構成される。データドメイン主導型データスチュワードシップの場合:
データを所有するすべてのビジネス機能が代表される必要があります。
※リードデータスチュワード or ビジネスデータスチュワード
まだデータガバナンスマネージャーの役割と責任が明確に理解できていないが、私の担当が多分この辺り。
図1.4ではFull Timeとなっているが、各所でリソースが足りずより現場に近いところでも汗をかいているので、しっかりと役割と責任を定義してリソース強化を進めたい。
データスチュワードシップ評議会の責任
本書への記載は12項目あったけど、たぶん次の7項目にまとまる。
データガバナンスの目標をサポートする共通のデータ定義とビジネスルールを確立する。
問題の解決を仲介または調停する。
データスチュワードシップ評議会とデータガバナンス委員会の決定事項を伝える。
データガバナンスプロセスに参加し、貢献する。
データスチュワードシップの原則と実践を、それぞれのビジネス機能に浸透させる。
データの使用に関するルールを伝える。
定義とデータ問題の管理において、他の利害関係者と協力する。
なお、目次では「データスチュワードシップ評議会の責任」は第3章の第3条に位置するが、実際の本文では第3章の第2条 第3項に位置する(英語版もこっちの配置なので目次が間違いだと思われる)
データガバナンスマネジャー
この記載を見ると、私はやはりデータガバナンスマネージャーのようだ。
しかし、実力不足か組織文化か「支援組織から適切な関与を得ること」が十分にできていない。特に人事。大組織の人事を適切に巻き込む方法を知りたい…
エンタープライズデータスチュワード
データガバナンスマネジャーに報告する。
データスチュワード評議会を通じて、データスチュワードのコミュニティをリードする。
ITとビジネス部門のプロジェクトリーダー/PMOとともに、データガバナー/ビジネスリーダー、データドメイン評議会マネジャーまたはその任命者とも情報交換して、データスチュワードシップを導入し維持する。
データガバナンスマネジャーと協力して、短期的および長期的なデータガバナンスのビジョンとフレームワークを策定する。
ビジョンを実現するためのプロジェクトを特定し、開始する。
すべてのデータガバナンス作業の取り組みが全体的なビジネス目標とデータガバナンスのビジョンに沿ったものであるようにする。
優先順位付けの基準を定義する。
ビジネスチームとITチームに指示を与える。
データスチュワードシップ組織の導入をリードする。
データガバナンスマネージャーのところで、「これが私」といったが、エンタープライズデータスチュワードも実践している。
これらが専任にできていないので、リソースが分散してしまい歩みが鈍い気がしてきた。
まだ、会社として取り組み始めたばかりで一応回っているが、今のうちからリソース強化の計画をしっかりと立てていきたい。
ビジネスデータスチュワード
ビジネスデータスチュワードの責任は合計で23項目
ビジネス連携: 11項目
データライフサイクルマネジメント: 8項目
データの品質とリスク: 4項目
それぞれの項目を集約すると以下と理解した
ビジネス連携
共同作業と協議
データガバナンスの実行
重要データの定義と管理
データガバナーとの協力
ビジネス要件の調整
データライフサイクルマネジメント
変更管理
データ関連の問題のトリアージ
データ使用状況の監視
データの品質とリスク(4項目なのでそのまま記載)
データ品質指標を監視し、改善の機会を定める
ビジネス部門と協力して、データ品質の許容レベルを定義する
データ品質指標を監視し、改善の機会を定める
企業全体で使用されるデータエレメントについて、有効値を定義する
プロジェクトデータスチュワード
プロジェクトデータスチュワードの責任は合計で13項目。
ビジネスデータスチュワードの半分強 --> 重要度も半分強か?(項目数がすべてではないが…)
メタデータに関する責任: 6項目
データ品質に関する責任: 4項目
データガバナンスプロジェクトの調整に関する責任: 3項目
各責任の項目は以下
メタデータ
プロジェクトで使用されているビジネスデータエレメントの名称と説明を整備する。
プロジェクトで使用されているビジネスデータエレメントの名称と説明を整備する。
ビジネスデータエレメントの名称と説明を適切なデータスチュワードと検討し、ビジネス上の定義を入手する。
プロジェクトが提案したビジネス上のデータ導出や計算の方法を収集し、文書化する。
プロジェクトが提案した導出や計算の方法を、適切なデータスチュワードとレビューする。
データスチュワードの決定をプロジェクトに通知し、プロジェクト計画に反映させる。
データ品質
データ品質ルールとデータ品質の問題点をプロジェクトから収集し、文書化する。
データ品質の問題がプロジェクトのデータ使用方法に与える影響を評価し、必要に応じてデータガバナーまたはビジネスデータスチュワードと協議する。
適切なデータスチュワードとプロジェクトマネジャーに相談し、プロジェクトで収集したデータ品質ルールと求められる期待に基づいて、データをプロファイリングすべきかどうかを決定する。
データ品質に関連するデータプロファイリング作業を行うことで、データプロファイリングの取り組みを支援する。
DGプロジェクトの調整
ビジネスデータスチュワード(リードデータスチュワードを含む)、データガバナー、エンタープライズデータスチュワードに、プロジェクトから生じる定義やデータ品質ルール、問題点を伝え、相談する。
プロジェクト全体を通じて、プロジェクトマネジャーやプロジェクトメンバーと協力しながら、データガバナンスに関連する問題を各プロジェクトで解決することを保証する。
可能であれば、プロジェクトデータスチュワードのこれまでの経験や専門知識を活かせるプロジェクトと連携する。
テクニカルデータスチュワード
責任についてのリード文がないが、表2.2から概要は次の通り。
責任として記載されているのは4項目
1つ目の項目は表2.2の記載と一緒であり、これがテクニカルデータスチュワードを端的に示していると思われる。
ソースシステム、抽出変換ロード(ETL)プロセス、データストア、データウェアハウス、ビジネスインテリジェンスツールに関する技術的専門知識を提供する
システムやプロセスがどのように機能するか(または機能しないか)を説明する。
プログラムコード、コピー句、内部データベース構造、その他のプログラミング構造をチェックし、情報がどのように構造化されているか、データがどのように移動しているか、データがシステム内またはシステム間でどのように変換されているかを調査する。
ビジネスデータエレメントがシステム内のどこに物理実装されているかを特定する作業を支援する。
オペレーショナルデータスチュワード
こちらも責任についてのリード文がなく、表2.2でも全体概要はよくわからない。私の理解としては次の通り(役割の裏返しを書いただけ)
そして記載されている責任は4項目
新しい値を作成したり、既存の値を変更したりする際に、データの作成と更新におけるポリシーと手順が確実に守られようにする。
ビジネスデータスチュワードによるデータの指標の特定と収集を支援する。
データ、業務処理プロセス、手順の変更について、是正プロジェクトチームを支援する。
ビジネスデータスチュワードによる問題や変更要求を調査するためのデータ分析を支援する。
データ品質改善のための機会を見極めて伝える。
データスチュワードシップRACIマトリックスの策定
これまでの説明からRACIマトリックスの例が記載されており、もしかしたらこれが理解に一番役立つかもしれない。
所感
様々な役割や責任をいくつものデータスチュワードで分担していることが理解できた。また、その中核となるのがビジネスデータスチュワードであり、次いでテクニカルデータスチュワードが重要そう。
ビジネスデータスチュワードを選任するとあるが、実際には簡単に立ち上がらないのが私の経験。いくつかのビジネスドメインでプロジェクトを並走しながら立ち上げている状況である。
この辺りについてのヒントもどこかに書いてないか探していきた。