エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門 / Engineering management for the rest of us

https://forkwell.connpass.com/event/325649/ の登壇資料です。

書籍は https://amzn.to/3z8TLUM から

Transcript

1. エンジニアリングが好きな私たちのための エンジニアリングマネジャー入門 2024/8/8
2. 2 発表終了時の到達点 • 「エンジニアリングが好きな私たちのための 　エンジニアリングマネジャー入門」本の全体像を知ること • 書籍で言及される知見の一部を、詳しめに知ること • 書籍を購入したい気持ちになる
3. 3 今日のアジェンダ • 書籍の位置付けを知る • 書籍の全体像を知る • 個別トピックをいくつか抑える
4. 4 • Sarah Drasner氏 (@sarah_edo) • Google社の Director of Engineering, Core Developer Web ◦ 元々は Frontend Developer ref: https://www.linkedin.com/in/sarahdrasner/details/experience/ 著者
5. 5 実践 学術/ 研究 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます
6. 6 実践 学術/ 研究 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 論文（のメタアナリシス） などから導出された知見に 基づく書籍。 様々な組織で使える 可能性がある。
7. 7 実践 学術/ 研究 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 論文（のメタアナリシス） などから導出された知見に 基づく書籍。 様々な組織で使える 可能性がある。 ある特定の企業でうまくいった 経験に基づく書籍。 n=1 に近いため文脈が 近ければかなりハマるかも。
8. 8 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます
9. 9 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 組織設計・戦略・システムなど トップが判断すれば方針が さっと変わるトピック中心
10. 10 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 組織設計・戦略・システムなど トップが判断すれば方針が さっと変わるトピック中心 人の関係性や組織文化など、 「やるぞー」といっても すぐに変わらないトピック中心
11. 11 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます
12. 12 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます
13. 13 実践 学術/ 研究 ハード（組織設計・戦略など） ソフト（人・文化など） 主観に基づく雑マッピング 注：もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます マネジメントに万能薬はない。 また、本書のみで全てを対応できるわけではなく 様々な行動の起点としての利用がおすすめ。
14. 14 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業 ◦ 通信会社で Generative AI Project の リーダー（EMとPdM） • サイドワーク ◦ 早稲田大学で非常勤講師（プログラミング） ◦ Podcaster (fukabori.fm) ◦ 翻訳者
15. 15 全体像
16. 16 書籍の全体像 Part1　自分のチーム Part2　コラボレーション Part3　チームが最高の仕事をできるように支援する Part4　自分の仕事 （厳密な順序性はないので、どこから読んでも大丈夫です）
17. 17 Part1　自分のチーム Chapter1　自分のチームを大切にする Chapter2　価値観の価値 Chapter3　信頼と弱さ Chapter4　自分のチームは「彼ら」ではなく「私たち」 Chapter5　幸せとやる気の原動力 Chapter6　長期的な従業員のケア Chapter7　キャリアラダー Chapter8　重要な1on1
18. 18 Part2　自分のチーム Chapter9　マネジャーとしてのコミュニケーション Chapter10　チェンジマネジメント Chapter11　フィードバックの与え方 Chapter12　フィードバックを受け取る Chapter13　良いミーティング Chapter14　対立のマネジメント Chapter15　クロスチームとオープンソースのコラボレーション
19. 19 Part3　チームが最高の仕事をできるように支援する Chapter16　チームの仕事の優先度付け Chapter17　プルリクエストのスコープを絞る方法 Chapter18　実行の速度 Chapter19　プロダクトとエンジニアリングの時間配分
20. 20 Part4　自分の仕事 Chapter20　ハイレベルでの優先度付け Chapter21　日々の優先度付け Chapter22　境界線を設定する Chapter23　まず自分を大切にすること Chapter24　自分を信じること
21. 21 個別ピックアップ （特に「おっ」と感じた部分） なお “〜” の部分は書籍の引用です
22. 22 価値観ワーク • 人は価値観に沿って判断し、行動している • この価値観をチーム内で共有できていると他者の理解がかなり容易になる
23. 23 価値観ワーク • 人は価値観に沿って判断し、行動している • この価値観をチーム内で共有できていると他者の理解がかなり容易になる • 価値観ワークでは、チームで以下のワードから共感できるものを 3〜5つほどピックアップし、選んだ理由を順番に話ていく 　責任、擁護、自律、思いやり、協力、貢献、創造性、好奇心、・・・ 　（全ての価値観は書籍参照） 　→ 書籍では、何度も何度もこの価値観が言及される
24. 24 会える環境を作りだす • 振り戻しがあるとはいえ、リモート中心の会社も多いし、 ハイブリッドな勤務形態も増えてきている
25. 25 会える環境を作りだす • 振り戻しがあるとはいえ、リモート中心の会社も多いし、 ハイブリッドな勤務形態も増えてきている • 本書では、お互いに顔を合わせる機会の重要性が主張される： “チームメンバーがお互いに会える機会を設けることが必要です。 　フェスティンガー（略）の研究では、アパートの住民間の交友関係について調べており、 　近接性と接触が、お互いの信頼関係の形成に貢献していることがわかりました。（略） 　たとえ、表面上はすぐに明らかでなかったとしても、 　一緒に過ごす時間が長いほど、類似点も多く見つかるでしょう。”
26. 26 プライベートスペースの重要性 • コミュニケーションの「透明性」を重視する企業がある e.g. できるだけpublic ch で
27. 27 プライベートスペースの重要性 • コミュニケーションの「透明性」を重視する企業がある e.g. できるだけpublic ch で • 本書では、オープンとプライベートとのバランスを取ることが大事と主張： “すべての雑談やチャットをオープンにしたがる企業もたくさんありますが、 　私は多くのリモートチームをマネジメントしてきた経験から、 　チームが自分たちだけの場所を持つことが重要だと考えるようになりました。”
28. 28 主語は「私たち」 • マネジャーによるチームの語り方によって、 周囲やチーム、自分へ多大な影響がある
29. 29 主語は「私たち」 • マネジャーによるチームの語り方によって、 周囲やチーム、自分へ多大な影響がある • どちらのパターン？ ◦ 「幹部がこう決めたから、少なくとも3つ機能を出す必要があります。 　だから実現方法を考えないといけないようです。」
30. 30 主語は「私たち」 • マネジャーによるチームの語り方によって、 周囲やチーム、自分へ多大な影響がある • どちらのパターン？ ◦ 「幹部がこう決めたから、少なくとも3つ機能を出す必要があります。 　だから実現方法を考えないといけないようです。」 ◦ 「次の四半期で重要なOKRの一つが登録者数の倍増です。 　そのために試算したところ、3つ機能をリリースすれば 　KRを達成できるとわかりました。 　だから、実現に向けて私たちでできることを話し合いましょう」
31. 31 フロー状態 • チクセントミハイが命名した状態のこと ◦ 人が完全に活動に没頭して、ただ一つの作業や課題に集中 ◦ 多くの人が「最も幸せ」と報告 • この状態に入ると「不満への耐性が高まる」
32. 32 フロー状態 • チクセントミハイが命名した状態のこと ◦ 人が完全に活動に没頭して、ただ一つの作業や課題に集中 ◦ 多くの人が「最も幸せ」と報告 • この状態に入ると「不満への耐性が高まる」 • マネジャーとして、部下に「フロー状態に入れ」と 無理にいっても作れるものじゃない → ではどうするか？
33. 33 フロー状態ができるかぎり存在する環境を作る • 仕事の前提・目的が合っていること （そもそも意義が分からないとダラダラ作業するだけ）
34. 34 フロー状態ができるかぎり存在する環境を作る • 仕事の前提・目的が合っていること （そもそも意義が分からないとダラダラ作業するだけ） • 仕事が困難ではあるが、不可能ではないこと （簡単すぎてもダメということ）
35. 35 フロー状態ができるかぎり存在する環境を作る • 仕事の前提・目的が合っていること （そもそも意義が分からないとダラダラ作業するだけ） • 仕事が困難ではあるが、不可能ではないこと （簡単すぎてもダメということ） • 同僚やチームで一体感があり、お互いをサポートし合っていること （これがないと、恐怖の中で仕事をすることに）
36. 36 フロー状態ができるかぎり存在する環境を作る • 仕事の前提・目的が合っていること （そもそも意義が分からないとダラダラ作業するだけ） • 仕事が困難ではあるが、不可能ではないこと （簡単すぎてもダメということ） • 同僚やチームで一体感があり、お互いをサポートし合っていること （これがないと、恐怖の中で仕事をすることに） • 頑張った結果として、給与・ボーナス・昇進が得られること （外発的動機だが、これがなければ頑張る意味が減る人も） その他に書籍では4-5個が紹介されているがここでは略
37. 37 ネガティブバイアス • 人の脳に自然に備わっているバイアス • たとえば、ストーブで手をやけどしたら、同じ過ちを繰り返さないよう 脳が強く印象づけておく。
38. 38 ネガティブバイアス • 人の脳に自然に備わっているバイアス • たとえば、ストーブで手をやけどしたら、同じ過ちを繰り返さないよう 脳が強く印象づけておく。 このとき悪い記憶と良い記憶が両方あると 自然と悪い記憶をより頻繁に呼び起こしてしまう。 → どうやって立ち向かうか？
39. 39 ネガティブバイアスへの立ち向かい方 • 事実を確認する
40. 40 ネガティブバイアスへの立ち向かい方 • 事実を確認する • ポジティブな要素に集うようにする ◦ ミラーニューロンの働きを活用する
41. 41 ネガティブバイアスへの立ち向かい方 • 事実を確認する • ポジティブな要素に集うようにする ◦ ミラーニューロンの働きを活用する • 結果を見直す ◦ 「もうだめだ」「チームが解体される！」と話しても あまり生産的にではない ◦ むしろ、起きるリスクを、話す/話してもらって整理したほうがいい
42. 42 1on1 • 1on1は不確実性を減らして、明確化するための良い機会 • そのための方法：
43. 43 1on1 • 1on1は不確実性を減らして、明確化するための良い機会 • そのための方法： ◦ 優先度付け ▪ 部下の仕事が多すぎる場合に、最重要なことを話し合う
44. 44 1on1 • 1on1は不確実性を減らして、明確化するための良い機会 • そのための方法： ◦ 優先度付け ▪ 部下の仕事が多すぎる場合に、最重要なことを話し合う ◦ アクションアイテムの作成 ▪ タスクが大きすぎる場合に分解・整理を支援する
45. 45 1on1 • 1on1は不確実性を減らして、明確化するための良い機会 • そのための方法： ◦ 優先度付け ▪ 部下の仕事が多すぎる場合に、最重要なことを話し合う ◦ アクションアイテムの作成 ▪ タスクが大きすぎる場合に分解・整理を支援する ◦ ビジョンの明確化 ▪ 何のための仕事なのか腹落ちしていないかもしれないため その仕事の必要性を伝える
46. 46 口を出さない • マネジャーの仕事は “何かを成し遂げるための戦術的詳細ではなく、 　成果に向けてみんなの足並みを揃えることです。 　「実現方法」は彼ら次第です。”
47. 47 口を出さない • マネジャーの仕事は “何かを成し遂げるための戦術的詳細ではなく、 　成果に向けてみんなの足並みを揃えることです。 　「実現方法」は彼ら次第です。” • これがめちゃくちゃ難しい！エンジニア上がりの場合は特に！ おそらくアーキテクチャや、開発方法には何かしらの 「こだわり」があるはず！
48. 48 口を出さない② • 口を出したくなるかもしれないが、 “実際には得意領域やフレームワークを熟知している 　非常に有能で知的なチームに質問をしなければなりません”
49. 49 口を出さない② • 口を出したくなるかもしれないが、 “実際には得意領域やフレームワークを熟知している 　非常に有能で知的なチームに質問をしなければなりません” • たとえば “このAPI定義は、ユーザーに提供できる最高のものになっていますか？” →“質問の答えはチームに任せています”
50. 50 何かを定着させるためには「繰り返し」が必要 • よくある課題：発信内容が伝わってないんだけど？🤔
51. 51 何かを定着させるためには「繰り返し」が必要 • よくある課題：発信内容が伝わってないんだけど？🤔 • コツは「同じメッセージを別の方法で伝えること」 たとえば： ◦ SlackやTeamsでのコメントで ◦ ビデオ会議で口頭で ◦ ドキュメントで
52. 52 「透明性を重視する」？ • よく使われる言葉であり、カッコイイ言葉
53. 53 「透明性を重視する」？ • よく使われる言葉であり、カッコイイ言葉 • ただ本当は 「他者が情報を隠していることを見たくない」　という意図なのでは？
54. 54 「透明性を重視する」？ • よく使われる言葉であり、カッコイイ言葉 • ただ本当は 「他者が情報を隠していることを見たくない」　という意図なのでは？ • 透明性は信頼を築くために非常に重要 ◦ リーダーに求められる透明性は人によって異なる ◦ また、透明の中には「有害なものもある」 ▪ 例：うわさ話、非生産的な愚痴　など → では、どこまで話せばいいのだろう？
55. 55 （話す/話さないの）境界線を引く “「他の人やグループにこの発言を聞かれても恥ずかしくないだろうか？」 　「言及されている当事者には、このフィードバックを直接伝えたか？」” • この質問に答えられるかどうかで著者は境界線を引いている
56. 56 チェンジマネジメントと透明性 • 良い方向への変化は確実に必要 ◦ そのためにチェンジマネジメントを行う ◦ そこで必要なのものが文化（だが今日は割愛）
57. 57 チェンジマネジメントと透明性 • 良い方向への変化は確実に必要 ◦ そのためにチェンジマネジメントを行う ◦ そこで必要なのものが文化（だが今日は割愛） • チェンジマネジメントの注意点の一つ ◦ 「不公平な意思決定」がなされたと解釈されると プライベートなチャネルやチャットで炎上する ◦ これは理由が理解されなかったり、意思決定のプロセスが 完全に不透明であると、「何かが隠されている」と感じて起こる
58. 58 フィードバックを与える前に • フィードバックの受け取り方の好みは人によって異なる • そこで、相手の価値観に応じて フィードバックを受け取りたい方法を事前に聞いておく
59. 59 フィードバックを与える前に • フィードバックの受け取り方の好みは人によって異なる • そこで、相手の価値観に応じて フィードバックを受け取りたい方法を事前に聞いておく • チームビルディングでの例：
60. 60 フィードバックをもらう • マネジャー/リーダーとして成長するための方法の一つが フィードバックをもらうこと
61. 61 フィードバックをもらう • マネジャー/リーダーとして成長するための方法の一つが フィードバックをもらうこと • そのために ◦ 匿名のフィードバックフォームを送る ▪ 正直な意見を求めやすい
62. 62 フィードバックをもらう • マネジャー/リーダーとして成長するための方法の一つが フィードバックをもらうこと • そのために ◦ 匿名のフィードバックフォームを送る ▪ 正直な意見を求めやすい ◦ 特定のプロジェクトや出来事についてのフィードバックを求める ▪ フィードバックが具体的になりやすい ▪ ただし、自分の意見を整理する時間のための沈黙を恐れない
63. 63 フィードバックをもらう • マネジャー/リーダーとして成長するための方法の一つが フィードバックをもらうこと • そのために ◦ 匿名のフィードバックフォームを送る ▪ 正直な意見を求めやすい ◦ 特定のプロジェクトや出来事についてのフィードバックを求める ▪ フィードバックが具体的になりやすい ▪ ただし、自分の意見を整理する時間のための沈黙を恐れない ◦ 1on1 でフィードバックを求める ▪ その際は、事前に伝えておいたほうがびっくりさせずにすむ
64. 64 なぜ、気まずいミーティングに？ • 目的・アジェンダを伝えても、 「あれ、なんか気まずかった」というミーティングは起こる • なぜか？
65. 65 なぜ、気まずいミーティングに？ • 目的・アジェンダを伝えても、 「あれ、なんか気まずかった」というミーティングは起こる • なぜか？ ◦ お互いをよく知らない
66. 66 なぜ、気まずいミーティングに？ • 目的・アジェンダを伝えても、 「あれ、なんか気まずかった」というミーティングは起こる • なぜか？ ◦ お互いをよく知らない ◦ 人が多すぎる、または適切な人がいない ▪ そもそも招待しなくていい ▪ 誰かの感情を傷つけるのが怖いなら、おそらく役割と責任が不明瞭
67. 67 なぜ、気まずいミーティングに？ • 目的・アジェンダを伝えても、 「あれ、なんか気まずかった」というミーティングは起こる • なぜか？ ◦ お互いをよく知らない ◦ 人が多すぎる、または適切な人がいない ▪ そもそも招待しなくていい ▪ 誰かの感情を傷つけるのが怖いなら、おそらく役割と責任が不明瞭 ◦ みんなが言わないことがある（🐘 in the room) ▪ いちばん有害なパターン ▪ 著者は口火を切って意見を求める
68. 68 良いミーティングには DRI を • DRI: Directly Responsible Individual ◦ DRIはプロジェクトやタスクの成功に対しての最終的な結果に責任を負う
69. 69 良いミーティングには DRI を • DRI: Directly Responsible Individual ◦ DRIはプロジェクトやタスクの成功に対しての最終的な結果に責任を負う “なぜDRIが必要なのでしょうか？ 　全員の意見を聞きたいと思っていても、最終的には決断を下さなければならず、 　ソフトウェア開発（そして人生）には 　必ずしも真の答えが一つだけとは限らないことがたくさんあります。”
70. 70 良いミーティングには DRI を • DRI: Directly Responsible Individual ◦ DRIはプロジェクトやタスクの成功に対しての最終的な結果に責任を負う “なぜDRIが必要なのでしょうか？ 　全員の意見を聞きたいと思っていても、最終的には決断を下さなければならず、 　ソフトウェア開発（そして人生）には 　必ずしも真の答えが一つだけとは限らないことがたくさんあります。” • みんなで意思決定を下さない（DRIとそうでない人は発言権が異なる）
71. 71 偽りの調和 • 何かを提案したときに ①（しばらく黙ってから）「なるほど、いいですね・・・」 ②「XとYという理由で反対です。」
72. 72 偽りの調和 • 何かを提案したときに ①（しばらく黙ってから）「なるほど、いいですね・・・」 ②「XとYという理由で反対です。」 • ①は、偽りの調和と呼ばれている状態 ◦ 同意しているように見えて、口をつぐんでいるかもしれない ◦ あるいは、発言することのコストが分からないのかもしれない
73. 73 偽りの調和 • 何かを提案したときに ①（しばらく黙ってから）「なるほど、いいですね・・・」 ②「XとYという理由で反対です。」 • ①は、偽りの調和と呼ばれている状態 ◦ 同意しているように見えて、口をつぐんでいるかもしれない ◦ あるいは、発言することのコストが分からないのかもしれない • ②の方が健全であり、良い成果につながる ◦ 職位が上がるに連れて現場の問題のコアから遠ざかる ◦ 問題の真実を知るためには、みんなに頼る必要性が増す
74. 74 メトリクスの限界 • エンジニアリングのメトリクスでずるい方法でハックできる ◦ 小さなissueをたくさんクローズする ◦ 簡単なPRをたくさん出す ◦ （もちろん健全なものもたくさんある） • 重要なのは、ビジネスにとって正しいことに取り組んでいるかどうか
75. 75 メトリクスの限界 • エンジニアリングのメトリクスでずるい方法でハックできる ◦ 小さなissueをたくさんクローズする ◦ 簡単なPRをたくさん出す ◦ （もちろん健全なものもたくさんある） • 重要なのは、ビジネスにとって正しいことに取り組んでいるかどうか “メトリクスは、異常値について話し合ったり、ケイデンスを把握したり、 　時間の経過とともにより正確な作業見積もりを得るために、 　非常に価値があります。”
76. 76 MVPの危険性 • MVP(Minimum Viable Product) の概念が業界標準に • そのMVPには危険性が2つある（ここでは1つだけ紹介）
77. 77 MVPの危険性 • MVP(Minimum Viable Product) の概念が業界標準に • そのMVPには危険性が2つある（ここでは1つだけ紹介） “完璧になるまでリリースを待つと、チームが燃え尽き、利益を失い、 　市場投入が遅れることになります。
78. 78 MVPの危険性 • MVP(Minimum Viable Product) の概念が業界標準に • そのMVPには危険性が2つある（ここでは1つだけ紹介） “完璧になるまでリリースを待つと、チームが燃え尽き、利益を失い、 　市場投入が遅れることになります。 　中途半端にリリースすると、対象顧客の信頼を失い、 　あなたがプロダクトが完成したと思っても、彼らは戻ってこないでしょう。” 　 → つまり、あまりにもショボイと、もう使ってくれない
79. 79 プロダクトとエンジニアリングの時間配分 • プロダクトとエンジニアリング（リファクタなど）の 時間配分をどうすればいいのか？ ◦ 「80%:20%」「50%:50%」と宣言しておく？ • 宣言したからと言って、そのまま使えるわけじゃない（外部変化など） • ではどうするか？
80. 80 プロダクトとエンジニアリングの時間配分 • プロダクトとエンジニアリング（リファクタなど）の 時間配分をどうすればいいのか？ ◦ 「80%:20%」「50%:50%」と宣言しておく？ • 宣言したからと言って、そのまま使えるわけじゃない（外部変化など） • ではどうするか？ ◦ ステークホルダーに共有可能な1枚の資料を共有 ▪ タスクの内容・性質、所要時間、重要性 ◦ （その他の方法は書籍で）
81. 81 まとめ
82. 82 本日お話ししたこと • 書籍の位置付け ◦ 実践寄り x ソフト寄り • 書籍の全体像を知る ◦ Part1〜4 の概要 • 個別トピックをいくつか抑える ◦ 1on1 や フィードバック、透明性など
83. 83 発表終了時の到達点 • 「エンジニアリングが好きな私たちのための 　エンジニアリングマネジャー入門」本の全体像を知ること • 書籍で言及される知見の一部を、詳しめに知ること • 書籍を購入したい気持ちになる