Data Engineering Study #24 データドリブン組織を支える技術

第23回では、「Data orchestration 特集」と題して、データオーケストレーションの具体的な方法や利用されるツールについて、3名の方から説明していただきました。
過去のイベントレポートはこちら

今回の勉強会では、「データドリブン組織を支える技術」と題して、データ利活用を推進している組織において、専門家たちがどのような課題に取り組んでいるのかご説明いただきました。また、「どうすればデータ活用が全社的に推進されやすいか」や「データ基盤構築をどのように経営目線のプロジェクトに落とし込むか」などについても紹介していただきました。

当日の発表内容はこちら

講演者紹介

永井伸弥氏

株式会社メルカリマーケットプレイス事業部 BI & Research platform team Manager

製薬企業の情報システム部門、ソーシャルゲーム開発会社などを経て、2019年メルカリ入社、データ基盤の整備とデータ分析の民主化を行うBI & Research platform teamを立ち上げ、チームマネージメントを担当。
X のアカウントはこちら

阿部昌利氏

株式会社ヤプリプロダクト開発本部データサイエンスグループマネージャー

修士まで心理統計学を学んだあと、株式会社帝国データバンクにてデータサイエンティストとしてのキャリアをスタート。その後、株式会社コロプラやオリックス株式会社、株式会社AbemaTVで分析チームの創成期にジョインし、サービス規模拡大を担う。キャリア10年目の2020年4月、株式会社ヤプリへジョイン。
X のアカウントはこちら

奥村純氏

株式会社GA technologies　執行役員 CDO

2014年京都大学大学院理学研究科で博士号（宇宙物理学）を取得。その後、大手インターネット関連事業会社にてデータアナリスト・機械学習エンジニア・AIプロダクトマネージャーを歴任。多くのサービスで、KPIマネジメント、データプロジェクト、データ基盤構築などをリード。2020年以降は複数の企業で執行役員・最高データ責任者などを歴任。2024年、株式会社GA technologiesに参画。『データサイエンティスト養成読本ビジネス活用編』『強化学習第2版』（監訳）など、出版・発信活動も積極的に行っている。
X のアカウントはこちら

常住彰氏

株式会社GA technologies　Data本部　DataManagement部　データエンジニア

2015年、新卒でデジタル系の広告会社に入社。メディアプランナーを経て、社内異動でBIエンジニアとなり、そこからデータマネジメントのキャリアが始まる。SIerを経て、2020年に株式会社GA technologies入社。データエンジニアとしてデータ基盤の運用保守、データ民主化に従事。

基調講演「Analytics Engineeringチームを立ち上げて学んだこと」

はじめに、株式会社メルカリマーケットプレイス事業部永井氏より、レガシー化したデータパイプラインの廃止についてお話ししていただきました。

当時のデータ分析環境の大まかな構成

永井氏：「2021年頃、私がまだデータアナリストとして働いていたとき、メルカリのデータ分析環境は本番環境のデータベースの内容をBigQueryにロードして、データアナリストや他の職種の方々が分析する流れでした。

当時から、メルカリではさまざまな職種の方々がデータを利用していました。データアナリストやエンジニアはもちろん、プロダクトマネージャーやマーケター、カスタマーサポートのメンバーも利用者の一員でした。当時でも、BigQueryのユーザーが月間800名ほどおり、非常に大規模な環境だったと思います。

また、本番環境DBからMySQLにデータをロードする際、2通りの線が描かれている点にも触れたいです。つまり、レガシー化したデータパイプラインと新しいデータパイプラインが並存している環境です。

それに関連して、社内の各チームの役割は、図のように分担されています。分析は、私も所属していた、アナリストチームが担当していました。一方で、本番環境DBや本番環境DBからBigQueryにロードするところまでは、エンジニアリングチームが担当していました。その代わり、中間テーブルを専門的に作ったり、アナリストとエンジニアの橋渡しをしたりする職種は当時ありませんでした。」

当時のデータ分析環境における課題

永井氏：「当時のデータ分析環境において、先ほど図に出てきたレガシー化したデータパイプラインに大きな問題がありました。具体的には、本番環境DBからBigQueryにデータをロードするパイプラインですが、node.jsフルスクラッチという独特なシステム構成で、稼働開始は2015年でした。

運用においても、メインの開発者の方が退職してしまった後、どのチームがオーナーシップを持ってメンテナンスしていくかが不明瞭な時期がありました。

さらに、このシステムのデータは、1日におよそ150名のメンバーが利用しており、クリティカルな用途にも使われていました。メンテナンスに不安を抱えつつも、非常に多くの業務がこのパイプラインに依存している課題感もありました。

また、技術面や運用面以外に、組織としての課題もありました。多くの関係者はこのデータパイプラインを廃止した方がよいと気づいていましたが、エンジニアリングとデータ分析の両方の視点を持っていて、音頭を取れる人がいませんでした。」

課題解決のために行ったこと

永井氏：「そのため、私がアナリストとしての役割から一歩踏み出して、このシステムの廃止を主導させてもらいました。ここで自分が率先して廃止に動いた理由は、おもに2つあります。

1つは、自分もアナリストとして分析していく中で、データ基盤のカオスな状況に困っていたため、何とかしたかったからです。もう1つの理由は、キャリアのバックグラウンドにおいて、エンジニアとしての経験とアナリストとしての経験があったため、自分だったらうまく橋渡しができるのではないかと考えたからです。

この時点では、まだチームは立ち上がっておらず、自分自身が個人の役割を少し越境して、レガシー化したデータパイプラインの廃止に取り組んだ状態でした。」

データマイグレーションに向けた課題

永井氏：「まず基本方針として、レガシー化したデータパイプラインを廃止して、新しいデータパイプラインに統合しようとしました。大元のデータソースは同じであるため、統合も可能だろうと考えていました。

新データパイプラインのマイグレーションにあたって、2つの課題に直面しました。

1つ目は、仕様の差異です。レガシー化したデータパイプラインと新データパイプラインで同じKPIを集計しても、仕様の違いにより数字が少し異なるケースがありました。この状況の中で、『レガシー化したデータパイプラインの仕様ではないと不都合』という意見が挙がっていました。

2つ目は、移行の量の問題です。仕様上の問題がなかったとしても、クエリを1個1個書き換えていると膨大な作業量になります。その作業量の多さも、データマイグレーションのうえで、ハードルの1つでした。」

課題解決へのアプローチ①：現状の調査

永井氏：「課題に対応するためにまず取り組んだことは、現状の調査です。

とくに、BigQueryへのアクセスログは、データ分析環境を改善していくうえで非常に役に立つ情報だと思いました。このプロジェクトでは、廃止対象のテーブルを頻繁に使っている人をアクセスログから洗い出していきました。これがわかることで、このテーブルを廃止するにあたってヒアリングを誰にしていけばよいのかが明らかになります。定性的にコミュニケーションを取っていくためにも、定量的な情報は役に立つと言えます。

そのうえで、なぜレガシーなKPIが必要なのか、業務上の必要性をヒアリングしていきました。ここでのヒアリングは、聞いたことをそのまま実現するためではなく、業務上の目的がどこにあって技術的にどのような解決策があるか、選択肢を広げるためです。」

ヒアリングを通して深堀りをしていく

永井氏：「社内で重要なデータとして、『取引高』と呼ばれるものがありました。取引高とは、メルカリのフリマ上で発生した取引の合計額です。

取引高に関して、新データパイプラインでは、キャンセルされた取引は取引高から随時差し引かれる仕様でした。一方レガシー版だと、その日発生した取引を翌日1時、2時になったらスナップショットを取り、スナップショットを取った時点でのキャンセルを抜くシステムでした。そのため、スナップショットを取った以降のキャンセルは抜かれない仕様でした。

しかし当時は、『スナップショット版の仕様の方が都合がよい』というところまでしか調べられていませんでした。そのため、『なぜスナップショット版の仕様の方が都合がよいのか』について、ヒアリングを通して深掘りしていきました。

ヒアリングの結果、予実管理上、過去実績の取引高が集計するたびに変化する点が不都合だと判明しました。取引高予測とそれに応じた広告予算などのコントロールは、おおよそ月末までの過去実績に基づいて行います。そのため、この過去実績が変わってしまうと、着地見込みを立てられず、業務に支障が出てしまいます。

このように、ヒアリングを行っていくことで、単に『レガシー版がいい』という大まかな要件ではなく、より解像度の高い要件が分かってきます。」

シンプルなシステムにするためのポイント

永井氏：「そうすることで、言われたことをそのまま実現するのではなく、別の選択肢も考えられるようになると思います。

実際にこのプロジェクトでは、既存の【キャンセル抜き版】と【スナップショット版】のほかに、キャンセルされた取引高も全て含んだ【キャンセル込み版】のKPIを新たに定義しました。この定義であれば、何回集計しても取引高が減っていくことはありません。

担当している方にとって必要だったのは、スナップショット自体ではなくて、集計するたびに過去実績が変わらない仕様でした。その目的を最低限達成し、そのうえで、いかにシンプルな仕様を実現できるかが重要だと思っています。

その結果、キャンセル込みの仕様が段違いに楽だったため、この仕様を新しいKPIの定義として設定しました。ちなみに、この仕様だとキャンセルが増えても気づきにくい点が課題であったため、別途キャンセル率を監視する工夫を行っています。」

課題解決へのアプローチ②：KPIの再定義

永井氏：「そして、今まで使っていた仕様はすべて、新たな仕様に統合していきました。このKPIの再定義によって、仕様の差異が原因で移行できないハードルが解消されました。」

課題解決へのアプローチ②：アクセスログのモニタリングと移行

永井氏：「もう1つは、量の問題です。仕様上の問題がなくても、クエリを書き換える量が多いため、その作業が手間でした。また、膨大な量のクエリを漏れなく書き換えることも大変でした。

この問題についても、アクセスログを活用した取り組みを行いました。具体的には、BigQueryのアクセスログを使って、レガシー版にアクセスしている人を洗い出します。そして、まだレガシー版を使っている人に対しては、移行マニュアルを改めてお知らせし、新たな仕様への移行を促しました。この結果、最終的にはレガシー版の利用者が0になりました。」

ここからは、なぜこのデータパイプラインがレガシー化してしまったのか、永井氏の見解を説明していただきました。

なぜレガシー化が起きたのか

永井氏：「この図は、『技術の創造と設計』という本からの引用です。

会社内のある仕事を円で表現しており、その円の中をさまざまなチームが分担しています。若い組織の場合、各チームがそれぞれオーバーラップして、自分の役割以上のことをやって、お互いに自分の仕事だと思う領域があります。一方成熟した組織だと、チームとチームの間に隙間ができてしまって、どのチームもやらない仕事が出てきてしまいます。

まさしく、レガシー化したデータパイプラインの廃止は、エンジニアリングとデータ分析の2つのチームの間に落ちてしまった仕事でした。そして、両チームが横断して考える機会がなかったために、そのシステムが長い間残ってしまったのだと思いますす。

成熟した組織でチーム間に隙間が生まれる現象について、この本では『遠慮の塊』と表現されています。この現象はまさに、チームのコミットメントが弱くなって隙間ができるイメージです。一方、メルカリで起きていた事態については、その要因が若干異なると思います。」

チーム間で隙間ができる原因とは

永井氏：「（上記画像の）右下のグラフは、2015年〜2021年にかけてのメルカリの社員数の推移を示しています。このグラフからわかる通り、およそ5、6倍に増えています。

想像ですが、レガシーシステムができた2015年当時は、データの廃止も簡単だったと思います。データを使っている人を各自認識できており、その人に対してコミュニケーションをすれば済んでいたでしょう。

一方2021年では、社員数の増加にともない、自分の知らない人がしている業務が増えました。そのため、業務に深く依存しているデータを消す作業が、2015年とは比べ物にならないほど困難になったと思います。チーム間に隙間が空いて落ちてしまったのは、コミットメントが弱くなったというより、会社の拡大にともない未知の業務が出現し、それが隙間になったのでしょう。

ゆえに、この現象は会社のマインドなどと関係なく、事業の拡大にともなってどの会社でも起きうるのではないかと思います。」

チーム間の隙間をなくす打開策とは

永井氏：「チーム間の隙間をなくす理想的な流れとして、まず経営陣が組織の隙間を発見して必要性を認識するべきだと思います。そして、隙間を埋めるために計画的に新しいロールやチームを定義し、そのロールが果たせるような人を採用するのがよいでしょう。

しかし、実際にそういった流れで組織の隙間が埋まっていくケースは多いとは言えません。経営者も全知全能ではないため、事細かに隙間の発生を認識してフォローしていくのは、非常に困難なことだと思います。

そのため、誰かが役割を少し越境しないと問題が解決しない状況はよくあります。私としては、アナリストのポジションを少し越境して、システムのマイグレーションに着手したことで問題を解決しました。このように、誰かが意思を持って越境することが、この問題に対する解決策の1つだと思います。

ただし、この解決策については功罪があるため、ネガティブな面についても後ほど触れます。」

振り返って思うこと

永井氏：「このレガシーなnode.jsのフルスクラッチのデータパイプラインは、2024年現在から考えると、悪い意味で独特な構成です。しかし、作った当時の判断としては正しかったと個人的には思います。

メルカリでは、2014年10月に初めてフリマの利用者に手数料を課しました。つまり、2014年10月までは売上が立っていなかったはずで、事業は生きるか死ぬかの境目だったと思います。そのため、数年後にメンテナンスしやすいシステムを作ることより、明日生き残るために必要なデータを迅速に出すことが優先だったのでしょう。

ゆえに、当時のシステムがどのような構成であっても、『明日役に立つものを作った、当時の判断は正しかった』と肯定していきたいと思います。

実際このシステムも、メンテナンスがしっかり行われてるときは、非常に安定性が高かったと聞いています。構成は独特でしたが、クオリティが低かった訳では決してないということもお伝えしておきたいです。」

旧データパイプライン廃止プロジェクトのまとめ

永井氏：「今回の問題は、レガシー化したデータパイプラインが長く残ってしまったことです。しかし少し抽象化すると、組織が拡大していった時に隙間に落ちた課題とも言い換えられます。

メルカリは、明日の生き残りをかけたフェーズから、事業がある程度安定して成長していったフェーズに変化しました。この避けられない変化によって、組織に隙間が生まれるものなのかなと思いました。

それに対する自分の取り組みは、役割を越境して、隙間に落ちているものを拾うことです。具体的な取り組みとして、データとヒアリングによって現状を把握し、KPIの再定義によって技術的に無理がなくて業務上困らない仕様を実現しました。そしてこの状態において、モニタリングとマイグレーションを行っていきました。」

レガシー化したデータパイプライン廃止のその後

永井氏：「この取り組みは、チームとしての取り組みというより、限りなく私個人の取り組みでした。しかしその後は、アナリティクスエンジニアリングのチームが設立され、私もそのマネージメントを担当しました。」

つづいて、チーム立ち上げで取り組んだ2つ目のプロジェクトである、「ロードマップの作製とアライン」についてお話ししていただきました。

ロードマップとアラインの取り組みとは

永井氏：「まず、ロードマップのアラインとはどういった取り組みなのかご説明します。

チームが今後1年で取り組むテーマを、VP（役員）の方や横のチームのマネージャーにレビューしてもらいます。内容としては、アナリティクスエンジニアリングチームの今後1年の取り組みを1クォーターに1回程度レビューしてもらいます。その中で、優先度や施策の費用体効果について議論し、内容をブラッシュアップしていきます。

内容のブラッシュアップでは、『このプロジェクトは効果的ではないのではないか』といったフィードバックを反映させて、既存のプロジェクトを廃止したり新たなプロジェクトを追加したりします。

このようにして、チームが取り組む内容を変えていき、チームの方向性を横や上にアラインしていきます。」

ロードマップの例①

永井氏：「たとえば、ロードマップの中でチームの位置付けを行います。会社の中でデータ分析の仕事がレイヤーに分かれているため、担当領域のすり合わせを行ったり、とくに重視している施策やその理由、全体的な方向性を話し合ったりします。」

ロードマップの例②

永井氏：「この表は、列が各クォーター、行はクォーターごとのテーマであり、大まかなスケジュールを示しています。」

ロードマップの例③

永井氏：「また、個別のプロジェクトに対して議論を行うこともあります。前クォーターまでの取り組みの結果、どのような効果が得られたか定量的に振り返ったり、今後のプロジェクトの評価基準について話し合ったりします。

『今後、プロジェクトをどのような視点で評価するのか』は、『このプロジェクトへの投資で、どのようなリターンを得ようとしているのか』とイコールだと認識しています。そのため、この業務が話し合いの中でも、もっとも重要な部分だと思います。

ちなみに上記の左の画像は、ベーシックテーブルスと呼ばれている中間テーブルの開発プロジェクトについて描かれたものです。この中間テーブルを使うことで、今までより効率的に分析できることを証明する基準として、『SQLの記述量を半分以下に減らせる』定量目標について話し合っています。また『BigQueryユーザーのうち、このテーブルの利用者を約70%にする』定量目標についても話し合っています。」

なぜ話し合いが重要なのか

永井氏：「どうしてこのような話し合いが重要か、自身の反省も含めて振り返っていきます。一つの理由として、チームの取り組みの費用対効果の説明が非常に難しいからです。これは、アナリティクスエンジニアリングチーム全般に言えることです。

人件費やBigQueryのコストなど、チームの活動にかかる費用については、非常に定量的かつ明瞭にわかります。一方で、『どのような効果が社外まで波及できたか』『最終的な成果にどれくらい繋がってるのか』など、チームが行った結果については、見えにくいところが多いのです。

そのため、経営陣から見ると、アナリティクスエンジニアリングチームは、費用は明確なのに効果は見えにくい存在になってしまいがちです。ゆえに、どういった効果を目指していくのか、アラインしていくことが非常に重要だと思います。」

データ基盤の改善で「成果」を上げるためには

永井氏：「経営学者のピーター・ドラッカーは、『組織の中に成果は存在しない。すべての成果は外にある。』という言葉を残しています。

お客様へのより良いサービスの提供や事業としての収益性の向上は、すべて社内だけで完結するのではなく、社外で起きた変化の結果です。そのため社外に表れる結果こそが、企業としての最終的な成果なのです。

それに対して、直接サービスの作成・提供をするエンジニアやデザイナーがいます。その前段階には、作る内容を考えるプロダクトマネージャーがいて、そのプロダクトマネージャーの意志決定を支援しているデータアナリストがいます。そして、さらにその前段階として、データアナリストが分析をよりよくできるよう、データ基盤の改善が行われます。

このように、データ基盤の改善は、最終的な成果から非常に間接的な地点にいます。ゆえに、成果が非常に測りにくいのだと思います。もちろん、測りにくいことと成果が小さいことは別ですが、構造的に測りにくい業務なのです。」

失敗談

永井氏：「このような効果が見えにくいテーマに取り組んでる中で、本来であれば効果が定量的に見えにくいからこそ、定性的なコミュニケーションなどに注力していく必要があったのです。しかし実際は、ロードマップのアラインはここ1年くらいで始めた取り組みだったため、説明が難しく、経営陣とのコミュニケーションに消極的でした。

このようなコミュニケーションをしっかり重ねていかないと、『このチームに、人員を継続的に割り当てる必要があるだろうか？』という議論にも発展しかねません。説明が難しいからこそ、対面でしっかりとコミュニケーションを取っていくことが重要だと学びました。」

ここからは、ロードマップ作成と役割の越境について、2つのテーマを絡めてお話ししていただきました。

越境の功罪

永井氏：「最初に、越境には功罪があると話しました。たとえば良くない点として、『個人に依存した取り組みは持続性が弱い』点が挙げられます。

越境して問題を解決すること自体は、非常に尊い取り組みです。しかし、その越境した人の貢献が大きければ大きいほど、その人が抜けたときの穴も大きくなります。この問題については、現職に限らずさまざまな会社で遭遇しました。

『誰かが越境して問題を解決できたからよし』ではなく、その人が抜けたときの穴を埋める役割を確立する必要があります。そこで初めて組織としての成長になりますし、その状態を目指していくべきだと思います。」

役割の確立

永井氏：「では、組織としての役割の確立とは何でしょうか。

新しいチームができて組織図に名前が乗れば役割が確立するかというと、そうとも限らないと思います。

とくにアナリティクスエンジニアリングは、他の組織と協力しないと、社外まで届くような成果を出せません。成果物を他のチームに使ってもらったり、他のチームから期待されていることに答えたりすることで、社外の成果に繋がっていきます。そのため、他のチームやVPから役割を期待され、それに応えている状態が維持できて初めて役割が確立し、組織の穴も埋まった状態になるのです。

そう考えると、チームに期待していることやしていないことを聞いて、それを反映していく作業は、まさしくチームの役割を確立していく過程だと思います。ロードマップのアラインは手間のかかる作業ですが、この作業こそが、個人の越境ではなく組織として問題解決していく過程だと思います。実際私もこの3年間で、この過程をもっと重視すべきだったと感じています。」

さいごに、3つ目のテーマである、中間テーブルの開発事例についてお話ししていただきました。

データ基盤の課題ヒアリング

永井氏：「レガシー化したデータパイプラインを廃止できたため、次に解決すべき課題は何か探していました。そこで社内でヒアリングを実施した結果、テーブルが複雑でSQLを書くのが大変だという声が多かったため、それを解決するために中間テーブルの開発に着手しました。

ここでのポイントは、多くのチームに一度にヒアリングすることです。1チームだけにヒアリングしても、会社全体としての優先順位が高いのか低いのか分からないからです。

この時は、およそ18チームにヒアリングしました。このくらいの規模になると、一度に対処できないくらいの課題が集まります。そうすると、自然と優先順位をつけていく方向に議論が向かいます。」

集計を効率化する中間テーブル

永井氏：「ここからは、中間テーブルの開発について具体的にお話します。ここでもやはり、どのようなデータがよく使われているのか正確に把握することが重要です。（上記）スライドの左側に載せているグラフは、メルカリのテーブルごとの利用数の分布です。

ご覧の通り、非常にパレートの法則に近い分布になっています。矢印から上のテーブルはBigQueryユーザーの1割以上が使っているため、基本的にはこの中からどれを中間テーブル化すべきか考えていきました。

一方、『今はそれほど利用されていないが潜在的には重要なデータ』を、より分析しやすくする選択肢もありました。しかし、メルカリはBigQueryのユーザーが非常に多かったため、まずは顕在化しているニーズに対応していく方が重要だと判断しました。

テーブルを作る時、頻繁に使われているテーブルは、やはりビジネス上でもUX上でも重要なデータが多いなと感じました。

たとえばメルカリでいうと、出品された商品やその商品の購入などに関するデータは、非常に頻繁に分析されていました。おそらく他の会社でも、売上や取引、在庫、重要なコンバージョンなど、ビジネス上のマイルストーンに関係するデータが上位に来るのではないかと想像します。

さらに、出品や購入のテーブルと同じクエリでよく分析されてるテーブルについても一緒に調べてみました。その結果、たとえば購入テーブルとは、アイテムやユーザーの属性をセグメントに分けるために使うテーブルなどが一緒に使われていると分かりました。それらのテーブルはシンプルにジョインして、中間テーブル化していきました。

どのような中間テーブルにニーズがありそうなのかは、分析によってある程度当たりがつきます。そのため、事前に調査・分析をしておくことで、ポイントをおさえた改善ができると思います。」

スピードと堅牢さのバランス

永井氏：「中間テーブルの開発について、私が担当してた時はスピード感が少し足りなかったと反省しています。

メルカリの今までのデータ基盤は、『明日生き残れるか』視点で作られてたものが多かったため、メンテナンス性に難があると感じていました。ゆえに、品質重視で過剰に堅牢さを求めてしまい、時間がかかっていました。

SRE（Site Reliability Engineering）では、エラーバジェットと呼ばれる発想があります。これは、たとえば年間5件まではインシデントを許容し、そのインシデント件数に収まる範囲で、できるだけスピードを上げていく考え方です。

堅牢さとスピードを0/100で考えるのではなく、このエラーバジェットのように、スピード40、堅牢さ60と、バランスを考えながら進めていればよりよかったと思います。」

LT1「データドリブン組織の継続的拡大のためのヒント」

次に、株式会社ヤプリプロダクト開発本部データサイエンスグループマネージャー阿部氏より「データドリブン組織の継続的拡大のためのヒント」というテーマでお話しいただきました。

データドリブン組織とは

阿部氏：「まず、この発表のタイトルの定義についてご説明します。

（上記）スライドに載せている図は、『実践的データ基盤の処方箋』に掲載されている、データドリブン組織のイメージです。今回は、この図に相当する体制が構築されている組織を『データドリブン組織』と見なします。」

継続的拡大とは

阿部氏：「また、タイトルで用いている『継続的拡大』の言葉は、NECが2022年頃に出していたレポートの定義に則っています。これによると、データ活用のステージは、大きく分けて以下の5つに細分化されます。

個人の努力
プロジェクト単位の予算
部門レベルの予算
部門横断
全社的

この流れにおいて、より上のステージへの移行を目指していくことを継続的拡大とみなしていきます。

データドリブン組織の体制ができた段階でステージ3程度だと思います。今回の講義では、それをさらに部門横断、全社的に広げていくことを『データドリブン組織の継続的拡大』と定義します。」

はじめに、データ活用ステージとハードスキルについてお話ししていただきました。

ステージ4から急激に難易度が上がる

阿部氏：「5つのデータ活用のステージにおいて、ステージ4から急激に難易度が上がると思います。ステージ3まではデータ技術者の一般的なハードスキルがあれば到達しやすいと考えるからです。

具体的には、

BIツールを導入・運用する
マネタイズポイントに統計的なモデルを導入・運用する
安定してデータのアウトプットが得られるようにデータのデータ基盤を導入する

などが実施できれば、ステージ3までは比較的到達しやすいでしょう。

一方、ステージ4以降はそれだけは到達できないと思います。このほかに、

予算獲得のために、何らかのデータ戦略を策定する
部署をまたいで実行する
チームで成果を得て、さらに取り組みを継続する
これらのサイクルを改善していく

などが必要になると考えます。これらの実施は非常に難易度が高いため、業界の実態としては、ステージ3でマンネリ化したりステージ4にチャレンジして挫折したりするケースが多いと感じます。

その結果として、データ活用人材が転職してしまう可能性もあると考えます。」

ステージ４に到達するためには

阿部氏：「私が過去に所属していた企業でも、あくまで私個人の見解ですが、在籍中にはステージ4に到達できませんでした。しかし、現在所属しているヤプリにおいては、ステージ4以上に行けるのではないかと思っています。

この違いが何なのかについて、考察していきます。」

ここからは、ステージ4に行くことの難しさについてお話ししていただきました。

ステージ4以上の難易度は「期待値と不確実性の高さ」にある

阿部氏：「ステージ4以上の難易度は、期待値と不確実性の高さにあると思います。ステージ3までは基本的に自分の所属のみが担当領域であるため、比較的プロジェクトの成功度や確実性は見積りやすく、期待値も調整しやすいです。ゆえに、どのようにデータを料理していけばよいかが見定めやすいと思います。

一方、部門横断になると、自分の所属の担当外になり、不確実性も大きくなりやすいのです。予算も大きく、期待値も高くなりやすいため、難易度が上昇します。

さらに、各部署に必ずしもシニアメンバーがいるわけではないため、プロジェクトに関わるメンバーの育成も並行していくケースがあります。したがって、元々プロジェクトとして難しくなりやすいうえに、それに立ち向かう体制もハンデを負いやすいのです。」

ステージ4以上になるためのアクション

阿部氏：「業界として、ステージ4に到達するために、よく見聞きするアクションとして、4つを紹介します。

1つ目は、役員以上のトップ層の人たちと一緒に進めていくパターンです。これには、プロジェクトの推進自体をコントロールしやすいというメリットがあります。一方、データにはさまざまな利権が絡みやすいため、何らかの社内政治的な要因でうまくいかなかったり、高い期待値に答えていくのが大変だったりするデメリットもあります。

2つ目は、CDPなどの時流に乗ったデータ統合プロジェクトを始めていくパターンです。この場合、予算承認は得やすいですが、まずはデータの収集がゴールになってしまい、価値に結びつけにくいデメリットがあります。結局さまざまな利用が可能になったものの、それがエンドユーザーにどのように役に立つのかがわからず、壮大なおもちゃができあがってしまうリスクがあります。

3つ目は、ラボなどの研究開発機関を設立して、ムーンショットな計画に取り組んでいくパターンです。この方法は、現場の目標との乖離が生じ、協力関係を築きにくいデメリットがあると思います。

4つ目は、データの民主化を掲げ、ボトムアップでさまざまなプロジェクトを立ち上げるパターンです。この方法は、現場目線のデータ活用を推進しやすいメリットがありますが、時間がかかりやすい点と、関係者がスキルアップして転職されやすい点がデメリットです。

データ活用のステージを4以上に上げるためには、おもに以上の4つのアクションが取れると思います。

しかし、私も過去にいくつかのアクションに取り組みましたが、胸を張って言える成果はありませんでした。非常に多くの経験値が得らるとはいえ、職務経歴書で十分に語れるかというと難しいところです。」

つづいて、ステージ4に到達するためのヒントについて考察していただきました。

データ組織が実施していること

阿部氏：「Yappliのデータ組織の取り組みで中心となるのは、Yappliを導入してくださった顧客へのアナリティクスサービスの提供です。無償のサービスとしては、裏側の基盤を用意して管理画面のダッシュボードを提供したり、Yappli Analyticsと呼ばれる、分析ツールを提供したりしています。

またYappli Data Hubと呼ばれる有償サービスによって、アプリの生ログを顧客に提供して各種ツールに連携したり、カスタムダッシュボードのオプションご提供したりしています。

加えて、全社的なダッシュボード運用や、レポーティングも担当しております。

各種データは全てBigQueryに貯蓄してあり、それをLookerやLooker Studioで社員に提供しています。

これだけ聞くと、この時点で活用ステージ4に行っているのではないかと思う方もいらっしゃるかもしれません。しかし私としては、部署横断で直接的にビジネスに貢献できるよう、戦略的に活動できるようになって初めて、ステージ4だと考えています。」

部署横断のアクションでステージ4に

阿部氏：「現在、筋が良さそうな部署横断案件を数多くいただいています。

たとえば、以下のようなお話をいただいております。

管理画面のトップにスコアを表示し、それを基にお客さんにネクストアクションを提供する
POSデータを連携して機能や施策に活かす
アプリの管理画面やポータルサイトのログからお客様にお声がけするタイミングをSlackで通知させる

このような部署横断のアクションができると、ビジネスに直結するデータ活用となり、ステージ4に到達していると言えると思います。」

なぜうまくいったのか

阿部氏：「どうしてうまくいっているのかについて考察します。

まず、主要プロダクトの開発部にいた点が大きかったと思います。データのアウトプットをお客様に直接届けるポジションを確立しておくことが重要です。

主要プロダクトがSaaSだった点も、よかったと思います。データは継続的に活用するPDCAと相性がよいため、お客様と中長期的な関係を築けるとやりやすいでしょう。

データに関わる部門が1つだった点もよかったです。これにより、多様な相談を受けてそれらを統合したうえで、解決策を企画・提案できました。

弊社のプロダクト自体、データと親和性が高いですが、データを活用しなくても成長可能なプロダクトでした。そのため、データ活用すべきタイミングをうかがって、最初のうちはデータを仕込んでおくことが大切です。」

データ活用の流れ

阿部氏：「今の話をまとめると、プロダクト/サービスにデータのアウトプットを組み込んでお客さんに届け、そのフィードバックをカスタマーサクセス担当がデータ組織に反映させていく流れです。これにより、顧客からのフィードバックを基に、継続的に学習できる形になっています。

プロダクト/サービスに、どう落とし込んで価値にしていくかを主軸にするため、自然とデータドリブン組織としても拡大しやすかったと思います。」

データドリブン組織を支える技術の重要なポイント

阿部氏：「データドリブン組織を支える技術の重要なポイントとして、『サービス構造や組織的な力学を見抜いて、それをデータドリブン領域の拡大に自然と作用させる技術』があると考えます。

顧客に対して、どのようにユーザーに貢献できるのかを具体的に言えると、非常にスムーズに話が進むと感じています。」

データを軸に皆で感動したい

阿部氏：「正直、ステージ3まで引き上げる力があれば、データ活用人材としては十分に生き残れると思います。

ではなぜ部署横断で全社的に取り組むステージ4以降を目指すかというと、データを軸に皆で感動したいからです。また、『より良い体験をユーザーに届けたい』『価値貢献したい』思いがあるからです。」

LT2「GA technologiesの経営戦略から駆動するデータ基盤構築」

最後に、株式会社GA technologies 執行役員 CDO奥村氏よりGA technologiesの経営戦略から駆動するデータ基盤構築についてお話しいただきました。

GA Groupが取り組む社会課題

奥村氏：「私たちGAグループは、社会課題をリアル×テクノロジーの融合によって解決しようとしている団体です。

主力事業は、RENOSYと呼ばれる、不動産取引をインターネット上で行えるサービスです。」

不動産業界の課題と挑戦

奥村氏：「不動産取引はまだまだアナログな業界です。非効率な業務や非合理的な業務が未だに数多くありますし、それによってさまざまな顧客の悪い体験が引き起こされていると感じます。

この問題を社会課題だと深刻に認識し、メスを入れる形で取り組んでいます。幸い、2022年5月のデジタル改革関連法の成立により、ネット不動産が勢いを増しています。」

本講演のテーマ

奥村氏：「本日お話ししたいのは、意味や価値のあるデータ施策は、どのようにしたら進むのか？という点です。

データの施策として、たとえば、機械学習でレコメンドを作ったり、データ分析をしたり、データカタログを入れたりといったことがあります。今回は、そういった施策を『どのように意味がある形、価値のある形に進めていけばよいのか』ついて深く考えていきます。」

過去にデータ分析を進めるうえで悩んだこと

奥村氏：「おそらくアナリストの方々は、このような流れで動いているでしょう。

ビジネス課題に対して問いを設定
仮説を立てる
分析を行う
レポーティングする
実際施策の実行まで伴走する

併せて、データウェアハウスの整備やデータ民主化など、分析活動自体の効率化や標準化も行います。

私はキャリアのスタート時に、さまざまな活動の中で、何を優先的に進めればもっとも事業に貢献できるのか、非常に悩んでいました。実際の工数では、全ての分析ニーズを満たせません。また、RICEのようなフレームワークもありますが、使いこなすには経験値が必要で、当時はうまく使えていませんでした。

さらに、ビジネス貢献をどのように説明するかも悩みの種でした。自分たちのチームが行っている分析活動がどれだけ会社に役に立っているかは、お金の単位で換算しづらいためです。

これにより、データを整備するプロジェクトなどの間接効果のある施策や、中長期的にやるべき施策を後回しにしてしまうケースはありがちだと思います。」

当時のアプロ―チ

奥村氏：「当時私がとったアプローチは非常に愚直でした。

まず、アナリストの立場を越境し、ゲームデザイナーやPDMなどのビジネスを考える側に回りました。先ほど永井さんは、越境には功罪あるとおっしゃっていましたが、実際越境してみると、『このデータがあればいいな』や『こういう分析があったら意思決定ができるな』といった気づきがでてきます。そういった観点をアナリストが内面化することによって、アナリストが作る優先度が現場の納得感と一致していきました。

また、多くの会社で行われているように、信頼関係を築きました。たとえば、管理会計（FP＆A）からデータが入り始めて、経営陣の信頼を得たうえで、中長期的な施策を行いやすくするアプローチがあります。」

似たような話題はデータマネジメントにもある

奥村氏：「似たような話題は、データマネージメントの領域でもあると考えています。

私自身も、前職でデータ基盤をリプレイスしましたが、非常にコストがかかりました。ツールの導入やストレージの追加で大きな予算を使うため、どうしても経営陣からはコストセンターとして見られてしまいます。

また、データマネージメントは縁の下の力持ちのような活動が多いです。そういった活動のメリットを論理的に説明し、上層部に伝えていくことは苦心しやすいです。

最近では、データ基盤の改善をどこまでやるべきかについても悩んでいます。さまざまな他社の事例を聞いていると、あれもこれもやりたくなってしまいます。ただ、データ施策は事業のフェーズや組織、規模によって価値が変わるため、適切なスコープやロードマップを正しく判断することは難しいと感じます。」

経営陣への説明の具体例

奥村氏：「実際に調べてみると、さまざまな経営陣への説明の仕方が存在します。よくある例として、データの施策によって実現した売上やコストカット、顧客体験の向上などを説明する方法があります。

実際には、これらのさまざまな材料のハイブリッドによって、もっとも効果的なパッケージを経営陣に対して説明していくことが重要だと思います。」

そもそもデータ施策はどこに紐づくべきなのか

奥村氏：「ここで改めて初心に立ち戻って、そもそもデータの施策はどのような数字を上げたり、どのような活動に対してアラインしなくてはいけないのか、考え直してみます。

スライドに掲載している本は、『三位一体の経営』という私が好きな経営本です。この本では、経営のスタイルには、大きく分けて3パターン存在すると述べられています。

1つ目に紹介されてるのは、『額の経営』と呼ばれるものです。額の経営では、売上やGMVなどの利益をとにかく大きくしていきます。データ活用でいうと、データ分析や機械学習によって、売上のアップサイドを作る活動を優先的にこなしていくイメージです。

2つ目は、『率の経営』と呼ばれるものです。率の経営では、営業利益率や活動の質を優先的に改善していきます。データ活用でいうと、オペレーション効率化によって、次々とコストカットしていく活動です。

そしてこの本では、最終的に『福利の経営』を目指すべきだと述べられています。福利の経営では、ROEやROICなどの指標をとにかく追求していく活動です。

データ活用に置き換えると、以下のようなサイクルが循環すると考えます。

会社がデータに対して投資する
さまざまな物事が効率化される
お客様の基盤が拡大していく
利益という形で会社に戻ってくる

このサイクルが継続的に回ることによって、競合他社に対して強い障壁を作れると感じています。」

データ活用のあるべき姿

奥村氏：「本来会社として目指すべき方向に対して、データ施策をどのようにアラインしていくのかを考える必要があります。その解決策として、上記スライドのようなピラミッドを用意しました。

データが会社にあると、そのデータを用いてAIなどの技術が作れそうだと感じるでしょう。しかし、そういったデータ活用戦略、出口の戦略の下には、データという資産を維持管理するためのデータマネージメント戦略があるべきです。

さらにその手前には、現在会社にはないが将来的に獲得するべきデータを取得する、M&Aを含む戦略があるべきです。そして、それらすべての戦略は経営戦略が土台になっています。

私のキャリアは、このピラミッドを上から下に下っていきましたが、作る方向は逆からの方がよいと思います。そのため、現在の私のCDOの立場として、当然経営戦略を作りますし、同時に一気通貫でデータ活用戦略まで作り切ることにチャレンジしています。」

ここからは、データエンジニアの常住氏より、具体的なデータ基盤プロジェクトについて説明していただきました。

データマネジメントのあゆみ

常住氏：「2020年頃、データマネジメントチームが立ち上がり、最初はデータの民主化をメインに取り組んでいました。2023年には、新しいデータ基盤を構築する構想を検討しはじめました。そして、2024年にData本部が立ち上がり、新データ基盤の構築を開始しました。」

これからのデータ基盤

常住氏：「これからのデータ基盤には、データの入口であるデータソースの増加に呼応して、出口も広がっていくプロセスを支えられる状態が求められます。」

スケーラビリティとガバナンスが両立するデータ基盤

常住氏：「求められるデータ基盤を実現するためには、スケーラビリティとガバナンスが両立しているデータ基盤の構築が大切だと考えます。

データソースが拡大していく中でも、具体的に以下のような統制が取れている必要があります。

見せてはいけないデータは見せないようにする
取り込みのエラーなどが起こった時は、きちんと検知できる
KPIは統一した定義で見られる

これらの点が実現できるよう、複数の製品群を組み合わせて、新たなデータ基盤を作ろうと動いています。」

データマネジメントチームとしてのチャレンジ

常住氏：「今年の目標は、“テック企業のデータ基盤”としてスタートラインに立つことです。具体的には、以下の取り組みにチャレンジします。

新しいデータ基盤を作り切る
既存のデータ処理の品質を向上させる
現在のデータマネジメント体制を強化する

翌年（2025年）以降は、データ基盤からのさらなる価値創出に挑戦していきたいと思っています。データチームだけではなくビジネスユーザーにも、データ基盤を使ってもらおうと考えています。

さいごに、これまでのお話をまとめていただきました。

GA technologiesの課題への向き合い方

常住氏：「今回、各組織においてデータ利活用の専門家がどういった課題に取り組んでいるのかがテーマでした。弊社としては、『意味や価値のあるデータ施策は、どのようにしたら進むのか』の課題に対して、『データ活用の経営戦略への紐づけ』と『データ基盤の構築』の掛け合わせで向き合っています。

ただ、課題解決にはもう1つの要素が必要であると考えています。データ活用を経営戦略に紐づけ、それを実現できる基盤を作った先には、『データ基盤を進化させ続ける』取り組みが必要だと思っています。」

データ基盤は常に進化が求められる

常住氏：「存在している経営戦略やデータ基盤は、常に変化するものだと認識しています。

たとえば弊社では、先日、中期経営計画を発表いたしました。この計画は2026年への目線になっており、すでに2年後のビジョンがあります。

そのため、スタートラインにのせた基盤には、すぐに進化が求められるのです。」

3つ目の要素を満たすためには

常住氏：「意義のあるデータ施策で続けるためには、経営戦略に紐づいたデータ活用、それを実現できるデータ基盤、そしてデータ基盤を進化させ続けるためのデータマネジメントを先陣で行うチームが必要だと考えます。そしてこの取り組みにより、3つ目の要素が満たされていくのだと思っています。」

過去のData Engineering Studyのアーカイブ動画

Data Engineering Studyはデータエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。

当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。

過去のアーカイブもYouTube上にございます。興味をお持ちの方はぜひご覧ください。https://www.youtube.com/@dataengineeringstudy6866/featured

TROCCO®は、ETL/データ転送・データマート生成・ジョブ管理・データガバナンスなどのデータエンジニアリング領域をカバーした、分析基盤構築・運用の支援SaaSです。データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご請求ください。