「売上と提供価値は一致しているのだろうか？」　LayerXが陥った“ポジショントーク”と“売上”の罠

自己紹介と今日話すこと

福島良典氏：LayerXの福島です。本日は「LayerXのプロダクト開発と組織」という題目で話します。コンセプトとしては、ちょっとダサい失敗談を語ろうと思っています。僕自身は、かっこいいプロダクト開発理論や、理想のプロダクト組織論をけっこう研究していますが、それについては本を読んでください。すごく突き放す感じですが、ぐうの音も出ないほどの正論が書いてあるので、僕の話よりそれを読んだほうがいいと思います。

一方で、自分たちは特別みたいな驕りから、実際に事業をやる時やプロダクトを作る時に、参入角度、人、リソースの制約など、すごくダサい失敗をいっぱいしてきたんです。これからもすると思います。

今日は、それを語りたいと思います。なぜこんなダサい失敗をしているのか。スタートアップのプロダクト作りは、どうしても不確実で限られた情報の中で、走りながら決めなくてはならないので、あとで振り返った時に「当たり前だよな」「なんでそんなことをやっちゃったんだろう」ということこそ、実際に肌で体感しないとわからないと思います。

最初に簡単に自己紹介をして、LayerXがどんな会社かを話したあと、メインのダサい失敗と、失敗を経たうえで今どのような開発文化になっているかを話したいと思います。

まず自己紹介です。バックグラウンドだけ簡単に話すと、もともと大学時代は機械学習やコンピューターサイエンスを研究していたエンジニアであり、論文を書いている研究者でもありました。大学院在籍時に「グノシー」というニュースアプリを提供する株式会社Gunosyを創業して、その時には起業家×toCサービスというキャリアを築いていました。

今は2社目を創業していて、toB向けにどれだけいいプロダクトを作れるかにチャレンジしています。会社の特徴として、プロダクトピーポーが経営しているというところを一番強調したいです。

僕らの会社では、業界に一石を投じたくて、共同CTOは代表として代表権を持っています。ソフトウェアカンパニーにおいて、CTOは代表クラスの重要な役割だと思いますが、代表取締役CTOは見たことがないので、そのような人事を行っています。また、取締役の半数がエンジニアバックグラウンドを持っています。僕は、昔はエンジニアでしたが今は開発はやっていません。半数以上がエンジニアのバックグラウンドという点が会社の特徴です。

LayerXの3つの事業

今は3つの事業をやっています。1つ目は、いわゆる会計領域などバックオフィス領域のSaaSを提供しています。2つ目は金融事業。アセットマネジメント会社は、紙とアナログの業務なのでメチャクチャ非効率で、それが投資家のリターンを圧迫しています。僕たちは、何かツールを提供するのではなくて、事業をまるっと飲み込んでしまうかたちでファンドを運用してしまおうと、完全にデジタルなアセットマネジメント会社を運用しています。

3つ目がPrivacy Techの事業です。これは今立ち上げているところですが、データのプライバシー性が、昨今すごく課題になっています。プライバシー領域がどんどん厳しくなることにより、そのデータを使う制約も増えてきますが、そこを技術によって、制約は守りつつコストを低く活用できないかという事業を立ち上げています。

前提として、LayerXが理想としている組織像を一言で言うのは難しいのですが、今までしてきた失敗とのリンクで考えると、意思決定がヘルシーになされる構造がいいと思っています。ほかにソフトウェア企業の特性として、顧客の課題が正しく吸い上げられて、顧客とプロダクト開発の距離が近いこと。伝言ゲームみたいに間に人がいないことが理想だと思っています。

ほかにも、課題に対するソリューションのデリバリーが早いこと。これは開発が早いからでもあります。開発からマーケティング、営業体制を築くところからカスタマーサクセスという専任のサポートメンバーがつきますが、それらのメンバーがきちんと使い方をユーザーに教えるところも含めてデリバリーが早いこと。僕らはよくプロダクトに対する仮説検証を「実験」と呼びますが、それがすばやくフィードバックされることが理想です。

LayerXの歴史

おそらく、これらの理想はみなさん知っていると思いますが、知ったうえでどういう失敗をするかについて簡単に話します。LayerXがやってしまった4つのダサい失敗を「罠」と言いますが、「ポジショントークの罠」「売上の罠」「PMFの罠」「阿吽の呼吸の罠」という4つの話をしたいと思います。

LayerXという会社にみなさんがどのようなイメージを持っているかというと「ブロックチェーンやっていませんでしたっけ？」だと思うんです。実は、ブロックチェーンコンサルないし、ベンダーをやっていた時期からピボットして、プロダクト型の組織に変えていったという歴史があります。今はSaaSと金融領域をやっています。プラスでブロックチェーンの受託をお客様に迷惑がかからないよう、どうしてもすぐにやめられなかったので並走していた時期もあります。

コンサルやプロジェクト型の組織だった頃は、会社の案件が増えるごとにメンバーをアサインしていくような、プロジェクト型の組織でした。今はどちらかというと、プロダクトを作って売るところにフォーカスする組織です。組織のかたちに善し悪しはありませんが、組織がどう変わっていったかについてイメージを持ってもらうために説明しています。

罠その1　ポジショントークの罠

先ほどの4つの失敗をどういうフェーズでやってきたか。ポジショントークの罠は、ブロックチェーンコンサルを立ち上げる時にはまりました。拡大している時は、売上の罠がありました。ピボットしたあともそんなにいい話ばかりではなく、PMFの罠や阿吽の呼吸の罠にはまりました。

ポジショントークの罠は、LayerXの意思決定がどうヘルシーではなくなっていったかという話で、意外と語られていません。PMやプロダクトを作る人は、どちらかというと与えられた諸条件の中で顧客の要望を吸い上げて、そこに優先度をつけるという仕事の仕方をしていると思いますが、それ以上にポジショニングやどういう商流で入るかが大事です。

もともと僕たちは、ブロックチェーンに強い開発会社という立ち位置でビジネスを展開していました。ブロックチェーンに関する開発やPoCに関しては、LayerXに頼もうというポジショニングで事業をやっていました。今で言う、ブロックチェーンコンサルやベンダーとしていろいろなプロジェクトに入っていましたが、このポジショニングで入ってしまうと難しいと思うことが多々ありました。

LayerXが本質的にやりたかったのは、顧客や業界構造の課題に合ったデジタル技術の選定などの泥臭いことです。データを集めることやマーケティングも含めて事業をやりたかった。一方で求められることは、どんな理由でブロックチェーンを使うのか、それに対して開発してほしいという、いわゆるベンダーのような役割だったんです。

僕らはよく、初期の段階で「これはそもそもブロックチェーン以前の問題なので、こういうことをやりましょう」という提案をしていましたが、これには矛盾がありました。僕らはブロックチェーンベンダーなので、先方はブロックチェーンに強いLayerXに発注する理由が欲しい、そうでないと発注できないと言ってきます。

ブロックチェーンコンサルというポジショニングで入った時は、「今は特にブロックチェーンはいりません。今は、もっとそれを活かすためにこういうことをやりましょう」という提案をしたかったのですが、そういう提案は、おそらく顧客のためにはなっているけれど、まったく僕らの売上にはならなかった。そういうことが積み重なると、どんどんブロックチェーンを使う理由を考えようとします。

冗談みたいな話ですが、先方もブロックチェーンのプロジェクトだからやりたい、なんとか理由を作ってくれと言う。うちの取締役に榎本（榎本悠介氏）という凄腕のエンジニアがいますが、彼がコードを書くよりも「なぜこの技術を使うのか」という説得資料を作っていることがアホらしかったんです。何をやっているんだろう、ブロックチェーンコンサルはやめようと思いました。これが一番の原因だったんです。本当につらくて意味がないと思う仕事でした。後ほど教訓のようなかたちでまとめています。

売上は上がっても、何やってんだろうと思っていた

アホみたいな失敗ですが、ポジショニングが意思決定を規定してしまう。僕らの会社のメンバーはかなり技術にも強く、ここにはこういう技術を使ったほうがいいとか、ここはそもそもExcelでいいということも言えるのに、なぜかブロックチェーンを使わないと売上にならないアホらしい事態に陥ってしまった。

さらに、先ほどのポジショントークの罠と売上の罠が重なると、おそらく多くのPMや会社は苦しむことになると思います。売上と提供価値は長期的にはだいたい一致しますが、短期的には一致しない時もあります。LayerXはなんとも言えない状況だったんです。売上はメッチャ上がっていましたが、何やってんだろう、この仕事続くのかなという不安がすごくあったんです。

ブロックチェーン技術は世の中で言われているほどありがたいものではありませんが、すごく有望な技術なんです。それ自体は否定しませんが、単体で使うとINSERTオンリーのデータベースのような、高価なトランザクション型のDBに過ぎません。その結果、1社で使うとPoCで止まってしまいますが、複数の会社が一定の条件下でこの仕組みに乗ると確かに効果が出ることを実証したんです。

ただし、そんなに都合よく複数の会社は乗っかってきません。そもそもシステムの問題ではなくビジネス的な問題も多かったです。ブロックチェーンを使う以前にいろいろな提案をしましたが、僕らはブロックチェーンの技術屋みたいに見られていたので、なかなかこういう提案が通らないという苦しみもありました。唯一進んだプロジェクトが今の金融の事業です。これは三井物産株式会社などとのプロジェクトですが、皮肉にもLayerXのブロックチェーン以外の技術力や、ビジネス推進力を評価してくれた結果、「事業を一緒にまるっとやろう」という話になりました。

これが多くのPMにPOの意思決定を惑わせる理由だと思いますが、「○○ベンダー」に限らず、メチャクチャ売上をつけてくれる顧客が必ずしもその後のプロダクトスケールの一般性のために正しい開発をさせてくれるとは限らない、要するに正しい提供価値が一致しない可能性はけっこうあるんです。ここはすごく気をつけてほしいところです。

世の中にはブロックチェーンに対する期待がものすごくあって、中国やアメリカではたくさんの事例が出ていて、確かにそれらの一つひとつには意味があるんです。

発注者側も賢いので、そのような事例をしっかり調べて、こういう案件をやりたいという依頼がどんどん来ました。地獄です。売上は上がっていく。価値を提供できているのかという不安はある。先ほどのポジショントークの罠もあって、なかなか抜け出せない沼にはまっていきました。

売上の罠

（スライドを示して）「売上の質」とありますが、みなさん、プロダクトの優先度をつける時にはすごく気をつけてほしい。僕らも、何度も何度も気をつけてはいるものの、同じ失敗をしているんです。特に、開発費やセットアップ費（初期開発費用）をもらうビジネスではよく起こると思いますが、単なる需給の問題です。例えば、ITエンジニアは希少、機械学習できるエンジニアは希少、ブロックチェーンがわかっているエンジニアは希少、開発資源が希少だから上がっている売上は世の中にいっぱいあるんです。

一方で、プロダクトが提供してくれる提供価値につく売上、これが本質的な売上です。なんとも難しいのが、プロダクトの提供価値はそんなに急には作れない。しかし需給が壊れているところに、開発費で売上を上げにいくことはわりと容易にできるんです。短期では、こちらの上のほう（開発資源の希少性で上がってくる売上）が簡単に作れてしまう。一方、こちらは（プロダクトが提供してくれる提供価値につく売上）時間がかかるし、提供価値とは少しずつ上がっていくものです。

それをしっかりやっている売上なのか、そうではない売上なのかによってぜんぜん価値が違いますが、売上は売上として計上されてしまう。これが、ポジショントークの罠と需給で上がる売上が組み合わさると、本当に地獄になります。

僕らのポジショニングの罠の教訓です。どんなに合理的な意思決定ができるメンバーでも、どういうポジションで商流に入るかによって提案できるものや実装できるものが規定されてしまいます。僕らがどんなに課題ファーストやフラットな技術選定をうたっても、どういうかたちで売上を上げているかによってしまう。そして、それが自由度の低いポジションだと、圧倒的に非合理な意思決定を強いられてしまう。だから僕らはプロダクト型組織で自由度を取り戻そう。それが転換する時に一番意識したことです。

もう1つは、売上の罠です。これはスタートアップあるあるだと思いますが、「売上が上がっている＝提供価値が出ている」と思ってしまうんです。本当の意味でやっている人は、売上と提供価値がずれていることはわかっているんですが、売上が伸びていると、そのビジネスは正当化されてしまうので意思決定が遅れてしまう。本来は撤退すべきものをズルズルとやり続けてしまう。ただ、これは遅かれ早かれ是正されるので、売上の質を追おうというのが、この2つの罠から僕らが得た教訓です。

LayerXの3つの決断

そこで、課題は変えずにリスクの取り方を変えようとしました。コンサル時代に、こういう課題が解ければいいという、肌で感じられるニーズのようなものがあったんです。そういった部分を、僕らが事業やプロダクトをまるっと持つかたちにすることで、リスクの取り方を変えようと思いました。

ピボットをするといっても、突然「ゼロから、新しいソーシャルゲームでも作るか」となると、会社をやっている意味はありません。僕らがブロックチェーンコンサルをやったからこそわかる意味のあるプロダクトを作る。コンサルで感じた裏側にある真のニーズ、こういう社会課題を解決したいという会社のミッションはぶれなかったので、そこにフォーカスしようと思いました。

2つ目は、自由度の高いポジション。意思決定がヘルシーになるポジションを取ろう。僕らはむやみに業界を広げていたんです。金融領域も物流領域も保険領域もやるみたいに、プロダクト価値が貯まらない状況になってしまっていた。特にコンサルをやっていると、そのような状況になりがちです。

ある案件では物流をやって、ある案件では突然画像認識をやって、医療系をやって……となると、その業界を深掘りしている人にしかわからない深い課題が蓄積されないので、プロダクトを中心に課題を深堀りしていこう、徹底的に強い面を作ろうと意識しました。

3つ目は、けっこう血しぶきが飛ぶような意思決定でしたが、売上を捨てて、プロダクト型組織へ完全に転換しました。僕はコンサルから始めることを悪いとは思いませんが、スタートアップにいるような人の気質は、プロダクト型があっていることが身に染みてわかりました。コントローラビリティが低いので、相当コンサルスキルがないと、自分が課題と感じているものに対して、ピンポイントでミートして課題解決策を出せない。コンサルで働いたことがない人がそれをやるのは不可能だと思うので、プロダクト型に挑戦しようと思いました。

僕は両方やってみて、どういう課題を解くのか、どういう技術選定をするのか、それに対する技術選定以外のあらゆるアプローチも含めて意思決定の自由度の高さを得られることが、プロダクトリスクを取ることの本質だと思いました。

それによってヘルシーな意思決定がなされることが超大事です。プロダクト型にすることで売上の質が完全についてくるわけではありませんが、より高い質の売上に変わっていきます。メンバーが優秀だから売上がつくのではなく、プロダクトが提供しているものに価値があるから売上がつきます。その価値を上げるために優秀なメンバーが開発するというのが僕らの目指すべき組織だなと思って、変えました。

（次回へつづく）