イレギュラーが発生してしまうMRR管理に課題
――一方、サブスクリプションビジネスの重要指標のひとつであるMRRの管理に課題を抱えていたと伺っています。
清水 大型の資金調達やマーケティング投資を行っていると、ほんの少しでも対応を間違えてしまうと、まったく違う結果を引き起こしたり、無駄な投資が発生してしまったりする可能性があります。会社の成果に対して正しい判断ができる状態を常につくっておきたいと考えていました。たとえばリアルタイムで、どれくらい売上があるかMRRベースでビシっとメンバー全員の回答が一致する状態にしておきたい。しかし実際は、ビジネス側と請求や会計側に若干ずれがある状態であり、それを課題と捉えていました。
――急成長のなかで、統一のコスト意識を持つためにも、売上やキャッシュを見える化していく必要があったのですね。
清水 まずはきれいに契約状況を入力できるデータ構造を選びました。アップセルやクロスセル、ダウンセル……どの項目をどう見るかを決めていきました。
野田 契約管理におけるレギュラーの入力ルールが決まって、ある程度ここは契約完了後に自動で生成されるようにしていこうと考えていたのですが、BtoBのビジネスはどうしてもイレギュラー契約がつきものです。システム的な制限のせいで、販売の機会を逃してしまうことは、私たちのミッション上、許容すべきではありませんから、イレギュラーな契約に対しては人的チェックを実施しながら回していこうと決断したのですが、この自動と手動を組み合わせた運用が、Salesforceの標準UIだけでは難しいという壁にぶつかりました。
清水 RPAを組むという案もありましたよね。
野田 はい。しかし、RPAもイレギュラーには対応できません。すべてのユーザーの契約を手作業で管理するのは物理的に無理ですし、お客様によって契約形態も違うので、とにかく全部手動にも全部自動にもできない状態にありました。そこで、頭の片すみにあったExcelのような操作性でSalesforceにデータを入力できる「RaySheet」が、このMRR管理の業務に向いているのではないかと思いつきました。Salesforceを活用するうえで、もともと気になっていたツールでもあったので、すぐに検討を始めました。
清水 同時にいくつかのツールも検討しましたが、立ち上がりの早さとシステムの柔軟性からRaySheetに軍配が上がりました。また、もしもSalesforceのカスタマイズでつくり込めたとしても、開発と検証にかかる時間や複雑な開発によるバグ対応の手間を考えると、手動とExcelライクなアプリケーションの組み合わせが最適だと判断したのです。
野田 そのほかには細かい部分にはなりますが、RaySheetのデータ編集における柔軟性やUIの見やすさは決め手となりました。また導入当時はまだ取り組んでなかったのですが、Visualforceにおける拡張性もあるので、いざとなったら自分たちでつくりこむことを選択できる点も重要なポイントでした。当社はかなり戦略ドリブンですから、システム導入時はいつも拡張性を大事にしています。システムでできないから、この施策はやらないというのは絶対にありえません。「やると言ったら、やる！」組織なので、我々のようなポジションは少したいへんなときもあります（笑）。
ユーザーもかなり自発的に使いこんでくれている印象です。コアユーザーが20代後半から30代なかばで、Excelになじみがある世代であるため、いきなりSalesforceをさわるよりもむしろとっつきやすさがあるようです。利用シーンもさまざまですね。たとえば、ひとつの企業のお客様情報を確認するときはSalesforceのレコードで見たほうが網羅的で見やすいですが、とある条件のレコードを一気に表示し、一気に編集したいときはRaySheetを活用すると便利です。
図：Salesforce標準画面の表示とRaySheetでの表示の違い
