いかにデータ基盤を活用するか？ 組織全体でデータドリブン文化を作り上げるためのスモールステップ：開発現場に“データ文化”を浸透させる「データ基盤」大解剖（終）（1/3 ページ）

「ゼクシィ縁結び・恋結び」の開発現場において、筆者が実際に行ったことを題材として、「データ基盤」の構築事例を紹介する連載。最終回は、「データ活用文化を、どのように組織に装着するか」についてお伝えします。

[横山翔，リクルートテクノロジーズ]

　「使われるデータ基盤」を構築するために筆者が取り組んだ試行錯誤を紹介する本連載『開発現場に“データ文化”を浸透させる「データ基盤」大解剖』。これまで、データ基盤構築の背景（第1回）、システム設計（第2回）、開発プロセス（第3回）について解説してきました。最後となる今回は「データ活用文化を、どのように組織に装着するか」についてお伝えします。

　なお、技術要素やツールとしてはJupyter NotebookやBigQuery、SlackやGitHubを扱いますが、他の手段でも代替可能な内容です。細部にとらわれずにご自身の担当する業務や組織に当てはめながら読んでいただければと思います。

データ駆動組織への招待

　連載第3回（開発プロセス）でお伝えしたように、筆者が担当する現場では、ビジネス部門が参照しているExcelシートの主要データ項目を、BigQueryに置き換える形でデータ基盤を構築しました。

　それまでは、下記のようにエンジニアが気軽にデータを見られない状況でした。

• 過去データが蓄積されているため、重いファイルを開くだけでも時間がかかった
• 関数やセルが多重参照されており、データ加工処理の調査や解釈が困難だった
• エンジニア部門で使われているmacOSでは開けないことがあった

　Excelというツールの良しあしを伝えたいのではありません。あくまでもExcelシートは特定の部署が使う「View」の一つでしかないはずです。部署や役割が異なれば、適切なViewも変わるはずです。にもかかわらず、1つのViewにマスターとなるデータや集計ロジックがあることが問題なのです。連載第2回（システム設計）でお伝えした通りです。

　結果としてアーキテクチャが限界を迎えてしまい、連載第1回（背景）でお伝えしたように、ソフトウェアエンジニアはデータ仕様を調査するために工数を費やすことになってしまいました。

　データ基盤の構築によってViewとModelを分離することで、なるべく特定のツールに依存せずデータを活用できる状態になりました。

　組織としてデータを活用していくためには、2つの要素が必要だと筆者は考えます。

　1つ目は上記で説明したように、テクノロジー観点での環境整備です。データ自体が使える状態になっていなければ、データ活用は実現できません。

　2つ目は、文化・プロセス観点での環境整備です。システムを用意してようやくスタート地点です。データを生かした製品開発を通して、最終的には世の中に顧客価値を提供することになります。そこで、次はデータ駆動組織へとシフトさせていくための取り組みをお伝えしていきます。

※なお取り組みの初期では、ソフトウェアエンジニアのみを対象としていましたが、現在では部署や役割にとらわれず多くの関係者がデータ基盤を活用しています。筆者の担当現場では、今回紹介する施策の延長上でデータの民主化を推し進めることができているので、他部署展開の観点でも、ぜひ参考にしていただければと思います。

Measure（計測）から始める

　筆者の担当現場ではプロダクトにおける仮説検証の枠組みとして、「Build」（構築）、「Measure」（計測）、「Learn」（学習）のサイクルを繰り返すという考え方を参考にしています。製品開発チームとしてBuildはできているが、MeasureとLearnは「できている」とは言い難い状況でした。

　今回は組織文化をボトムアップで変えていくためにMeasureから切り込みました。有志で集まり、施策の結果をデータで分析するところから始めました。以下のようなものが代表例です。

・ユーザー観点：どれだけ多くのユーザーが新機能を使ったのか

　ある程度の利用率を達成しているのであれば、ユーザーがプロダクトに対して抱いている期待に応えたといえるでしょう。

・ビジネス観点：登録数や売上といったビジネスKPIはどの程度向上したのか。また、副作用は発生していないか

　ある機能を押し出せば、その分だけ別の機能が使われなくなる可能性があります。

計測の具体的な進め方

　具体的な進め方としては、以下のような形で実施しました。

1. 分析要件の洗い出し

　まずはホワイトボードに分析要件を書き出します。その際、カスタマーの行動遷移をベースにして指標の関係に注目します。アプリの利用を促進する施策の場合、ログイン率が向上し、その分だけアクションが向上し、結果として売上換算でXX円のビジネス価値を創出した、といった形で効果測定ができます。

2. データ分析

　Jupyter NotebookでBigQuery（構築したデータ基盤）からデータを取得し、要件を満たすようにデータ分析を行います。Jupyter Notebookの.ipynbファイルは内部的にはjson形式のテキストなので、分析の履歴をGitでバージョン管理することが可能です。

3. 分析結果の共有

　分析結果をステークホルダーに共有して、次の意思決定に活用します。Jupyter Notebookによるデータ可視化がそのまま使えます。ミーティングの場で関係者にGitHubのプレビューを見せたり、画面のキャプチャーをSlackに貼り付けてレポートしたりといった形で、スピード重視の運用で済ませてしまうことも多々あります。

良かった点と課題

　このような形で、有志のメンバーでMeasure（案件の効果測定）に切り込みました。

　良かった点としては、開発担当がビジネス視点で語れるようになったことです。自分の仕事がビジネスにどのようなインパクトを与えたのかを、定量的に言えるようになりました。「Xカ月を費やした担当案件で、年間XX円の売上効果を生み出した」とエンジニア自身が胸を張って言えるようになったのです。

　一方で、課題もあります。チームに大きな改善余地があることが顕在化されました。効果測定に着手したところ、開発メンバーが自分の理解不足に気付く場面が見受けられました。

• フロントエンド寄りのメンバーが複雑なSQLを書くのに手間取る
• 自分が担当していない実装箇所だと、「データの中身がどうなるのか」の仕様を知らない
• 細かく分析するために本当は必要だったログ要件が漏れている
• そもそもビジネスKPIの構造を十分に把握できていない

　きちんと効果を測定するために必要な“当たり前”ができていなかったのです。

　これらの課題は、個人学習によって補ったり、詳しい人が勉強会を開催したり、要件定義フォーマットを修正するといった形で、一つ一つ解決していきました。データ分析に限らない話ですが、個人やチームが課題の可視化、改善のサイクルを継続的に回せるからこそ、新しい取り組みがうまくいくのだと思います。

　効果測定に慣れてくると、今度は「さらに数字を伸ばすにはどうすればいいか」という観点で振り返るようになり、エンジニアが起案を始めました。「言われたものを作るだけ」という“Build重視の思考”からの脱却です。プロダクト志向チームへの第一歩でした。

　とはいえ、企画の素人の起案がいきなり通るわけではありません。ビジネス部門と壁打ちを繰り返したり、社外勉強会で知り合った他社エンジニアからサービス運営の参考事例を教わったり、社内の他部署が抱える問題意識をヒアリングしたり、データを基に効果を見立てたり、サンプル実装を提示したりと、さまざまな試行錯誤を重ねて、ようやくチーフプロデューサーからGoサインが出るようになりました。