Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

iwashi
November 16, 2022

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

More Decks by iwashi

Other Decks in Technology

Transcript

  1. An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る (at NTT

    Com TechLunch #158) 2022年11月 NTT コミュニケーションズ 岩瀬 / @iwashi86
  2. 1 発表終了時の到達点 • An Elegant Puzzle: Systems of Engineering Management※

    の書籍に書いてある内容の一部を理解している ※ 岩瀬が2022年に読んだ中で一番学びがあった本
  3. 4 書籍の全体像 1. 組織 - 組織やチームデザイン 2. ツール - システム思考、ツール、変化の起こし方

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

    3. アプローチ - EMが直面する課題と解決法 4. 文化 - 組織文化への取り組み 5. キャリア - 採用、評価、昇進 6. 付録 → 個人的に印象に残った箇所を順不同でかいつまんで紹介します!
  5. 10 チームの状態 https://lethain.com/durably-excellent-teams/ 1. 遅れている状態 ◦ 毎週バックログが伸び続ける。チームメンバーはめちゃくちゃ働くが進捗はいまいち ◦ メンバーの士気は低く、不満が口から出ている 2.

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

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

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

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

    立ち泳ぎ状態 ◦ 必要な仕事はできているが、技術的負債の返済はできず 新しいプロジェクトにも着手できていない ◦ メンバーの士気は[1]に比べ高いが、引き続きかなり働いている 3. 返済可能な状態 ◦ 技術的負債の返済ができている。その結果、さらに返済するための時間が生まれている 4. 革新が起こせる状態 ◦ 技術的負債がほとんどなく、メンバーの士気も高く、新たなユーザーニーズも満たせている どうやって 次の状態に移行するか?
  10. 16 チームの移行方法 https://lethain.com/durably-excellent-teams/ • [1]遅れている状態 -> [2]立ち泳ぎ状態 ◦ [2]に移行できるまで採用する ◦

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

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

    ちょっとした成功を祝う、楽観的な考えを吹き込む • [2] 立ち泳ぎ状態 -> [3] 返済可能な状態 ◦ チームの労力を合わせて、たくさんのことを「終わらせる」。並行して走っている仕事を減らす ◦ チームメンバーの生産性の見方を、個人からチームへと変えていく • [3] 返済可能な状態 -> [4] 革新が起こせる状態 ◦ 負債を返済し始めているので、さらに時間を作れるようにする ▪ ステークホルダーは「時間ができてそうだから、新しい価値を!」となるかもしれないが そこを耐えて [3] -> [2] に戻さないようにする • [4] イノベーションを起こせる状態以降 ◦ Slack!(トムデマルコの書籍を読もう!) ◦ ただし、失敗しがちなのは顧客価値に繋がらないフレームワークの移行への着手など
  13. 20 移行時の注意点 https://lethain.com/durably-excellent-teams/ • それぞれの状態の移行には「時間がかかる」 ◦ システムによっては、数年以上の負債蓄積がある ◦ 逆に言えば、修正に時間がかかるのと同じで 効果が出れば長い時間維持できる

    • 簡単には効果が出ない ◦ 長く時間がかかっても、自分の計画を信頼して維持すること (だから組織をいじったり、新しい仕事を始めずに続けること)
  14. 23 3大ツール + α • システム思考 ◦ 右の書籍を読めばわかる ◦ ストックとフローを用いてシステムで考える

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

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

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

    ◦ 書籍では “LeanとDevOpsの科学” を引用して具体化される • メトリクス ◦ あとで出てくる • ビジョン ◦ (原著参照) • プロダクトマネジメント(思考) ◦ (探索・選択・検証をEM視点から書いてある、詳細は原著) では具体的に どうやって変化を導く?
  18. 29 厄介な問題 • こんな経験は? ◦ ここに問題がありそうだけど、自分は部長でも課長でもなくて 一人の担当者にすぎない ▪ or 新しく配属された部署だと、まだ信頼貯金がない…

    ◦ どうやって解決すればいいんだろう? (岩瀬補足:PdM とかまさにこれ。多くは人事権限がない) • そんな時に(すべてではないが)上手く行った方法がある ◦ それが Model -> Document -> Share
  19. 35 参考:Model→Document→Share と トップダウン のどちらを使えば? • Model → Document →

    Share ◦ 新しい施策を採用する余裕がない ◦ 新しい施策を広めるためのリソースがない ◦ 分散型で意思決定したいトピックである ◦ チームが自律的に採用できる ◦ 徐々に変更が起こってもいい • それぞれに特徴、向き不向きがある
  20. 36 • トップダウン、強制型 ◦ 新しい施策を採用する余裕がある ◦ 新しい施策を広めるためのリソースがある ◦ 中央集権的に決定したいトピックである ◦

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

    組織内で一貫性が必要 ◦ 素早く変更を起こしたい • Model → Document → Share ◦ 新しい施策を採用する余裕がない ◦ 新しい施策を広めるためのリソースがない ◦ 分散型で意思決定したいトピックである ◦ チームが自律的に採用できる ◦ 徐々に変更が起こってもいい • それぞれに特徴、向き不向きがある • Model → Document → Share 型は 組織の価値観があっているときに効果をより発揮しやすい ◦ ただし、同僚からの尊敬など、自然発生するAuthority(信頼貯金)は必要 参考:Model→Document→Share と トップダウン のどちらを使えば?
  22. 43 良いゴールとは? • 次の4つの組み合わせになっているもの ◦ たどり着きたい目標の状態 ◦ 現在のベースライン ◦ 現在のトレンド(現在のベロシティを表している)

    ◦ 時間の区切り • 上記を考慮すると、たとえば ◦ 「3Qでは、フロントページのレンダリング時間を 600ms(p95)から 300ms(p95)にする。  2Qでは、レンダリング時間が 500ms から 600ms に増えてしまっている。」
  23. 46 ゴールのタイプ • ゴールには2つの興味深いタイプがある ◦ 投資:たどり着きたい未来の状態を描くもの ◦ ベースライン:保ち続けたい状態を表すもの • なぜ、2つのタイプを考える必要があるか?

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

    ◦ たとえば、「データパイプラインの処理時間を短くしたい」というゴールは… ▪ 今はp95で6時間かかっているコアバッチジョブを、3Qでp95で3時間以内とする ▪ 2Qを通じて2時間遅くなってしまった • 上記は良いゴールであるが、ちょっと物足りない ◦ なぜならば、クラスタサイズを2倍にすれば明日にでも達成できるから(お金の力で) ◦ 必ずしも悪いわけではないが、別のやり方もある
  25. 55 新任マネージャーのハマりポイント(1) • 部下のやりたい方向にのみマネジメントする ◦ そして、それが顧客や会社の興味とずれている • 反対に上だけにマネジメントする ◦ 上だけを見て、チームをおざなりにする

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

    ◦ 成果は健全なチームから生まれるのにもかかわらず • 上にまったくあげない ◦ チームの成功と認知は、上司との関係に大きく依存するにもかかわらずやらない ◦ 素晴らしい業績は伝わるべき • 部分最適化しすぎ ◦ 会社がサポートできない技術を使ったり 他のチームと競合するプロダクトを作ったりしてしまう
  27. 59 新任マネージャーのハマりポイント(2) • 採用じゃ問題は解決しないと思いこむ ◦ 追われているときは採用じゃなくて、消化活動したくなる ◦ でもビジネスが伸びたら、結局採用が必要になる。採用がだめなら燃え尽きる… • 関係構築に時間を使わない

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

    ◦ チームは顧客が欲しがるものを作ってリリースすることに時間を使う ◦ そのためには社内の人脈が確実に必要 • 自分の役割に固執しすぎる ◦ 効果的なマネージャはチームの”のり”のように振る舞い、チームのギャップを埋めている ◦ そのために役割・スコープを越えて、本当にやるべきことやる必要がある • 上司が人間であることを忘れる ◦ 上司の行為(たとえば大事なことを言い忘れるとか)によって、イライラすることもある ◦ ただ悪意でやってるわけではなく善意でやっている(あやまちを犯すこともある)と考える
  29. 63 経験あるマネージャーのハマりポイント • 前の会社で上手くいったことをやってしまう ◦ 「修正」し始める前に、まず立ち止まって耳を傾けるのが大事 ◦ そうしなければ存在しない問題に取り組んでしまう • 関係構築に時間を使いすぎる

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

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

    ◦ 大きな企業から小さな企業に移ったマネージャにありがち ◦ 小さな企業では、関係構築よりも「実行」(Execution)が大事 • 採用がすべてを解決すると考えてしまう ◦ 採用によって問題を解決できるが、やりすぎると文化が薄まり、かつ人の役割や責務が曖昧になっていく • 委譲ではなく逃げてしまう ◦ 委譲は大事だが、やりすぎて本当にやるべきことから逃げてはダメ • 地に足がつかなくなっている(浮世離れしている) ◦ 大企業でありがちだが、現実から遠い意思決定をしやすくなってしまう (その他、新米でもベテランでもハマるポイント4点は原著参照)
  32. 69 インクルージョン • 書籍ではインクルージョンの2側面について語られている ◦ 機会(Oppotunity)へアクセスできること ▪ (岩瀬補足:NTT-G の各種人事制度が該当) ◦

    メンバーシップ(こっちを紹介) ▪ 会社のグループの一員として感じられること • なお先に、アンチパターン ◦ 上記(特に機会)が限られた人に提供されている状態 ◦ 退職の要因になる
  33. 72 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs

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

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

    (Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的 • コーヒーチャット ◦ 異なるチームからランダムで呼ばれて話す会 • チームでのランチ ◦ 週1回などでランチする会 (儀式的で嫌な人もいる)
  36. 77 メンバーシップにおける注意点 • 前述の活動はシンプルだが そのシンプルさゆえに、考慮すべき事項が埋もれることがある • またどの活動も全員に有効なわけではない ◦ ランチ会といっても複雑な食事制限があるメンバーがいたら? ◦

    運動がある活動だったとして、運動が苦手なメンバーがいたら? ◦ 終業後だとして、子供がいる親だったら? • さまざまな組み合わせで考えること および同僚とアイデアを(小さく)検証するのが大事
  37. 81 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会 • 上手くいかなかったこと

    ◦ 重要な教訓などをびっしり書いた内容の濃いプレゼン ◦ 結果的に出席率も下がり、学習効果も低かった
  38. 83 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする

    ◦ 進め方 ▪ チェックインで20-30秒で名前・所属・考えていることを共有 ▪ プレゼンは短く5分程度、残りはブレイクアウトして ディスカッションする時間に • 盛り上がらないこともあるので、10分程度が良い ▪ ブレイクアウトして戻ったら、学びを相互共有する
  39. 86 タイムマネジメントのコツ (1) • 4半期に一回振り返りする ▪ 時間に何に使ってきたかカテゴリ分けする ▪ ざっくり何に使ったか、それを何に次に四半期に使うか振り返る •

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

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

    シニアになればなるほど(所掌が広がるほど)、責務を持つ重要な仕事を完了しにくくなる ◦ さらに悪いことに、1on1が長期のゴールとぶつかってくる ◦ 最終的には長期のゴールを重要視する • レバレッジの効く小さな仕事を終わらせる ▪ 終わらせればさらに時間ができる • やらないことを決める ▪ ただし、適当にやめるんじゃなくて構造的なやり方でやめる ▪ まず、やらないけど重要な仕事をいくつか見つける ▪ 次に新しくあがってきた組織のリスクとなる仕事を再分類する ▪ で、チームや上司に「これがやれてない」と伝える ← 重要
  42. 90 タイムマネジメントのコツ (2) • 時間を先に割り当てておく ◦ “スキップレベル1on1で全員と毎月30分” と決めると、組織が拡大したときに破綻する ◦ だから時間を先に割り当てておく

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

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

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

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

    ▪ たとえば、毎週2hと決めてその中で対応する • システム・プロセスを作ったら、どこかのタイミングで例外処理も委譲する ◦ 例外対処はマネージャの役割だが、抱えすぎてしまうマネージャも多い ◦ 例外対処はエネルギーを使うので、どこかで別のマネージャに委譲すべき • そのミーティングに出る価値があるか検討する ◦ シニアになるにつれて、ミーティングに呼ばれやすくことがある ◦ そのミーテイングに出ることによって、出なかったときより価値が出せるか考える • ちょっと先の成長を見越して採用する • カレンダーで2時間のブロックを、週にいくつか作る • (それでもだめなら)秘書的なサポートを得る
  47. 99

  48. 106 Identify(候補者を見つける) • 候補者がやってくるソースは大きく分けてインバウンド、ソーシング、リファラルの3つ ◦ スタートアップなどはリファラルに依存しがち ◦ ただ、急成長する企業はすぐにリファラルが枯渇して、ソーシングとインバウンドに依存するようになる • インバウンド(自然流入)

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

    ◦ いわゆるWebサイトから直接応募するケースなどが該当 ◦ 量は多いが、質は低くなりがち • ソーシング ◦ 企業側が積極的に動いて探してくるケースが該当 ◦ Linkedinとか、大学訪問、カンファレンスやミートアップで誘うのもここ ▪ ちなみに別の章で、Linkedinの具体的な運用(スロットルされるまで送るとか)が書いてある • リファーラル ◦ 前職の同僚や、大学の友人をつれてくる方法。小さな会社だと主流 ◦ 3つの内で一番効率がよい
  50. 112 Evaluate(評価する) • その候補者が会社で本当に上手くやっているか見極めるフェーズ ◦ 次の矛盾する3つ観点のバランスを取る必要があるため難解 • 観点 ◦ 確からしさ

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

    ▪ 候補者が会社で成功すると自信をどれだけ持てるか ▪ 離職は士気にかかわるし、上手くやるには時間もかかる ◦ 候補者体験(CX) ▪ 候補者が評価されている間も、心地よい体験を得られるように ▪ 入ってほしい候補者をみつけたとしても、その候補者が興味を失ったら終わり ◦ 効率 ▪ チームの時間と、候補者の時間をいちばん効率よく使いたい ▪ ここでは、候補者と評価者の時間の非対称に注意 • 例えば、候補者が自宅で課題を解くための時間は長くかかるが、その評価は一瞬、はBad
  52. 114 参考:Effective Interiview の7要素 • 候補者に親切に • すべてのインタビュワー(面接官)が 面接対象のRoleの要件について合意している •

    インタビューで「何を」「どうやって」見極めるか理解しておく ◦ 技術についてプレゼンしてもらう、ペアプロ・ペアデバッグする など (なお、著者は単なるアルゴリズム的な質問に否定的) • インタビュー前にしっかり準備する • 候補者に興味を持つ・示す • インタビュー自体にフィードバックループを • ファネルを計測して改善する
  53. 116 ファネルの最適化 • ファネルを設計したら、実装・運用して「測定」する ◦ ATS(Applicant Tracking System) のメタデータを上手く使うのもココ •

    測定は超重要 ◦ なぜならば、どこに注力すべきか分かるため ◦ 会社によって注力する箇所は異なるし、同じ会社でもフェーズによって異なる ◦ 唯一の方法は、ファネルに着目をして改善を繰り返すこと
  54. 121 ファネルを拡張する方法 (1) • Closeで終わらせる以上に、上手くファネルを拡張して活用する方法がある • オンボーディング ◦ 候補者が入社してからスピードが出てくる(立ち上がる)までにどれぐらい時間がかかるか? ◦

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

    計測は簡単じゃないが、個人が対象ではなくグループが対象になるので、少し乱雑でも構わない ◦ 生産性に関するメトリックを見ると良い ▪ 例えば、入社してからP40の生産性を出すまでにかかる時間は? • 影響・成果 ◦ 入社してからどのぐらい影響を与えているか? ◦ これも計測は簡単じゃないが、先ほどと同じく個人ではなくグループのトレンドを見る ◦ 代替指標は、雇用してからの時間に基づくパフォーマンスレートの分布 になるだろう
  56. 124 ファネルを拡張する方法 (2) • 昇進 ◦ 入社してから昇進するまでの時間は? ▪ 組織内で新たなポジションへアクセスできているかどうか理解できる指標にもなる •

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

    継続率(離職率) ◦ 入社したメンバが辞めていないか? ◦ これは測定が簡単だが、遅行指標になる ◦ 重要なメトリックなので測定すべき • ここまでの数値はセンシティブな数値なので、組織によっては共有を嫌がる ◦ それでも構わない。誰かがケアしているのが大切!
  58. 126 採用面接の評価は難しい • Cracking the Coding Interviewをパラパラ読んだ人いる? ◦ 新しいロールに対する候補者の評価は「雑な科学」だと分かる ◦

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

    インタビューの精度に疑問を持っている人がほとんどであり 自信を持って採用できている人はあんまりいない • ただ、ちょっとした構造と創造性によって 公平で一貫したやり方で確度を高められる
  60. 128 評価を上手くするためのやり方 • メトリクスファースト。データがなければ改善できない ◦ 余談:戦略の章でもデータの大事さが出る。データがなければ空中戦になるから • 今の面接プロセスのパフォーマンスを理解する ◦ 例えば

    ▪ ファネルはどうなっているか?どこで落ちている?他社のデータと比較したら? ▪ インタビューの結果と、実際の業績は関連している? ▪ 特に成功に資する要素はなんだった? ▪ インタビューで聞いても役立たない要素は? • …… (書籍には、この後も項目が続く。詳しくは原著で)
  61. 130 書籍の全体像とのマッピング 1. 組織 a. チームの4状態と移行方法 2. ツール a. システム思考、良いゴールと悪いゴール

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

    b. 権威に依存せずに変化を起こす方法、Model→Doc→Share c. タイムマネジメント 3. アプローチ a. マネージャーのハマりポイント 4. 文化 a. インクルージョン、機会とメンバーシップ 5. キャリア a. 採用、採用、採用 6. 付録 これで全体の30%ぐらい? (残りは書籍で)
  63. 132 おさらい:発表終了時の到達点 • An Elegant Puzzle: Systems of Engineering Management

    の書籍に書いてある内容の一部を理解している おしまい