創業時より取り組むデジタルメディア事業を軸に、デジタル集客支援事業や新規事業を展開する株式会社キュービック（以下、キュービック社）。同社が自社開発したデータ分析基盤が50以上ものデジタルメディアの運営を支えていたものの、システムの老朽化によってさまざまな課題が発生していました。データ分析基盤の刷新はどのように進められ、どのような成果を得ることができたのか、リアルなお話を伺いました。

また、これまで国内で多くのスタートアップから大手企業を支えてきたアマゾン ウェブ サービス ジャパン合同会社（以下、AWS社）からは、データ分析基盤の刷新を決断する企業が抱えている課題や、経営層の理解を得るためのフレームワークなど、過去の支援実績から広い視野で語っていただきました。

登壇者紹介

尾﨑 勇太 氏

株式会社キュービック
テクノロジーエキスパートセンター Tech Lead

福家 哲郎 氏

アマゾン ウェブ サービス ジャパン合同会社
パートナーアライアンス統括本部 ISVパートナー本部
Senior Partner Development Manager, Startups

中村 祐太

株式会社primeNumber
カスタマーサクセス本部
Head of Customer Success

シンプルなビジネスモデルだからこそ、日々の施策のPDCAをスピーディに回す必要があった

累計50を超えるデジタルメディアを運用しており、「ヒト」基点のマーケティングとデザインを武器に3桁億円の売上で推移するなど、デジタルメディア業界のトップランナーとして成長を続ける株式会社キュービック。

データエンジニアである尾﨑 勇太氏は2020年11月に同社へ入社し、新規プロダクトを立ち上げたのち、経営課題の解決に携わるようになったとのこと。直近ではデータ分析基盤のリプレイスや、データ活用の推進に取り組んでいます。同社のビジネスモデルにおけるデータ活用の必要性について、セッション冒頭にお話しいただきました。

「弊社のビジネスモデルは非常にシンプルです。自社で運営しているメディアに訪問したユーザーをクライアントのWebサイトへ送客し、そのユーザーが商品やサービスを購入、登録することで、成果報酬をクライアントから受け取っています。

ただ、シンプルではありつつも、実際に送客したユーザーが成果につながるかどうかは不確実性が高いため、データを活用することによって売上の着地見込みを正確に把握することが施策のPDCAを回していく上での鍵となります」（尾﨑氏）

データ活用に重きを置く同社では、独自のデータ分析基盤であるCUEBiC Analyticsを構築、活用することでデジタルメディアへの訪客層を分析し、SEOや広告運用の改善を高速化しています。このCUEBiC Analyticsによって、広告媒体やアフィリエイトサービスプロバイダから収集した運用実績レポートを集計し、BIツールのTableau上に表示、メディアの運用担当者がフォーキャストを分析できる環境を作り上げています。

既存のデータ分析基盤が老朽化し、事業成長に耐えられなくなったことでリニューアルを検討

キュービック社では2021年、さらなる事業成長に耐えうる全社的なDX戦略として「中長期IT戦略」を策定、その一環としてデータウェアハウスの刷新が決定されました。このプロジェクトでデータ分析基盤の構築を担当した尾﨑氏が、当時抱えていた課題を振り返ります。

「2021年当時のCUEBiC Analyticsは老朽化していました。正確な売上の着地見込みを把握するという当初のビジネス要求に応えられないほど、致命的な欠陥が生じていたのです。具体的には以下のような課題を抱えていました。

• 売上予測値に20％程度の誤差が発生していた
• 集計パフォーマンスが劣化していた（集計時間の増加）
• 機能改善の費用対効果が低減していた

この背景には、事業成長に伴って扱うドメインや事業フローが変化したことや、データ分析基盤自体の問題に加えて、初期開発メンバーの離脱や属人化の進行といったエンジニアリング課題も伴っていました」（尾﨑氏）

以上の経緯から、既存のデータ分析基盤をより事業にフィットさせ、さらにエンジニアリング課題を軽減することを目的にデータ分析基盤のリニューアルプロジェクトがスタートしました。導入検討時の代替アーキテクチャが以下の図です。

広告やASPから取得したデータを受け取るフロントに「TROCCO®︎」を配置し、データウェアハウスにはAmazon Redshiftを選定。データの集計や整形処理には、AWSアプリケーションを駆使し、集計したデータの分析には引き続きTableauを使用することになりました。このアーキテクチャは早期に実現することができたものの、新たな課題が発生したのだと尾﨑氏は当時の反省ポイントを挙げました。

「リニューアル当初のアーキテクチャでは、データ抽出以降の工程にAWSアプリケーションを使用していました。しかし、当時はAWS様やprimeNumber様に対する弊社側の解像度が低い状態で構築を進めていたため、社内スキルセットとの乖離やブラックボックス化といった新たな課題が発生していたのです。

こうした反省ポイントを踏まえ、関係者で共通認識を持ちながらデータ分析基盤を構築することになりました。具体的には、社内向けのレポートをAWS様やprimeNumber様に共有させていただき、アーキテクチャのよかった点や改善点、目指したい姿を細かくお伝えしました。

これによって、両者の見解とベストプラクティスをディスカッションしながら設計へ反映できるようになり、弊社の課題解決に合理的なアーキテクチャを設計できるようになったのです」（尾﨑氏）

AWS社が考える、データが多様化・複雑化することで生じる3パターンの頻出課題

キュービック社におけるデータ分析基盤のリニューアルプロジェクトのお話を受け、AWS社の福家氏からは、キュービック社と同じくデータ分析基盤を再構築することになった他社事例と頻出課題についてご紹介いただきました。

「これまで多くのお客さまのお話を伺った経験から、①分析パフォーマンス、②コスト、③属人化、と3つの課題を解決するためにデータ分析基盤を見直すケースが多い印象です。それぞれについて解説します。

①分析パフォーマンス

企業のデータ量や分析作業に関わる利用者数の増加に伴い、アクセス集中時のパフォーマンスや運用体制に課題が生じるケースです。この場合は、よりハイスペックでパフォーマンスに優れたデータ分析基盤を構築していくことになります。

また、既存のデータ分析基盤がオンプレミス環境で構築されている企業の場合、たび重なる追加開発によって複雑化したデータ処理やひっ迫するデスク容量、さらにバッジ処理の長時間化といった課題を解決するため、クラウドへの移行を決断することもあります。

②コスト

ツールのライセンス管理が不十分で、使われていないアカウントが多数存在したり、高止まりしているデータ分析基盤のインフラコストを最適化できていなかったり、といった課題がよく見られます。その他にも、データ分析に発生する手作業によってオペレーションコストがかかっているケースも珍しくありません。

③属人化

大きく2つのパターンがあります。まず一つが、事業部や部署単位で別々のデータ分析基盤やツールを使用することで分析業務の方法やノウハウがサイロ化してしまい、社内共有が難しくなるパターン。もう一つが、データ分析基盤の運用が特定の社員に集中しているケースです。その社員がもし退職や休職してしまうと、データ分析業務がすべて止まってしまいます。

以上のような課題が顕在化する前に、多くのクラウドベンダーが提供しているアセスメントのツールやプログラムを活用し、事前にリスクを検知して対策することが重要です」（福家氏）

AWSではWell-architectedレビューというアーキテクチャを評価するフレームワークや、AWSのパートナー様向けのAWSファンデーショナルテクニカルレビュー（FTR）というアーキテクチャを評価するプログラムをご提供しています。

経営層やビジネス側との目線を合わせ、理解を得る難しさ。AWS社が提供するフレームワークとは

データ分析基盤の刷新には、当然コストがかかります。ツールやシステム利用料、データエンジニアの人的コストなどの予算を事前に確保するため、実際にデータを取り扱う現場と経営層の目線を合わせることが重要であり、簡単ではありません。

企業文化によって大きく状況が変わる問題ですが、キュービック社はデータ分析基盤の刷新にかかるコストについて、どのように経営層の理解を得ることができたのでしょうか。

「弊社の場合、DX戦略という大枠の方針はありつつも、もともとデータウェアハウスのR&Dとしてスタートしたプロジェクトだったため、経営層への緊張感を持ちながら進めていきました。

短期的に承認を得るのではなくて段階的に検証実績を積み上げ、合計5回の経営層への報告のうち、最後の報告時に中長期の予算を一気に取得しました。その際、データ分析基盤の刷新でどの程度の効果があるかを概算で提示しています」（尾﨑氏）

その他にも尾﨑氏は以下のような工夫によって経営層の理解を得られたそうです。

• システム寄りの話ばかりでなく、競合の情報など興味を持ちやすい話題を提示した
• 導入したデータウェアハウスに蓄積したデータをどのように活用するかのロードマップを提示した
• 実際にプロトタイプを作成し、現場と経営層のギャップを解消しながらシステムの磨き込みを進めていった

一方、AWS社の福家氏からは、データ分析基盤の刷新やクラウドリフトの社内提案時に活用できるフレームワークをご紹介いただきました。

「AWS社では、Cloud Adoption Framework（CAF）というフレームワークをご用意しています。これはクラウドジャーニーにおける6つの観点と4つのステージを整理したものです。

まず、6つの観点では、検討すべきポイントを技術的・非技術的で2つに分けていることが特徴です。先ほどの尾﨑様のお話ですと、技術的なデータエンジニアと非技術的な経営層、それぞれの観点にあてはめることができます。

　一方で4つのステージは、計画を立てる「Project」、小規模なスコープで新しい分析基盤を導入する「Foundation」、本来ターゲットとしているすべてのスコープに対して新しいシステムを導入する「Migration」、最後にコストを最適化する「Reinvention」と、プロジェクト全体を4つの時間軸に分けています。

こうしたベストプラクティスをご活用いただき、ぜひデータ分析基盤の構築プロジェクトにお役立ていただけると幸いです」（福家氏）

データ集計の精度を30％向上させ、事業成長に耐えられる分析基盤を実現！

データ分析基盤のリニューアルプロジェクトによって、数度の試行錯誤を受けて最終的にフィックスされたアーキテクチャがこちらです。

「TROCCO®︎」導入前に抱えていたいくつかのビジネスインパクトに影響する課題は解決することができたとのことです。

「売上予測値の誤差や集計パフォーマンスの劣化、機能改善の費用対効果が低減していたという課題は解決できました。加えて、エンジニアリング課題であった技術負債や属人化の進行といった問題も概ね解決し、事業成長に耐え得る分析基盤に生まれ変わることができたと自負しています。

そして、定量的な成果は以下の通りです。

システムの刷新に加え、最新の業務フローに合わせた集計方法へ見直した結果、特に致命的な課題であったデータ集計の誤差を40％も低減することができ、集計精度の30％向上に成功しました。

また、コストセンター化していたエンジニアリング工数も、自動化やローコード化によって、8人月から4人月まで半減できました。これはただの削減ではなく、ビジネス側の要求に柔軟かつスピーディーに応えられる環境であることを意味します。

そして、ひとりのデータエンジニアとして最もフォーカスしたい点が、データエンジニアに求められるスキルセットが軟化したことです。以前はRails中心でデータの収集からアウトプットの出力までを一手に担っていました。今回のプロジェクトによって、データ設定の部分だけをRailsで行いつつ、以降の部分を『TROCCO®︎』とSQLで代替することでエンジニアリソースを軽減できるようになったのです」（尾﨑氏）

今後はカスタマーを分析し、最適なユーザー体験を提供できる状態を目指したい

2021年に決定されたデータウェアハウスのリニューアルの完了を目前に控えたキュービック社。当時抱えていた課題を解決した現在、今後はどのような展望を描いているのでしょうか。

「データウェアハウス構築はあくまで手段ですが、現在は目的になってしまっています。具体的には、扱っているデータが広告と成果という限定的な集計にとどまっており、Webサイトの動向やユーザー動向の分析など、デジタルメディアにおける最適なユーザー体験の実現にデータを活用していきたいのです。

そこで中長期計画の一環として、現状リーチできていない新たな情報収集を行ったり、技術的な部分で機械学習基盤の構築を計画していたりといった展望を描いています。そのためのネクストステップとして、まずはセグメント別にユーザーのデータを蓄積し、分析できる環境を構築していきます。それによって、分析の精度を向上させるだけでなく、現在顕在化していない仮説の抽出や定量的な数値根拠に基づいた意思決定ができるような状態を実現したいですね」（尾﨑氏）