【PMF実現への近道】AutifyとLoglassのリアルストーリーに学ぶ、SaaSのPMFを効率的に進めるポイント

SaaS起業家の“圧倒的な成長”を支援するべく、ALL STAR SAAS FUNDでは全5回からなる短期集中型の連続セッション＆オフィスアワーを開催しました。その名も「ALL STAR SAAS BOOT CAMP」です！

ARR 0〜1億円のシード企業、あるいは起業準備中のSaaS起業家にとって、ARR10億円を達成するまでに築く基盤こそがT2D3達成のコアになります。数多くのSaaS起業家へ支援を続けているVCとしての経験、そして学びを、また新たな起業家たちへ伝えていきたいと、私たちはそう考えています。

そこで、課題を乗り越えてきたSaaS企業の現役経営陣とSaaSスタートアップの各成長フェーズを支援してきたALL STAR SAAS FUNDの投資メンバーが、実体験をもとに各テーマについて解説します。初回のテーマは『SaaS PMF実現に向けた近道』です。

スピーカーには、 AIを用いた「ソフトウェアテスト」の自動化ツールを開発するAutifyの近澤良CEO、大企業向けの経営管理SaaSを提供するLoglassの坂本龍太CTOが登場。「PMFを実現するまでに押さえるべきポイント」や「PMFに向けて持つべき心構え」など、まるごとPMFだけに絞ったセッションとなりました。

まずは、ALL STAR SAAS FUNDのPartnerである湊雅之が「PMFの前提」を解説。その後、登壇者とのセッションに進みました。

（※この記事は、約1.5時間からなるセッションをテキスト化・再構成したものです）

そもそも「SaaSプロダクトのPMF」とは？

‍湊：まず、SaaSプロダクトの「PMF」の中身は、大きく4つに分解できます。

1．お客さまの課題（＝バーニングニーズ）がわかっていること

2．課題を解決するソリューションが特定できていること

3．ソリューションとなるプロダクトができていること

4．スケールする（＝スケーラビリティがある）こと

つまり、PMFの失敗とは、これら4つのポイントが根詰まりであるケースが多いのです。そして、これらは順番に起こるのではなく、同時並行であることも見落としがちなポイントといえます。

たとえば、2つ目のソリューション検証を飛ばしてしまうのは、ソフトウェア業界を経ていない方が陥りがちです。見込み顧客の課題を聞いて、いきなりプロダクトを作りだしてしまうようなことも、よくあるものです。あるいは3つ目のように、制作したプロダクトが実際のところ「Excelの延長線上」のようになってしまっているケースもあります。

加えて言うと、VCや起業家の間でも課題に挙がるのが「価格設定」です。SaaSはリカーリングレベニューでお金を集め、それを再投資して、どんどんプロダクトの価値を上げていくものですが、初期単価が安いと再投資ができなくなってしまうために、狙えるパイも小さくなり、機能開発もしにくくなるのです。

そこで今回は、PMFを成功させるためのこれら4つのポイントを、AutifyやLoglassの実践例から、より具体的に見ていければと思っています。

プロダクトは必須ではないが、バーニングニーズの特定にヒアリングは欠かせない

‍湊：最初に「バーニングニーズの特定」からいきましょう。最も大事な論点は、ターゲット顧客を見定め、ヒアリングを重ねることにあります。約100社にもインタビューができれば素晴らしいですが、すべてがそうではないでしょう。そこで、僕が勝手に「ミスター・バーニングニーズ」と呼ぶ近澤さんに伺いたいのですが、いつ、どうやってヒアリングを重ね、お客さまの課題に対する仮説を作ったのでしょうか。Autifyの経験を聞かせてください。

近澤：そもそもAutifyに至る2年前は、テストの自動化ですらなかったですし、ピボットも8回くらいやっています。テストの自動化でいくことを決めたのは、Alchemist Acceleratorに入る直前で、そこで粗いながらに仮説を立てました。ターゲットを洗い出し、その人たちから課題をよく聞き、最初の3カ月で60社ほどヒアリング兼セールスをしました。

ただ、3カ月たってもまったく売れない。そこで、課題の仮説やプロダクト自体に問題があると考えました。ヒアリングノートをすべて見返し、課題をスプレッドシートに並べていきながら、同じ課題をカウントするようにしました。

そして、カウント順にソートしてみることで、企業規模を問わずに「テスト自動化がエンジニアリングリソース不足で進んでない」という共通項が初めて見えたんです。もう一つ見えたのは、アジャイルで開発をしているとUIが変わるたびに自動テストのメンテナンスをしなければならず、それに時間を取られることです。

この2つを解決すれば間違いなく大きなビジネスになると確信したのが、Autifyにとって最初のバーニングニーズの特定でしたね。それをお客さまにぶつけたら、これまでとまったく反応が変わりました。

湊：ヒアリング時にはすでにプロダクトがあったのでしょうか？

近澤：同時並行で開発はしていましたが、結果的には開発しなくてもよかったと、今は思えますね。結局、Autifyはプロダクトなしに契約が取れましたから。顧客が「買うか、買わないか」はプロダクトの有無よりも、課題の解決を説得できるかどうかに懸かっているからです。プロダクトがあれば説得力は増すけれど、絶対に必要というわけではありません。

湊：やはり60社ほどにヒアリングしないとバーニングニーズは見つかりませんでしたか？それとも、20社ほどである程度は傾向が見えましたか。

近澤：確かに30〜40社ぐらいで気づけたかもしれないですね。ただ、偏りがないのかを検証する意味では、ある程度の数を重ねたほうがいいでしょう。100社に聞いて、8割が同じことを言えば間違いないはずですから。

Loglassはなぜ200社も壁打ちしたのか？

湊：Loglassでは、どういった課題仮説をして、共通項の見極めをされたのでしょう？

坂本：僕は共同創業者ですが、もともとは代表の布川が投資銀行を経て、上場企業のメディア系企業でゼロから経営企画や経営管理の業務を作り上げた経験をもとに、ニーズを見極めていったという前提があります。毎月、実績データを集計して予算と突合する業務をする際に、手作業のデータ処理がまさに「Excelワーク」で大変だったと。

まずはエンジニアたちとGoogleスプレッドシートとGAS（Google Apps Script）で実績データを自動で突合できるシステムを作り、予実管理をはじめたのですが、同様に世のなかでも課題になっているのかを考えました。加えて、経営企画やCFOを対象とした日本最大級のFacebookやSlackコミュニティを運営していたことから、起業も視野に入れながら、参加している200社ほどに布川が壁打ちをはじめてみたのがLoglassのはじまりです。

湊：布川さんは自分が対象顧客であることから仮説を作り、その後にヒアリングをしていった。とはいえ200社は僕が耳にしたなかでも一番に多いくらいです。そこからセグメントごとにバーニングニーズを切り分けていったのでしょうか？

坂本：そうですね。ドメイン業務に浸りきっておらず、業界的な固定観念を持ってない布川が、共通性を見極めるためにヒアリングしていったのが功を奏していると思います。

‍湊：ドメインエキスパートの必要性は領域特化のSaaSでは論点になりやすいですが、それに引っ張られすぎると仮説に引っ張られて偏ったプロダクトが生まれるケースになる。まさにバランスが大事という学びがあります。

坂本：その点では、僕らは企業規模を不問としてヒアリングしていきました。いずれの企業規模でも予実管理に課題があるなかで、売上1兆円規模の企業ではExcelなどでは経営管理ができないこともわかってきました。ニーズが大きい企業にはSIerが10億規模の予算を得て作ったようなシステムもすでにありました。

そこで少し視点を変えてみました。部署が数十から数百ある企業においては、経営企画が予算を組むときに、まずExcelフォーマットをそれだけの部署に配布して入力してもらったデータをかき集めている現状がありました。ただ、部署によってExcelスキルも異なるので、データが壊れていたり統一されていなかったりして、再提出してもらうケースもある。

そういった社内システムでも解決できない「データの収集と統合」に絞ったのが、Loglassにとっての最初のピボットでしたね。約200社へ話を聞いたうちの3割ほどは好感触でしたが、仮説検証のためのヒアリングを重ねたかったのと、プロダクト開発開始からの受注については、1年近くを費やしています。その間も、法的な拘束力はない申込書みたいなものに署名してもらってはいました。

近澤：Autifyではバーニングニーズの見極めは「受注と反応」で見ていました。課題から逆算してソリューションを作って、エンジニア不在でもノーコードで自動化でき、AIがメンテナンスするという紙芝居みたいなデモ動画を一晩で作っていったら、顧客の食いつきが明らかによかったんです。「いつできる？いくら？この機能はある？こんなこともできる？」なんて具体的になって。僕らも「それならいくら払いますか？」と予算も確認できて（笑）。

あと、僕らはプロダクトはもちろん、最初はソリューションも売っていました。テスト自動化ツールの提供だけでなく、自動化のシナリオもAutify側で作成していました。「テストケースをいただければ弊社で自動化します」といって、テストスクリプトを書きました。もし僕らの製品に不満があれば、テストスクリプトをお渡しするので、御社側で運用していただいて構いませんというかたちで、顧客に精査してもらったわけですね。

……というのも最初、Autifyにはテストシナリオを作る機能がなかったんですよ。だから自分たちでスクリプトを書いた（笑）。でも、今思えばそれがよかった。顧客から自動化したいテストケースをExcelですべてもらって、それを「どうやったら自動化できるか」と、僕が毎日一つひとつにらめっこしていった。

とにかく大変だったので二度とやりたくはないですけれど、それを分析していくと課題はたくさん浮かび上がってきました。リンク切れをチェックしたい、サインアップは必ずやりたい、Eメールが絡むテストをしたい……といったように、顧客の自動化に関するニーズが見えましたから、それらをバックログに入れていきました。

「ヒアリングさせてくれる人はどこにいるのか」をまず考える

‍湊：ヒアリングに関連して、お客さまやユーザーになっていただく方に、どういった名目で話題を持っていき、課題を引き出すときにどんな工夫をされていましたか？

近澤：結構聞かれる質問ですね。ケースバイケースではありますが、Autifyは友人や知人といった自分のネットワークからセグメントをまずは決めて、「自分がやりたいと考えていることについてヒアリングをさせてほしい」とメッセージを送りました。僕はもともとエンジニアでしたから、テストに課題を持っている人をたくさん思いついたんです。

あとは、Alchemist Acceleratorに入っていたときは営業も兼ねていました。LinkedInのセールスナビゲーターのライセンスを買って、企業規模ごとにCTOやVP of Engineering、QAといったセグメントを定義し、返信率が高いところを探りました。AutifyはプロダクトマネジャーよりもエンジニアやQAのほうが返信率は高かったです。

「僕らはAlchemist Acceleratorに入る前途有望なスタートアップなので、ぜひお話を聞いてください」みたいにコンタクトして、課題を聞いたり。あとは、QAを募集している会社をリストアップしました。IndeedやWantedlyから会社を抽出して、Facebookで共通の友人がいる人に紹介してもらったり。

だから、まず考えるべきは「ヒアリングさせてくれる人たちがどこにいるのか」を知ることなんだと思います。

坂本：正直、ヒアリングされる側のメリットはゼロといっても過言ではないときに、それでも「聞かせてください」と食い下がってでも伝えられることが、根本的には大事だと思っています。

ヒアリングにおいては、まずは業務に対して詳しいことを示すのが大事。そうでなければ、一歩踏み込んだときのバーニングニーズや、そもそもの困りごとを引き出せません。「この人はわかっているから話せる」という関係を短期で結ぶために、業務解像度を極めて高く持つことは徹底しました。

近澤：みんな課題は解決してほしいわけですから、それが叶うと思えれば、話だけは普通にしてくれると思うんです。関係値によるところはありつつ、友達でなくても、「あなたの課題を解決できるはずです」と来られたら、30分くらい割いてくれることは十分あり得ます。

海外リサーチをすることで見えたもの

‍湊：次に、ソリューションの仮説について、どのように定めていったのかを聞いてみたいです。それこそSaaSが世界中にあるなかで、海外リサーチも含めて考えていったのですか？

坂本：競合はとにかくリサーチしました。先行プレイヤーのホワイトペーパーをすべて読み続けたのが初期のころの記憶ですね。そこから、観点やコンセプトの違いを見ていきました。たとえば、北米でもLoglassに近い領域が何社もあるなかで、なぜそれらが生まれ、共存し続けられているのかを調べました。

Oracleや会計事務所といったバックグラウンドがあったり、まったく関係ないデータエンジニアリングからきていたりするのに、どのようなバリュープロポジションで戦っているのかを明らかにしていく作業でしたね。そのうえで日本展開しているサービスがあるなかで、自分たちが勝っていけるところを明らかにしていきました。

調べたのは数十社でしょうか。「データをいかに整えるか」といった領域まで広げると、Loglassに近いと思えるところは相当あるんです。海外リサーチについては布川とも話してみたのですが、自分たちの5年や10年先をいく先輩たちと捉えて、どういった攻め方をしたかという経験をトレースできる観点でも、とても大切だと思っています。

Loglassが狙う市場の立ち上がりで言えば、世界には1兆円規模の企業も出てきていますが、国内ではまだいない。やはり5年程度のギャップがあるのであれば、先行する海外企業は一つのモデルケースになるのでしょう。

近澤：もちろんAutifyも海外含めて相当にリサーチして、先行企業が提供しているソリューションと、その元になる仮説を見ていきました。やはりバーニングニーズから逆算して最適なものを作ったら当たった感触はありましたからね。そのうえで、ソリューションの原案であるノーコードとAIメンテナンスは今でも変わらず、僕らの提供価値のコアになっています。

モックアップは、ヒアリングの精度を高めるためのツール

湊：バーニングニーズの見極めから、次に「課題を解決するソリューションの特定」へ移りましょう。ソリューションとプロダクトは似て非なるもの、ということが、近澤さんのデモ動画で受注したエピソードでも伝わりますが……。

近澤：僕が一晩で簡単なHTMLとCSSを書いた、ぺらぺらな紙芝居みたいなもので（笑）。

坂本：Loglassの場合は布川がネットで出会ったエンジニアがいて、その方にVBAかJSで動くだけの……それこそ紙芝居より少し解像度が高いくらいのものを作ってもらって、話を聞いてまわっていたそうです。僕が関わる寸前くらいからFigmaで布川が自作してデモを見せていましたね。

「課題を解決するソリューションの特定」の段階では、僕はまだまだプロダクトを作る必要はないと考えます。ただ、検証のために、起業家がモックアップを使いこなして、ヒアリングの精度を高めるためのツールだと思えばよいのではないでしょうか。

湊：SaaSならばプロダクトよりも先にデモを作れ、と。これは大事なポイントですね。とはいえ、そこから実際のプロダクト作りも欠かせないわけです。“Minimum Viable Product（以下、MVP）”として、最低限売れるために必要なプロダクトの機能の見極めも難しいところです。

近澤：僕にとってのMVPはプレゼンテーションとデモ動画だとは思うのですが（笑）、売れるための最低限でいえば、ピボット前のプロダクトで作っていたものを流用して、つなぎ合わせて、動いているようには見せられたと思います。

MVPとして売れることと、その後のステップで満足してもらうことには、また違う段階がありますよね。テストケースを分析して、どこの機能を作れば顧客がちゃんとテストを作れるのか。その優先順位をつけるために、顧客と契約するときに最低限欲しい機能をお聞きして、実装するといったネゴシエーションも実際ありました。契約書に「3月にはこの機能、4月にはこの機能、5月にはこの機能が出ます」といった内容を盛り込んだりしながら。

それらの機能があれば、顧客としては最低限でも使えるという判断ができる、と定義できていたのだと思います。

湊：なるほど。お客さまからもアグレッシブに「この機能やプロセスをカバーしないと使えない」と明確に答えを聞けていたわけですね。

近澤：これはテストケース をもらって分析する、思い返すに大変だったコンサルティングを手掛けたことが活きています。「まずできそうなもの」「次にできそうなもの」「ちょっと難しそうなもの」と3分類して、それぞれに必要な機能を見定めていったんです。そのうえで「来年の4月から走り出すなら、まずここまでの機能でいかがでしょう？」と交渉しました。

湊：受注前からコミットしていったわけですね。

近澤：そうです。僕が夜な夜な分析し、レポートを出して、「これが自動化できるなら契約できます」みたいな感じで。

湊：いやぁ、めちゃくちゃ泥臭いですね。

近澤：血へどが出るぐらい泥臭かったです。

構想から「8割方、捨てて」機能を絞り込む

‍湊：Autifyのプロダクトはエンジニアの方々など比較的にテックに強い人たちが顧客になりやすいのだとは思いますが、一方でLoglassは必ずしもそうではなく、さらには業務プロセスが長いケースも多いはずです。MVPの見極めが非常に難しいように感じます。

坂本：確かに苦しい日々でした（笑）。布川がドメインエキスパートなので知識はあったのですが、それをいかにミニマムにしていくかが大事でしたから、一旦は顧客の解像度を上げていくためにヒアリングなどを重ねました。予算策定一つとっても、決済承認がどのような業務フローで流れ、いかにメンバーが関係し、どういった感情で責務を担うのか。

たとえば、社長が「今期は15%は利益を伸ばしたい」と言う。それは電話で伝えられるのか、それとも会議で話されるのか。受けた側はどういった気持ちでExcelフォーマットに落とし込み、いかなるデータをやり取りするのか……。

そういった細部まで目を配り、一から十まで何も見ずに業務を完全に再現できるくらいの解像度に高めることを、初期のLoglassではやっていきました。僕らが幸運だったのは代表の布川がゼロからの立ち上げで、経営企画や経営管理の全体像を把握していたことです。その経験を大企業のケースに合わせ、解像度を高め、複数社に対して「起きうる業務」を整理していったんです。

そこから機能開発を考え、上から下までユーザーストーリーを洗い出してみると、百数十の項目が出てきてしまいました。僕らだけで作ろうとすると「丸三年は軽くかかるよ」と言われていました。それでは資金もまったく足りませんね（笑）。

あと、Loglassの難しさでいえば、業務をシステムに乗せていこうとしたときに、購入の決め手になるような「キラーな機能」というのはなく、基本的には業務の前後関係があり、部分的にExcelなども併用して動くことも前提になります。業務の依存関係を紐解き、プロダクトとして盛り込むべき機能を涙ながらに削った結果、8割方を捨てて30項目弱にまで絞り込みました。

湊：疑似体験できるレベルまで検証しきってから「これが作れれば間違いない」という段階に至ってから取り掛かったわけですね。

プライシングに明確な答えはないが、セオリーはあり得る

‍湊：プライシングの決め方についても、ぜひ伺いたいです。初期は特に価格設定が難しいかと思うのですが、近澤さんはどのようにしましたか？

‍近澤：価格設定は「どこのお財布を握りにいくか」が大事だと思っています。だから、「ぶっちゃけた話、いくらなら買います？予算はどれくらいあります？」と直接聞きます。相手の期待値もわかるし、どういった思考で予算を捻出しているのかも見えてくるから、絶対に聞かないとだめですね。

Autifyの場合は、現状で手動テストに割いている人員と、テストを回すためにかかっている時間が聞けるので、そこからROIを考えるロジックが見えます。たとえば、そこをAutifyで自動化すれば「人件費が10分の1くらいになりますよ」と言ったり。そういうやり取りをしていると、顧客の「お財布の上限」みたいなのが見えてきます。

結局は、顧客がどういうふうな考えを持ち、いくらならお買い得に思えるのか、という感覚は絶対に理解しなければいけません。そして、「お財布」はどこから出てくるのか。Autifyならテストや開発ツールの予算であることが多いですが、どちらで見るにしてもバジェットも変わりますからね。

初期段階では僕らは競合がいませんでしたから、それほど他社を気にする必要もなかったのですが、今だといろいろと状況が変わっています。競合製品の価格も意識する必要は出てきていて、かなり細かく変えています。

湊：ありがとうございます。予算、ROI、他社のソフトウェアに払っている金額といったところをベンチマークされたと。まさにお手本といえる決め方ですね。

坂本：LoglassもROIやコストメリットは観点の一つでした。もう一つは、競合なども多数調べていましたから、大まかなプライシングは把握していました。Loglassは初期設定も「高価ななかでも安価なくらい」でしたが、現在はさらに3倍に値上げできています。

Autifyさんと異なるのが、Loglassは該当する予算がないことで、市場としても立ち上がってないことです。僕らも「正直なところ、いくらなら導入したいか」といったコミュニケーションはかなり発生してしまいました。ただ、そもそも市場がないのは「自分たちがスタンダードを作っているのだ」という自負にはつながるのかなと思います。

湊：ビジョンセリングといいますか、将来的な価値の大きさをお客さまに納得してもらうところを徹底されたのでしょうか？

坂本：そうですね。そこで「萎縮してしまってはいけない」というのが僕にとっても学びです。機能数で言えば、他社と比べて少なくなるのは立ち上がり時期であれば仕方ない。単なる機能数などの勝負をせず、きちんと自分たちのコンセプトを信じて、立派な価値を出せることを、萎縮せずにはっきり伝える。それが初期の営業などの肝だったと思っています。

現在のLoglassは、営業状況や競合に合わせて、年間に何回もプライシングを変えながら進めています。全体の値段としては上げていても、プランを分けるといった施策を取るなどして、絶えず変えていく。価格設定には明快な答えはなく、ずっと変え続けるものではありますが、きちんと上げ続けることを実現するのが大事ですね。

巨大市場であることを言語化する

‍湊：市場の拡張性についての考えも聞いてみたいです。特に投資家へ説明するときには必要になってくる要素かと思います。どういったセグメントへ広げていくか、第2・第3のプロダクトを作っていくのか……「レイヤーケーキ」ともいわれますが、PMF前後の段階で、それらはすでにあったのでしょうか。

近澤：PMF前後では、ほとんど無かったですね。ただ、巨大市場なのは明らかでした。「IT予算の3分の1をテストに使っています」みたいな話があるくらい（笑）。そうなると市場性は「1.3トリリオンUSドル」にもなったので、これらが自動化へ舵を切っていくとすれば、市場の大きさについては説明不要だったとは感じます。

湊：マクロで見て、「登り方はさておき、これだけの巨大なマーケットが望めます」と明示的に考えられたと。

近澤：そうですね。登り方は後から明確になってきました。シード調達では計画はなく、シードからシリーズAへの間に解像度が高まってきたところで、プロダクトのレイヤーケーキや段階的なフェーズを提示していったんです。

坂本：Loglassは、より高単価を狙える市場があることは明確だったと感じていました。初期から100社、200社とヒアリングしていたなかで、日本なら誰でも知っているような企業で「経営管理のための社内データが多すぎ、オンプレミスのサーバーで10億円規模のものを導入した」といったお話も出てきますから、「とてつもないニーズがある！」と（笑）。

Loglassという社名は、スペイン語のLograr（達成する、実現する）という意味も由来に含まれています。根本的に経営管理よりは、現業をよりブラッシュアップして、達成を支援したいと考えています。今は経営判断や経営管理に資するデータをまとめられるものですが、より営業面で売り上げを積み増したい、調達系に対しても予実管理をしていきたいといった、職種に特化したプランニングもぜひ進めたい、といった構想は初期から持っていました。

PMFの達成は定性的／定量的に見えてくる

‍湊：ズバリ、お二人が「PMFを感じた瞬間」はいつですか。どういった反応がお客さまからあったのでしょうか？

‍近澤：やはり、プロダクトがない状態で契約を取れたときは「これだ！」という感じでしたね。ベータローンチ後もメディアに取り上げていただいたら、たくさんの問い合わせがきましたし、問い合わせをしてくださる会社の質も、まるっきり変わりました。Autifyは4人のスタートアップなのに、大手銀行さんからも連絡が来たり（笑）。

よほど皆さん困っていると感じましたし、今までのプロダクトとはリードの質が明らかに違う。「これは本当にバーニングニーズを捉えた」と思えましたし、プロダクトを出した後でもTwitterで言及されたり、デモを見せたときに感動を伝えてくれたり、といったところからも感じましたね。

坂本：うちは「電話が鳴り止まない！」……なんてことはなかったんですが（笑）、初期にご契約いただいた方々が更新してくださり、チャーンレートが極めて低いまま推移してきたときに、PMFをしっかり感じましたね。

あとは、正規の価格でご契約いただき、その後もすごい勢いでご利用いただいているところを数値としても見たときに、「これはPMFをしている」という強い実感がありました。

湊：それらの実感に関連して、定量的に「この指標がよくなったから、PMFしたかもしれない」と判断材料になるものはあると思いますか？

坂本：アクティビティは相当見ていました。たとえば、デイリーログインの状況。予算管理なら「月に何回か」は見るのがベースになりますし、そのうえでお客さまの組織全体で使われているかどうかを、数字から逆算していきました。

あとは、Loglassが予算を作るプロダクトである以上は、どれぐらいの頻度で予算編成がなされたのか。多ければ予算データがLoglassにも入ってくるわけですから、社内から需要のあるデータがシステム内にあるといえ、業務と極めて密接に入り込んでいるわけですから、PMFといって差し支えないでしょう。

近澤：僕らはインバウンドのデモ数なんかは見てはいたものの、どちらかというと定性的な実感のほうが大きかったですかね。定量的な指標でPMFを証明することはできたとは思いますけれど、特段に指標としたものはなかったです。

PMFを実現させるためには「固執せず、あきらめない」

‍湊：近澤さんだとインバウンドのリードの変化、坂本さんだと目に見える数値面の成果といったところから、感覚としてギアが変わる瞬間が、お二人にもあったんですね。もう一つ、そのPMFを実現するためにどういったチームが必要だったと考えますか？

近澤：最初期のAutifyは共同創業者と僕の2人だけで、僕がエンジニアリング以外のすべてを担って、もう一人がエンジニアリングを担当していましたね。

坂本：代表の役割はドメインエキスパートであり、プロダクトオーナーであり、営業や事務もすべて担っていました。あとは、私とUIデザイナーがいましたが、デザインに関して初期から取り組んだのは価値があったと思っています。Figmaなどのデモをきれいに作る、それをプロダクトに落とし込む、といったところですね。

PMFでいうとCSが初期からすごく強かったことも、すごく感謝しています。CSがドメインエキスパートであり、サポートすることで更新が続いた面があったと思いますし、エンジニアとしても助かりました。

近澤：その点ではAutifyもハンズオンでサポートしてきましたね。あとは、わかりやすいUIも最初から気をつけていました。最初は、エンジニア自身がデザインもある程度担えましたし、次に入ったエンジニアもUXのセンスが高いメンバーでした。彼が最初のAutifyのシナリオ画面を作ったんです。

湊：PMFにおいて重要で、お二人に共通するのは「寄り添い」が大事なのだと共感しました。最後にお二人から一言ずつ、PMFを実現させるための心構えを、ぜひ伺わせてください。では、坂本さんからお願いできますか。

坂本：「固執しない」ということを繰り返してきました。科学的なもの、お客さまの反応といったものを素直に受け入れ、アクセルを踏むことをきちんと慎重に恐れながら、自分の案に対してもドライに考えていく。その姿勢が、僕は大事だと思っています。

近澤：「あきらめない」。この一言ですね。

湊：強い言葉です。

近澤：あきらめない、以上です。長い戦いになるので、あきらめないでください。