datatech-jp Advent Calendar 2021 3日目への投稿です。
今年は datatech-jp のコミュニティの方達と話をしたり、輪読会に参加させていただくことができました。datatech-jp 自体の説明は1日目の投稿からご覧いただけます。Slack チャネルもあり、気軽にいろんなことが相談できたり、輪読会を開いたりと徐々に活発になってきていますので、ぜひご覧ください：
私からは、技術的横断組織にいる私が ここ2年くらいの DMBOK を中心とした社内の活動で得た知見を共有できる範囲でお話します。
所属組織について
私はサイバーエージェント社の Media Data Tech Studio という横断組織にいます。秋葉原ラボという組織は聞いたことがある方もいるかもしれませんが、2021年秋から組織名が変更されています。以下公式HPから説明を引用します：
Media Data Tech Studioは大規模データ処理やデータ分析、機械学習などを専門とするエンジニアが在籍する研究開発組織です。サイバーエージェントのメディアサービスから得られるデータを活用することで、メディアサービスと会社の発展に寄与することを目的として2011年4月、秋葉原にオフィスを開設しました。 サービスから日々生成されるユーザーのアクセスログや行動ログなどを大規模に集積、処理する基盤を整備し、その基盤上のデータを機械学習や自然言語処理技術などを用いてサービスに活かせるシステムを構築、提供しています。 また、基盤上のデータを分析、マイニングすることによりサービスやユーザーの状況を把握し、サービス拡大および健全化を図る基礎を担っています。
特定のサービス（例えばアメーバブログ、ABEMA（AbemaTV）、タップル、WINTICKETなどサービスがあります）の発展を支援することももちろんですが、あくまでも「横断組織」としてデータ活用をどう支援できるかを日々模索している組織です。
注力する事業を合理的に判断したい
DMBOK 輪読による共通言語の獲得
様々なサービス事業を有する中、どの事業のどのプロジェクトにフォーカスすべきかの戦略を立てるため、データマネジメントの観点で事業状況を可視化できないかと検討をしました。そのためにまず ゆずたそさんの30分本を読んで概要を理解し、その後 DMBOK の書籍をチーム内で輪読を始めました。
もう少し正確に言うと CMMI 基準のデータマネジメント評価をしようとしたのですが英語文献しかなく、何ヶ月か輪読した後に断念しました。。その点 DMBOK は日本語訳が出ており、チームでディスカッションできるレベルまで持っていくことを考えると、訳書があるのは無視できないメリットだなと感じました。ちょっと高いですが、一人一冊購入してバイブルのようにしている企業もあるようですね。
datatech-jp Advent Calendar 2021 2日目の方も記事も読ませていただきましたが、とても共感しました。DMBOK は読んでいて楽しいです。DMBOK は教科書的なことばかり書いてあるかと思いきや、著者たちの思いが詰まった文章が散りばめられています：
データは資産だと考えて管理することがデータマネジメントですが、「資産」というからには「負債」にもなりうる点にも言及されているのは新たな気づきでした。使う前に必ずデータ欠損チェックを行わなければいけない状態だったり、ライフサイクルが定義されていないためデータ削除ができずに管理コストが膨らんでしまっている環境もあります。
脱線しましたが、こうやってチーム内で DMBOK を読み合わせしたことにより、その後の業務の下地にできたと思います。データセキュリティについてここまで検討できていなかったねとか、メタデータも検討してユーザが参照できる情報を増やさないと、といった議論が横断組織内で行われるようになりました。
事業状況の可視化
事業状況の可視化については以前の記事に書きましたが、DMBOK をベースに弊社横断事業部の状況を加味した独自の成熟度評価を作成しました：
私が横断組織ではなくサービス事業部の中にいたら、ここまでしなくてもよかったかなと思います。自分がサービス事業にいて DMBOK の知識があれば、どの辺が足らないかは課題ベースで取り組めそうですし、周りにディスカッションできるメンバーがいればブレストベースでも目標策定できそうです。サービスの詳しい状況がわからない中で注力事業を判断するという目的があったので独自の成熟度チェックリストを作成したのですが、サービス事業部の方へのデータマネジメントの啓蒙も行えたりするなどのメリットもありました。
横断組織としてデータマネジメントを遂行するメリット
データスチュワードを見つけて支援する
DMBOK にも書かれていますが、多くの組織では暗黙的にデータ周りの業務を担っている担当者がいるはずです。この方を組織の中で見つけ、データの問い合わせやクエリ作成で疲弊している場合はサポートしてあげることがとても大切だと考えています。そして俗人化を防ぐためにこの人の役割に「データスチュワード」と名前を付け、組織として重要なポジションであると伝えると、気づいたらデータ周りに詳しい人がいなくなってしまった、といった事故が防げます。
このデータスチュワードを組織として立て付けようとしている場合、ハードスキルだけでなくソフトスキルが非常に重要なポジションだなと感じています。というのもデータスチュワードはデータを整備して使いやすい状態に保っておくのですが、データ利用者とのコミュニケーションが重要になるためです。利用者がデータを使いやすい状態にするためにはどうしたらよいかが自然に考えられる方だと安心してデータスチュワードをお任せできると思います。
ここにDMBOKなどの外部知識を足して、さらに利用者がデータ活用しやすい状態にするのはどうしたらよいかを戦略として考えられると、データガバナンスとして成熟した状態かと思います。データスチュワードの方は、7つの習慣でいう第三領域（重要ではないが緊急性が高い）に忙殺されている場合が多いので、第二領域（重要だが緊急性は低い）の課題に取り組めるだけの時間やバイタリティが残されているかも組織的には重要です。
横断組織側のメンバーがデータスチュワードになるのは正直厳しいです。サービス内の様々な状況を把握しておかなければいけないため、基本的にはその組織内のメンバーからデータスチュワードの役割を探さなければいけません。ただ横断側としてこういった役割が重要であると伝えられると、企業全体のデータ活用レベルの底支えができると感じています。
駆け込み寺としての機能
データスチュワードを見つけ、その方が意欲的にメタデータの整備やデータモデルの整備を始めたとしても、組織規模によっては一人で孤軍奮闘することになりかねません。そのような場合に一緒に課題解決に取り組んだり、データモデル作成の方法を指南したりすることができます。
もちろん外部の専門家の力を借りるのも選択肢としてはアリですが、組織内に多くのサービス事業を抱える弊社の状況だと、横断組織としてこの役割を保有しておくのは合理的かなと考えています。
データ基盤としてパブリッククラウドを利用する場面もあり、私の組織だとオンプレミスの基盤を中心に運用しているため、まだまだ知見・経験が少ないのですが、パブリッククラウドでどのようにデータ基盤を運用したらよいかのノウハウを溜めておきたいです。ここは今後の課題ですね。この他、データモデリングの方法、データアーキテクチャ図の作成方法、ETL処理基盤のノウハウなど、横断組織として溜めておきたい領域はたくさんあります。今はオンプレミス基盤の運用中心なのですが、今後は外部ツールも積極的に検証して社内展開できると面白そうだなとも考えています。
共通化できるものがあればシステムで共通化する
行わなければいけない、ただ取り組むには時間がなかったり面倒な分野は横断組織として価値が出しやすい領域です。例えば以下の記事で答えていますが、Media Data Tech Studio（旧秋葉原ラボ）ではストリーミング処理システム Mine を開発・運用しています。ここではログのフォーマット管理、バリデーション、転送管理などを行っており、データ品質を保つことに貢献しています。他にも様々なアプリケーションを開発していますが、そうでなくても OSS やマネージドサービスの提供などでも運用が複雑なものであれば横断組織として取り組めるものもあるかなと思います。
今後取り組みたいこと
パブリッククラウドに強くなる
弊社ではオンプレミスのデータ基盤を中心に利用していますが、サービス事業部側でパブリッククラウドを利用する場面が増えるなど、いわゆるハイブリッドなデータ基盤を運用しています。オンプレミス側は横断組織、パブリッククラウドはサービス事業部という棲み分けが自然となされていますが、サービス規模も様々なので、相談があった時に困らないようにパブリッククラウドや外部ツールの学習も組織として取り組みたいなと思っています。
データモデリングに強くなる
データモデルは非常に強力です。可視化の力というか、データモデルを見せれば一発で解決するという場面を何度も経験したので、一度しっかりとしたデータモデルを作って定期的に更新すると、コミュニケーションの質が格段に良くなります。データ利用者からの問い合わせに対して「ここに可視化してあります」と一言でレスポンスできる場面も何度もありましたが、その度に作っておいてよかったなと感じました（本当は検索性を上げて、利用者自身が見つけておける状態にしないといけないですが）
データモデリングには鳥の目と虫の目を行き来する苦しさ、自分の理解が徐々に可視化されていく感覚、その先にデータの関係性を可視化の力で殴りかかる痛快感があります。DMBOK ではデータモデラーという役割があるぐらいですし、インフォグラフィクスのような多少アートのような領域でもあるので、もっと詳しくなりたい領域の一つです。まだ経験が少なく、作ったモデルを見せることはできるのですが「指南」できるレベルではないので、ある程度手順化したりして横断組織としての武器を手に入れられたらいいなと思っています。
さいごに
今年は datatech-jp のコミュニティに参加して、社外にこんなにも同じ悩みをもっている方達がいるんだ知れて心強く感じました。私は横断組織にいてサービスを直接見ていない点が少し他の方と違うかなと思い、今のポジションで考えていることをつらつらと書いてみましたが、もしツッコミや質問があれば Twitter でもよいので気軽にご連絡ください。
