2021年12月10日、データマネジメント領域に特化した「Tech × Marketing Conference 2021」
同イベントでは、データマネジメントというテーマを軸に、データ整備、ツールやサービス、データ基盤構築といったさまざまな視点から、豪華登壇者による10のセッションが行われました。当日の各セッションの様子はYouTubeチャンネル で公開されています。
本稿は「実践的データ基盤への処方箋の刊行にあたって」と題して行われたパネルディスカッションを再構成し、ダイジェストとしてお送りします。なお、このパネルディスカッションのアーカイブはYouTubeで公開しています
データ基盤構築でよく聞くお悩み
パネルディスカッションの冒頭では、データ基盤構築の際に挙げられる悩みについて、執筆者が書籍の内容を引用しながら深堀りしていきました。
高屋： 「データ基盤の構築がうまくいかない」っていうお話をよく聞くんですよね。（ 執筆にあたって）どんなお悩みがあるかをまず挙げました。
データ基盤構築におけるお悩み
（『 実践的データ基盤への処方箋』の「はじめに」より）
これは本書の「はじめに」で掲載しています。この中のいくつかについて詳しく伺います。「 社内に散らばるデータを集めたら、そのあと何をしたら良いかわからない」これはどういうことなんでしょうか？
ゆずたそ： よく大きな会社でデータ統合プロジェクトとかをやったりします。複数の部署でデータを集めましょうとか。集めたあとに何をするのか決まらないまま、そういったプロジェクトが始まったりするんです。提案資料を見ると「データを集めることによる効率的なマーケティング」とか書いてあるんですけど、具体的にどのデータをどの施策につなげてどういう風に使って、それで売上はどのぐらい上がるのかって話がまったくないまま、データ統合プロジェクトが急に始まっちゃうんですね（笑） 。結局3年後に一応できるはできるけど、それではい終わり、みたいなことがあると思ってます。こういう話は結構あるんじゃないかと思ってますね。
本名：横山翔。令和元年創業・東京下町のITコンサルティング会社「風音屋」代表。日本におけるDataOpsの第一人者。慶應義塾大学経済学部にて計量経済学を専攻。リクルートやメルカリ、ランサーズでデータ活用を推進。広告配信最適化や営業インセンティブ設計など、データを駆使した業務改善を得意とする。コミュニティ活動では、DevelopersSummitのコンテンツ委員やDataEngineeringStudyのモデレーターを担当し、データ基盤やダッシュボードの構築について積極的に情報発信している。当面の目標は100社のデータ活用を支援して各産業の活性化に貢献すること。著書に『個人開発をはじめよう！』『 データマネジメントが30分でわかる本』がある。
高屋： 「ずっとメンテナンスしてきた分析レポートが、実はなんの意思決定にも使われていなかった」これはどういうことですか？
伊藤： こういうデータが見たいから、こういうレポートが欲しいですっていう強い依頼がよくあるんですね。それで、すごくニーズがあるんだなと思って作りこんだ分析レポート／ダッシュボードがあって、それをずっとメンテナンスし続けている。蓋を開けてみると、その人が見たいっていうだけの指示で、その先のアクションだったり意思決定にはつながってない。その担当者も1回見たら満足してもう見ないとか、これはスポットで必要な分析とかアドホック分析でよくある話です。コミュニケーションが断絶していて、ひたすらその分析レポートを作り続けている人がいるのに、実は何の意思決定にも使われていない。これは本当にあった怖い話で、たぶん（データ基盤に関わる人にとって）あるあるだと思います。みなさん胸に手を当てると、ちょっとウルっとなることが多いかなと思うんですが。
高屋： 「データ収集が時間内に終わらず、その日の分析で利用できなかった」これはどういうことでしょうか？
渡部： 12時（夜0時）に処理を締めて、売上とか、コンバージョンとかを夜間バッチで集計して、翌朝10時から使えますみたいなしくみはよくあると思います。ところが、集計処理にめちゃくちゃ時間がかかって終わらないとか、データを取ってくるのに時間がかかって朝までにできません、みたいなことは結構あると思うんですよね。こういうのって大体（原因が）2つあって、1つはデータ分析に適した技術を使ってないことです。たとえばWebのバックエンドに使うようなデータベースをそのまま分析用で使おうとしても、全然アーキテクチャが違っていてスピードが出なかったりします。そういうことを知らないまま、Webと同じデータベースで集計していて全然スピードが出ないということがあるんですよね。
東京工業大学大学院 情報理工学研究科にてデータ工学を研究。株式会社野村総合研究所にて大手証券会社向けのシステム基盤を担当し、その後はオープンソース技術部隊にてオープンソースミドルウェア全般の技術サポート・システム開発を担当。その後、株式会社リクルートテクノロジーズに転職し、リクルート全社の横断データ分析基盤のリーダーをする傍ら、東京大学での非常勤講師やビッグデータ基盤のコンサルティングを実施。現在は、株式会社MobilityTechnologies（旧JapanTaxi株式会社）にてMLOpsやデータプラットフォームを担当している。著書に『図解即戦力 ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書』
（あともう1つは）データの取り方にもコツがあります。データベースからデータを取るときに「select * from table」みたいに全部のテーブルを取ってしまうことがよくあるんですよ。何も考えずにやるとそうなるんですね。でも、収集する対象のテーブルに更新日付があれば、更新日付を元に前回からの差分のデータだけを収集すれば少ないデータ量ですむわけです。そういうのを知らないまま無邪気に全コピーしているとすごい時間がかかるし、しかもその元のデータベースを管理するエンジニアから怒られるとか、ほんとよくある話ですね。
高屋： 「過去に外部のデータ分析会社に外注をしたが、うまくいかなかった」これはいかがでしょうか。
伊藤： 少し前まではAIとか流行ってたと思うんですが、そのときによくPoC貧乏とか言われていました。データ分析プロジェクトを立ち上げたのにそこから価値が出せないとか、とりあえずPoC（Proof of Concept）して終わりみたいな。組織として何かコンセプトをもとに検証して、それが知見になればいいんですけれども、何の成果も得られませんでした、みたいになりがちです。そうすると、発注側の企業としてはデータ分析なんてなんの役にも立たないじゃないかっていう話がよく聞かれました。これも涙なくしては語れないような話です。
ゆずたそ： （発注側の企業の）データの渡し方もありますよね。ちょっと切り取ったCSVファイルだけ渡して、2ヵ月以内に20枚のレポートが戻ってくるみたいな。それだけ見てもなんとなく特徴はわかるけど、じゃあそこからどうしようみたいになって、そこから先に進まなかったりすることもあります。
伊藤： 発注者側のシナリオと持っているデータの内容が合っていないということがあると思います。これもあるあるです。
寄せられる悩みは多く、これらに回答する目的で『実践的データ基盤への処方箋』を執筆したという背景が説明されました。続いて、執筆にあたって理想的なデータ基盤の全体像を定義したという話になりました。
データ基盤の全体像
高屋： これが今日みなさんにお見せしたい図です。これを作るのに毎週打合せをしましたね。
登壇者らで考えたデータ基盤の全体像
（『 実践的データ基盤への処方箋』の「はじめに」より）
伊藤： 我々の苦労、血と汗と涙のつまった図ですね。
打ち合わせを重ねて作成したというデータ基盤の全体像にふれながら、執筆内容を紹介していきました。
高屋： データ基盤構築のお悩みもこれを使って説明すると上手く収まる、このどこかが欠けていても良くないという図になっていると思います。まずはゆずたそさんに、データの入口と出口という面からご説明をお願いします。
ゆずたそ： 主に図の左端のデータソースと書いてある部分と、右側のデータ基盤の利用者に関する部分ですね。ここをちゃんと考えようということを書いています。
たとえばなんですけど、さっきお話したような、システムを作ったけれども使われないとか、データを集めたけどその先どうするかわからないっていう話は、この右側（出口）の、データを使う側のことを考えずにプロジェクトを始めてしまうので、そういった問題が起きると思います。どういう人が、どう使って、どんな効果を得たいのかという、この右側の部分を押さえずに、データを集めようと真ん中の部分を作り始めるのは違うでしょ、というのが先ほどの話への回答かなと思います。
データ基盤の利用、具体的にはデータを使ってクーポン配信するようなシステムを作る場合は、システムを作るソフトウェアのエンジニアがいます。また、そこでもし機械学習のロジックを使うのであれば機械学習エンジニアがいます。クーポンを配信する前にクーポンの効果を見立てるとか、このクーポンを配信する対象のリストにはどんな人がいるのかを分析するなら、データアナリスト、データサイエンティストと呼ばれるような人たちがいると思います。さらにその先には、データを活用した施策を打って喜ぶ人というのは、社外であればそのサイトを使う人とかクーポンが届くお客様がいますし、社内であればデータを見て意思決定をする意思決定者がいると思います。
左側、データの入口の部分を説明します。さっきの話で言うと、CSVファイルを渡されたけどこれじゃ分析できないよ、みたいな問題は左側（入口）に原因があると思います。使いたいデータがちゃんと入力されてるんだっけ？ とか保存されてるんだっけ？ といった問題です。データソースにあたるものは、ファイルのシステムとか、Webサイトのデータベース（事業DB） 、ログやあるいは外部のAPI、あるいは社内の他のシステムからAPIで取ってくるとか、あとは営業スタッフが入力するツールとかが考えられます。こういったデータソースの中から、必要なものをちゃんと引っ張ってくる必要があると思っています。
この図のデータの入口と出口についてちゃんと考えなければ、いくら良いシステムを作ってもそれが役に立つのはなかなか難しいということを書いています。
高屋： データ基盤の構成を表す図の中央について、渡部さんご説明いただけますか。
渡部： 図の真ん中はデータの持ち方を表しています。データの持ち方には、データレイク、データウェアハウス、データマートの3つがあります。それに対してメタデータを管理します。これらをどうやって作るかを2章で解説しています。さらに、この3つのデータの持ち方の右側の「ユースケース」という部分は、例えばレコメンドAPIに結果を流し込むデータアプリケーションだとか、TableauのようなBIツールやであったりとか、データの探索的な使い方などをユースケースとしています。
データ基盤システムは基本的に、データ収集があって、真ん中（データレイク、データウェアハウス、データマート）があって、ユースケースに出ていく、という3つで分けるとすくいわかりやすく、それを図で表現しています。
データ収集のところでは、データソースの種類に応じた収集方法も解説しています。ファイルとデータベースの取り方は、APIの取り方と全然違うので、それをまとめて1つのツールでやろうとすると無理です。こういう解説もしていますね。
あと、データソースの箱の下に「データ所有者」という人がいます。この人が重要で、データを取るときに相対するのってデータソースのシステムの管理者なんですね。データベースの管理者とか、APIの管理者とか。そういう管理者の人たちとどういうふうに調整していくとうまくデータが取れるのか、を気にする必要があります。
ゆずたそ： さっきおっしゃってましたね。DBをダイレクトで叩くと怒られる。
渡部： めちゃくちゃ怒られるんですよ。何やってんだ！って。ですのでこの人は重要です。
データ組織にまつわる人々～データスチュワードとは
パネルディスカッションの終盤では「データスチュワード」の役割について話題がおよびます。
伊藤： 『実践的データ基盤への処方箋』でいうと、1章と2章がデータマネジメント系のシステムに携わっている人たちが必要な部分ですが、そもそも自分たちのデータ組織ってどういうレベルなのかを3章で解説します。ですので、最初は組織のアセスメントの紹介から入って、実際こういった組織を運営していくにあたって意識しないといけないことを解説しています。
先の図で言うと、各コンポーネントの担当者や利用者であったり、データスチュワードやデータエンジニアといった専門性の高い人たちを束ねるための組織の箱をデザインする話であったりとか、あとは採用についてもふれています。組織運営の運用のプラクティスであったり、あとは非機能要件やガバナンスに近い話題として、セキュリティを意識した運用ルールの策定であったりとか、匿名加工も最後の方に出てきます。
高屋： この本ではじめてデータスチュワードという役割を知ることになったんですが、どういう役割を担うのかお伺いしたいです。
ゆずたそ： データスチュワードってデータマネジメントの本や資料を見ると必ず出てくる役割です。世話役って書いてある通り、データに関する困りごとを解決する人というのが正しいかなと思います。
主に2つ役割があると思います。1つは、実際のユーザーの声、データを利用する人たちの声、データを生成している人たちの声を拾って、社内でこのデータはこういう役割／定義ですというのを解答していく、教えていく、そういった役割です。時には、データを使うことに慣れてない人の代わりに集計を手伝うような場面も、実務上はあると思います。ボトムアップでの課題解決役です。
もう1つは、トップダウンでのデータ活用促進の役割もあると思います。データを使ったらもっと価値を生み出せるはずなんだけれど、データを使うことに慣れていない部門に対して、しっかりと働きかけていく。「 こういうふうに使ってみたらどうですか？」っていう提案をしていく活動もあると思います。
データスチュワードがいないと、データに関する困りごとを拾う人がいなかったり、データを使ったら価値を生み出せる部門に対して働きかける人がいなかったりすることになるので、データ利用を促進していくなかで大きな損失が起きてるんじゃないかなと思います。
パネルディスカッションの様子（画面左上から、全体の進行を務めたCARTA HOLDINGS中田氏、Classi株式会社伊藤氏、技術評論社高屋、左下からMobilyty Technologies渡部氏、ゆずたそ氏）
2年をかけてバージョンアップを繰り返した図については、執筆者らのこだわりが強く、パネルディスカッションは盛り上がりを見せます。
高屋： データ組織の三角の表現について、渡部さんにお伺いしたいです。
渡部： 三角にしているのは、データエンジニアは、データ収集やデータウェアハウスを整備するところがメインの役割で、データマートとかユースケースにいくとその役割をスチュワードの方にまかせていくみたいな位置づけを意味しています。
ゆずたそ： これ、いろいろ言いたくなっちゃいますね。100:0じゃないから、四角じゃないんですよね。あくまでもお互い連携があって、（ 責務に）グラデーションがあるからこの三角になっているとか。
伊藤： ある程度人員がそろって、役割分担ができればこの図のような形になるんですが、まだ始めたばかりではこの図のようにはならないと思います。この図を見て、こういうところにポジションが必要で、そうじゃないと基盤を作っても運用がまわらないんだという、羅針盤のように使っていただきたいですね。このような気持ちでみんなで議論して、2年ぐらいかかりましたからね。
与えられた時間ではすべて説明しきれないという声があがるなか、最後に読者へのメッセージを伝えてセッションは終了しました。
ゆずたそ： データ分析やシステム、ツールの本はいっぱいあると思うんですけど、結局それらをいくら勉強しても、実務で使うにはそこにもう1つ壁があって、そこについて考える本になってるのかなと思います。いざやるぞってなったときにいろいろ困ることが起こると思うので、そのときの旅のお供にしていただけると嬉しいです。
