Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
An Elegant Puzzle: Systems of Engineering Manag...
Search
iwashi
November 16, 2022
Technology
15
18k
An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る / Learn roughly "An Elegant Puzzle: Systems of Engineering Management" in 50 minutes
NTT Communications の社内ランチ勉強会 (TechLunch) で講演した資料です。
iwashi
November 16, 2022
Tweet
Share
More Decks by iwashi
See All by iwashi
エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門 / Engineering management for the rest of us
iwashi86
22
4.9k
エレガントパズル 30分 ダイジェスト版/ Elegant Puzzle 30min Digest
iwashi86
5
430
エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle
iwashi86
18
3.7k
ベロシティを高く保つ仕事のすすめ方 / Maintaining a High Velocity as Productivity Hacks
iwashi86
54
19k
マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
iwashi86
64
31k
30分でわかる「エンジニアのためのドキュメントライティング」- インフラエンジニアBooks / Docs for Developers within 30 minutes
iwashi86
9
2.4k
エンジニアのためのドキュメントライティング / Docs for Developers
iwashi86
34
21k
なぜ変化を起こすのが難しいのか? - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
iwashi86
59
85k
2015年 第4四半期の WebRTC 標準化 アップデート / 2015 update of WebRTC Standards
iwashi86
0
200
Other Decks in Technology
See All in Technology
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
Can We Measure Developer Productivity?
ewolff
1
150
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
300
強いチームと開発生産性
onk
PRO
35
11k
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
The Role of Developer Relations in AI Product Success.
giftojabu1
0
130
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
Terraform Stacks入門 #HashiTalks
msato
0
360
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
SSMRunbook作成の勘所_20241120
koichiotomo
3
160
『Firebase Dynamic Links終了に備える』 FlutterアプリでのAdjust導入とDeeplink最適化
techiro
0
130
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Speed Design
sergeychernyshev
25
620
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Done Done
chrislema
181
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Unsuck your backbone
ammeep
668
57k
Code Review Best Practice
trishagee
64
17k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Typedesign – Prime Four
hannesfritz
40
2.4k
Practical Orchestrator
shlominoach
186
10k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
Transcript
An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る (at NTT
Com TechLunch #158) 2022年11月 NTT コミュニケーションズ 岩瀬 / @iwashi86
1 発表終了時の到達点 • An Elegant Puzzle: Systems of Engineering Management※
の書籍に書いてある内容の一部を理解している ※ 岩瀬が2022年に読んだ中で一番学びがあった本
2 著者 • Will larson氏 (@lethain) • Uber社のシニアエンジニアリングマネージャーや Stripe社のエンジニア組織のHeadを歴任して 現在はCalm社のCTO
• Hacker News にブログポストがよく載っており IT界隈の著名人の1人
3 どんな本? • 実際にEMや、EMを束ねるHeadとして活動してきた 著者の知見がまとまっている書籍 • 実践的なプラクティスや考え方が多く掲載される ◦ 研究による裏付けがメインという類の書籍ではない
4 書籍の全体像 1. 組織 - 組織やチームデザイン 2. ツール - システム思考、ツール、変化の起こし方
3. アプローチ - EMが直面する課題と解決法 4. 文化 - 組織文化への取り組み 5. キャリア - 採用、評価、昇進 6. 付録
5 書籍の全体像 1. 組織 - 組織やチームデザイン 2. ツール - システム思考、ツール、変化の起こし方
3. アプローチ - EMが直面する課題と解決法 4. 文化 - 組織文化への取り組み 5. キャリア - 採用、評価、昇進 6. 付録 → 個人的に印象に残った箇所を順不同でかいつまんで紹介します!
6 本題
7 チームの状態と移行 https://unsplash.com/photos/E9PJO_vL3E8
8 チームの状態(次のページで説明) https://lethain.com/durably-excellent-teams/ より
9 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている
10 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.
立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
11 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.
立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている 3. 返済可能な状態 ◦ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
12 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.
立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている 3. 返済可能な状態 ◦ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている 4. 革新が起こせる状態 ◦ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
13 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.
立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている 3. 返済可能な状態 ◦ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている 4. 革新が起こせる状態 ◦ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている さて今、 ご自身のチームは どの状態にいますか? (心の中で考えよう)
14 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.
立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている 3. 返済可能な状態 ◦ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている 4. 革新が起こせる状態 ◦ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている どうやって 次の状態に移行するか?
15 チームの移行方法 https://lethain.com/durably-excellent-teams/ • [1]遅れている状態 -> [2]立ち泳ぎ状態 ◦ [2]に移行できるまで採用する ← ヘッドカウントで諦めるマネージャも多いが頑張りどころ ◦
ちょっとした成功を祝う、楽観的な考えを吹き込む
16 チームの移行方法 https://lethain.com/durably-excellent-teams/ • [1]遅れている状態 -> [2]立ち泳ぎ状態 ◦ [2]に移行できるまで採用する ◦
ちょっとした成功を祝う、楽観的な考えを吹き込む • [2] 立ち泳ぎ状態 -> [3] 返済可能な状態 ◦ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす ◦ チームメンバーの生産性の見方を、個人からチームへと変えていく
17 チームの移行方法 https://lethain.com/durably-excellent-teams/ • [1]遅れている状態 -> [2]立ち泳ぎ状態 ◦ [2]に移行できるまで採用する ◦
ちょっとした成功を祝う、楽観的な考えを吹き込む • [2] 立ち泳ぎ状態 -> [3] 返済可能な状態 ◦ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす ◦ チームメンバーの生産性の見方を、個人からチームへと変えていく • [3] 返済可能な状態 -> [4] 革新が起こせる状態 ◦ 負債を返済し始めているので、さらに時間を作れるようにする ▪ ステークホルダーは「時間ができてそうだから、新しい価値を!」となるかもしれないが そこを耐えて [3] -> [2] に戻さないようにする
18 チームの移行方法 https://lethain.com/durably-excellent-teams/ • [1]遅れている状態 -> [2]立ち泳ぎ状態 ◦ [2]に移行できるまで採用する ◦
ちょっとした成功を祝う、楽観的な考えを吹き込む • [2] 立ち泳ぎ状態 -> [3] 返済可能な状態 ◦ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす ◦ チームメンバーの生産性の見方を、個人からチームへと変えていく • [3] 返済可能な状態 -> [4] 革新が起こせる状態 ◦ 負債を返済し始めているので、さらに時間を作れるようにする ▪ ステークホルダーは「時間ができてそうだから、新しい価値を!」となるかもしれないが そこを耐えて [3] -> [2] に戻さないようにする • [4] イノベーションを起こせる状態以降 ◦ Slack!(トムデマルコの書籍を読もう!) ◦ ただし、失敗しがちなのは顧客価値に繋がらないフレームワークの移行への着手など
19 移行時の注意点 https://lethain.com/durably-excellent-teams/ • それぞれの状態の移行には「時間がかかる」 ◦ システムによっては、数年以上の負債蓄積がある ◦ 逆に言えば、修正に時間がかかるのと同じで 効果が出れば長い時間維持できる
20 移行時の注意点 https://lethain.com/durably-excellent-teams/ • それぞれの状態の移行には「時間がかかる」 ◦ システムによっては、数年以上の負債蓄積がある ◦ 逆に言えば、修正に時間がかかるのと同じで 効果が出れば長い時間維持できる
• 簡単には効果が出ない ◦ 長く時間がかかっても、自分の計画を信頼して維持すること (だから組織をいじったり、新しい仕事を始めずに続けること)
21 (変化を効果的に導く) ツール https://unsplash.com/photos/sm0Bkoj5bnA
22 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える
◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される
23 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える
◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される • メトリクス ◦ あとで出てくる
24 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える
◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される • メトリクス ◦ あとで出てくる • ビジョン ◦ (原著参照)
25 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える
◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される • メトリクス ◦ あとで出てくる • ビジョン ◦ (原著参照) • プロダクトマネジメント(思考) ◦ (探索・選択・検証をEM視点から書いてある、詳細は原著)
26 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える
◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される • メトリクス ◦ あとで出てくる • ビジョン ◦ (原著参照) • プロダクトマネジメント(思考) ◦ (探索・選択・検証をEM視点から書いてある、詳細は原著) では具体的に どうやって変化を導く?
27 (権威に依存しない) リーダーシップ https://unsplash.com/photos/6U5AEmQIajg
28 厄介な問題 • こんな経験は? ◦ ここに問題がありそうだけど、自分は部長でも課長でもなくて 一人の担当者にすぎない ▪ or 新しく配属された部署だと、まだ信頼貯金がない…
◦ どうやって解決すればいいんだろう? (岩瀬補足:PdM とかまさにこれ。多くは人事権限がない)
29 厄介な問題 • こんな経験は? ◦ ここに問題がありそうだけど、自分は部長でも課長でもなくて 一人の担当者にすぎない ▪ or 新しく配属された部署だと、まだ信頼貯金がない…
◦ どうやって解決すればいいんだろう? (岩瀬補足:PdM とかまさにこれ。多くは人事権限がない) • そんな時に(すべてではないが)上手く行った方法がある ◦ それが Model -> Document -> Share
30 https://lethain.com/model-document-share/
31 Model • 月次などでチームの健康状態やスループットを計測する ◦ 例:タスクサイズを軽量に測定 • 大事なのは変化を加える前のベースライン(基準値)を知ること
32 Model • 月次などでチームの健康状態やスループットを計測する ◦ 例:タスクサイズを軽量に測定 • 大事なのは変化を加える前のベースライン(基準値)を知ること • おおっぴらに宣伝するのではなく、「ちょっとした実験だよ」
といった意味づけではじめて、しばらく続ける ◦ ダメだったらやめればいい • 一定、効果が出てくると感じたら…
33 Document • 次の内容を文書化する ◦ 解決しようとしている問題 ◦ 試行から学んだこと ◦ 他のチームで採用(再現)するための方法の詳細
▪ 可能な限り詳しく、汎化して ▪ 他のチームに新規メンバが入っても理解できるように
34 Share • 短いメールでドキュメントを配布する ◦ この時自分の経験談も入れておく • 「採用してください!」とは言わない ◦ 単に方法を紹介するだけでいい
• 奇妙なことに著者の経験からいえば、 トップダウン・強制型のアプローチよりも採用率が高い
35 参考:Model→Document→Share と トップダウン のどちらを使えば? • Model → Document →
Share ◦ 新しい施策を採用する余裕がない ◦ 新しい施策を広めるためのリソースがない ◦ 分散型で意思決定したいトピックである ◦ チームが自律的に採用できる ◦ 徐々に変更が起こってもいい • それぞれに特徴、向き不向きがある
36 • トップダウン、強制型 ◦ 新しい施策を採用する余裕がある ◦ 新しい施策を広めるためのリソースがある ◦ 中央集権的に決定したいトピックである ◦
組織内で一貫性が必要 ◦ 素早く変更を起こしたい • Model → Document → Share ◦ 新しい施策を採用する余裕がない ◦ 新しい施策を広めるためのリソースがない ◦ 分散型で意思決定したいトピックである ◦ チームが自律的に採用できる ◦ 徐々に変更が起こってもいい • それぞれに特徴、向き不向きがある 参考:Model→Document→Share と トップダウン のどちらを使えば?
37 • トップダウン、強制型 ◦ 新しい施策を採用する余裕がある ◦ 新しい施策を広めるためのリソースがある ◦ 中央集権的に決定したいトピックである ◦
組織内で一貫性が必要 ◦ 素早く変更を起こしたい • Model → Document → Share ◦ 新しい施策を採用する余裕がない ◦ 新しい施策を広めるためのリソースがない ◦ 分散型で意思決定したいトピックである ◦ チームが自律的に採用できる ◦ 徐々に変更が起こってもいい • それぞれに特徴、向き不向きがある • Model → Document → Share 型は 組織の価値観があっているときに効果をより発揮しやすい ◦ ただし、同僚からの尊敬など、自然発生するAuthority(信頼貯金)は必要 参考:Model→Document→Share と トップダウン のどちらを使えば?
38 良いゴールと悪いゴール https://unsplash.com/photos/M1-7VLtyLbo
39 ゴールを話すタイミング • ゴールを話すタイミングがいつやってくるか? ◦ どの会社、どの部門であっても マネジメントのスコープが広がるにつれて、すべてを理解するのは困難に ◦ そのときにゴール(What)について話すことで やり方(How)を分離して議論できる
→ これが、言うは易く行うは難し
40 悪いゴールとは? • 数字だけになっているもの ◦ たとえば ▪ 「ビルド時間の50パーセンタイルが2秒以下になること」 ▪ 「9つのプロジェクトを終わらせること」
• なぜ、上記が悪いのか?
41 悪いゴールとは? • 数字だけになっているもの ◦ たとえば ▪ 「ビルド時間の50パーセンタイルが2秒以下になること」 ▪ 「9つのプロジェクトを終わらせること」
• なぜ、上記が悪いのか? ◦ それが野心的なゴールなのか、重要なのかわからないから
42 良いゴールとは? • 次の4つの組み合わせになっているもの ◦ たどり着きたい目標の状態 ◦ 現在のベースライン ◦ 現在のトレンド(現在のベロシティを表している)
◦ 時間の区切り
43 良いゴールとは? • 次の4つの組み合わせになっているもの ◦ たどり着きたい目標の状態 ◦ 現在のベースライン ◦ 現在のトレンド(現在のベロシティを表している)
◦ 時間の区切り • 上記を考慮すると、たとえば ◦ 「3Qでは、フロントページのレンダリング時間を 600ms(p95)から 300ms(p95)にする。 2Qでは、レンダリング時間が 500ms から 600ms に増えてしまっている。」
44 良いゴールである、と判断するためには? • シンプルな2つのテスト質問の組合せによって可能 ◦ 質問: ▪ その領域に詳しくない誰かが難しさについてある程度わかるかどうか ▪ うまく行った場合に評価できるかどうか
• 前述の4つの観点を含められていれば、おそらくこの2つの指標を満たしている
45 ゴールのタイプ • ゴールには2つの興味深いタイプがある ◦ 投資:たどり着きたい未来の状態を描くもの ◦ ベースライン:保ち続けたい状態を表すもの • なぜ、2つのタイプを考える必要があるか?
46 ゴールのタイプ • ゴールには2つの興味深いタイプがある ◦ 投資:たどり着きたい未来の状態を描くもの ◦ ベースライン:保ち続けたい状態を表すもの • なぜ、2つのタイプを考える必要があるか?
◦ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは… ▪ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする ▪ 2Qを通じて2時間遅くなってしまった
47 ゴールのタイプ • ゴールには2つの興味深いタイプがある ◦ 投資:たどり着きたい未来の状態を描くもの ◦ ベースライン:保ち続けたい状態を表すもの • なぜ、2つのタイプを考える必要があるか?
◦ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは… ▪ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする ▪ 2Qを通じて2時間遅くなってしまった • 上記は良いゴールであるが、ちょっと物足りない ◦ なぜならば、クラスタサイズを2倍にすれば明日にでも達成できるから(お金の力で) ◦ 必ずしも悪いわけではないが、別のやり方もある
48 そこで相殺目標 • 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する ◦ すなわち、相殺目標(相反する目標)を設定する
49 そこで相殺目標 • 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する ◦ すなわち、相殺目標(相反する目標)を設定する • たとえば、先ほどの例に対する相殺目標は ◦ コアバッチ処理の効率は
1GB 0.05$ を超えてはいけない ◦ パイプラインを利用しているチームに対して アラートを今より増やしてはいけない(今は週2回発生している) など
50 相殺目標の効果 • ベースラインのメトリクスにより解決策を絞り込め かつアクセルを踏むタイミングを制御できる ◦ 例:新機能に向けていい感じに進んでいる。 でも、信頼性がベースラインより下回ったら、優先度を変えよう ◦ (岩瀬補足:エラーバジェット、SLI、SLOの概念に似ている)
51 相殺目標の効果 • ベースラインのメトリクスにより解決策を絞り込め かつアクセルを踏むタイミングを制御できる ◦ 例:新機能に向けていい感じに進んでいる。 でも、信頼性がベースラインより下回ったら、優先度を変えよう ◦ (岩瀬補足:エラーバジェット、SLI、SLOの概念に似ている)
• ただ、これは必須じゃない ◦ たとえば、投資目標が達成するなら、10%は許容できるかもしれない ◦ トレードオフを事前に明確に考えておくのが大事
52 マネージャーが ハマるポイント https://unsplash.com/photos/-Cmz06-0btw
53 新任マネージャーのハマりポイント(1) • 部下のやりたい方向にのみマネジメントする ◦ そして、それが顧客や会社の興味とずれている
54 新任マネージャーのハマりポイント(1) • 部下のやりたい方向にのみマネジメントする ◦ そして、それが顧客や会社の興味とずれている • 反対に上だけにマネジメントする ◦ 上だけを見て、チームをおざなりにする
◦ 成果は健全なチームから生まれるのにもかかわらず
55 新任マネージャーのハマりポイント(1) • 部下のやりたい方向にのみマネジメントする ◦ そして、それが顧客や会社の興味とずれている • 反対に上だけにマネジメントする ◦ 上だけを見て、チームをおざなりにする
◦ 成果は健全なチームから生まれるのにもかかわらず • 上にまったくあげない ◦ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない ◦ 素晴らしい業績は伝わるべき
56 新任マネージャーのハマりポイント(1) • 部下のやりたい方向にのみマネジメントする ◦ そして、それが顧客や会社の興味とずれている • 反対に上だけにマネジメントする ◦ 上だけを見て、チームをおざなりにする
◦ 成果は健全なチームから生まれるのにもかかわらず • 上にまったくあげない ◦ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない ◦ 素晴らしい業績は伝わるべき • 部分最適化しすぎ ◦ 会社がサポートできない技術を使ったり 他のチームと競合するプロダクトを作ったりしてしまう
57 新任マネージャーのハマりポイント(2) • 採用じゃ問題は解決しないと思いこむ ◦ 追われているときは採用じゃなくて、消化活動したくなる ◦ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
58 新任マネージャーのハマりポイント(2) • 採用じゃ問題は解決しないと思いこむ ◦ 追われているときは採用じゃなくて、消化活動したくなる ◦ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる… • 関係構築に時間を使わない
◦ チームは顧客が欲しがるものを作ってリリースすることに時間を使う ◦ そのためには社内の人脈が確実に必要
59 新任マネージャーのハマりポイント(2) • 採用じゃ問題は解決しないと思いこむ ◦ 追われているときは採用じゃなくて、消化活動したくなる ◦ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる… • 関係構築に時間を使わない
◦ チームは顧客が欲しがるものを作ってリリースすることに時間を使う ◦ そのためには社内の人脈が確実に必要 • 自分の役割に固執しすぎる ◦ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている ◦ そのために役割・スコープを越えて、本当にやるべきことやる必要がある
60 新任マネージャーのハマりポイント(2) • 採用じゃ問題は解決しないと思いこむ ◦ 追われているときは採用じゃなくて、消化活動したくなる ◦ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる… • 関係構築に時間を使わない
◦ チームは顧客が欲しがるものを作ってリリースすることに時間を使う ◦ そのためには社内の人脈が確実に必要 • 自分の役割に固執しすぎる ◦ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている ◦ そのために役割・スコープを越えて、本当にやるべきことやる必要がある • 上司が人間であることを忘れる ◦ 上司の行為(たとえば大事なことを言い忘れるとか)によって、イライラすることもある ◦ ただ悪意でやってるわけではなく善意でやっている(あやまちを犯すこともある)と考える
61 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう
62 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう • 関係構築に時間を使いすぎる
◦ 大きな企業から小さな企業に移ったマネージャにありがち ◦ 小さな企業では、関係構築よりも「実行」(Execution)が大事
63 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう • 関係構築に時間を使いすぎる
◦ 大きな企業から小さな企業に移ったマネージャにありがち ◦ 小さな企業では、関係構築よりも「実行」(Execution)が大事 • 採用がすべてを解決すると考えてしまう ◦ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
64 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう • 関係構築に時間を使いすぎる
◦ 大きな企業から小さな企業に移ったマネージャにありがち ◦ 小さな企業では、関係構築よりも「実行」(Execution)が大事 • 採用がすべてを解決すると考えてしまう ◦ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく • 委譲ではなく逃げてしまう ◦ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ
65 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう • 関係構築に時間を使いすぎる
◦ 大きな企業から小さな企業に移ったマネージャにありがち ◦ 小さな企業では、関係構築よりも「実行」(Execution)が大事 • 採用がすべてを解決すると考えてしまう ◦ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく • 委譲ではなく逃げてしまう ◦ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ • 地に足がつかなくなっている(浮世離れしている) ◦ 大企業でありがちだが、現実から遠い意思決定をしやすくなってしまう (その他、新米でもベテランでもハマるポイント4点は原著参照)
66 インクルージョン https://unsplash.com/photos/ZFXZ_xMYTZs
67 インクルージョン • 書籍ではインクルージョンの2側面について語られている ◦ 機会(Oppotunity)へアクセスできること ▪ (岩瀬補足:NTT-G の各種人事制度が該当)
68 インクルージョン • 書籍ではインクルージョンの2側面について語られている ◦ 機会(Oppotunity)へアクセスできること ▪ (岩瀬補足:NTT-G の各種人事制度が該当) ◦
メンバーシップ(こっちを紹介) ▪ 会社のグループの一員として感じられること
69 インクルージョン • 書籍ではインクルージョンの2側面について語られている ◦ 機会(Oppotunity)へアクセスできること ▪ (岩瀬補足:NTT-G の各種人事制度が該当) ◦
メンバーシップ(こっちを紹介) ▪ 会社のグループの一員として感じられること • なお先に、アンチパターン ◦ 上記(特に機会)が限られた人に提供されている状態 ◦ 退職の要因になる
70 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当
71 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs
(Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会
72 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs
(Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的
73 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs
(Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的 • コーヒーチャット ◦ 異なるチームからランダムで呼ばれて話す会
74 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs
(Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的 • コーヒーチャット ◦ 異なるチームからランダムで呼ばれて話す会 • チームでのランチ ◦ 週1回などでランチする会 (儀式的で嫌な人もいる)
75 メンバーシップにおける注意点 • 前述の活動はシンプルだが そのシンプルさゆえに、考慮すべき事項が埋もれることがある
76 メンバーシップにおける注意点 • 前述の活動はシンプルだが そのシンプルさゆえに、考慮すべき事項が埋もれることがある • またどの活動も全員に有効なわけではない ◦ ランチ会といっても複雑な食事制限があるメンバーがいたら? ◦
運動がある活動だったとして、運動が苦手なメンバーがいたら? ◦ 終業後だとして、子供がいる親だったら?
77 メンバーシップにおける注意点 • 前述の活動はシンプルだが そのシンプルさゆえに、考慮すべき事項が埋もれることがある • またどの活動も全員に有効なわけではない ◦ ランチ会といっても複雑な食事制限があるメンバーがいたら? ◦
運動がある活動だったとして、運動が苦手なメンバーがいたら? ◦ 終業後だとして、子供がいる親だったら? • さまざまな組み合わせで考えること および同僚とアイデアを(小さく)検証するのが大事
78 メンバーシップの測定メトリクス • リテンションレート • リファラルレート(コホートによる) • 出席率 • コーヒーチャットの開催数 など
79 学習コミュニティ https://unsplash.com/photos/XkKCui44iM0
80 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会
81 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会 • 上手くいかなかったこと
◦ 重要な教訓などをびっしり書いた内容の濃いプレゼン ◦ 結果的に出席率も下がり、学習効果も低かった
82 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする
83 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする
◦ 進め方 ▪ チェックインで20-30秒で名前・所属・考えていることを共有 ▪ プレゼンは短く5分程度、残りはブレイクアウトして ディスカッションする時間に • 盛り上がらないこともあるので、10分程度が良い ▪ ブレイクアウトして戻ったら、学びを相互共有する
84 タイムマネジメント (コツがいっぱいある) https://unsplash.com/photos/xLs4XSQmxtE
85 タイムマネジメントのコツ (1) • 4半期に一回振り返りする ▪ 時間に何に使ってきたかカテゴリ分けする ▪ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
86 タイムマネジメントのコツ (1) • 4半期に一回振り返りする ▪ 時間に何に使ってきたかカテゴリ分けする ▪ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る •
シニアになればなるほど(所掌が広がるほど)、責務を持つ重要な仕事を完了しにくくなる ◦ さらに悪いことに、1on1が長期のゴールとぶつかってくる ◦ 最終的には長期のゴールを重要視する
87 タイムマネジメントのコツ (1) • 4半期に一回振り返りする ▪ 時間に何に使ってきたかカテゴリ分けする ▪ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る •
シニアになればなるほど(所掌が広がるほど)、責務を持つ重要な仕事を完了しにくくなる ◦ さらに悪いことに、1on1が長期のゴールとぶつかってくる ◦ 最終的には長期のゴールを重要視する • レバレッジの効く小さな仕事を終わらせる ▪ 終わらせればさらに時間ができる
88 タイムマネジメントのコツ (1) • 4半期に一回振り返りする ▪ 時間に何に使ってきたかカテゴリ分けする ▪ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る •
シニアになればなるほど(所掌が広がるほど)、責務を持つ重要な仕事を完了しにくくなる ◦ さらに悪いことに、1on1が長期のゴールとぶつかってくる ◦ 最終的には長期のゴールを重要視する • レバレッジの効く小さな仕事を終わらせる ▪ 終わらせればさらに時間ができる • やらないことを決める ▪ ただし、適当にやめるんじゃなくて構造的なやり方でやめる ▪ まず、やらないけど重要な仕事をいくつか見つける ▪ 次に新しくあがってきた組織のリスクとなる仕事を再分類する ▪ で、チームや上司に「これがやれてない」と伝える ← 重要
89 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する
90 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
91 余談:組織デザインと例外処理 ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、 各人の努力が最終的なアウトプットにまとまるように統合しなければならない。 人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。 この分業と調整の工夫が集積されたものが組織デザインである。”
92 余談:組織デザインと例外処理 ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、 各人の努力が最終的なアウトプットにまとまるように統合しなければならない。 人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。 この分業と調整の工夫が集積されたものが組織デザインである。” • 調整を行うための方法に標準化とヒエラルキーがある
93 余談:組織デザインと例外処理 ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、 各人の努力が最終的なアウトプットにまとまるように統合しなければならない。 人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。 この分業と調整の工夫が集積されたものが組織デザインである。” • 調整を行うための方法に標準化とヒエラルキーがある • 標準化とは、いちいち問い合わせしなくていいように
プロセスを事前に決めておくこと
94 余談:組織デザインと例外処理 ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、 各人の努力が最終的なアウトプットにまとまるように統合しなければならない。 人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。 この分業と調整の工夫が集積されたものが組織デザインである。” • 調整を行うための方法に標準化とヒエラルキーがある • 標準化とは、いちいち問い合わせしなくていいように
プロセスを事前に決めておくこと • ただし、どうしてもプロセスにハマらない例外事象が出てくる ◦ そこでヒエラルキーを作って、例外処理を管理者が担う ◦ (ただ、これはエネルギーを消耗するよ、という話)
95 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき • そのミーティングに出る価値があるか検討する ◦ シニアになるにつれて、ミーティングに呼ばれやすくことがある ◦ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
96 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき • そのミーティングに出る価値があるか検討する ◦ シニアになるにつれて、ミーティングに呼ばれやすくことがある ◦ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える • ちょっと先の成長を見越して採用する
97 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき • そのミーティングに出る価値があるか検討する ◦ シニアになるにつれて、ミーティングに呼ばれやすくことがある ◦ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える • ちょっと先の成長を見越して採用する • カレンダーで2時間のブロックを、週にいくつか作る
98 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく
▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき • そのミーティングに出る価値があるか検討する ◦ シニアになるにつれて、ミーティングに呼ばれやすくことがある ◦ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える • ちょっと先の成長を見越して採用する • カレンダーで2時間のブロックを、週にいくつか作る • (それでもだめなら)秘書的なサポートを得る
99
100 週7hぐらい 1on1している
101 週4hぐらい 採用面接してる
102 採用 https://unsplash.com/photos/fY8Jr4iuPQM
103 採用ファネル全体像 https://lethain.com/hiring-funnel/
104 Identify(候補者を見つける) • 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ ◦ スタートアップなどはリファラルに依存しがち ◦ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
105 Identify(候補者を見つける) • 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ ◦ スタートアップなどはリファラルに依存しがち ◦ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる • インバウンド(自然流入)
◦ いわゆるWebサイトから直接応募するケースなどが該当 ◦ 量は多いが、質は低くなりがち
106 Identify(候補者を見つける) • 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ ◦ スタートアップなどはリファラルに依存しがち ◦ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる • インバウンド(自然流入)
◦ いわゆるWebサイトから直接応募するケースなどが該当 ◦ 量は多いが、質は低くなりがち • ソーシング ◦ 企業側が積極的に動いて探してくるケースが該当 ◦ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ ▪ ちなみに別の章で、Linkedinの具体的な運用(スロットルされるまで送るとか)が書いてある
107 Identify(候補者を見つける) • 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ ◦ スタートアップなどはリファラルに依存しがち ◦ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる • インバウンド(自然流入)
◦ いわゆるWebサイトから直接応募するケースなどが該当 ◦ 量は多いが、質は低くなりがち • ソーシング ◦ 企業側が積極的に動いて探してくるケースが該当 ◦ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ ▪ ちなみに別の章で、Linkedinの具体的な運用(スロットルされるまで送るとか)が書いてある • リファーラル ◦ 前職の同僚や、大学の友人をつれてくる方法。小さな会社だと主流 ◦ 3つの内で一番効率がよい
108 Motivate(応募する気持ちになってもらう) • 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある ◦ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨 ◦ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため
109 Motivate(応募する気持ちになってもらう) • 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある ◦ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨 ◦ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため • このフェーズで効果的なこと
◦ 候補者と一緒に過ごす時間を増やす ▪ コーヒーを一緒にのんだり、取り組んでいるプロジェクトについて話したり お互いから学べることを楽しむ ◦ 正直に、ちょっとだけ楽観的に、ロールについて明確に定義して話す
110 Evaluate(評価する) • その候補者が会社で本当に上手くやっているか見極めるフェーズ ◦ 次の矛盾する3つ観点のバランスを取る必要があるため難解
111 Evaluate(評価する) • その候補者が会社で本当に上手くやっているか見極めるフェーズ ◦ 次の矛盾する3つ観点のバランスを取る必要があるため難解 • 観点 ◦ 確からしさ
▪ 候補者が会社で成功すると自信をどれだけ持てるか ▪ 離職は士気にかかわるし、上手くやるには時間もかかる
112 Evaluate(評価する) • その候補者が会社で本当に上手くやっているか見極めるフェーズ ◦ 次の矛盾する3つ観点のバランスを取る必要があるため難解 • 観点 ◦ 確からしさ
▪ 候補者が会社で成功すると自信をどれだけ持てるか ▪ 離職は士気にかかわるし、上手くやるには時間もかかる ◦ 候補者体験(CX) ▪ 候補者が評価されている間も、心地よい体験を得られるように ▪ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり
113 Evaluate(評価する) • その候補者が会社で本当に上手くやっているか見極めるフェーズ ◦ 次の矛盾する3つ観点のバランスを取る必要があるため難解 • 観点 ◦ 確からしさ
▪ 候補者が会社で成功すると自信をどれだけ持てるか ▪ 離職は士気にかかわるし、上手くやるには時間もかかる ◦ 候補者体験(CX) ▪ 候補者が評価されている間も、心地よい体験を得られるように ▪ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり ◦ 効率 ▪ チームの時間と、候補者の時間をいちばん効率よく使いたい ▪ ここでは、候補者と評価者の時間の非対称に注意 • 例えば、候補者が自宅で課題を解くための時間は長くかかるが、その評価は一瞬、はBad
114 参考:Effective Interiview の7要素 • 候補者に親切に • すべてのインタビュワー(面接官)が 面接対象のRoleの要件について合意している •
インタビューで「何を」「どうやって」見極めるか理解しておく ◦ 技術についてプレゼンしてもらう、ペアプロ・ペアデバッグする など (なお、著者は単なるアルゴリズム的な質問に否定的) • インタビュー前にしっかり準備する • 候補者に興味を持つ・示す • インタビュー自体にフィードバックループを • ファネルを計測して改善する
115 Close(内定承諾) • Motivateのフェーズに似ている ◦ ただ、1日費やす代わりに、数年を費やしてもらうかもしれない意思決定になる ◦ 給与・ボーナス・福利厚生など、複数の要因が絡んでくる • ファネル上の最後のステップなので、ファネルの全体効率を考えると特に重要
116 ファネルの最適化 • ファネルを設計したら、実装・運用して「測定」する ◦ ATS(Applicant Tracking System) のメタデータを上手く使うのもココ •
測定は超重要 ◦ なぜならば、どこに注力すべきか分かるため ◦ 会社によって注力する箇所は異なるし、同じ会社でもフェーズによって異なる ◦ 唯一の方法は、ファネルに着目をして改善を繰り返すこと
117 どこまでファネルを最適化すればいいの? • ファネルの改善初期は比較的簡単 ◦ 各フェーズを見渡して投資箇所を決めていく
118 どこまでファネルを最適化すればいいの? • ファネルの改善初期は比較的簡単 ◦ 各フェーズを見渡して投資箇所を決めていく • 厄介なのは「各セクションはどこまで高めるのが合理的なのか?」ということ ◦ つまり、50%でいいのか、85%まで上げないといけないのか
119 どこまでファネルを最適化すればいいの? • ファネルの改善初期は比較的簡単 ◦ 各フェーズを見渡して投資箇所を決めていく • 厄介なのは「各セクションはどこまで高めるのが合理的なのか?」ということ ◦ つまり、50%でいいのか、85%まで上げないといけないのか
• ライバル企業の数値があるなら有用な情報になる ◦ これがないと、過剰投資 or 過小投資につながる
120 ファネルを拡張する 拡張域 https://lethain.com/hiring-funnel/
121 ファネルを拡張する方法 (1) • Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある • オンボーディング ◦ 候補者が入社してからスピードが出てくる(立ち上がる)までにどれぐらい時間がかかるか? ◦
計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない ◦ 生産性に関するメトリックを見ると良い ▪ 例えば、入社してからP40の生産性を出すまでにかかる時間は?
122 ファネルを拡張する方法 (1) • Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある • オンボーディング ◦ 候補者が入社してからスピードが出てくる(立ち上がる)までにどれぐらい時間がかかるか? ◦
計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない ◦ 生産性に関するメトリックを見ると良い ▪ 例えば、入社してからP40の生産性を出すまでにかかる時間は? • 影響・成果 ◦ 入社してからどのぐらい影響を与えているか? ◦ これも計測は簡単じゃないが、先ほどと同じく個人ではなくグループのトレンドを見る ◦ 代替指標は、雇用してからの時間に基づくパフォーマンスレートの分布 になるだろう
123 ファネルを拡張する方法 (2) • 昇進 ◦ 入社してから昇進するまでの時間は? ▪ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
124 ファネルを拡張する方法 (2) • 昇進 ◦ 入社してから昇進するまでの時間は? ▪ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる •
継続率(離職率) ◦ 入社したメンバが辞めていないか? ◦ これは測定が簡単だが、遅行指標になる ◦ 重要なメトリックなので測定すべき
125 ファネルを拡張する方法 (2) • 昇進 ◦ 入社してから昇進するまでの時間は? ▪ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる •
継続率(離職率) ◦ 入社したメンバが辞めていないか? ◦ これは測定が簡単だが、遅行指標になる ◦ 重要なメトリックなので測定すべき • ここまでの数値はセンシティブな数値なので、組織によっては共有を嫌がる ◦ それでも構わない。誰かがケアしているのが大切!
126 採用面接の評価は難しい • Cracking the Coding Interviewをパラパラ読んだ人いる? ◦ 新しいロールに対する候補者の評価は「雑な科学」だと分かる ◦
インタビューの精度に疑問を持っている人がほとんどであり 自信を持って採用できている人はあんまりいない
127 採用面接の評価は難しい • Cracking the Coding Interviewをパラパラ読んだ人いる? ◦ 新しいロールに対する候補者の評価は「雑な科学」だと分かる ◦
インタビューの精度に疑問を持っている人がほとんどであり 自信を持って採用できている人はあんまりいない • ただ、ちょっとした構造と創造性によって 公平で一貫したやり方で確度を高められる
128 評価を上手くするためのやり方 • メトリクスファースト。データがなければ改善できない ◦ 余談:戦略の章でもデータの大事さが出る。データがなければ空中戦になるから • 今の面接プロセスのパフォーマンスを理解する ◦ 例えば
▪ ファネルはどうなっているか?どこで落ちている?他社のデータと比較したら? ▪ インタビューの結果と、実際の業績は関連している? ▪ 特に成功に資する要素はなんだった? ▪ インタビューで聞いても役立たない要素は? • …… (書籍には、この後も項目が続く。詳しくは原著で)
129 ということで 今日紹介したこと
130 書籍の全体像とのマッピング 1. 組織 a. チームの4状態と移行方法 2. ツール a. システム思考、良いゴールと悪いゴール
b. 権威に依存せずに変化を起こす方法、Model→Doc→Share c. タイムマネジメント 3. アプローチ a. マネージャーのハマりポイント 4. 文化 a. インクルージョン、機会とメンバーシップ 5. キャリア a. 採用、採用、採用 6. 付録
131 書籍の全体像とのマッピング 1. 組織 a. チームの4状態と移行方法 2. ツール a. システム思考、良いゴールと悪いゴール
b. 権威に依存せずに変化を起こす方法、Model→Doc→Share c. タイムマネジメント 3. アプローチ a. マネージャーのハマりポイント 4. 文化 a. インクルージョン、機会とメンバーシップ 5. キャリア a. 採用、採用、採用 6. 付録 これで全体の30%ぐらい? (残りは書籍で)
132 おさらい:発表終了時の到達点 • An Elegant Puzzle: Systems of Engineering Management
の書籍に書いてある内容の一部を理解している おしまい