【レビュー】実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ

目次

■はじめに
■■データ活用の現状
■■データ活用のためにはデータ基盤が必要
■■データ基盤をつくるための道具や知識が揃ってきた
■■データ基盤を十分に活用できているとは言い切れない
■■データ基盤の活用には、知識や技術だけでなく現場のノウハウが必要
■■データ、システム、ヒトのノウハウ
■■データ基盤の全体像と組織
■■想定する読者
■■本書では書いていないこと

第1章　データ活用のためのデータ整備

■1-1　データの一連の流れを把握し、入口から出口までを書き出す
■■データソースからユースケースまでの流れ
■■入口と出口を洗い出すCRUD表
■■データ基盤に関する用語集をまとめる

■1-2　データの品質は生成元のデータソースで担保する
■■データソースとは何か
■■なぜデータソースの品質に注意すべきか
■■データの生成過程を知る

■1-3　データが生じる現場を把握して業務改善につなげる
■■データソースの詳細を把握する方法
■■ERD（実体関連図）を書こう
■■業務レイヤを書こう
■■業務レイヤで課題の原因と改善案を考える
■■組織の枠を超えてデータ生成の現場を考えよう

■1-4　データソースの整備ではマスタ・共通ID・履歴の3つを担保する
■■マスタデータを生成しよう
■■共通IDを生成しよう
■■履歴データを生成しよう

■1-5　データレイク層の一箇所にデータのソースのコピーを集約する
■■データレイク層とは何か
■■どのようにデータレイクをつくるか
■■現場で生じるデータレイク層の課題
■■なぜデータを一箇所に集めるべきか

■1-6　データウェアハウス層では分析用DBを使って共通指標を管理する
■■データウェアハウス層とは何か
■■なぜ共通指標を集計すべきか
■■なぜ分析用DBで共通指標を集計・管理すべきか

■1-7　共通指標は本当に必要とされるものを用意する
■■どのようにデータウェアハウス層をつくるか
■■手順①：データクレンジングの実施
■■手順②：スタースキーマの作成
■■手順③：共通指標の集計
■■初期段階ではデータウェアハウス層をつくらない

■1-8　特定用途に利用するデータマートはユースケースを想定してつくる
■■データマート層とは何か
■■なぜユースケースごとにデータを管理すべきか
■■どのようにデータマートをつくるか
■■現場で生じるデータマート層の課題とその解決法

■1-9　ユースケースを優先的に検討しツールの整備を逆算する
■■ユースケースとは何か
■■なぜユースケースに注目すべきか
■■どのようにユースケースを定めるか
■■現場で生じるユースケースの課題

■1-10　データの調査コストを減らすためにメタデータを活用する
■■メタデータとは何か
■■なぜメタデータを管理すべきか
■■どのようにメタデータを管理するか
■■現場で生じるメタデータの課題と対処法

■1-11　サービスレベルを設定・計測して改善サイクルにつなげる
■■サービスレベルとは何か
■■なぜサービスレベルを計測するか
■■どのようにサービスレベルを設定・計測するか
■■現場で生じるサービスレベルの課題と対処法

■1-12　データ基盤の品質を支えるデータスチュワードの役割を設ける
■■データスチュワードとは何か
■■なぜデータスチュワードが必要か
■■データスチュワードはどう振る舞うか
■■現場で生じるデータスチュワードの課題と対処法

第2章　データ基盤システムのつくり方

■2-1　一般的なデータ基盤の全体像と分散処理の必要性を理解する
■■データ基盤のつくり方は一般化されてきた
■■データ基盤を構成するシステムコンポーネント
■■大量のデータには分散処理が必要

■2-2　データソースごとに収集方法が違うこと、その難しさを理解する
■■データ収集は難しい
■■データソースの種類ごとの収集方法
Column　データを収集せずに分析に利用する「フェデレーション」

■2-3　ファイルを収集する場合は最適なデータフォーマットを選択する
■■ファイルデータの収集方法
■■ファイルの中身を厳格に管理したい場合はデータ構造も一緒に収集する
■■データの量を減らしたい場合はParquetを検討する

■2-4　APIのデータ収集では有効期限や回数制限に気をつける
■■APIによるデータ収集とは
■■APIからデータを収集する方法
■■API実行回数制限やAPIキーの有効期限に注意

■2-5　SQLを利用したデータベース収集ではデータベースへの負荷を意識する
■■企業にとって重要なデータはデータベースに入っている
■■SQLを利用したデータベース収集
■■テーブルが大きい場合はフェッチを活用する
■■収集が間に合わない場合はテーブルの一部だけを収集する
■■それでも間に合わない場合はSQLを並列実行する
■■SQLによる収集はデータベースへの負荷が大きいためレプリカを用意する

■2-6　データベースの負荷を考慮したデータ収集ではエクスポートやダンプファイル活用を視野に入れる
■■データをファイルにエクスポートして収集する
■■ダンプファイルを利用する

■2-7　更新ログ経由のデータベース収集はデータベースの負荷を最小限にしてリアルタイムに収集できる
■■データではなく操作を収集する
■■操作が記録された更新ログを収集する
Column　レプリカから収集する方法と更新ログ収集は何が違う？
■■更新ログ収集はCDCツールが本命

■2-8　各データベース収集の特徴と置かれた状況を理解して使い分ける
■■データベース収集方法のまとめ
■■使い分けのコツ
■■どの方式もうまくいかない場合

■2-9　ログ収集はエージェントのキャパシティに注意
■■ログとは
■■ログはログ収集エージェントで収集する
■■ログ収集ができる製品

■2-10　端末データの収集は難易度が高いためできるだけ製品を利用し無理なら自作する
■■端末データは大量だが有用
■■ブラウザイベントやスマホアプリイベントはデータ収集製品を利用する
■■自作する場合は分散メッセージキューを使う
■■分散メッセージキューの注意すべき特徴
■■分散メッセージキューをうまく運用するコツ
■■具体的なシステムのつくり方

■2-11　ETL製品を選ぶポイントは利用するコネクタの機能性とデバッグのしやすさ
■■ETL製品とは
■■使うコネクタの機能を重視する
■■ソースコードレベルでデバッグしやすいものを利用する
■■エンジニアがいなければプログラミングレスのETL製品も選択肢の1つ

■2-12　データレイクでは収集したデータをなくさないようにする
■■収集したデータを原則そのまま蓄積する
■■データレイクには冗長化でき容量が拡張できる製品を選ぶ
■■ファイルはオブジェクトストレージに蓄積する
■■CSVやJSONデータはデータベースに入れてもOK
Column　画像や音声などのバイナリデータを分析用DBに入れてもよい？
■■データがオンプレミスにあってもデータレイクはクラウドにする

■2-13　データウェアハウスには抽出や集計に特化した分析用DBを採用する
■■オペレーショナルDBではなく分析用DBを採用する
■■オペレーショナルDBはデータの操作に強い
Column　NoSQLはオペレーショナルDB
■■分析用DBはデータの抽出と集計に強い

■2-14　分析用DBはクラウド上で使い勝手が良い製品を選ぶ
■■分析用DBの製品選定が最も重要
■■分析用DBの一覧
■■初期コストの低いクラウド上の分析用DBがおすすめ
■■クラウド上の分析用DBはデータソースと同じクラウドの製品が自然な選択肢
■■クラウド上の分析用DBの選び方
■■使い勝手も重視する

■2-15　列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける
■■列指向圧縮を理解していないと分析用DBを正しく使えない
■■データ圧縮
■■データの読み飛ばし
■■データの一部の更新や削除が遅い
■■分析用DBに優しいSQLを書こう

■2-16　処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する
■■ワークフローエンジンとは
■■自前でワークフローを制御するのは大変
■■ワークフローエンジンの特徴を理解し必要なタイミングで導入する

■2-17　ワークフローエンジンは「専用」か「相乗り」かをまず考える
■■ワークフローエンジン製品を選ぶ前にデータ基盤専用にするか相乗りにするかを考える
■■データ基盤専用にする場合は使いやすいものを選ぶ

第3章　データ分析の組織

■3-1　アセスメントによって組織の現状を客観的に把握する
■■組織におけるデータ分析の重要度を見極める
■■データ活用成熟度のアセスメント
■■データを活用する土壌があるのか確認する
Column　データ活用成熟度のアセスメントの具体例

■3-2　組織の状況に合わせて組織構造を採用する
■■初期フェーズは集権型組織を採用しよう
■■中期フェーズでは分権型組織を採用しよう
■■成熟期はハイブリッド型組織を採用しよう

■3-3　データ組織の成功に必要な要因を理解する
■■幹部からの支援
■■明確なビジョン
■■前向きに取り組むべきチェンジマネジメント
■■リーダーシップ統制
■■コミュニケーション
■■ステークホルダーの関与
■■オリエンテーションとトレーニング
■■導入状況の評価
■■基本理念の遵守

■3-4　データ組織を構成する職種と採用戦略の基本を押さえる
■■データ活用を推進するCDO（Chief Data Officer）
■■データを整備するデータスチュワード
■■意思決定を支援するデータアナリスト
■■データからインサイトを発見するデータサイエンティスト
■■データ基盤の構築・運用・保守を行うデータエンジニア
■■採用戦略

■3-5　データ活用とセキュリティはトレードオフの関係にあることを理解する
■■データ活用とセキュリティのトレードオフ
■■データ取り扱いにおける優先すべき4つのポイント
■■セキュリティには求められる要求が多い
■■活用の価値は見えやすいがセキュリティは見えにくい

■3-6　組織の利益となるデータのセキュリティポリシーとそのセキュリティ基準を決める
■■データのセキュリティポリシーを定義する
■■データセキュリティ基準の定義

■3-7　適切な権限設定とリスク管理方法を定める
■■IAMを用いて権限を管理する

■3-8　データ利用や権限管理などの運用ルールをドキュメント化する
■■運用ルールのドキュメントを作成する

■3-9　担当、見直しサイクル、判断基準を決めてデータやツールの棚卸を定期的に行う
■■棚卸の対象を選定する
■■誰が・いつ・どのように棚卸を行うかを決める

■3-10　不正アクセスに備えてデータ保護や匿名加工技術を適用する
■■データの保護
■■匿名加工技術を使う

■3-11　監査では評価方法を理解して客観性を担保する
■■情報システムにおける監査の位置付け
■■リスクアセスメントによるリスク評価
■■監査は独立した組織が行う

データ整備／データ基盤システムの構築／データ分析組織立ち上げのプロがすぐ効くノウハウを教えます！

「会社内でバラバラになっているデータを集めたが、これから何をしていいか分からない」
「最新技術を利用してデータ基盤をつくったがニーズがなかった」
「頻繁に障害が発生するデータ収集に対応してきたが、そのデータは誰にも利用されていなかった」
「データの意味が分からず、データの意味の聞き込み調査で1日が終わった」

データを活用してビジネス価値を創出したいと考える企業は増えています。そのために、とりあえずデータを集めて、データレイク、データウェアハウス、BIツールなどのソフトウェアを導入したのですが、データ活用が進まないという声を聞きます。なぜ、せっかくコストをかけてつくったデータ基盤なのに機能しないのでしょうか？

Garbage In Garbage Out（ゴミを入れたらゴミが出てくる）という言葉があるように、適切な形でデータを取得しなければ、適切な分析はできません。また、各ソフトウェアに限定した知識ではなく、データ基盤システムとして利用するためのノウハウがなければ、データ基盤は機能しません。さらにデータ基盤にはたくさんの人が関わるため、組織のあり方やデータの取り扱いにも注意が必要です。

取得したデータからデータ活用までの架け橋となるのがデータ基盤のはずです。ビジネス価値につながらないデータ基盤はコストを垂れ流すだけの病んだシステムになりかねません。そこで本書では、データ基盤の本来の機能を甦らせるため、またデータ基盤の構築でつまづかないためノウハウを処方します。データ整備、システムの知識、組織のあり方、データの取り扱いといった"データ基盤を機能させるためのノウハウ"を、この道のプロが惜しげもなく披露します。データ基盤が思うように機能していない、これからデータ基盤を構築したいが何からはじめればよいか分からない、といったことで悩まれている方には一読の価値があるはずです。

　・データに携わるなら学んでおきたい"データマネジメント"について[2023-05-27に投稿]

　・データ分析プロジェクトのフェーズ毎の参考書籍紹介[2023-02-26に投稿]

　・データウェアハウス層について整理してみた[2022-11-07に投稿]