IVRyにアナリティクスエンジニアが必要になった裏側
IVRyの和田です！
私は半年前にデータアナリストとしてIVRyに入社し（入社エントリ）、このたびロールが「アナリティクスエンジニア」と改まりました。弊社では「アナリティクスエンジニア」のロールを担っていただける方をまだまだ絶賛募集中です。
この記事ではIVRyでアナリティクスエンジニアというロールが必要になった背景を紹介したいと思っております！
宣伝
2025-03-25にコミューン株式会社様と一緒に、「SaaS x コミュニケーションデータ x スタートアップでのデータ分析」というテーマでのLT会を開催予定です！私もスピーカーとして登壇予定です！この記事で紹介し切れないことも含めつつ、SaaSスタートアップのデータ周りの話をできればと思っておりますので、ぜひ聞きに来てください！
詳細は追って展開させていただきます！
IVRyにおけるアナリティクスエンジニア
実のところ、データアナリストからアナリティクスエンジニアにロール名が変わってもやることはほとんど変わらないというのが実情です（笑）
世間一般のアナリティクスエンジニアの定義とはズレてしまいますが、IVRyにおいてはやることを変えるというよりもサークル（IVRyにおける職能別の組織）内外に対する「今は各種事業指標の定義の策定や、そのためのデータマートの構築に比重を置くぞ！」という宣言みたいなものになっております。
データ周りのロールの動き方のイメージは弊社VP of Data大曽根の記事をご覧頂けると幸いです。
データ整備に比重をおいている背景
ここからは「事業指標の定義やデータマート構築に力を入れるぞ！」という意思決定に至った要因を3つ紹介します！IVRyのデータサークルが改善したいと思っているポイントが伝われば幸いです。
1. 「飛び降りながら、飛行機を作る」スタートアップ
古くから使われている例えではありますが、スタートアップではとにかく生き残るために色々なことを進めていく必要があります。
そんな状況下でデータだけが完璧で綺麗なんてことはもちろんありません。プロダクトもどんどん改善され、使えるデータもどんどん増えていくという状況下では、データ分析基盤もその進化に追従する必要がありますが、それを担う人が不明瞭であるというのが課題でした。結果として「このデータは最新の状態を反映できているんだっけ？」という状況が発生することになり、余計な確認作業などが発生してしまうことになります。
過去との整合性をとりつつデータソースの状況に合わせて各種データを整備していく体制構築が実現したいことの一つです。
2. サブスクリプション型プロダクトの分析サイクルの特徴
私はtoCプロダクトに関わってきた経験の方が長いのですが、toCプロダクトと比べると、IVRyのようなサブスクリプション型のtoB SaaSプロダクトではアクションの1サイクルが少し長めだという印象を持っています。特に支払いが月毎であるため重要な事業指標も月単位のものが多くなり、「仮説 → 結果の確認 → 次の仮説」というサイクルも月単位になりがちです。
ECサイトのようなtoCプロダクトではA/Bテストなどの方法を用いて比較的短期間（短ければ数週間など）で仮説検証を行うことができ、効果が高ければ売上などの事業上重要な指標の変化もすぐ観測できることがあります。
一方で、サブスク型のビジネスモデルでは週単位での劇的な変化は起こりにくく、数ヶ月先をターゲットにして動くことが多いです。プロダクトの進化の速さも相まってサイクルの最初の方と最後の方ではデータの状況も異なることが多々あり、使用するデータの継続的なメンテナンスが課題となるのですが、データサークルの人員数などの問題もあり個々のプロジェクトに完全に張り付いて対応するのがまだまだ難しい状態です。
各プロジェクトがデータをつかってやりたいことを自分たちで実現できるようにしていくイネイブリング活動の前段として、共通的に使えるデータマートの構築が必要だと考えています。
3. 組織拡大に伴うデータの重要性の高まり
私は2024年8月に入社して社員番号119なのですが、半年経った今社員数は 200人近くまで増えています。
人数が増えるのに比例してコミュニケーションの重要性も増していく一方ですが、その際に使うデータの信頼性も重要になってきています。各々が出しているデータに食い違いがあると、「何が差分なのか」「他の数字はあっているのか」と本質的ではない箇所でコミュニケーションが止まってしまうことがあります（そして差分調査依頼はデータサークルに来ます。）
プロジェクトなどを跨いで共通のデータを利用するために、スプレッドシートや Looker Studioでアドホックに作ったデータを恒常的に利用しやすい形式に整備していく必要があります。
現在の進行状況
実現したいことを改めてまとめると下記のような感じです。
データ定義がプロダクトの変更に追従できている体制
各プロジェクトが自走するための、使いやすいデータマート構築
アドホックなクエリを吸い上げて横断的に恒常利用しやすい状態への移行
基本的には世の中のベストプラクティスに乗っかってGitHub + dbt（今はdbt Core）でのデータモデル管理を進めています（ここはそんなにトリッキーなことはしていないはず……）
各課題に対するdbtの導入状態は以下のようになっています。
プロダクトの変更への追従
全体影響のあるような変更はdata warehouse層で吸収できるように
dbt testで影響の大きい変更がないかを定期的にチェック
accepted_valuesによく助けられています。スキ。
データマート構築
今は重要な事業指標からトップダウンにデータモデルを整備
データ定義はdbt docsで簡易にカタログ化
アドホックなクエリの吸い上げ
データの利用先（スプレッドシートやLooker Studio）をexposureに追加して利用状況把握できるように
超参考にしている10X 吉田さんの記事: https://www.yasuhisay.info/entry/2024/01/20/114845
同じことをやっている箇所はまとめてwarehouse, martとしてdbtでの管理に寄せていく
今後について
まだまだ道半ばという状態ではあるのですが、データリネージもなんとなく階層化されてきました（ほんの一部分ですが↓）
dbt導入前はデータソース（緑）と利用先（exposure / 橙）がそれぞれ直接的に繋がっていて、それぞれの利用先の中で加工しているために数字がちょっと違う、ということが発生する状態だったので、それと比べるとかなり改善されてきたと思います。まだそうなっている部分はたくさんありますw
定義済みのデータが揃ってきたことでデータ分析タスクをさばく速度も徐々にあがってきており、恩恵は強く感じています。定義済みのデータがもっと出揃えばもっと日々の業務も高速化できるのは間違いないので、これを更に広げ、各プロジェクトが自走できるようになるところまでもっていきたいです。
今は会社にとって重要な事業指標から順番にトップダウン的にデータ整備を進めていますが、データ周りの課題としてはデータ整備だけでなく「音声のような非構造データどう扱おう」「全社員がデータ分析をする文化を維持したままデータセキュリティをどう担保しよう」みたいな別の観点の課題もまだまだあります。
ロール名こそアナリティクスエンジニアに変わったものの、やることに壁ができるわけではなく、色んな課題そのものに向き合える環境なので、チャレンジできる領域が広いのがデータ周りの職種としては嬉しい限りです。例えば私は、エンジニアチームと連携してプロダクト用のデータ周りにもdbtを導入したりとかもしています！↓
We’re Hiring
データ整備に比重をおいたアナリティクスエンジニアを募集していますが、データ周りの職務範囲は非常に曖昧であるし、結局のところスタートアップなので全部やるしかない！みたいなシーンばかりなので、あまりロール名は気にせずに、ぜひカジュアル面談で直接的にお話できると嬉しいです！
データ周りのキャリアを進んでいる方はキャリアに関して悩み多き人が多いと思うので、お互いに情報交換できると嬉しいです！（というか自分も相談乗って欲しいです）
カジュアル面談はこちらから！