Upgrade to Pro — share decks privately, control downloads, hide ads and more …

開発組織拡大に耐えうる組織戦略と開発人事チーム

 開発組織拡大に耐えうる組織戦略と開発人事チーム

4年間で開発メンバーを30名から100名へ エンジニア採用戦略と事業をスケールさせる組織設計
https://peatix.com/event/3112465/view

のイベントで発表したスライドです。
Chatwork開発組織における直近の組織戦略と開発人事(DevHR)での取り組みについてまとめました。

Noriaki Kadota

February 14, 2022
Tweet

More Decks by Noriaki Kadota

Other Decks in Technology

Transcript

  1. © Chatwork 自己紹介 2 • 門田 矩明 (カドタ ノリアキ) •

    前職 ◦ エンジニア ➢ エンジニアリングマネージャー ➢ SaaS組織責任者 兼 採用人事 • Chatwork株式会社 プロダクト本部 ◦ 2020年夏 入社 ◦ DevHR(開発人事)チーム ◦ 2021年10月〜 副本部長兼任
  2. © Chatwork Chatworkは日本最大級のビジネスチャットサービス 3月 リリース 30万社 突破! 20万社 突破! 導入社数34.3万社を突破!

    (2021年12月末日時点) 4 ※ Nielsen NetView 及びNielsen Mobile NetView 2020年6月度調べ月次利用者(MAU:Monthly Active User)調査 ※ 調査対象44サービスはChatwork株式会社にて選定 10万社 突破!
  3. © Chatwork 5 メディア Chatworkの働く人や組織について、Chatworkのことを 幅広く知ることができるメディアです。 Chatworkのエンジニアとデザイナーたちが集う、クリエ イターによるブログです。 https://chado.chatwork.com/ https://creators-note.chatwork.com/

    Chatworkメンバーの仕事内容紹介、インターンシップや 研修制度などの取り組みの裏側をまとめています。 https://www.wantedly.com/companies/chatwork/ プロダクトデザイン&BX組織でfun & creativeに働く様子 もお伝えしていくブログです。 https://note.com/chatworkdesign/ Chatwork Design マガジン
  4. © Chatwork 開発組織 2016-2019 10 • サービス利用規模 拡大 • 30-40名ぐらい

    • 開発本部機能を追加 • SREを追加 ◦ インフラ安定化 • 技術領域で組織を集約
  5. © Chatwork 開発組織 2020 (門田が入社した頃) • サービス利用規模 超 拡大 •

    60名 • 詳細職種での組織細分化 • 職種部署毎にMGRを配置 • プロダクトマネージャー組織規模 が拡大、機能開発の方向性も多角 化 11
  6. © Chatwork 参考: エンジニアリングマネージャー(EM)の一般的な職務 13 ピープル マネジメント プロジェクト マネジメント プロダクト

    マネジメント テクニカル マネジメント ※Chatworkでは、 プロダクトマネージャーが専任で存在するため EMはプロダクトマネジメントをしていません
  7. © Chatwork エンジニアリングマネージャー(EM)の希少性 • なり手が少ない ◦ 職務にテクニカルマネジメントが含まれている ▪ 一定レベル以上の能力が求められる ▪

    いわゆるテックリードにマネジメント全般をやってもらう必要がある ▪ コード書く時間が確実に減る ▪ やりたい人が少ない • 採用が難しい ◦ エンジニア業界全体においてもレアリティが高い ▪ 転職市場での母数が少なく、各社争奪戦が繰り広げられている ▪ 職種ピンポイントで探す場合、更にレアリティがあがる • 例) Scalaテックリードレベル x マネジメント経験 14
  8. © Chatwork エンジニアリングマネージャー(EM)の希少性ゆえの問題 • 組織のスケールアウトが出来ない ◦ マネージャーがいない = 部署を増やすことができない ▪

    それでも、どんどんと人数はスケールする ◦ 常にスケールアップ = 既存MGRの能力向上 しか選択肢がない • 単一障害点(SPOF)になりやすい ◦ 権限や情報がマネージャーに集中している (シングルポイント) ▪ サブを配置する場合も、常日頃からの冗長化は出来ない事が多い ◦ 転職などで離職する場合に代わりを用意するのが難しい ▪ 育休・産休・ケガや病気による入院の場合も同様 ◦ 障害(離任)発生時、簡単に組織が機能不全に陥る 15
  9. © Chatwork エンジニアリングマネージャー(EM)の組織課題への打ち手 ➢ エンジニアリングマネージャーの希少性は高い前提で組織設計する ✓ 組織のスケールを超えるスピードでの育成、採用を前提としない ✓ 少ないEM人数で組織の設計を行う方法を検討する ➢

    エンジニアリングマネージャーを冗長化する前提で組織設計する ✓ マネージャーの役割を見直し、権限と情報を集中しないようにする ✓ 1組織単位に対して、複数名のマネージャーで冗長化する 16
  10. © Chatwork プロジェクト型開発 1. Chatworkでは、1つの機能開発に対して都度プロジェクトを編成する ◦ プロジェクトマネージャー (≒EM) を都度決定している ◦

    各職種(部署)から要件に応じて都度メンバーをアサインしている ◦ 機能リリースのタイミングでプロジェクトが解散される 2. Chatworkでは、プロジェクトの成果物 を各部署にて運用保守している ◦ プロジェクトで作成されたサービスを部署に持ち帰る ◦ 持ち帰る前提のため、プロジェクト中から品質保証を各部署で行っている ▪ 設計レビュー、コードレビュー、運用レビュー ▪ プロジェクトに関する情報を部署内で逐次共有しながら進めている 17
  11. © Chatwork プロジェクト型開発の問題 • プロジェクト体制づくりのコストが高い ◦ 編成における準備期間が長く、調整役のPjM(≒EM)の負荷が高い ◦ チームビルド(コミュニケーション)のコストが高い •

    継続的な機能改善が行いにくい ◦ 機能リリース後に解散しているため、機能改善が出来ない ◦ プロジェクトを再招集した場合に、同じメンバーがアサインできない ▪ 都度、1から説明し直す必要がある • 各部署の負担が月日とともに増大する ◦ 持ち帰るたびに各部署内の運用保守タスクが増えている ◦ 各部署が全プロジェクトの品質保証を行う必要がある ◦ プロジェクトアサインメンバーがプロジェクトにフルコミット出来ない 18
  12. © Chatwork プロジェクト型開発の組織課題への打ち手 ➢ プロジェクトを用いずに開発する前提で組織設計する ✓ 1機能開発において必要な職種を内包するチームで編成する ✓ プロジェクトマネージャーを極力必要としない設計とする ➢

    特定の機能に対する開発運用チームを固定化する前提で組織設計する ✓ 機能コンテキスト単位でチームを編成、固定化する ✓ 機能の追加や拡張が発生した場合に、 チームの追加や再編成を行い、1チームの負荷を均一に出来る設計とする 19
  13. © Chatwork エンジニアリングマネージャー(EM)の職務を分解 21 ピープル マネジメント プロジェクト マネジメント プロダクト マネジメント

    テクニカル マネジメント ピープル マネー ジャー プロダクト マネー ジャー プロジェクト マネー ジャー エンジニア チーム アーキテクト ※Chatworkでは、 プロダクトマネージャーが専任で存在するため EMはプロダクトマネジメントをしていません
  14. © Chatwork 開発チームからマネジメントを分離する ✓ 開発チームにテクニカルマネジメントを委譲する ◦ チームの外にアーキテクトを設置し、技術支援する ✓ プロダクトマネージャーを各開発チームにアサインする ◦

    中間に位置するプロジェクトマネージャーを置かない ✓ タスクマネジメントを行わず、自己管理化されたチームを目指す ◦ チームに閉じて立案 / 開発 / 運用を自己解決できるようにする 22
  15. © Chatwork ピープルマネージャーと開発チームの関わり ✓ ピープルマネージャーと開発チームを 多 対 多 の関係にする ◦

    1ピープルマネージャーは、複数のチームを担当する ▪ ピープルマネージャーのリソース効率を最大化する ◦ 複数のピープルマネージャーで、1チームを担当する ▪ ピープルマネージャーを冗長化する ✓ ピープルマネージャーは以下の業務を行う ◦ 1on1、目標設定、考課査定 ◦ 採用、アサインメント ◦ 各種ワークフロー対応 (勤怠、経費承認) ◦ チームで対応できない障害の除去 (スクラムマスターのサポート) 23
  16. © Chatwork 最新の開発組織体制 25 • 現在 90名 (そろそろ22新卒も!) • 職種別部署から、Featureチーム体制への移行中

    • ピープルマネジメント専任(門田)で1年運用中 ピープルマネージャー 約55名 約25名 職種別部署メンバー Featureチームメンバー プロダクトマネージャー 約10名
  17. © Chatwork 現在の課題 • 新しい組織体制への不安解消 ◦ 成功体験をたくさん作って、聞けるようにする ▪ ≒ バイラルマーケティング

    • ピープルマネジメントの冗長化 ◦ 1チームに対して複数マネージャーを当てる場合の 運用上の問題洗い出しと解消 • モノリシックなアーキテクチャの分割 • 技術的な品質保証に関する課題の解消 • などなど 26
  18. © Chatwork よくある話 〜人事 x 開発 採用定例〜 28 今困ってるポジションあります? Aチームにめちゃ強いエンジニアをアサインしたいんですよねー

    人事 開発 人事 了解です!頑張ります! 人事 母集団20人とカジュアル面談3件獲得しました!(血眼) 他チームのエンジニアアサインできそうなので解決しました! 開発 人事 えっ 開発 えっ 〜1週間後〜
  19. © Chatwork なんでこんな事が起きるの? ✓ ミッションが異なる ◦ 人事が採用をメインとするのに対し、組織開発は改善アクション全般 ◦ 組織改善アクションにおいては、採用は一つの策でしかない ✓

    情報や認識の共有にラグがある ◦ 採用優先順位やペルソナは組織課題によって日々少しづつ変化する ◦ 組織課題は継続的に事情を知っておかないと理解が難しい ◦ 定例会議などピンポイントで会話していては情報が足りない 29
  20. © Chatwork DevHR (開発人事) ってなに? 30 組織開発 採用広報 ピープルマネジメント 採用

    DevHR DevHR CTO 広報 DevHR 人事 DevHR MGR 広義で人事的な組織課題アクションに対して一貫したオーナーシップを持つチーム
  21. © Chatwork DevHR (開発人事) の体制 • 人事と組織開発+エンジニアでワンチーム ◦ 組織開発 2名

    ◦ エンジニア 1名 ◦ 人事 2名 • スクラムチームでタスクに取り組む ◦ 朝会での情報共有 ◦ タスク横断での優先度判断 ◦ ペア・モブワークの実施 31
  22. © Chatwork DevHR の最近の活動 • 組織開発 ◦ 中期プロダクト開発組織の組織設計案作成 • 中途採用

    ◦ 新規募集ポジションのペルソナ策定、募集ページの作成 • 新卒採用 ◦ 新卒採用戦略の立案、説明用資料の作成 ◦ インターンシップ企画案出しワーク • 技術広報 ◦ だいくしーのスクラムBar #2 企画運営 • その他 ◦ 雇用契約書作成 32
  23. © Chatwork ダイレクトスカウトにおけるDevHR内アクションの例 35 2. アウトプットを拝見する 3. 文面を考えて送る 1. タレントリストを作る

    4. 返信や日程調整をする DevHR(組織開発) DevHR(人事) 5. カジュアル面談する CTOにもお願いしたり 6. 次のアクションを考える
  24. © Chatwork 2021年テックイベント 36 イベント集客数 BEST3 • Chatwork Dev Day

    → 442人 (新規 366人) • 0 から考える SaaS セキュリティ → 184人 (新規 165人) • だいくしーのスクラム Bar 🍺 #0 → 114人 (新規 69人) conpass累計メンバー数 自社イベント実施回数  21 回 78 人 1,086 人 →
  25. © Chatwork イベント開催におけるDevHR内アクションの例 37 2. イベントを企画する 3. イベントを開催する 1. 現場からネタを集める

    4. イベント結果を分析する DevHR(エンジニア) DevHR(人事) 5. 会社に興味を持っていただい た方とお話する
  26. © Chatwork DevHR 活動を通じてのGoodPoint ✓ エンジニアなど専門職の知見と、人事の知見を組み合わせて組織改善に取り組めた ✓ 開発部署横断の全体最適な採用がチームで行えるようになった ✓ 組織状態の変化を毎日共有し、全員が常に最新の状態に保てるようになった

    ✓ 今、何で忙しいのかわかるようになった ✓ 職域を超えて、タスクのヘルプ・巻取りが容易になった ✓ スクラムイベントを通して、チーム活動としての改善が行えるようになった 38