Slide 1
Slide 1 text
An Elegant Puzzle:
Systems of Engineering Management
を50分でざっと知る
(at NTT Com TechLunch #158)
2022年11月
NTT コミュニケーションズ 岩瀬 / @iwashi86
Slide 2
Slide 2 text
1
発表終了時の到達点
● An Elegant Puzzle: Systems of Engineering Management※
の書籍に書いてある内容の一部を理解している
※ 岩瀬が2022年に読んだ中で一番学びがあった本
Slide 3
Slide 3 text
2
著者
● Will larson氏 (@lethain)
● Uber社のシニアエンジニアリングマネージャーや
Stripe社のエンジニア組織のHeadを歴任して
現在はCalm社のCTO
● Hacker News にブログポストがよく載っており
IT界隈の著名人の1人
Slide 4
Slide 4 text
3
どんな本？
● 実際にEMや、EMを束ねるHeadとして活動してきた
著者の知見がまとまっている書籍
● 実践的なプラクティスや考え方が多く掲載される
○ 研究による裏付けがメインという類の書籍ではない
Slide 5
Slide 5 text
4
書籍の全体像
1. 組織 - 組織やチームデザイン
2. ツール - システム思考、ツール、変化の起こし方
3. アプローチ - EMが直面する課題と解決法
4. 文化 - 組織文化への取り組み
5. キャリア - 採用、評価、昇進
6. 付録
Slide 6
Slide 6 text
5
書籍の全体像
1. 組織 - 組織やチームデザイン
2. ツール - システム思考、ツール、変化の起こし方
3. アプローチ - EMが直面する課題と解決法
4. 文化 - 組織文化への取り組み
5. キャリア - 採用、評価、昇進
6. 付録
→ 個人的に印象に残った箇所を順不同でかいつまんで紹介します！
Slide 7
Slide 7 text
6
本題
Slide 8
Slide 8 text
7
チームの状態と移行
https://unsplash.com/photos/E9PJO_vL3E8
Slide 9
Slide 9 text
8
チームの状態（次のページで説明）
https://lethain.com/durably-excellent-teams/ より
Slide 10
Slide 10 text
9
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
Slide 11
Slide 11 text
10
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
2. 立ち泳ぎ状態
○ 必要な仕事はできているが、技術的負債の返済はできず
新しいプロジェクトにも着手できていない
○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
Slide 12
Slide 12 text
11
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
2. 立ち泳ぎ状態
○ 必要な仕事はできているが、技術的負債の返済はできず
新しいプロジェクトにも着手できていない
○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
3. 返済可能な状態
○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
Slide 13
Slide 13 text
12
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
2. 立ち泳ぎ状態
○ 必要な仕事はできているが、技術的負債の返済はできず
新しいプロジェクトにも着手できていない
○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
3. 返済可能な状態
○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
4. 革新が起こせる状態
○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
Slide 14
Slide 14 text
13
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
2. 立ち泳ぎ状態
○ 必要な仕事はできているが、技術的負債の返済はできず
新しいプロジェクトにも着手できていない
○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
3. 返済可能な状態
○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
4. 革新が起こせる状態
○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
さて今、
ご自身のチームは
どの状態にいますか？
（心の中で考えよう）
Slide 15
Slide 15 text
14
チームの状態
https://lethain.com/durably-excellent-teams/
1. 遅れている状態
○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
○ メンバーの士気は低く、不満が口から出ている
2. 立ち泳ぎ状態
○ 必要な仕事はできているが、技術的負債の返済はできず
新しいプロジェクトにも着手できていない
○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
3. 返済可能な状態
○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
4. 革新が起こせる状態
○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
どうやって
次の状態に移行するか？
Slide 16
Slide 16 text
15
チームの移行方法
https://lethain.com/durably-excellent-teams/
● [1]遅れている状態 -> [2]立ち泳ぎ状態
○ [2]に移行できるまで採用する ← ヘッドカウントで諦めるマネージャも多いが頑張りどころ
○ ちょっとした成功を祝う、楽観的な考えを吹き込む
Slide 17
Slide 17 text
16
チームの移行方法
https://lethain.com/durably-excellent-teams/
● [1]遅れている状態 -> [2]立ち泳ぎ状態
○ [2]に移行できるまで採用する
○ ちょっとした成功を祝う、楽観的な考えを吹き込む
● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
○ チームメンバーの生産性の見方を、個人からチームへと変えていく
Slide 18
Slide 18 text
17
チームの移行方法
https://lethain.com/durably-excellent-teams/
● [1]遅れている状態 -> [2]立ち泳ぎ状態
○ [2]に移行できるまで採用する
○ ちょっとした成功を祝う、楽観的な考えを吹き込む
● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
○ チームメンバーの生産性の見方を、個人からチームへと変えていく
● [3] 返済可能な状態 -> [4] 革新が起こせる状態
○ 負債を返済し始めているので、さらに時間を作れるようにする
■ ステークホルダーは「時間ができてそうだから、新しい価値を！」となるかもしれないが
そこを耐えて [3] -> [2] に戻さないようにする
Slide 19
Slide 19 text
18
チームの移行方法
https://lethain.com/durably-excellent-teams/
● [1]遅れている状態 -> [2]立ち泳ぎ状態
○ [2]に移行できるまで採用する
○ ちょっとした成功を祝う、楽観的な考えを吹き込む
● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
○ チームメンバーの生産性の見方を、個人からチームへと変えていく
● [3] 返済可能な状態 -> [4] 革新が起こせる状態
○ 負債を返済し始めているので、さらに時間を作れるようにする
■ ステークホルダーは「時間ができてそうだから、新しい価値を！」となるかもしれないが
そこを耐えて [3] -> [2] に戻さないようにする
● [4] イノベーションを起こせる状態以降
○ Slack！（トムデマルコの書籍を読もう！）
○ ただし、失敗しがちなのは顧客価値に繋がらないフレームワークの移行への着手など
Slide 20
Slide 20 text
19
移行時の注意点
https://lethain.com/durably-excellent-teams/
● それぞれの状態の移行には「時間がかかる」
○ システムによっては、数年以上の負債蓄積がある
○ 逆に言えば、修正に時間がかかるのと同じで
効果が出れば長い時間維持できる
Slide 21
Slide 21 text
20
移行時の注意点
https://lethain.com/durably-excellent-teams/
● それぞれの状態の移行には「時間がかかる」
○ システムによっては、数年以上の負債蓄積がある
○ 逆に言えば、修正に時間がかかるのと同じで
効果が出れば長い時間維持できる
● 簡単には効果が出ない
○ 長く時間がかかっても、自分の計画を信頼して維持すること
（だから組織をいじったり、新しい仕事を始めずに続けること）
Slide 22
Slide 22 text
21
（変化を効果的に導く）
ツール
https://unsplash.com/photos/sm0Bkoj5bnA
Slide 23
Slide 23 text
22
3大ツール + α
● システム思考
○ 右の書籍を読めばわかる
○ ストックとフローを用いてシステムで考える
○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
Slide 24
Slide 24 text
23
3大ツール + α
● システム思考
○ 右の書籍を読めばわかる
○ ストックとフローを用いてシステムで考える
○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
● メトリクス
○ あとで出てくる
Slide 25
Slide 25 text
24
3大ツール + α
● システム思考
○ 右の書籍を読めばわかる
○ ストックとフローを用いてシステムで考える
○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
● メトリクス
○ あとで出てくる
● ビジョン
○ （原著参照）
Slide 26
Slide 26 text
25
3大ツール + α
● システム思考
○ 右の書籍を読めばわかる
○ ストックとフローを用いてシステムで考える
○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
● メトリクス
○ あとで出てくる
● ビジョン
○ （原著参照）
● プロダクトマネジメント（思考）
○ （探索・選択・検証をEM視点から書いてある、詳細は原著）
Slide 27
Slide 27 text
26
3大ツール + α
● システム思考
○ 右の書籍を読めばわかる
○ ストックとフローを用いてシステムで考える
○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
● メトリクス
○ あとで出てくる
● ビジョン
○ （原著参照）
● プロダクトマネジメント（思考）
○ （探索・選択・検証をEM視点から書いてある、詳細は原著）
では具体的に
どうやって変化を導く？
Slide 28
Slide 28 text
27
（権威に依存しない）
リーダーシップ
https://unsplash.com/photos/6U5AEmQIajg
Slide 29
Slide 29 text
28
厄介な問題
● こんな経験は？
○ ここに問題がありそうだけど、自分は部長でも課長でもなくて
一人の担当者にすぎない
■ or 新しく配属された部署だと、まだ信頼貯金がない…
○ どうやって解決すればいいんだろう？
（岩瀬補足：PdM とかまさにこれ。多くは人事権限がない）
Slide 30
Slide 30 text
29
厄介な問題
● こんな経験は？
○ ここに問題がありそうだけど、自分は部長でも課長でもなくて
一人の担当者にすぎない
■ or 新しく配属された部署だと、まだ信頼貯金がない…
○ どうやって解決すればいいんだろう？
（岩瀬補足：PdM とかまさにこれ。多くは人事権限がない）
● そんな時に（すべてではないが）上手く行った方法がある
○ それが Model -> Document -> Share
Slide 31
Slide 31 text
30
https://lethain.com/model-document-share/
Slide 32
Slide 32 text
31
Model
● 月次などでチームの健康状態やスループットを計測する
○ 例：タスクサイズを軽量に測定
● 大事なのは変化を加える前のベースライン（基準値）を知ること
Slide 33
Slide 33 text
32
Model
● 月次などでチームの健康状態やスループットを計測する
○ 例：タスクサイズを軽量に測定
● 大事なのは変化を加える前のベースライン（基準値）を知ること
● おおっぴらに宣伝するのではなく、「ちょっとした実験だよ」
といった意味づけではじめて、しばらく続ける
○ ダメだったらやめればいい
● 一定、効果が出てくると感じたら…
Slide 34
Slide 34 text
33
Document
● 次の内容を文書化する
○ 解決しようとしている問題
○ 試行から学んだこと
○ 他のチームで採用（再現）するための方法の詳細
■ 可能な限り詳しく、汎化して
■ 他のチームに新規メンバが入っても理解できるように
Slide 35
Slide 35 text
34
Share
● 短いメールでドキュメントを配布する
○ この時自分の経験談も入れておく
● 「採用してください！」とは言わない
○ 単に方法を紹介するだけでいい
● 奇妙なことに著者の経験からいえば、
トップダウン・強制型のアプローチよりも採用率が高い
Slide 36
Slide 36 text
35
参考：Model→Document→Share と トップダウン のどちらを使えば？
● Model → Document → Share
○ 新しい施策を採用する余裕がない
○ 新しい施策を広めるためのリソースがない
○ 分散型で意思決定したいトピックである
○ チームが自律的に採用できる
○ 徐々に変更が起こってもいい
● それぞれに特徴、向き不向きがある
Slide 37
Slide 37 text
36
● トップダウン、強制型
○ 新しい施策を採用する余裕がある
○ 新しい施策を広めるためのリソースがある
○ 中央集権的に決定したいトピックである
○ 組織内で一貫性が必要
○ 素早く変更を起こしたい
● Model → Document → Share
○ 新しい施策を採用する余裕がない
○ 新しい施策を広めるためのリソースがない
○ 分散型で意思決定したいトピックである
○ チームが自律的に採用できる
○ 徐々に変更が起こってもいい
● それぞれに特徴、向き不向きがある
参考：Model→Document→Share と トップダウン のどちらを使えば？
Slide 38
Slide 38 text
37
● トップダウン、強制型
○ 新しい施策を採用する余裕がある
○ 新しい施策を広めるためのリソースがある
○ 中央集権的に決定したいトピックである
○ 組織内で一貫性が必要
○ 素早く変更を起こしたい
● Model → Document → Share
○ 新しい施策を採用する余裕がない
○ 新しい施策を広めるためのリソースがない
○ 分散型で意思決定したいトピックである
○ チームが自律的に採用できる
○ 徐々に変更が起こってもいい
● それぞれに特徴、向き不向きがある
● Model → Document → Share 型は
組織の価値観があっているときに効果をより発揮しやすい
○ ただし、同僚からの尊敬など、自然発生するAuthority(信頼貯金)は必要
参考：Model→Document→Share と トップダウン のどちらを使えば？
Slide 39
Slide 39 text
38
良いゴールと悪いゴール
https://unsplash.com/photos/M1-7VLtyLbo
Slide 40
Slide 40 text
39
ゴールを話すタイミング
● ゴールを話すタイミングがいつやってくるか？
○ どの会社、どの部門であっても
マネジメントのスコープが広がるにつれて、すべてを理解するのは困難に
○ そのときにゴール（What）について話すことで
やり方（How）を分離して議論できる
→ これが、言うは易く行うは難し
Slide 41
Slide 41 text
40
悪いゴールとは？
● 数字だけになっているもの
○ たとえば
■ 「ビルド時間の50パーセンタイルが2秒以下になること」
■ 「9つのプロジェクトを終わらせること」
● なぜ、上記が悪いのか？
Slide 42
Slide 42 text
41
悪いゴールとは？
● 数字だけになっているもの
○ たとえば
■ 「ビルド時間の50パーセンタイルが2秒以下になること」
■ 「9つのプロジェクトを終わらせること」
● なぜ、上記が悪いのか？
○ それが野心的なゴールなのか、重要なのかわからないから
Slide 43
Slide 43 text
42
良いゴールとは？
● 次の4つの組み合わせになっているもの
○ たどり着きたい目標の状態
○ 現在のベースライン
○ 現在のトレンド（現在のベロシティを表している）
○ 時間の区切り
Slide 44
Slide 44 text
43
良いゴールとは？
● 次の4つの組み合わせになっているもの
○ たどり着きたい目標の状態
○ 現在のベースライン
○ 現在のトレンド（現在のベロシティを表している）
○ 時間の区切り
● 上記を考慮すると、たとえば
○ 「3Qでは、フロントページのレンダリング時間を 600ms(p95)から 300ms(p95)にする。
2Qでは、レンダリング時間が 500ms から 600ms に増えてしまっている。」
Slide 45
Slide 45 text
44
良いゴールである、と判断するためには？
● シンプルな２つのテスト質問の組合せによって可能
○ 質問：
■ その領域に詳しくない誰かが難しさについてある程度わかるかどうか
■ うまく行った場合に評価できるかどうか
● 前述の4つの観点を含められていれば、おそらくこの2つの指標を満たしている
Slide 46
Slide 46 text
45
ゴールのタイプ
● ゴールには2つの興味深いタイプがある
○ 投資：たどり着きたい未来の状態を描くもの
○ ベースライン：保ち続けたい状態を表すもの
● なぜ、2つのタイプを考える必要があるか？
Slide 47
Slide 47 text
46
ゴールのタイプ
● ゴールには2つの興味深いタイプがある
○ 投資：たどり着きたい未来の状態を描くもの
○ ベースライン：保ち続けたい状態を表すもの
● なぜ、2つのタイプを考える必要があるか？
○ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは…
■ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする
■ 2Qを通じて2時間遅くなってしまった
Slide 48
Slide 48 text
47
ゴールのタイプ
● ゴールには2つの興味深いタイプがある
○ 投資：たどり着きたい未来の状態を描くもの
○ ベースライン：保ち続けたい状態を表すもの
● なぜ、2つのタイプを考える必要があるか？
○ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは…
■ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする
■ 2Qを通じて2時間遅くなってしまった
● 上記は良いゴールであるが、ちょっと物足りない
○ なぜならば、クラスタサイズを2倍にすれば明日にでも達成できるから（お金の力で）
○ 必ずしも悪いわけではないが、別のやり方もある
Slide 49
Slide 49 text
48
そこで相殺目標
● 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する
○ すなわち、相殺目標（相反する目標）を設定する
Slide 50
Slide 50 text
49
そこで相殺目標
● 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する
○ すなわち、相殺目標（相反する目標）を設定する
● たとえば、先ほどの例に対する相殺目標は
○ コアバッチ処理の効率は 1GB 0.05$ を超えてはいけない
○ パイプラインを利用しているチームに対して
アラートを今より増やしてはいけない（今は週2回発生している） など
Slide 51
Slide 51 text
50
相殺目標の効果
● ベースラインのメトリクスにより解決策を絞り込め
かつアクセルを踏むタイミングを制御できる
○ 例：新機能に向けていい感じに進んでいる。
でも、信頼性がベースラインより下回ったら、優先度を変えよう
○ （岩瀬補足：エラーバジェット、SLI、SLOの概念に似ている）
Slide 52
Slide 52 text
51
相殺目標の効果
● ベースラインのメトリクスにより解決策を絞り込め
かつアクセルを踏むタイミングを制御できる
○ 例：新機能に向けていい感じに進んでいる。
でも、信頼性がベースラインより下回ったら、優先度を変えよう
○ （岩瀬補足：エラーバジェット、SLI、SLOの概念に似ている）
● ただ、これは必須じゃない
○ たとえば、投資目標が達成するなら、10%は許容できるかもしれない
○ トレードオフを事前に明確に考えておくのが大事
Slide 53
Slide 53 text
52
マネージャーが
ハマるポイント
https://unsplash.com/photos/-Cmz06-0btw
Slide 54
Slide 54 text
53
新任マネージャーのハマりポイント(1)
● 部下のやりたい方向にのみマネジメントする
○ そして、それが顧客や会社の興味とずれている
Slide 55
Slide 55 text
54
新任マネージャーのハマりポイント(1)
● 部下のやりたい方向にのみマネジメントする
○ そして、それが顧客や会社の興味とずれている
● 反対に上だけにマネジメントする
○ 上だけを見て、チームをおざなりにする
○ 成果は健全なチームから生まれるのにもかかわらず
Slide 56
Slide 56 text
55
新任マネージャーのハマりポイント(1)
● 部下のやりたい方向にのみマネジメントする
○ そして、それが顧客や会社の興味とずれている
● 反対に上だけにマネジメントする
○ 上だけを見て、チームをおざなりにする
○ 成果は健全なチームから生まれるのにもかかわらず
● 上にまったくあげない
○ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない
○ 素晴らしい業績は伝わるべき
Slide 57
Slide 57 text
56
新任マネージャーのハマりポイント(1)
● 部下のやりたい方向にのみマネジメントする
○ そして、それが顧客や会社の興味とずれている
● 反対に上だけにマネジメントする
○ 上だけを見て、チームをおざなりにする
○ 成果は健全なチームから生まれるのにもかかわらず
● 上にまったくあげない
○ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない
○ 素晴らしい業績は伝わるべき
● 部分最適化しすぎ
○ 会社がサポートできない技術を使ったり
他のチームと競合するプロダクトを作ったりしてしまう
Slide 58
Slide 58 text
57
新任マネージャーのハマりポイント(2)
● 採用じゃ問題は解決しないと思いこむ
○ 追われているときは採用じゃなくて、消化活動したくなる
○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
Slide 59
Slide 59 text
58
新任マネージャーのハマりポイント(2)
● 採用じゃ問題は解決しないと思いこむ
○ 追われているときは採用じゃなくて、消化活動したくなる
○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
● 関係構築に時間を使わない
○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
○ そのためには社内の人脈が確実に必要
Slide 60
Slide 60 text
59
新任マネージャーのハマりポイント(2)
● 採用じゃ問題は解決しないと思いこむ
○ 追われているときは採用じゃなくて、消化活動したくなる
○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
● 関係構築に時間を使わない
○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
○ そのためには社内の人脈が確実に必要
● 自分の役割に固執しすぎる
○ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている
○ そのために役割・スコープを越えて、本当にやるべきことやる必要がある
Slide 61
Slide 61 text
60
新任マネージャーのハマりポイント(2)
● 採用じゃ問題は解決しないと思いこむ
○ 追われているときは採用じゃなくて、消化活動したくなる
○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
● 関係構築に時間を使わない
○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
○ そのためには社内の人脈が確実に必要
● 自分の役割に固執しすぎる
○ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている
○ そのために役割・スコープを越えて、本当にやるべきことやる必要がある
● 上司が人間であることを忘れる
○ 上司の行為（たとえば大事なことを言い忘れるとか）によって、イライラすることもある
○ ただ悪意でやってるわけではなく善意でやっている（あやまちを犯すこともある）と考える
Slide 62
Slide 62 text
61
経験あるマネージャーのハマりポイント
● 前の会社で上手くいったことをやってしまう
○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
○ そうしなければ存在しない問題に取り組んでしまう
Slide 63
Slide 63 text
62
経験あるマネージャーのハマりポイント
● 前の会社で上手くいったことをやってしまう
○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
○ そうしなければ存在しない問題に取り組んでしまう
● 関係構築に時間を使いすぎる
○ 大きな企業から小さな企業に移ったマネージャにありがち
○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
Slide 64
Slide 64 text
63
経験あるマネージャーのハマりポイント
● 前の会社で上手くいったことをやってしまう
○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
○ そうしなければ存在しない問題に取り組んでしまう
● 関係構築に時間を使いすぎる
○ 大きな企業から小さな企業に移ったマネージャにありがち
○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
● 採用がすべてを解決すると考えてしまう
○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
Slide 65
Slide 65 text
64
経験あるマネージャーのハマりポイント
● 前の会社で上手くいったことをやってしまう
○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
○ そうしなければ存在しない問題に取り組んでしまう
● 関係構築に時間を使いすぎる
○ 大きな企業から小さな企業に移ったマネージャにありがち
○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
● 採用がすべてを解決すると考えてしまう
○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
● 委譲ではなく逃げてしまう
○ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ
Slide 66
Slide 66 text
65
経験あるマネージャーのハマりポイント
● 前の会社で上手くいったことをやってしまう
○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
○ そうしなければ存在しない問題に取り組んでしまう
● 関係構築に時間を使いすぎる
○ 大きな企業から小さな企業に移ったマネージャにありがち
○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
● 採用がすべてを解決すると考えてしまう
○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
● 委譲ではなく逃げてしまう
○ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ
● 地に足がつかなくなっている（浮世離れしている）
○ 大企業でありがちだが、現実から遠い意思決定をしやすくなってしまう
（その他、新米でもベテランでもハマるポイント4点は原著参照）
Slide 67
Slide 67 text
66
インクルージョン
https://unsplash.com/photos/ZFXZ_xMYTZs
Slide 68
Slide 68 text
67
インクルージョン
● 書籍ではインクルージョンの2側面について語られている
○ 機会（Oppotunity）へアクセスできること
■ （岩瀬補足：NTT-G の各種人事制度が該当）
Slide 69
Slide 69 text
68
インクルージョン
● 書籍ではインクルージョンの2側面について語られている
○ 機会（Oppotunity）へアクセスできること
■ （岩瀬補足：NTT-G の各種人事制度が該当）
○ メンバーシップ（こっちを紹介）
■ 会社のグループの一員として感じられること
Slide 70
Slide 70 text
69
インクルージョン
● 書籍ではインクルージョンの2側面について語られている
○ 機会（Oppotunity）へアクセスできること
■ （岩瀬補足：NTT-G の各種人事制度が該当）
○ メンバーシップ（こっちを紹介）
■ 会社のグループの一員として感じられること
● なお先に、アンチパターン
○ 上記（特に機会）が限られた人に提供されている状態
○ 退職の要因になる
Slide 71
Slide 71 text
70
メンバーシップを高めるために良かったこと
● 業務時間中に開催される週次の定例イベント
○ 任意で誰でも参加できる
○ 論文読み会や読書会が該当
Slide 72
Slide 72 text
71
メンバーシップを高めるために良かったこと
● 業務時間中に開催される週次の定例イベント
○ 任意で誰でも参加できる
○ 論文読み会や読書会が該当
● ERGs (Employee Resource Groups)
○ 共通の属性・背景を持つメンバが集まる機会
Slide 73
Slide 73 text
72
メンバーシップを高めるために良かったこと
● 業務時間中に開催される週次の定例イベント
○ 任意で誰でも参加できる
○ 論文読み会や読書会が該当
● ERGs (Employee Resource Groups)
○ 共通の属性・背景を持つメンバが集まる機会
● チームでのオフサイト
○ 4半期に1回立ち止まってふりかえる
○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
■ 特にマネージャーの集まりで効果的
Slide 74
Slide 74 text
73
メンバーシップを高めるために良かったこと
● 業務時間中に開催される週次の定例イベント
○ 任意で誰でも参加できる
○ 論文読み会や読書会が該当
● ERGs (Employee Resource Groups)
○ 共通の属性・背景を持つメンバが集まる機会
● チームでのオフサイト
○ 4半期に1回立ち止まってふりかえる
○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
■ 特にマネージャーの集まりで効果的
● コーヒーチャット
○ 異なるチームからランダムで呼ばれて話す会
Slide 75
Slide 75 text
74
メンバーシップを高めるために良かったこと
● 業務時間中に開催される週次の定例イベント
○ 任意で誰でも参加できる
○ 論文読み会や読書会が該当
● ERGs (Employee Resource Groups)
○ 共通の属性・背景を持つメンバが集まる機会
● チームでのオフサイト
○ 4半期に1回立ち止まってふりかえる
○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
■ 特にマネージャーの集まりで効果的
● コーヒーチャット
○ 異なるチームからランダムで呼ばれて話す会
● チームでのランチ
○ 週1回などでランチする会 （儀式的で嫌な人もいる）
Slide 76
Slide 76 text
75
メンバーシップにおける注意点
● 前述の活動はシンプルだが
そのシンプルさゆえに、考慮すべき事項が埋もれることがある
Slide 77
Slide 77 text
76
メンバーシップにおける注意点
● 前述の活動はシンプルだが
そのシンプルさゆえに、考慮すべき事項が埋もれることがある
● またどの活動も全員に有効なわけではない
○ ランチ会といっても複雑な食事制限があるメンバーがいたら？
○ 運動がある活動だったとして、運動が苦手なメンバーがいたら？
○ 終業後だとして、子供がいる親だったら？
Slide 78
Slide 78 text
77
メンバーシップにおける注意点
● 前述の活動はシンプルだが
そのシンプルさゆえに、考慮すべき事項が埋もれることがある
● またどの活動も全員に有効なわけではない
○ ランチ会といっても複雑な食事制限があるメンバーがいたら？
○ 運動がある活動だったとして、運動が苦手なメンバーがいたら？
○ 終業後だとして、子供がいる親だったら？
● さまざまな組み合わせで考えること
および同僚とアイデアを（小さく）検証するのが大事
Slide 79
Slide 79 text
78
メンバーシップの測定メトリクス
● リテンションレート
● リファラルレート（コホートによる）
● 出席率
● コーヒーチャットの開催数 など
Slide 80
Slide 80 text
79
学習コミュニティ
https://unsplash.com/photos/XkKCui44iM0
Slide 81
Slide 81 text
80
Community of Learning - 上手くいかなかったこと
● いわゆるEMコミュニティでの勉強会
Slide 82
Slide 82 text
81
Community of Learning - 上手くいかなかったこと
● いわゆるEMコミュニティでの勉強会
● 上手くいかなかったこと
○ 重要な教訓などをびっしり書いた内容の濃いプレゼン
○ 結果的に出席率も下がり、学習効果も低かった
Slide 83
Slide 83 text
82
Community of Learning - 上手くいったこと
● 上手く行ったアプローチ
○ 主催者は講師ではなく、互いの学びをファシリテートする
Slide 84
Slide 84 text
83
Community of Learning - 上手くいったこと
● 上手く行ったアプローチ
○ 主催者は講師ではなく、互いの学びをファシリテートする
○ 進め方
■ チェックインで20-30秒で名前・所属・考えていることを共有
■ プレゼンは短く5分程度、残りはブレイクアウトして
ディスカッションする時間に
● 盛り上がらないこともあるので、10分程度が良い
■ ブレイクアウトして戻ったら、学びを相互共有する
Slide 85
Slide 85 text
84
タイムマネジメント
（コツがいっぱいある）
https://unsplash.com/photos/xLs4XSQmxtE
Slide 86
Slide 86 text
85
タイムマネジメントのコツ (1)
● ４半期に一回振り返りする
■ 時間に何に使ってきたかカテゴリ分けする
■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
Slide 87
Slide 87 text
86
タイムマネジメントのコツ (1)
● ４半期に一回振り返りする
■ 時間に何に使ってきたかカテゴリ分けする
■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
○ 最終的には長期のゴールを重要視する
Slide 88
Slide 88 text
87
タイムマネジメントのコツ (1)
● ４半期に一回振り返りする
■ 時間に何に使ってきたかカテゴリ分けする
■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
○ 最終的には長期のゴールを重要視する
● レバレッジの効く小さな仕事を終わらせる
■ 終わらせればさらに時間ができる
Slide 89
Slide 89 text
88
タイムマネジメントのコツ (1)
● ４半期に一回振り返りする
■ 時間に何に使ってきたかカテゴリ分けする
■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
○ 最終的には長期のゴールを重要視する
● レバレッジの効く小さな仕事を終わらせる
■ 終わらせればさらに時間ができる
● やらないことを決める
■ ただし、適当にやめるんじゃなくて構造的なやり方でやめる
■ まず、やらないけど重要な仕事をいくつか見つける
■ 次に新しくあがってきた組織のリスクとなる仕事を再分類する
■ で、チームや上司に「これがやれてない」と伝える ← 重要
Slide 90
Slide 90 text
89
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
Slide 91
Slide 91 text
90
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
Slide 92
Slide 92 text
91
余談：組織デザインと例外処理
”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
この分業と調整の工夫が集積されたものが組織デザインである。”
Slide 93
Slide 93 text
92
余談：組織デザインと例外処理
”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
この分業と調整の工夫が集積されたものが組織デザインである。”
● 調整を行うための方法に標準化とヒエラルキーがある
Slide 94
Slide 94 text
93
余談：組織デザインと例外処理
”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
この分業と調整の工夫が集積されたものが組織デザインである。”
● 調整を行うための方法に標準化とヒエラルキーがある
● 標準化とは、いちいち問い合わせしなくていいように
プロセスを事前に決めておくこと
Slide 95
Slide 95 text
94
余談：組織デザインと例外処理
”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
この分業と調整の工夫が集積されたものが組織デザインである。”
● 調整を行うための方法に標準化とヒエラルキーがある
● 標準化とは、いちいち問い合わせしなくていいように
プロセスを事前に決めておくこと
● ただし、どうしてもプロセスにハマらない例外事象が出てくる
○ そこでヒエラルキーを作って、例外処理を管理者が担う
○ （ただ、これはエネルギーを消耗するよ、という話）
Slide 96
Slide 96 text
95
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
● そのミーティングに出る価値があるか検討する
○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
Slide 97
Slide 97 text
96
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
● そのミーティングに出る価値があるか検討する
○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
● ちょっと先の成長を見越して採用する
Slide 98
Slide 98 text
97
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
● そのミーティングに出る価値があるか検討する
○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
● ちょっと先の成長を見越して採用する
● カレンダーで2時間のブロックを、週にいくつか作る
Slide 99
Slide 99 text
98
タイムマネジメントのコツ (2)
● 時間を先に割り当てておく
○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
○ だから時間を先に割り当てておく
■ たとえば、毎週2hと決めてその中で対応する
● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
● そのミーティングに出る価値があるか検討する
○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
● ちょっと先の成長を見越して採用する
● カレンダーで2時間のブロックを、週にいくつか作る
● （それでもだめなら）秘書的なサポートを得る
Slide 100
Slide 100 text
99
Slide 101
Slide 101 text
100
週7hぐらい
1on1している
Slide 102
Slide 102 text
101
週4hぐらい
採用面接してる
Slide 103
Slide 103 text
102
採用
https://unsplash.com/photos/fY8Jr4iuPQM
Slide 104
Slide 104 text
103
採用ファネル全体像
https://lethain.com/hiring-funnel/
Slide 105
Slide 105 text
104
Identify（候補者を見つける）
● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
○ スタートアップなどはリファラルに依存しがち
○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
Slide 106
Slide 106 text
105
Identify（候補者を見つける）
● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
○ スタートアップなどはリファラルに依存しがち
○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
● インバウンド（自然流入）
○ いわゆるWebサイトから直接応募するケースなどが該当
○ 量は多いが、質は低くなりがち
Slide 107
Slide 107 text
106
Identify（候補者を見つける）
● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
○ スタートアップなどはリファラルに依存しがち
○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
● インバウンド（自然流入）
○ いわゆるWebサイトから直接応募するケースなどが該当
○ 量は多いが、質は低くなりがち
● ソーシング
○ 企業側が積極的に動いて探してくるケースが該当
○ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ
■ ちなみに別の章で、Linkedinの具体的な運用（スロットルされるまで送るとか）が書いてある
Slide 108
Slide 108 text
107
Identify（候補者を見つける）
● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
○ スタートアップなどはリファラルに依存しがち
○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
● インバウンド（自然流入）
○ いわゆるWebサイトから直接応募するケースなどが該当
○ 量は多いが、質は低くなりがち
● ソーシング
○ 企業側が積極的に動いて探してくるケースが該当
○ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ
■ ちなみに別の章で、Linkedinの具体的な運用（スロットルされるまで送るとか）が書いてある
● リファーラル
○ 前職の同僚や、大学の友人をつれてくる方法。小さな会社だと主流
○ 3つの内で一番効率がよい
Slide 109
Slide 109 text
108
Motivate（応募する気持ちになってもらう）
● 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある
○ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨
○ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため
Slide 110
Slide 110 text
109
Motivate（応募する気持ちになってもらう）
● 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある
○ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨
○ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため
● このフェーズで効果的なこと
○ 候補者と一緒に過ごす時間を増やす
■ コーヒーを一緒にのんだり、取り組んでいるプロジェクトについて話したり
お互いから学べることを楽しむ
○ 正直に、ちょっとだけ楽観的に、ロールについて明確に定義して話す
Slide 111
Slide 111 text
110
Evaluate（評価する）
● その候補者が会社で本当に上手くやっているか見極めるフェーズ
○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
Slide 112
Slide 112 text
111
Evaluate（評価する）
● その候補者が会社で本当に上手くやっているか見極めるフェーズ
○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
● 観点
○ 確からしさ
■ 候補者が会社で成功すると自信をどれだけ持てるか
■ 離職は士気にかかわるし、上手くやるには時間もかかる
Slide 113
Slide 113 text
112
Evaluate（評価する）
● その候補者が会社で本当に上手くやっているか見極めるフェーズ
○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
● 観点
○ 確からしさ
■ 候補者が会社で成功すると自信をどれだけ持てるか
■ 離職は士気にかかわるし、上手くやるには時間もかかる
○ 候補者体験（CX）
■ 候補者が評価されている間も、心地よい体験を得られるように
■ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり
Slide 114
Slide 114 text
113
Evaluate（評価する）
● その候補者が会社で本当に上手くやっているか見極めるフェーズ
○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
● 観点
○ 確からしさ
■ 候補者が会社で成功すると自信をどれだけ持てるか
■ 離職は士気にかかわるし、上手くやるには時間もかかる
○ 候補者体験（CX）
■ 候補者が評価されている間も、心地よい体験を得られるように
■ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり
○ 効率
■ チームの時間と、候補者の時間をいちばん効率よく使いたい
■ ここでは、候補者と評価者の時間の非対称に注意
● 例えば、候補者が自宅で課題を解くための時間は長くかかるが、その評価は一瞬、はBad
Slide 115
Slide 115 text
114
参考：Effective Interiview の7要素
● 候補者に親切に
● すべてのインタビュワー（面接官）が
面接対象のRoleの要件について合意している
● インタビューで「何を」「どうやって」見極めるか理解しておく
○ 技術についてプレゼンしてもらう、ペアプロ・ペアデバッグする など
（なお、著者は単なるアルゴリズム的な質問に否定的）
● インタビュー前にしっかり準備する
● 候補者に興味を持つ・示す
● インタビュー自体にフィードバックループを
● ファネルを計測して改善する
Slide 116
Slide 116 text
115
Close（内定承諾）
● Motivateのフェーズに似ている
○ ただ、1日費やす代わりに、数年を費やしてもらうかもしれない意思決定になる
○ 給与・ボーナス・福利厚生など、複数の要因が絡んでくる
● ファネル上の最後のステップなので、ファネルの全体効率を考えると特に重要
Slide 117
Slide 117 text
116
ファネルの最適化
● ファネルを設計したら、実装・運用して「測定」する
○ ATS(Applicant Tracking System) のメタデータを上手く使うのもココ
● 測定は超重要
○ なぜならば、どこに注力すべきか分かるため
○ 会社によって注力する箇所は異なるし、同じ会社でもフェーズによって異なる
○ 唯一の方法は、ファネルに着目をして改善を繰り返すこと
Slide 118
Slide 118 text
117
どこまでファネルを最適化すればいいの？
● ファネルの改善初期は比較的簡単
○ 各フェーズを見渡して投資箇所を決めていく
Slide 119
Slide 119 text
118
どこまでファネルを最適化すればいいの？
● ファネルの改善初期は比較的簡単
○ 各フェーズを見渡して投資箇所を決めていく
● 厄介なのは「各セクションはどこまで高めるのが合理的なのか？」ということ
○ つまり、50%でいいのか、85%まで上げないといけないのか
Slide 120
Slide 120 text
119
どこまでファネルを最適化すればいいの？
● ファネルの改善初期は比較的簡単
○ 各フェーズを見渡して投資箇所を決めていく
● 厄介なのは「各セクションはどこまで高めるのが合理的なのか？」ということ
○ つまり、50%でいいのか、85%まで上げないといけないのか
● ライバル企業の数値があるなら有用な情報になる
○ これがないと、過剰投資 or 過小投資につながる
Slide 121
Slide 121 text
120
ファネルを拡張する
拡張域
https://lethain.com/hiring-funnel/
Slide 122
Slide 122 text
121
ファネルを拡張する方法 (1)
● Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある
● オンボーディング
○ 候補者が入社してからスピードが出てくる（立ち上がる）までにどれぐらい時間がかかるか？
○ 計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない
○ 生産性に関するメトリックを見ると良い
■ 例えば、入社してからP40の生産性を出すまでにかかる時間は？
Slide 123
Slide 123 text
122
ファネルを拡張する方法 (1)
● Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある
● オンボーディング
○ 候補者が入社してからスピードが出てくる（立ち上がる）までにどれぐらい時間がかかるか？
○ 計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない
○ 生産性に関するメトリックを見ると良い
■ 例えば、入社してからP40の生産性を出すまでにかかる時間は？
● 影響・成果
○ 入社してからどのぐらい影響を与えているか？
○ これも計測は簡単じゃないが、先ほどと同じく個人ではなくグループのトレンドを見る
○ 代替指標は、雇用してからの時間に基づくパフォーマンスレートの分布 になるだろう
Slide 124
Slide 124 text
123
ファネルを拡張する方法 (2)
● 昇進
○ 入社してから昇進するまでの時間は？
■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
Slide 125
Slide 125 text
124
ファネルを拡張する方法 (2)
● 昇進
○ 入社してから昇進するまでの時間は？
■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
● 継続率（離職率）
○ 入社したメンバが辞めていないか？
○ これは測定が簡単だが、遅行指標になる
○ 重要なメトリックなので測定すべき
Slide 126
Slide 126 text
125
ファネルを拡張する方法 (2)
● 昇進
○ 入社してから昇進するまでの時間は？
■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
● 継続率（離職率）
○ 入社したメンバが辞めていないか？
○ これは測定が簡単だが、遅行指標になる
○ 重要なメトリックなので測定すべき
● ここまでの数値はセンシティブな数値なので、組織によっては共有を嫌がる
○ それでも構わない。誰かがケアしているのが大切！
Slide 127
Slide 127 text
126
採用面接の評価は難しい
● Cracking the Coding Interviewをパラパラ読んだ人いる？
○ 新しいロールに対する候補者の評価は「雑な科学」だと分かる
○ インタビューの精度に疑問を持っている人がほとんどであり
自信を持って採用できている人はあんまりいない
Slide 128
Slide 128 text
127
採用面接の評価は難しい
● Cracking the Coding Interviewをパラパラ読んだ人いる？
○ 新しいロールに対する候補者の評価は「雑な科学」だと分かる
○ インタビューの精度に疑問を持っている人がほとんどであり
自信を持って採用できている人はあんまりいない
● ただ、ちょっとした構造と創造性によって
公平で一貫したやり方で確度を高められる
Slide 129
Slide 129 text
128
評価を上手くするためのやり方
● メトリクスファースト。データがなければ改善できない
○ 余談：戦略の章でもデータの大事さが出る。データがなければ空中戦になるから
● 今の面接プロセスのパフォーマンスを理解する
○ 例えば
■ ファネルはどうなっているか？どこで落ちている？他社のデータと比較したら？
■ インタビューの結果と、実際の業績は関連している？
■ 特に成功に資する要素はなんだった？
■ インタビューで聞いても役立たない要素は？
● ……
（書籍には、この後も項目が続く。詳しくは原著で）
Slide 130
Slide 130 text
129
ということで
今日紹介したこと
Slide 131
Slide 131 text
130
書籍の全体像とのマッピング
1. 組織
a. チームの4状態と移行方法
2. ツール
a. システム思考、良いゴールと悪いゴール
b. 権威に依存せずに変化を起こす方法、Model→Doc→Share
c. タイムマネジメント
3. アプローチ
a. マネージャーのハマりポイント
4. 文化
a. インクルージョン、機会とメンバーシップ
5. キャリア
a. 採用、採用、採用
6. 付録
Slide 132
Slide 132 text
131
書籍の全体像とのマッピング
1. 組織
a. チームの4状態と移行方法
2. ツール
a. システム思考、良いゴールと悪いゴール
b. 権威に依存せずに変化を起こす方法、Model→Doc→Share
c. タイムマネジメント
3. アプローチ
a. マネージャーのハマりポイント
4. 文化
a. インクルージョン、機会とメンバーシップ
5. キャリア
a. 採用、採用、採用
6. 付録
これで全体の30%ぐらい？
（残りは書籍で）
Slide 133
Slide 133 text
132
おさらい：発表終了時の到達点
● An Elegant Puzzle: Systems of Engineering Management
の書籍に書いてある内容の一部を理解している
おしまい