【1章】実践的データ基盤への処方箋を現場で活かすために
概要
「データ活用のためのデータ整備」
データ活用とは、溜めたデータを使用して分析したり、モデル構築することでビジネスへのインパクトを出すことです。
ただし、活用するには、溜めているデータの品質の向上や使用用途に適したデータの形に変換する必要があります。データの整備が不十分だと、分析結果が誤差を含むものになり、ビジネスに貢献することができなくなります。
この章では、データ整備の重要性と、データ整備を行う際に押さえるべきポイントについて解説されています。データ活用を成功させるためには、データ整備をしっかりと行うことが不可欠です。
以下は、第1章で解説されている主なポイントになります。
データ活用には、データの整備が必要不可欠である。
データ整備を行う際には、データの品質を担保し、データの利活用に必要なデータを集め、データのサイロ化を解消することが重要である。
データ生成から活用までの流れをCRUD表へ
多くの企業では、「何を解決するためにデータを使用するのか（出口）」と「どのデータソースからデータを取得するのか（入口）」が曖昧になっており、データの活用が思ったより進んでいないというケースがあります。
この問題を整理するためのものがCRUD表になります（具体的な表は実際に本を手に取って読んでください）。
誰が・どの業務で・何ができるのかを表したものになります。
この表にまとめていくことで全体を理解しやすく、組織に浸透させやすいと思いました。各会社では、ドキュメントを整備していると思いますが、文章のみで書かれていたり、部門毎にバラバラに書かれていたりすることが散見されます。CRUD表があると長期的に見てもメリットが大きそうな予感がします。
また、個人的な意見ですが「何を解決するためにデータを使用するのか」という問題は、設計フェーズでリソースを使っていくのが良さそうだと考えています。つまり、データの設計フェーズでエンジニアだけでなく、利用者（経営層、データサイエンティスト）が一緒に議論して、仕様を決めていく必要があります。というのも、目的は利用者が決定していくことがほとんどということと、設計したデータが結局あまり使えるものになっていないということが多々あるからです。
データの品質は生成元のデータソースで担保する
ここでは、溜めることができそうなデータは溜めていこうという話から始まります。
最近はデータ品質を向上させるツールが発展してきています。ただ、これらのツールを使っていて思うのが、データレイク層以降（データクレンジングが正しく動作できているか）に着目していることが多いです。
もちろん、データレイクやDWHで暫定的な対応をすることは可能ですが、恒久対応をするのであればデータソースから見直していく必要があります。
具体的には、データソースの整備ではマスタ・共通ID・履歴の3つを担保していきます。肌感として、マスタと履歴に関して上手くいっていないケースをよく見るので、これらについて述べていきます。
マスタデータは、人が介在することが多いデータになります。例えば、担当者が手入力するのか、システムを通して登録するのか、は様々ですが、高い頻度で誤入力されます。これは、手順書を用意してミスを減らしていくしかなさそうです。また、後述する履歴データと同じ設計・連携をすることが重要です。
履歴データは、トランザクションデータのように1つ1つの変更をデータとしてレコードに入れていったものになります。よくあるケースとして、データソースのレコードが変更された時に、データレイク上では変更後の値しか入っていないことがあります。これは、全件連携でデータソースの中身を全てデータレイクにコピーしていたりすると発生します。こういうケースは、リアルタイム連携で変更が発生した時に都度レコードを挿入することが1つの解決策になります。
マスタデータ、履歴データのどちらにも関することで、本にも記載がありますが、上書きを減らす設計を導入するのも良さそうです。
DWH層で共通指標を管理する
売上やCV率などの全社で使用していく共通指標は、DWHの一部で管理する必要があります。これは独自（のデータマート）で集計してしまうことで、バラバラな値になってしまうからです。データ管理をする部門が、DWHで管理をすることで解決できます。
また、Tableauやスプレッドシートで集計してしまうとデータが管理できずバラバラになってしまうことも散見されます。
初期段階ではデータウェアハウス層をつくらない
データエンジニアリングが日本でも浸透してきて、3層構造はよく知られるデータ基盤知識の1つになりました。データレイク、DWH、データマートを作成することが先行してしまいますが、これは長期的に見て失敗するケースがあります。例えば、共通指標の再定義などがあります。
早すぎる最適化は手戻りが発生してしまうので、データマートはデータソースを参照するような構造を取る方が良いです。
また、これは完全に個人的見解ですが
DWH、データマートはテーブルで作成するのではなく、ビューで作成することをオススメします。これも上記と同様の理由で、初期は頻繁にデータ変形のニーズが変わることが多いからです。
データの調査コストを減らすためにメタデータを活用する
分析するにもデータの意味がわからないので調査をする必要が出てきて、どのテーブルのこのデータは誰が管理しているのかを調査するのに数ヶ月かかったことはないでしょうか。
この問題を無くしていくためにメタデータを管理する必要があります。
ここで注意ポイントとして、最初からメタデータ管理をする部隊を作っていくのではなく、スモールステップとしてデータ生成者がカタログを登録するだけで良いです。後々部隊が機能しなくなることが多数です。
サービスレベルを設定・計測して改善サイクルにつなげる
多くの企業では業務システムのサービスレベルを設定していますが、データ基盤のサービスレベルまでを設定していることは稀に思えます。
データ連携が何時までに完了しているか、という共通認識はあり、目標の1つに入れているだけになっているケースがよくあります。
もちろん100%連携できていれば良いでしょうが、そんなことはできません。ですので、時間までに連携できたのかを1年間で何日あったのか、達成度を集計・目標に立てる必要があります。
まとめ
この章では、データ基盤を作成していく上で大事な考え方や知っておくべき知識についてが述べられています。
対象としては、データエンジニアはもちろん、データアナリストやデータサイエンティスト、経営層は一度読んでおくべきだと思います。
ここまで噛み砕いて、現場で使えるように書いてくれている本はなかなか無いので是非手に取ってみてください。
続きの第2章はこちら
いいなと思ったら応援しよう！
