今回のテーマ：
ビジネスに繋げるためのデータ活用策と、それをデータ基盤に落とし込む際の考え方
ユースケース
ここでのユースケースは、データ分析基盤の用途を指す。
例えば、食品メーカーで考える施策として、
・サプライチェーン最適化
・在庫最適化
・売上や仕入れ数、広告コストのモニタリング
・商品開発におけるABテスト
などが挙げられるが、これらの施策に対し、以下の流れでユースケースを定める
ユースケースの定め方
1、事業についての目標、現状、課題、施策を洗い出す
2、データ活用施策の投資対効果を見立て、優先順位を定める
3、期待される効果と必要なコストを算出し、総合的に判断して優先順位を決める
上記ユースケースを実現するためにデータ分析基盤を整備することになるが、
データ基盤構築の目的＝ユースケースの実現であり
開発・運用コスト < ユースケースの便益
が前提となる。
つまり実務においては、最初にユースケースを検討→データ活用方法検討→データ収集・投資の判断という流れとなる。
ユースケースについては、課題やニーズを深掘りし、解像度を上げていくことが重要かと思われるが、そこら辺については下記の書籍が個人的には参考になった。
解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法
サービスレベルの設定・計測
サービスレベル＝サービスの品質水準
サービスレベルはユースケース毎に以下の流れで設定、計測する。
1、目標設定
例えば、
・営業支援システムにおいて、「週次の売上データの集計が月曜日の8時までに終わっている」
・労務で使用するシステムにおいて、「勤怠情報の更新が毎朝7時までに終わっている」
といったものが挙げられる。使用する人や部署によりサービスレベルは異なる。例えば、前者の営業支援システムでの遅延率が5%は許容範囲かもしれないが、後者の労務システムでは許容できないなど。
2、関係者との合意
仮に遅延率目標を1%とした場合、それが達成可能かどうかをデータエンジニアやデータ生成者に確認する。
3、現状の計測
遅延率目標1%に対し、現状ではどの程度達成できているかを計測する。
課題の設定
現状の計測の結果、未達であれば何が問題かを分析する。
必要な施策の実施
問題を取り除くことができる施策を実施。
結果の振り返り
最後に、実施した施策によって結果がどうなったかを検証する。
データパイプライン
ここから具体的に、データを収集するところからユースケース（データ活用）までの流れをまとめていく。
一連のデータパイプラインに関する基本的な用語などについては、以下にもまとめてあります。
データレイク
データレイクの正しい活用法
１、データをそのままコピーしてくる
データレイクに置いておくデータは、そのままの状態、いわゆるROWデータが望ましい。とりあえずありのままのデータを溜めておくイメージ。
むやみに加工してしまうと、異なる視点（月単位、週単位など）から分析をしたいと考えた際に柔軟性がなく、使い勝手が良くない。
また、後々データに誤りが見つかった際、元データが間違っているのか、加工後のデータがおかしいのか問題を切り分けられない。
なので加工・修正するとすればデータレイクに取り込む前段階で大元のデータソース自体に行う、それが間に合わなければ後述のデータウェアハウスで行うのがベター。
２、データレイクを作るのは一箇所とする
複数箇所に作るとデータソースの修正が発生した際に全てのデータレイクに取り込み直さないといけない。
また、データレイクは部署を横断してデータを溜めておく場でもあるので、複数箇所に作ると各部署からデータをかき集める事態にもなり得るため共通の場としておく。
データウェアハウス
データウェアハウスでは共通指標を管理する
会社全体で見た時、部門毎に言葉の定義が異なっていると、分析結果を見た経営層は誤った意思決定をしてしまう。
主要指標については、共通指標をデータウェアハウスで管理する。例えば、部署横断での分析の際、「売上」が何を示すのか共通の指標を作るべき（税込、税抜、割引のありなしetc)
部署によって用途が異なるデータについては、後述のデータマートで管理する。
データウェアハウスは分析用DB（データウェアハウス製品）を使用するべし
分析用DBは他のツールから参照されることを前提に作られているが、スプレッドシートやBIツールはその限りではない。なので、「売上」のような主要な指標はBIツールなどではなく、部門横断で分析用DBにデータを用意した方が良い。
※DBにはオペレーショナルDBと分析用DBがあり、オペレーショナルDBはアプリケーションに使うようなDBで行指向型、分析用DBは分析に特化しており列指向型となる。ここら辺は別途どこかで記事をまとめたい。
データマート
用途（ユースケース）と１対１の関係になるのがデータマート
データマートを作るメリット
１、試行錯誤できる
ユースケースと１対１の関係になるため、他部門や他用途への影響を気にする必要がなく、試行錯誤しても影響範囲が限られる。
２、過去のロジックを再利用できる
ユースケース毎にデータ集計ロジックを用意しておけば、類似の業務が発生した際に既存ロジックを参考にできる。
３、システムの応答時間が速くなる
事前に集計処理を施しておけば、ダッシュボードを表示するたびに複雑な集計が必要ないので、応答時間の早さにつながる。
データマートの課題と解決策
課題１：
個別にデータマートを作りすぎ、似たような集計ロジックが無駄に散在する。
解決策：
データの利用状況や依存関係を整理し、不要なデータマートは削除するなど組織としてクリーニングの仕組みを作る。
課題２：
データマートに各ツールを使う場合、集計ロジックが格ツールに分断され、依存関係が管理できない。
解決策：
各種使いやすいツールで試行錯誤→軌道に乗りそうだったら、ロジックをSQLに書き換え、定常的に実行できるようにワークフローエンジンに組み込む。
終わりに
今回は、ビジネスに繋げるためのデータ活用策として重要なユースケースとサービスレベルの考え方、それを実現するためのデータパイプライン設計の考え方についてまとめました。
次回のテーマは検討中！