全社目標から考えるプロダクト開発体制
はじめに
SkillnoteVPoEの安藤です。
今回はプロダクト開発組織について、全社目標（KPI）を背景に、どのような目的を持ち、どのような効果を狙って、体制作りを行っているかを記載したいと思います。
プロダクト開発組織の変遷
Skillnoteのいま（2022年）のプロダクト開発について（ https://note.com/daisuke_ando/n/n8ea737164414）でも記載したように、2019年時点では私1名体制（笑）だったプロダクト開発部門は2020年に4名、2021年に7名、2022年に14名へと少しずつ増員してきました。
これに伴い、2022年下期から2チーム体制を取り、もともと単一チームだった頃の課題であるコミュニケーションパスの複雑化等に対応する形で変化してきました。主にボトムアップのアプローチでの変化になります。
2023年下期からの体制
2023年下期からは更なる変更を加え、以下の図に示す通り、4チーム＋「VPoE室」という体制とすることとしました。
2022年からプロダクト開発部門全体の人数は15名と、2022年からほぼ変わっていないにも関わらず、4チームに分けたことにはいくつか背景、狙っている効果があります。
小さなチームに分割し、権限委譲することでマネジメントの負荷を軽減しつつチームの機動力を上げる
「プロダクトデザイン」「インフラ・品質成長」チームにより開発部門を横断した重点施策を推進する
「VPoE室」により全社重点施策に対し直接関与し、これを推進する
2024年移行の体制増強の柱を作る
小さなチームに分割し、権限委譲することでマネジメントの負荷を軽減しつつチームの機動力を上げる
私含め、EM（エンジニアリングマネージャー）メンバーは全員がEMとしての経験を豊富に持つわけではありません。そのため、2022年までの「1人が6名を見る」という体制のまま、プレイングを残した状態で今後もマネジメントするのは難しいと判断した、という背景があります。
また、メンバーの目標設定・評価・1on1・アサインなど、多くの意思決定権を私一人が持ち続けていたことにより、レビュー（プルリクエストのマージ）が遅くなったり、部門施策の打ち手が遅れるなど、開発メンバー15人全員がスピード感を持って全力で前進していくことのボトルネックになりつつありました。
これらの課題解決のため、2チーム制を4チーム制に変更し、各EMに権限委譲することでマネジメントの負荷を軽減しつつチームの機動力を上げることが狙いの1点目です。
「プロダクトデザイン」「インフラ・品質成長」チームにより開発部門を横断した重点施策を推進する
2022年から、部門施策としてギルド制度（プロジェクト制度）を導入し、ボトムアップでの重点施策の実行を推進してきました。
※どのようなルールでどのような施策を打ってきたかという点については回を改めてご紹介できればと考えています。
大小含め最大で20近い数のギルドが立ち上がっては終わって、を繰り返しましたが、そのうちチームとして定常化した方が良いものをまとめて組成しました。
例えばデザインシステムの構築、インシデント対応の強化、QAテストの最適化、といった個別課題を継続的に実施していくことを狙うのが2点目です。
「VPoE室」により全社重点施策に対し直接関与し、これを推進する
3点目はボトムアップ視点ではなくトップダウン視点での狙いです。
全社横断の重点施策に対し、プロダクト開発部門が直接関与できる部分があります。
そこに早い段階から開発メンバーをアサインし、一緒に企画検討していくことで施策の実行スピードを上げる、解像度を上げてプロダクトの品質にも寄与していくという、技術でビジネス価値を創出していくことを狙っています。
2024年移行の体制増強の柱を作る
4点目は総合的な観点になります。
この体制を通じて、2024年以降、30名、50名とエンジニアが増えても拡張可能な、人を増やせる組織体制の基盤として機能させていきたいと考えています。
各EMが成長し、それぞれが持てるメンバーを増やし、私自身はEMの成長にコミットしていく、その経験を次のEMやメンバーを育成するノウハウとして落とし込んでいき、より組織としてのケイパビリティを上げていく、という狙いです。
全社目標に対する関係性
今回の体制変更は足下の課題、ボトムアップでの課題解決も当然含みつつ、トップダウンでの目標達成についても意識した内容になっています。
具体的には、全社重点施策への関与を通してARR増に貢献すること、プロダクト開発部門横断施策を通してプロダクト品質を向上し、それによってチャーン・ダウンセル目標の達成に貢献すること、といった全社目標達成を強く意識して組織編成を検討しました。
実際の体制変更は8月下旬からの予定で、現在は変更により生じてくることが予想される課題点についてEM間で検討・対応を討議している段階です。マトリクス型の組織体制になるため、情報をどのような方法で流通させるのが良いか、チーム同士が混乱しないような日々の業務の進め方など、細かな点を詰めています。
まとめ
現時点ではプロダクト開発部門のKPIが全社KPIにどう関連しているか、見える化できていないのですが（そもそもチームのKPIそのものが見える化できていない・・）、少しでも目的意識を持ちやすい状態を作ることで、メンバー自身の目的が直線で全社KPIに寄与している、どうがんばれば会社が成長するか実感できるような世界を作りたいと考えています。
そのためにも開発部門の生産性の見える化をより進める必要がありますし、スキルマップを活用したエンジニアの評価制度を運用し部門全体の底上げを図るなど、私自身の役割も各チームの成長に応じてどんどん変えていく必要があると考えています。
今後の開発組織についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、是非気軽にお話にきてください！
この記事が気に入ったらサポートをしてみませんか？