第2回勉強会「Data Engineering Study #2」では「データ収集基盤」について学びました。
データ分析基盤は、作ったらそこで終わりではありません。基盤を作り上げたあとは、頑張って貯めたログをビジネスに活用したり、基盤を利用する社内ユーザーを育成する「啓蒙」フェーズが始まります。むしろ作ってからが始まりなのです。
第3回目の今回は、分析基盤を上手く組織に浸透させる方法について、基調講演ではData Pipeline Casual Talkの主催者である伊藤氏に水先案内人を務めていただきます。
そして事例講演では、0→10の立ち上げフェーズの事例としてエウレカ鉄本氏、10→100の拡大フェーズの事例としてDeNA長谷川氏を迎え、各社の具体的な事例から学びます。
当日のセッション内容はこちらのYouTubeでご覧ください。
基調講演「データ分析基盤の浸透に必要なこと」
データの処理工程であるパイプラインの技術情報や活用をカジュアルに話す会である「Data Pipeline Casual Talk」の主催者、伊藤 徹郎 氏（@tetsuroito ）。
同氏は教育業界のICT活用を支援している株式会社Classi株式会社にて、データアナリティクスを行なっています。今回は、データ分析基盤が組織に浸透した状態の定義と、データ分析基盤を組織に浸透させるために必要なことについてお話いただきました。
なぜデータ分析基盤は使われなくなるのか
過去のイベントで語られた「最初に描いた基盤は、おそらく使われない」という経験は、データ分析基盤に携わったことがある人は必ず通る道です。苦労して基盤を作ったのに利用されないことは徒労感があります。一所懸命に作ったダッシュボードも利用されたのは最初の1週間だけで、悲しいデータを眺めながら虚無を感じることも。
この原因について伊藤氏は、いくつかの例を挙げています。
伊藤氏：「まず1つが、開発者が考えるデータ分析基盤が、現場のニーズに合っていないこと。『ビジネスバリュープロセス』と呼ばれる、顧客へ価値を届ける業務プロセスにおいて、データ活用が組み込まれていないことも要因に挙げられます。
他にも、データ基盤の運用品質が低くいことで、求められるタイミングに求められるデータを提供することができず、ユーザー側の信頼を失い、段々と自分たちが作ったデータ基盤が使われなくなっていくこともあります。
データ分析基盤を組織に浸透させる『銀の弾丸』はないと、私は断言します」
データ分析基盤が浸透した状態とは？その定義を考える
組織にデータ分析基盤が浸透した状態をどのように定義すべきなのでしょうか。そもそも定義がなされていないという場合も珍しくありません。
伊藤氏が考える基盤が組織に浸透するために必要なものとして、「戦略」と「データマネジメント」の2つを紹介しました。
伊藤氏：まずは『戦略』について。この構成要素は、『診断』『基本方針』『行動』の3つに分解されます。
診断：
取り組むべき課題を見極めること。利用状況のKPIを定量的に持つことから始めます。組織の担当者や担当部署にヒアリングし、定性的な情報も含めて今の組織の情報、データ利用状況を診断していきましょう。
基本方針：
次に、診断で見つかった課題に対する総合的な方針を示します。ビジネスをする上で、顧客への還元価値を最大化していくことが、1つのビジネス目標です。その価値を提供するものにデータを活用することによって、その価値をより最大化できるようなユースケースというのを特定していきます。
行動：
基本方針を実行するために、一貫した行動をとることです。データ分析基盤のチームの業務では、多くのユースケースが出てくるとさまざまなビューが作られ、そこにビジネスロジックを組み込んでいくことになると思っています。その中で必要な処理を共通化していくために、モデル部分をメンテしていくことが重要だと思います。
伊藤氏：次に『データマネジメント』について。このDAMAフレームワークにそれぞれの要素を入れられています。
データ分析基盤を浸透させていくには？
データ活用が業務フローにも組み込まれ、きちんとサイクルを回していくためにデータ基盤のマネジメントが機能する状態になるには、現場からのボトムアップだけでは限界であり、トップの協力も必要不可欠だと、伊藤氏は強調します。
伊藤氏：経営戦略論の学者であるヘンリー・ミンツバーグ氏が提唱する『創発戦略』という考え方をご紹介します。これはトップダウンとボトムアップのぶつかり合う場所こそが、企業戦略にとって重要であるというもの。
現場だけでなく、トップもデータを活用していくことが重要だと発信をしなければなりませんし、そうしたビジョンを掲げていくことによって、評価体系や目標設定にも反映されます。そうすると、現場もデータを活用するために動きやすくなるので、業務フローの提案もしやすくなったり、施策の立案を行いやすかったりと、データ活用が組織に浸透していくのではないでしょうか。
事例紹介1「Data Platform 運用推進事例とこれから」
恋活・婚活マッチングアプリ「Pairs」を開発・運営する株式会社エウレカでBI（Business Intelligence）の責任者を務める鉄本 環 氏（@tamaki0506） から、同社で進めたデータプラットフォーム構築プロジェクトの概要と、その後の運用フェーズでの事例を紹介いただきました。最後には、今後データプラットフォームをどうしていきたいかというお話についてもお話いただきました。
エウレカのデータプラットフォームの立ち位置と設計
エウレカのBIチームは、ファイナンスやマーケットといった投資判断や予測をする部分や、プロダクト施策の検証、評価のデータ活用に関わっています。組織全体で幅広く、かつ高度なデータ活用が期待されているチームであるそうです。
鉄本氏：データプラットフォームには、過去の意思決定を蓄積しており、意思決定の効率化に関わっています。アナリストは分析作業の効率化に時間を使い、新たな意思決定のデータの材料を用意し、知見を得ている、このようなエコシステムを理想としています。
続いて、エウレカのデータプラットフォーム全体構成について。Google CloudComposerをETL部分に組み込み、データウェアハウス、データマート層を構築しています。以前はデータベースから直接分析をしている状態だったといいます。
鉄本氏：構築する際にはプロジェクトとして立ち上がり、BIチームのアナリストを中心にメンバーをアサインして立ちあげました。ベースが作れたことでプロジェクトは3ヶ月ぐらいで解散し、その後はコミュニティ活動として、アナリストが兼任して有志で運用するという形に移っています。
データプラットフォーム運用の成功事例
続いて鉄本氏はデータプラットフォーム運用の成功事例を紹介しました。会議形式でデータプラットフォームを活用しそうなターゲットを絞り、使い方を教えていたそうです。
鉄本氏：自発的にレクチャー会を会社全体に開催してくれる人も現れました。データ基盤を作っている人だけがやるレクチャー会よりも、データプラットフォームを使っている人がやってくれることで、利用者目線のメリットやポイントがカバーされたことで浸透が進んだなと。
鉄本氏：ただ、その一方で、課題もあります。
DWH、データマートが拡充され続け、組織で使っていく人も増え続けていくという未来を描いていましたが、現在は一部にとどまってしまっています。原因としては、やっぱり有志による改善運用は限界があるということ。
兼任でやっているので、片手間でやる状態になってしまい、元々プロジェクトとしてやっていたものがデータエンジニアの仕事と思われてしまい、なかなかアナリストの方でデータウエアハウス、データマートを作ろうという意識が生まれませんでした。
技術的なハードルが高いことも原因の1つ。組織的にも、データプラットフォームにリソースを投資し続けるという価値があまり実感できていないことも要因です。
データプラットフォームの改善と浸透のために
こうした課題に対して、データプラットフォームの改善にどのような取り組みをしているのでしょうか。鉄本氏はまず、データプラットフォームプロジェクトの進め方自体を仕切り直したそうです。
鉄本氏：チーム内とチーム外で浸透の対象を切り分けました。BIチーム内に対しては、コミュニティの活動をデータエンジニアとして行うために、業務を再定義しました。その上で、アナリストの業務プロセスを見直し、DWH、データマートの拡充というのを業務の一環として組み込めるように整理し直しています。
チーム外に関しては、これまで作ってきた成果物をレポートという形で価値の最大化できることにフォーカスを置いています。実際に使ってもらったフィードバックをもらい、UXを改善したり、どうやって使えばいいのかという教育を戦略的にやっていこうと切り替えています。具体的に、アナリストの業務プロセスがどういうふうに変わったかが以下の図です。
鉄本氏：今までデータエンジニアがやっていたDWH、データマートを作る業務をアナリストの方に移動させたことで、データエンジニアはアナリストの活動がもっと簡単になるような部分に集中できるようにしました。成果物自体は、やはり接触頻度が高いものから展開していくというのが、運用の入り口としてはよいかなと思います。
データプラットフォームが担う役割は、データ戦略にも及んでいく
最後に、鉄本氏からはデータプラットフォームを今後どうしていきたいかについて語られました。
鉄本氏：データプラットフォームが担う役割を、今後データの文脈でAIにも広げていきたいなと思っています。今までBIチームの意思決定をサポートしていたんですけれども、やっぱりオンライン・デーティングで価値を出していくために、アルゴリズムを強化していくところでデータプラットフォームの活用を広げていきたいなと思っています。
これからは組織の浸透だけでなく、データプラットフォーム活用を最大化していくというところに、新しいチャレンジをしていきます。
事例紹介2「分析基盤と組織のあり方 DeNAの事例」
株式会社DeNAで分析基盤の企画、構築、運用に従事している長谷川 了示 氏（@haseritchie ）からは、「分析基盤を浸透させていく上で、分析基盤を担う組織（分析基盤組織）がどのように形を変えていったか」について紹介されました。同社の事例からは、組織設計の参考となるノウハウが多数紹介されました。
事業別か、機能別か？多角化経営を進めるDeNAの組織形態
ゲーム事業やスポーツ事業など、M&Aを通して事業の多角化を進めているDeNA。
一般的に多角化経営を行なっている企業の組織形態は以下の3つに分かれています。
- 事業部制組織：事業ドメイン毎に組織を分ける。関係者間で目標や情報を共有しやすく、素早い意思決定が可能
- 機能別組織：業務の専門性ごとに組織を分ける。人材の取り合いが起こらず、効率的なリソース配分と人材育成ができる
- マトリクス組織：１人の社員が複数のミッションに取り組む組織。指揮系統が重なるため、現場に混乱が生じやすい
では実際に、DeNAではどのような組織形態を採用しているのでしょうか。
長谷川氏：DeNAでは、事業部制と機能別のハイブリッドの組織形態であると言えます。4つの事業本部を機能別の組織が支えているという形です。その中で分析基盤組織がどのような変遷を経たのか。最初に立ち上がった際は、経営事業部の中の1つの分析組織として発足し、そこから分析基盤を担う部分だけが機能別組織として分離し、全社の分析基盤を支えるようになりました。
急成長するゲーム事業の中から生まれたデータ分析基盤
分析基盤の組織がどのような歴史を経てきたのだろうか。この組織が立ち上がる前から、データを元にサービスを改善する文化は存在していたそうです。
長谷川氏：2010年に『怪盗ロワイヤル』に代表されるモバイルゲームが大ヒットし、ゲーム事業が急成長しました。事業の急成長に伴い、データを分析することによるサービス改善効果も飛躍的に大きくなったのです。
そこでデータ分析にどんどん投資をしていこうという判断になり、ゲーム事業の中でアナリストと分析基盤エンジニアが一体となった組織が立ち上がり、大規模な分析ができる基盤ができあがりました。
この時点で、オンプレミスでのHadoopの運用を開始しています。どんどんゲームのデータが格納されるようになる中で、その分析基盤を更なる高度化とゲーム以外の事業にも展開していくため、組織を再編し、機能別組織として全社共通の部門になったのです。
さらに、その中で分析基盤のチームをさらに機能別グループに編成し、機能に特化させることで基盤の高度化を実現しました。
「分析基盤」と「分析基盤組織」、並行して取り組む改革とは
DeNAでは現在進行系で、「分析基盤」と「分析基盤組織」の大きな改革に並行して取り組んでいるそうです。どの背景にはどのような課題があるのでしょうか。「分析基盤の刷新」においては、データの利用部門が広がったことで、事業や技術環境が変化したことに伴い、これまで構築してきた分析基盤が事業の要件を満たせなくなってきたという事情があると長谷川 氏は言います。
長谷川氏：近年マシンラーニングやAIを含めた、より高度な取り組みを推進していきたい要請が、現場と経営の双方から届いていました。一方でその当時の分析基盤は、さまざまな事業と利用者が1つの環境に同居しており、システムリソースを共有する設計になっている、いわばマルチテナント的な形でした。
このため、スピーディーに改善しようとしても影響範囲が大きく、特定の事業に合わせて環境をカスタマイズすることも難しいという課題がありました。そこで今進めていますのが、『パブリッククラウド』です。これを採用することで、サービスごとに環境をきっちり分離したり、あるいは1つのサービスの中でもワークフローごとにリソースを分離するといったことが実現できます。
もう1つの大きな改革というのが、「分析基盤の組織の刷新」です。この課題の背景にあるのが、分析基盤の組織と事業部組織の距離感を感じるようになったことだ長谷川 氏は説明しています。
長谷川氏：機能別組織の特徴として、どうしても事業部側と目標や前提を共有しづらいというデメリットがあります。中でもコミュニケーションコストの上昇が目立ってきました。分析基盤のエンジニア側にも、モチベーションを保つ上で自分たちの貢献が若干把握しにくくなるという負の影響がありました。
この要因として、基盤が完成して運用フェーズに入ってきた際、過度な機能分化がフィットしなくなってきたのではないかと考えたのです。また、今までアナリストと分析基盤エンジニアでコミュニケーションを取っていたところに、さらにデータエンジニアが入ってきたことで、3者間で情報共有になってしまいました。その結果、データエンジニアと分析基盤エンジニアで、業務が重なる部分がどうしても発生していました。
そこでゲーム事業部のデータエンジニアと分析基盤グループを統合し、全社共通の組織として再編したのです。全社共通組織の形を取りつつ、機能別組織の中では目的別に再編しています。
事業部別か、機能別か。自社の分析基盤の状況に応じて模索すべき
長谷川氏：「分析基盤の組織形態を考える上で、事業部別とすべきか、機能別とすべきかはよく論点になることです。どちらが正解ということはなく、自社と自社の分析基盤の状況に応じて、常に最適な組織形態で模索していくべきです。
DeNAの場合、最初の立ち上げは急成長中のゲーム事業部の中で立ち上げたあとに、全社共通の機能別組織として更なる高度化と全社展開を進めています。そこに最新のクラウド技術を取り入れて、分析基盤を刷新することと並行して、より事業推進やデータ活用面に活動をシフトさせようとしています。DeNAの事例が少しでも参考になれば嬉しいです」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw
trocco®は、ETL/データ転送・データマート生成・ジョブ管理・データガバナンスなどのデータエンジニアリング領域をカバーした、分析基盤構築・運用の支援SaaSです。データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご請求ください。
