みなさんこんにちは。株式会社ベーシックの甲斐（@Kai_MSYK）と申します。

ベーシックでは「PLG事業部」という名の、PLG型（Product-Led Growth）のSaaSを開発・提供する部署が存在します。私はその中で PdM（Product Manager） 兼 新規事業開発担当として、PLGの奥深さを日々感じながら働いています。

さて、今回のnoteでは、そんなPLGの事業成長を実現するための一つの手段であると言われている「ボウリングレーン・フレームワーク」をチームで運用してみた話を紹介したいと思います。

「ボウリングレーン・フレームワーク」は、ここ数年でSaaSの運営に携わる人へ徐々に広まってきており、以下の書籍でも紹介されている概念です。

端的に言うと、PLG型のサービスにおける「オンボーディング施策」のための概念ですが、こちらの書籍以外でその詳細が語られる機会は、 Web上でもまだまだ少ないのが現状です。また、実際に施策として取り入れている企業は、体感としても現時点では極めて限られているように思えます。

そんな中、私が所属するPLG事業部では、提供中のサービスである『formrun（フォームラン）』において、少し前から「ボウリングレーン・フレームワーク」を実際に取り入れ、継続的に運用するためのチーム体制を構築していました。

我々もまだまだ試行錯誤の最中ではありますが、世の中に情報がまだ少ないからこそ、少しでもSaaSに携わる皆様の参考になればと思い、これまで得た学び等を、このたび綴ってみることにしました。特に以下のような方に、ご覧いただけますと幸いです。

PLG型のSaaSが「広まった背景」と「成立条件」

まず大前提ですが、近年SaaSを展開する企業の傾向として、”PLG型”のプロダクトを新規事業として開発する、もしくは既に提供中の事業の形態をPLG型へと舵を切る企業が増え始めていると感じています。

SaaSという観点で見ると、元々は2000年代頃からのセールスフォースに代表されるように、機能がオールインワンで備わっており、包括的な課題解決が可能な、いわゆるSLG型（Sales-Led Growth）のサービスが成長を遂げてきました。

その後、新型コロナウイルス感染症の蔓延によるWebツールの活用者の増加の影響もあり、2020年以降は「1ペイン、1ソリューション」で課題を解決可能なPLG型のサービスの導入が進みました。営業担当者との商談を設定する必要がなく、誰でも簡単にセルフサーブ形式で契約できるサービスの需要が急速に高まる結果となりました。

有名な例を挙げるとすれば、Zoomがこちらに該当します。「Web会議を実施したい！」というニーズに対し、無料ですぐに導入できるZoomは、まさにPLGを体現するサービスです。他の例としても、コミュニケーションツールのSlackや、オンラインストレージのDropbox、多機能なメモアプリケーションツールであるNotionなども、PLGの文脈で語られる機会の多い代表的なサービスです。

PLGには、事業として成立する3つの条件があるとされています。どれか1つでも欠けてしまうと、PLG型のサービスとしては片手落ちの状況であり、大きな成長が見込めないサービスになってしまいます。

【PLG型SaaSが成立するための3条件】
①TAM（最大の市場規模）が大きい領域であること
②低価格帯であること
③すぐに使えるシンプルなプロダクトであること。

我々PLG事業部で提供している『formrun』も、まさにこちらの条件を満たしているサービスです。詳細については、PLG事業部長の佐々木が MarkeZineさんの記事で解説しておりますので、よろしければ合わせてご覧ください。

「ボウリングレーン・フレームワーク」とは？

PLG型のサービスで事業成長を追い求めていくためには、「ボウリングレーン・フレームワーク」の活用が必須と言われています。

「ボウリングレーン・フレームワーク」とは、ユーザーが無料プラン、もしくはトライアルプランを試している最中に、サービスの機能を知ってもらう／慣れてもらうことを目的とする「オンボーディング活動」において必要な概念です。

皆様ご存じの通り、スポーツのボウリングでは毎回できるだけ多くのピンを倒す必要があります。しかし、ボウリングの初心者であれば、ボールを真っ直ぐに投げることができず、レーン脇のガターにボールを落としてしまうシーンが少なくないはずです。

そうした課題を解決するために、”バンパー”と呼ばれる、ボールをガターに落とさないためのサイドフレームが開発されました。実際にボウリング場へ足を運んだことのある方は、子供や初心者がバンパーを設置してボウリングをしている姿を見たことがあるかと思います。

スポーツのボウリングと同様に、PLGのプロダクトにおいても、何かしらサイドフレーム（バンパー）が構築されていなれば、ユーザーから十分に機能を理解してもらえず、利用途中に離脱されてしまいます。せっかく人の役に立つサービスを開発したとしても、ユーザーが求める成果を出せないオンボーディング設計では意味がありません。

PLGプロダクトにおいても、ガター（＝離脱）の状態を起こさないためには、オンボーディングプログラムを構築するときに「ボウリングレーン・フレームワーク」を意識することが必要なのです。

「ボウリングレーン・フレームワーク」を構成する要素

下記の図で示されているように、「ボウリングレーン・フレームワーク」を構成する要素としては、以下の3つと定義されています。

1. ストレートラインを開発する

2. プロダクトバンパーを構築する

3. コミュニケーションバンパーを構築する

「ストレートライン」とは、上図の中央にある矢印が該当し、ユーザーがプロダクトの価値を感じるまでの最短距離を指します。
例）フォーム作成管理サービスにおける「フォーム作成画面へ遷移した状態 → フォームの作成完了」までの導線など

SLG型のプロダクトである場合、セールス活動や人を介したハイタッチのサポート活動を通じて、ユーザーへのオンボーディングを促すことができます。
しかし、PLG型のプロダクトの場合、基本的にはセールス活動で人手を介在させることなく、ユーザー自身がサービスに直接触れることでオンボーディングを実現させる必要があります。そのためにも、プロダクトの価値を端的に感じてもらう必要があるのです。

また、「ストレートライン」から落ちかけているユーザーを再度レーンの中央へ引き戻すために、上図の左右にある2つの「バンパー」を用意する必要があります。

右から支えている「プロダクトバンパー」では、ユーザー自身が自然とプロダクトの仕様を理解し、導入を進めるために必要な施策例が並んでいます。
プログレスバーやチェックリスト、ツールチップの設置など、プロダクトのUI/UXに溶け込ませたオンボーディング施策が主になっており、近年では自前で全てを実装するわけではなく、そうした機能を提供するSaaSを利用して解決しているケースも増えています。

左から支えている「コミュニケーションバンパー」では、ユーザーを啓蒙する役割を担っており、プロダクトへの再訪や有料版へのアップグレードを促す施策例が並んでいます。
Eメールやプッシュ通知、Tipsコンテンツの作成、時には郵送でのダイレクトメール送付など、プロダクト外でのユーザー接点を設けることを目的にしています。

ベーシックでは他にも様々な施策に取り組んでいますが、今回のnoteでは、社内でどのように「ボウリングレーン・フレームワーク」自体を浸透させたのかを主たるテーマとしており、「ストレートライン」「プロダクトバンパー」「コミュニケーションバンパー」それぞれの具体的な施策内容については、また別の機会でご紹介できればと思います。

【前提】ベーシックで取り組んでいた「ボウリングレーン・フレームワーク」の導入状況

まず前提として、これまでのベーシックのPLG事業部における取り組み状況としては、「ボウリングレーン・フレームワーク」を構成する「プロダクトバンパー」と「コミュニケーションバンパー」は既に一定用意できていたものの、その運用における”属人性”が高いという問題を抱えていました。

具体的には、要件定義と公開アナウンスを担当するPdM（Product Manager）が、新機能のリリースや仕様変更を行う際に、「更新すべきバンパー」を自分でピックアップし、自身が手を動かして作業をすることにより「ボウリングレーン・フレームワーク」を都度更新する、というような運用を行っていました。

たとえば、2021年にリリースされた「一斉メール配信機能」の場合、担当のPdM自身が「更新すべきバンパー」として、Eメールの配信文言作成や、配信先リストの作成、Tipsコンテンツ作成等の洗い出しを行い、その更新作業も当人が全て実施するという属人的な状況でした。

しかし、こちらのような運用では、当然のことながらPdMしか「更新すべきバンパー」を洗い出すことができず、その結果、各バンパーが然るべきタイミングで更新されているかを、チーム全体としてあまり認識できていませんでした。
先ほど例として挙げた「一斉メール配信機能」のリリースにおいても、「ツールチップの設置をリリース直後から取り組んでおけばよかった」「サービスサイトの機能一覧ページにて一斉メール配信機能が使える旨を書き忘れていた」など、更新すべきバンパーの抜け漏れが後で発覚するという事態が実際に発生していました。

加えて、PdM自身も年間を通して複数の機能開発要件を担当しているケースが多かったことから、本来のPdM業務を優先した結果、各バンパーの更新作業が結局後手に回ってしまうケースも頻発していました。

そのため、「ボウリングレーン・フレームワーク」の属人化が引き起こす、バンパーの洗い出し状況のブラックボックス化や、バンパーの更新し忘れといった問題を解消すべく、以下の取り組みを行いました。

【本題】「ボウリングレーン・フレームワーク」を運用に乗せるためにチームで取り組んだこと

上述した「ボウリングレーン・フレームワーク」の属人化解消のため、現在では、PdMのメンバーだけでなく、マーケティングチームや、カスタマーサポートのチームメンバーと協働しながら取り組むように変更しています。

そして、こちらの体制を実現するために、各チームの施策担当者が、誰でも「ボウリングレーン・フレームワーク」をアップデートできるよう、以下の4ステップの順を追ってチームへの浸透を図りました。

Step❶：チームメンバー全員に対する課題図書の読了依頼
Step❷：開発プロセスにおける「ボウリングレーン企画」フェーズの新設
Step❸：「ボウリングレーン企画」フェーズで起案する資料の雛形を作成
Step❹：チームメンバーへの説明・浸透

Step❶：チームメンバー全員に対する課題図書の読了依頼

「ボウリングレーン・フレームワーク」の理解を促すため、課題図書としてPLG事業部内のメンバー全員に、冒頭でも触れた以下の書籍を読んでもらいました。

対象者はマーケティングやサポート担当のメンバーのみならず、デザイナーやエンジニアまで、まさに「formrunに関わる全ての人が本に目を通している状態」を作りました。

書籍ではSaaSに関する基本的な用語（Unit Economics や Payback Periodなど）やSaaS事業の特性なども網羅的に説明されていたこともあり、「ボウリングレーン・フレームワーク」に対する共通理解を持つという本来の目的に加えて、自分たちが携わる事業の解像度を高めるという点でも、非常に有意義な取り組みとなりました。

Step❷：開発プロセスにおける「ボウリングレーン企画」フェーズの新設

formrunでは、「機能開発の企画」から「外部への公開」に至るまでを、ざっくり以下のプロセスで遂行していますが、こちらの図にあるように、エンジニアが取り組む実装作業と同時並行で「ボウリングレーン企画」というフェーズを設けました。

「ボウリングレーン企画」という言葉については、前述PLG本の中でも紹介はされておらず、formrunにて「ボウリングレーン・フレームワーク」を浸透させるために、ベーシックで独自に取り決めた概念です。

「ボウリングレーン企画」フェーズでは、新機能のリリースに伴い、「プロダクトバンパー」と「コミュニケーションバンパー」にてそれぞれ追加するべき施策を取りまとめ、社内のステークホルダーを巻き込みながら「ボウリングレーン・フレームワーク」を継続的に更新するための準備内容を取りまとめています。

Step❸：「ボウリングレーン企画」フェーズで起案する資料の雛形を作成

以下の図のように、「ボウリングレーン企画」における起案資料は、私以外のPdMでもドキュメントをまとめられるように以下の雛形を用意しました。

企画ごとにこちらの雛形をコピーし、資料の流れに沿ってPdMが内容を埋めることにより、誰でも「ボウリングレーン企画」を担当できる体制を築いています。

Step❹：チームメンバーへの説明・浸透

その上で、以下の流れでチームへの説明・ルール作りを行っていきました。

上にある雛形の一例のように、「ボウリングレーン企画」フェーズで起案する資料では、他部署に依頼したい施策の具体内容とスケジュールについて記載しています。

社内への説明時に工夫した取り組みとして、1)の手順にて、各部署の責任者だけでなく、実際に施策に取り組むメンバー層の社員からもヒアリングを行うようにしました。

それにより、施策の難易度や実施スケジュール、インパクトを丁寧に把握し、企画資料がファジーな書き方にならないよう、「誰が見てもわかる粒度（都度の確認作業を最小限に抑えられる粒度）」で事前記入が完了するような雛形へと修正を加えました。

「ボウリングレーン企画」のメリット

ベーシック流の「ボウリングレーン企画」を導入したことにより、大きくは2つのメリットを得ることができたと感じています。

• 施策企画時の網羅性担保ができ、スピーディーな実行が可能になった

• 新機能をリリースした際に、想定よりも高い利用率を達成できた

■施策企画時の網羅性担保ができ、スピーディーな実行が可能になった

以前は新たな機能を提供し始めたとしても、「ボウリングレーン・フレームワーク」の更新をし忘れており、なかなかサービスサイトの機能紹介ページに反映されない、というケースが散見されました。

このような問題を解決するために「ボウリングレーン企画」のフェーズを設けたことにより、新機能をリリースした直後に展開すべきユーザーオンボーディング施策が、不足なく、かつスピーディーに反映・実行できるようになりました。

企業によっては「PMM（プロダクト・マーケティング・マネージャー）」を置くことで業務分担をしているケースもありますが、formrunでは「ボウリングレーン企画」という取り組みとあわせて、企画者自身がマーケットのポテンシャル調査と要件定義、機能リリース後の利用促進施策のハンドリングに取り組んでいます。このことにより、機能案の企画からリリース作業まで一気通貫したプロジェクト推進を実現し、事業推進の質とスピードの向上に繋がっていると感じています。

■新機能をリリースした際に、想定よりも高い利用率を達成できた

新機能を新たに提供する際には、「月次ごとのユーザーの利用率」をあらかじめシミュレーションしておくのですが、「ボウリングレーン企画」を導入して以降、事前に想定した数値よりも高い利用率を、早い段階で達成できています。

直近の例を挙げると、アンケートで利用可能な「マトリックス選択」機能のリリース、「条件分岐選択」の機能リニューアルにおいて、想定よりかなり前倒しのタイミングで高い利用率が計測されており、数としても思った以上に沢山のユーザーから利用してもらえる機能となりました。

＜該当機能の参照＞

• 【新機能】アンケートフォームで利用できる「マトリックス選択」をリリースしました！

• 【機能リニューアル】「条件分岐選択」項目において2回の分岐が可能になりました！ 

以前まではリリース後に一定の時間をかけていたユーザーへの案内等を、機能のリリース直後から迅速に実施できたことが、こうした成果に繋がったと感じています。
PdMとしては「作って終わり」ではなく、当然のことながらより多くのユーザーから利用されることを目標として取り組んでいるため、「ボウリングレーン企画」の導入によってこれらの成果を得られたことは、非常に嬉しい限りです。

「ボウリングレーン・フレームワーク」を運用し続けるために必要な組織体制

PLGは「プロダクトでプロダクトを売る」事業であると言われていることもあり、今回ご紹介した「ボウリングレーン・フレームワーク」を取り入れ、お客様の業務環境や利用状況に応じて更新し続けることが欠かせません。

そのうえで、ベーシックのPLG事業部において「ボウリングレーン・フレームワーク」を浸透できた要因は、PdMが主体となってチームを適切に巻き込めたこと、そして結果的にPdM以外のメンバーもプロダクトを第一に考える文化を形成できたことの2つでした。

「ボウリングレーン・フレームワーク」を運用するためには、マーケティングやカスタマーサポート、カスタマーサクセスはもちろん、UI/UXに深く溶け込んだ仕様設計と開発が伴う場合も多々あり、その際にはデザイナーやエンジニアとのコミュニケーションも必須となります。

また、適切なコミュニケーションの構築は大前提として、加えて組織としてもSLGのような縦割りの分業体制ではなく、プロダクトづくりに携わるメンバーを中心とした協働を前提とした組織体制が必要になると考えています。

前述のように、マーケティングやCS担当者のみならず、エンジニアやデザイナーとの接点も多く存在するチーム体制ゆえ、相手の高い専門性に応じた適切なコミュニケーションスキルや、プロジェクトの管理・進行のスキルがPLG型の組織には求められます。

私自身も「チームメンバーが施策や業務を推進しやすいコミュニケーションはどのようなものなのか？」という問いについて日々思考を巡らせ、都度の改善を繰り返していますが、チームメンバーも同じように考えてくれる人ばかりで、いつもありがたいと感じています。

また、上述のような環境が整備されている背景として、PLG事業部で定義されている”バリュー”の存在があると考えています。ベーシックでは部署ごとにメンバーへ求められている“バリュー”が明文化されているのですが、PLGの事業に関わる方がいらっしゃいましたら、大切にしたい行動指針やマインドを、皆様のチーム内でも言語化・構造化しておくことをお勧めします。

最後に

今回は「ボウリングレーン・フレームワーク」を社内へどう浸透させたかをメインにPLG事業部のformrunにおける取り組みをご紹介しましたが、とはいえPLG については、まだまだベーシックとしても、さまざまな知見や概念理解を深めていきたいと思っています。

自分たちのスタンスとしては 、formrunを日本一、そして世界に通じるPLG型SaaSへと進化させることを掲げており、こうした目標を目指すに至った背景については、PLG事業部長である佐々木のnoteをご覧いただければ嬉しいです。

今回のnoteをお読みいただき、少しでもベーシックのPLG事業に興味が湧いた方は、採用ページもぜひ覗いてみてください。

また、私、甲斐自身に興味を持っていいただけた方は、Twitter（@Kai_MSYK）宛にお気軽にDM等いただけると嬉しいです。PLGのサービスや、これからのSaaSについてディスカッションしたい人からのご連絡をお待ちしてます！

最後までお読みくださり、ありがとうございました！