【イベントレポ】2024/11/12 効率的かつ最適な意思決定を後押しする「データ可視化」の実践ノウハウ データマネジメントの勘所【日本経済新聞社×アソビュー】
今作っているデータ基盤がどのように利用されるか想像はついていますでしょうか？
今回はデータ基盤利用者側の目線に立って、真に利用されるデータ基盤はどのように作っていくかをこのイベントを通じてまとめられると良いなと思っています。
概要
『データマネジメントの勘所』シリーズでは、データエンジニアやデータサイエンティスト/アナリストをはじめとするエンジニアのデータマネジメントの実現にむけた挑戦にスポットライトをあてて、泥臭い取り組みや試行錯誤の中で得た気づきや学びを紹介しています。
今回は、様々なデータを見える化してビジネスを前に進める意思決定に活かせる「データ可視化」にフォーカス。
大量データを用いて効率的に可視化していきたい！という皆さん、「手動でのデータ取得が大変」「取得したデータの整形に時間がかかる」なんてお悩みを抱えていませんか？
今回は【日本経済新聞社】【アソビュー】のエンジニアが自社の取り組みを振り返りながら、データ可視化を実践する上で効果的なメソッドやノウハウを伺いながら、皆さんのお悩みを解決するヒントをお伝えしてます。
情報収集や学習する時間が取れず、新しい技術やツールのトレンドが分からないという超多忙なエンジニアも必見の内容です！
意思決定のスループットを向上！日経が挑戦する「逆算のデータ可視化」
概要
株式会社日本経済新聞社 佐野 玄
萩原 匡侑
日経では内製データ分析基盤「Atlas」を核として、社内の様々な組織・業務の中でデータが可視化され利活用されています。データを使う部署や利用シーン、それに意思決定のニーズに応じて必要なデータの粒度や鮮度が大きく異なります。意思決定の現場の要件から逆算して、適切なデータ可視化を実現するために私たちが実践している設計思想と実現方法をご紹介します
データ可視化のビジネス要件
前提
事象の発生からデータ化、分析可視化までをレイテンシーと呼び
解釈と打ち手をうつまでの所要時間・時間当たりの数をスループットと呼ぶ
プラットフォーム推進室の役割は、特定の事業に属さず横断的な基盤整備や事業支援を行っている。
社内には多数のデータ消費者がいる。1000万人規模の会員、1.6億レコード/日、2000テーブル。利用者はサービス開発者、記者、マーケティング、広告ビジネスで参照している。
データは重力を持つ。最大のデータに他のデータが集まってくる。なぜなら一つにまとめたほうがコストやオペレーションが良くなり、データから価値を生むまでのレイテンシーが短くなる。
内製データ分析基盤の「Atlas」は社内システムとサードパーティからデータを収集し利用者に活用してもらっている。
用途に応じてリアルタイム性、サードパーティ連携、探索的な集計・可視化が求められている。
以上を踏まえた課題
連携サービスが多い
ステークホルダー
いい感じに活用できるためのインターフェース
権限管理の実現
Bespokeのアプローチ
*Bespokeとはオーダーメイドの意味
ツールの使い分け
データサイエンティスト
Google ColabやStreamlitなどを使用し機械学習などを行う
データアナリスト
KinabaやRedashでダッシュボードを作成する
マーケ担当やサービス開発者
データアナリストが作成したはダッシュボードを参照して意思決定する
記者・編集者
内製ダッシュボードで必要な情報を即座に確認できるようにする
DBの使い分け
SingleStore
記事データ、アクセスログなどリアルタイム収集
GoogleBigQuery
数十分単位の連携で良いデータ
元はRedshiftだったがスケーラビリティやterraformの管理のしやすさからこちらを採用
elasticsearch
JSONドキュメントを処理しやすいため使用
人材育成にも取り組んでおり、
Slackで相互に質問し合える環境を作っている。
BIの使い分け
Redash
社内で最も利用者数が多い
OSS版をAWS上にセルフホストした。なぜならユーザー数が増加しても運用や金銭コストが増加しないようにするため
SQLが必要なためデータ人材以外にはハードルが高い。そのため人材育成プログラムや相談できるSlack環境やチュートリアルドキュメントを充実
Tableau
経営幹部など電子版関係者にリッチなダッシュボード
データ可視化のプロが在籍する部門に徹底したメンテナンスのもと利用
SaaS版を利用している
全社に展開するとライセンス費用がボトルネックになるので、目的と頻度を整理して調整
DataSquad
内製のダッシュボードツールの一つ。編集関係者向け。
速報性の高いデータの可視化。
渾身と呼ばれる電子版のトップページの一番目立つエリアに対して、数分単位でどの記事を持ってくるかの意思決定をしている。
渾身分析ツールという専門画面で、意思決定の場面に特化した機能を提供する画面になっている
エンゲージメントスコアという記事の評価も個別に可視化している
可視化ニーズに迅速に対応するために
ニーズ① 広告キャンペーンの初速をすぐ知りたい
広告キャンペーン毎にアクセスログをBigQueryとelasticsearchに蓄える。BigQueryには過去のデータを蓄えて、elasticsearchは最新のみを蓄える。
ニーズ② 記事の付帯情報を加味した分析がしたい
たとえば、記事も頻繁に更新されるため、更新毎にアクセスログを分析したい。
その場合、CMD由来のデータはリアルタイムに連携している。そのパイプラインの中でEnritchmentする。というのは、ログを受け取った際に記事のメタデータをあらかじめPre-JOINしておく。こうすることで、迅速に分析ができる。
ニーズ③ Marketoのデータと並べて確認したい
外部ツールを普段使っているRedashに統合したいという要望に対して、たしかに拡張性の高いAirflowで開発することも可能。しかし、TROCCOを導入して、ゼロベースで開発することを避けられる。さらに、新しいデータ連携があっても運用コストがあまり増大しない。
TROCCOを社内に開放して気軽にデータを連携できるようにしてしまうと依存関係が複雑になる。そのため、TROCCOはデータ部署だけで管理するようにした。ちなみに、TROCCOはterraform管理対象のβ版にもなっている。
内製にするか外部調達するかの判断
自社システム間の連携、リアルタイム性の要求、新規性の高い何かがあるものは内製する方が有利
外部ツールとの連携、粗目の定期実行でファイル連携、汎用的なDB間の転送などは内製してもコストがかかるため、外部調達する。
TROCCOの場合は最短最速でデータ連携ができる。逆に社内システムの連携や特殊な要件を無理にTROCCOでやっても運用が難しい場合はAirflowとpythonで内製する。
まとめ
逆算して整えることが重要である。
どんなアクションのためにどんな意思決定をするか。そのためにどんな情報が必要か。最速の可視化を可能にするには何が必要か。実現方法と技術スタック、組織体制は？など、理想状態から逆算して考える。
目的に応じたDBとBIを整備する
ツールだけではなくヒト面も同時に
データが扱えるようになるまでのタイムラグを最小に
価値を出すデータ可視化のために。ビジネス側とエンジニア側の垣根のないデータドリブン文化作り
概要
アソビュー株式会社 霧生 隼稀
意思決定のスピードを上げ価値をしっかりと届けるために、アソビューではデータ基盤利用者とデータエンジニアが日々会話をし、要件をすり合わせながら「一緒に」データ基盤を作っています。
今回はデータの可視化の文脈から、データ基盤で価値を出すためにアソビューが大事にしている文化や体制についてご紹介します。
会社紹介
アソビュー株式会社
2011年創業
物質的な豊かさから心の豊かさへ
遊び予約サイトだけでなく、パートナー側の業務DXや、最近だとふるさと納税で各地方の遊びにもアプローチ
会員数1000万人以上
施設数も1万施設以上
分析規模は100テーブル、最大70億、15TB
データ基盤について
変遷
2020年くらいにデータ基盤構築プロジェクトが頓挫
2022年にデータ基盤構築選任チームの立ち上げ。DATALEとともに本格化
2024年アーキテクチャの見直しをしながら順調に
2つのキーワード
事業価値
ただ収集しているだけでは価値に繋がらない。そのため利用先を考える。
構築スピード
BigQueryを採用した。理由としてGoogleAnalytics4やすでに一部存在しているデータをそのまま活用できるため。
SaaSのプロダクトとしてTROCCOを採用した。これは日本企業向けの豊富さやサポートとのやり取りのしやすさ、簡単に設定できるから。
アーキテクチャ
結果
Tableau Cloud上での分析結果のView数は600view/日
アクティブユーザーも週100人
最速で事業価値を出すための取り組み
構築スピード
秘伝のタレを活用する
データ基盤あるなしに関わらず、企業はどこかでデータを見ている。それはスプシかもしれないし、アプリケーション用のDBのviewかもしれない。そんな先人達が作った「秘伝のタレ」をデータ基盤で継続的に見れるようにする。
専任チームを作る
データ基盤構築の優先度は上げ難い。なぜなら、「秘伝のタレ」で最低限必要なデータは見られており、ちょっと使いづらいけど何とかなっている。兼務だと本業に集中してしまい進まない。
実際専任チームを作ってから本格化し始めた
開発はできるだけしない
データ基盤構築はとてもお金がかかる、長期的なプロジェクト。
最初から完璧なアーキテクチャやデータモデリングを目指しても上手くいかない。なぜなら実際運用してみないと上手くいかない。モダンデータスタックなど早い技術革新がある。課題が見えてきた段階で継ぎ足しや改善が必要だと考える。出ていくお金よりもデータ基盤で生み出すお金を早い段階で作る。
事業価値
経営陣を巻き込む
意思決定のスピードを上げる。本質的に価値のある指標や方向性をインプットできる。
エンジニアだけだと本質的に見たいデータがぶれる。
分析者と一緒に要件定義を行う
データ分析者とデータエンジニア間でプロジェクトを組み定例MTGを行っている
具体的には、用語や指標の共通認識を作る。言葉の定義が利用者間やBIごとに違っているとデータの信頼性が落ちていく。それをエンジニアと分析者で共通認識を作ることで品質をあげる。
たとえば限界利益の指標など
データ定義の共有
データカタログの提供はセルフ分析で重要
リリースのたびに更新内容の説明などにも使える
定例以外にもアドホックな場を用意
データエンジニアがデータ分析を深く理解し、ビジネスの課題を理解した上で分析者と要件を決めることを重要視している。
TableauとDATA Saber
DATA Saberコミュニティの重要性
Tableauを採用している。なぜなら、SQLを分からなくてもセルフ分析できる。
DATA SaberはTableauに関しての技術力とデータドリブン文化を伝えていくための認定プログラム。外部のプログラムを使って文化的な醸成も行っている。
DATA Saber達で社内のコミュニティを形成している。その中で色んなバックボーンを持った人がいるので、そこで話が進む。
社内コミュニティとデータチーム
データエンジニアがデータ分析の理解を進めていく一方で、データ利用者もデータ基盤への理解を深めていくことで、価値ある可視化を最短で作れる。
データ人材全員で回すPDCA
売上が知りたい→取得、視覚化を選ぶ、視覚化、インサイトを得る、シェアする
データ可視化の活用範囲の拡大
BIツールはデータ可視化だけではない。
事例① 業務効率化
csvの作成業務をTableauで事前作成して業務時間を0に
事例② サービスリプレイス
予実管理のSaaSプロダクトをTableauに移管して自社サービス化。
年間500万円のコストを浮かせてデータ基盤で利益を生み出す。
今後の展開
DATA Saberの増員
ダッシュボードマネジメント
ダッシュボードが500を超えてきた。
新規参入障壁やパフォーマンス問題など、ダッシュボードまでをプロダクトとかんがえてデータエンジニアと分析者で協力
《主催社LT》TROCCOを利用したデータ可視化の実現方法
概要
株式会社primeNumber 鈴木 大介
①データ可視化の目的の整理
コンテキスト
だれがいつどこで何を見て
アウトプット
どうするか
アウトカム
結果どうなるか
どうするかを整理する
頻度は？
一度のみ
ニーズ発生時
定点観測
抽象度は？
戦略検討
戦術調整
施策実行
仮にダッシュボードを作るとなったとき
3パターン
サービスネイティブ機能を利用する
構築の手間がかからない
表現の自由度が低い
BIからサービスに直接接続する
表現の自由度は高い
一方でサービスに悪影響を与える
データ基盤を整備してBIから繋ぐ←TROCCOはこのためのサービス
TROCCOの位置づけ
サービスデモ
広告効果を確認したい時、GoogleAnalyticsやYahoo検索広告を横断で見る。
Snowflakeで統合してLookerStudioで可視化
ワークフローはTROCCO上で実施できる。
GUIベースで広告サービスからのインジェストや、Snowflake上でSQLの実行を順番を指定して起動することができる。
まとめ
どんな企業にもある「秘伝のタレ」にプラスアルファの価値を加えて提供できると良いんだろうなと思いました。ただ、きっと秘伝のタレを直接見る方がリアルタイム性もありパフォーマンスも早く使い慣れているはずなので、やはり利用者との会話は必要不可欠だと感じますね。
クロストークでデジタル庁が出しているダッシュボードデザインの実践ガイドブックなるものも紹介されていたのでリンクを記載します。PowerBIのテンプレートまであって、プロトタイプ作るときはここからコピーして来ようと思いました。