罠その3 PMFの罠
福島良典氏：変わってきて、すごくうまくいきましたという話ができればいいのですが、ここから先もアホみたいな失敗を何度もやっています。（スライドを指して）「PMF（プロダクトマーケットフィット）の罠」と書いててありますが、ベンチャーの世界やプロダクト新規事業では、「プロダクトマーケットフィットをまず検証する、それができたらアクセルを踏もう」が定説になっていると思うんです。
ただ、僕はそんなキレイな状態が起こるのかとかなり疑問を持っています。どちらかというと、アクセルを踏んで初めてPMFに到達すると思います。あるプロダクトがうまくいって、その次のプロダクトを出す時は、すごく意識したほうがいいと思うんですが、昔やったことはなぜか忘れてしまうんです。「僕たちは、まずこのフェーズでPMFをしたあとにアクセルを踏んで、組織を拡大して、グッと伸びて、こうやったよね」みたいに記憶が改変されてしまうんです。
新規事業を起こす時には、まずPMFができるような検証をしようと言われていますが、僕の感覚では真逆で、「やると決めた結果、PMFをしていた」ことってけっこうあると思うんです。本で語っているような理想的なPMFはいろいろとあると思います。
例えば、「ユーザーに対してアンケートを取って、なくなると困ると言った人が7割に到達することがPMFだ」「ターゲットユーザー100人に聞いたら15人がお金を払います、時間を使いますと言ってくれたものがPMFである」もう少し初歩的な話だと、「LTV/CPAが3倍以上になったらPMFで踏んでいい」など。
僕は少なくとも、みなさんが実際にプロダクトと向き合ううえでは、こんな状態は起こらないと思っているんです。例えば、紙芝居を持っていって仮説を検証しろとよく言いますが、それでお金をもらったことはありませんよね。真の課題を引き出せるかというと、よくわからない感じで終わることがけっこうあると思います。
「プロダクトのデモを作ってきました、ヒアリングさせてもらって使ってくれませんか、実際これがこういう感じで、デザインがあたったら使いますか」と聞くと、だいたいリップサービスで、「それいいですね」「使いますよ」「お金払いますよ」と言ってくれますが、その後リリースして商談に行くと嘘だったことがわかる。
ほかに、実際にプロダクトをリリースしたあとの継続性は、特にtoBプロダクトの場合強く重視されると思っています。「途中でやめませんよね」とか、「しっかり投資して改善していくものであれば入れますよ」みたいなことです。
要は、紙芝居だけだとPMFを検証したいという中途半端なやり方で、じゃあPMFしなかったら撤退するんですか、ということです。このサービスに僕らが乗っかったとして、データはどうなるんですか、この業務はどうなるんですか、というところで、結局、継続性や永続性を前提としたプロダクトでないと、まともな人は買ってくれません。
また、普通に商売をしていると、顧客はどんどん広がってぜんぜん違う顧客層に当たります。プロダクトもどんどん変わっていきます。チャネルがどんどん変化していきます。「いつの数字を信じればいいの？ 常に変わっていくんだけど」となる。
アクセルを踏まないとアクセスできない顧客もいます。その反応がBtoBだからこそ、継続性を本気で見られると思うんです。（アクセルを）踏まないと本当にプロダクトだけをシビアに見る顧客には出会えないんです。PMFが終わってからアクセルを踏むのか、アクセルを踏まないと、ここが突破できないのかというと、にわとりと卵で、僕はアクセルを踏むことが卵だと思っています。
お客さまにどんなにボロクソに言われても1年間はがんばろうと思った
プロダクトをやっている時、理想的なPMFには達しなかったので、すごく不安だったんです。僕らは、プロダクト作りや起業などを経験していたので、「こんな反応やこんなトラクションじゃ、ちょっと踏んでも厳しくないか」という考えが何度も頭をよぎったんです。
今思うとアホらしいですが、何度もそれが頭をよぎった結果、（1つ前のスライドを示して）先ほどのこれを思い出したんです。提供価値は作るのに時間かかる。そもそもリスクを取らないとプロダクトの価値は生まれない。ここで撤退することが、果たしてヘルシーな意思決定なのか……まず1年がんばろうと思ったんです。
お客さまにどんなにボロクソに言われても、使わないと言われても、どんなに醜い結果になっても、1年は踏ん張らないと駄目だと思ってやったんです。そこから競合環境も変わってきて、まったくPMFしていないのにアクセルを踏まないといけない、ベンチャーあるあるな状況に追い込まれたので踏みました。
踏んだ結果、なんとなく今は自信があるんです。もしかしたら初めてマーケットフィットしたかもしれない。翌日には、やはりしなかった、みたいにコロコロと変わるのですが、それは前提が変わるということです。
アクセルを踏んで、初めてそれっぽいものにたどり着いたかもしれないという感覚がありました。例えば、いくつかプロダクトを分散して、試しながらいいものに寄せていくという発想は、プロダクト作りでは絶対にやってはいけない、PMFの本が語る理想的なPMFの罠です。僕らはこれにはまっていました。今振り返ると、もっと躊躇わずにどんどんアクセルを踏めばよかったと思っています。「そんな規模で？」「そんな状態で？」みたいなことこそすごく大事だと思います。
罠その4 阿吽の呼吸の罠
実は今、解決していない問題として、スケールする時に起こる、阿吽の呼吸の罠があります。僕らはプロダクトをリリースしてまだ1年も経っていないので、プロダクトマーケットフィットという言い方はあれかもしれませんが、初期から見ているメンバーと、今入ってきたメンバーには、ドメイン知識の差がすごくあります。
僕たちは驕っていたんです。こういう状況があることはなんとなく知りつつも「僕たちはほかの会社と違って、今のやり方でもスケールできる」「僕たちはほかの会社と違って○○なんだ」と。特別だという驕りが阿吽の呼吸を生み、それが新しいメンバーのオンボードの制約となってスケールしなくなります。
初期は少数精鋭で、みんなでドメイン知識を学び、開発もすごく密結合にやっていくがゆえに出る早さがあると思うんです。プロダクトを立ち上げる時は、必ずこっちに振るべきだと。一方で、「これはもうスケールさせなきゃ」と思ったら、いち早くそのやり方を捨てなければいけないことを僕は知っていたはずですが、「今回は特別だし、優秀なメンバーを集めているし、できるんじゃねえか」という謎の驕りがあったんです。
かつて、情報を記録するということを疎かにしたこともありましたが、今回はそういうことはしていません。開発中のログも全部溜めているし、スプリントでどういう議論をして、どういうベロシティが出たかも全部記録しているし、商談やカスタマーサクセスの動画も全部記録していて、情報は十分にある。こんなに優秀な人を採用して、情報を透明にしてアクセスしやすくして、さらに各人が自律分散に決められるようなKPIの設定もしている。「俺たちはいけるだろう。簡単にオンボードできるし、どんどんスケールさせられるだろう」と思いましたが、そんなことはないんです。
それは阿吽の呼吸で動いていることと変わらないので、結局駄目でした。今はセオリーに従って、例えばオンボード期間を半年置くとか、あえて、非エンジニアリング的な経理や請求書に関わる業務の知識をキャッチアップする時間を作るとか、そういう当たり前を当たり前にやることを徹底しています。
これで阿吽の呼吸の罠からは抜け出せるのではないかと思っていますが、なぜか人間は回数を重ねるごとに、自分たちは特別だという驕りを忘れられなくなります。「こんなにきちんとやっているんだからいけそうじゃん」という考えにはまってしまっていたということです。
以上がはまっていった罠です。最後に、それらを踏まえた結果、今のLayerXのプロダクト開発組織はどうなっているかについて話します。まず、組織としてブレないために、事業部のミッションを決めました。これも阿吽の呼吸の罠みたいなところがあって、例えば新しいメンバーが入ってきた時に、プロダクトを見せて、経理の効率化や、効率化をした結果何が起こるのかという部分を伝えていたつもりでした。
こんなにわかりやすいプロダクトを作っているんだから、見てくれれば伝わると思っていたんですよね。でもそれは自明ではないので、そういう暗黙知であった部分を、ミッションレベルで決めるために、あらためて言語化をしています。
LayerXの現状
今どういうメンバーがいるか。プロダクト型の組織を目指したので、プロダクトを作っていたメンバーやSaaS事業、ビジネス経験のあるメンバーを採用しています。コンサル事業のためのメンバーはぜんぜん採用していません。
スケールするタイミングになって、阿吽の呼吸の罠にはまった経緯を踏まえて、今は組織としてプロダクトの提供価値を出すことにこだわっています。その背景には、売上と提供価値にすごくギャップがあったという反省があります。
今はメンバーの優秀さや、開発資源の希少性ではなく、実際にプロダクトでどのくらいの時間を削減できたのか、どれくらい強烈に業務を簡易化できたのかを見るようにしています。ここは会社として、定量・定性の面からプロダクトチームで一番重視しているところです。
（スライドを示して）契約する前に営業チームがこういうKPIを作ったり、実際にオンボードさせる段階でプロダクトチームとカスタマーサクセスのチームが連動して、オンボード後のヘルスコアを見ています。僕らは売上＝どれだけの経理事務を削減したかという裏KPIを持っていて、「ここと売上が一致していないと、この売上は意味がない」というくらい、どれだけ時間や工数が削減できたかを徹底的に追っています。
ほかに、意思決定の自由度を上げることや、最初の開発者とお客さまとの間に伝言ゲームのように人を置かないことを重視しているので、エンジニア、ビジネス職問わず、自律的に分析やモニタリングを行って、きちんと記録した結果こうなっていますなど（スライドを示して）開発文化にも反省が活かされています。
「デモ駆動開発」は少しもじったような言葉ですが、コンサルをやっていた時にプロダクトではなく資料ばかり作っていた背景があるんです。資料ばかり作っていたけれど本当に意味がなかった。やはり動くものが圧倒的に正義で、動くものがあって初めて議論ができる。
紙芝居営業もぜんぜん駄目でした。紙芝居で営業をしましたが、マジで時間の無駄だったと思いました。それよりも簡単なものでも、すごく狭まった体験でもいいから、そのプロダクトのアハ体験と言えるようなものを、どんなにダサくてもいいから動くかたちで早く顧客に見せたほうが意味があると僕らは思ったんです。なので、週次定例でもプロダクトのデモを見せるなど、ここを見せるために開発の優先度を切るくらいの決め方をしています。
技術スタックと開発のこだわり
（スライドを示して）「技術スタック」については最初の話との対比になると思いますが、反省点があります。LayerXはブロックチェーンのコンサルをやっていたのに、今は自社のプロダクトを作る時にブロックチェーンの技術を一切使っていません。でも、これが僕らの意思決定のすべてだと思っています。
つまり、合理的な意思決定ができていなかったんです。今使っている技術スタックは、ごく普通のものです。本当に一切ブロックチェーンは使っていません。将来は使うかもしれませんが、1つの選択肢に過ぎないくらいで、やはり意思決定が濁っていたということです。
開発は、どちらかというとプロダクトの立ち上げ期みたいですが、社内では、よく技術的な意思決定が大事だという話をしていました。要するに、どこを締めてどこを緩めるか、どこをマネージドサービスに頼って、どこをコアと定義して自分たちで開発して深掘りしていくかにこだわっています。最初からサービスの性質上、セキュリティの部分にだけはこだわっています。
正式な用語なのかはわかりませんが、うちのエンジニアがよく「スキーマ駆動で開発しています」と言います。プロダクトを作る前に、データベースのインターフェイスや、APIのインターフェイスのスキーマをベースにコードを生成してからやっていくところで、データベースの設計やAPIのスキーマ設計にメチャクチャこだわっているらしいんです。僕は開発に参加していないので伝聞ですが、そこは後戻りできない。適当にやってしまって、早さ＝雑になってはいけないので、そこを土台として開発スピードを底上げしています。
事業を作るということにこだわりたい
資産化については、インフラやフロントパーツなどの各種コードは徹底的に再利用できるようにして、次の開発のレバレッジを効かせています。「バクラク請求書（旧LayerXインボイス）」に加えて「バクラク申請（旧LayerX ワークフロー）」という新しいプロダクトを作っています。どんどん作るスピードを速めるよう工夫しています。
事業を作るということにこだわりたいと思っていますが、これもやはり最初の反省が活きています。コンサルを否定するというよりは、僕らがやっていたコンサル事業は事業に向かわず開発費を取ることに集中していたことを反省しています。
そうではなく、事業をまるっと飲み込んだ時に業務ドメインや業務フローを貪欲に理解する、生の声を拾っていく。マーケティングはマーケティング、セールスはセールスみたいに区切るのではなく、被る部分をしっかりと1つのプロダクトと定義して効率性を上げていく。○○の技術を使ったから解決されるという話ではないということをすごく重視しました。つまり、完全に頭を切り替えて事業をやっているということです。
開発の最後に、デザイナーがUIをあてるようなフローは個人的にはあまりいけてないと思っています。うちのおもしろいところですが、開発に逐次的に入れるように、デザイナーが積極的にコーディングをします。たまたまそういうデザイナーが在籍してくれているのが大きいのですが、それによってかなり開発のスピードが上がっていると感じています。
エンジニアブログでは、経営の考え方や開発の設計、開発組織の仕組みのほか、技術的意思決定について発信しています。
1人目のPMを募集中
最後に、今ちょうど1人目のPMを募集中です。1人目とはなんぞやですが、僕らの組織は今まであまりPMという人を置いていなかったんです。どちらかというと少数精鋭で、各エンジニアがある程度ユーザーの声も拾っているという前提で、優先度をPMが決めることはあまりありませんでした。
プロダクトオーナー＝PMで、そのプロダクトオーナーもエンジニアなので、ばりばりコード書きながら背中合わせで開発していましたが、そのやり方だと阿吽の呼吸過ぎてスケールしなくなってきたので、1人目のPMを募集中です。今はエンジニア上がりのメンバーと経理上がりのメンバーがPMっぽい働きをしながらやっていますが、もう少し本格的に暗黙知に頼らず意思決定ができる人を探しています。
どういうチームかというと、先ほどの失敗を経て、プロダクトに対して、ユーザーやお客さまが提供価値に対して感じている課題を、どんなやり方でもいいから最速で解こうと考えています。1年半前のチームと今のチームの雰囲気を比べると、同じメンバーでやっているのにこんなに変わりました。プロダクトに向き合っている時こそ、うちのチームのメンバーの良さが出ると思っています。
ぜんぜんパフォーマンスが違うんです。そういうことも含めて、今日お伝えしたかったのは「ちょっと最初に戻ろうか」です。やはり意思決定がヘルシーになされる。課題が早く吸い上げられる。それに対するデリバリーが早い。さらに、それが元になって紙芝居のようなあいまいなヒアリングではなく、実際に使われる実験の中で、すばやく顧客のペインがフィードバックされる。いかにこれに近づけるかだと思います。LayerXは、一般的な失敗ではなく、それを遠ざけるような失敗をしてきました。
みなさんもプロダクトを育てていく中で、アホな失敗は避けてもらいたいと強く願いつつ終了します。
