見出し画像

2022年のプロダクト開発組織の変化と今後

メリークリスマス🎅🎄
Offersで 事業・プロダクトの成長に貢献し続けたい tanamako です。Offers PM Advent Calendar 2022、最後の投稿です。

皆さんはどのような一年だったでしょうか。
弊社は2022年プロダクト開発組織で大きな変化がありました。この記事では、プロダクト開発組織に関する変化と今後について紹介します。

2022年のプロダクト開発組織に関する変化


大きく分けて3点変化がありました。

  • VPoE、VPoPの入社

  • コンウェイ→逆コンウェイ

    • モノシリックな体制から、feature制への移行

    • プロダクト開発組織の正社員数が約2倍へと増加

    • 2人目PM、正社員デザイナーが2名、元CTO経験者の入社など大幅にプロダクト開発組織の戦力が増強

  • CTO、CPOの新規事業へのコミット

VPoE、VPoPの入社でのポジティブな変化


経営ボード内での変化

  • 2022年1月にVPoEの入社、8月にVPoPが入社し、経営ボードが5名となり、これまでよりも様々な議論が活性化

  • 創業メンバー3名ではやり切れなかった各セクションの実行が進み、走りながら強固な組織を作るための必要なアクションが出来た

また、各ボード間でのフィードバックが促進され、ボードの安定性が増し、全社とプロダクト開発組織に良い変化をもたらしてくれています。
経営ボードの器が会社の器なので、入社してくれて感謝しかありません。

全社

  • 評価制度、人事制度が強化され、より納得度がある評価を実施できた

  • VPoPの入社で、業務委託の方のみの採用チームから採用組織が立ち上がり、基本的な採用プロセスが徐々に回るようになり始めた

  • 1on1ドキュメントの作成で、コミュニケーションの質が向上した

プロダクト開発組織

  • プロダクト開発組織の採用(PM、デザイナー、エンジニア)をHRチームに徐々に移管

    • 創業からCTO、CPOで採用と開発・プロダクトづくりを兼務してきたが、VPoE・VPoPの入社でチーム化・移譲ができた

  • プロダクト開発組織の文化づくりへの投資が開始された

  • テックブログ、デザイナーブログ、PMブログなど、技術広報をスタート

  • TGIFの実施

  • エンジニア構造化面接の導入

    • エンジニアチームから導入し、デザイナー・PMでも一部実施

  • エンジニア、デザイナー、PMキャリア・評価ラダーのアップデート

2人の入社によって多方面で言語化や型化が進んでいます。

コンウェイ→逆コンウェイへの移行


  • プロダクト開発組織の正社員数が2倍になり、チームから組織に変化

  • モノシリックな体制から、マルチプロダクト立ち上げに伴い、feature制へ移行

  • これまではエンジニア組織の生産性を測るためにd/d/d/やFour Keysなどを活用し、今後は新規プロダクトを活用した新指標の導入を検討

  • エンジニア組織だけの開発生産性だけではなく、PM・デザイナー含む全体で生産性を可視化することを目的とスループット最大化(≒リリース量)を推進する

CTO、CPOの新規事業へのコミット


参照:overflow Development組織戦略資料
  • 事業方針でOffersと基盤にコミットしていたCTOが10月から新規事業に異動

  • これに伴って、エンジニア組織をアップデート、後述する技術戦略の組織図に変更された

  • 2023年1月にベータリリースする予定のサービスにコミットしている

  • 組織戦略のモニタリング、日々の開発プロセスの変化を察知できるようなプロダクトを目指す

  • Offersの立ち上げ時同様に、原体験ドリヴンで自分たちが徹底して使い、スピード感を持ってMUST HAVEなプロダクトへ

Development組織とPMのスタンス


Development組織戦略(エンジニア寄り)

  • VPoEの入社から半期に一度技術戦略を社内で公開

  • 技術戦略の言語化と公開は、PM・デザイナー・エンジニアチームの目線の統一・視座を高めるとともに、全社の技術組織の戦略と戦術の解像度が高めるのに役立っている(年明けか、次回作は公開されるとかされないとか)


PMの基本方針

  • PMは少数精鋭

    • 現状は大きく分けると2プロダクトで、今後もできるだけシンプルな機能に保つため、複数プロダクトを作っていく予定。

    • プロダクト開発組織規模がそこまで大きくないためプロジェクト、プロダクトマネジメント兼務は必須で、分業化を積極的に推進しない方針

  • 事業への責任と役割分担

    • 前提、事業への責任なきプロダクトマネジメントは存在せず、ただ創ることに大きな意味はない。

    • PMの事業への関与の役割は、事業推進は「事業責任者の役割」で、PMはプロダクトでのアウトカムに責任を持つ

    • 事業責任者主導で事業計画策定、PMは事業責任者と共に事業計画からロードマップへ落とし込み、日々の開発バックログ作成・更新、スプリント時のバックログリファインメントが求められる

    • 事業責任者以外とのビジネス職との連携(機能立案〜リリースでのヒアリング、テスト実施)はPMの役割

  • 事業×プロダクトに強いPMへ

    • 上記の事業責任者と共同で事業計画からプロダクトロードマップ・バックログを作成することでより事業<>プロダクトの紐付きが強くなる。

    • toBプロダクトは特に、プロダクトの提供価値=継続率やMRRなどの事業数値にヒットするので重要

    • PMの今後のキャリアを考えたときに、分業体制よりも総合的に経験した上で、自身の強みを発揮できる人になってほしい(私が、その方が弊社のPMの市場価値が上がると考えているため)

PMの方針の一部ですが、こちらはまた別記事で年明けに公開します。
リリース物や振り返りに関してはこちら。

2023年 の プロダクト開発組織


PM

  • リリースしたコア機能のGTMをやり切ること。リリースがゴールではなく、してからがスタート

  • プロダクト開発組織が拡大、PMも分業化フェーズに差し掛かかりつつあるが、必要に応じて判断する

  • 個々人の得意・不得意部分を整理し、配置は流動的に変化させる

  • 短期的にはデータ分析チームを持ち、開発の優先順位決定をリードする

エンジニア

参照:overflow Development組織戦略資料
  • HRデジタル化基盤構築

    • 認証認可、APIレイヤー統合

  • 技術負債の返却

  • Progressive Delivery

  • 細分化したSLO/SLI

  • 持続可能な開発フロー

デザイナー

参照:overflow Development組織戦略資料
  • コミュニケーションデザイン、プロダクトデザインの分離

  • チーム分割され、人員が増加

プロダクトチーム全体


  • 継続的な技術広報の強化

    • 各チームでのブログの継続

  • 筋肉質な組織になるためのイネーブルメント強化

    • チームごとの強化

    • 組織全体の底上げ

  • プロダクトチームのビジネスチームとの定期的なタッチポイント強化

    • プロダクト勉強会の強化

    • 全社スプリントレビューの推進

  • PM、デザイナー、エンジニアが共通して目標にしているProduct KPIの達成

最後に

overflowのプロダクト開発組織は、「若手とシニアがそれぞれの強みを持ち寄って、変化に対応する組織」です。皆がポジティブで、一緒にプロダクトづくりをするメンバーをリスペクトし、努力できるチームです。

会社観点では「スーパーオープン、スーパーフラット、スーパーポジティブ」な点ですね。

副業もフルタイムも関係ない、どのSlackチャンネルにも入れる、なんて性善説で皆ポジティブなんだっていう感じです。

https://note.com/offers_pm/n/n3fba4d43946f#e99f571f-5dbd-4a31-a8de-d3efd659a9b5

この一年で大きな変化が起きたプロダクト開発組織ですが、
2023年も お客さまに愛され、そして「プロダクト開発組織がターゲットのプロダクト=開発している自分達がユーザー」であるからこそ、高い品質のプロダクトにできるように一丸となって頑張っていきます。

Offers、overflowに関わる全ての皆様2022年はありがとうございました。2023年もよろしくお願いいたします。

告知コーナー


副業を始めたい方

🎄Advent Calendar 2022 🎄


いいなと思ったら応援しよう!

この記事が参加している募集