【PLG】Spirが実践するプロダクト開発で重視する4つの原則
日本のSaaSスタートアップ最前線で、Product-Led Growth（以下、PLG）に挑戦しているSpir。前回は創業の裏側についてSpir CEOの大山氏に語っていただいた。
PLG連載企画の2本目となる今回は、Spirというプロダクトがいかにして生み出されたのか、プロダクト開発に焦点を当てて掘り下げていく。（聞き手は、UB Ventures 大鹿琢也）
Time to Valueの徹底追求
大鹿 前回のインタビューでは、PLG戦略の中心となるコンセプトとして、ユーザーが直感的に利用し価値を感じてもらう、という一連のユーザー体験の追及がプロダクトの重点となることをお話しいただきました。
今度はより具体的な設計について教えてください。特に、ユーザーへの価値訴求において何を強く意識しましたか。
大山 一番大事なのはやはりTime to Value、いかに早くバリューを感じてもらうかだと思います。究極は半自動的に日程調整ができる世界を作りたいので、"半”自動の半分に人が介在する際に、いかにストレスなく感覚的に日程調整を済ませられるかを意識してデザインしました。
我々はカレンダーアプリに慣れているので、使いこなせるのは当たり前だと思ってしまいます。しかしGoogleカレンダーを初めて見た人は、意外と複雑で難しいと感じますよね。
Spirでは「予定管理」をするカレンダーと全く同じインターフェース上に、「日程調整」という別のオブジェクトを乗せているので、ユーザーのアクションとしては複雑性が一層増しています。普通はカレンダーで日程調整をしたことがないので、ユーザーは何をしたら良いか分からなくなりやすいです。
「予定管理」と「日程調整」を行うプロダクト画面
Spirについて
SpirはGoogleカレンダーやOutlookなどのビジネスで利用している複数のカレンダーと連携し、Google MeetやZoomなどのWeb会議の日程調整からカレンダーへの登録までをワンストップで行うことが出来るカレンダープラットフォームです。
例えば日程調整の際に、送られてきた候補日の中から予定を確定するとき、自分のカレンダーを見て前後の予定も見たくなると思います。場合によっては、それらの予定を編集してずらしたいこともあります。
日程確定ページに予定を編集する機能も必要なのか、あるいは日程確定のページから予定編集のページに遷移するのか。こうした条件分岐がかなりあって、そのプロセスの設計は相当複雑です。
しかし実際にカレンダーを使っていると、日程を調整している際に予定を編集したくなりますし、その逆もある。結局どちらもやりたくなるんです。両方可能にしないといけないんですが、その塩梅が大事で、なんでもできてしまうとユーザーを迷わせてしまいます。
Spirも試行錯誤を繰り返して今のプロダクト設計になっていますが、それでもユーザーには「難しすぎる」「可能なアクションの数が多すぎる」と言われるので、まだまだ迷わせているなと思っています。シンプルさを保ちながら、どうやって全てのパターンに対応するか、非常に苦労しながらデザインしています。
"気持ちいい体験”の創出がプロダクト開発の成否を決める
大鹿 私はβ版から利用させていただいていますが、Time to Valueのバリューについて言えば、Spirの根源的な価値は初期からあったのではないでしょうか。候補を自動抽出し、日程調整をURLで簡単に送れて、確定後はZoom URL等が入った状態で双方にカレンダーが共有されるというプロセスを、Spirでは初期段階から一気通貫で体験することができました。
大山 しかし、そうした体験はCalendly（カレンドリー）のような既存の日程調整ツールでもできます。それでは何が違うんでしょうか、といった話をよく機能軸でされますが、もう機能で比べる時代ではないと思っています。
例えば、上流から下流の様々な調整に付随する業務を自動化していくことで、価値を追加することも可能です。具体的には、Spirで日程調整をした相手の情報をATS（採用管理システム）やSFA（営業支援システム）に登録する、相手にメールでリマインドを送る、アンケートフォームを取る、といったように自動化できるプロセスは他にも沢山あります。ですが、それはあくまで機能の価値です。
今までSLG（Sales-Led Growth）がやっていたような、特定のペインを解決できる単一機能での勝負ではなく、プロダクト全体を通じた体験が"いかに気持ちいいか”の勝負だと考えています。Calendly、YouCanBook.me、TimeRex、eeasy、Spirがやっていることは同じですが、「Spirを使う方が気持ちいいよね」と言ってもらわないといけない。
PLGとSLGのチェックリスト（詳細はこちら）
大鹿 PLGの場合、多くは既存のサービスが存在するレッドオーシャンでの戦いです。求められる機能があることは前提となり、機能での戦いではない。選ばれるためには「ユーザーにとって"気持ちいい"サービスかどうか」が重要ということですね。
では、"気持ちいい体験”って具体的にはどのようなものでしょうか。
大山 例えば「ECで買い物するときに何故Amazonを使いますか？」という質問に近いです。機能としてできることはほとんど同じですが、Amazonで買うと少しだけ届くのが早い、少しだけ商品が探しやすいといった差だと思います。
あるいは、SlackやZoomがなぜプロダクトとして評価されたのかも同じことです。自由度の高い絵文字機能や通話品質が評価されることもありますが、本当に通話品質が良いと思ってZoomを選びましたか？（笑）機能の違いではなく、ストレスを感じずになんとなく気持ちいい体験ができたからではないでしょうか。
バリューについて単純化したくなりがちですが、人間は複雑系なので明確なものではないはずです。だからこそ、プロダクト全体を通して「やっぱりこれなんだよな」という心地よさを生み出せるかがPLGにおいて非常に重要だと思っています。
"気持ちいい体験”は言語化が難しいです。もちろんエンジニアなど社内メンバーとも議論しましたが、ある程度事業が軌道に乗るまでは、プロダクトマネージャーとして私が最終的な意思決定をしてきました。こだわるポイントが細かすぎるとメンバーから何度も言われましたが、そのちょっとの差で全然違ってくると思います。
大鹿 「神は細部に宿る」ということですね。繰り返しにはなりますが、PLGでは、こだわりぬいたユーザー中心のサービス設計が差別化になります。一方で、こうしたプロダクトづくりにはやはり相応の時間・労力が必要になるかと思います。
競合サービスも既にある中で、プロダクト開発の場面で焦ることはありませんでしたか。
大山 我々がサービス始めた頃には、Calendly、biskett、TimeRexといった既存の競合ツールにお金を払っている人達がいたんです。
MVP（Minimum Viable Product）はそれらを参考に一定つくることができますし、その先での有料課金ユーザーの獲得も見えていたので、それほど焦っていませんでした。むしろそこに上乗せする構想を作りきれるかどうか、そしてマーケットシェアが取れるかどうかが重要でした。
一方で、PLGで取り組む領域はレッドオーシャンでの後発のサービスなので、最低限必要とされる機能の水準が高いです。カレンダーや日程調整ツールとして必要な機能は、ベータ版リリースの頃には揃っていました。その中で"気持ちいい体験”ができるというのはどういうことか、アクティブ率やリテンションをどう高められるかを現在は試行錯誤しています。
ジャーニーマップの作り込みによるユーザー体験の設計
大鹿 "気持ちいい体験”を、"いかに早く届けるか”が、まず初めに重要だということですね。
一方で、言語化が難しい"体験の気持ちよさ”をどのようにプロダクトへと落とし込んでいったのでしょうか。
大山 私の場合は、自分の中でカスタマージャーニーマップを詳細に描いています。ジャーニーマップの中で、自分が一番引っかかる点はどこなのか、行動パターンにはどのようなオプションが必要なのか、オプションを削るならどういった優先順位なのかを、きちんと捉えて設計するということです。
ジャーニーマップを描いたときに、入口から終わりまで最低限繋がった体験として提供できないといけません。例えば日程調整においては、候補を出すことは必要なプロセスの1つですが、「どうやって候補を出したいか」というディテールまでこだわって考えるのが、気持ちよさに繋がると考えています。
日程調整の候補を出すこと自体はどのツールでもできますが、そこに違いがあるんです。ベストなユーザー体験を創出するために、ユーザーの各ファンクションにおけるジャーニーマップを作成し、それを見ながらUIを作りますし、どういう順番で体験してもらうかにも相当こだわっています。
大鹿 一連のユーザー体験を記した設計図として、ジャーニーマップを作り、どのような体験が適切かあらかじめ検証をしているのですね。
実際に、ジャーニーマップ自体はどのようにして作成されているのでしょうか。
大山 自分がカスタマーになりきれれば「こういうパターンもある」「この場合はこうしたい」といったジャーニーマップが見えてきます。そうすればジャーニーマップ自体は作れますが、それをプロダクトで実現する際には非常に多くのコンフリクトがあって難しいです。今はユーザー体験をどのようにプロダクトに反映するかに注力しています。
究極的には、候補日時の自動抽出ボタンを押したり、予定にタイトルを入力したりするというプロセス自体も面倒なはずです。日程調整をする際は、まずは候補日時やタイトルが入力された状態で出てきて、あとは微調整すればよい、という半自動化された状態を目指していきます。
プロダクト自体をグロースのための弾み車とせよ
大鹿 "気持ちいい体験"を重視したこと、そのために"ジャーニーマップ"を描き細部まで検証をしていること、Spirの根幹にあるPLGならではのプロダクト開発について教えていただきました。
この他にも、プロダクト開発で意識されたことはありますか。
大山 私は、グロースサイクルをプロダクトでどのようにつくるかを、中長期的な目標として初期の頃から意識していました。アクティベーション（プロダクトの本源的価値が届く）、リテンション（価値を感じて継続される）、バイラル（潜在ユーザーに拡散される）、コンバージョン（バイラルした人が登録する）という4ステップが自然に回らないと、取っても取っても溜まらない生け簀になってしまいます。4ステップそれぞれのファネルでやるべきことはあるので、時期によって注力していたことは違いますが、最終的にそのグロースモデルが回っていないとPLGモデルの意味がありません。獲得したユーザーがプロダクトに満足し、使ってリテンションしていく中で、他のユーザーが増えていくような設計を心掛けています。
Spirでは「ユーザーのアクティブ率」＝「ユーザーが日程調整を主催する割合」だと考えています。Spirに登録したら必ず日程調整を主催する状態になれば、グロースサイクルが勝手に回るようになっているはずです。そうすれば、プロモーションやバイラルを加速させるための設計、あるいはモバイル対応や英語対応も検討したいです。
大鹿 リアルな事業のお話をありがとうございました。今回のお話の中で、Spirがプロダクト開発で大事にされている4つの原則が見えてきました。
第一にTime to value。ユーザーがプロダクトを直感的に利用することができて、その価値を素早く感じられる必要があります。その際に、機能の価値を届けるだけでは不十分で、その先のユーザー体験全体の"気持ちよさ”を追求していくことが重要です。
この追及にあたり、開発の指針になっているのが、顧客目線で作り込まれたジャーニーマップでした。設計された一連のプロセスによって、価値を感じたユーザーが使っていく中で、自然とバイラルして潜在ユーザーを呼び込み、彼らがコンバージョンしてユーザーとなります。こうしたグロースモデルをプロダクトに埋め込むことで、まさにPLGの真価が発揮されるのです。
次回はSpir CEO大山さんへのインタビュー記事の最終回です。Spirがいかにして成長を測り、次のアクションにつなげていったのかを伺います。
■ UB Ventures 大鹿琢也 プロフィール
大鹿 琢也 Takuya Oshika UB Ventures プリンシパル
青山学院大学 国際政治経済学部卒業。2013年にユーザベースに新卒1期として入社。入社2年目にSPEEDA Customer Loyaltyチームのリーダーを歴任。2014年末から香港に赴任、アジア事業の立ち上げを、岩澤（現UB Ventures代表）と共に推進。2018年から、Head of Asia Customer SuccessとしてCSチームのマネジメント、アジア事業企画・開発などを経験。2021年2月にUB Venturesに参画。
■ 参考図書・記事のご紹介
これまでUB Venturesでは、PLGの概念についてリサーチし、レポートを執筆してきました。そのなかで、UB Ventures監訳にて体系的にPLGを説明する解説本も刊行しております。
■ Spirについて
SpirはGoogleカレンダーやOutlookなどのビジネスで利用している複数のカレンダーと連携し、Google MeetやZoomなどのWeb会議の日程調整からカレンダーへの登録までをワンストップで行うことが出来るカレンダープラットフォームです。
__________________________________________________________________________________
編集：西谷 崇毅 | UB Ventures インターン
2021.11.15