第6章 実践的データスチュワードシップ
データスチュワードシップを読み始めたので覚書として残しています。
第6章と次の第7章が本書で最もボリュームのありメインと考える。
はじめに
データスチュワードシップが適切に実施されなければ、スチュワードたちに過度の負担がかかり、彼らの不満や「反発」を招く恐れがある。重要なのは、データスチュワードシップの実践的かつ基本的な側面に焦点を当てることである。
第5章まではデータスチュワードシップの全体像や取り組むための準備であり、第6章からが本丸となる。
全体間・総論は理解・合意を得られても「具体的には？」という各論に入ると話が合わないことが多い。そのため実践ということなのでここは非常に重要となる。
基本事項
データスチュワードシップの出発点はほとんどの場合、時間をかける価値のあるキービジネスデータエレメント(BDE)を選択し、作成、使用、品質に関するビジネスルールとともに、厳密な定義と導出方法を定めることである。もちろん、これらすべてを実現するには次の二通りのうちどちらかを実行する必要がある。
2通りとは「ビジネス機能主導」か「データドメイン主導」かの2通りのことである。
出発点として2通りを上げらえれているが、出発ということであればデータドメインなどが明確になっていないと思うので事実上ビジネス機能主導になると思われる。
若い組織であらかじめ設計されているのであれば話は違うかもしれないが…
キービジネスデータエレメントの選択
まず、データスチュワードシップ評議会は、BDEの所有者を決定しなければならない。次に、BDEを定義し、それらの作成と使用上のビジネスルールを確認し、データ品質ルールを文書化する必要がある。
(中略)
ほとんどの企業では何千ものBDE、そしてそれ以上の物理データエレメントがあるため、最初にすべきは焦点を当てる最も重要な(キーとなる)ビジネスエレメント(KBE)を定めることである。
この考え方はわかるが、KBEを決めるのが難しい。
これに対して考慮すべきいくつかのBDEが記載されている。
財務報告用データ:
金融界に報告され、投資判断の材料となるデータにはガバナンスが必要。一般に財務のエキスパートはこの要件を理解していて、通常は導出ルールを含むBDEを定義している。リスクと規制報告用データエレメント:
多くのデータガバナンスの取り組みが、リスクと規制報告用データから始まることが多い。これらの報告書が重要であるだけでなく、データを適切にガバナンスする価値を示すことが極めて容易なためである。企業幹部が紹介するビジネスデータエレメント:
企業幹部のプレゼンテーションの中で、重要な役割を果たす用語(BDE)には高い優先度が必要。一方で、その用語が何を意味し、どのように測定されるか不明確なことが多い。注目度の高いプロジェクトで使用されるデータ:
注目を集めるプロジェクトで使用されるデータは、ガバナンスの対象として高い優先順位を持つべき。また、プロジェクトは範囲が限定されているため、マネジメントされたやり方に従うことでデータをガバナンス下に置く機会が得られる。ビジネスデータスチュワードに決定をゆだねる:
注意を払う価値のある重要なエレメントはなにかをデータスチュワードに決めさせる。データの専門家であるビジネスデータスチュワードは、自分たちのビジネス機能に有益な、どのビジネスデータエレメントを扱うべきかを知る良い立場にある。
責任あるビジネスデータスチュワードの任命
多くの場合、どのビジネス機能またはデータドメインがそのBDEを所有すべきかは明確である。多くのデータエレメントは単一のビジネス機能によって、かつ単一のビジネス機能のために収集される。
(中略)
しかし、そのデータが利害関係者とみなされる他のビジネス機能で使用されないということではない。
データはひとつのビジネス機能に閉じないで、他のビジネス機能でも使われることは簡単にイメージできる。だからこそ、「このデータはだれが主管か？」というような問題がよく見られる。
これに対して以下の2つの重要な質問があるとのこと。
BDEの定義や導出方法が変更された場合、誰のビジネスが根本的に変わるのか。
データはビジネスプロセスのどこで発生するのか。
要するにインフォメーションチェーンの根本と利害関係者の役割（RACI）を特定しようということと理解。
実際に実践しようとすると利害関係者がそれぞれの視点から話すのでなかなまとまらないので、インフォメーションチェーンとRACIを見える化して対応したことがあるので効果は認める。しかし、特定するのに時間はそれなりにかかった…
ビジネスデータエレメントの命名
BDEの命名はビジネスデータスチュワードにとって重要なタスクである。
(中略)
BDEの命名基準の基本セットには以下のものが含まれている必要がある。
命名基準の基本セットは以下
名詞で始め、名詞の前に有効な修飾語を持つ形容詞を付ける。
名前に一貫性を持たせるために、1つ以上の修飾語を付ける。
「クラスワード」で終わる用語を使用する。
略語は使用しないようにする。
業界でよく知られていない用語や専門用語は避ける。
同じ用語を部門や通信用にわたって使い分けることは避ける。
英語を対象に書いているので、略語などは概念が少し異なるかもしれない。しかし日本語や組織で独特の省略が存在することがあるむしろ注意が必要。
なお、クラスワードについては付録Cに記載があるが多いため省略。
良いビジネス定義の作成
ビジネスデータスチュワードの主要な責任は、BDEとは何か、なぜそれがビジネスにとって重要であるかを明確に定めるビジネス定義を提供することである。
ビジネスデータスチュワードの責任としているが、企業全体など組織横断的なデータマネジメント（の文化）を導入するためにまさに検討中である。
良いビジネス定義の特徴についても言及が以下の通り記載してある。
ビジネス上の言葉を使った用語の定義
その用語がビジネスに対して果たす目的が明確であること
その用語を類似の用語と区別できる程度に具体的であること
定義で使用している既定義の用語にリンクできること
必要な場合は作成上のビジネスルールを明記するか、それらのルールにリンクする
最後の1つ以外は意味を理解できるが、最後のはビジネス定義の特徴というか、プロセスな気がする。
よく読んでみると"ビジネス定義を完全で有用なものとするため含むべきもの"としているのでビジネス定義そのもの以外が書いてあると理解。
この辺りを反復可能なプロセスとして確立していく必要があるのだろう。
ビジネスデータエレメントに対する作成と使用上のビジネスルールの定義
データが適切な時にのみ作成され、設計された目的のためにのみ使用されることを保証する鍵は、データの作成と使用に関するビジネスルールを定義することである。
私の経験から現場カイゼンが進んでいるとデータが設計された目的外に使われているケースが多い。自分たちの範囲だけで無理やり進めてしまうケースがあるからだ。それが他との連携や全体最適を目指そうとした際に曲者となる。
そのためデータ作成や使用のビジネスルールを定め守らせることがデータ品質に直結することはよく理解できる。
作成ルールに含まれるべきもの
ビジネスプロセスのどの時点でそのデータを作成または取得しなければならないか
どのような状況ではデータを作成してはならないか。
そのデータを作成する前に、他にどのようなデータが存在し、利用可能でなければならないか。
どのビジネス機能がそのデータを作成することが許されるか。
そのデータを本番環境で使用する前に、どのような承認プロセス(もしあれば)が必要か。
まさに上記の観点でルールを明確にするため、DFDやサブジェクトエリアモデルを作っているところである。
使用ルールに含まれるべきもの
そのデータを使用する前に適用して合格しなければならない妥当性テスト。
必ず存在しなければならない他のデータとの関係性。
どのようなビジネスプロセスがそのデータを使用しなければならないか。
各プロセスがそのデータを使用する方法。
従来業務であれば妥当性テストまではやりすぎな気がするが、分析などの2次活用まで想定するならデータ品質確保のためにあるほうが良いと思う。
導出ルールの定義
導出ルールを定義し文書化することが非常に重要ということ。つまり
文書化して関係者間で共有することにより、ルールの一貫性と正確性を確保
これにより、異なる解釈や計算結果による矛盾を防ぎ、ビジネス上の意思決定や顧客対応の質を向上させる
当たり前だけど意外とできていないことが多いと思われる。
反復可能なプロセスの設定
一連の反復可能なデータスチュワードシップのプロセスを持つことは、データスチュワードシップの導入を成功させる鍵であり、最終的にはデータスチュワードシップの目標であるデータマネジメントの改善につながる。
確かに人によって認識が異なっており「俺のデータマネジメント」がいたるところに存在しているのを目にする。そのため反復可能なプロセスまで落とし込み、定義するというのは非常に重要と思う。
必要不可欠なプロセスの例として以下が記載されている。
新しいビジネスデータエレメントをガバナンス下に置く
ビジネス用語集をマネジメントする
データ品質問題を評価し、解決策を見出す
データガバナンスの要求や問題を解決する
ポリシー、手順、指標をマネジメントする
複数のプロジェクトデータスチュワードの作業を調整する
イシューログをマネジメントする
このようなことが当たり前のように実施されている組織を見たこともある。組織としての力が強くさすがと思わされた。
一方で全く実践していない組織も見たことがあるが、このような組織にこれらを導入していくのはなかなか骨が折れる。今振り返れば、データスチュワードシップの取り組みがまだ始まっていない組織にアプローチしている空振り状態だったかもしれない。
データスチュワードシップ導入範囲の定義
データガバナンスの導入当初によくある疑問に、全社を横断して一度に導入するのか、それとも特定の事業部門に絞って導入するのか、ということがある。この意思決定を下すにはいくつかの考慮事項がある。
ベースラインを作るのか、トップアップ・ボトムアップを進めるのかという話は何度か相談されたことがある。私自身は絶対的な答えはなく、組織の文化や状況により判断が必要と考えている。
本書ではそれらを判断するための考慮事項が記載されている。
ベースラインを作ったほうが良い
小規模企業の場合
ビジネスユニット間でデータ問題が共通している場合
大規模なデータプロジェクトが進行中の場合
上層部の全社展開命令がある場合
個別で導入したほうが良い
単一または少数のビジネスユニットでのプロジェクト
大規模なデータ問題を抱える重要なビジネスユニット
独立性の高いビジネスユニット
どのような場合にベースラインを作るべきか、トップアップ・ボトムアップで個別推進すべきか明文化したことがなかったのが、感覚的には非常に近い。
ビジネスデータスチュワードとデータガバナンスプログラム・オフィスの連携方法について
データガバナンスプログラムオフィスのスタッフはビジネスデータスチュワードと継続的に緊密に協力する必要がある。
(中略)
開催される各会議が目的を持ち、データスチュワードシップの取り組みに付加価値をもたらすことが明らかであれば、スチュワードが進んで参加する可能性ははるかに高くなる。
連携が重要なのも、会議に目的を持たせる必要性も理解するが、どのような内容だとスチュワードたちの関心に刺さるのかについては疑問を持っていた。
開催形式やそのコンテンツについて書いてあり非常に勉強になる。
データスチュワードとの定例会議
データスチュワードシップの進捗や問題に関する確認
データスチュワードシップツールのトレーニングと更新
プロセスや手順の新規導入と改善
大規模な全社的取り組みの計画
対話型フォーラムの活用
フォーラムでの対応内容
メタデータの定義と導出方法に関する入力
作成と使用のルールのレビュー
データ品質ルールのレビュー
データプロファイリング結果の評価
問題に関する一般的なフィードバックの要請
フォーラムの運用手順
データガバナンス担当者やステークホルダーがフォーラムで課題を投稿し、意見を求める。
データスチュワード会議のメンバーが通知を受け、都合の良いタイミングでフィードバックを提供。
必要に応じて課題がデータガバナンスボードへエスカレーションされる。
解決策が確定次第、フォーラム上に結果を共有。
フォーラム活用のメリット
会議不要で担当者が都合の良いタイミングで対応可能。
全ての議論内容が記録され、透明性が向上。
メールのやり取りを最小限にしつつ効率化を実現。
ワーキンググループの活用
ビジネスデータエレメントの定義または導出方法に対する変更案。
データ品質ルールの改訂を含む、認識されたデータ品質問題の検出と修正。
データの使用と作成上のビジネスルールの変更。
プロジェクトデータスチュワードとビジネスデータスチュワードの連携方法
ビジネスデータスチュワードへの負担軽減
ビジネスデータスチュワードとプロジェクトデータスチュワードの連携をスケジュールに反映。
協力関係を明確にし、過度な負担を避ける。
情報収集と提供
プロジェクトデータスチュワードはビジネスアナリストや専門家から定義・導出方法・データ品質ルールを収集し提供。
質問や懸念事項を事前に整理してビジネスデータスチュワードに伝える。
データプロファイリングの実施
質問の前にデータプロファイリングを行い、結果を確認後、必要に応じてビジネスデータスチュワードと共有。
プロジェクトに問題がない場合でも結果共有は推奨。
BDEリストの管理
プロジェクトデータスチュワードはBDEリストの重複を排除し、同じ項目で複数の依頼が発生しないよう管理。
ビジネスデータスチュワードの割当
特定されていない場合、エンタープライズデータスチュワードに問い合わせ、候補を割り当てるプロセスを実行。
日々の仕事をこなすためのイシューログ活用
いろいろ書いてあるけど、データに関する課題管理表をちゃんと運用しようということ。運用する際に各プロセスにしかるべき責任者を当てる必要がある。
文書化と伝達: コミュニケーション計画
データスチュワードシップ活動に直接参加する人だけでなく、その活動の影響を受ける人、つまりデータのすべてのユーザーと、データに依存するプロセスに依存するすべての人とコミュニケーションが必要。
要するにほぼ全員。
分かってはいるけど、文字に起こすと恐ろしい。
何を伝えなければならないか
コミュニケーションでは達成された目標はもちろん、決定事項、一般的な情報と進展状況、データガバナンスとデータスチュワードシップの取り組みについて漏れなく気づいたことを、利害関係者に伝えるべきだ。こうした気づいたことには成功事例、必須トレーニング、指標、データガバナンス組織の「ブランディング」などが含まれる。
データガバナンス組織のブランディングがここに記載されるとは思わなかったが確かに重要である。ブランディングという言い方はしていないが、プレゼンスを上げる必要があるというのは常に思っているポイントである。
このポイントが意外と成功に導く大きなポイントになると考えている。
コミュニケーション計画に何を含めるべきか
「ビジネスデータスチュワードとデータガバナンスプログラム・オフィスの連携方法について」と合わせてみるのが良いと感じた。
コミュニケーション計画として、目的・アウトプット・対象者・手段・頻度・発表者を少なくとも決める必要がある。
これ自体は当たり前なので何の違和感もない。
ここでは上記についてサンプルが記載されているため非常に参考になる。
ターゲットを絞ったコミュニケーションの重要性
データのソースと用途について関係者に通知するために、「ターゲットを絞ったコミュニケーション」が必要なある場合があるとのこと。具体的には、データの変更、データソースシステムの変更、メタデータの変更を含ような場合。
プロジェクト方法論へのデータガバナンスの追加
プロジェクトマネジメントの方法論はそれぞれ異なるが、表 6.4はこれらのタスクと、単純なソフトウェア開発ライフサイクル(SDLC)とどのように関連しているかについて、良いヒントを与えてくれる。これらのタスクはプロジェクト方法論との統合に最適な出発点である
ソフトウェア開発ライフサイクルとデータライフサイクルが異なることはDMOBK1に記載されており常々訴えているが、ソフトウェア開発ライフサイクルのタスクでも違いがあることが示された。
各フェーズでデータ品質やメタデータに関するタスクなどが入っており、データ活用などでデータサイエンティストが絡む場合には意識されると思われる。一方でIT部門の開発として進めている場合には意識がいかない可能性があるため注意が必要。
データガバナンスやデータスチュワードシップのロードマップ構築と遵守
データガバナンスの「ロードマップ」はその取り組みのタスク、マイルストーン、依存関係を示したものである。導入の様々な部分をカバーする、いくつかの異なるロードマップが存在する場合がある。
組織には複数のデータビジネスエレメントが存在しているため、ロードマップを作るのに様々な領域の考慮が必要となる。本書の注記にも記載されているが、コミュニケーション計画だけで別枠のレーンを作る必要がある。
全体俯瞰できるものを作ったとしても、各ドメインからは抽象的過ぎてわからないという声が届くことがある。そのため全体俯瞰版だけでなく、詳細版が必要となると考える。
本書においては3つの粒度でサンプルが記載されており、組織のロードマップ検討に非常に役に立つ。
データスチュワードシップツールの指定
データスチュワードシップの取り組みを文書に記録し、その成果を伝えるのに役立つ重要な4つのツールがある。それらはデータスチュワードシップポータル、データスチュワードシップWiki、ビジネス用語集、メタデータリポジトリ(MDR)である。
４つのツールについては名前からイメージするものとほとんど変わらない。
掲載すべき内容などは参考になるが、ここまで読み進めてきているのであれば当然と思える内容ばかりである。
すべてのツールについてをデータガバナンスマネージャーなどが担当することになるといくらリソースがあっても足りなくなる。
本書ではワークフローによるプロセスの自動化があげられており、参考になる。
所感
冒頭にも書いたが、第６章はもっともページが割かれており本書のメインと思われる。ページ数だけでなく内容も充実しており、タイトル通り非常に実践的なものだった。
これから活動を開始するなどの場合には本章に記載されている内容をもとに組み立てると非常に参考になるはずである。
その一方で、前章までの準備が整っていない状態だとなかな手のつけにくい内容でもあると感じるものでもあった。しっかりと準備を整えてから実践に入ることを勧める。