コミューン株式会社でデータチームのアクティングマネージャーをしている前側（まえかわ）と申します。2023年6月よりコミューンにJOINしました。X(旧Twitter)ではウィルという名前で活動しております。
はじめに
コミューンはオンラインコミュニティの企画・構築・運用を一気通貫でサポートするコミュニティプラットフォームのcommmuneというSaaSツールを提供しております。
SaaSスタートアップのデータ組織運営は泥臭く、データ基盤の整備に着手するのに時間がかかったり、高度な分析に着手できないまま進んでいく企業も少なくありません。
コミュニティというビジネスドメインは比較的新しい領域で、解明していかないといけないことが多いです。また、コミューンは専門性が高くプロフェッショナルな人が多いです。セールス、プロダクト、デザイナーどれをとってもかなり細かく肩書きがつけられています。その分だけデータのオーダーも専門的で多岐にわたる傾向があります。デザイナーの明確な組織体制や役割分担をみた時はこのフェーズでここまで丁寧に役割を定義しているのかと驚きました！
さらにマルチプロダクトに事業を展開しているため、複数事業がPMFするとデータ基盤の全体最適化を考えたり個別特化のデータ分析が必要だったりと複雑さが増していく可能性があります。
本記事ではスタートアップ組織において、属人化から脱却して、オペレーショナルエクセレンスなデータ基盤を構築していくノウハウをご紹介します。
そのため、以下のような方の参考になるのではないかと考えています。
- データ基盤の運用属人化に悩まれている方
- データエンジニアやアナリティクスエンジニアのキャリアを歩み始めたばかりの方（またはキャリアパスを検討されている方）
- データチームを組成していきたい経営者やマネージャーの方
- コミューンに興味関心がある方
コミューンのデータチームについて
コミューンは私が入るまで2名のアナリティクスエンジニアがデータ生成〜データ活用を守ってきました。社員数が100名を超えて、プロダクト、ビジネス、経営など社内のデータ活用ニーズに応えるのは難しく、少しずつ対応をしていました。データ基盤を整理する時間を捻出することが難しいことが課題の一つでした。
スタートアップの社員数100名〜のフェーズでデータ基盤の整備は必要なのか？
データ人材の人数が少ないフェーズのため時間を当てるのが難しいですが一定必要だと思います。データ基盤を整えて対応しないと、毎回の作業あたりの速度と品質が低い状態が続きます。それではデータエンジニアやデータアナリストの採算が合わなくなるので、データチームとして成果が出しづらい状況が続いてしまうのではないかと思います。会社の成長や事業に合わせてデータ基盤の成長を描いていくことが必要です。
なぜ重要かのサマリー
- 事業の定量面を踏まえた意思決定の速度と品質を向上させることができる
- プロダクトで実装する時に使うデータでトラブルが発生するリスクがある
- セキュリティインシデントが発生するリスクがある
コミューンのデータマネジメントの状態
コミューンのデータマネジメントは上記の表で言うところのLevel2~Level3に変化するタイミング
100人を超えたあたりからチームとしてのオペレーションを統一していき、300人ほどのタイミングでデータエンジニアリングチームを組成しデータを高品質に担保していくようなイメージで考えております。
コミューンではチームレベルでの運用を「オペレーションナルエクセレンス」に実行できるように改善を続けている状況です。
データ基盤の概要
コミューンのデータ基盤の概要図です。
モダンなデータツールも採用し、低コストでうまく運用できています。
ただしこのデータ基盤を効果的に活用することが課題で、以下の3つの取り組みを行いました。
1.DWHの4層の適切な使い分けの実施
概要図で示した通り、すでにBigQueryのテーブルを4層に分けて管理していたのですが、急ぎの対応で手が回らないことが多く、4層を適切に使えていないケースがありました。
特に、個々人で使い慣れているData Lakeテーブルから多重WITH句でいきなりデータマートを作成するようなケースが多かったです。この場合、毎回一から同じようなデータの前処理を記述する必要があり時間がかかりますし、ミスが発生しやすく、チェックもしづらい状態でした。
そこで、dbt, trocco, redashのクエリーや過去の集計依頼を整理し、代表的に分析に使えるウェアハウス層のテーブルとデータマート層のテーブルを作成しました。
分析によく使うデータマートは一通り対応したため、データ提供にかかるリードタイムが1作業あたり3日分ほど削減できました！
分析者個人からチームとして動く時にとても大変な作業ですが、きちんと4層で運用することができると余計な工数を削減できます。
コミューンではデータマート層のテーブルを目的ごとのワイドテーブルで作るように設計しております。このワイドテーブルをどこまで便利に集約するか、どこからテーブルを分割するかの工夫が肝になっております。
一定誰でも四則演算をするだけで必要な集計ができる状態を担保しているので、データチームがいないとデータ集計ができないという事態を改善できそうなところまできております。データの民主化を加速させるために取り組んでよかったことと思います。
2.データカタログの作成
将来のデータの民主化を見据えて、汎用的に使えるデータマートのワイドテーブルを誰でも利用できるようにデータカタログをnotionベースで作成しました。
とりあえずDWHを作成して、後からドキュメントをまとめようとしても、後から大変でやらなくなることが多いですし、メタデータの品質を担保するために素早くできるところから着手していきたかったです。
テーブルのメタデータはdbtのymlで記述し、BigQueryのINFORMATION_SCHEMAで管理しています。またcolabを使ってnotionのデータカタログ配下にあるnotion DBに入れる仕組みです。
詳しい内容はデータカタログに関するテックブログを後日公開予定です。
3.データマネジメントのアセスメントの実施
3-1.データマネジメントのアセスメントをやる意義
データマネジメントの必要性は、LLMやDXなどデータを適用できる場面の拡大、データ漏洩などに対する危機意識の高まりなどいくつもの観点があります。スタートアップの100人overのフェーズでやる意味として特に「目指すべきデータ活用を実現するための説明材料」「データチーム内の目線を揃える」という2つの観点があり、なるべく早く取り組めると良いと考えています。
3-2.利用者が求めるデータ活用を実現するための説明材料
定量データを気軽に利用したい VS データを理解して適切に加工するには時間がかかる
データチームが立ち上がったばかりの段階では、データの利用者とデータ提供者の間で対立する構造が生まれてしまいます。
この対立を解決してデータを気軽に利用できるようにするために必要なことを利用者および経営に説明できるようにする必要があります。そのために必要なこととしてデータマネジメントのアセスメントがあると思います。
データエンジニアの中で有名なDMBOKのダーマホイールでは11の領域に分けてデータマネジメントを進めていくと良いと提唱しています。
参考：一般社団法人データマネジメント協会 https://www.dama-japan.org/Introduction.html
コミューンにおける現状の各領域の説明とやることの例
このダーマホイールを用いて現状を評価することが「利用者の求める気軽にデータを利用したい」という状態に近づくための第一歩であり、この結果を用いて例えばデータモデリングをここまで上げるとデータの品質が向上したり、データ提供速度が上がるため実行しています。といった形で説明可能な状態になります。
3-3.データ人材の目線を揃える
コミューンでは中途入社の人材が多く、バックグランドの違うメンバーが集まります。
データエンジニアは比較的に新しい職種で経験値が重要な職種のため、今後も中途入社者で構成されることが予想されます。中途入社の集まりなので各人で経験してきたことも大切にすることも違います。立ち上がったばかりのチームにおいて、短期にできることは限られていますし、何を実行するかの意見が合わないことが多いと運営上の大きな課題となります。データマネジメントに関するアセスメントを実施することで目線を揃えることができて、素早くデータ基盤のロードマップを作成してチームで動けるようになるのではないかという思いで入社してすぐにアセスメントを実施しました。
毎回認識を揃えるためにコストを払うより基準を作った方がいいと思い実施したのですが、やってみてよかったです！
3-4.アセスメントをやってみて
3ヶ月間チームで議論して、各領域の定義、スコアの意味やゴールなどをコミューンの現状に合わせてオリジナルで作りました。
| 3ヶ月で実施したこと | 説明 |
|---|---|
| PJ発足 | DMBOKのアセスメントを自社に合う形で設計し評価を回せる状態を3ヶ月で作る前提で設計。 |
| DMBOK各章の輪読会 | 有識者のnoteや参考文献を利用して読み合わせ。 |
| DMBOK各章の定義や守備範囲の決定 | 関わりあう各章の棲み分けや各章を一言で説明できるようにする。少数精鋭のスタートアップに合わせたアレンジの実施。 |
| 評価点数と定義づけ | 自分たちが評価しやすい点数設計。 |
| 現状評価 | 各人で評価してすり合わせを行う。その中でズレがなければ評価設計がうまくいっている。 |
| スタートアップにおけるアセスメント設計 | 1.オペレーショナルエクセレンス、2.品質最大化、3.経営戦略とデーて戦略の連動という3STEPのゴールを設計。 |
| OKRやロードマップと連動 | データチームの業務に組み込む。 |
| 来期目標設計 | PDCAを回せる状態を作る。 |
先人の知恵、歴史に学びつつ、単純にマネするのではなく、自社に最適な形を模索したのが良かったと思います！どうあるべきかのすり合わせを通して各メンバーの大切にしている観点がわかったり、データ戦略を作ることの難しさをメンバーに経験してもらえたことが副次的な効果としてあったと思います。
コミューンのある時点での四半期ごとのアセスメントの結果
3-5.アセスメントの結果
- データを単純に提供するだけでなく社員がデータを活用していくために、体制を含めてどのような順番で何をしていけば良いかを考えられるようになった。
- 自社のデータ基盤の現状と目指すべき姿が明確になり、より目線をそろえて業務ができるようになった。
- データエンジニアのメンバーが自分でロードマップを積み、その結果をアセスメントしていきながら運営できるようになった。
- データチーム以外に対してデータ基盤の必要性を説明する材料ができた
スタートアップで依頼対応や既存業務で忙しくメンバーが少ない中で実施するのはハードでした。しかし、いつかやろうと思っていても数年は実施できないようなテーマだと思いますし、すぐに着手してよかったと思いました。
一方で、データマネジメントのアセスメントは一定経験値のあるメンバーが揃っていないと作っていくことが難しいと思いますので、もしこの記事を見てくださっている方で不明なことがあれば私やXでデータマネジメントについて投稿している方などに相談してみることをおすすめします。
アセスメント活動は目的を見失わずに継続していくことが大事ですのでこれからも取り組んでいきたいと思います。
データマネジメントのアセスメントについても詳しい内容はコミューンのテックブログで後日ご紹介予定です。
今後の展望
本記事を最後までお読みいただきありがとうございます。
本記事では、データ基盤の運用を属人化からチーム体制へ変えていくために必要なことをまとめました。すでに成熟しているデータチームの方々からすると当たり前のことも多かったかと思いますが、1-3名でデータ全般の業務を担われている方からすると共感していただける内容もあったのではないかと思います。
経営からするとデータチームの業務が理解しづらく、経営の速度に合わせてデータ活用を展開できない。データエンジニアやアナリストの方からすると経営にデータマネジメントの必要性が伝わらない。経営のスピード感についていけないという課題がどの会社でもあると思います。
私は経営戦略にアラインして、データチームのリソースを投下し定量面で事業を支えられる組織を作りたいと思っております。「データを正しく流通させる」ためにも意思決定の品質と速度を支えるデータエンジニアリングチームをこの調子で作っていけたら嬉しいです。
宣伝
年内に3つほどデータ関連のイベントに登壇予定でございます。オフラインのイベントもあります。データエンジニアリングに関してぜひ皆様のお話しを伺ってみたいと思いますので、交流できると嬉しいです。
X (旧:Twitter)でご連絡いただくこともウェルカムですし、データ系のイベントでお会いしましょう。
不定期でdbtを語ろうの会など、データエンジニアリング大好きな各社の面々と開催しています。
コミューンで働くことに興味がある方はぜひカジュアル面談でお話しさせてください。
データチームは各社の経験豊富なメンバーがどんどん集まっていて面白いタイミングです！！
事業もぐんぐん伸びていて、データチームも一気に急拡大しており、今後も必要に応じて組織を拡大していく予定です！一緒にコミュニケーションの未来やコミュニティの分析をしたい方がいらっしゃいましたらご連絡ください！
コミューン株式会社 カジュアル面談お申し込みフォーム / Commune Inc. Casual Interview Application Form
