1人目PMを2回経験。自己組織化したプロダクトチームをつくるためのロードマップ【開発PM勉強会レポート】

2022年10月12日

note株式会社プラットフォーム開発グループ とどけるユニット マネージャー

石坂 優太

新卒でパイオニアに入社し、カーナビ開発のソフトウェアエンジニアとして従事。その後、ビズリーチ、リテールテック領域のスタートアップを経て、2019年5月にnote入社。
入社当初はエンジニアとしてサービス開発に携わり、2021年4月よりプロダクトマネージャーを担当。現在はnoteのクリエイターやnoteに投稿された作品を、広く世の中に届けることをミッションとする「とどけるユニット」のマネージャー。

IT業界のプロダクトマネージャー、プロジェクトマネージャーのための相互学習コミュニティ『開発PM勉強会』。8月30日に開催されたイベント「開発PM勉強会 vol.14」のテーマは「プロダクトの1人目PM」

note株式会社プラットフォーム開発グループの「とどけるユニット」でマネージャーを務める石坂優太氏から、noteのPMチーム立ち上げと、自己組織化したプロダクトチームをつくるためのロードマップを紹介していただきました。

1人目PMって、つまりどんな人だろう?

1万人規模の大企業から10人規模のスタートアップ企業まで、幅広い規模の企業に所属した経験を持つ石坂氏は、1人目PMも2回経験しているという。そんな彼が今回の勉強会に登壇するにあたって考えたのは、「1人目PMって、つまりどんな人だろう?」ということ。

スタートアップ企業での立ち上げ初期なのか、それとも事業をより成長させるため新規事業立ち上げ初期なのか。企業の規模感や事業のフェーズによって1人目PMが担うべき役割も異なるし、求められるスキルも大きく変わる。

ただ、傾向としては「企業フェーズと事業フェーズが初期であればあるほど、プロダクトに向き合う割合が高くなる。その後、企業と事業が成長するにつれて、組織に向き合う割合が高くなっていく」というのが石坂の見解だ。

そんな石坂がnoteで1人目PMになったのは、「初期の初期ではないけれど、まだまだ成熟したプロダクトではない」時期だった。PM体制の立ち上げ・整備がまさに目下の課題だったという。

開発組織を立て直すために、noteの1人目PMが誕生

石坂氏は2019年5月にエンジニアとしてnoteに入社。その後、noteの飛躍的な成長にともなって開発チームの人数も3年で約2.5倍以上に増加した。しかし開発体制は3年前とほぼ変わらず、CEOとCXOがPMの役割を担っている状況だった。

事業の規模が大きくなるにつれ、少数の意思決定者に負荷が集中し、ボトルネックになりつつあった。長期的な機能開発を担う複数の開発チームに加え、短期的な機能改善を担うカイゼンチームも抱えており、石坂氏は「この体制でこの規模を支えていたのが不思議だった」と当時を振り返る。

▲図式では4つのPJTチームに分かれているが、実際はもっとあったという

当然、カバーしきれない部分も増えてきて、意思決定の質と量が下がり出してしまう。現状打開すべく、経営チームと開発チームが話し合い、noteのミッションである「だれもが創作をはじめ、続けられるようにする」を実現するために、PMのポジションを新たにつくって開発体制を一新することにしたのだ

そこでPMの経験があり、エンジニアチームのリーダーも務めていた石坂氏がnoteの1人目PMに抜擢されたのだ。

自己組織化したプロダクトチームをつくるためのロードマップ

こうして1人目PMとなった石坂氏は、「PMがひとりいたからといって、根本的な課題解決にはならない」と考え、自己組織化したプロダクトチームをつくり、組織に根付かせるために動き始めるのだ

▲PMがソリューションを決めて開発チームがそれを実行するようなトップダウンの組織ではなく、チーム全体で課題特定から仮説検証まで担える自走するチームをつくりたい

第1フェーズ:種まき

まず、PM、エンジニア、デザイナーで構成されたプロダクトチームをひとつ立ち上げた。石坂氏は当時エンジニアチームのリーダーも兼任していたため、別の方にPMをアサインし、自分はサポートする形で関わっていたという。

チームには従来のようにタスク単位でアサインするのではなく、事業目標に対して解くべき課題をアサインし、チームで課題に対する解き方を決めたり、仮説立案をしたりするようにした。さらに、PRD(プロダクト要求仕様書)を使った企画から振り返りまでのサイクルを導入しチームとして動くための知見を蓄積できるデータ基盤の構築行った。そうすることで、社内の複数チームを展開していくための「型」をつくったという。

一方で第1フェーズの反省点として、石坂氏は「PM経験者である自分が事例をつくってから、引き継いだほうがよかった」と語った。チームにアサインした「2人目PM」はPM未経験の方で、イチからのキャッチアップでだいぶ苦労をかけたという。

さらに、組織が拡大していくことを見据えて、PM候補をほかにも選出しておいたのは正解だったという。外部からPMを中途採用するのは、適する人材が少なく時間かかるため、「PM体制を立ち上げていく初期には、会社のミッションやビジョンを理解している社内の人間から、候補を選出して育成するのがベストという学びが得られた。

第2フェーズ:広げる

事業の規模が大きくなり、noteの開発組織「プロダクトの基盤をつくるチーム」と「プロダクトのグロースを目標とするチーム」に分かれた。第2フェーズの「広げる」は、このうちプロダクトのグロースを目標とするチームの施策である。

このフェーズでは、第1フェーズでつくった型を使い、一部従来の機能開発にフォーカスした「フィーチャーチーム」を残しながら全体の約6割のチーム体制を変更した。

PM採用にもさらに力を入れ、社内でのコンバート積極的に行った。だた、それに比例して開発メンバーも増え続けたため、PMの人材不足が依然として課題だった。

また、プロダクトチーム体制に変えて影響範囲が広がったぶん、「こうする意義がわからない」「うまい企画ができない」など、体制変更の意図が十分に浸透できなかったための課題も多く抱えていた。

ただ石坂氏は「こういう規模の組織で新しい取り組みをやっていくなら、トラブルはつきもの」とし、その状況を受け入れるのも大切だと話している。

「組織の形さえ整えたら、あとは自然とうまく進んでいく」なんてことはない。現場の状況を細かく判断しながらの、適切な対応がPMには求められる。

そして第2フェーズを経ての感想として、石坂氏は会社全体のコンセンサスが取れたうえでチームの体制変更を推進することが極めて重要だと話した。これだけの規模になるとPMの意志のみならず、EMやCTO、デザイナーの協力を得られてこそ、「自己組織化したプロダクトチームづくり」 を成し遂げられるのだという。

第3フェーズ:成果を出す

第3フェーズは現在取り組んでいる段階だ。第2フェーズまでを経て身につけてきた考え方、貯蓄してきたアセットを用いて、具体的な成果を出すために横軸から縦軸への組織体制の変更を行った。

初期はプロダクトマネジメントのノウハウを組織に根付かせるために、組織を横断するPM組織をつくった。いまでは、基本的な考え方・動き方が各チームに根付いたと判断し、より事業目標にコミットできる縦軸の組織へと改編し

さらに、PM、エンジニア、デザイナー以外の職種を巻き込んだり、OKRを導入してフィーチャーチームを解体したりと、成果を出すための組織体制に移行しているのだ。

1人目PMが1年半で組織改編!今後はとことん成果を追求していく

石坂氏がnoteの1人目PMになってから1年半が経った成果として以下のことが達成された。

  • ・PMは1人から7人にまで増えた
  • ・CEO/CXOを中心に行ってきた施策の意思決定はチームに移譲され、チーム単位でPRDを使った仮説立案から検証まで行うことが定常化
  • ・プロダクトグロースを目的としたチームが全部プロダクトチームに移行

プロダクトチーム体制を組織に根付かせ、1人目PMとして期待以上の成果を出した石坂氏だが、「エンジニアリングもプロダクトマネジメントも、やりたいことを実現するための手段」だと振り返る。

言い換えれば、「1人目PMを置くこと」が目的だったのではなく、「エンジニアチームのリーダーとして、プロダクト開発のボトルネックになっている意思決定の課題を解決したいと考えた結果、1人目PMが誕生した」という経緯だったからこそ、PM体制の整備をスピーディに進めてこられたのだ。

石坂氏は、noteのような事業・組織規模が大きくなりつつある企業における1人目PMの動き方は「人による」としながらも、レバレッジの効く組織へのアプローチを重視して取り組んだことが成果を挙げられた理由の一つだと話した。

組織改編を成功させた今、「あとは成果を出すだけ」と意気込みを語る石坂氏。イベントの最後には「成果を出すために、一緒に頑張ってくれるPMやエンジニアを募集しています」とフロアに呼びかけ、セッションを締めた。

Q&A:エンジニアをやりながら、PMするのは現実的なのか

セッション後の質疑応答タイムでの石坂氏の発表に質問が寄せられた。

Q:エンジニアをやりながら、PMするのは現実的ですか?どちらかに集中したほうが良いですか?

A:「初期段階で、他にできる人がいないから兼任する」という状況ではないのなら、あまり現実的ではないと思います。PMは事業価値やユーザー価値を重視してプロダクトに向き合いますが、エンジニアは「システムの構造が美しいか(効率的か、保守・運用がしやすいか)」を重視して追求する傾向があります。これほど異なる思考を共存させて、バランスをとって判断するのは難しいと思います。

文:成澤綾子

関連記事

人気記事

  • コピーしました

RSS
RSS