カスタマーサクセス|書籍|英治出版
第I部 カスタマーサクセスの歴史、組織、必要性第1章 サブスクリプションの津波第2章 カスタマーサクセス戦略第3章 定期収益型でないビジネスにおけるカスタマーサクセス ...
http://www.eijipress.co.jp/book/book.php?epcode=2260
こんにちは。バルス採用ブログ編集部です。
今回は、バルスが展開しているSPWN Portalというサービスの、開発にまつわる取り組みやカルチャーをご紹介します。
SPWN Portalは、動画配信、チケット販売、グッズの販売、ギフティングやファンクラブの運営といった機能を、1つのWebアプリケーションの中でワンストップで利用できるプラットフォームです。
これにより、アーティストは、サービスを利用するファン(ユーザー)のデータを活用し、安定して収益を生み出すことができるようになります。
私たちにとってのユーザーはアーティストとファンであり、BtoBtoCというビジネスモデルになっています。
2020年4月に新規事業として一般リリースをしましたが、それ以前からベースとなるサービスは存在していました。バルスは創業当初は、バーチャルアーティスト(いわゆるVTuber)のARライブ事業のみを行っており、当時からライブの動画配信やチケット販売・投げ銭するための機能が必要だったため内製した、というのがSPWN Portalのルーツです。
コロナウィルスの影響で、アーティストが表現の場をオンラインに切り替え始めた時流に合わせ、一般向けにリリースをしました。
2020年までは、とにかく開発速度を重視してリリースし、貯まっていく技術的負債を横目にユーザーの声を吸い上げて改善していくことに注力をしてきました。しかし、嬉しい悲鳴ではあるのですが、急激にユーザーが増えたことで、グロースするための要件に対して開発が追いつかなくなってきました。
それが如実に現れた最も大きな事例として、2020年の年末に開催された、数万人が視聴する大規模なライブ配信でした。アクセスが集中すると、システムの安定のために1分間の販売枚数を制限する必要が出てきました。当時、アクセスが集中し負荷がかかることは想定していたのですが、その経験が十分ではないため未知数な部分が大きかったのです。
2021年に入ってからは早速改善に取り組みました。まずは、現状のスペックを計測するところから始め、ボトルネックを調査し、チーム全体で現状を認識しながら、どこをどう改善していくかを話し合って実装していきました。一ヶ月ほどで秒間800枚程度までは売ることができるところまで改善しました。
今年の2月に同規模のイベントがありましたが、その時は何のトラブルもなく終えることができ、確実に前進できたと実感できるものでした。更なるスペックを求めて現在も改善を続けています。
このように、スピード重視で作ってリリースしてきた時期の技術負債はまだ山積みですが、着実に解決に向けて進めています。
ワクワクする未来の話をします!
今後、実装していきたいアイデアは豊富にあります。
何を優先して実装していくかは、サービスの性質上、withコロナという時世では大いに変わってきます。
ここでは、アーティストがafterコロナを見据え、リアル会場でのイベント開催に向けて動き始めている中で、私たちがチャレンジングに取り組んでいるものをご紹介します。
会場での物販を想定した便利アプリケーション
ユーザーは、SPWN Portal上で予め決済しておけば、会場でQRコードを提示するだけでスムーズな受け渡しができるような、運営サイドで使用するアプリケーションの開発を進めています。これには、在庫の処理が最適化されている必要があり、クイックレスポンスなデータの管理や運用が求められます。
最終的には、倉庫システムと連携させることで、会場の在庫が少なくなると倉庫から自動発送し、会場に商品が補充されるような世界を目指しています。
インフラは可能な限りフルマネージドなサービスを使用しており、動画配信はAWSを、アプリケーションはFirebaseを使っています。
動画配信周りは SPWN のキモとなる技術で、AWSのリソースをフル活用し、低遅延で大規模ユーザーが視聴可能なインフラを構築しています。
また、データ周りはFirestoreというデータベースを使っています。Firestoreはリアルタイムアップデートの機能があり、データの変更をリアルタイムに、そして簡単にクライアントに反映することが可能です。この他にも、提供されているAPIがプロダクトとの親和性が非常に高いため、機能をフル活用しています。
アプリケーションは、フロントエンドは TypeScript と React、バックエンドは Node.js on Firestore Functions という構成です。あまり特殊なことはしていませんが、フロントエンド・バックエンド共に TypeScript で書けるのでコンテキストスイッチが最小限でコードを行き来できるようになっています。
また、BI用のデータマートへのデータの同期のコードなど、アプリケーション周辺のツールも可能な限り TypeScript で書いています。
ここからは、カルチャーの話になります。
会社として、OKR(Objective Key Result)という目標達成のためのフレームワークを取り入れています。会社のOKRが1本の大きな幹として存在し、そこに各チームが枝となり、QuarterごとにOKRを定めていきます。
一般的に、組織の規模が大きくなり、経営との距離が離れていくにつれて、自分が何のために働いているかが分からなくなってしまう傾向に陥りがちで、実際にバルスも昨年まではその状態でした。そこで代表からの声かけで、今年から運用を始めました。
まだ1Qを終えたところですが、会社の目標がクリアになったという感想を持つメンバーが多く、また会話の中でもOKRというワードがよく出てきており、ポジティブに働いています。
2021年のOKRです。
基本機能というのは、イベントページの作成や、配信の開始・終了、チケットの設定などを指していて、主催者側で管理画面上で完結できるようにすることを目指しています。
OKRにはチェックイン・ウィンセッションといったセレモニーがあります。 チェックインはその週にやることを確認し、ウィンセッションはその週の成果を確認します。
開発者ならこれに似たフレームワークを耳にしたことがあると思います。そう、スクラムです。 SPWN Portal の開発チームは、OKRのセレモニーをスクラムのセレモニーにマージして長期目標をスプリントという短期のスパンに分割して追うようにしています。 こうすることで、OKRと開発内容が乖離せず、またチームメンバーも目標を見失うことがなく日々開発することができています。
開発チームの体制は、PdM1名、エンジニアが6名(うち業務委託の方が1名)です。
スクラムの手法を取り入れていて、週次でスプリントを回しています。
スプリントの始まりには3時間以上の時間をかけて、その週に取り組むチケットについてチーム全員で話すプランニングを実施します。
まず、どのように実装するかをチーム全員の認識を合わせます。次に、その実装にどのくらいのコストがかかるのかを見積もり、コストが大きすぎる場合はチケットを分割します。最後に、誰が実装するのかを決めます。 ここに大きく時間を割くことで、誰が実装するのかに関わらず、どのように実装されているのかの共通認識を持つことができます。これは各開発者のチーム感にもつながってくるようです。
スプリントの終わりには、そのスプリント期間中に実装したものを可能なら画面を見せつつデモします。このレビュー会にはカスタマーサクセスのメンバーも参加し、顧客影響のある機能を早めにキャッチアップしています。 その後、スプリントの振り返りを行います。この会では、スプリント期間中に起きた問題とそれをどう解決したのかをチームメンバーに共有します。今後同様のことが起こらないように何をするべきなのかを話し合います。このレトロスペクティブにもカスタマーサクセスのメンバーが参加していて、顧客に影響が起こらないためにどうすべきかを一緒に考えてもらいます。
また、カスタマーサクセスが中心となり、毎週輪読会というイベントをおこなっています。カスタマーサクセスにとって、エンジニアは社内で最もコミュニケーションを取る機会が多いため、「カスタマーサクセス」の定義と責務をエンジニアが理解することで、円滑なコミュニケーションに繋げます。
具体的には、カスタマーサクセスの青本があり、毎週、参加者が章ごとに代わる代わる読み、要点を説明していきます。「バルスならこういうCSのやり方があるね」というアイデア出しにも繋がります。
現在は、ビジネスサイドのメンバーも参加し、「THE MODEL」を読んでいます。そもそもプロダクトは、ビジネス側の要求を実装することで成り立つため、ビジネスサイドとのコミュニケーションは必要不可欠です。ビジネスサイドではどんな思考のもと企画をおこなうのか、どのように周りの部署と連携していくのか、それぞれが正しくあるべき姿とは?絶賛輪読中です。
バルスでは、エンジニアを積極採用中です。
転職するかどうかは未定だが、話を聞いてみたい、という方も大歓迎です!
エントリをお待ちしています。