巷で噂の「ちいとぽ」こと、 Team Topology を読みました。
書籍自体はソフトウェア開発周辺に関する組織設計の話がメインですが、私はもともとウェブエンジニアの出身でいながら、前職が人事で、現職は開発組織の従業員体験（ EX ）向上の施策担当です。関心どころとしては、開発チーム構成の外側も含みます。
この本を通して得た知識をもとに、改めて開発人材における「採用活動」のチーム体制について整理をしたくなりました。そこで、 Recruiting Team Topology for dev と称して内容を考えてみることにしました。
前提
まず、前提として Team Topology で紹介されていた概念のうち、この記事に関わるものを紹介します。
- 4つの基本的なチームトポロジー
- 3つのインタラクションモード
- コラボレーションモード - 他のチームと密接に協力する
- ファシリテーションモード - 障害除去のため、他のチームを支援する・支援される
- X-as-a-Service モード - サービスを提供する・提供される。境界を明確化することで連携負荷を最小化する
Recruiting Team Topology for dev
人事任せパターン
基本的に採用活動を人事の採用担当に任せるパターン。現場は求人要件として必要となる最小限の情報のみ提供する。 ここでは、人事の採用担当がストリームアラインドチームに相当します。
さて、ここで開発者採用の実務について考えてみましょう。採用実務には以下のようなものがあります。
- 候補者さんにささるアトラクト
- 自社にとって必要な候補者さんの見極め
- 現場が求める基準に応じたチームマッチや、スキル面での選考
そして、開発者の採用において候補者さんが転職者として企業に求めている期待や現場が考える候補者さんへの期待を知るにはシステム開発のバックグラウンドが欠かせません。結果として、入社後も活躍してくれる魅力的な人材を人事のみで採用するのは困難と考えられます。
現場単独自走パターン
基本的に採用活動を開発現場が自走して担当しているパターン。人事の採用担当は基本ノータッチ。
ここでは、開発現場がストリームアラインドチームに相当します。
開発者目線で、アトラクトや候補者さんの判別は「人事任せパターン」より、うまく進行しやすいはずです。
一方で、開発現場は開発の業務を持っています。また、採用のエキスパートではありません。そのため、採用に必要となる前提知識の獲得や、採用活動についてまわる様々な作業によって、現場の開発業務との両立が難しくなっていきます。結果として、スカウトの実施や採用課題の解決に向けた議論に使う時間が増えず、気づくと採用の重先順位が下がって採用が完全に動かなくなる、ということすらあるのではないでしょうか。
組織によっては、 CTO や VPoE がこの部分の負荷を多めに受け持つことでなんとか回すケースもあるかと思いますが、その場合これらの人の負荷が大きくなりすぎて、開発組織づくりなどその他の重要な業務に使う時間とのバランス調整が必要になってきます。
全員採用パターン
昨今「スクラム採用」の名で耳にする全員採用のパターンです。全員採用とはいえ、その責務分担のパターンまで細かに語られることは少ないです。
そこで Team Topology の知識を元に3つのチームでの構成を考えてみます。なお、これは思考実験として考えているだけで、実際にこの運用をしたことがあるわけではありません。
- 開発採用ストリームアラインドチーム
- 開発採用イネーブリングチーム
- 採用プラットフォームチーム
開発採用ストリームアラインドチーム
- 採用責任を持つ EM を中心に採用関与するチームメンバーを含めたチーム
- 責務
- 対象求人の採用に責任を持つ
- 選考に責任を持つ
- カルチャーマッチ
- スキルマッチ
- アトラクトの責任を持つ
- 採用プロセスの最適化に責任を持つ
- 選考に責任を持つ
- 対象求人の採用に責任を持つ
- 担当
- 開発現場
開発採用イネーブリングチーム
- 採用に関わる知識、スキル提供を行うチーム
- 責務
- 採用に関わる知識をストリームアラインドチームに提供する
- 採用基礎知識
- 選考手法
- バイアス
- 採用に関わるスキルをストリームアラインドチームに提供する
- 面談、面接トレーニング
- 採用に関わる知識をストリームアラインドチームに提供する
- 支援担当
- 開発内の組織・人事担当が持つケース
- 人事が持つケース
採用プラットフォームチーム
- すべての採用枠で必要になる共通業務をサービスとして提供する
- 責務
- 全社共通選考の提供
- 適性検査
- リファレンスチェック
- 全社の採用広報
- バーレイザー
- 採用アシスタント機能の提供
- 日程調整
- 面談、面接アンケートの構築・運用
- 労働条件通知書の作成
- 全社共通選考の提供
- 支援担当
- 開発内の組織・人事担当が持つケース
- 人事が持つケース
チームトポロジーとインタラクションモード
候補者さんが転職に求める価値を把握し、自分たちが受け入れる候補者さんのカルチャーマッチやスキルマッチを一番把握しやすいのは実際にその人物を受け入れるチームです。そのため、中心となる開発採用ストリームアラインドチームは開発現場が好ましいでしょう。
しかし、開発現場には開発業務があるため、採用に関するドメイン知識・スキルの獲得に大きな工数をかけるのが難しいです。そこで、開発採用イネーブリングチームが採用に関する知識・スキル面の習得を支援します。また、採用業務に関わる負荷軽減として採用プラットフォームチームが日程調整、適性検査など、現場ドメインの知識は必要なく、それでいてほぼすべての採用枠に対して共通で必要となるものを X-as-a-Service として提供します。
候補者さんからのフィードバックを元にした採用プロセスの改善は、候補者さんと近い属性でフィードバック内容を理解しやすい現場の開発採用ストリームアラインドチームに集約するのが好ましいでしょう。開発採用イネーブリングチームが担当する内容は、開発という業務ドメインの影響を受けると考えています。一般的な採用と開発者採用で求められる前提や候補者理解の内容は異なりますし、面談・面接に求められる前提や、実技選考などについても開発文脈への理解度が必要になります。そのため、個人的に開発採用イネーブリングチームを置くのであれば全社人事よりも開発組織担当(VPoEや開発部付きの人事)が好ましいと考えています。
逆に、採用プラットフォームチームが担当する内容は開発の業務ドメインの影響が小さいです。
次にコラボレーションの方法についてですが、前提として採用活動は個別の採用枠1つ1つに責任者がいるのに対し、それに相対する採用担当の窓口は1つということも少なくないでしょう。となると、採用担当者は求める前提が異なる様々な求人枠への対応を一人で担う必要がでてきてしまいます。コラボレーションモードで応対しているといくら時間があっても足りなくなってしまいます。その意味で、それぞれの責務境界を明確にし、全体としてコラボレーションのコストを下げても問題ないチーム構成にするのが好ましいのではないでしょうか。
その意味で、開発の前提知識が必要な開発採用ストリームアラインドチーム、開発採用イネーブリングチームは開発側へ、前提知識が不要な全社共通の採用業務は採用プラットフォームチーム側がよいのではと考えたわけです。
これらの構成を取りまとめる間、責務整理・プロセス整理・認識統一をはかる初期のみコラボレーションモードでやりとりし、境界を明確にしたら X-as-a-Service モードにシフトするのが理想的に思います。
以下は、開発採用ストリームアラインドチームと採用プラットフォームチームによる採用業務のイメージです。
まとめ
開発採用を推進する開発採用ストリームアラインドチーム。
開発採用の知識、スキル面での習熟を支援する開発採用イネーブリングチーム。
開発に限らない採用全般をサービス提供する採用プラットフォームチーム。
この記事の例はあくまで1例に過ぎません。各社の事業形態や、企業としてのフェーズなど異なる前提がありますから、様々なバリエーションがあるでしょう。 各社におけるこれらの担当割り振りなど気になるところです。
