少人数チームから大人数チームに転職して気づいた、PdMが意識するべきポイントの違い
はじめに
今年、自分の中での大きなイベントの一つとして、転職があった。
いわゆるスタートアップの少人数チーム（開発チームは自分含めて5人＋業務委託2人）から、GMOペパボ株式会社 SUZURI事業部、すなわち大組織（開発チームは20人超）への転職である。
転職の理由はシンプルで、自分が前職の本当に素晴らしいチームメンバーと働きながら学び身に付けたPdMとしてのスキルを、大人数チームでも発揮できるのか挑戦したいという気持ちが強くなったからである。なぜSUZURIなのか、の理由はたくさんあるが一旦ここでは割愛する。
これを執筆している11月末日現在、かれこれ転職して1ヶ月になるが、部下のチャレンジを積極的にサポートしてくれる上司と協力的なメンバーの姿勢のおかげもあいまって、今の職場ではまさに自分がやりたかったことができている。むしろ期待以上である。
日々少人数チームのPdMとしての動き方との違いにハッとさせられることがあり、それにどう対応していくのか？を考え、実行している。とてもやりがいがある環境だ。
今回は、転職して1ヶ月が経ったので、現時点で少人数チームと大人数チームでのPdMの動き方として、個人的に感じた違いを書いていきたいと思う。
▼これを深掘っていく
人数が多い組織、少人数のチームとは全く違う視点があって面白い。
— マキヤマミルテ@SUZURI (@_mmakiyama) November 26, 2020
今までは密にやりとりすることがスピード感につながってたけど、大組織だと逆にそれが遅れの原因になりうる。
今はいかに各々の判断コストを下げられるか？をベースに、ルールの明確化やタスク状況の可視化などをとても意識している。
1. タスクの把握方法
少人数チームの時：朝会で進捗&スケジュール確認
前職では、タスク状況は毎日実施する朝会で概ね把握することができており、特に問題なかった（ちなみに今は新しいメンバーも増えてタスク管理ツールを正式に導入してるとのこと）。
少人数ゆえに、同時並行で進められるタスク数もある程度限りがあるので、朝会で進捗状況やスケジュールを確認し、「あの人は今これをやってて、来週これがリリースできそうだな」というのはドキュメントを都度更新する運用でカバーできていた。
大人数チームの時：タスク管理ツールで全員のタスクを可視化
上記の運用は不可能である。まず、全員を招集するようなMTGはとてつもなく時間を奪うので、できるだけ避ける必要がある。入社直後、メンバーの自己紹介の場を設けてもらっただけで45分近く要し、ちょっと申し訳ない気分になった。
また、人数が多いため、他の人が何のタスクを持っているのかをコミュニケーションベースで把握するのは至難の技、というかコストが半端なくかかる。
だからこそ、「誰が、何を、いつまでにやるのか」の全体像を、メンバー全員が把握できる環境を整えることが必須であった。
事業の急成長に伴いメンバーが急増した関係で、ここが改善の余地ありだったため、GitHubのProject機能を使ってタスク管理のカンバンを作って運用してみた...という話はまた別の記事で書きたい。
2. プロジェクトやタスクの進め方
少人数チームの時：密にコミュニケーションを取りながら進める
プロジェクトや新しいタスクを進めるにあたり、どれだけコミュニケーションのハードルを下げられるか、みたいなところを意識していたように思う。
そもそも全員よく喋る人たちだったので、話しかけにくい、みたいな問題はなかったが、特にリモートになってからは認識の齟齬や確認漏れがないよう、密にコミュニケーションをとっていこう！というのが少なくとも自分のスタンスだった。
大人数チームの時：ルール化してメンバーの判断コストを下げる
どれだけ個人の判断コストを下げられるか、というところが一番大事だなと感じた。もちろんコミュニケーションをとることも大事だが、わからなかったら相談すればいい、をベースにすると、間に挟まる人がどんどん増えて、スピード感が一気に落ちてしまう。
なので、ルールや判断基準を明確にし、ひとりひとりの判断コストを削減する、ということが業務スピードを向上させるにあたり肝要なのである。
まだ難しいなと思ってるのは、そのルールや基準の浸透化である。これは大人数に対して一人が言っててもあんまり浸透しないだろうなと思っていて、アクションするときに必ずそのルールが目に触れる（例：フォーマット）だとか、チーム自体をそもそも少人数チームに区切って、そこの各リーダーに啓蒙してもらうとか、そういう仕組みが必要である。
▼最近更新したエンジニアへのタスク依頼のフォーマットの一部。
人によって判断基準の境界線が曖昧にならないよう、明確に場合分けしてる。（対象 のところは、期日の根拠となるタスク内容の具体例を書いている）
3. 改善案を実行するまでのフロー
少人数チームの時：誰がやるかが自ずと決まる
PdMは自分一人だったので、やるかやらないかの判断含め最終的な判断をするのは自ずと自分になる。
さらにチームの課題感は大体共通であるし、何かをやろう！となったときに、エンジニア側も誰がやるのかは（人数の都合上）自動的に決まるため、あとはいつやるのかを決めればプロジェクトが進んでいく。
大人数チームの時：ステークホルダーが多いので実行するまで胆力がいる
大人数チームの場合、良い案や問題提起は人数に比例してたくさん出てくる。しかも、施策だけじゃなくてCS案件、他チームからの要望、セキュリティ対応、業務効率化など、同時並行でやらねばならないことが山ほどある。
そのため、いざ いいねいいね！やりたいね！となったときに、膨大なやるべきことの中から優先度とスケジュールを決め、担当者を割り振り、実行するまで大変な胆力がいる。
出てきた良い案を宙に浮かせないために、これまで以上に「やりきる」ことの重要性...逆をいうと、アイディアだけ出すことの無意味さを痛感する日々である。
▼本当この状態である
やりたいですね〜！って言ってるやつを本当にやるの本当に本当に胆力いるから、最近は「（いついつに）やりましょう！」って言い切ることで気合でやりきってる。
— マキヤマミルテ@SUZURI (@_mmakiyama) November 26, 2020
【12/29 追記：後日談】
なお、本記事執筆当時（11月末）はこのような感想でしたが、現在はこの大人数のチームを「座」という単位で分けて少人数チーム化したことで、劇的に 「3.改善案を実行するまでのフロー」 の大人数チームの課題が解消されたという話を、少人数チーム化を一緒に進めたSUZURIのシニアエンジニアリングリード・黒瀧（@kurotaky）さんとの共同執筆でペパボのテックブログにて公開しましたのでぜひこちらも合わせてご一読ください！
終わりに
ということで、転職して1ヶ月で特に違いを実感したことを書き出してみた。少人数と大人数、という主語が大きめの話をしてしまったが、もちろんやり方やルール、方針は人数の多寡に関わらず社によって違うだろうということを前提に、あくまで自分個人の所感である。
手前味噌ながら、今のチームは大人数組織で発生しうる「言われたことをやる」チームではなく、それぞれがサービスへの愛がとても強く、どうやったらもっとユーザーに喜んでもらえるか？ということをベースに全員が主体的に行動しているところがすごく素敵だなあと思っている。し、そういうチームがいる場所で働けてとても幸運である。
とはいえ、いくら個人個人が優秀でも、指揮者がしっかりリードしないとその能力を全力で発揮できないと思っているので、自分が指揮者もといPdMとしてチーム全体のパフォーマンスを最大化するんだ！という使命感を持って日々頑張って働いている。
※この記事は、SUZURIのAdvent Calendar（12月15日）の記事です。
昨日はあらきちさんのおすすめクラフトビール5選の記事でした。下戸だけどビール飲みたくなる！！
明日の担当は別チームの愛され系サブマネージャー・マグマスパゲティさんです。
SUZURIの他メンバーによる記事はこちら。
🐤🐤🐤
SUZURIにご興味を持っていただいた方へ
現在急成長中のSUZURIでは、一緒に働いてくれるメンバーを募集中です！サービスを心から愛しつつ、事業のさらなる拡大を一緒に目指していただける方は、ぜひ以下のページをご覧ください。
▼エンジニアを始め、全てのポジションで積極採用中です！
