[レポート] LayerXのプロダクト開発と組織 #pmconf2021

2021年10月26日(火)、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨するイベント『プロダクトマネージャーカンファレンス2021』がオンライン形式で開催されました。

当エントリでは、ブレイクアウトセッション『LayerXのプロダクト開発と組織』の参加(視聴)レポートをお届けします。

目次

• セッション概要
• セッションレポート
  • はじめに
  • LayerXがしてきた"ダサい"失敗
  • コンサル事業時代に陥った「罠」
  • プロダクト型組織移行後に陥った「罠」
  • LayarXのプロダクト開発の組織文化
  • 総括
• まとめ

セッション概要

セッション概要は以下の通りです。

• LayerXのプロダクト開発と組織

セッションレポート

はじめに

• 本日のコンセプト
  • "ダサい"失敗を語ろう
    • かっこいい情報は書籍に書いてある。正論はそっちを読もう
    • 実際のところは事業アングルや人的資源の制約、「僕たちは特別」という奢りなどからダサい失敗をいっぱいするもの。それを語ります
  • スタートアップの"リアル"を語ろう
    • 不確実な情報の中で走りながら決めなくてはいけない、という状況での「やらかし」
• 自己紹介
• 企業(LayarX)紹介
  • 上場企業の創業経験者達で固める経験豊富なチーム
  • 経営のエンジニア比率が高いテックカンパニー
  • SaaS事業/FIntech事業/Privacy Tech事業

LayerXがしてきた"ダサい"失敗

• 前提とする「組織の理想像」
  • 意思決定がヘルシーになされる構造
  • 顧客の課題が正しく吸い上げられ、顧客と開発の距離が近い
  • 課題に対するソリューションのデリバリーが速い
  • 実験の結果が素早くフィードバックされ、改善が回ること
• LayerXがやってしまった、4つの『ダサい失敗』
  • ポジショントークの罠
  • 売上の罠(提供価値とのギャップ)
  • PMFの罠
  • 阿吽の呼吸の罠
• LayerXの組織変遷：コンサル・PJ型の組織からプロダクト型の組織にピボットしている
  • コンサル・PJ型の組織の場合、案件が増える毎にメンバーをアサイン
  • 現在はプロダクトを作って売る形にシフトしている

コンサル事業時代に陥った「罠」

ポジショントークの罠

• コンサル・PJ型の組織時代、ブロックチェーンコンサル(ベンダー)立ち上げ期の話
• どういう諸条件、商流で入るのかが大事、という内容
• ポジショニングが意思決定を規定してしまう
  • "ブロックチェーンに強いLayeyX"というポジショニング。この条件で入ると、色々厳しい状況があった
  • LayeyXがやりたいのは事業、先方はベンダー的な役割を求めていた
  • ブロックチェーンコンサル的な立場で入ると『初期段階ではブロックチェーン要らないですよね』という提案になるケースも：お客様のためにはなってもLayerXの売上にはならない
  • 先方の意向(ブロックチェーンに強いLayeyXさんに発注する理由が欲しい)もあり、コードを書くよりも説得資料をつくる時間が長くなってしまった
  • 結果「ブロックチェーンコンサルやめよう」となった

売上の罠

• コンサル・PJ型の組織時代、ブロックチェーンコンサル(ベンダー)拡大期の話
• 売上≠提供価値
  • 世の中のブロックチェーンPoCブームに乗る形で売上は絶好調
  • 単体で使うと単なる高価なトランザクションDBに過ぎない
    • 結果PoC止まりに
  • 開発需要は旺盛、案件はどんどん来るのでやめられない
  • 売上の質
    • 単に需給の関係で、開発資源が希少だから上がっている売上
    • 一方、プロダクトが提供してくれる提供価値に付く売上(こっちが本質的な売上)
      • こっちは急には作れない、提供価値は少しずつ上がっていくもの
    • 短期では「需給の売上」の方が早く作れてしまうが、いずれも同じ「売上」として計上されてしまう
    • 前述の「ポジショントークの罠」と組み合わせていくと、状況によっては「地獄」となる

教訓

• 「ポジショントークの罠」から得られたこと
  • プロダクト型組織でリスクを取る
• 「売上の罠」から得られたこと
  • 売上≠提供価値
    • 売上が伸びているとそのビジネスは正しいと正当化されがち
  • 売上の質を追う

教訓からのLayerXの決断

• 「売上を捨てて、プロダクト型組織へ」
• 課題を変えず、リスクのとり方を変更
  • ブロックチェーンコンサルから、現在の3事業へPivot
    • コンサルを得て経た「リアルな課題」にフォーカス
    • 技術選定にとらわれないポジションに
    • 業界をむやみに広げない
      • プロダクトを中心に課題を深堀り、徹底的に強みを作る
  • 売上を捨ててプロダクト型組織へと転換
    • プロダクト型の本質
      • 課題や技術選定に対する自由度の高さ
      • 「ヘルシーな意思決定」が可能に
      • 売上の質：メンバーが優秀(希少)だから売上が付くのでは無く、提供価値に売上が付く。提供価値として開発したものがプロダクトに蓄積されていく

プロダクト型組織移行後に陥った「罠」

PMFの罠

• PMF = Product Market Fit
  • PMF(プロダクトマーケットフィット)とは？達成までのプロセスや検証手法までを解説
  • Product Market Fit（PMF）を定量的に測定する方法「Growth Accounting」とは？ | トピックス | 電通デジタル

Product Market Fit（以下PMF）とは、「プロダクト（製品やサービス）がマーケットにフィット（適合）し、受け入れられている状態」を指す。 平たく言えば、「プロダクトに満足して、継続利用してくれるユーザーが右肩上がりで増加している状態」のことだ。 投資家が投資するかどうか判断する場合も「PMFを達成しているか」を基準にする場合も多い。

• プロダクト型組織への移行後の話
• PMFが終わったらアクセルを踏もう → アクセルを踏んで初めてPMFに到達する
  • 本が語る理想的なPMFと現実
    • 理想：こういうのは実際あるのか？
      • 「なくなると困る」が7割
      • 100人聞いたら15人が「お金を払う」
      • LTV/CPA > 3
    • 現実：
      • 紙芝居では真の課題は引き出せない
      • リップサービスの「使いますよ」「お金払いますよ」
      • アクセルを踏まないと、新しい未知の顧客に出会えない
  • 理想的PMFに達していない不安
    • 何度も「撤退」のワードが頭をよぎる
  • 「アクセルを踏んでみて初めてPMFに到達」が正しい
    • 「鶏と卵」な問題はあるが、氏は「アクセルを踏む」が卵だと考えている
    • 1年は踏ん張らないとダメだ、と思い頑張る→競合環境の変化などもあり、全くPMFしてないのにアクセルを踏まないといけなくなった(ベンチャーあるある)→踏んだ→何となくの自信が芽生え「PMFしたかも？」と思う事も多くなってきた
    • 躊躇わずにアクセルは踏んでいこう

阿吽の呼吸の罠

• プロダクト型組織への移行後の話/まだ解決していない問題でもある
• 文脈を知るゆえの速さ、知るゆえのスケールのしなさ
  • PMF以前から見ているメンバーとそうでないメンバーの文脈差、ドメイン知識の差
  • 「俺たちは特別」という奢り
  • 「情報を記録している」という奢り
  • 「優秀な人を採用しているから」という奢り
  • セオリーに従う
    • 暗黙知の徹底排除

LayarXのプロダクト開発の組織文化

組織概要

• 組織としてブレないために、組織のミッションを決めた
• 阿吽の呼吸で支えられてきた部分を解く、暗黙知であった部分を新しいメンバーにとって自明となるようにミッションレベルで落とし込んだ
• メンバー比率
• メンバーのバックグラウンド
• 採用計画

カスタマーサクセスにこだわる

• 「カスタマーサクセス」に徹底的にこだわる
  • 「契約したが利用していない状態」は最悪
  • 業務フローに乗り、効果が出ることに徹底的にこだわる形とした
  • カスタマーサクセスは職種では無く、チーム全員で取り組むべき概念であり達成すべき状態
  • 定量・定性の両面からモニタリングを行い、お客様の成功に向き合う
    • 【定量】プロダクトKPI
      • 契約前からKPIを設定し、理想のユーザー像定義、定量的にモニタリングを実施
    • 【定量＆定性】モニタリング＆ヒアリング
      • エンジニア職、ビジネス職を問わず、自律的に分析とモニタリングを実施。異常があれば課題のヒアリングも行った
    • 【定性】お客様のリアルな声を聞き、プロダクトを改善する
      • 商談や月次フィードバックは動画(※要許諾)でチームに共有
      • エンジニアが同席するケースも
  • 解約率と幽霊解約
    • 共にゼロで確かな価値提供、高い満足度を実感
      • 幽霊解約＝契約はしているものの、請求書を全くアップしていない状態

開発文化

• 「爆速開発」＝高速な顧客課題、事業の検証と組織的学習
• 爆速を生む開発スタイル：基本は王道のスクラム開発(2週間1スプリント)＋爆速開発のための工夫を実施
  • 「自律的で、背中を預け合う並列開発」
  • 「デモ駆動開発」
    • 動くモノが正義、動くモノがあってはじめて議論出来る
    • コンサルをやっていた時に資料ばっかり作っていたことを反省
  • 「使われないものを作らない」
• 技術スタックの今：合理的な意思決定を行った結果

改めて、こうやって書いてみると変わった部分は少ない気がする。もちろんR&DではRustやIntel SGXなども登場するけど。SaaSや金融事業においては丁寧に普通の技術を普通に使い、巨人の肩に上手く乗ることで技術で悩む部分を減らして、とにかく顧客への価値とはなんぞやを突き詰めている。

— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) August 7, 2021

• 技術面でのこだわり
  • 爆速開発≠雑。こだわるポイントと、やりすぎないポイントに強弱を付ける
    • アーキテクチャはシンプルに、PMFが見えたら作り込む
      • マネージドサービスの徹底活用
      • コアとノンコアの意識
    • スケールと開発速度の両立のため、設計には初期からこだわる。一方やりすぎない部分も決める
      • サービス特性上、セキュリティは初期段階から手を抜かずにきっちり設計・実装
      • スキーマ駆動開発
        • DBとAPIスキーマをベースにコードを生成し、実装の土台として開発スピードを底上げ
    • 資産化
      • インフラ、フロントパーツ、各種コードは徹底的に資産化して次のレバレッジを効かせる。
      • 「LayerXワークフロー」は資産を活かし、2ヶ月でリリース
• エンジニアの気質
  • お客様にとって価値を届け続ける事にこだわる気質
    • 「事業を作る」
      • マーケティング、セールス、CS、全てのプロセスを含めて1つの「プロダクト」
      • ビジネス職と垣根を作らず議論に参加
    • 「お客様の声に応える」
    • 「新領域にチャレンジ」
    • 「ファクトベースで議論」
• 情報の透明性へのこだわり
  • アウトプット＝スキルx情報のアクセス性x組織リソースのアクセス性
    • 経営会議の議事録はフルオープン
    • 商談、フィードバック動画も全部アクセス可能
    • 各チームがオンボード資料を作成
    • 両代表が入社時オンボードにコミット

総括

• (再掲)前提とする「組織の理想像」
  • 意思決定がヘルシーになされる構造
  • 顧客の課題が正しく吸い上げられ、顧客と開発の距離が近い
  • 課題に対するソリューションのデリバリーが速い
  • 実験の結果が素早くフィードバックされ、改善が回ること

まとめ

という訳で、プロダクトマネージャーカンファレンス2021のセッション『LayerXのプロダクト開発と組織』の視聴レポートでした。

• プロダクトマネージャーカンファレンス 2021 の記事一覧 | DevelopersIO