こんにちは。モノグサ株式会社で Customer Reliability Engineer（以下、CRE）として働いている大野です。
モノグサにおける一人目のCREであり、日々CREとして何をするべきか考え試行錯誤しながら業務に取り組んでいます。今回、「モノグサにおけるCREがどのような職種か？」ということについて、日々考えていることを紹介していきたいと思います。この内容は全部で3回に分かれており、その3回目になります。
Part1はこちら tech.monoxer.com Part2はこちら tech.monoxer.com
今回はCustomer Success（以下、CS）と共に行っているヘルススコアのデータ環境整備について紹介します。
ヘルススコアとは
ヘルススコアとは顧客の活動状況からプロダクトの利用状況を評価する指標のことであり、解約防止や顧客の成功を予測し、より良い方向へと導く事に活用される指標です。SaaSビジネスにおいてはLife Time Value（以下、LTV）を高める重要性が広く認知されていますが、ヘルススコアは最終的にはLTVを高めることにもつながる重要なものさしであります。モノグサではヘルススコアを日々確認し契約いただいている組織（顧客）の状況を把握すると共に、ヘルススコアを良い方向へと導く施策を進めております。実際に取得している具体的なヘルススコア指標についての説明は今回は割愛したいと思います。
直面した課題
ヘルススコアの取得を開始したのは2020年の夏頃からであり当時はCSのメンバーがメインで取り組んでいました。Redashでヘルススコアの元となるデータを取得して、その値をGoogleスプレッドシート上に組み込まれた複雑な関数が処理して結果を出力するという仕組みです。 当時直面していたのはGoogleスプレッドシートを利用していたことに起因する以下のような課題です。
Googleスプレッドシートセル上限問題
Googleスプレッドシートは一つのBookのセル数に上限があります。さまざま関数を組んで複雑に計算式を組み上げていった結果、当時のセル数上限である500万セルに近づいていました。また複雑に関数が組み込まれているため、上限を超えないように工夫しようとするとどこかでエラーが発生し、連鎖的に他の箇所でもエラーが発生していました。そもそも関数の処理自体が非常に時間がかかることや、それらの管理コストが大きいという課題がありました。意図しない書き込みが起こりうる問題
Googleスプレッドシートでヘルススコアを確認中にセルに誤って文字を入力し、それに気付かずにセーブされてしまうことで意図せずに入力が書き変わってしまうことが発生しうる状況でした。しかし、その管理は現実的ではないため、意図しない書き込みがない前提でヘルススコアを活用していました。データ格納先が変更される問題
Googleスプレッドシート上のデータの格納箇所や形式が変更されることもあり、以前利用したデータを再利用するとなるとデータを探し直す必要が発生していました。ヘルススコアを活用した継続的な解約予測やアップセル予測をすることが難しく、その場限りの解析しかできない状況になっていました。
上記のような課題からヘルススコアを運用するにあたって管理コストが高く、現状の方法では残り半年で運用ができなくなるという状況になっていました。そのため短期間で上記の課題を解決する方法を考え、実行する必要がありました。
課題をどう解決したか
課題を解決するにあたり、ヘルススコアは社内の共通言語でもあることからエンジニアに寄りすぎない使われ方にすべきだと考え、また課題の緊急性の高さを踏まえて速やかに解決する方法を模索しました。当初はGainsightなどのCSソフトウェアを導入することも検討していましたが、導入に際してネガティブな部分を解消することができず、特に課題解決までの時間が不足することから、既存のシステムを大きく変更せずに解決することを模索しました。
これまではGoogle Apps ScriptとRedash APIを用いてデータを取得して一つのGoogleスプレッドシートへデータの書き込みをしていました。そのデータを複雑に組み込まれた関数で処理し、Googleスプレッドシート内の別シートにヘルススコアとして算出していました。これらの既存のシステムを活用しつつ、データを蓄積するシステムを構築し、必要なときに必要なヘルススコアデータを誰でも取得できるようにしました。
解決に当たっては以下の手順を踏むことでデータを日付別に記録できるようにしました。
Redashで作成しているクエリの整理を行い、組織単位で集計するようにする
以前はRedashで必要なデータをほぼそのまま抽出してGoogleスプレッドシート上で集計している箇所が存在していましたが、その部分をRedashのみで完結させるようにしました。Redashからデータを取得した際にはそのデータをそのままCSVでGoogle Driveに日付別に取得できるようにする
これによりデータの意図しない書き換えに対して復元が速やかに可能となると同時にGoogleスプレッドシートのセル数上限問題も解消することにつながりました。CSが利用するGoogleスプレッドシートへの最新データの更新を毎日実施する
最終的にはCSが使いやすいようGoogleスプレッドシートに結果を書き込むことにしたため、意図しない書き換えを完全に防げるわけではないですが、毎日定期実行され記録を最新の状態に保つことができるようにしました。これにより複雑な関数を管理するコストや過去の記録を手動でコピーする作業が不要になりました。
上記の対応により、当初抱えていたセル上限問題や人為ミスによる書き込み問題を解決する方法でデータを取得することができるようになりました。そしてデータの形式も統一的に取得できるようになったことでデータを分析することも比較的容易になりました。
これから
既存のヘルススコア運用に関連する緊急性の高かった課題は解決できたものの、ヘルススコアやデータ分析環境整備についてはまだまだ改善する余地はたくさんある状況です。最初の記事で、CREという職種は「お客さま自身がプロダクトを管理できる環境をエンジニアリングの力で実現する」ことが求められると書きました。ヘルススコア自体が「お客さま自身がプロダクトを管理できているか」の指標であり、ヘルススコアを設計することこそがCREの業務の根幹となります。そのため今後もCSと共にヘルススコアの改善を進めていきたいと思っています。
また、今回の記事では詳細を書きませんでしたが、解約やアップセル状況を踏まえた新しいヘルススコアを設計をするために機械学習によるデータ分析にも取り組みました。さまざまな文献を参考にしつつ、解約やアップセルに大きく影響する指標をデータ分析から洗い出しをし、最終的にデータ取得のシステムを構築するのと同時に新しいヘルススコアを設計することができました。
データ分析については個人的には興味のある分野で社内でもっと取り組みたいと思っているのですが、現状モノグサではその環境の整備がなかなか進んでいない状況です。また本記事の執筆時点で、モノグサではデータエンジニアという職種の募集はでているのですが、データエンジニアとして働いている社員はいません。現状では組織単位での分析を行っていますが、将来的にはユーザー単位での分析を実施することになるかもしれず、その場合には既存のデータ解析環境では対応しきれないことが多く発生すると考えられます。中長期的視点でのデータ解析環境の構築を今後しつつ、新しくデータエンジニアの採用があればその方と共に環境整備をしていきたいと思っています。
Monoxerは長期間・長時間利用してもらうことで本当の価値を感じてもらうことのできるサービスのため、第一にお客さまからの信頼が欠かせません。モノグサのプロダクトやCREについて興味を持った場合にはお気軽にご連絡ください。
