日々のあれこれφ(..)

もっぱら壁打ち

「データマネジメントが30分でわかる本」を読んだ

www.amazon.co.jp

実際には30分では分かりませんが、だいたい4時間くらいでデータマネジメントをするにあたって出てくる問題や要素などの全体像を見渡せるライトな本でした。

手に取った理由

仕事でデータを扱う部分に携わる機会が多くなり、その中でデータの扱い方に関してこれでいいのかといった言語化できない不安を抱いていました。 この本を見つけたのは偶々だったのですが「データマネジメント」「場当たり対応止めませんか」の文言が刺さりました😅

この本は有志のメンバーが自費出版したものなのですが、以下のような点が良かったので購入を決めました。

  • メインの執筆者がフルスタックエンジニアで、私のようなシステムを管理するレイヤーからデータを利用する側のレイヤーまで網羅的にカバーされている
  • データマネジメントの専門書の内容を元に構成されている
  • ことに加えて、実際に現場でどう実施したかという具体的な事例が合わせて載っている
    • この本をインデックスに、より深く知りたいところをDMBOK本を読んでいけばいいんじゃないかと思ったり

読書メモ

1章:データアーキテクチャ

  • データアーキテクチャとは、データとビジネスのつながりを可視化したもの

    • あるデータがどの業務に貢献しているのか
    • あるビジネスがどんなデータに依存しているのか
  • アーキテクチャ作成時に抑えること

    • どこからデータが取られているか
    • どこに保存しているか
    • どのビジネスで使われているのか
  • データアーキテクチャを作成することで現状を把握し、それを元に理想を描き、理想図から得られるビジネス価値を確認した上で改善策を練っていくことが必要

筆者が経験した具体的事例としてパワポの資料が載せられていた。「部署」「利用用途」「データの種類と利用用途ごとにCRUD必要な操作をまとめたもの」など自分が想像していたよりもざっくりしたものだった。

2章:データストレージとオペレーション

  • DBの選定、管理、運用を行い信頼できるデータを提供することが目的
  • 候補となるDBの特徴が業務要求に合致しているか
  • 業務ニーズを理解してデータの保存、活用、移動などの要件を満たせるようにアプリケーションの開発を行う
  • データの重要性とのバランスを取る
    • 例えば筆者の例の場合、スタートアップ時にはSoEの思想でBigQueryとGASで簡易的なシステムを開発し、スケール時にはSoR思想のWebAPI + RDS構成に移行した
    • SoE:System of Engagement。体験重視。
    • SoR:System of Record。記録重視

3章:データ統合と相互運用性

  • ELTを効率的に管理できるようにする
    • ELT:Extact(抽出)、Transform(変換)、Load(取り込み)
  • 利用者とシステムを仲介するハブになり、アクセス権限を適切にしたり、過剰リクエストやご集計を防ぐなどで双方の負担を軽減する
    • 利用者:シンプルで便利なデータを見たい
    • システム:事業成長によって量と種類が増える。複数のデータソースが分散している状態にある
  • 必要なフォーマットとタイミングで安全に提供できるようにする
  • 共通のモデルとインターフェースを開発し、統合にかかるコストと複雑さを削減する
  • 重要なイベントを検知できるようにアラートとアクションを定義する
  • 業務要件を明確にし、求められる更新頻度によってバッチ、ストリーミング、APIスクレイピングなどどれがいいのか判断する。

4章:データモデリングとデザイン

  • データ同士の関係性を図に示すこと

  • データモデルは以下3つの粒度に分けられる

    • 概念モデル:e.g. 学校は学生を在籍させるので、学校一覧と学生一覧のデータが紐付く
    • 論理モデル:e.g. 学校一覧には学校コードと学校名が含まれる。学生一覧には学生番号と在籍している学校コード、学生氏名が含まれる。学校一覧と学生一覧は学校コードを介して紐付く
    • 物理モデル:e.g. 論理モデルをDB上のテーブルとして表現したER図のようなもの
  • 概念モデルを作るとしたら、データアーキテクチャから紐解くのが一番得策

  • メタデータとして保存し、いつ誰がどのように更新するか決める必要もある
  • 作る時の注意点としては、問い合わせや法令遵守など、見えにくい部分を抜かさないようにすること

  • 具体例として、データモデル設計をモデルストーミング手法を用いて行なった話が挙げられていた

    • モデルストーミング手法:ホワイトボードや紙に書き出しながらブレインストーミングの要領で集計用のデータモデルを設計する。Agile Datawarehouse Design本で紹介されているやり方
    • コツ:データの網羅性にこだわらない。最初に全てのテーブルを設計するのはウォーターフォール開発の発想であって、モデルストーミング手法では必要なものから正しく小さく作るべきとされている
  • データモデルのタイプ:スタースキーマ

    • ファクト:関心対象となるイベントの発生を1レコードで表現
    • ディメンション:分析の切り口となる属性値(イベント発生の場所や時間など5W1H + How manyで表せそうなもの)
  • データモデルは継続的に見直すもの

5章:マスターデータ管理

  • マスターデータ:一貫して欠損がない信頼できるデータ。顧客データや都道府県コードの変換表など
  • 複数からの参照に耐えうるマスターデータを管理するには、
    • データ定義の所有者や責任の所在を決める(責任:最新で完全であることに)
    • データの変更プロセスを定義する。
      • 完全で最新であることを担保するために、変更したいデータはどこから取得するか、検証する方法、既存のマスターデータをどのように整形するのか、見直すタイミングはいつか、こういったもののプロセスを決める
    • ELTの一要素として実装する
    • SLAと評価尺度を決める。
    • 鮮度の保証を決める。決めるに当たってどのくらい参照されているのかを計り、需要と照らし合わせて決める
  • 利用を促すガバナンスルールを整備する

6章:ドキュメントとコンテンツ管理

  • 非構造データ:DB外にある否定形なデータ。例えばプロジェクト計画が書かれたword、予算計画が書かれたexcelなど
  • これらを管理することでセキュリティ対策を行う

  • これを行うには以下のようなアクションが必要になる

    • 散らばっているデータがどこにあって、何かを調査する。内容を社内wikiなどで検索しやすい環境に集約する。作業の大半がこれになる
    • 管理のためのモチベーション作り
    • 非構造データを表形式で紐付ける。ドキュメントの用途や属性で検索、抽出を可能にする
      • e.g. 情報システム資産台帳
  • 筆者がやったこと

    • とりあえず社内wikiの個人ページに残し、書いたか関係者に見てもらう
    • 質問を受けて「ここに書いたよ」といったやりとりが3回されたら、個人ページから適切な場所に移す
    • そのドキュメントについて質問を受けることで、閲覧者の視点を把握する
    • 気になる点があったら読み手に修正してもらう
    • 上記のようなことを少数チームで運用して、土台とサンプルができたら全社に広める

7章:データセキュリティ

  • データセキュリティのインシデントのほとんどは、そのデータの危険度が知られていないことから起こる

  • 主なtodo

    • 適切なアクセス権限を設定する
    • 規則とポリシーを理解する
    • 機密に関する全てのステークホルダーの要求が実行され、監視されていることを保証する
  • データセキュリティを守るためにやるべきこと

    • 組織がどんなデータを持っているのか特定する
    • データのセキュリティレベルや規定カテゴリ(PIP、財務データなど)を決める
    • セキュリティレベルをメタデータとして保存し、定期的に見直す
  • セキュリティ要件の担保を開発工程に組み込むなどの取り組みも必要になる

8章:データ品質

  • データ品質とは:使う人の要求を満たせているかどうか
  • データ品質の基準、要件、使用を定義する
  • レベルを測定・監視・報告書を作るプロセスを定義する
  • ニーズに合致するデータを定義する
    • 全部の品質をやみくもに高くするのではなく、優先的に品質が求められるデータをはっきりさせる
    • そのために部署、用途ごとに期待されているサービスレベルを可視化し、参照頻度に合わせて品質を定義する。使っていないデータに時間を使わないようにするため

9章:DWHとBI

  • 業務分析と意思決定を支えるデータを提供するためのもの
    • ツールを導入しレポーティングの自動化を行なったり
  • そのためにやること

    • 支援対象となる業務分析案件を理解する
      • 誰がどんな目的でどんなデータを見たいのか
    • 提供に必要な技術環境と業務プロセスを構築する
      • データソース選定とシステム開発
      • 運用チームを作ってアラートやデータ検証の自動化をする
    • 利用者が効果的な分析と意思決定をおこなるように支援する
  • CIF:Corperation、Information、Factory

  • データの活用促進をする7ステップ

    1. どのチーム・担当者がどのくらい活用しているのかアクセスログを取る
    2. チームごとのデータ利用状況をマッピングする
    3. ↑を元にターゲットの優先度を決める
    4. 対象チームが行なった施策の効果を測定する
    5. 結果を踏まえて次のアクションを行う
    6. 地道なハンズオン
    7. 業務フローに分析工程を組み込む

多くの場合、データ活用よりも経営と現場業務を立て直すことが急務だったりする (刺さる...)

10章:メタデータの管理

  • 利用者がデータを見つけやすくするためのもの
  • 業務用語とその利用法に関する組織の理解を提供
  • 様々なソースのメタデータを収集し、統合する
  • メタデータにアクセスするための標準的な方法を提供する

  • メタデータの分離

    • ビジネス:内容と状態・入力規則と測定結果
    • テクニカル:技術的詳細やシステムに重点。テーブル名・カラム名・アクセス権
    • オペレーショナル:処理・アクセスの詳細・最終更新時間・エラーログなど
  • メタデータの管理はほとんど挫折しているとの記述があった

    • 開発が追いつかなかったり、ビジネスに直接貢献しにくい分野だから景気などで耐性変動のあおりを受け易かったりと
    • 筆者曰く、結局はドキュメントでカバーする問題なのではという結論になっていた

11章:データガバナンス

  • 組織の中でデータマネジメントを強化していくにあたって、組織、案件、プロセス、システムにガバナンスを効かせる必要がある

おわりに

業務のモチベーションとはまた別に、少し前に話題になっていたワークマンのエクセル経営の記事が印象に残っていて、数字ベースで自組織をちゃんと見れるようになりたいなと思うようになったのも読書のモチベーションの一つだったかもしれません。

今の状態だと机上の空論になりかねないので自分でできる範囲で何かしらのアウトプットを出したい...(データアーキテクチャの概要図まとめるくらいだったらできそう?)