ゆずたそ、渡部徹太郎、伊藤徹郎 『実践的データ基盤への処方箋』

タイトル通り、データ分析基盤の構築・運用について実践的な面が書かれた一冊。それぞれ現場で課題に向き合ってきたからこそ書ける、ノウハウや躓きのポイントが書かれている。DMBOKみたいな一般論を一通り見た後だと、実践的に問題になってくるポイントがつかめる。データ基盤の作り方は認知されているが、活用の仕方は認知されていない。その活用には、知識や技術だけではなく、実際にビジネス価値を出している現場のノウハウが必要である。本書では、データ活用のノウハウをデータ、システム、人の観点から解説している。

データについては、まずCRUD表を用いてデータの入口と出口を明らかにし、全体像をつかむことが書かれる。個々のデータソースの詳細はER図で把握する。こうしてデータそのものの流れが把握される。加えて、データ生成過程をロール（作業者）、オペレーション（作業者の行動）、アプリケーション（作業者のツール）、ストレージ（データが記録されるところ）の4つのレイヤ（業務レイヤ）で捉える。これらレイヤのどこに課題があり、改善点があるかを考える。データソースで大切なのは部署横断のマスタ、全社共通ID、履歴である。

データウェアハウスは唯一の情報源とすべき。DWH層で売上など共通指標を定義する。共通指標は各所から参照されるものなので、分析用DBで定義すべきもの（例えばLookerもこうした指標の定義の思想を持っているが、BIツールのレベルでやってはダメということか）。データ活用が進んでいないのにデータウェアハウスを作ってはいけない。データウェアハウスの構築は、活用が進んでから。データ活用が成功して共通指標が分かってからでないと、想像で作った実態に合わない共通データになってしまう。

データマートは、活用のユースケースと一対一で作る。そのほうが利用者側は試行錯誤しやすく、処理も速くなる。このアプローチの問題は、データマートが乱立すること。メタデータをしっかり管理し、使われていないマートを検知することで対処する。また、集計ロジックがツールに組み込まれ、見えなくなってしまうという問題もある。個々のデータマートで試行錯誤が終わったらSQL化してワークフローエンジンに乗せていくという、2つのステップでデータマートを作ることで対処。データマートは、データソースの性質とユースケースごとにITサービス品質を設定すること。一律なサービス品質の設定は有効ではない。

メタデータの管理について書けば、メタデータ整備の専門部隊には消極的な意見が書かれる。メタデータの専門部隊を立ち上げたくなるが、多くの場合うまくいかない。はじめはうまく行っても、データソースが多様化していくと情報更新が追いつかなくなる。データソースの内容に責任を持っており、一番詳しく変化にも気付くのはデータ生成者なのだから、彼らを巻き込まなくてはデータ整備は進まない。

システム面も、データソース、データレイク、データウェアハウス、データマートといったアーキテクチャに基づいて書かれる。データソースはファイルからデータベースまで収集元が様々であるため、データ基盤構築の中で最も取り扱いが難しく注意が必要。具体的に、更新ログからデータレイク側でデータベースを復元するのではなく、更新ログに直接クエリできるようにするCDCツールなどが扱われる。CDCツールとしては、AWSのDatabase Migration Service、GCPのDatastreamなど。データレイクをオブジェクトストレージに設けるのではなく、データウェアハウスと同じ分析用DBで扱うことが流行ってきている（データレイクハウス）。管理する対象が1つで済むという点と、SQLを用いてデータウェアハウス生成処理が記述できて開発しやすいという点、JSON型が利用できるデータベースが増えてきた点といったあたりがその背景と思われる。

起動順序や再実行の管理の点でワークフローエンジンを使うべきだが、自作するのは難しい。ワークフローエンジンは、他の事業システムに既に設置されているなら、データ基盤側はまず相乗りすることを考える。データ基盤で準備したデータに基づいて事業側のシステムが動く場合に一括して管理できる。ただし変更の柔軟性は落ちる。

データ活用は結局は人の側面が大きい。組織の根本にある企業文化が、データ活用を成功させるための鍵を握る。データに基づく意思決定を行っているか、定性データと定量データのバランスは取れているか、など。ただし、データは誰が管理しているか、などは文化に関する問いではない。データ活用の初期には、独立したデータ部を作るなど中央集権型組織が良い。組織が分かれていることによるサイロ化には、プロジェクト化することで対処する。中期には、各事業部にデータ人材を配置する分散型組織が良い。成熟期には、集権型と分散型の両方を取り入れた組織が良いが、これには一定以上のデータ人材が必要。