ICC FUKUOKA 2024のセッション「事業成長を支えるプロダクトを作る秘訣 – プロダクト企画、組織の作り方からグロース戦略まで」、全5回の③は、プロダクトに沿った開発、組織編成などについて議論。LayerX 松本 勇気さんは、少人数＆爆速の自社開発スタイル、永沢 岳志さんはメルカリが編み出したプラットフォーム化による開発体制など、各社各様のスタイルを紹介します。ぜひご覧ください!
ICCサミットは「ともに学び、ともに産業を創る。」ための場です。そして参加者同士が朝から晩まで真剣に学び合い、交流します。次回ICCサミット KYOTO 2024は、2024年9月2日〜9月5日 京都市での開催を予定しております。参加登録は公式ページをご覧ください。
本セッションのオフィシャルサポーターはココナラです。
▼
【登壇者情報】
2024年2月19〜22日開催
ICC FUKUOKA 2024
Session 2C
事業成長を支えるプロダクトを作る秘訣 – プロダクト企画、組織の作り方からグロース戦略まで
Supported by ココナラ
(スピーカー)
稲田 武夫
アンドパッド
代表取締役社長
鈴木 歩
ココナラ
代表取締役社長CEO
永沢 岳志
メルカリ 執行役員CGO CEO Fintech / メルペイ 代表取締役CEO
松本 勇気
LayerX
代表取締役CTO
(モデレーター)
倉橋 隆文
SmartHR
取締役COO
▲
▶「事業成長を支えるプロダクトを作る秘訣 – プロダクト企画、組織の作り方からグロース戦略まで」の配信済み記事一覧
複数のプロダクトやフェーズに対し、組織をどう作る？
倉橋 チーム作り、方向性を同じにするという内容にもなってきたので、次のテーマに移りたいと思います。
何を作るか決まったとして、では、どんなチームで作るかですね。
アンドパッドでは20のプロダクトがあるということで、多数のプロダクトチームが同時進行していると思うのですが、どんな構造になっているのでしょうか？
▶製品（アンドパッド）
稲田 弊社がプロダクト組織を作る上で、いくつか大事にしていることがありますが、その中の一つがプロダクトフェーズという考え方です。
PMF、プレセールス、新製品、既存製品の4フェーズがあります。
この4フェーズのうち、各プロダクトがどのフェーズにあるのかを意識してもらっています。
プロダクト開発時点の会話やキーワードが全然違います。
例えばPMFであれば、とにかくファンを作ることが重要です。
ファン、ファンと、僕はファンという言葉しか言っていないです（笑）。
プレセールスは、仮でプライスを決めて、とにかく売ってもらいます。売れるかの検証ですね。
新製品のフェーズになると事業計画に入れ込むため、入射角度、つまり圧倒的に突き抜ける成長率が重要です。
既存製品になると、キーワードはNo.1です。
品質もそうですし、我々が作る意味は何かを問い続けます。
このように、フェーズを意識していますね。
PMも、それぞれ特徴がありますよね。
全部ができるPMはいないので、それぞれのタイプを考えて配置をしています。それが一番重要ですね。
倉橋 では、PMFフェーズばかり担当するPMもいれば、既存製品ばかり担当するPMもいるということでしょうか？
稲田 そうですね、できるだけ色々なプロジェクトをしてほしいと思っています。
既存製品ほど、要件定義は複雑化しますよね。
基盤開発系になったり、負荷の話になったりするので、要件定義能力が高い人は既存製品から入ります。
でもたいてい、PjM（プロジェクトマネージャー）能力の高い人は新規事業がしたくてベンチャーに入社します。
倉橋 そうですね（笑）。
稲田 （笑）。
でも、まずは一つ立ち上げてもらったら、そのあとで新しい事業に取り組んでもらうようにしています。そういう流動性は持たせていますね。
倉橋 なるほど。
鈴木 採用時点では、フェーズごとのPdM（製品情報管理）の要件で分けて採用しているのでしょうか？
稲田 PdMの採用は非常に難しいと思っており、どこか突き抜けていれば採用するという考え方で採用しています。
きちんと要件定義ができる方、プロダクトの設計能力が高いエンジニアドリブンな方、マーケットにディープダイブできる方など、突き抜けた能力を持っている人が弊社では活躍しています。
鈴木 この人は最初からPMFフェーズのプロダクトにアサインしよう、などイメージしてから採用するのでしょうか？
稲田 それはそうですね。
あと、SmartHRも同様だと思いますが、SaaSなのでPMM（プロダクトマーケティングマネージャー）という組織もあります。
まずPMMに所属してもらい、プロタクトについて徐々に学んでもらった後にPdMになってもらうケースもありますね。
PdMを採用後、どう育てる？
鈴木 皆さんにもおうかがいしたいのですが…PdM（プロダクトマネージャー）の採用に、実は苦戦しています。
採用もそうですが、オンボーディングがめちゃくちゃ難しいと感じています。
各社の状況は分かりませんが、ココナラの場合、あらゆるカテゴリを扱っているので、ハイコンテクストなのです。
ですので、「やってみてください」だと立ち上がらないのです。
PdMを採用した後、どういう経験を積んでもらうべきなのか、どう育てていくのか、オンボーディングで工夫されていることはありますか？
松本 まだプロダクト開発を始めて3年ほどなので、そこまで参考にならないかもしれませんが、「バクラクらしい開発」ができる人にしなければいけないと考えています。
ですので、既存のプロダクトを介して、バクラクらしい開発に慣れてもらうことが第一ステップだと思っています。
僕らもアンドパッドさんと同様、組織は結構流動的です。
その瞬間の重要な戦略に沿ってリソースをアサインしていくのですが、まずは1つのプロダクトに取り組んで成長してもらうようにしています。
ただ、プロダクトフェーズはまだまだ長いので、3年程度では、これから僕らも悩むのだろうと思っていますね。
倉橋 ちなみに、「バクラクらしい開発」とはどういう開発なのでしょうか？
松本 一番は、よく出す「爆速」というキーワードですね。
ヤフーさんが昔提唱していて、僕らも今、爆速開発と呼んでいるのですが、とにかくアウトカムを素早く届けることです。
アウトプットではなくて、アウトカムです。
実際にお客様が喜んでくれたものがどれだけ作れたかという点に、全ては集約されるべきだと思っているので、最優先はスピードです。
期間内に幾つの機能をリリースできたか、それがアウトカムにつながったかをしっかり追う必要があるため、スピードを担保するには色々なものをかなぐり捨てる意思決定をしなければいけません。
普通であれば必要だと思っているものでも、意外と捨てられるものもあると思います。
お客様の話を聞いて裏のニーズを探り、どれだけ素早くアウトカムを届けられるかという点に振り切るスタイルです。
また、組織について言えば、プロダクト開発は少人数で行っています。
僕らの開発組織は、1プロダクトあたり平均3-4人で作っています。
倉橋 小さい！
松本 少人数ですし、PdMも全ての仕様の要件定義をしているわけではないのです。
何を作るかという大雑把なプランは作りますが、あとはエンジニアが作り込んでいきます。
倉橋 なるほどなあ。
松本 その中でデザイナーと連携して整えたり、逆に、先にデザイナーがUIを作ったり、あまり役割を規定せずに少人数で、フルスタックで開発しようというスタイルです。
これが私たちの組織のらしさというか……。
永沢 エンジニアも入れて3人ですか？
松本 PdMにプラス、エンジニア、デザイナーです。
デザイナーは兼務することも多いので、専属エンジニアを入れて3名ですね。
永沢 アウトカムとは、その領域の売上を指していますか？
それとも、お客様のエンゲージメントを測っているのでしょうか？
松本 エンゲージメントに近いですね、お客様の課題が解決したかどうかです。
To Cのサービスとは違うポイントは、アウトカムが届いたとして、それがすぐに売上に反映されるわけではないということです。
セールスやカスタマーサクセスの活動の中では、プラスだったという評価にしかなりません。
そこには少し距離がありますね。
倉橋 機能とUXのバランス、スピードとクオリティのバランスの取り方が難しい気がしています。
先ほど話していた「バクラクらしい開発」というのは言語化されているのか、それとも徒弟制度で見て学ぶものなのか、どう実践されているのでしょうか。
松本 両方ですね。
属人的に突き抜ける＆全体水準を上げるチームの2軸（松本さん）
松本 衝撃的な話をすると、バクラクにはいくつもプロダクトがありますが、最初の開発は1人で行っていました。
榎本という天才がいまして、彼の能力を最大限発揮させるための組織を作ってきたのです。
▶“本当に”使いやすいプロダクトとは。バクラク事業部CTOが目指す「愛のある」ものづくり（#LXエモカレ）｜LayerX
ですから、バクラクらしさの一つの要素は、榎本らしさです。
初期のLayerXはすごく属人的であり、だからこそ爆発開発を実現できたと思っています。
僕の組織作りのモットーは「楽しく」であり、また、メンバーの能力が、その人がしたい仕事で発揮されている状況が良いと思っています。
色々な人を採用して、その人たち全員のやりたいことをうまくパズルにしながら組織を作っています。
CTOの榎本は、とにかく早く作るのが好きで、お客様の話を聞くのが好きなので、「好きなように作って」と作らせます。
横軸には、デザインのUIのパーツやトンマナを揃えることなどを担当し、全体の水準を上げていくチームと、縦軸には属人的に突き抜けてもらうという二軸がある、と組織を整理しています。
倉橋 フェーズによって得意不得意が分かれるので、アンドパッド稲田さんの組織に近い気もします。
特定のことはそれが得意な人に任せて、後から別の人が整える感じですよね？
稲田 任せた後、整えるタイミングで大きなネガティブが発見されて、前任者を否定しなくてはいけないケースもありますよね。
でもLayerXは、それをするっと乗り越えていっている印象を、勝手に持っています。
エンジニア出身のPMをどう育てるのかが、私の関心事です。
PMとテックリードは、どこまでいっても利害が一致しないですよね。
私にとって、プロダクト開発組織の変数は、グッドPMとグッドテックリードの組み合わせです。
良い組み合わせをいくつ作れるかが、事業スピードを決めると思います。
1人が両方できたらベストだとも思っています。
榎本さんは作りきる人かもしれませんが、エンジニアからPMになる場合、どう育てているのか、ぜひ聞きたいです。
永沢 メルカリの場合、ある程度スケールしなければいけないという前提があります。
松本さんの話はすごく印象的でした。1人の強い個の世界観で作り上げて別の人が整えるというのは、それを念頭に置いて組織設計をしておかないと実現できないと思いました。
過去の失敗をもとに、負債がたまらないように、最初からプラットフォーム化しようとしています。
そのチームにはプラットフォームに強いPMがいて、新規事業を作るための基盤を整えます。
標準化するという発想なので、スピードよりも安定、コントロールしながら事業を立ち上げる方向に進んでいます。
一方で、新規事業を立ち上げる際、全てその方法でやるとスピードが出ないともずっと思っていたの
で、今の話は参考になりました（笑）。
倉橋 とはいえ、メルカリもプロダクトをどんどん出していますよね。
永沢 個人的には、もっと速くできると思っています。今のスピードは遅いかなと思います。
倉橋 プラットフォームや技術など、これを満たさないといけないというものがある中で……？
永沢 そうですね、それを決めないで始めた後のインテグレーションが結構大変だったんです。
倉橋 昔はそんな感じだったのですね。
永沢 今はワンアップです。
例えば会社を別に立てて、そこで別に作ってしまうと、その瞬間は良いかもしれませんが負債が溜まっていって、コアメンバーが抜けたり、別事業を始めたりすると、対応がすごく大変になるという経験をしました。
それを経て、どこまで共通化するかについての議論が始まって、その議論を今も続けています。
慎重開発、スピード開発の２つに分ける理由（倉橋さん）
鈴木 聞けば聞くほど皆さんの組織が素晴らしすぎて……でも、しょうもない話もしていいですか？
先ほどのバクラクの開発体制について、少人数で、PdMも最小でバトンを渡しつつ、各メンバーが自主性を持ってというのはベストだと思います。
我々も小さい会社だった時はそうだったのですが、組織が大きくなるにつれて、 気づけばバトンリレーのようになってしまうこともあります。
これは極端な例ですが、PdMが完璧に仕様書を作って要件定義をしたと思っていても、そこに漏れがあるケースが絶対にないとは言い切れません。しかし、仕様書のまま実装してしまうエンジニアがいる、ということも起こりうると思います。
それを起こさないようにする、起こった時にどう前の状態に戻すかについて聞きたいです。
SmartHRも1,000名を超えていると思いますが、そういうことは起こっていないのでしょうか？
倉橋 私たちも社内は大きく2つに分かれています。
マザーシップと呼ばれる超巨大なコードベースがあり、そこでは影響範囲を考えるので、物事が進むのがめちゃくちゃゆっくりで、慎重に開発します。
配置シミュレーションなど新しいアプリケーションを作るチームは、LayerXと同様、最初は3人ほどの組織なのです。
その3人が作り、その3人がそのプロダクトによる成果に責任を持つ形なので、開発は結構スピーディーで全てをドキュメンテーションしません。
ツーカーで開発してしまう感じです。
土台となっているマザーシップについては開発に時間がかかりますが、アプリケーションはスモールチームでとにかく高速で回していきます。
この、スモールチームという形式がすごく大事な気がします。
オーナーシップを持ち、お互いの顔が分かる状態なので。
3人くらいの小さいチームにできるかどうかが勝負だと思っています。
鈴木 それぞれの人の特性によって、アサインメントを分けていますか？
たとえば全エンジニア、全デザイナー、全PdMが主体的に物事を進める、当事者意識を持っていると理想的ですが、それは難しいですよね。
倉橋 それ、すごく分かります。だからうちは完全に分けていますね。
ベースを担当する、じっくり開発をしたいタイプと、PDCAを回して混乱も楽しめるタイプに明確に分かれるので、その間の人材交流はあまりなく、結構固定化されます。
鈴木 採用時点で分けているのか、入社後に適性を見るのか、どちらですか？
倉橋 我々の場合、採用時点では分けていませんが、採用後の配置を決める時に、この人は何となくこっちかなとアサインし、もしはまって本人もハッピーであればそのまま続けてもらいます。
とはいえ人間なので、ずっと似たことをしていると逆のことが恋しくなるため、その場合は異動してもらいます。
組織、技術、ソフトウェアを同時に設計する
松本 LayerXは、逆かもしれません。
我々は当事者意識を持っている人材しか採用しません、これはカルチャーの問題だと思っています。
カルチャーに合わない人は採用しないというルールは、徹底しています。
例えば、僕がリファラル採用で誰か候補者を連れてきても、社員の誰かが、NOではなく「ちょっと分からないですね」と言った瞬間、それはNOということなので採用しません。
それくらい採用基準を明確にしており、最初から全エンジニアが価値にコミットできるように組織を作っています。
また、物事が複雑になる理由は、人と人とのコミュニケーションの設計の問題だと思います。
なぜそれがソフトウェア開発に影響を与えるかと言うと、みんなの利害が自分の作っているものに紐づくからです。
組織、技術、ソフトウェアを同時に設計する必要があります。
その上には、事業のあり方やお客様にとっての価値があり、それに合わせて組織と技術を同時に設計することをプロダクトの開発初期からずっと考えていました。
そこで、プロダクトカットで作るけれど横軸でIDが連携されるので、何を作るか分からなくてもIDは分離し、プロダクトが増えてきてもバクラクらしいスピードやトンマナを揃えていくために、さきほどの横軸のイネーブリングと呼んでいる仕組みを作りました。
これによって、組織がもっと攻められるということに当事者意識をもって燃えてくれる人を連れてきて、みんなで共有するデータ資産などの共通基盤を作っています。
僕は、こういうことは1年半先を見据えて設計しています。
ですので、「1年半先にはこうなっているから、あなたが入社するとこういう面白いことになるから、ぜひ入社してください」という採用を、ずっと行っています。
その、採用する人の個人ミッションが組織に与える影響まで全て考えて、組織を設計しています。
鈴木 ありがとうございます。
採用が肝だというのは本当にその通りだと思いますが、どうしても人が欲しい、足りない……。
倉橋 エンジニアやPMは常に足りないですからね。
鈴木 この売り手市場で、そこまで徹底されているのはすごいですね。
ちなみに、メルカリにもエンジニアがたくさんいると思いますが、当事者意識の醸成については、どう工夫されていますか？
永沢 僕はエンジニアの面接には入っていないので分からないのですが（笑）、基本的にはミッションとバリューへの共感がある人を採用しています。
ただ、今の話を聞いていて、やはり組織のサイズが大きくなると、カルチャーをどう担保するかについて、改善の余地があると思いました。
小さい組織の方がカルチャーの浸透率というか濃度は高くなるので、そういう環境をいかに作りながらスケールさせていくかということなんだなと思いました。
倉橋 オーナーシップを持ったスモールチームを作るのが正義だということですね。
今のテーマで無限に話せそうですが、時間も迫っているので、次のテーマに移りたいと思います。
今の時代のプロダクト作りにAIは避けて通れないので、松本さんに語っていただければと思います。
（続）
編集チーム：小林 雅／小林 弘美／浅郷 浩子／戸田 秀成