ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

価値のあるデータ分析基盤をつくるために実践したこと

こんにちは。ユニファでデータ分析基盤の開発をリードしている浅野です。「Unifa Advent Calendar 2022」21日目のこの記事では、「せっかくデータ分析基盤をつくったのに使われない」という悲しい(けどよくある)事象の発生確率を減らすために実践してきたことを書いてみます。

adventar.org

1. 明確な課題があることを確認する

さまざまなプロダクトやサービスからの売上を正しく把握するのに時間がかかる、KPIの算出方法が定まっておらず人によって数値がバラバラになってしまう、など、1つで良いのでデータ分析基盤で解決したい大きなビジネス課題を特定し、ステークホルダーと合意しておくことはとても重要です。

ユニファでも何年も前からつくりたいよね、という話はありましたが、どうしても今すぐに解決したい課題があったわけではないので手をつけずにいました。その後、おかげさまでユニファのプロダクト群であるルクミーを導入していただくお客様がどんどん増え、カスタマーサクセスのチームがお客様のプロダクト利用状況を効率的に把握できる仕組みがないと業務が立ち行かなくなる、という課題が見えてきました。

カスタマーサクセスの支援によってお客様にしっかりと我々のプロダクトの価値を感じていただくことと、それを生産性が高い状態で実現することはビジネス上の優先事項の1つであるため、「この課題を今データ分析基盤を開発することによって解決する」ことへの会社としての大きなモチベーションが確認できました。

2. その課題がデータ分析基盤で解決することを確認する

上記の課題は今解決すべきイシューである、という合意が得られたら、本格的に開発を始める前に、その課題が本当にデータ分析基盤で解決するのかを確認することで「つくったのに使われない」リスクを下げることができます。

ユニファでは、前述のカスタマーサクセスにおける課題に対して、どのような指標をどれくらいの更新頻度で提供すると役に立つのかカスタマーサクセスの担当者と一緒に一つずつ定義を行い、まずはRedashやスクリプトなど手近(だけど面倒)な方法を組み合わせて手作業で定期的にデータを提供し始めました。しばらくするとこのデータはカスタマーサクセスの業務に取り込まれ、たまに更新が滞ったりデータに不整合が生じたりするとすぐに問い合わせが来るようになりました。

この段階で、上記の課題を解決するためにそのデータとそれを信頼性高く自動的に提供できる分析基盤の必要性を確認することができました。厳密にいうと十分性(分析基盤があれば課題が解決すること)はまだ確認できていませんが、そこは飲み込んで本格的な開発に踏み切りました。

3. 小さくつくる

本格的な開発を始めるといっても、いきなり大きなリソースを投下するのは得策ではありません。特にスタートアップではリソースが限られている上に激しい環境変化に晒されているので、いつでもピボット/撤退できるように初期のコストやスコープはできるだけ小さくしておくことが大事だと思います。

私もデータ分析基盤について様々な活用事例などを見聞きしてきたので、事業KPIの算出やプロダクトグロースへの貢献など、やりたいことがたくさん頭の中に浮かびました。しかし、あれもこれも手を出すと時間がかかる上にフォーカスのブレたものができてしまうリスクが高いので、まずはターゲットユーザーを「自分が担当している顧客のプロダクト利用状況を効率的に把握したいと思っているカスタマーサクセス担当者」に限定し、そのユーザーに刺さるかどうかだけで要件を絞りこみました。その要件に集中するために、開発中はカスタマーサクセス以外の部署への露出はかなり抑えました。

リソースを集中したこともあり、ほぼ狙い通りの時期にターゲットユーザーへ自動的に算出した指標を届け始めることができ、フィードバックをもとに提供するデータを段階的に充実させることができました。この頃、社内の勉強会にて「カスタマーサクセス活動の過去・現在・未来」というタイトルで、いかにデータを活用して効率的な活動ができるようになったかをカスタマーサクセスの方が話してくれました。それを聞いて「このターゲットユーザーに適切なものを提供できている」という確信を得ることができました。

4. データの提供方法を工夫する

データ分析基盤が使われない要因の一つに、ユーザーにとって価値のあるデータがどこにあるのか(そもそもあるのか)分からない、というものがあると思います。適切な変換を施したデータがデータマートにあるので後は好きに分析してください、というだけでバリバリ活用してくれるユーザーばかりであれば心配ないですが、そうでない場合はデータの提供方法に工夫が必要だと思います。

ユニファではデータの変換にdbtを使っており、そのdbtのドキュメント生成機能を活用することで、どこにどのように変換されたデータがあるのかをユーザー自身で確認できるようにしています。これだけでも効果はありますが、より一歩踏み込んだ対策として、Reverse ETLも活用しています。(最近ではData Activationと呼ばれることもある)Reverse ETLは、データ分析基盤からユーザーが普段利用しているシステムにデータを連携することを意味します。

具体的には、分析基盤上で変換を行って算出したプロダクトの利用状況を示すさまざまな指標を、カスタマーサクセスメンバーがメインで使っている業務システム上で確認できるようにデータ連携を行っています。普段の業務を行う中で分析基盤を経由したデータに触れることになるので、「せっかくつくったのに使われない」というリスクをかなり低減することができます。

5. 名前をつける

データ分析基盤という言葉はかなり堅い響きがあります。価値あるものをつくる、という意味では本質的ではないかもしれませんが、ユーザーにも開発メンバーにも愛着を持ってもらうために名前は重要です。Classiのソクラテス、リクルートのKnile、GMOペパボのBigfoot、など皆さんかっこいい名前をつけていますね。

ユニファの社名はUnify Familyから取っていることもあり、ユニファのデータ分析基盤はUnify Dataを意味するUnida(ユニダ)と命名しました。ちょっと発音しづらいこともあり最初は市民権を得られるか不安でしたが、今ではすっかり広まっていろんな部署でUnidaの名前を呼んでもらっています。

まとめ

お気づきの方もおられると思いますが、上記はプロダクト開発において推奨されるプロセスとほぼ同じです。Burning Needsを見つけ(1)、プロトタイプを作り(2)、PSFを確認し(2)、ペルソナを設定し(3)、MVPをつくって改善し(3)、PMFを実現し(3)、スケールする。UXも練り上げる必要があるし(4)、プロダクトには当然名前もつける(5)。

たとえ社内で利用するシステムであっても本当に意味のあるものをつくりたかったので、こうしたプロセスを意識して実践してきました。その結果、Unidaはカスタマーサクセスの業務にはなくてはならない存在となりました。その後全社的に露出を高めた結果、営業や開発、そして経営サイドからもUnidaを活用してこんなことができないか?という相談がたくさん舞い込み、まさに大きくスケールしていく段階になってきました。スケールさせるにはリソースが足りない、という新たな悩みは出てきましたが、せっかくつくったのに使ってもらえない、と悩む必要は無くなりました。

この記事が、これから「価値のあるデータ分析基盤をつくろう」と思っている方のお役に立てれば幸いです。


ユニファで一緒に働く仲間を募集しています!

unifa-e.com