”企業は、全然ユーザーの役に立たないものをつくる” SaaSのグローバルイベントで学んだこと
2022年9月にアメリカ・サンフランシスコにて開催されたSaaStr。現地で学んだB2B SaaS（ビジネス向けSaaS）の最前線を3つの記事にギュッとまとめてお届けします。今回はその第1弾です。
SaaStrとは、B2B SaaS最大のコミュニティです。毎年の会合では、注目スタートアップ企業のプレゼンテーション、メンターシップや協業のマッチング、VCとのmeetupなどが行われています。
今年は99か国から1万人以上が参加し、289人がスピーカーとして登壇しました。一部のセッションはSaaStr Annualの公式YouTubeにて公開されています。
freeeからは、プロダクトマネージャー・小泉とプロダクト企画職・内木の2名が参加し、成長のヒントを入手してきました。
キーワードは「ユーザーフィードバック」
今回のSaaStrでは、数多くのセッションで「ユーザーフィードバック（顧客の声）」というキーワードが出てきました。
SaaSの特徴として、ユーザーがパソコンにソフトウェアをインストールするのではなく、クラウド上にあるソフトウェアにアクセスして利用するものであるため、SaaS企業はソフトウェアに変更を加えやすいという強みがあります。
つまり、SaaSの成功の鍵は、ユーザーからのフィードバックを取り込みながら、従来にないスピードでどんどんソフトウェアをアップデートしていくことにあります。
特にB2Bでは、ターゲットとするユーザーの業務に寄り添うソフトウェアでないとまったく使ってもらえません。B2Cと同じようにデータから分析できる部分ももちろんありますが、B2Bではユーザーの本当のペインは何なのかを理解するために、ユーザーと対話しながらプロダクトを設計する必要があります。
そのため、プロダクトマネージャーとしては、プロダクトのビジョンをつくり、ロードマップに落とし込み、優先順位づけを行いながら日々の開発をする中で、ユーザーのフィードバックは最も重要なインプットとなります。
「ユーザーのフィードバックは最重要、そりゃそうだよね」と思う方こそ、ぜひこの記事を読んでほしい。SaaStrでは、フィードバックの活用レベルが私たちの想像を超えたものであることがわかりました。
この記事では、SaaStrのセッションから、私たちが本当にユーザーからのフィードバックを活かせているのか？とハッとさせられた発見をご紹介します。
どのユーザーからどうやってフィードバックを集めて、どう解釈して、どうプロダクトへの反映の意思決定をしていくのか、そのサイクルをどう回していくのか・・・B2B SaaSだからこその難しさと楽しさが詰まった部分かもしれません。
1. 本当にユーザーに使ってもらうものを作るには
Stripeの「エクストリーム・プロダクト・デザイン」
StripeのCTOは、ウォーターフォール型のソフトウェア構築プロセスを引き合いにだしながら、「企業はユーザーにとって全然役立たないものをつくる傾向がある」と指摘します。
Stripeとは、2010年に創業された個人事業主や大企業まで使える決済サービスです。高機能で開発しやすいAPIを提供していることが特徴の一つで、1秒あたり最大1.3万APIリクエストを処理するほど利用されています（ちなみにfreee会計でも、このAPIを利用してStripeユーザーの決済データを取り込める機能を提供しています）。
Stripeでは「エクストリーム・プロダクト・デザイン」という手法を用い、ユーザー第1に行動することで、ユーザーが求める革新的なプロダクトを世に出しています。
例えば、Stripeの初期ユーザーであるLyftとタクシーマッチングサービスを共同開発した事例では、Lyftユーザーの決済ペインを解消するため、ドライバーアプリでは従来の決済サービスよりも売上の入金サイクルを早め、乗客アプリではユーザが望むどんな支払方法も使える機能を提供しました。
これが他社との差別化になり、当時タクシーマッチングサービスが乱立する中で、Lyftのマーケットシェア拡大につながったそうです。
①適切なユーザーからフィードバックを得て、素早くイテレーションを繰り返す
エクストリーム・プロダクト・デザインの1つ目のポイントは「適切なユーザーからフィードバックを得て、素早くイテレーションを繰り返すこと」です。
イテレーションとは、アジャイル開発における設計、開発、テスト、改善の開発サイクルのこと。
プロダクトをできるだけ早くユーザーに届けるほど、サービス提供側が「たぶんユーザーはこうだろう」と推測する無駄を省き、ユーザーの実際の反応に基づいて、本当に必要な機能の開発に時間を費やせるようになります。
例えば、特定のユーザーだけにベータ版のAPIを提供して、本当に動くプロダクトでフィードバックを得て改善をした上で、全ユーザに公開するという手法もとっているそうです。
②摩擦を見つけ、すぐに取り除く
2つ目のポイントは「摩擦（friction）を見つけ、すぐに取り除くこと」です。
すぐにって、どれくらい「すぐ」だと思いますか？
StripeのCTOによると「1日以内、理想的には1時間以内」だそうです・・！
フィードバックをもらっても、リリースまでに時間がかかっていてはダメ。変更がまだ簡単なリリース初期の段階から、フィードバックのループを回します。
フィードバックのループにおける課題特定から改善までの間隔が、プロダクト改善のレベル、ひいては、マーケットシェアや長期的な品質を決めるのです。
ユーザーフィードバックのループを1時間で回すには、フィードバックを得る前から、プロダクト改善の環境が整っていなくては無理ですよね。
③チームとプロセスを改善し、学び続ける組織になる
そこで最後のポイント「チームとプロセスを改善し、学び続ける組織になること」が重要になります。
フィードバックを集める仕組みに投資することに加え、開発文化として透明性が高くコラボレーションがしやすいこと、エンジニアやデザイナーの生産性を向上するため専門のチームを置いて社内ツールを整備することが必要だそうです（freeeでいうと、GYOMU HACKチームの取組かなと想像しています）。
この社内ツールについても社内でフィードバックのループを回して、日常的に生産性向上のための改善を続けていればこそ、ユーザーからのフィードバックを１時間で反映できる基盤や文化ができるのだろうなと思います。
StripeユーザーのLyftの事例のように世の中を便利にする新しいサービスの創出の裏側には、「エクストリーム・プロダクト・デザイン」によるユーザーフィードバックのループを強固にする取組がありました。私たちも見習わねば・・・！
２．拡大フェーズのSaaSが陥りがちな課題
mParticle, Confluent, Criblといったデータカンパニーのスピーカー4名の対談では、拡大フェーズのSaaS企業が陥りがちな課題についての言及がありました。
CriblのFarrah Buiさんは、「会社が大きくなるにつれ、ユーザーとの直接的な繋がりが薄れ、ユーザーが自分たちのプロダクトから享受している価値を深く理解できなくなってしまいがち」と危惧しています。
組織が大きくなると、必然的にユーザーと関わる担当者が増え、部署によって使うチャネルが異なる、なんてことも。また、プロダクトのモジュール間や、セールス・マーケティングなど社内のステークホルダーの「調整ごと」も増えていきます。
プロダクト起点でビジネスを伸ばし、組織としても大きくなりつつあるfreee。プロダクト組織の一員としては、かなりグサッとくる内容でした。
では、どのようにすれば、組織が拡大フェーズにあっても、ユーザーから目を逸らさないプロダクトづくりが可能なのでしょうか？
mParticleのShradha Kothariさんは、より具体的に事例を紹介しています。
①ユーザーフィードバックを収集するとき
組織の規模が大きくなると、さまざまなチームが異なるツールを導入することは珍しくありません。しかし、チャネルが複数ある状態で、フィードバックを収集しようとすると、煩雑かつ情報過多になりがちです。
そこで、フィードバックを回収するためのツール・チャネルは1つに統一すべきだと、Shradhaさんはいいます。
組織が大きくなると、営業・カスタマーサクセス・サポートといった業種ごとに異なるツールが導入されるというのはよくあること。しかし、「フロー全体を最適化する」という目的から、ツールを理想ベースで考えることも大切なのだと学びました。
②ユーザーフィードバックを精査するとき
プロダクト開発に携わる身としては、自分たちのやり残していることやロードマップに乗っているものに対してのフィードバックが欲しくなりがちです。しかし、そのようにフィルタリングされたフィードバックのみでは、イノベーションは起こらないだろうとShradhaさんは指摘しています。
一方で、すべてのフィードバックを開発ロードマップに加えるのは現実的ではありません。Stripeのように1時間で1つの改善を繰り返しても、寄せられるすべてのフィードバックに応えることはできないでしょう。
いやいや、どうすればいいんだ・・・！とツッコみたくなりました。
ここからは私たちの解釈ですが、やるべきは、開発ロードマップを一旦傍においた上で、要望の裏側にある「ユーザーの課題そのもの」に対して優先順位をつけるということではないかと思います。
そして、ここで重要なのは、意志をもって進めるオーナーの存在です。仕組みがあったからといって、おそらくこの課題の見極めプロセスは機能しません。ユーザーのペインを理解しつつ、フィードバックの優先度を定めていくことが、オーナーには求められているのではないでしょうか。
早速、社内での取り組みもスタート！
SaaStrから持ち帰ったノウハウをヒントに、社内では早速、ユーザーフィードバック・サイクルの改善に向けたプロジェクトが推進されています。
せっかくお客様が届けてくれたフィードバックだからこそ、1つ1つ丁寧に精査し、開発チームに届ける。実際に機能がリリースされたら、フィードバックを上げてくださったお客様に、きちんとお伝えする。freeeのプロダクトが、お客様のペインを解消しながら成長していけるよう、引き続き頑張ります！このプロジェクトの進展は、いずれまたどこかで発信できればと思います。
次回は「B2B SaaSにおけるプロダクトマネージャーの役割とは？」というテーマでお送りします。お楽しみに！
freeeは「あえ共freee」というマガジンから、freeeの事業や組織に関する情報を発信しています。フォローしていただけたら嬉しいです！
この記事が気に入ったらサポートをしてみませんか？