キャディ株式会社の図面データ活用クラウド「CADDi DRAWER」の開発・運用を担う​​DRAWER事業本部のVPoEとして、元Sansan株式会社 CTOの藤倉成太さんが就任しました。今回はキャディ CTOの小橋昭文さんと藤倉さんにインタビューしました。


前代未聞の速度で成長する「CADDi DRAWER」。その根幹を支える組織作りのビジョンとは

<p>はじめまして、<a href="https://www.asoview.co.jp/"><u>アソビュー</u></a>でデータ基盤チームに所属している霧生です。</p><p>近年、モダンデータスタックの登場などによりデータ分析基盤は一層盛り上がりを見せています。選択肢も増えてできることが多くなった反面、どう構築していくか迷う場面も多いのではないでしょうか。今回はアソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説しますので、ご参考になれば幸いです。</p><h2 id="h551033d7c6">現在のアソビューのデータ分析基盤</h2><p>アソビューは創業10周年を超えており、当然ながら今までもデータを分析して事業やサービスに役立ててきました。しかし、コードやインフラの継ぎ足しを重ねたことにより秘伝のタレのような状態と化してしまい、多くの課題が生まれています。そこで、アソビューではこの問題を解消するために、昨年から<a href="https://datale.co.jp/"><u>株式会社DATALE</u></a>さんとともにデータ分析基盤の再構築を行いました。</p><p>データ分析基盤を構築するにあたり、「使われる」データ分析基盤にすることを大切に設計・実装していきました。というのもそもそも「データ分析基盤は使われなければ意味がない」からです。ただデータを収集しているだけ、データ分析基盤を作ることだけが目的になってしまっている場合、どれだけ優れたアーキテクチャを組んでも、データからインサイトを得てビジネスに役立てるデータ活用のプロセスが進みません。</p><p>では、どうすればデータの活用が進むのでしょうか。その答えのひとつが弊社も利用しているBIツール、<a href="https://www.tableau.com/ja-jp" target="_blank" rel="noopener noreferrer nofollow">Tableau</a>が提唱しているビジュアル分析のサイクルにあると考えています。</p><p></p><figure><a href="https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm" target="_blank" rel="noopener noreferrer nofollow"><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5a80e285e9884c8894dbfeb628a3f26e/image1.png" alt="" width="489" height="425"></a><figcaption>ビジュアル分析のサイクル。画像は https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm より引用。</figcaption></figure><p>「どこからデータを分析していけばいいかわからない」「分析結果を見てもよくわからない」というユーザーからのフィードバックは「タスク」がないことに起因していることが多いです。</p><p>簡単な例ですが、「売り上げを上げたい」「コストを下げたい」といったタスクに対して、どんなデータを見ればいいか、さらにそのデータをどう見ればいいかなどを考えて、必要十分なデータを取捨選択していくことが重要です。こうして適切なデータを適切に扱うことで、より価値のある活用につながります。また、ビジュアル分析のサイクルはただのプロセスサイクルではないため、分析を行う中でさらに必要なデータが出てくることもあります。柔軟かつ高速にビジュアル分析のサイクルを回すことで、データ分析基盤は使われる・価値のあるものに進化していきます。</p><p>分析者と同じ視点に立ち、高速に新しいデータを連携して分析のプロセスを回す。これがデータ分析基盤を新規に作り上げていく段階では特に重要な観点だと考えています。そこで私たちが導入したのが<a href="https://trocco.io/lp/index.html"><u>trocco</u></a>です。troccoとはETL/データ転送機能を提供する分析基盤構築・運用支援のSaaSです。troccoを提供している<a href="https://primenumber.co.jp/"><u>株式会社primeNumber</u></a>が日本企業ということもあり、日本語での手厚いサポートや日本でよく使われるSaaSからのデータ連携にも多く対応しています。troccoは主にGUIで設定を作成するため、初期の学習コストや設定作業のコストを大幅に削減でき、いち早くデータを提供できます。</p><p>また、データウェアハウスには<a href="https://cloud.google.com/bigquery?hl=ja"><u>BigQuery</u></a>を採用しました。これも構築・提供スピードを重視した技術選定です。GAなどの他のGoogleサービスとの親和性や、よく使われるSaaSとの連携に対応していることを考えて選択しました。</p><p>最終的なアーキテクチャは下記のようになりました。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8ed3924aac5846ada4dbc3991266cc67/image2.png" alt="" width="1537" height="865"></figure><p>troccoにはデータマート生成という機能があり、これを利用して収集したデータを最終的に分析可能な状態に変換してデータマートを構築しています。</p><p>BIツールは先にも出てきたTableauを利用しており、直近では社内のアクティブユーザー数が全社員の4分の1に迫る40人前後、Tableau Cloud上での分析結果のView数は約600view/日と、広く使われる状態を実現できていると感じています。今ではマーケティング施策やモニタリングだけではなく、アプリケーションへのデータの利活用や広告の最適化など、さまざまな用途でデータ分析基盤が使われています。</p><p>これは株式会社DATALEさんのご協力はもちろんですが、分析しているアソビュー社員のデータに対しての感度の高さや意欲など、さまざまな立場とスキルを持ったメンバーが揃い尽力した結果だと思います。データ分析基盤は使われなければ意味がないと冒頭で書きましたが、それはつまりエンジニアだけで作り上げるものではなく、使っている人や状況に応じてアーキテクチャも変わっていくべきということです。現状は前述の構成を使っていますが、運用している中での課題も出てきており、その解決のためには小手先の対応ではなくアーキテクチャレベルの改修が必要になっています。</p><h2 id="h7070e90391">将来的なデータ分析基盤の構想と導入したい技術</h2><p>先に挙げた現状抱えている課題ですが、大きく分けて下記の2つがあります。</p><ul><li>データマートに対してのSQLの実行速度とデータ基盤全体の料金</li><li>データ分析基盤の堅牢性</li></ul><h3 id="h4312134b13">データマートに対してのSQLの実行速度とデータ基盤全体の料金</h3><p>ビジュアル分析のサイクルを高速に回していくには、さまざまなデータについて異なる角度から何度もビジュアル分析を試すデータ探索によって、BIツールから素早く結果を取得できることが重要になります。アソビューではデータ分析基盤の利用が拡大し分析可能なデータが加速度的に増えていった結果、いくつかのテーブルで速度劣化が起きるようになりました。また、うれしい悲鳴ではありますが、データ分析基盤の利用が拡大し利用者が増えたことにより料金も大きく増加しています。</p><p>テーブルの構造変更やBigQueryの機能の利用など、現状のアーキテクチャでも改善できる部分は当然あると考えています。しかし投げるクエリやテーブルの性質、利用しているBIツールとの相性などを鑑みて、アソビューの場合は同時並行で検証を行っていた<a href="https://www.snowflake.com/ja/"><u>Snowflake</u></a>を利用することでこれらの課題に対して一定の効果が期待できると判断しています。</p><p>速度面では、データ探索中にTableauが類似したクエリを多く投げる点や、ライブ接続でViz*を見た場合に同じクエリが投げられる点などから、Snowflakeの強力なキャッシュ機能の恩恵を受けやすいこと。料金面では従量課金の方式がBigQueryではデータのスキャン料であるのに対して、Snowflakeはデータウェアハウスというコンピュートリソースの起動時間であるため、予測が立てやすく利用者が爆発的に増えた場合でも対応しやすい料金体系になっていることが理由です。</p><p><em>*…Tableauで作成した、ビジュアライズされたグラフや表。</em></p><p>また、管理側の目線ではクラウドサービスプロバイダーであるGCPのひとつの機能であるBigQueryよりも、データクラウドとしての機能に特化しているSnowflakeのほうがアクセスコントロールが優れている点もあり、管理と利用の両面でSnowflakeへの移行はメリットが大きいです。</p><p>一部ではすでにSnowflakeの実験利用が始まっています。GAなどBigQueryに依存したデータがあるので、Snowflakeだけでデータ分析基盤を構築することはできないですし、クエリの細かな違い、データの移行やどう活用するかのステップなど多くの課題がありますが、一歩一歩移行を進めていく予定です。</p><h3 id="h11f5f4f8cc">データ分析基盤の堅牢性</h3><p>データ分析基盤の利用者が増えて、データ分析基盤自体の業務への依存度が高まっています。それに伴い、データの鮮度や状態といったデータ分析基盤の可用性や変更に対しての強さ、堅牢性の重要度が日々増しています。</p><p>troccoはGUIからの設定が主であるため導入コストの低さが特徴です。しかし、分析できるデータが増えて規模が大きくなるにつれて、データマートを構築するためのクエリやそれらを取りまとめるワークフローは複雑になっており、管理が煩雑で属人化が激しくなってきています。これをきっかけに、より使われるようになったからこそ堅牢性を上げていきたいと考えています。しかし、堅牢性は構築スピードとトレードオフになってしまうため、バランスをどう取るかに頭を悩ませています。</p><p>現状この問題に対してはdbtを導入することが良いのではないかと考えています。troccoにもdbt連携という機能があるため、どこでどう実行するか、Snowflakeへの移行も含め今後検討していく予定です。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>アソビューにおけるデータ分析基盤のアーキテクチャと、その設計意図に関しての紹介でした。</p><p>技術の更新が激しい界隈ですし、ここには書けていない課題も多くある状況です。お察しの通りアソビューのデータ分析基盤はまだまだ道半ば、なんなら走り始めた段階だと思っています。しかし、データ分析基盤の利用者は日々増えており、データドリブンな文化も浸透してきています。ここを走り切ってデータの利活用が進むことが大きく事業を成長させる重要な要素であることは間違いありません。</p><p>これからも、より「使われる」データ分析基盤になるように改善を続けていきます。1年後には別の姿になっているかもしれません。その時はまたどこかで共有できればと思います。本記事が皆さまの一助になれば幸いです。</p><p>編集：中薗昴</p><p style="text-align: start">提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow"><u>株式会社Haul</u></a></p>

アソビューでデータ基盤チームに所属している霧生さんによる寄稿。アソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説します。

trocco・BigQuery・Tableauを採用。アソビューがデータ分析基盤の再構築に挑んだ理由

<p><a href="https://corp.moneyforward.com/" target="_blank" rel="noopener noreferrer nofollow">株式会社マネーフォワード</a>のCTO室副室長の松本と申します。主にデータエンジニアのチームのマネジメントを担当しています。本記事では執筆時点（2023年8月）のマネーフォワード内のデータ分析における業務やアーキテクチャについて説明します。</p><h2 id="h3e48e533b6">事業紹介</h2><p>より具体的なイメージを持っていただくために、マネーフォワードはどのような事業を行っているかについてまずは説明します。法人向け・個人向け・金融機関向けという3つの事業領域を定義しており、法人向けは事業者の経理や人事労務などの作業効率化のためのバックオフィスSaaSの提供、個人向けは家計簿・資産管理アプリなどのPFMサービス、金融機関向けでは、金融機関の顧客への業務DXサービスやコンサルティングサービスなどを提供しています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5ddcd75d6b1048c2a122b3bd7eae0536/image1.png" alt="" width="1462" height="655"><figcaption>「2023年11月期第2四半期決算説明資料」より抜粋。グラフは2023年11月期第2四半期累計売上高に占める内訳。</figcaption></figure><p>IR資料にもある通り、法人向け領域は売り上げの多くを占めており、特にデータ活用の社内ニーズも高まっている領域です。エンジニアチームも注力領域として日々改善を続けています。そのような背景から、本記事では法人向け領域でのデータ活用を中心に記載しています。</p><h2 id="hed5e2f5a5c">データ分析のワークロード</h2><p>続いてデータ分析におけるワークロードについてです。データ分析のための業務と一口に言ってもさまざまな技術要素や知識が組み合わさって構成されています。生産性や専門性の観点から3つのプロセスに大別し、それぞれに業務プロセスや開発フローを定義し運用しています。</p><h3 id="h2cd7571313">1.データ収集</h3><p>1つ目はデータ収集プロセスです。データ分析に利用されるデータはプロダクトのデータベースだけではなく、利用しているSaaS・広告関連などのツール・行動ログなど多岐にわたります。通常これらのデータは1カ所に集約されていることはないため収集する仕組みを新たに構築する必要があり、収集する際には収集元の仕様やセキュリティ強度を理解した上で設計することが求められます。マネーフォワードのデータ分析環境は利用者が差異を意識せずに分析ができるよう連携先ごとに異なる仕様を吸収するために、スクラッチの仕組みやツールなどを組み合わせて構築しています。</p><h3 id="h14d5d243b1">2.データロード</h3><p>2つ目はデータロードのプロセスです。こちらもユースケースによって同じデータソースに対してもさまざまな処理要求があります。用途によってリアルタイムに近いデータが必要である場合や、日次レポートや月次集計処理などの場合はそれぞれのタイミングに合わせる形でよいケースもあります。全てのデータを一律に処理すると仕組み上はシンプルですが、キャパシティやコストなどの問題を抱えることになるため、データロードにおいても異なった要件に対応できるよう複数の仕組みを用意しています。</p><h3 id="hb3d85062bf">3.データ利用・分析</h3><p>3つ目は実際のデータ利用・分析のユースケースになります。データ収集とデータロードの工程を経て利用可能となったデータを用いて事業KPI管理のためのダッシュボードを構築したり、マーケティング施策の改善などビジネスのためにデータを活用したりすることなどが主な用途ですが、特別定額給付金が家計消費に与える影響に関する研究論文に利用された事例もあります。</p><h2 id="hfd97687f98">アーキテクチャ構成と設計意図</h2><p>上記を実現するためのアーキテクチャについて解説します。データの連携元としては代表的なものとしてRDB・SaaS・行動ログ・広告データの4つがあり、それぞれについて説明します。</p><h3 id="hf8fcd0af10">多数のプロダクトから迅速にデータを集めるために</h3><p>まずRDBとの連携ですが、マネーフォワードでは日々新たなプロダクトが生まれており、それぞれのチームが独立して意思決定を行い構築・運用しています。一方でデータ分析はさまざまな軸で行われるためシームレスに利用可能なことが求められます。それらを実現するために複数あるRDBのデータ変更をキャプチャし、集約した後に各環境へ配布するという方式をとっています。</p><p>直接的にデータロードをすることも可能ですが、一度同じ形式に変換する方式をとることにより、新規プロダクトの仕様差分を抽象化して分析可能なデータのデリバリー速度を向上させています。現状はこの方式に落ち着いているのですが、元々はそれぞれのプロダクトごとにデータ分析のパイプラインや環境が存在しており、開発や管理も煩雑な状態でした。そのため数年かけて集約に取り組みました。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1d7c21c81d024a95aa9eee41c82ae7ab/image2.jpg" alt="" width="1920" height="1112"></figure><p>SaaSとのデータ連携においてボトルネックになりやすいのが仕様変更時の対応です。マネーフォワード内では業務効率化やビジネス成長を目的として各部署でさまざまなSaaSの導入検討や活用が進んでいます。一方でSaaSはそれぞれの仕様があり、安定して分析用途のデータを提供するためにはそれらの仕様変更に追随し続ける必要があります。</p><p>これらに対しては外部のETLツールを積極的に利用することで、社内のエンジニアがSaaSの個別仕様への追随を意識せずに済むようにしています。行動ログ・広告データもSaaSと同じく外部ソースなので、仕様変更を吸収するために外部のツールを利用しています。</p><p>一方で、ツールでは実現できない要件であるケースも多々あります。その場合は独自の実装をするケースがありますが、マネージドサービスと比較して技術面での負債化やメンテナンスコストの増大につながる懸念が大きいため、一定期間で再評価して継続すべきか否かの判断を行っています。</p><h3 id="hdc6685d508">安全管理対策としての環境分離</h3><p>またこれらのデータにはさまざまな情報が含まれています。情報の安全管理のために、各項目に情報レベルを定義・分類し、異なる環境へ格納するようにしています（言い換えると情報レベルごとに環境を分断しています）。各環境は参照できる情報が制限されていたり、エクスポートが制限されていたりとレベルに応じた安全対策がそれぞれなされています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5b2ff1df32ee41cb8a9ca0e5855fd6bd/image4.jpg" alt="" width="1920" height="1262"></figure><p>制約が多い環境は分析体験が悪化するため、分析者は分析の目的によって環境を使い分けています。そして、それぞれの環境に異なったレベルのデータが混入しないように自動で検知するための仕組みを構築し対処しています。</p><h3 id="hf6bbcaf0eb">メタデータの重要性</h3><p>これまでデータそのものの収集に関して説明しましたが、付帯情報（メタデータ）についても同様の課題を抱えています。つまり複数のプロダクトからデータを集約できても、それらのデータが何を意味するのかがわからなければデータとしての価値は低いですし、分析者が分析作業を中断して調査を行うのも合理的ではありません。</p><p>また、先に述べた通りマネーフォワードでは多くのプロダクトを運営しており、それぞれに開発チームが存在しています。つまり、多くの開発チーム・エンジニアが社内にいるということであり、問い合わせ先を確認するのもそれなりの作業量になります。これらの課題に対処するために独自で情報に対してメタデータを登録・更新できる仕組みを構築しています。分析者が一度調べた内容をこの仕組みに登録すれば、他の分析者もそれらの知見を再利用できるようになっています。</p><p>さらに、これらのデータは構成情報のみのため1カ所に集約して管理し、先に述べた各情報レベルの環境へ「配信」するという構成にしています。理由としては将来的には情報レベルのさらなる細分化や、利用技術によって環境を分離する必要が出てくることを想定しているためです（売上集計の業務環境と大規模なモデルを構築する環境では必要な機能・リソースが異なるというようなことを想定しています）。現在は分析者用途ですが将来的にはエンジニアも他プロダクトのメタデータを知りたいというニーズは出てくると考えられるので、エンジニア向けの用途としても想定しています。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>マネーフォワードにおけるデータ分析に関するワークロードとアーキテクチャを紹介しました。最後にこれからデータ分析のアーキテクチャを検討されている方にお伝えしたいことがあります。</p><p>データ分析に関連した業務や職務は細分化し続けています。以前は分析環境といえば専ら分析用データベースがあるという形でしたが、現在ではデータ量が増加し分析手法も多様化して、単一のデータベースでは実現できないユースケースがたくさん出てきています。それらの実現のために多くの機能や複数の環境が求められるように変化してきていると感じています。</p><p>一方で環境の増加はメンテナンスコストや技術的負債の増加を招きます（それらを避けるために機能拡張に消極的になるケースもあります）。これらの最適解を見つけるためには、なるべく多くのステークホルダー・関係者と適切にコミュニケーションをとり、正しい意思決定をし続けることが肝要だと考えています。本記事がみなさまのデータ分析に関する業務の一助となれば幸いです。</p><p></p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

株式会社マネーフォワードのCTO室副室長である松本さんが、同社におけるデータ分析業務の内容やそのアーキテクチャについて解説します。

「データ分析」の記事一覧