企業のデータ分析基盤が成長するときは「成長痛」が発生する
小林氏はまず、「データ分析基盤の成長痛」がどのようなものかについて、primeNumber社内のデータ分析基盤の成長過程を例に挙げて説明した。
最初の1年目、0→1のフェーズではとにかく速く構築することを求められ、全速力で立ち上げた。しかし1年後には、1→10フェーズを迎え、分析のテーブル数が900を超えた。一つひとつのテーブルのデータを手作業で集めることなど到底できない。そこで自動化が求められるようになった。そして直近では、テーブル数が4500にも及び、データ分析のユーザーの数も50を超えるようになってきた。品質の悪いデータから意思決定をしてしまうと、誤った結果を招いてしまう。
そこで、データの品質を担保し、多くのユーザーに使ってもらえるようにデータを民主化していくことが必要になってきた。
社内のデータ分析基盤の成長過程を振り返って、小林氏は成長過程においてはそれぞれ「成長痛」というものがあったと感想を漏らした。primeNumberの場合、構築スピード、自動化、データ品質と民主化が成長痛になるだろう。
クラシコムは2006年創業の企業で「北欧、暮らしの道具店」というECサイトを運営している。クラシコムではアパレルやインテリア雑貨、食器などの商品を販売するだけでなく、読み物や音声コンテンツ、ドラマ、映画などを制作し、配信している。さらに、企業のブランディングを支援する事業も手掛けている。
高尾氏がクラシコムに入社した2019年に、社内の有志で勉強するところからデータ分析の取り組みが始まった。「当時は、MySQL上にデータがあり、それをRedashで可視化するほか、行動ログはGoogle Analyticsのコンソールで、別の環境で見るという状況でした」と高尾氏は振り返る。
当時は、データ分析基盤と呼べるほどのものはほとんど無く、スプレッドシートをデータマートのように使っていたという。このような運用に限界を感じ、BigQueryやLookerを導入した。これで、日々のデータの推移を見るなどの基本的なことは便利にできるようになってきた。すると、複数のデータ・ソースを使いたいと考え始め、primeNumberが提供するデータ分析基盤の総合支援サービス「trocco」を導入した。そしてLookerで使用する言語であるLookML（Looker Modeling Language）の使い方が複雑になってきたことが課題としてだんだんと顕在化したため、troccoのdbt（Data Build Tool）連携機能を使い始めた。
Lookerの「応用的な利用方法」が運用を複雑にしてしまった
その頃、クラシコムでは受注データや会員データなどのデータはAWS上に置き、行動ログはGoogle Analytics 4で取得してFirebase Analyticsに蓄積していた。顧客対応データはZendeskに貯まっていて、予算データなどの一部のデータはスプレッドシートに保存していた。このように分散したデータはtroccoを使ってBigQueryに統合していた。そして統合したデータをLookerで加工集計して、ダッシュボードを作っていたそうだ。
ここで、クラシコムではLookerのフォーラムに投稿されているテクニックを使用して、データマートを作成していた。クラシコムも非常に便利に使っていたと高尾氏は語る。Lookerは本来BIツールだが、応用的に利用して集計ツールとしても使っていたということだ。
しかしクラシコムもLookerを便利に使いすぎて、運用が複雑になっているとも感じていた。そこで、風音屋の横山氏にシステムを見てもらったところ、Lookerのディレクトリ構成やカラムの生成ロジックなどについて問題点を指摘された。ここで高尾氏は問題を正確に把握することができた。
実は高尾氏は、横山氏に相談する以前からデータ分析のユーザーとしても、システムに問題があると感じていた。すでに、複数のデータマートを参照してデータマートを生成するとき、データ連携のタイミングがずれると生成に失敗するという問題を把握していた。さらに、その時点のシステムが分かりにくい構造になっており、設計者でなければ修正が難しいものになっていることも感じていた。
そこで、Lookerで加工集計をしていたところを、troccoのdbt連携機能（dbt on trocco）に加工集計機能を移すことを決めた。そのプロジェクトに参加したのがこのセッションに登壇している4名だ。プロジェクトは2023年夏ごろに完了を目指しているがすでに効果は出始めており、利用頻度の高いテーブルをdbtに移行させたことでデータマート生成が失敗することが少なくなってきた。
「不可逆にしない」ために、外部に発注した
今回のプロジェクトに参加した4名の役割分担は以下の通りとなっていた。高尾氏がプロジェクトのオーナーとしてゴール・イメージを明確化し、データ分析基盤の改修を池田氏に依頼する。池田氏はLookerが受け持っていた加工集計機能をdbt on troccoに移し替える作業を担当する。
クラシコムはprimeNumberが提供するdbt on troccoを使いながら、ユーザーとして感想や要望をprimeNumberに返す。そして横山氏がシステム全体のコンサルティングを担当した。ここからは、高尾氏、池田氏、横山氏がプロジェクト進行に当たって特に意識した点について語った。
高尾氏は、新しいことを始めるときに「可逆性を持たせるプロジェクトにする」方針をクラシコムが採っていることを明かし、外部に委託できたことはありがたかったという。データ分析をあまりしてこなかったクラシコムがデータ分析を始めるといっても、どんな効果を生むかも分からない、どんな仕事があるかも分からない。 そうなると、いきなり人を採用することは難しい。そのため、外部に委託するという選択をした。
高尾氏の外部に委託するという判断について、横山氏は「よくあること」と評する。「特に、今回のような小さい規模でこれから始めるという初期段階ではよくある話だ」と言う。そして、データ分析基盤が一定以上大きくなったときも外部に委託することが多くなる。内部の人員だけでは業務が回らなくなるからだ。そして、その中間の規模にある企業は、内製にこだわる、自分たちだけでうまくやっていこうとすることが多いともいう。
さらに横山氏は高尾氏の判断について、「無理に規模を追うとか、いきなり大きな体制を作ろうとか、内製化していきなり強いデータ・チームを作るぞという進め方をしないところが、無駄がない投資、ROIが高い意思決定の結果につながっているのではないか」と語った。
池田氏は、業務委託としてプロジェクトに参加したことについて、クラシコムとカヤックが「伴走型支援」という形で協力している事実を挙げ、「いずれは自分が外れることができるように」ということを強く意識していたと明かした。「技術選定にしても、自分が抜けても問題ないものを選定するように心がけていた」と話した。
そして池田氏は、今回のプロジェクトの人員構成は良かったとしながらも、「できればクラシコム社内にもエンジニアがいた方が良かった」と語る。「技術選定などで何かを決めたときにクラシコム社内にもエンジニアがいれば、なぜこうしたのかという意図を引き継げる」とその理由を明かした。
また池田氏は、今回のプロジェクトではナレッジをドキュメント化することを強く意識したともいう。カヤックは伴走型支援という形で参加しており、いつかは池田氏もプロジェクトから外れることを是としている。後継となる人たちに自身の意図を伝えるためにドキュメントを残すのだ。
横山氏は、プロジェクトのコンサルティングと全体進行を担当する上で、「改善していく仕組みと文化」を根付かせることが大切だと感じていた。データ分析基盤は企業の成長に応じて作り変えていかなければならない。
そのため、今回のプロジェクトでは、リファクタリングの文化を定着させることを意識したという。ビジネス・開発の双方にとってソースコードを定期的に整理することが大事な取り組みであるという認識を持てるように働きかけた。
その際、メーカー出身の高尾氏が想像しやすいように、工場での仕事を例に挙げて説明した。ソースコードのリファクタリングをするのは、工場を稼働させる前に床に落ちている器具を整理整頓して事故を防ぐのと同じだ、といい、その重要性を伝えたそうだ。
リファクタリングは効果を示しにくいものではあるが、共通言語を持つことで、相互理解ができた状態でプロジェクトを進められた。
