Scaling Teams 開発チーム 組織と人の成長戦略
著者
監訳者名
出版年
はじめに
「実証済みの解決策」を集めた道具箱が、まさしく本書であり、きっと皆さんのお役に立てると考えている。
タイトルの通り、組織を拡大、特に採用を通して人数を増やすことについての実践的なお話が本書のテーマとのこと。一方で、「はじめに」の段階でも採用によって解決できない問題も当然あり、そういった場合も含めて採用以外の選択肢を検討せよと言っている。
第1章: 採用のスケーリング --チームの拡充
1~3章では「スケーラブルな採用プロセス」についての「鉄則」を紹介する。
効率よく正確に評価するコツ
採用プロセスから極力「バイアス」を排除するコツ
チームに貢献できる有能な人材を確保する機会を最大限に広げるコツ
「現時点でこのチームがやれること」と「将来このチームがやるべきこと」の間の溝を埋めるために採用を行う。
溝には2つある
スキルの溝
チームにこなせる作業量の溝
ベストなチームになるように採用を行う
≠ベストな人材
長期に渡りチームの成功にもっとも貢献できる人材
実際の採否に関わらず、どの応募者にも「この会社で働きたいものだ」を思いつつ面談会場をあとにしてもらうこと
面接に限らず、どの場面でもこうありたい
ダイヤモンドの原石を見つけるためにはもっとリスクを冒すべし
採用において、どこまでリスクをとるのかをはっきりさせるのが大事。「悩んだら不採用」というのが当たり前だと思っていたが、そうではなくてリスクの許容度をはっきりさせるのが大事なんだな。
1.1.7. 直感に頼るべき時を見極めよ
直感は偏見につながる恐れがあるから唯一の採用基準にはできないが、もっと探りを入れて相手を、そして自分の反応を見定めろと命じるシグナルではある。
なるほど。直感自体を信じるのではなく、直感というシグナルを信じて行動する。
創業チームは多様性無視してもかまわないが、それ以外の場面ではチームの多様性の確保は最優先である。
1.2. 採用プロセス
https://gyazo.com/56dc4a2c3869c609630c6429f6988523
入り口は「紹介」「ソーシング」「応募」の3つ
「身元紹介」と「退社手続き」までをここに含めているのが面白い。
「紹介」はコスパが最もいいが、不採用の場合もあるので候補者、紹介者に丁寧なコミュニケーションが必要
また、多様性を確保するのが困難、サブグループを作り一斉にやめるといったリスクがある。
リクルーターには3種類いる
一般リクルーター
成果報酬型
エグゼクティブリクルーター
定額制の場合が多い
時給制のリクルーター
フルタイムの専任リクルーターでも、通常は月に1名か2名の雇用締結
それだけできればすごいレベルではある
最初のリクルーター
他の職種と同様、一人目のリクルーターはその職種の流儀などに大きな影響を与える
リクルーターは、いわば「我が社の顔」である
会社の「雇用者としてのブランド」を決定づけるのである
1.3. 雇用者としてのブランド
「雇用者としてのブランド」を確立できれば、採用過程への大きなテコ入れ効果が期待できる
OSSでの貢献はブランディングにつながるが、
「オープンソースプロジェクトは継続的なメンテナンスとサポートが欠かせない」という点だ。ソースコードを公開した配位が、その後、一切更新なし、あるいはプルリクエストへの対応無しで放置したりすれば、技術的ブランドのイメージダウンを招きかねない
はい…がんばります。
次章は採否の決め方。
第2章: 採用のスケーリング――面接と採否の決定
二章では「面接」「採否の決定」「身元紹介」の3つを扱う。
採用プロセスのスケーリングの立ち遅れを示唆する兆候
候補者から同じ質問を何度もされたなど否定的なフィードバックがある
採否決定の過程が長引く
新人の質が落ちたと苦情がくる
多様性がチームに欠けている
既存のメンバー構成と変わらない
採用責任者が人手不足で荒れる
2.1. 面接
2.1.1. 履歴書のふるい分け
指針を示すが、例外がおおいのであまり当てにならない
具体的な実績を探せ
過去の在職期間をチェックせよ
職場以外での専門的な活動を見よ
幹部を採用する場合は、特に職歴をよくチェックすること
2.1.2. 最初のスクリーニング
双方にとって直接面接をする価値があるか否かを検討すること
直接でもリモートでも面接の情報収集力は抜きん出ている。~ただしバイアスには影響されやすい。
実感としてもそう感じる。採否にバイアスを持ちこまないようにするために、「ふるい分けのステップ」と「実践的な課題に挑戦してもらうステップ」で選考担当者間でお互いの評価を見えないようにする仕組みやツールもある。
このステップの制度と効率を高めることは、採用プロセスのスケーラビリティを高める上で不可欠だ。
「リモート面接のコツや注意点を紹介する」とあるが、リモートに限らない話だと思った。
開口一番、「弊社について、これまでにどんなことを耳にされましたか。何か質問はありませんか」と訪ねてみてほしい。
過去に在籍していた企業の文化や価値観がどのようなものだったか、また、そのどこが性に合わなかったか、訊いてみるとよい。
前の職場をやめた(やめたい)理由は必ず訊いておこう
ジョブホッパーは巧妙に理由をつくってあるだろうし、EQの低い面接官はそれを見抜けないだろう
「チームの文化と価値観の点で適任か」と「該当のポストに最低限要求される職務をこなせるか否か」を見定める必要がある。
リモート面接が完了すれば、リクルーターは候補者に関するやり取りから、性別や人種など、バイアス要因となり得る詳細を削除する操作を行っても構わない。
そこまでしてもよいかのか。なるほど。
2.1.3. 課題
候補者の能力を図るために課題を出すときのアプローチ
自宅で取り組めるように送付し、面接の中で課題についてディスカッションすることで本人が取り組んでいることを確認する
自社に来てやってもらう
OSSなど公開されているものを課題と同等に取り扱う
この段階でバイアスを排除するコツは「課題のステップで担当者が候補者の履歴書を見ずに、もしくは匿名化した履歴書をみて評価を行う」というものだ。
スキルをみるときはスキルだけをみるために、ここまでしてバイアスを排除しようとするのか。
コラム: 課題に対するアドバイス
Etsyの元CTOのアドバイス
制限時間を伝える
問題の意図を伝える
評価基準を明確にする
回答の評価をフィードバックする
2.1.4. 面接内容の検討
Googleによれば4人を超える担当者は1人につき1%しか精度に寄与しない
一方で面接官を減らしすぎると、現場が蚊帳の外に置かれたと感じることもある
多様性の向上を目指すなら、まず面接官のパネルの多様性を極力高めなければならない。
2.2. 採否の決定
言うまでもなく採用は管理者がチームや組織を構築する中で格別に重要な職務だ。
採否の決定方法
採用責任者が採否の決定権を掌握
決定権の所在が明確であるいっぽう、責任者が組織のニーズを把握していなければうまくいかない
幹部が単独で採用を決定
担当VPが決めるが、採用責任者が決定する場合と同様に現在のチームの状況を把握していないとうまく行かないが、このパターンが非常に多いらしい。
面接委員団の採決
複数の面接官で採否を議論できるが、少人数でも組織のニーズを把握できていない人物がまじると面倒になる
採用委員会
面接官と採否を決めるメンバーを完全に分ける方法。Googleが採用している。
面接官が正しくレポートするスキルが必要。レポートのみで採否をきめなければならない。
バーレイザー
Amazonが採用している。
文化からスキルまで卓越した社員がバーレイザー(バーを上げる者)として必ず採用プロセスに1名関わる。
バーレイザーの職務の中で採用の比重が大きくなるので、ルール決めが必要。
2.3. 採用プロセスの選定
採用決定プロセスに複数人が関与するとより良い人材が確保できることを立証するデータはあるが、面接官の相違で採否を決める手法を、採用委員会が採否を決定する手法と比較して優劣を立証したデータは現時点では見当たらない。
これを比較するのは確かに難しそう。
最高幹部は個々の人材の採否決定にいちいち関与するより、むしろ適正な採否決定が確実に下せるプロセスを整備すべきだ」
最近のhsbtの動きはこれをやっているように感じる。 2.3.2. 「多様性向上のための施策」は後々改めて読んでみる
第3章: 採用のスケーリング――雇用契約締結、新入社員研修、退社手続き
オファーで押さえるポイントは3つ。「2,3ヶ月後に期待する職務」というのは考えたことがなかった。
果たしてもらいたい職務
2,3ヶ月後に期待する職務
金銭面(給与以外の面も)
3.1 オファー
オファーを受けてもらうコツ
候補者の重視しているものに合わせる
「直近効果」のバイアスを利用する
金額交渉は短く、理由と敬意も説明する
3.2 アクハイヤー
人材獲得目的の買収のこと。ポイントは通常の採用と変わらないが、その対象が組織全体になっている。点に注意する。
可能ならば、全員と面談をすること。
3.3. 自社採用プロセスの評価
自社のプロせうがどの程度機能しているか、データを使って評価する
初めてコンタクトを取ってからオファーに至るまでの時間と、各ステップの時間
オファーを断るときに上げる理由
ルート毎の成約件数割合
各ステップの通過人数
離職に関するデータも集めること
これに関する(我々の実体験にも即する)経験則は「離職率が年間10%以下であれば概ね健全」
10%以下でも定期的な内容の確認は必要。割合だけみていると優秀な社員ばかりやめていることに気づけない。
3.4 新入社員研修
肝に命じる必要があるのは「会社の規模が拡大すればするほど、成熟度が増せば増すほど、新入社員研修プロセスへの期待や要求も高まる」という点だ。
複数のチームが持ち回りで研修をしたり、複数のチームでOJTを受けるなど、ペパボで実践していることも出てくる
3.4.4 メンタープログラム
メンターの文脈で「バディ」が出てきた。
3.5 退社手続き
「残念な離職」と「残念でない離職」を区別し、それぞれ追跡調査をすること。
「残念でない離職」の場合は、なぜそれが「残念でない」のかを深堀りする。採用プロセスに問題があったのか、入社後に問題があったのか。
第4章: 管理体制の導入
「管理職の新設」は「時間の無駄」だと考えられることも多いが、「人事管理に明示的に照準を定めることこそが全社レベルの成功の鍵となる」
4.1 フォーマルな人事管理の必要性
チームは人の集まり~共通の目標に照準を定めて効率よく作業を進められる結束力の強いチームが自然に育つことなど、めったに無い。
チームリーダーがメンバーとのミーティングという本来の職務が果たせなくなったら、フォーマルな管理体制を導入すべし。
人事管理のポストを設けるのではなく、専門領域のマネジメントポストを用意することでも問題を解決できることがある
テックリード、エンジニアリングマネージャ、プロダクトマネージャ、など。
「もはや専属の管理者が必要だ」と思ったが、根本的な理由は実はメンバーのスキル不足だったというケースが時にある。
スキル不足であることがわからなかったり、その状態を放置してしまっていたと考えると、そういう場合も管理者が不足しているとは言えそうに思う。
4.2 人事管理の導入
自分たちがどういった人事管理の文化 を望んでいるのかを把握しておくことだ。
「人事管理の文化」という言い回しは面白いと感じた。
そして肝心なのは「並外れた技術力」を「管理者としての可能性」と混同してはならない、という点だ。
「可能性」といっているところがいい
管理者を任命する場合には、チームメンバーへの不意打ちにならないようにする必要がある。
管理体制変更は下準備をしっかりし、理由や意図を明確に説明すべき。
Twitterの事例紹介
「プラットフォーム・ステアリング・グループ」というシニアエンジニアを集めたグループを作り、「緊急度は低いが優先度が高い」プロジェクトが何かを議論させ、それを四半期ロードマップに組み入れるという仕組みを作った。
4.3 管理者の育成
なぜかIT業界では技術部門の管理の職務を、ほぼ完全に「現場で仕事を通じて習得するもの」と捉えているのである。
管理者として大成するか否かを推測する際に役立つ経験則的な指針があるから、それを紹介しておこう。一番シンプルなのが「上・横・下」の尺度だ。
上: 部下の側から上司をうまく使っているか
横: うまく協働できているか。将来同僚となる人々とも協働できそうか。
下: 指導能力を備えているか
命じもしないのに部下のひとりがやってきて、管理者にしてくださいと申し出る、そして私自身もそのエンジニアがたしかに管理者向きの有望な候補者だと思う―そんなケースは私の場合は、これまでに2度しかなかった。
2度もあったのはすごいと思った。
新任の管理者を打診する最初のステップは、以下のようなことを説明・紹介すること。
管理者になるとどういったことに面食らい、感動し、怒り、やりがいを感じるか
管理者になるということは「報酬系」を作り変えることである。
チームのコードを読むのなら自由になって構わないが、コード書きは管理の職務をすべてこなしてからでなければやってはいけない。
はい……
負担の軽い管理職研修をする
読書会や、本やブログについて話し合う会を行う。
裁量に任せる部分とそうでない部分を切り分ける
4.4 外部からの管理者の採用
外部で実績をあげている管理者を採用するメリットはある
ただし
チームの面々と面談をし、管理者に期待することなどをすり合わせておく
有力な候補者が2名見つかるまではオファーを出さない
外部からきた管理者の人数が増えすぎないようにリミットを設ける
大量の外部の管理者が短期間で入ると、組織文化が壊れてしまう
4.5 まとめ
「成長中のチームでは管理者が不可欠な役割を果たす」という点について異議を唱える幹部はまずいないだろう
第5章: 大規模組織の人事管理
直属の管理者を育て、スケーラブルな管理チームを構築するための手法を紹介する。
5.1 管理チームの拡大
人事管理の職務の中には、コツを掴むのに何年もかかる込み入ったものもある。
多様性を受け入れる職場づくりのしかた
切り出しづらい問題を部下に伝える話術
チームに必要な新人を募集、採用する
どれも身に覚えがある。
新任の管理者には必ずメンターを
実績を上げているが自身を過小評価する「インポスター症候群」になりやすい
「管理についての学習は新任管理者の重要な職務の一つ」
このためにも「管理者のレベルアップ支援の責任者」を任命するのはよい
100人から1000人という規模のスタートアップで生じがちな構図が「我々 vs 彼ら」だ
どこでもおきるんだな。
管理者の勤務成績を把握するのはむずかしい。以下の点を意識すること。
会社の期待レベルを明示する
継続的にフィードバックする
伝聞頼みで評価しない
達成度と好感度は別
管理者の解雇はメンバーを引き連れてやめないという確信をもてるまで行わない。
5.2 急成長期のチームの士気
業績が好調な場合は問題が表面化しないが、プロアクティブに動かなければならない。
この製品は自分がこの手で生み出した、この製品に対する自分の影響力は非常に大きいといった感覚が、途方も無いエネルギーを生むのである。
リファクタリングやテスト、デバッグは「かっこいい」とは口が裂けても言えないという一文があるが、そういう価値観もあるのだなぁ。
失策には懲罰よりも学びで対応
功績には
全社会議や全社員向けメールで間を置かずにその功績を称える。
issuuという会社のルール
「エンジニアは時折チームを替える必要がある。そうすればテックスタックの全貌を十分に理解し、これまでよく知らずに来た同僚とも共に働き、社内の新たな課題を見つけることができる」
これを実現するために、希望者と受け入れ先のチーム、両方にルールを設けていた。
5.2.3 ワークライフバランスの実現
あまり口に出したくない言葉だが、いいことが書いてあった
週末は「充電」する
夕方のミーティングや夕食は避ける
納期は恣意的なものではなく現実的な視点で決める
管理者が率先してやる必要がある
スタートアップは短距離走よりはマラソンに近い。
勝負のポイントで仕掛けるためには、それまで力を温存しなければならないのだ
5.2.4 開放的な職場作り
オフィスの設備は多様性を確保できるように。
自身がアルコール依存症の人や、近しい人がそういう場合に、ビールが常備されている職場は魅力的に見えるだろうか。
正式なプロセスが確立されていないと、社員は仕事の進め方を理解しようとする際に「不文律」を頼りにすることになる。
柔軟なプロセスと、プロセスが無いことは違うのだ。
心理的安全性の話。
「リーダーであるあなたの行動は(言葉以上にとは言わないが)言葉と同程度にモノを言う」
この章では、リーダーが率先してやるということを何度も述べている。
EtsyとTwitterで交流プログラムをやってたことがある。
5.2.6 キャリア形成
5.2.6.4 スロッティング
初めてキャリアラダーを設定するときに、社員をキャリアラダーに割り当てる(スロットに入れる)こと。
中途採用の場合も同じ言葉を使う。
キャリアラダーを設計するに当たり、隣接する職位で給与に重なりをもたせる場合がある。
ストックオプションがある場合に、その割合を個別に対応できるようできるメリットがある。
キャリアパスは会社の価値観を反映するものでなければならない。
昇進・昇格プロセスの策定においては、以下のようなことができるようにすること。
多様な評価者の見解を参考に
多様な視点での評価を
最終決定は潔く受け入れ、理由や背景を説明する
特に理由は必ず述べること。不合格なのだとしたら、次に何をすればいいかをフィードバックする。
第6章: 組織のスケーリング――組織設計の原則
増員を図ったら、その分、チームの生産性が期待どおりに増える、そんな組織構造を段階的に整備してくコツやノウハウを紹介する。
まじで!
この章ではバリューストリームマップを出して、価値の流れがスムーズになるように組織を設計せよということが言われている。あらためて作りたいなぁ。 組織設計の5つの原則
デリバリーチームの構築
自律性の確保
目的の明確化と成功度の測定
継続的デリバリー
継続的学習を重視する文化の醸成
どれもとてもよいが、デリバリーチームというのが今の自分の課題感とはよくあっている。
継続的学習を除くと、その他の3つはすべてデリバリーチームがあることが前提になっていそう。
継続的学習も、デリバリチームが構築できていないと、正しく学習ができないというのはそう。
一方で、大規模プロジェクトはデリバリーチームを横断して組織される場合もある。その場合は、その業務量に合わせて専用のチームを構築するかを決めること。
一ヶ月を超えるプロジェクトは必ず専用チームを立ち上げるなどといった目安を決めてしまうのもよい。
自律性を確保するとは
一定の制約の範囲内で、どの作業をすすめるかを決める自由をチームが有すること
ここでの制約は
ビジネス上の優先度
組織全体の目標
チームの権限
ネットフリックスのカルチャーガイドを参考に
結局は
チームに100%自律性を与えてしまうのではなく、「チームの自律性」と「上層部による管理」の間で程よいバランスが取れる箇所を探るべし
一方で、以下の2つは守るべし
チームは常に少なくとも勤務時間の半分を自由に使えるようでなければならない。
半分ってほんと!?
より広範な戦略的取り組みにおいて、あるチームがボトルネックになっているようなら、そのチームは作業時間のすべてを使ってでもボトルネックの解消に務めなければならない。
明確かつ計測可能な目標を与え、それを実現する方法はチームに委ねる。
ある製品なり機能なりを誰よりもよくわかっているのは、毎日その製品に関わる作業を進めている現場のチームだ。
管理者の介入が許されるのは、チームが危険な道へと足を踏み入れつつあると強く感じたときだけだ。
よくいわれることではあるが、難しい。
「踏み入れつつあること」を「強く感じた」というのがポイントなのかなぁ。
6.2.4 目的の明確化と成功度の測定
ほぼOKRの話だ!
6.3 他社の参考事例
Yammer
デリバリチームの話。
チームを細分化したところで、コードを仕上げて本番環境に移すのを何らかの形で制限されるようなら、そんなチームは使い物にならない
Spotifyの話はいつものやつ。
Airbnbの事例はふつうのことを言ってるだけではと思った。
第6章: 組織のスケーリング――デリバリーチーム
デリバリーチームを構成するとき、4つの観点が考えられる
プラットフォーム
iOS、Android、Webなど
直感的で実現しやすい(かもしれない)
一方で、スケールアップには課題がある
機能
各プラットフォームの人数、スキルが十分になったら、そのエンジニアを機能毎に分けていくと機能毎のデリバリーチームになる。
各プラットフォームで機能の提供を同時に行う事ができるのがメリット。
人員不足になりやすいのがデメリット。また、チーム感のコミュニケーションや調整をうまくする必要がある。機能ごとにUIが変わったりすることがないようにしないといけない。
事業
全社レベルのKPIでチームを作る方法。
KPIに直結しない開発を担当するチームも必要になる。これは「機能」で分割した場合も同様。
メリットは全社レベルの目標へのチームの貢献がわかりやすい
デメリットは「コアチーム(KPIに直結しない開発をするチーム)」のバリューが見えにくい
スケールアップも難しい。
このアプローチは、KPIを分解してチームを作るのではなく、全社レベルのKPIを複数たて、それにチームを割り当てるようなイメージになっている。ゆえに、スケールアップするには新しいKPIを作ったり、チームの中で分割したりする必要があるのだろう。
顧客グループ
特定の顧客グループ向けの複数の機能を、他チームに依存せずに開発すること
ECの文脈であれば、「ショップオーナー」「購入者」といった感じだろうか。CtoCなら「売り手」と「買い手」
メリットはどこに価値を届けるかが明確なのと、顧客の成長に合わせてチームの学習が進むこと
デメリットはスケール。
どの会社も単独のアプローチではなく、複数組み合わせている。
「機能」のアプローチをとったが、エンジニアが足りないため一部プラットフォームになっている
「機能」または「プラットフォーム」で編成し、「事業」のチームをいくつか作る