An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る / Learn roughly "An Elegant Puzzle: Systems of Engineering Management" in 50 minutes

NTT Communications の社内ランチ勉強会 (TechLunch) で講演した資料です。

Transcript

1. An Elegant Puzzle:
   Systems of Engineering Management
   を50分でざっと知る
   (at NTT Com TechLunch #158)
   2022年11月
   NTT コミュニケーションズ 岩瀬 / @iwashi86
   

   View Slide

2. 1
   発表終了時の到達点
   ● An Elegant Puzzle: Systems of Engineering Management※
   の書籍に書いてある内容の一部を理解している
   ※ 岩瀬が2022年に読んだ中で一番学びがあった本
   

   View Slide

3. 2
   著者
   ● Will larson氏 (@lethain)
   ● Uber社のシニアエンジニアリングマネージャーや
   Stripe社のエンジニア組織のHeadを歴任して
   現在はCalm社のCTO
   ● Hacker News にブログポストがよく載っており
   IT界隈の著名人の1人
   

   View Slide

4. 3
   どんな本？
   ● 実際にEMや、EMを束ねるHeadとして活動してきた
   著者の知見がまとまっている書籍
   ● 実践的なプラクティスや考え方が多く掲載される
   ○ 研究による裏付けがメインという類の書籍ではない
   

   View Slide

5. 4
   書籍の全体像
   1. 組織 - 組織やチームデザイン
   2. ツール - システム思考、ツール、変化の起こし方
   3. アプローチ - EMが直面する課題と解決法
   4. 文化 - 組織文化への取り組み
   5. キャリア - 採用、評価、昇進
   6. 付録
   

   View Slide

6. 5
   書籍の全体像
   1. 組織 - 組織やチームデザイン
   2. ツール - システム思考、ツール、変化の起こし方
   3. アプローチ - EMが直面する課題と解決法
   4. 文化 - 組織文化への取り組み
   5. キャリア - 採用、評価、昇進
   6. 付録
   → 個人的に印象に残った箇所を順不同でかいつまんで紹介します！
   

   View Slide

7. 6
   本題
   

   View Slide

8. 7
   チームの状態と移行
   https://unsplash.com/photos/E9PJO_vL3E8
   

   View Slide

9. 8
   チームの状態（次のページで説明）
   https://lethain.com/durably-excellent-teams/　より
   

   View Slide

10. 9
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    

    View Slide

11. 10
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    2. 立ち泳ぎ状態
    ○ 必要な仕事はできているが、技術的負債の返済はできず
    新しいプロジェクトにも着手できていない
    ○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
    

    View Slide

12. 11
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    2. 立ち泳ぎ状態
    ○ 必要な仕事はできているが、技術的負債の返済はできず
    新しいプロジェクトにも着手できていない
    ○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
    3. 返済可能な状態
    ○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
    

    View Slide

13. 12
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    2. 立ち泳ぎ状態
    ○ 必要な仕事はできているが、技術的負債の返済はできず
    新しいプロジェクトにも着手できていない
    ○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
    3. 返済可能な状態
    ○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
    4. 革新が起こせる状態
    ○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
    

    View Slide

14. 13
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    2. 立ち泳ぎ状態
    ○ 必要な仕事はできているが、技術的負債の返済はできず
    新しいプロジェクトにも着手できていない
    ○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
    3. 返済可能な状態
    ○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
    4. 革新が起こせる状態
    ○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
    さて今、
    ご自身のチームは
    どの状態にいますか？
    （心の中で考えよう）
    

    View Slide

15. 14
    チームの状態
    https://lethain.com/durably-excellent-teams/
    1. 遅れている状態
    ○ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち
    ○ メンバーの士気は低く、不満が口から出ている
    2. 立ち泳ぎ状態
    ○ 必要な仕事はできているが、技術的負債の返済はできず
    新しいプロジェクトにも着手できていない
    ○ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている
    3. 返済可能な状態
    ○ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている
    4. 革新が起こせる状態
    ○ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている
    どうやって
    次の状態に移行するか？
    

    View Slide

16. 15
    チームの移行方法
    https://lethain.com/durably-excellent-teams/
    ● [1]遅れている状態 -> [2]立ち泳ぎ状態
    ○ [2]に移行できるまで採用する　←　ヘッドカウントで諦めるマネージャも多いが頑張りどころ
    ○ ちょっとした成功を祝う、楽観的な考えを吹き込む
    

    View Slide

17. 16
    チームの移行方法
    https://lethain.com/durably-excellent-teams/
    ● [1]遅れている状態 -> [2]立ち泳ぎ状態
    ○ [2]に移行できるまで採用する
    ○ ちょっとした成功を祝う、楽観的な考えを吹き込む
    ● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
    ○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
    ○ チームメンバーの生産性の見方を、個人からチームへと変えていく
    

    View Slide

18. 17
    チームの移行方法
    https://lethain.com/durably-excellent-teams/
    ● [1]遅れている状態 -> [2]立ち泳ぎ状態
    ○ [2]に移行できるまで採用する
    ○ ちょっとした成功を祝う、楽観的な考えを吹き込む
    ● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
    ○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
    ○ チームメンバーの生産性の見方を、個人からチームへと変えていく
    ● [3] 返済可能な状態 -> [4] 革新が起こせる状態
    ○ 負債を返済し始めているので、さらに時間を作れるようにする
    ■ ステークホルダーは「時間ができてそうだから、新しい価値を！」となるかもしれないが
    そこを耐えて [3] -> [2] に戻さないようにする
    

    View Slide

19. 18
    チームの移行方法
    https://lethain.com/durably-excellent-teams/
    ● [1]遅れている状態 -> [2]立ち泳ぎ状態
    ○ [2]に移行できるまで採用する
    ○ ちょっとした成功を祝う、楽観的な考えを吹き込む
    ● [2] 立ち泳ぎ状態 -> [3] 返済可能な状態
    ○ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす
    ○ チームメンバーの生産性の見方を、個人からチームへと変えていく
    ● [3] 返済可能な状態 -> [4] 革新が起こせる状態
    ○ 負債を返済し始めているので、さらに時間を作れるようにする
    ■ ステークホルダーは「時間ができてそうだから、新しい価値を！」となるかもしれないが
    そこを耐えて [3] -> [2] に戻さないようにする
    ● [4] イノベーションを起こせる状態以降
    ○ Slack！（トムデマルコの書籍を読もう！）
    ○ ただし、失敗しがちなのは顧客価値に繋がらないフレームワークの移行への着手など
    

    View Slide

20. 19
    移行時の注意点
    https://lethain.com/durably-excellent-teams/
    ● それぞれの状態の移行には「時間がかかる」
    ○ システムによっては、数年以上の負債蓄積がある
    ○ 逆に言えば、修正に時間がかかるのと同じで
    効果が出れば長い時間維持できる
    

    View Slide

21. 20
    移行時の注意点
    https://lethain.com/durably-excellent-teams/
    ● それぞれの状態の移行には「時間がかかる」
    ○ システムによっては、数年以上の負債蓄積がある
    ○ 逆に言えば、修正に時間がかかるのと同じで
    効果が出れば長い時間維持できる
    ● 簡単には効果が出ない
    ○ 長く時間がかかっても、自分の計画を信頼して維持すること
    （だから組織をいじったり、新しい仕事を始めずに続けること）
    

    View Slide

22. 21
    （変化を効果的に導く）
    ツール
    https://unsplash.com/photos/sm0Bkoj5bnA
    

    View Slide

23. 22
    3大ツール + α
    ● システム思考
    ○ 右の書籍を読めばわかる
    ○ ストックとフローを用いてシステムで考える
    ○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
    

    View Slide

24. 23
    3大ツール + α
    ● システム思考
    ○ 右の書籍を読めばわかる
    ○ ストックとフローを用いてシステムで考える
    ○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
    ● メトリクス
    ○ あとで出てくる
    

    View Slide

25. 24
    3大ツール + α
    ● システム思考
    ○ 右の書籍を読めばわかる
    ○ ストックとフローを用いてシステムで考える
    ○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
    ● メトリクス
    ○ あとで出てくる
    ● ビジョン
    ○ （原著参照）
    

    View Slide

26. 25
    3大ツール + α
    ● システム思考
    ○ 右の書籍を読めばわかる
    ○ ストックとフローを用いてシステムで考える
    ○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
    ● メトリクス
    ○ あとで出てくる
    ● ビジョン
    ○ （原著参照）
    ● プロダクトマネジメント（思考）
    ○ （探索・選択・検証をEM視点から書いてある、詳細は原著）
    

    View Slide

27. 26
    3大ツール + α
    ● システム思考
    ○ 右の書籍を読めばわかる
    ○ ストックとフローを用いてシステムで考える
    ○ 書籍では “LeanとDevOpsの科学” を引用して具体化される
    ● メトリクス
    ○ あとで出てくる
    ● ビジョン
    ○ （原著参照）
    ● プロダクトマネジメント（思考）
    ○ （探索・選択・検証をEM視点から書いてある、詳細は原著）
    では具体的に
    どうやって変化を導く？
    

    View Slide

28. 27
    （権威に依存しない）
    リーダーシップ
    https://unsplash.com/photos/6U5AEmQIajg
    

    View Slide

29. 28
    厄介な問題
    ● こんな経験は？
    ○ ここに問題がありそうだけど、自分は部長でも課長でもなくて
    一人の担当者にすぎない
    ■ or 新しく配属された部署だと、まだ信頼貯金がない…
    ○ どうやって解決すればいいんだろう？
    （岩瀬補足：PdM とかまさにこれ。多くは人事権限がない）
    

    View Slide

30. 29
    厄介な問題
    ● こんな経験は？
    ○ ここに問題がありそうだけど、自分は部長でも課長でもなくて
    一人の担当者にすぎない
    ■ or 新しく配属された部署だと、まだ信頼貯金がない…
    ○ どうやって解決すればいいんだろう？
    （岩瀬補足：PdM とかまさにこれ。多くは人事権限がない）
    ● そんな時に（すべてではないが）上手く行った方法がある
    ○ それが Model -> Document -> Share
    

    View Slide

31. 30
    https://lethain.com/model-document-share/
    

    View Slide

32. 31
    Model
    ● 月次などでチームの健康状態やスループットを計測する
    ○ 例：タスクサイズを軽量に測定
    ● 大事なのは変化を加える前のベースライン（基準値）を知ること
    

    View Slide

33. 32
    Model
    ● 月次などでチームの健康状態やスループットを計測する
    ○ 例：タスクサイズを軽量に測定
    ● 大事なのは変化を加える前のベースライン（基準値）を知ること
    ● おおっぴらに宣伝するのではなく、「ちょっとした実験だよ」
    といった意味づけではじめて、しばらく続ける
    ○ ダメだったらやめればいい
    ● 一定、効果が出てくると感じたら…
    

    View Slide

34. 33
    Document
    ● 次の内容を文書化する
    ○ 解決しようとしている問題
    ○ 試行から学んだこと
    ○ 他のチームで採用（再現）するための方法の詳細
    ■ 可能な限り詳しく、汎化して
    ■ 他のチームに新規メンバが入っても理解できるように
    

    View Slide

35. 34
    Share
    ● 短いメールでドキュメントを配布する
    ○ この時自分の経験談も入れておく
    ● 「採用してください！」とは言わない
    ○ 単に方法を紹介するだけでいい
    ● 奇妙なことに著者の経験からいえば、
    トップダウン・強制型のアプローチよりも採用率が高い
    

    View Slide

36. 35
    参考：Model→Document→Share と トップダウン のどちらを使えば？
    ● Model → Document → Share
    ○ 新しい施策を採用する余裕がない
    ○ 新しい施策を広めるためのリソースがない
    ○ 分散型で意思決定したいトピックである
    ○ チームが自律的に採用できる
    ○ 徐々に変更が起こってもいい
    ● それぞれに特徴、向き不向きがある
    

    View Slide

37. 36
    ● トップダウン、強制型
    ○ 新しい施策を採用する余裕がある
    ○ 新しい施策を広めるためのリソースがある
    ○ 中央集権的に決定したいトピックである
    ○ 組織内で一貫性が必要
    ○ 素早く変更を起こしたい
    ● Model → Document → Share
    ○ 新しい施策を採用する余裕がない
    ○ 新しい施策を広めるためのリソースがない
    ○ 分散型で意思決定したいトピックである
    ○ チームが自律的に採用できる
    ○ 徐々に変更が起こってもいい
    ● それぞれに特徴、向き不向きがある
    参考：Model→Document→Share と トップダウン のどちらを使えば？
    

    View Slide

38. 37
    ● トップダウン、強制型
    ○ 新しい施策を採用する余裕がある
    ○ 新しい施策を広めるためのリソースがある
    ○ 中央集権的に決定したいトピックである
    ○ 組織内で一貫性が必要
    ○ 素早く変更を起こしたい
    ● Model → Document → Share
    ○ 新しい施策を採用する余裕がない
    ○ 新しい施策を広めるためのリソースがない
    ○ 分散型で意思決定したいトピックである
    ○ チームが自律的に採用できる
    ○ 徐々に変更が起こってもいい
    ● それぞれに特徴、向き不向きがある
    ● Model → Document → Share 型は
    組織の価値観があっているときに効果をより発揮しやすい
    ○ ただし、同僚からの尊敬など、自然発生するAuthority(信頼貯金)は必要
    参考：Model→Document→Share と トップダウン のどちらを使えば？
    

    View Slide

39. 38
    良いゴールと悪いゴール
    https://unsplash.com/photos/M1-7VLtyLbo
    

    View Slide

40. 39
    ゴールを話すタイミング
    ● ゴールを話すタイミングがいつやってくるか？
    ○ どの会社、どの部門であっても
    マネジメントのスコープが広がるにつれて、すべてを理解するのは困難に
    ○ そのときにゴール（What）について話すことで
    やり方（How）を分離して議論できる
    →　これが、言うは易く行うは難し
    

    View Slide

41. 40
    悪いゴールとは？
    ● 数字だけになっているもの
    ○ たとえば
    ■ 「ビルド時間の50パーセンタイルが2秒以下になること」
    ■ 「9つのプロジェクトを終わらせること」
    ● なぜ、上記が悪いのか？
    

    View Slide

42. 41
    悪いゴールとは？
    ● 数字だけになっているもの
    ○ たとえば
    ■ 「ビルド時間の50パーセンタイルが2秒以下になること」
    ■ 「9つのプロジェクトを終わらせること」
    ● なぜ、上記が悪いのか？
    ○ それが野心的なゴールなのか、重要なのかわからないから
    

    View Slide

43. 42
    良いゴールとは？
    ● 次の4つの組み合わせになっているもの
    ○ たどり着きたい目標の状態
    ○ 現在のベースライン
    ○ 現在のトレンド（現在のベロシティを表している）
    ○ 時間の区切り
    

    View Slide

44. 43
    良いゴールとは？
    ● 次の4つの組み合わせになっているもの
    ○ たどり着きたい目標の状態
    ○ 現在のベースライン
    ○ 現在のトレンド（現在のベロシティを表している）
    ○ 時間の区切り
    ● 上記を考慮すると、たとえば
    ○ 「3Qでは、フロントページのレンダリング時間を 600ms(p95)から 300ms(p95)にする。
    　2Qでは、レンダリング時間が 500ms から 600ms に増えてしまっている。」
    

    View Slide

45. 44
    良いゴールである、と判断するためには？
    ● シンプルな２つのテスト質問の組合せによって可能
    ○ 質問：
    ■ その領域に詳しくない誰かが難しさについてある程度わかるかどうか
    ■ うまく行った場合に評価できるかどうか
    ● 前述の4つの観点を含められていれば、おそらくこの2つの指標を満たしている
    

    View Slide

46. 45
    ゴールのタイプ
    ● ゴールには2つの興味深いタイプがある
    ○ 投資：たどり着きたい未来の状態を描くもの
    ○ ベースライン：保ち続けたい状態を表すもの
    ● なぜ、2つのタイプを考える必要があるか？
    

    View Slide

47. 46
    ゴールのタイプ
    ● ゴールには2つの興味深いタイプがある
    ○ 投資：たどり着きたい未来の状態を描くもの
    ○ ベースライン：保ち続けたい状態を表すもの
    ● なぜ、2つのタイプを考える必要があるか？
    ○ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは…
    ■ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする
    ■ 2Qを通じて2時間遅くなってしまった
    

    View Slide

48. 47
    ゴールのタイプ
    ● ゴールには2つの興味深いタイプがある
    ○ 投資：たどり着きたい未来の状態を描くもの
    ○ ベースライン：保ち続けたい状態を表すもの
    ● なぜ、2つのタイプを考える必要があるか？
    ○ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは…
    ■ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする
    ■ 2Qを通じて2時間遅くなってしまった
    ● 上記は良いゴールであるが、ちょっと物足りない
    ○ なぜならば、クラスタサイズを2倍にすれば明日にでも達成できるから（お金の力で）
    ○ 必ずしも悪いわけではないが、別のやり方もある
    

    View Slide

49. 48
    そこで相殺目標
    ● 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する
    ○ すなわち、相殺目標（相反する目標）を設定する
    

    View Slide

50. 49
    そこで相殺目標
    ● 前述の問題回避のために、ベースラインのメトリクスを含めてゴール設計する
    ○ すなわち、相殺目標（相反する目標）を設定する
    ● たとえば、先ほどの例に対する相殺目標は
    ○ コアバッチ処理の効率は 1GB 0.05$ を超えてはいけない
    ○ パイプラインを利用しているチームに対して
    アラートを今より増やしてはいけない（今は週2回発生している）　など
    

    View Slide

51. 50
    相殺目標の効果
    ● ベースラインのメトリクスにより解決策を絞り込め
    かつアクセルを踏むタイミングを制御できる
    ○ 例：新機能に向けていい感じに進んでいる。
    　　でも、信頼性がベースラインより下回ったら、優先度を変えよう
    ○ （岩瀬補足：エラーバジェット、SLI、SLOの概念に似ている）
    

    View Slide

52. 51
    相殺目標の効果
    ● ベースラインのメトリクスにより解決策を絞り込め
    かつアクセルを踏むタイミングを制御できる
    ○ 例：新機能に向けていい感じに進んでいる。
    　　でも、信頼性がベースラインより下回ったら、優先度を変えよう
    ○ （岩瀬補足：エラーバジェット、SLI、SLOの概念に似ている）
    ● ただ、これは必須じゃない
    ○ たとえば、投資目標が達成するなら、10%は許容できるかもしれない
    ○ トレードオフを事前に明確に考えておくのが大事
    

    View Slide

53. 52
    マネージャーが
    ハマるポイント
    https://unsplash.com/photos/-Cmz06-0btw
    

    View Slide

54. 53
    新任マネージャーのハマりポイント(1)
    ● 部下のやりたい方向にのみマネジメントする
    ○ そして、それが顧客や会社の興味とずれている
    

    View Slide

55. 54
    新任マネージャーのハマりポイント(1)
    ● 部下のやりたい方向にのみマネジメントする
    ○ そして、それが顧客や会社の興味とずれている
    ● 反対に上だけにマネジメントする
    ○ 上だけを見て、チームをおざなりにする
    ○ 成果は健全なチームから生まれるのにもかかわらず
    

    View Slide

56. 55
    新任マネージャーのハマりポイント(1)
    ● 部下のやりたい方向にのみマネジメントする
    ○ そして、それが顧客や会社の興味とずれている
    ● 反対に上だけにマネジメントする
    ○ 上だけを見て、チームをおざなりにする
    ○ 成果は健全なチームから生まれるのにもかかわらず
    ● 上にまったくあげない
    ○ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない
    ○ 素晴らしい業績は伝わるべき
    

    View Slide

57. 56
    新任マネージャーのハマりポイント(1)
    ● 部下のやりたい方向にのみマネジメントする
    ○ そして、それが顧客や会社の興味とずれている
    ● 反対に上だけにマネジメントする
    ○ 上だけを見て、チームをおざなりにする
    ○ 成果は健全なチームから生まれるのにもかかわらず
    ● 上にまったくあげない
    ○ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない
    ○ 素晴らしい業績は伝わるべき
    ● 部分最適化しすぎ
    ○ 会社がサポートできない技術を使ったり
    他のチームと競合するプロダクトを作ったりしてしまう
    

    View Slide

58. 57
    新任マネージャーのハマりポイント(2)
    ● 採用じゃ問題は解決しないと思いこむ
    ○ 追われているときは採用じゃなくて、消化活動したくなる
    ○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
    

    View Slide

59. 58
    新任マネージャーのハマりポイント(2)
    ● 採用じゃ問題は解決しないと思いこむ
    ○ 追われているときは採用じゃなくて、消化活動したくなる
    ○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
    ● 関係構築に時間を使わない
    ○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
    ○ そのためには社内の人脈が確実に必要
    

    View Slide

60. 59
    新任マネージャーのハマりポイント(2)
    ● 採用じゃ問題は解決しないと思いこむ
    ○ 追われているときは採用じゃなくて、消化活動したくなる
    ○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
    ● 関係構築に時間を使わない
    ○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
    ○ そのためには社内の人脈が確実に必要
    ● 自分の役割に固執しすぎる
    ○ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている
    ○ そのために役割・スコープを越えて、本当にやるべきことやる必要がある
    

    View Slide

61. 60
    新任マネージャーのハマりポイント(2)
    ● 採用じゃ問題は解決しないと思いこむ
    ○ 追われているときは採用じゃなくて、消化活動したくなる
    ○ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる…
    ● 関係構築に時間を使わない
    ○ チームは顧客が欲しがるものを作ってリリースすることに時間を使う
    ○ そのためには社内の人脈が確実に必要
    ● 自分の役割に固執しすぎる
    ○ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている
    ○ そのために役割・スコープを越えて、本当にやるべきことやる必要がある
    ● 上司が人間であることを忘れる
    ○ 上司の行為（たとえば大事なことを言い忘れるとか）によって、イライラすることもある
    ○ ただ悪意でやってるわけではなく善意でやっている（あやまちを犯すこともある）と考える
    

    View Slide

62. 61
    経験あるマネージャーのハマりポイント
    ● 前の会社で上手くいったことをやってしまう
    ○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
    ○ そうしなければ存在しない問題に取り組んでしまう
    

    View Slide

63. 62
    経験あるマネージャーのハマりポイント
    ● 前の会社で上手くいったことをやってしまう
    ○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
    ○ そうしなければ存在しない問題に取り組んでしまう
    ● 関係構築に時間を使いすぎる
    ○ 大きな企業から小さな企業に移ったマネージャにありがち
    ○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
    

    View Slide

64. 63
    経験あるマネージャーのハマりポイント
    ● 前の会社で上手くいったことをやってしまう
    ○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
    ○ そうしなければ存在しない問題に取り組んでしまう
    ● 関係構築に時間を使いすぎる
    ○ 大きな企業から小さな企業に移ったマネージャにありがち
    ○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
    ● 採用がすべてを解決すると考えてしまう
    ○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
    

    View Slide

65. 64
    経験あるマネージャーのハマりポイント
    ● 前の会社で上手くいったことをやってしまう
    ○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
    ○ そうしなければ存在しない問題に取り組んでしまう
    ● 関係構築に時間を使いすぎる
    ○ 大きな企業から小さな企業に移ったマネージャにありがち
    ○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
    ● 採用がすべてを解決すると考えてしまう
    ○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
    ● 委譲ではなく逃げてしまう
    ○ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ
    

    View Slide

66. 65
    経験あるマネージャーのハマりポイント
    ● 前の会社で上手くいったことをやってしまう
    ○ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事
    ○ そうしなければ存在しない問題に取り組んでしまう
    ● 関係構築に時間を使いすぎる
    ○ 大きな企業から小さな企業に移ったマネージャにありがち
    ○ 小さな企業では、関係構築よりも「実行」（Execution）が大事
    ● 採用がすべてを解決すると考えてしまう
    ○ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく
    ● 委譲ではなく逃げてしまう
    ○ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ
    ● 地に足がつかなくなっている（浮世離れしている）
    ○ 大企業でありがちだが、現実から遠い意思決定をしやすくなってしまう
    （その他、新米でもベテランでもハマるポイント4点は原著参照）
    

    View Slide

67. 66
    インクルージョン
    https://unsplash.com/photos/ZFXZ_xMYTZs
    

    View Slide

68. 67
    インクルージョン
    ● 書籍ではインクルージョンの2側面について語られている
    ○ 機会（Oppotunity）へアクセスできること
    ■ （岩瀬補足：NTT-G の各種人事制度が該当）
    

    View Slide

69. 68
    インクルージョン
    ● 書籍ではインクルージョンの2側面について語られている
    ○ 機会（Oppotunity）へアクセスできること
    ■ （岩瀬補足：NTT-G の各種人事制度が該当）
    ○ メンバーシップ（こっちを紹介）
    ■ 会社のグループの一員として感じられること
    

    View Slide

70. 69
    インクルージョン
    ● 書籍ではインクルージョンの2側面について語られている
    ○ 機会（Oppotunity）へアクセスできること
    ■ （岩瀬補足：NTT-G の各種人事制度が該当）
    ○ メンバーシップ（こっちを紹介）
    ■ 会社のグループの一員として感じられること
    ● なお先に、アンチパターン
    ○ 上記（特に機会）が限られた人に提供されている状態
    ○ 退職の要因になる
    

    View Slide

71. 70
    メンバーシップを高めるために良かったこと
    ● 業務時間中に開催される週次の定例イベント
    ○ 任意で誰でも参加できる
    ○ 論文読み会や読書会が該当
    

    View Slide

72. 71
    メンバーシップを高めるために良かったこと
    ● 業務時間中に開催される週次の定例イベント
    ○ 任意で誰でも参加できる
    ○ 論文読み会や読書会が該当
    ● ERGs (Employee Resource Groups)
    ○ 共通の属性・背景を持つメンバが集まる機会
    

    View Slide

73. 72
    メンバーシップを高めるために良かったこと
    ● 業務時間中に開催される週次の定例イベント
    ○ 任意で誰でも参加できる
    ○ 論文読み会や読書会が該当
    ● ERGs (Employee Resource Groups)
    ○ 共通の属性・背景を持つメンバが集まる機会
    ● チームでのオフサイト
    ○ 4半期に1回立ち止まってふりかえる
    ○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
    ■ 特にマネージャーの集まりで効果的
    

    View Slide

74. 73
    メンバーシップを高めるために良かったこと
    ● 業務時間中に開催される週次の定例イベント
    ○ 任意で誰でも参加できる
    ○ 論文読み会や読書会が該当
    ● ERGs (Employee Resource Groups)
    ○ 共通の属性・背景を持つメンバが集まる機会
    ● チームでのオフサイト
    ○ 4半期に1回立ち止まってふりかえる
    ○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
    ■ 特にマネージャーの集まりで効果的
    ● コーヒーチャット
    ○ 異なるチームからランダムで呼ばれて話す会
    

    View Slide

75. 74
    メンバーシップを高めるために良かったこと
    ● 業務時間中に開催される週次の定例イベント
    ○ 任意で誰でも参加できる
    ○ 論文読み会や読書会が該当
    ● ERGs (Employee Resource Groups)
    ○ 共通の属性・背景を持つメンバが集まる機会
    ● チームでのオフサイト
    ○ 4半期に1回立ち止まってふりかえる
    ○ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように
    ■ 特にマネージャーの集まりで効果的
    ● コーヒーチャット
    ○ 異なるチームからランダムで呼ばれて話す会
    ● チームでのランチ
    ○ 週1回などでランチする会　（儀式的で嫌な人もいる）
    

    View Slide

76. 75
    メンバーシップにおける注意点
    ● 前述の活動はシンプルだが
    そのシンプルさゆえに、考慮すべき事項が埋もれることがある
    

    View Slide

77. 76
    メンバーシップにおける注意点
    ● 前述の活動はシンプルだが
    そのシンプルさゆえに、考慮すべき事項が埋もれることがある
    ● またどの活動も全員に有効なわけではない
    ○ ランチ会といっても複雑な食事制限があるメンバーがいたら？
    ○ 運動がある活動だったとして、運動が苦手なメンバーがいたら？
    ○ 終業後だとして、子供がいる親だったら？
    

    View Slide

78. 77
    メンバーシップにおける注意点
    ● 前述の活動はシンプルだが
    そのシンプルさゆえに、考慮すべき事項が埋もれることがある
    ● またどの活動も全員に有効なわけではない
    ○ ランチ会といっても複雑な食事制限があるメンバーがいたら？
    ○ 運動がある活動だったとして、運動が苦手なメンバーがいたら？
    ○ 終業後だとして、子供がいる親だったら？
    ● さまざまな組み合わせで考えること
    および同僚とアイデアを（小さく）検証するのが大事
    

    View Slide

79. 78
    メンバーシップの測定メトリクス
    ● リテンションレート
    ● リファラルレート（コホートによる）
    ● 出席率
    ● コーヒーチャットの開催数　など
    

    View Slide

80. 79
    学習コミュニティ　
    https://unsplash.com/photos/XkKCui44iM0
    

    View Slide

81. 80
    Community of Learning - 上手くいかなかったこと
    ● いわゆるEMコミュニティでの勉強会
    

    View Slide

82. 81
    Community of Learning - 上手くいかなかったこと
    ● いわゆるEMコミュニティでの勉強会
    ● 上手くいかなかったこと
    ○ 重要な教訓などをびっしり書いた内容の濃いプレゼン
    ○ 結果的に出席率も下がり、学習効果も低かった
    

    View Slide

83. 82
    Community of Learning - 上手くいったこと
    ● 上手く行ったアプローチ
    ○ 主催者は講師ではなく、互いの学びをファシリテートする
    

    View Slide

84. 83
    Community of Learning - 上手くいったこと
    ● 上手く行ったアプローチ
    ○ 主催者は講師ではなく、互いの学びをファシリテートする
    ○ 進め方
    ■ チェックインで20-30秒で名前・所属・考えていることを共有
    ■ プレゼンは短く5分程度、残りはブレイクアウトして
    ディスカッションする時間に
    ● 盛り上がらないこともあるので、10分程度が良い
    ■ ブレイクアウトして戻ったら、学びを相互共有する
    

    View Slide

85. 84
    タイムマネジメント
    （コツがいっぱいある）
    https://unsplash.com/photos/xLs4XSQmxtE
    

    View Slide

86. 85
    タイムマネジメントのコツ (1)
    ● ４半期に一回振り返りする
    ■ 時間に何に使ってきたかカテゴリ分けする
    ■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
    

    View Slide

87. 86
    タイムマネジメントのコツ (1)
    ● ４半期に一回振り返りする
    ■ 時間に何に使ってきたかカテゴリ分けする
    ■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
    ● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
    ○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
    ○ 最終的には長期のゴールを重要視する
    

    View Slide

88. 87
    タイムマネジメントのコツ (1)
    ● ４半期に一回振り返りする
    ■ 時間に何に使ってきたかカテゴリ分けする
    ■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
    ● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
    ○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
    ○ 最終的には長期のゴールを重要視する
    ● レバレッジの効く小さな仕事を終わらせる
    ■ 終わらせればさらに時間ができる
    

    View Slide

89. 88
    タイムマネジメントのコツ (1)
    ● ４半期に一回振り返りする
    ■ 時間に何に使ってきたかカテゴリ分けする
    ■ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る
    ● シニアになればなるほど（所掌が広がるほど）、責務を持つ重要な仕事を完了しにくくなる
    ○ さらに悪いことに、1on1が長期のゴールとぶつかってくる
    ○ 最終的には長期のゴールを重要視する
    ● レバレッジの効く小さな仕事を終わらせる
    ■ 終わらせればさらに時間ができる
    ● やらないことを決める
    ■ ただし、適当にやめるんじゃなくて構造的なやり方でやめる
    ■ まず、やらないけど重要な仕事をいくつか見つける
    ■ 次に新しくあがってきた組織のリスクとなる仕事を再分類する
    ■ で、チームや上司に「これがやれてない」と伝える　←　重要
    

    View Slide

90. 89
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    

    View Slide

91. 90
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    ● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
    ○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
    ○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
    

    View Slide

92. 91
    余談：組織デザインと例外処理
    ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
    各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
    人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
    この分業と調整の工夫が集積されたものが組織デザインである。”
    

    View Slide

93. 92
    余談：組織デザインと例外処理
    ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
    各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
    人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
    この分業と調整の工夫が集積されたものが組織デザインである。”
    ● 調整を行うための方法に標準化とヒエラルキーがある
    

    View Slide

94. 93
    余談：組織デザインと例外処理
    ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
    各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
    人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
    この分業と調整の工夫が集積されたものが組織デザインである。”
    ● 調整を行うための方法に標準化とヒエラルキーがある
    ● 標準化とは、いちいち問い合わせしなくていいように
    プロセスを事前に決めておくこと
    

    View Slide

95. 94
    余談：組織デザインと例外処理
    ”様々な経済性を求めて分業が行われる。しかし分業を行うと、各人の活動を調整、
    各人の努力が最終的なアウトプットにまとまるように統合しなければならない。
    人々の活動を調整し、最終的なアウトプットへと統合していくために多様な工夫が施される。
    この分業と調整の工夫が集積されたものが組織デザインである。”
    ● 調整を行うための方法に標準化とヒエラルキーがある
    ● 標準化とは、いちいち問い合わせしなくていいように
    プロセスを事前に決めておくこと
    ● ただし、どうしてもプロセスにハマらない例外事象が出てくる
    ○ そこでヒエラルキーを作って、例外処理を管理者が担う
    ○ （ただ、これはエネルギーを消耗するよ、という話）
    

    View Slide

96. 95
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    ● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
    ○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
    ○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
    ● そのミーティングに出る価値があるか検討する
    ○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
    ○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
    

    View Slide

97. 96
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    ● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
    ○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
    ○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
    ● そのミーティングに出る価値があるか検討する
    ○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
    ○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
    ● ちょっと先の成長を見越して採用する
    

    View Slide

98. 97
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    ● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
    ○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
    ○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
    ● そのミーティングに出る価値があるか検討する
    ○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
    ○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
    ● ちょっと先の成長を見越して採用する
    ● カレンダーで2時間のブロックを、週にいくつか作る
    

    View Slide

99. 98
    タイムマネジメントのコツ (2)
    ● 時間を先に割り当てておく
    ○ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する
    ○ だから時間を先に割り当てておく
    ■ たとえば、毎週2hと決めてその中で対応する
    ● システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する
    ○ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い
    ○ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき
    ● そのミーティングに出る価値があるか検討する
    ○ シニアになるにつれて、ミーティングに呼ばれやすくことがある
    ○ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える
    ● ちょっと先の成長を見越して採用する
    ● カレンダーで2時間のブロックを、週にいくつか作る
    ● （それでもだめなら）秘書的なサポートを得る
    

    View Slide

100. View Slide

101. 100
     週7hぐらい
     1on1している
     

     View Slide

102. 101
     週4hぐらい
     採用面接してる
     

     View Slide

103. 102
     採用
     https://unsplash.com/photos/fY8Jr4iuPQM
     

     View Slide

104. 103
     採用ファネル全体像
     https://lethain.com/hiring-funnel/
     

     View Slide

105. 104
     Identify（候補者を見つける）
     ● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
     ○ スタートアップなどはリファラルに依存しがち
     ○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
     

     View Slide

106. 105
     Identify（候補者を見つける）
     ● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
     ○ スタートアップなどはリファラルに依存しがち
     ○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
     ● インバウンド（自然流入）
     ○ いわゆるWebサイトから直接応募するケースなどが該当
     ○ 量は多いが、質は低くなりがち
     

     View Slide

107. 106
     Identify（候補者を見つける）
     ● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
     ○ スタートアップなどはリファラルに依存しがち
     ○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
     ● インバウンド（自然流入）
     ○ いわゆるWebサイトから直接応募するケースなどが該当
     ○ 量は多いが、質は低くなりがち
     ● ソーシング
     ○ 企業側が積極的に動いて探してくるケースが該当
     ○ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ
     ■ ちなみに別の章で、Linkedinの具体的な運用（スロットルされるまで送るとか）が書いてある
     

     View Slide

108. 107
     Identify（候補者を見つける）
     ● 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ
     ○ スタートアップなどはリファラルに依存しがち
     ○ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる
     ● インバウンド（自然流入）
     ○ いわゆるWebサイトから直接応募するケースなどが該当
     ○ 量は多いが、質は低くなりがち
     ● ソーシング
     ○ 企業側が積極的に動いて探してくるケースが該当
     ○ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ
     ■ ちなみに別の章で、Linkedinの具体的な運用（スロットルされるまで送るとか）が書いてある
     ● リファーラル
     ○ 前職の同僚や、大学の友人をつれてくる方法。小さな会社だと主流
     ○ 3つの内で一番効率がよい
     

     View Slide

109. 108
     Motivate（応募する気持ちになってもらう）
     ● 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある
     ○ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨
     ○ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため
     

     View Slide

110. 109
     Motivate（応募する気持ちになってもらう）
     ● 候補者が見つかったら、インタビューに来てもらえるようにモチベートする必要がある
     ○ この時点で、会社にあまり情熱がない人をフィルターする方法もあるが、非推奨
     ○ むしろ、本当は情熱があったとしても、その表現が下手な人をフィルターしてしまうため
     ● このフェーズで効果的なこと
     ○ 候補者と一緒に過ごす時間を増やす
     ■ コーヒーを一緒にのんだり、取り組んでいるプロジェクトについて話したり
     お互いから学べることを楽しむ
     ○ 正直に、ちょっとだけ楽観的に、ロールについて明確に定義して話す
     

     View Slide

111. 110
     Evaluate（評価する）
     ● その候補者が会社で本当に上手くやっているか見極めるフェーズ
     ○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
     

     View Slide

112. 111
     Evaluate（評価する）
     ● その候補者が会社で本当に上手くやっているか見極めるフェーズ
     ○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
     ● 観点
     ○ 確からしさ
     ■ 候補者が会社で成功すると自信をどれだけ持てるか
     ■ 離職は士気にかかわるし、上手くやるには時間もかかる
     

     View Slide

113. 112
     Evaluate（評価する）
     ● その候補者が会社で本当に上手くやっているか見極めるフェーズ
     ○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
     ● 観点
     ○ 確からしさ
     ■ 候補者が会社で成功すると自信をどれだけ持てるか
     ■ 離職は士気にかかわるし、上手くやるには時間もかかる
     ○ 候補者体験（CX）
     ■ 候補者が評価されている間も、心地よい体験を得られるように
     ■ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり
     

     View Slide

114. 113
     Evaluate（評価する）
     ● その候補者が会社で本当に上手くやっているか見極めるフェーズ
     ○ 次の矛盾する3つ観点のバランスを取る必要があるため難解
     ● 観点
     ○ 確からしさ
     ■ 候補者が会社で成功すると自信をどれだけ持てるか
     ■ 離職は士気にかかわるし、上手くやるには時間もかかる
     ○ 候補者体験（CX）
     ■ 候補者が評価されている間も、心地よい体験を得られるように
     ■ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり
     ○ 効率
     ■ チームの時間と、候補者の時間をいちばん効率よく使いたい
     ■ ここでは、候補者と評価者の時間の非対称に注意
     ● 例えば、候補者が自宅で課題を解くための時間は長くかかるが、その評価は一瞬、はBad
     

     View Slide

115. 114
     参考：Effective Interiview の7要素
     ● 候補者に親切に
     ● すべてのインタビュワー（面接官）が
     面接対象のRoleの要件について合意している
     ● インタビューで「何を」「どうやって」見極めるか理解しておく
     ○ 技術についてプレゼンしてもらう、ペアプロ・ペアデバッグする　など
     （なお、著者は単なるアルゴリズム的な質問に否定的）
     ● インタビュー前にしっかり準備する
     ● 候補者に興味を持つ・示す
     ● インタビュー自体にフィードバックループを
     ● ファネルを計測して改善する
     

     View Slide

116. 115
     Close（内定承諾）
     ● Motivateのフェーズに似ている
     ○ ただ、1日費やす代わりに、数年を費やしてもらうかもしれない意思決定になる
     ○ 給与・ボーナス・福利厚生など、複数の要因が絡んでくる
     ● ファネル上の最後のステップなので、ファネルの全体効率を考えると特に重要
     

     View Slide

117. 116
     ファネルの最適化
     ● ファネルを設計したら、実装・運用して「測定」する
     ○ ATS(Applicant Tracking System) のメタデータを上手く使うのもココ
     ● 測定は超重要
     ○ なぜならば、どこに注力すべきか分かるため
     ○ 会社によって注力する箇所は異なるし、同じ会社でもフェーズによって異なる
     ○ 唯一の方法は、ファネルに着目をして改善を繰り返すこと
     

     View Slide

118. 117
     どこまでファネルを最適化すればいいの？
     ● ファネルの改善初期は比較的簡単
     ○ 各フェーズを見渡して投資箇所を決めていく
     

     View Slide

119. 118
     どこまでファネルを最適化すればいいの？
     ● ファネルの改善初期は比較的簡単
     ○ 各フェーズを見渡して投資箇所を決めていく
     ● 厄介なのは「各セクションはどこまで高めるのが合理的なのか？」ということ
     ○ つまり、50%でいいのか、85%まで上げないといけないのか
     

     View Slide

120. 119
     どこまでファネルを最適化すればいいの？
     ● ファネルの改善初期は比較的簡単
     ○ 各フェーズを見渡して投資箇所を決めていく
     ● 厄介なのは「各セクションはどこまで高めるのが合理的なのか？」ということ
     ○ つまり、50%でいいのか、85%まで上げないといけないのか
     ● ライバル企業の数値があるなら有用な情報になる
     ○ これがないと、過剰投資 or 過小投資につながる
     

     View Slide

121. 120
     ファネルを拡張する
     拡張域
     https://lethain.com/hiring-funnel/
     

     View Slide

122. 121
     ファネルを拡張する方法 (1)
     ● Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある
     ● オンボーディング
     ○ 候補者が入社してからスピードが出てくる（立ち上がる）までにどれぐらい時間がかかるか？
     ○ 計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない
     ○ 生産性に関するメトリックを見ると良い
     ■ 例えば、入社してからP40の生産性を出すまでにかかる時間は？
     

     View Slide

123. 122
     ファネルを拡張する方法 (1)
     ● Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある
     ● オンボーディング
     ○ 候補者が入社してからスピードが出てくる（立ち上がる）までにどれぐらい時間がかかるか？
     ○ 計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない
     ○ 生産性に関するメトリックを見ると良い
     ■ 例えば、入社してからP40の生産性を出すまでにかかる時間は？
     ● 影響・成果
     ○ 入社してからどのぐらい影響を与えているか？
     ○ これも計測は簡単じゃないが、先ほどと同じく個人ではなくグループのトレンドを見る
     ○ 代替指標は、雇用してからの時間に基づくパフォーマンスレートの分布　になるだろう
     

     View Slide

124. 123
     ファネルを拡張する方法 (2)
     ● 昇進
     ○ 入社してから昇進するまでの時間は？
     ■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
     

     View Slide

125. 124
     ファネルを拡張する方法 (2)
     ● 昇進
     ○ 入社してから昇進するまでの時間は？
     ■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
     ● 継続率（離職率）
     ○ 入社したメンバが辞めていないか？
     ○ これは測定が簡単だが、遅行指標になる
     ○ 重要なメトリックなので測定すべき
     

     View Slide

126. 125
     ファネルを拡張する方法 (2)
     ● 昇進
     ○ 入社してから昇進するまでの時間は？
     ■ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる
     ● 継続率（離職率）
     ○ 入社したメンバが辞めていないか？
     ○ これは測定が簡単だが、遅行指標になる
     ○ 重要なメトリックなので測定すべき
     ● ここまでの数値はセンシティブな数値なので、組織によっては共有を嫌がる
     ○ それでも構わない。誰かがケアしているのが大切！
     

     View Slide

127. 126
     採用面接の評価は難しい
     ● Cracking the Coding Interviewをパラパラ読んだ人いる？
     ○ 新しいロールに対する候補者の評価は「雑な科学」だと分かる
     ○ インタビューの精度に疑問を持っている人がほとんどであり
     自信を持って採用できている人はあんまりいない
     

     View Slide

128. 127
     採用面接の評価は難しい
     ● Cracking the Coding Interviewをパラパラ読んだ人いる？
     ○ 新しいロールに対する候補者の評価は「雑な科学」だと分かる
     ○ インタビューの精度に疑問を持っている人がほとんどであり
     自信を持って採用できている人はあんまりいない
     ● ただ、ちょっとした構造と創造性によって
     公平で一貫したやり方で確度を高められる
     

     View Slide

129. 128
     評価を上手くするためのやり方
     ● メトリクスファースト。データがなければ改善できない
     ○ 余談：戦略の章でもデータの大事さが出る。データがなければ空中戦になるから
     ● 今の面接プロセスのパフォーマンスを理解する
     ○ 例えば
     ■ ファネルはどうなっているか？どこで落ちている？他社のデータと比較したら？
     ■ インタビューの結果と、実際の業績は関連している？
     ■ 特に成功に資する要素はなんだった？
     ■ インタビューで聞いても役立たない要素は？
     ● ……
     （書籍には、この後も項目が続く。詳しくは原著で）
     

     View Slide

130. 129
     ということで
     今日紹介したこと
     

     View Slide

131. 130
     書籍の全体像とのマッピング
     1. 組織
     a. チームの4状態と移行方法
     2. ツール
     a. システム思考、良いゴールと悪いゴール
     b. 権威に依存せずに変化を起こす方法、Model→Doc→Share
     c. タイムマネジメント
     3. アプローチ
     a. マネージャーのハマりポイント
     4. 文化
     a. インクルージョン、機会とメンバーシップ
     5. キャリア
     a. 採用、採用、採用
     6. 付録
     

     View Slide

132. 131
     書籍の全体像とのマッピング
     1. 組織
     a. チームの4状態と移行方法
     2. ツール
     a. システム思考、良いゴールと悪いゴール
     b. 権威に依存せずに変化を起こす方法、Model→Doc→Share
     c. タイムマネジメント
     3. アプローチ
     a. マネージャーのハマりポイント
     4. 文化
     a. インクルージョン、機会とメンバーシップ
     5. キャリア
     a. 採用、採用、採用
     6. 付録
     これで全体の30%ぐらい？
     （残りは書籍で）
     

     View Slide

133. 132
     おさらい：発表終了時の到達点
     ● An Elegant Puzzle: Systems of Engineering Management
     の書籍に書いてある内容の一部を理解している
     おしまい
     

     View Slide