データ基盤づくりがなぜ重要なのかがとてもよく分かり、かつ実践的な取組みやユースケースも豊富で勉強になる。
特に、以下の課題に何度も直面するため、本書を反芻して自身にインプットして、組織改善に活かしたい。
————————
データ活用が未成熟な組織において、声の大きな顧客の影響を受けて意思決定をしてしまうケースがよくあります。顧客の声を意思決定に反映すること自体は素晴らしいのですが、定量的な基準を取り入れないと、声の大きい顧客のみの要望に対応し続けることになりがちです。
顧客の声を聞く文化にデータを添えていくことがポイントです。
要望の発生件数を加味して、サービスにとって良い声なのか、改善するべきものなのかなどを定量的に把握して、意思決定に利用できるような業務を構築しましょう。
実践的データ基盤への処方箋
ビジネス価値創出のためのデータ・システム・ヒトのノウハウ
■データ活用のためにはデータ基盤が必要
・真のデータ活用とは、一時的ではなく継続的に企業の成長を支えることです。一時的にデータをかき集めて効果を出せたとしても、それに継続性がなければ、企業にとって意味はないのです。
・継続的にデータ活用をするためには、企業内に「データ基盤」が整備されている必要があります。データ基盤とは継続的にデータを収集して蓄積しておくためのコンピューターシステムです。
・もし企業内にデータ基盤の整備されていなければ、データの活用しようと思う度にデータを様々な場所からかき集めてくる必要があります。あるデータは業務システムのデータベースにあったり、とあるデータは共有ファイルシステムの中のスプレッドシートに記録されていたり、さらには顧客から集めたアンケートなどは紙で保管されていたりするかもしれません。こうした状況では、データを集めることに作業時間のほとんどを費やしてしまうことになるでしょう。このように企業でデータ活用するためにはデータアナリストやデータサイエンティストがいるだけでは不十分であり、データ基盤が整備されていることが必要であると分かります。
■データ基盤を作るための道具や知識が揃ってきた
●道具が揃ってきた
・ IT ベンダー各社はデータ基盤を作るための製品を市場に投入してきています。例えばデータを集めるためのツールである「ETL製品」、データを蓄積し分析するための「DWH製品」、そしてデータをチャートとして可視化したりレポートにまとめ上げる「BI 製品」などです。 ITベンダーにとって企業のデータ基盤を抑えることが重要な戦略になってきています。
●知識も揃ってきた
・データ基盤の知識についても体系化されて簡単に学習できるようになってきました。例えば、データ基盤にデータを蓄積する方法について、5年前までは特に決まった方法論はありませんでした。しかし最近ではデータの持ち方を「データレイク」「データウェアハウス」
「データマート」の3つに分けて持つと良いという方法論が確立されて、書籍や it ベンダーの説明資料で紹介されるようになってきました。
■データ基盤の全体像
■データソースからユースケースまでの流れ
・データは、データソースから右方向にいくつかの層を経由してユースケース（データ活用）にたどり着き、各層ではメタデータが付与されています。
●データソース
・オリジナルのデータのこと、もしくはそのデータの発生源を指します。顧客が EC サイトで注文すると、データベースに購入履歴が記録されます。材料の仕入れや商品の輸送については、紙の台帳で管理しているかもしれません。これらがデータソースです。
● データ収集
・データソースからデータを集める仕組みです。 EC サイトのデータベースから記録を取り出したり、紙の台帳をデジタルに変換したりしてデータを収集します。システム開発の比重が強いです。
●データレイク層
・多様なデータを集約する場所です。データソースのデータをそのままコピーしたデータ、またそのデータの置き場所を指します。注文履歴を分析用のデータベースに集約したら、それがデータレイクです。加工や結合していないコピーなので、データソースと一対一の関係にあります。
●データウェアハウス層
・加工・結合したデータを置く場所です。共通指標となるデータ、またそのデータの置き場所を指します。自社 EC サイトだけでなく、外部のウェブサイトやオフラインのイベントでも同じ商品を販売している場合、それらのデータを組み合わせて「売上」という横断の指標を集計します。
●データマート層
・加工・結合したデータを置く場所です。特定用途向けのデータ、またそのデータの置き場を指します。「毎週のジャンル別の売上」といったデータが該当します。用途ごとに作るので、ユースケースと一対一の関係にあります。
●ユースケース
・データ基盤の用途です。経営者がダッシュボードツールで「毎週のジャンル別の売上」を確認することや、キャンペーン担当者が特定の顧客層にシステムでクーポンを配布する事などをユースケースと呼ぶことができます。
●メタデータ
・データを説明するためのデータです。「購買記録データには購入者や商品金額が記録されている」といったスキーマ情報や「誰がどのデータをいつ更新・参照した」といった更新・参照情報が該当します。データの利用状況を確認することで、利用促進のヒントを得たり、トラブルを察知してその対策につながったりします。
■入口と出口を洗い出すCRUD表
・CRUD表では、人やシステムがデータをどう扱うのかを表形式で整理します。
・C（Create）：データを生成する
・R（Read）：データを参照する
・U（Update）：データを更新する
・D（Delete）：データを削除する
■データの品質は生成元のデータソースで担保する
●データソースとは何か
・ヒト・モノ・システムがなんらかの行動をとることで、記録が残ります（履歴データが生成される）。 EC サイトの訪問記録を例に挙げると以下のようなデータです。
・ユーザID、訪問時間、開いたページ、クリックしたボタン
・これらのデータをもとに、時間帯によって人気の商品（コンテンツ）がわかれば、時間帯によってバナーの表示を変えることで、顧客にとって使いやすいウェブサイトに改善できるでしょう。
■データが生じる現場を把握して業務改善につなげる
●データソースの詳細を把握する方法
・データの全体像を把握するには前述のCRUD表が役に立ちます。データの現状把握に加えて、これから必要になるデータを想定するために使いましょう。
・さらに個々のデータソースの詳細を把握するために ER図の描き方を学びましょう。ER図はデータ同士の関係性を図示したものです。テーブルを列挙し、関連する ID 同士を結ぶことで ER 図を作成できます。
■データソースの整備ではマスタ・共通ID・履歴の3つを担保する
●データ整備で問題を解決しよう
・データソースの中で特に問題になりやすいのが「マスタ」「共通ID」「履歴」です。筆者が支援した多くの現場ではこれらのデータが生成されていませんでした。これらのデータソースの品質を担保しましょう。
●マスタデータを生成しよう
・ EC サイトでグッズを販売するにあたって、同じような商品であるにも関わらず「食器」「食事」「キッチン」「カトラリー」「ランチ」など、スタッフによって入力内容が異なる場合があります。これではジャンル別で売上を分析する時、どのジャンルとどのジャンルが同じものを指すかを判断しなければいけません。同時に、法人営業の取引先企業の業種についても「飲食店」「飲食業」「レストラン」など入力者によってデータのバリエーションが生じることがあります。
・このような問題が発生するのは、各部門が独立して業務にあたっているためです。グッズの製造元や輸入元によって部署が分かれている場合、各部署ごとに異なる製造・調達のマニュアルを使っていて、データ入力についても異なる内容が記載されているのかもしれません。あるいはデジタルマーケティング部門が検索エンジンの上位表示を狙うために、ウェブサイトに多くのキーワードを表示させようとして、バリエーションを意図的に増やしているのかもしれません。
・この問題を解消するには、部門横断のマスタデータと業務手順書を機能させることです。上記の例であれば「ジャンル」や「業種」の一覧をマスタデータとして管理し、社内に周知します。「駅・路線」「市区町村」といったデータもマスタデータとしてよく扱われます。この取り組みは、一つの部門だけで推進しようとしてもなかなか全員の足並みが揃わないものです。データソースを生成している各部門の担当者が集まって、タスクフォースを組むように働きかけるのが良いでしょう。導入時には現場のスタッフが入力業務で困らないように手順書を案内してその通りに入力されているかをチェックできると安心です。
●共通 ID を生成しよう
・全社共通の商品 ID を導入することを考えましょう。部門Aと部門 B がそれぞれで商品 ID を付与してしまうと、会社横断で集計できません。ID は全社最適な視点で付与しましょう。
●履歴データを生成しよう
・ EC サイトで商品の説明文を書き換えるときに、過去の説明文を保存せずに上書きしていたとしましょう。顧客が閲覧する EC サイト上の画面では、最新の商品説明文だけを表示すれば十分だからです。しかしこれは典型的なアンチパターンです。データを上書き・削除してしまうと、過去のデータが必要な時にやり直せないのです。そのリスクを負う積極的な理由がなければ履歴は残しましょう。
・履歴が必要になるのは、データ分析部門、カスタマーサポート部門、リーガル部門といった他部署の業務です。
・データ分析の視点で履歴は重要です。ある商品の販売数が急に増えたり減ったりした時には、説明文を変えたから売れたのか、曜日や天候による影響なのか、事象を切り分けてデータを確認します。また「どのような説明文だと購買に繋がらないか」「どのような説明文だと購買に繋がるか」といった分析は EC サイトの改善には不可欠です。商品の説明文を更新する時に、過去の説明文を記録しておかないと、このような分析を諦めることになります。
・問い合わせ対応の観点でも履歴データは重要です。顧客が購入した時に「カラー：グレー」と記載されていたのに、数日後に上書きされブラックが手元に届いたらどうでしょうか。悪意があったわけではなくても、偶然が重なって、そういった事態が発生するかもしれません。そのとき商品説明文の履歴データが残っていなかったら、顧客から問い合わせを受けても、サポートスタッフは当時の状況を確認できません。消費者保護の観点からも、法令やガイドラインによって履歴の保存が義務付けられているケースがあります。
・履歴を残す方法として筆者は非正規化を行っています。履歴データと最新データの両方を保持するように設計します。顧客が閲覧する商品説明ページでは、商品テーブルを参照して、最新情報だけを表示します。一方で、問い合わせ対応のための管理画面では、編集履歴テーブルを参照します。わざわざテーブルを分離するのは、システムパフォーマンスを考慮してのことです。
■データレイク層の一箇所にデータのソースのコピーを集約する
● データレイク層とは何か
・データソース（=水源）から流れてきたデータを蓄える場所なのでレイク（＝湖）と呼びます。
・EC サイトの注文履歴データを分析用 DB にコピーしている場合、それがデータレイクと言えます。データレイクのデータはデータソースと一対一の関係にあります。何も加工していないただのコピーだからです。
・何も加工していない、ただのコピーであることが重要です。仮にデータの中身に誤りがあったとしても、修正や加工をせず、そのまま集約しましょう。
●なぜデータを一箇所に集めるべきか
・データレイクは部署横断で複数のデータを集約する場所です。部署・システムを横断してデータを活用することで、顧客体験やビジネス価値を向上できるようになります。
・例えば、集客部門とカスタマーサポート部門が、Excelでそれぞれの部門ごとにデータを管理していたとしましょう。集客部門は、キャンペーンやクーポンの発行情報といったデータを持っています。ここでカスタマーサポート部門に顧客からキャンペーンに関する問い合わせが寄せられたとしても、データが集約できていなければ満足できる回答はできないでしょう。
・データ活用が進みデータを統合できるようになると、それまでわからなかった次のような事実が可視化されます（クーポンではなく別の施策に注力すべきだった）
・「クーポンをきっかけに流入した顧客はすぐ解約してしまう」
・「クーポンで流入した顧客のサポートに労力を費やしていた」
・「トータルで見るとクーポン配布キャンペーンは他施策に比べて投資対効果が低かった」
・データを集約することで、このような部署横断のデータ活用が容易になります。
■どのようにユースケースを定めるか
・最初に、自社あるいは担当事業について、目標、現状、課題、施策を洗い出します。例えば以下のような内容です。
●3年後の目標：売上50億円＝顧客50万人×単価1万円
●現状：売上30億円＝顧客30万人×単価1万円
●課題：顧客数＝新規登録10万人＋継続利用20万人（去年からの解約10万人）
●施策：
①デジタル広告配信による登録促進
②解約候補者へのクーポンメール配信
・実務においては、これらを詳細まで検討します。例えば「登録過程のどこを改善すると効果的か」「何を改善すると解約を減らせるのか」「優良顧客の解約で平均単価が下がるリスクはあるか」といった課題について、調査・分析を行います。
・次に、データ活用施策の投資対効果を見立て、優先順位を定めます。それぞれの施策について、期待される効果と必要なコストを書き出し、総合的に判断して優先順位を定めます。
■続いてデータ活用施策の概要設計します
・「どの顧客または社員の」「どの作業または判断を」「どのように置き換えるか」を書き出しましょう。
・ これらの設計では業務改善や UX デザインの手法が役に立ちます。例えば顧客への提供価値であればカスタマージャーニーマップ。社員への提供価値であればバリューストリームマッピングや業務フロー図といった手法が存在します。
・データの利用状況を5 W 1 H で特定できると設計の際に便利です。誰が、いつ、どこで、何のために、何をどうするのか、を書き出しましょう。例えば売上ダッシュボードを作る場合は以下のようになります。
└◯◯部長が（誰が）
└水曜日の朝10時に（いつ）
└役員ミーティングで（どこで）
└進捗確認のために（何のために）
└週次の売り上げ推移を（何を）
└報告する（どうするのか）
・利用状況をここまで解像度高く描けば、売上ダッシュボードを作ることの意義が見えてきます。
■SQL による収集はデータベースへの負荷が大きいためレプリカを用意する
・ SQL による収集は高機能で敷居が低いというメリットがありますが、一方で使い方によってデータベースに負荷がかかるというデメリットがあります。
・例えば EC サイトの取引データを扱っているデータベースを考えると、そのデータベースはユーザーのオンラインリクエストによって常に参照・更新されている状態です。このような状態のデータベースに対して、全件のデータ収集をするような SQL を実行してしまうと、データベースの負荷が高くなり、オンラインリクエストへの応答が遅くなります。これでは EC サイトの業務機能に影響を及ぼしかねません。
・SQL によるデータ収集がデータベースに与える負荷は大きく3つあります。それはキャッシュ汚染、長時間クエリ、一時ファイルによるディスク圧迫です。
・まずキャッシュ汚染についてです。データベースには、頻繁に使うデータをハードディスクではなくメモリ上に保持しておいて、応答を高速化するキャッシュという機能があります。 EC サイトの例であれば、頻繁に注文される商品のデータなどがメモリ上に保持されており、このデータへの参照はすぐに応答できる仕組みです。キャッシュ汚染とはこのキャッシュ上のデータがデータ収集の SQL により必要のないデータに置き換わってしまうことを指します。
・次に長時間クエリについてです。今まで単にデータベースと解説していたものは、より正確にはオペレーショナルDBというデータベースであり、 SQL に対して短い応答時間で結果を返せるように作られています。その応答時間は数ミリ秒から数十ミリ秒程度が一般的であり、100ミリ秒 を超えるとクエリは「スロークエリ」という特別なクエとして扱われることもあります。そんなオペレーショナルDBに対して、データ収集で実行するテーブルのすべてを取得するような SQL は、数十から数百秒の実行時間になることもあり、オペレーショナルDBにとってはリソースを大量に消費するクエリとなります。
・最後に一時ファイルによるディスク圧迫についてです。データベースの多くでは ORDER BY などを用いてデータを並び替えるときに、並び替える対象のデータが大きいと、そのために必要なデータがメモリに収まりきらず一時ファイルを生成します。この一時ファイルが大きすぎる場合、ディスクの空き容量を圧迫し、場合によってはディスク容量が枯渇することでシステムが不安定になります。大量のデータを並び替えながら収集するときに注意する必要があります。
・これらの負荷を開始したい場合は、オンラインリクエストを処理するデータベースとは別に、データを取得するためのデータベースを用意する方法があります。多くのデータベースにはデータを同種のデータベースに同期するレプリケーションという機能があります。これを用いてレプリカと呼ばれるデータベースの複製を作り、そこから収集すれば、オンラインリクエストにほとんど影響を与えることはありません。
■各データベース収集の特徴と置かれた状況を理解して使い分ける
●データベース収集方法のまとめ・使い分けのコツ
・まず最初に考えるべき方法は「レプリカから SQL」です。 SQL によって列や行を絞ることができる上、レプリカのデータベースからの収集であれば収集元のデータベースへの負荷を少なくできます。実際に多くの現場でこの収集方法がとられています来てまずはこの方法を試してみましょう。
・もし収集対象のデータベースにレプリカが無い場合は、状況によって採用する方法を変えていきます。データソースのデータベースが重要な業務との連携が少なくデータ収集の負荷に耐えられる場合は「SQL」を採用しましょう。負荷を考慮しなければならない場合は「エクスポート」、「データベースダンプ」もしくは「CDC ツール」を検討します。予算が限られている場合は「エクスポート」が最も安く実現できます。
●どの方式もうまくいかない場合
・データベースを管理してる担当者から「本番データベースを他の部署が参照するなんてありえない。本番障害になったらどう責任を取るつもりだ！」といった論調で責められてしまうデータ基盤担当者は世の中にたくさんいるのです。
・そういった場合はデータベースからのデータ収集は諦め、データベースにデータを入れているアプリケーションからデータを収集する作戦を考えてみましょう。例えば、ユーザーの購買履歴データが欲しい場合に、データベースにある購買テーブルからは収集が出来なかったとしても。購買を処理したアプリケーションのログからその情報収集できれば目的は達成できます。
■ログ収集はエージェントのキャパシティに注意
●ログとは
・エンジニアの人がログという言葉を見ると、システムの障害対応の時に確認するエラーメッセージが出力されたファイルをイメージするでしょう。しかし、データ分析の文脈においてログ収集と言うと、分析対象の人や物の振る舞いを記録する時系列のデータを指します。2つの具体例を用いて解説しましょう。
・よく分析の対象となる6の一つは Web サーバーのアクセスログです。主な Web サーバーには Apache HTTP Server や nginxが挙げられ、Web サーバーが強くするアクセスログには次のような情報が格納されています。
└アクセスした時間
└アクセス元の IP アドレス
└アクセスに用いた端末情報（ユーザーエージェント情報）
└アクセスした URL
└ Web アプリケーションが設定したユーザーを識別する情報
・このログを分析することによって、 Web サイトのどのページがどれだけ表示されているかや、ユーザーがどんなアクションをしているかが分かります。
・他によく分析に利用されるログは、アプリケーションのログです。例えば EC サイトには、商品の購買を処理するアプリケーションがあります。そのアプリケーションでは商品の在庫を減らしたり決済したりするのですが、その処理の結果をログファイルに出力するシステムを作ります。このログを収集することで、いつ誰がどんな商品を購入したかという情報を分析できます。
・購入のデータであればデータベースにも入っているため、わざわざログを収集する必要はないように思えるかもしれません。しかし、多くの場合、データベースには確定された情報しか格納されていません。例えば購入しようと思い商品詳細画面に入ったけれど、「購入を確定する前に離脱した」という情報は、データベースに格納されていませんが、アプリケーションのログからはその様子が鮮明に分析できることがあります。
●ログはログ収集エージェントで収集する
・ログはどのように収集するのでしょうか。ログび実態はファイルなので、前述したファイル収集の方法を用いて収集できるように思えるかもしれません。しかし、ログはファイルの末尾に新しい行が常に追記されるため、1回そのファイルをコピーして収集完了とはいかず、定期的にファイルを確認し、追記された行があれば新たに収集する必要があります。この点が前述のファイル収集とは異なる点でありファイル収集の方法を適用できないわけです。そこでログ収集エージェントを利用します。
●ログ収集ができる製品
・ログ収集は複雑な仕組みであるため、自前で解決することは少なく、オープンソース、有償製品、もしくはクラウドサービスを利用することがほとんどです。 オープンソースではTreasure Data社が中心となって開発したfluentdやfluentbit、Elastic社が中心となって開発したLogstashが有名です。 クラウドサービスでは AWS のCloud WatchエージェントやGCPのCloud Logging Agentなどがあります。
■分析用 DB はクラウド上で使い勝手が良い製品を選ぶ
●分析用 DB の製品選定が最も重要
・分析用 DB はデータ基盤の中でも重要なコンポーネントのひとつです。データ資産の中核を担うデータウェアハウスやデータマートは、分析用 DB に格納し分析することで初めて価値を発揮します。
・分析用 DB にはデータを消失しないように保存する能力だけでなく、大量のデータを高速に処理する処理性能も求められます。処理性能が悪ければ、夜間に走らせた集計処理が終わらず、翌日の意思決定が遅れてしまうかもしれません。
・また使いやすさも重要です。分析用 DB はデータ基盤の利用者に公開され、 SQL を用いて自由にデータを触ってもらう環境であるため、使いにくい分析用 DB を選んでしまうと使われないデータ基盤になってしまう可能性があります。
■初期コストの低いクラウド上の分析用DBがおすすめ
・ここからは分析用 DB の選び方を解説していきます。選定の上で一番に優先すべきは初期コストの低さです。
・データ分析は試行錯誤の連続です。分析対象のデータや分析の要求はビジネスの成長と共に変化します。その都度必要となるストレージの量や計算リソースの量は変わり、データ分析が活発になるほど利用者からの要求が増える傾向にあります。
・最初からシステムの規模を推定することはほぼ不可能と言っていいでしょう。そのため選定の上では初期コストの低さが重要です。低いコストではじめて、ビジネスのニーズに合わせてシステムの規模を増やしたり減らしたりできるようにしておく必要があります。
・その観点で言うとオンプレミスのDWH製品は候補から外してよいでしょう。同じ理由でオンプレHadoopも候補から外せます。加えて運用するエンジニアの人件費が高くつきます。
・よって基本的に分析用 DB の選択肢はクラウド製品を選ぶことになります。クラウドの分析用 DB であれば基本的には従量課金であるため、多額の初期費用は必要ありません。例えば、 BIG query であればアカウントを登録すれば利用が始められ、料金は保存したデータ量とクエリ毎の課金になります。クラウドの分析用 DB は試行錯誤に最適なのです。
●クラウド上の分析用 DB はデータソースと同じクラウドの製品が自然な選択肢
・分析用 DB はデータソースから大量のデータを収集する必要があるため、データソースがあるクラウドで利用できる分析用 DBを選ぶのが自然な選択肢となります。例えば、 EC サイトにおいて Web アプリケーションが AWS で構築されており、 AWS のデータベースがデータソースならば、分析用 DB としては AWS 上で動作するものが第一候補になります。
・データソースと分析用 DB が同じクラウドにあることで二つのメリットがあります。一つはネットワーク通信が同一クラウド内で完結するということです。データソースと分析用 DB が同じクラウド内であると、クラウド内の帯域の大きいネットワークを経由してデータ分析ができますので、大量のデータであっても短時間で収集できます。加えて、クラウドの外部にデータを転送するときに費用がかからないメリットもあります。もう一つはクラウドにあるデータ転送・共有サービスの恩恵を受けられる点です。クラウドによってはデータソースから分析用 DB に簡単にデータを転送できる仕組みを持っています。
■不正アクセスに備えてデータ保護や匿名加工技術を適用する
●データの保護
・近年のインターネットサービスは常にさまざまなリスクにさらされています。情報処理セキュリティ機構（以降 IPA） が毎年「情報セキュリティ10大脅威」としてよくある攻撃手法公開しています。
・不正アクセスを受けた時、重要なことは自社のデータの保護です。データ保護はプライバシーを保護する観点からも重要な役割を果たし、法整備が進んでいることは前述しました。ユーザーは企業が定めた利用規約などの記載に従って、情報利用に同意しています。日本においては個人情報保護法が2003年に制定され、改訂を重ねています。2015年の法改正で個人情報の取り扱いを認める一方で、情報漏洩などによる罰則も整備されました。詳細は触れませんが、重要情報や保有しているデータを暗号化やハッシュ化しておくことで、不正アクセスによる個人の個人情報の漏洩のリスクを軽減することも期待できるでしょう。
●匿名加工技術を使う
・自社で個人情報を保持する際に、個人を特定し得るデータの一部を匿名化することで、情報の解像度を落としてセキュリティを担保できます。2015年の個人情報保護法改定に伴って創設された匿名加工という操作を用います。
・個人情報とは、特定の個人を識別できる情報であると言えます。企業が保有している個人情報で言えば、個人の氏名やメールアドレス、電話番号、住所のような顧客の会員情報の中でよく用いられる情報のことです。近年では、これらの単独で個人を特定できる情報を誤用した事故に加え、数々のデータを組み合わせて個人を特定し得る容易照合性を持つデータの取り扱いに注目が集まっています。
本棚登録 : 87人
感想 : 10件
0
