第2章 データスチュワードシップのタイプについて
データスチュワードシップを読み始めたので覚書として残しています。
はじめに
「データスチュワードシップ」という総称は主に、ビジネスデータスチュワードとテクニカルデータスチュワードの2つの異なるタイプのスチュワードを包含している。しかし、場合によっては、また別のタイプのデータスチュワードであるプロジェクトデータスチュワードによって「補う」必要がある。
いきなり複数種類のデータスチュワードが登場して混乱する。
これまでデータスチュワードを分けて考えたことがほとんどなく、ここでいうビジネスデータスチュワードのことをデータスチュワードと思っていた。それぞれの概要は次の通り。
ビジネスデータスチュワード: ビジネス機能が所有するデータに対して責任を負う人
オペレーショナルデータスチュワード: 入力作業など、データを直接扱う人
プロジェクトデータスチュワード: プロジェクトにおけるデータスチュワードシップを代表する人
テクニカルデータスチュワード: アプリケーション、データストア、ETLプロセスがどのように機能するかについての知識を持つIT代表者
ビジネスデータスチュワード
ビジネスデータスチュワードとは特定のビジネス領域における鍵となる代表者であり、その組織におけるデータの品質、使用、意味について責任を負う。
（中略）
ビジネスデータスチュワードはその役割を果たす上で必要な情報を得るために、自分の領域で誰に相談すればよいかを知っておく必要がある。そして、ひとたびビジネスデータスチュワードがその情報を集めた後は、情報の提供者ではなく、そのスチュワードがデータを管理する責任を負う。
こんなことを実践している人はよく見かける。ただし、その方や組織の職務としてではなく、領域のキーマンとして自然とやっている人が多い印象。
すでに実施している人にビジネスデータスチュワードのタグを張るのが良いか、新たな席を用意してしっかりと評価できるようにするほうが良いか…
評価制度をすぐに変えられないから前者のにせざるえな気がする。
適切なビジネスデータスチュワードの選択
多くのビジネス領域には「疑問に答えてもらうにはあの人のところに行けばいい」とみんなが知っている人物がいる。（中略）多くの場合、ビジネスデータスチュワードシップはこの役割と責任を単に正式にしたものである。
前述した「領域のキーマンとして自然にやっている人」のことですね。
ここではタグを張るだけでなく、役割を正式にしたほうが良いと言っており、そのメリットは次の通り。
質問への回答は一度だけ
ビジネス用語集に反映されれば、ビジネスデータスチュワードは質問者に「まずは調べてもらう」ように促すことができる議論の減少
データガバナーの支援のもとに意思決定をする技量を持つため、議論の回数が減り、無駄な時間も少なくなるはず変更のための反復可能なプロセス
評議会の決定が利害関係者に不都合な場合、意思決定者を巻き込み、見直しプロセスを導入し、通常の会議を繰り返す方法よりも、関係者を効率的に調整し、混乱を減らすことができる追加の報酬と評価
役割を正式に定めることで、個人の業績目標を調整し、この専門知識と責任を正式に認めることができる
最後の追加の報酬と評価がすぐにできないので、「業務量が増えるだけ」と思われてなかなか引き受けてくれないのが本書との違いで悩みどころかなぁ
成功するビジネスデータスチュワードの特性
文章作成能力
改善への取り組み
優れた対人スキル
ビジネスパーソンなら当たり前のようなスキルだと思う。実際に私が採用面接するときにはこの辺りを見ることが多いが、これらが十分に備わっている人は少ない気がしている。
余談だが、日本語版には箇条書きとして4点の行頭文字があるが、正しくは3点のみ。上から3つ目の点は2つ目の「改善への取り組み」の内容である（英語版のほうは正しく3点で記されている）
ビジネスデータスチュワードとデータ
ビジネスデータスチュワードは自分が代表するビジネス機能にとって最も重要で、自分が最も詳しいデータを管理する。
（中略）
ビジネスデータスチュワードと彼らが管理するデータを結びつけるにはいくつかのアプローチがある。
3つのアプローチが紹介されているが、組織（企業）として単独のアプローチを採用すべきという意意味ではないと考える。
たぶんデータの特性や使用目的などに応じて異なるアプローチを採用し、データガバナンスを実現すべき。
だからこそ、このセクションのタイトルが「ビジネスデータスチュワードとデータ」というようにデータに焦点が当たっていると思った。
ビジネスデータスチュワードの重要な役割
スチュワードには他にも多くの種類があるが、ビジネスデータ スチュワードはそのデータが何を表すのか、 何を意味するのか、 どんなビジネスルールが関連している のかを知っているという点で、 データの権威である。
（中略）
ビジネスデータスチュワー ド、 テクニカルデータスチュワード、 利害関係者の関係は図2.1に示す通りである。
上記の図でもテクニカルデータスチュワードが複数回出ており、これがビジネス部門もIT部門も「データはIT」と考えてしまう減いかもしれないと思った。
ビジネス利害関係者も複数回出ているが、今の会社では相手が異なることがほとんど。一方でテクニカルデータスチュワードはIT部門が対応しており、広く見ているのがIT部門。そのためビジネス部門もIT部門も「データはIT」と言ってる気がした。
この利害関係の図をしっかりと伝えて理解、共感してもらうための活動を進める。
テクニカルデータスチュワード
テクニカルデータスチュワードはデータガバナンスを支援する重要な役割を持つIT担当者である。
（中略）
ビジネスデータスチュワードはテクニカルデータスチュワードがサポートするITアプリケーションや技術的なプロセスを通じて、テクニカルデータスチュワードと関わる。この関わりには2つの経路がある。
例なども書いてあるが、要約するとテクニカルデータスチュワードの役割は次の4つと理解した。
技術的な専門知識の提供
システムやプロセスの動作説明
データ品質問題の解決支援
システムへのビジネスデータ要素の実装場所の特定支援
プロジェクトデータスチュワード
プロジェクトデータスチュワードはビジネスデータスチュワードからのインプットを必要とする問題や質問に気付くよう訓練された人であり、その情報をビジネスデータスチュワードに提供する人である。
プロジェクトとビジネスデータスチュワードの間の橋渡し役として機能し、プロジェクトにおけるデータガバナンスの推進を支援すると理解。
つまり、ビジネスデータスチュワードをあらゆるプロジェクトに参加させると業務負荷が高くなるから代わりにその役割を実施するということだと思う。
ビジネスデータスチュワードの権限などを持ってしまうと全体性を損なう可能性が出てくるので明確に別の役割としたのだろう。
オペレーショナルデータスチュワード
オペレーショナルデータスチュワードはビジネスデータスチュワードの助手」である。
（中略）
多くの場合、オペレーショナルデータスチュワードは最前線で働き、データ品質の改善が特定のグループに利益をもたらす機会をいち早く察知できる人たちである。
名前を付けているが、業務のオペレーターとしてオペレーションだけでなく、データに関しても理解している人のことだと思う。現場で班長とかリーダーとか呼ばれてる人。
所感
第2章の冒頭に主に2つ（ビジネスデータスチュワードとテクニカルデータスチュワード）と記載のある通り、この2つが重要と感じた。どちらも潜在的には存在しているのだろうが、しっかりと評価できるようにすることが大切と考える。
今の所属の場合、IT側＝テクニカルデータスチュワードは評価されるようになっているが、ビジネス側＝ビジネスデータスチュワードは業務と認識されておらず、ボランティアになってしまっているのが課題。
残りの2つについてはあったほうがいいとは思うが、枝葉と感じる。まずはビジネスデータスチュワードとテクニカルデータスチュワードをしっかりと立てるところにリソースを割きたい。
