一人PMから二人三脚期を経て、PMチームになった話
※生成AIによると「Product Manager」はこんなイメージらしい（4人をイメージし、長井が Canva の Text to Image で作成）
スタイリストがつくネットショッピング「DROBE（ドローブ）」を運営しているDROBE COO の長井（@daisukenagai）です。
DROBE社では、このFY2023の上期にPM（プロダクトマネージャー）が2名増え、私を含めると合計4人になりました。
思い起こせば、2019年の創業時の一人PM時代から、はじめてチームになったという感覚を持っています。これもいい機会だと思い、DROBEをPMという切り口で振り返ってみようと思います。
創業 / 一人PM期：2019/04 - 2020/09
創業タイミングということもあり、PMという概念 / 職種こそギリギリあったと思いますが、言わずもがなこのタイミングはPMというより、TNZ（とにかく・なんでも・ぜんぶ）でした。
CEOとCOO
代表であり、PM経験も長い山敷ですが、創業当時から一定の棲み分けをしていたように思います（お互いに、まじまじと話したことはないのですが）。
ざっくり言えば上記のような感じです。
当時を振り返って改めてすごいなーと思うのは、PM経験がある山敷が「プロダクトをXXXにしてほしい」とか「YYYの機能を入れてくれ」とか、意見を突き通そうとすることが一回もなかったです（もちろん一意見としてのインプットはあります）。
ミニCEOとも言われるPMに意思決定を委ねる点、言うは易しで実はなかなかできないことかなと思います。もちろんプロダクトだけではなく、事業（つまりPLもBSもぜんぶ）を考えられるというのが大前提になるとは思いますが。
ここの関係性は以下の「どろきゃす」でも話しているのでご興味あれば。
PMとエンジニア
PMやプロダクト開発という意味ではこちらのほうがピンとくるかもしれません。創業時、エンジニアの都筑とは、常に背中合わせで開発をしていました。
仕様書は作らない。と、ドキュメントは最低限、当時はコロナ前ということもあるホワイトボードが仕様書代わりになっているときもありました。
こんな状態の中でも背中を預けられる状態のためには、PMはテクノロジーやプログラミングに対して、エンジニアにもビジネスやUXに対する素養やリスペクトが大前提です。
都筑には、ビジネスの話1を聞いて10理解したり、ちょっとした違和感を片っ端から直していくUX感度など、エンジニアとして以上にリスペクトする部分が大いにあり、常に背中を預けながらプロダクト開発を進められていた感覚がありました。
二人三脚期：2020/10 - 2023/07
PMFまでは解像度を高め、最少人数でやる。というDeNA時代の師匠の教えもあって、創業から1年くらいはPM採用せずに1人で突っ走ることにしていました。
これ。人数を増やすと合意形成やモチベーションのムラからむしろ時間がかかることも😌人数を増やすのではなく的を絞る https://t.co/p3JkwCxnzZ
— だーはら (@da_hara7) September 21, 2023
が、徐々に自分のカレンダーが常に空きがなくなり、ミーティングができなくなり、Slackのレスが遅くなり、、、と自分が明らかにボトルネックになることが露呈してきたタイミングで、DROBE社としてはじめてPMを採用することを決めました。
目まぐるしく状況が変わる事業や組織の中で明確に役割分担をできるイメージもなかったこともあり、PdMもPjMもBizDevも経験があるような人を想像しながら採用を進めていくことにしました。
McKinsey の「デジタル世界のプロダクトマネージャー」にも各プロダクトに対するプロファイルの記載があり、B2Cプロダクトは Generalist という記述もあるようです。
そんなこんなで（雑）、採用スタートから約半年後、Kさんがジョインしてくれました。
このタイミングから急速にドキュメント化などを進めていくことになります。
とにかく引き継ぎをしながら、こういうドキュメントを作っていきましたが、バージョン管理されていない自分の過去の記憶を遡るのはめちゃくちゃ大変で、なぜ少しずつでもドキュメント化してこなかったんだ…と後悔したことを覚えています。
カオス化したPRDも最低限の状態を保ているように整備。
一方で「まだ2人」の状況であり、明確なドメインや境目はつけられず、都度「これどっちがやる？」というという状況であることを前提に、ドキュメントやオペレーション整備の粒度や精度を決めていきました。
PMチーム期：2023/08 -
二人三脚にも限界が見え始めました。
プロダクト開発チームで価値を出していくことの重要度が高まる中で、
「どっちがやる？」横行により、特定ドメインへの解像度を高めにくい
結果、PMだけでなく開発チームの解像度向上や知見が蓄積されない
という状況が続き、更にPMを採用することを意思決定しました。
PMトライアングル
このとき初めて意識したのがPMトライアングルです
元記事を翻訳したこの記事が素晴らしすぎるので解説はこちらに委ねますが、DROBEとしては、
Kさんは、右下の「The Business」に該当すること
「Developers」はエンジニアとも協業 / 代替可能なこと
といったことを考えながら「Users」に関連するスキルや経験を中心とした方の採用活動を実施していきました。
なお、日本での採用ということもあり、より具体的なイメージをすり合わせるために古巣であるDeNAの「Pococha CultureDeck」も大いに参考にさせていただきました。
そんなこんなで（雑2）、2023年5月にJさん（元エンジニア）、2023年7月にHさん（元デザイナー）がジョインしてくれました。
ビジネスドメイン
2人→4人になるにあたり、最初に手を付けたのが責任領域（ビジネスドメイン）の棲み分けです。
社内で提案もあり、バリューストリームマッピング(VSM)を用いて、価値の流れを可視化し、各PMと話しながらビジネスドメインを決めていきました。
商品供給：DROBE事業の商品調達から商品価値向上
顧客体験：DROBE事業のマーケットからの顧客獲得および購入体験向上
xOps：DROBE社およびDROBE事業に関わる一連のビジネスオペレーションのスループット向上
実態としては、これと並行して開発チーム全体でもLeSS（Large Scale Scrum）導入の流れがあり、それともアラインしながら最も良い分割方法や境目を探索していったというのがより正確なところです。
DROBEのLeSS導入についての詳細は以下も参照ください
デリゲーションポーカー
ビジネスドメイン整理に伴って、デリゲーションポーカーを用いて、PO（長井）とPMとの権限の認識合わせもしました
現時点では、各ビジネスドメイン x アクションごとに大まかに整理をしている状態ですが、今後迷った際に立ち返ったり、目標設定に利用（e.g. 上期にXXXを4から5のレベルにしよう）することを前提に作っています。
さいごに
結果論ですが、3人よりも4人のほうが議論をするときに2対1の構造になりづらいなどの利点もありそうです。
まだまだ個人としてもチームとしても志半ばではありますが、プロダクトとともに成長して / させていきたいです。
PMイベントの登壇もお誘いいただいたのでもしよろしければ（同じようなテーマで話します）
こんなプロダクト開発チームに興味を持っていただいたエンジニアのみなさまはこちらもご覧ください。
この記事が気に入ったらサポートをしてみませんか？