Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

【Eightの3つの新サービス(2)】個人向けアプリ上で法人向けサービスを開発した話:Eight企業向けプレミアム

Eight事業部の大熊です。Eightのアーキテクトをやっております。

今回は、個人向けアプリのEight上で提供されている法人向け名刺共有サービスである「企業向けプレミアム」について紹介したいと思います。

materials.8card.net

Eightを利用されている方であればご存知の通り、Eightは名刺でつながるビジネスのためのSNSとして個人が持つビジネスネットワークを活用していただくためのアプリです。「企業向けプレミアム」は、個人が持つ名刺を社員同士で共有することで、組織としても人脈を活用できるようにするサービスです。

共有する名刺情報はEightに既に登録されているので、サービス利用のために名刺を登録しなおしたり、データ化を待つ必要はありません。すぐに社員が持つ人脈を活用することができます。

個人向けと法人向けを両立させる難しさ

「企業向けプレミアム」のリリース当時、Eightには既に広告サービスなど法人向けの商品がありました。しかし、Eightアプリ上で個人ユーザーがダイレクトに利用する法人向けのサービスはありませんでした。 Eightは組織にしろアプリのデータ構造にしろ個人向けのアプリに最適化されていました。その状態でのリリースです。リリース以降、様々な課題に直面してきました。

その中でも、開発として特に困難だった課題は、個人向けと法人向けの仕様の両立です。この課題は今も完全に解決したとは言えない状況で、絶賛改良に取り組んでいるところです。

Eightの主要な仕様は個人が利用する文脈を前提に設計されてきました。仕様設計時に法人向けのサービスでよくある文脈、例えば管理者がいて、管理者が自社の社員(=自社のEightユーザー)をサービス利用のために管理するといった文脈は考慮されていません。そのため、サービスを利用してほしい社員ユーザーを招待する、という一見シンプルかつ重要なユースケース一つとってもハマりポイントがあります。

「企業向けプレミアム」を利用する社員ユーザーは、「Eightプレミアム」*1ユーザーになっていただく必要があります。名刺を共有する価値を最大限感じてもらうために高いデータ化品質を提供するためです。そのため、利用する社員ユーザー数に応じてアカウント利用料金をいただいています。

社員を「Eightプレミアム」へアップグレードする要件を、当初は個人向けに用意されていたアップグレード機構を法人向けに利用する形で実現しました。しかし、サービスを提供していく中で徐々に法人サービスの文脈では不都合な仕様であることが表面化してきました。特に、部署移動や退職等の利用者に変更があるタイミングで柔軟にアップグレード対象を変更できない課題が大きく、ユーザーからも改善要望が多くありました。アップグレードされる社員ユーザーとしては手間がかからない一方で、管理者ユーザーの目線で見ると負担がかかる仕様となっています。

この機構の上で実現可能な改善は続けてきました。しかし、個人向けの仕様としては要求を満たしていたため大幅な手入れをすることが難しく、根本的には解決されない状態となっていました。

利用ベースの課金体型へ

2019年10月に、「企業向けプレミアム」は課金体系を変更しました。

blog.8card.net

毎月の利用料金を、固定の基本料金と月ごとの利用実績で変動するアカウント利用料の合計で請求する体系です。これだけ聞くとSaaSによくある体系に聞こえます。月ごとの利用実績で変動するアカウント利用料 というのが肝です。従来では実現できなかった少しだけ試しに使ってみたいケースや、社員が部署移動や退職により利用を中止するケースに柔軟に対応できるようになりました。

そうです、ついに根本的な課題が解決されたのです。

改善のアプローチとしては、

  • 個人向けに設計されていた機構に手を入れて個人/法人の両方の文脈の要件を満たせるようにする
  • 法人向けとして扱いやすい形の全く別の仕様を設計する

の二択です。前者は従来から動いてたものに対する改修であるため、既に動作自体は保証されています。しかし、先に書いた通り個人/法人の異なる文脈から発生する要件を一つの仕組みで扱うことに限界を感じていました。そこで後者を選択し、アカウント利用料にまつわる設計を根本的に見直すことにしました。

「Eightプレミアム」にアップグレードする要件自体は特に問題ありません。そのトリガーに問題があるのです。個人としてのプレミアム体験はそのままにアップグレードのトリガーを独立した機構として用意することで、これまで扱えなかった法人向けの要件を柔軟に対応できるようになりました。

既にプロダクションで提供されているサービスに対する変更であり、また既存契約企業に対しての対応も検討する必要がありました。セールス、カスタマーサポート、社内の経理など各種部署を巻き込みつつプロジェクトを進め、無事10月に新規契約から新しい体系へ切り替えることができました。既存企業も11月下旬に切り替え予定です。

その要件は個人向けのみの文脈で考えるとどうなるか?

「企業向けプレミアム」は個人向けアプリのEightをさらに拡張するような法人向けサービスです。必然的に個人向けアプリの各種仕様、制約の影響を受けることになります。そのようなサービスを設計する場合は、法人向けの要件をいったん個人向けの仕様として整理し直すと良さそうだと感じました。

今回のケースであれば、元々欲しかったのは個人以外のエンティティにより特定のユーザーを「Eightプレミアム」にアップグレードする機構です。これを、まずは個人向けのサービスである「Eightプレミアム」の要件として設計します。「企業向けプレミアム」の設計としてはこの機構を利用するだけです。そうは言いながら双方の要件と照らし合わせながら設計するのは間違いないです。それぞれの文脈だけみて成立するか?と問いながら設計することで、個人/法人の仕様や設計が不必要に依存関係を持ってしまうのを避けることができます。

長々と書きましたが、関心ごとをちゃんと分けましょう、という話ではあります。ただ、分けるためのアプローチとして、特に個人/法人を同一アプリ上で提供する場合に、「法人向けの要件であっても個人向け要件として整理できるか考える」、というのが一つのアプローチになりそうです。

このシリーズの記事

buildersbox.corp-sansan.com

buildersbox.corp-sansan.com

buildersbox.corp-sansan.com

© Sansan, Inc.