ユースケース

ここでのユースケースは、データ分析基盤の用途を指す。

例えば、食品メーカーで考える施策として、
・サプライチェーン最適化
・在庫最適化
・売上や仕入れ数、広告コストのモニタリング
・商品開発における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に書き換え、定常的に実行できるようにワークフローエンジンに組み込む。

終わりに

今回は、ビジネスに繋げるためのデータ活用策として重要なユースケースとサービスレベルの考え方、それを実現するためのデータパイプライン設計の考え方についてまとめました。

次回のテーマは検討中！

参考図書

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