※ この「TROCCO体験記」は全4回の連載となります。

こんにちは。ゆずたそ(@yuzutas0)と申します。

前回はTROCCO®︎の感想を話し合いました。特に、TROCCO®︎と社内開発の使い分けが論点になりました。そこで今回は「自社開発せずTROCCO®︎をフル活用する」ことを選んだ2社の事例を見てみます。

株式会社ホワイトプラス:1ヶ月でデータ基盤を構築

1つ目の事例は、株式会社ホワイトプラスです。ネット宅配型クリーニングを提供している会社で、私が住んでいるマンションでも、たまに白い箱を見かけます。

創業者の1人・CTOの森谷さん(@32oooooooo)は、拙著『データマネジメントが30分でわかる本』でご一緒させていただきました。

森谷さんは Developers Summit 2020 や自社ブログで TROCCO の利用事例を紹介しています。

注目したいのは以下の3点です。

  • TROCCO活用によって1週間でデータをBigQuery(データウェアハウス)に反映した
  • 中間テーブルは作らずに、BigQueryの永続UDF(スクリプト機能)で集計ロジックを共通化した
  • 過去10年のデータを分析することで初回割引額を最適化してLTVを改善した

初期構築にコストを掛けず、TROCCO®️やGCPの機能を活用して、高速で開発しています。私(ゆずたそ)が過去に類似システムをスクラッチで構築したときは、いずれも3ヶ月〜6ヶ月ほど費やしているので、スピード感の差は圧倒的だと言えます。

ちなみに、株式会社ホワイトプラスでは、データエンジニアを積極採用中だとのことです(2020年6月現在)。システム開発だけでなく、データの可視化や活用戦略まで踏み込むポジションで、ビジネス志向の強いエンジニアリングを実現できそうです。昨今のライフスタイル変化に直結する宅配型事業は面白そうですね!(勝手に宣伝)

株式会社Mobility Technologies:API活用によるジョブ分離

2つ目の事例は、株式会社Mobility Technologiesです。

同社の渡部さん(@fetarodc)は『ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書』の著者で、私(ゆずたそ)の前職の同僚です。渡部さん経由で、TROCCO®️導入を推進した伊田さん(@mida12251141)をご紹介いただきました。

この事例ではワークフローエンジン(Airflow)から、TROCCO®️のWebAPIをコールしてデータ連携ジョブを実行しています。TROCCO®️単体ではまだパイプライン管理を実現できません(※脚注)。複雑なワークフローを作る場合には、このシステム構成に落ち着くでしょう。

  • Airflowのソースコードでジョブの流れを管理
  • データ取得元ごとのETLロジックはTROCCO®︎に丸投げ
※上記の資料を読んで @yuzutas0 が解釈・作図

これは美味しいところ取りの構成と言えます。あくまでも管理したいのはジョブの依存関係や定義です。多くのソフトウェアエンジニアにとって、システム間のインターフェース調整は、デバッグ地獄になりがちで、テストや保守の手間が掛かるため、そこまで面白くない(最初は楽しいけど徐々に体力と精神の摩耗に気付く)のが正直なところでしょう。

ジョブの依存関係や定義を自社で管理できると、業務をブラックボックス化せずに済みます。将来もし何かあったときにはTROCCO®️から他のシステムに移植可能です。専任の人材を雇ったり、SaaSに完全依存することに比べると、利用開始のハードルは低いと言えるでしょう。


TROCCO®️だけでデータ連携システムを構築できるのか?

2社の事例を踏まえた結論として、回答は「工夫次第でYES」と言えます。

各データを取得して分析用DB(データウェアハウス)に反映するだけなら問題ないでしょう。マーケティングやセールスの現場の多くでは、分析用DBの各データが最新状態を保っていれば、あとはExcelやダッシュボードツールで1日1回集計するだけで十分ではないでしょうか。

仮に複雑なワークフローを扱う場合であれば、株式会社Mobility Technologiesの事例のように、ワークフローエンジン(Airflowなど)で管理して、そこからTROCCO®️のWebAPIを呼び出す構成になるでしょう。抑えるところは抑えて、ラクできるところはラクする。今後のデファクト・スタンダードになりうる設計だと思います。

一方で、ワークフローエンジン経由で中間テーブルを作らずとも、株式会社ホワイトプラスの事例のように、永続UDF(スクリプト機能)やテーブルビューを活用することも可能です。定期バッチでテーブルを作らないので、常にリアルタイムな結果を返せる点がメリットです。パフォーマンスやコスト面でデメリットもありますが、サーバを立てて管理することの負担と比べると、十分に魅力的な選択肢だと言えます。

おわりに

中間テーブルやワークフローについては、本来不要な場面にも関わらず、ソフトウェアエンジニアやデータアナリストが手段と目的を履き違えて、無理に導入していると感じることがあります。TROCCOのようなSaaSツールの導入によって、関係者が「もっと低コストでラクできる」と気付き、より本質的な仕事に目が向くようになると、業界全体が健全になるのではないでしょうか。

※追記:この原稿の執筆後に「ワークフロー管理機能をリリースしました」「TROCCOの設定をGitHubでコード管理できるようにする予定です」「設定ファイルをエクスポートできるのでベンダーロックインは懸念しなくて大丈夫です」と教えていただきました。最強じゃないですか。

最終回は、運営者にぶっちゃけQ&Aを聞いてみたいと思います。

次回に続く!

yuzutas0 (ゆずたそ)

風音屋 / 個人開発のWebサービスがGigazineに掲載。PyConJPやDevelopersSummitでベストスピーカーを受賞。日経産業新聞1面やForbesJapanに取材掲載。著書に『個人開発をはじめよう!』『実践的データ基盤への処方箋』『データマネジメントが30分でわかる本』など。