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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© Chatwork Chatworkは日本最大級のビジネスチャットサービス 3月リリース 30万社突破！ 20万社突破！導入社数34.3万社を突破！ (2021年12月末日時点) 4 ※ Nielsen NetView 及びNielsen Mobile NetView　2020年6月度調べ月次利用者（MAU:Monthly Active User)調査 ※ 調査対象44サービスはChatwork株式会社にて選定 10万社突破！

Slide 5

Slide 5 text

© 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 マガジン

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© Chatwork エンジニアリングマネージャー(EM)の希少性 ● なり手が少ない ○ 職務にテクニカルマネジメントが含まれている ■ 一定レベル以上の能力が求められる ■ いわゆるテックリードにマネジメント全般をやってもらう必要がある ■ コード書く時間が確実に減る ■ やりたい人が少ない ● 採用が難しい ○ エンジニア業界全体においてもレアリティが高い ■ 転職市場での母数が少なく、各社争奪戦が繰り広げられている ■ 職種ピンポイントで探す場合、更にレアリティがあがる ● 例) Scalaテックリードレベル x マネジメント経験 14

Slide 15

Slide 15 text

© Chatwork エンジニアリングマネージャー(EM)の希少性ゆえの問題 ● 組織のスケールアウトが出来ない ○ マネージャーがいない = 部署を増やすことができない ■ それでも、どんどんと人数はスケールする ○ 常にスケールアップ = 既存MGRの能力向上しか選択肢がない ● 単一障害点(SPOF)になりやすい ○ 権限や情報がマネージャーに集中している (シングルポイント) ■ サブを配置する場合も、常日頃からの冗長化は出来ない事が多い ○ 転職などで離職する場合に代わりを用意するのが難しい ■ 育休・産休・ケガや病気による入院の場合も同様 ○ 障害(離任)発生時、簡単に組織が機能不全に陥る 15

Slide 16

Slide 16 text

© Chatwork エンジニアリングマネージャー(EM)の組織課題への打ち手 ➢ エンジニアリングマネージャーの希少性は高い前提で組織設計する ✓ 組織のスケールを超えるスピードでの育成、採用を前提としない ✓ 少ないEM人数で組織の設計を行う方法を検討する ➢ エンジニアリングマネージャーを冗長化する前提で組織設計する ✓ マネージャーの役割を見直し、権限と情報を集中しないようにする ✓ 1組織単位に対して、複数名のマネージャーで冗長化する 16

Slide 17

Slide 17 text

© Chatwork プロジェクト型開発 1. Chatworkでは、1つの機能開発に対して都度プロジェクトを編成する ○ プロジェクトマネージャー (≒EM) を都度決定している ○ 各職種(部署)から要件に応じて都度メンバーをアサインしている ○ 機能リリースのタイミングでプロジェクトが解散される 2. Chatworkでは、プロジェクトの成果物を各部署にて運用保守している ○ プロジェクトで作成されたサービスを部署に持ち帰る ○ 持ち帰る前提のため、プロジェクト中から品質保証を各部署で行っている ■ 設計レビュー、コードレビュー、運用レビュー ■ プロジェクトに関する情報を部署内で逐次共有しながら進めている 17

Slide 18

Slide 18 text

© Chatwork プロジェクト型開発の問題 ● プロジェクト体制づくりのコストが高い ○ 編成における準備期間が長く、調整役のPjM(≒EM)の負荷が高い ○ チームビルド(コミュニケーション)のコストが高い ● 継続的な機能改善が行いにくい ○ 機能リリース後に解散しているため、機能改善が出来ない ○ プロジェクトを再招集した場合に、同じメンバーがアサインできない ■ 都度、1から説明し直す必要がある ● 各部署の負担が月日とともに増大する ○ 持ち帰るたびに各部署内の運用保守タスクが増えている ○ 各部署が全プロジェクトの品質保証を行う必要がある ○ プロジェクトアサインメンバーがプロジェクトにフルコミット出来ない 18

Slide 19

Slide 19 text

© Chatwork プロジェクト型開発の組織課題への打ち手 ➢ プロジェクトを用いずに開発する前提で組織設計する ✓ 1機能開発において必要な職種を内包するチームで編成する ✓ プロジェクトマネージャーを極力必要としない設計とする ➢ 特定の機能に対する開発運用チームを固定化する前提で組織設計する ✓ 機能コンテキスト単位でチームを編成、固定化する ✓ 機能の追加や拡張が発生した場合に、チームの追加や再編成を行い、1チームの負荷を均一に出来る設計とする 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© Chatwork 開発チームからマネジメントを分離する ✓ 開発チームにテクニカルマネジメントを委譲する ○ チームの外にアーキテクトを設置し、技術支援する ✓ プロダクトマネージャーを各開発チームにアサインする ○ 中間に位置するプロジェクトマネージャーを置かない ✓ タスクマネジメントを行わず、自己管理化されたチームを目指す ○ チームに閉じて立案 / 開発 / 運用を自己解決できるようにする 22

Slide 23

Slide 23 text

© Chatwork ピープルマネージャーと開発チームの関わり ✓ ピープルマネージャーと開発チームを多対多の関係にする ○ 1ピープルマネージャーは、複数のチームを担当する ■ ピープルマネージャーのリソース効率を最大化する ○ 複数のピープルマネージャーで、1チームを担当する ■ ピープルマネージャーを冗長化する ✓ ピープルマネージャーは以下の業務を行う ○ 1on1、目標設定、考課査定 ○ 採用、アサインメント ○ 各種ワークフロー対応 (勤怠、経費承認) ○ チームで対応できない障害の除去 (スクラムマスターのサポート) 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© Chatwork なんでこんな事が起きるの？ ✓ ミッションが異なる ○ 人事が採用をメインとするのに対し、組織開発は改善アクション全般 ○ 組織改善アクションにおいては、採用は一つの策でしかない ✓ 情報や認識の共有にラグがある ○ 採用優先順位やペルソナは組織課題によって日々少しづつ変化する ○ 組織課題は継続的に事情を知っておかないと理解が難しい ○ 定例会議などピンポイントで会話していては情報が足りない 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© Chatwork DevHR 活動を通じてのGoodPoint ✓ エンジニアなど専門職の知見と、人事の知見を組み合わせて組織改善に取り組めた ✓ 開発部署横断の全体最適な採用がチームで行えるようになった ✓ 組織状態の変化を毎日共有し、全員が常に最新の状態に保てるようになった ✓ 今、何で忙しいのかわかるようになった ✓ 職域を超えて、タスクのヘルプ・巻取りが容易になった ✓ スクラムイベントを通して、チーム活動としての改善が行えるようになった 38