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