みなさま、お疲れ様です！開発人事の高瀬 (@Guvalif) です。
この記事は、Chatwork Product Day 2023 の開催を応援すべく、連載企画の一環として投稿しています。
今回は、「事業部 (プロダクト本部) にて開発人事を担う部署を新規発足した際の、成功体験と失敗体験」というテーマでお送りします。
この記事の位置づけ
- この人はどんな思いで、どんな仕事をしているんだろう？ 🤔 を明らかにする一種の公開社内報
- Chatwork における "DevHR" の現在地点を解説するもの
- プロダクト本部クレド「失敗が大事」の精神にもとづいて、失敗事例を共有し次に活かすもの
そもそもなぜ開発人事を担う部署が新規に必要となったのか？
遡ること 2022 年の 12 月、開発人事全般を担うバーチャルチーム "DevHR" は多くのメンバーを抱えるに至っていました。
以下は当時の実際のチーム図で、発足当初 (2020 年) に "副本部長 / EM / 採用担当人事 / エンジニア採用広報" の 4 人体制であった頃と比べると、 情報共有や意思決定のスピード感に難があるようになっていました：
また、2023 年から新規に採用担当人事やエンジニア採用広報を受け入れることも見えていたため、 Two Pizza Rule*1 を超えるチーム人数構成となることは避けられない状況にありました。
チーム人数が多くなった時に取りうる対処は "チームを分割する" こと。 幸いなことに、ピープルマネジメントを担うチーム と採用を担うチームが既に実部署として存在していたため、 自然な流れとして "ブランドリフト" および "育成" を担うチームを、実部署として設立することが検討されました。
"DevRel 部" の誕生と DevHR のメタスクラム化
かくして、2023 年の 1 月に「社内外問わずプロダクト開発者との横断的な関係性構築を担う」という目的をもって DevRel 部 が設立され、そのタイミングで自分自身の肩書きも MGR となりました。
部署のコンセプトと持ちうる機能は下図の通りであり、認知獲得から受け入れまでを一気通貫して見れることが強み (となるはず) でした。
ありがたいことに、このコンセプトは採用候補者にもウケが良く、2023 年 1Q において 2 名のチームメンバーを採用することができました。
また、この時点で DevHR の各機能と実部署がそれぞれ対応することとなり、 2023 年 1Q 以降の DevHR は各部署から PO のみを集めるスケーリングスクラム体制へと移行します。
戦略体系と組織構造の対応
体制も新たに、順調な動き出しができると期待に胸を膨らませていたわけですが、 DevRel 部には構造上の欠陥があることがすぐに明らかとなりました。
以下の記事は、COO の福田による "戦略" の考え方に関するものですが、 2023 年上期に 社内の全本部および全部署 でも、同様な戦略体系の構築 (カスケーディング) を行なっています。
部署単位で戦略体型を構築することはなかなかマレであるとは思いながら、 中期経営計画の達成に向けた経営陣の本気度を垣間見るものでもあります。
さて、ソフトウェア・エンジニアの方々であれば "コンウェイの法則"*2 を聞いたことがあるかと思いますが、 誤解を恐れず言えば 戦略体系の実現可能性は組織構造の影響を強く受ける という類似があるように思います。
そう考えた時に、DevRel 部の立ち位置はかなり微妙で：
- ピープル＆ブランド本部の "採用ブランディングチーム"
- ピープル＆ブランド本部の "新卒採用部"
- プロダクト本部の "ピープルマネジメント部"
といった、社内の既存部署やチームとの戦略体系の棲み分けも曖昧です。 ソフトウェア開発で言うところの システム境界が曖昧である状態 にも近いですね。
これに関しては CEO の山本からも指摘を受けるところとなり、 DevRel 部が発足して間もなく、あり方を再検討することとなりました。
DevRel 部の適切な再分割
MGR として自分が取りうる選択肢は：
- DevRel 部を残しつつ、戦略体系の棲み分けを精緻化する
- DevRel 部を解体し、既存の部署やチームへと統合する
上記の 2 つだった訳ですが、1 ヶ月ほど悩んだ末に後者の意思決定をしました。 戦略遂行の可能性を最大限上げようと思えばそれが適切でしたし、 かっこ悪くも内心を言えば、経営陣に適切な説明がしきれる見通しが立たなかったというのもあります。
さし当たって、本部長を含む関係各位に「どのように DevRel 部を分割・機能委譲したいか？」を説明し、 数ヶ月のランディング期間を設けて、2023 年 10 月時点での DevHR は以下の姿となりました：
一部に仮想的な兼任者を含むものの、戦略体系と組織構造が一対一に対応づき、 スケーリングスクラム体制としてもより動きやすくなったと感じています。 全てがワンチームな DevHR も懐かしくはありますが、組織の成長とともに DevHR も適切に進化するべきで、 その一端となる出来事にもなったのかなと振り返っています。
まとめ
戦略体系と照らし合わせて組織を考えることは初めての経験であり、 考慮不足な部分で多くの方々に迷惑をかけたかなと思います。 DevHR の皆様にも、この場で改めてお詫びしたい次第です 🙏
ただ、失敗ゆえに正しい選択ができたとも思っているので、悔いはありません。 "なんでもできる" は "何ができるかわからない" ということを改めて肝に銘じ、 今後も良い組織づくりの手助けができたらと思います 💪
最後に、Chatwork における組織開発に興味を持っていただけた方は、ぜひぜひカジュアル面談などお気軽にお声がけいただければ嬉しく思います！
おわり
*1:チーム編成において、ピザ 2 枚を配りきれる 8 ～ 10 名程度だと効率が良いとする考え方
