はいさい！しまぶだよ。
というわけで、「エンジニアリングマネージャー お悩み相談室」を読みました。
図書館でがーっと読んで、ノートにメモを取りながら進めたのですが、これがなかなか参考になる、刺さる内容が多くてですね、せっかくなので読書ログとしてまとめておこうと思います。
Xでもつぶやいていた。
この本を読んで得たもの
まず、自分なりに大きく3つにまとめてみました。
EMというのは翻訳者である
- POとエンジニア、営業(Biz)とエンジニア、事業とエンジニア...と様々な組み合わせ
- 違う職種間に橋をかける
- このへんをひっくるめると、けっきょくのところ「人」に立ち返る（気がしている）
- 人の考えを理解して、言語化して、また人に伝える
この本を通してずっと出てくるのが 翻訳者 というワードです。自分もEMとして日々やっていることって、まさにこれのような気がしています。違う職種間の言葉を変換して伝えたり、そもそも人は違うものだから変換して伝えないといけない。結局のところ「人と人をつなぐ」ことに尽きるんだなぁと改めて思いました。
推論のはしごを活用する
- 人の考えを理解する、伝えるという所で「推論のはしご」をうまく活用できるとよさそう
- 情報を埋めずに勝手に推測していることはよくある
- そんなつもりはなかったのに...とか
- 直接話してやっと誤解がとけるみたいな
- われわれは勝手に推測してしまっている
これ、めちゃくちゃ心当たりがあります。ただ見えているものだけを見て、勝手に解釈して、勝手に結論出してしまうやつ。それで変な誤解を生んだりするやつ。自分もやりがちだし、メンバーがそうなっているときにサポートする側としても知っておきたい考え方だなと。
求め合う
- これはこの記事でも書いた
- 求め合える組織が強いと思っている
馴れ合いじゃなくて「求め合う」。お互いに尊重しつつも、期待をちゃんと口に出す。衝突を恐れない。これができるチームは強いと思っています。
求め合おう2026。
読書メモ
ここからはメモです。気になったところをざっと書き出しています。
目標づくりの基本
- アジャイルチームによる目標づくりのガイドブック がある（インセプションデッキ、OKR）（P8）
- この本はたしか持っているはずなので読もう
- OODAループ
- 観察(Observe) → 状況判断(Orient) → 意思決定(Decide) → 行動(Act)
- TDDと同じ構造（P9）
OODAループとTDDの構造が一緒っていうのは面白い気づきでした。
EMとしての覚悟
- エンジニアの帽子を脱ぐ覚悟が必要（P11）
- マネージャーの仕事は「決断すること」と「周囲を巻き込むこと」（P13）
1on1の設計
- 目標や期待値のすり合わせの場（P15）
- 自分がサポートできること。出来ないことは他の人につなぐ
- ガイドラインが必要!! 聞くべき項目
- 今取り組んでいること
- よかったこと、うまくいったこと
- 足りないこと、改善したいこと
- モヤモヤしていること、気になっていること
- もちろん話したいことがあるのなら、重点的に話したいことを聞く
- 特になければガイドラインに沿って上から。全部話さなくてもよいというスタンスで。
EMは翻訳者
- PdM ↔ Engineer 間の橋渡し役（P17）
- 早めに情報を共有する（P18）
チームの目標設定プロセス
- 現在地を明らかにする
- 目的地を定める
- 現在地を常に更新する
定量を取る
↓
定量 ⇔ 定性の双方で確認するための質問ができる → 説得力につながる
チームの成長を加速させる
- チームの成果を社内外に発表する（P23）
- 月1回、個人のふり返りを発表（P24）
- 1on1は「ジャッジの場」ではないことを明確に。サポートの場（P25）
- チームの調子が良いのであれば、次の目的は少し先（3歩先）を置いてみる（P26）
- チームの目標は Must と Will の両面から考える（P32）
- 個人の問題をチームの問題へ昇華させる
- 特性表を作り「目標を引き出す」（P37）
パフォーマンスの最大化
- チームのパフォーマンスを最大化することがマネージャーの仕事・責任（P53）
- チームが自力で判断して動ける環境を整備する
- 自分の実力をチームの天井にしない
「自分の実力をチームの天井にしない」、これはけっこうグサッときました。
直近自覚はしていて、自分より上手に出来る人がいるのならどんどん委譲していこうと思っていて、それはやれているかな。
自分にしかやれないこと、自分が得意なことをやっていこうと思いました。
自己開示とチーム結束
- そのタスクの大切さを伝える（P55）
- 自分のトリセツを用意する（P71）
- 弱みや悩みを自己開示 → 結束力のあるチームへ
情報の伝え方
- 自分の言葉で説明できるように情報を取りに行く（P91）
- メンバーへは、メンバーが知りたいことと交差させて伝える
情報は自分の言葉で伝えられるように。これ大事。
馴れ合いからの脱却
- 「馴れ合い」から「求め合う」チームへ（P101）
- お互いに尊重しつつも、横の可能性や期待をお互い口に出す。衝突も辞さない。
これはほんとうにそうで、よく言われる「心理的安全性」は馴れ合いの場ではないと自分は思っています。
想像力と感情の切り分け
- 必要なのは共感ではなく想像力（P113）
- 事実と感情を切り分ける（P114）
推論のはしご
- 「推論のはしご」を一段ずつ降りるのをサポートする（P116）
- 不満は結果 → 裏側には感情がある → 事実をどのように見て解釈したのか
- 情報を埋めずに勝手に推測しているかもしれない
- テクニック
- ミラーリング（オウム返し）、バックトラッキング（同じ言葉をちょっと替えて相手に返す → ちょっと違うとなったら深ぼる）
意思決定
満点の答えは出せなくても、これが最善という着地点を見つける。みんなが納得するものなどない。
意思決定の根拠をオープンにすることが重要。
フィードバック
- 相手にNoを突きつけるのではなく、「行動に対しての認識を互いにすり合わせる」（P127）
- フィードバックを日常に溶けこます（P131）
- 感謝や困りごとを気軽に投げかけ合う
感謝をデイリースタンドアップで投げかけ合うのは真似したいなと思った。
説得と折り合い
- 説得すること、納得してもらうことをゴールとしない（P141）
- これは肝に銘じよう
- 折り合えるポイントを探す
技術的成果の伝え方
- 技術的な成果をビジネスの言葉に翻訳する（P149）
- ビジネスの価値として伝える。当初の期待値をどれくらい上回ったか。
- コンディションシートの利用（P153）
- メンバーの動きをメモしたもの
- 振り返りのフォーマット例（P155）
- 相手は否定したいんじゃなく、別の深い理解を得るために質問をしてくれている（P163）
「相手は否定したいんじゃない」。これは忘れがちだけど大事な捉え方ですよねぇ。。
視野を広げる
- 「橋をかける」（P173）
- これまた繰り返し出てくるワード
- 1.5年先を見る（P174）
- 自分がどこまで理解しているか → 見えた次を埋めるプロセス
- 隣のチームのマネージャーだったら？と考える（P179）
- 横断的に → 事業に必要な目線へ
チームの未来を描く
- どこにボトルネックがあるのか（P183）
- どんな人とどんな未来を一緒に作りたいのか（P186）
- 全て出来る人なんていない
- 絞る、ボトルネックを解消出来る人、得意なことを任せる、他の部分は後でキャッチアップしてもらう
- ロードマップを説明するように、そこに対してどのように活躍できるのか、してほしいのかを伝える（P188）
- どんな未来を目指しているのかを言葉にすることが大事（P191）
- 自社やチームの魅力を自分の言葉にする（P194）
- 社外の仲間を増やす!!（P197）
- 発信する → 同じことに悩んでいる誰かの力になれるかも
「社外の仲間を増やす」「発信する」。これは自分が勉強会に参加したり、カンファレンスに登壇したりしていることと完全に一致していて、続けていきたいなって思えた。
EMとしてのスキルの保ち方
- 知識を一旦手放すつもりでインデックスを再構築する。頭の中の容量を空ける。（P208）
- 大局観を磨く（P210）
- 半年で現場に戻れるかどうかを目安に
- メンバーを頼って大局をつかむ（P213）
- 情報は知っておく、新しい技術は試しておく
- マネジメントは、その力をふるう対象をコードやプロダクトに閉じず、チームや組織、そして事業へと広げていくこと（P216）
「エンジニアに戻ろうと思えば、いつでも戻れる状態を保っておく。」
これ、とても大事なことだと感じました。
職種を超えた協働
- 職種は違えど同じプロダクトを作る仲間（P221）
- 問題を整理し、プロダクトの価値を高めるために何が出来るのかを考える
- デザイナーと言えどもエンジニアと接するのと変わらない
- フロントエンド、バックエンド、インフラ、QA、色々あるよね
- 共通言語を持つこと自体は大事!!
- 同じ言葉で喋れるように鍛錬は必要
経営視点
自分にとってはまだ遠い世界の話だなぁという感じでした。ただ、経営について知ることはこの先大事なことになってくるんだろうなとは思っています。
EMの行動原則（読書ログから抽出）
読書メモ全体から行動原則を抽出してみました。
| # | 原則 | キーワード | 代表ページ |
|---|---|---|---|
| 1 | 翻訳者であれ | 橋をかける、共通言語、ビジネスの言葉に変換 | P17, P91, P149, P173, P221 |
| 2 | 未来を描き言葉にせよ | 1.5年先、ロードマップ、言葉にする | P174, P186, P188, P191 |
| 3 | チームの天井にならない | 環境整備、ボトルネック解消 | P53, P183, P213 |
| 4 | 求め合う関係を築け | 自己開示、フィードバック、衝突を辞さない | P71, P101, P127, P131 |
| 5 | 発信し仲間を増やせ | 社外の仲間、成果発表、誰かの力に | P23, P194, P197 |
| 6 | 技術者としての自分を保て | インデックス再構築、試しておく、半年で戻れる目安 | P208, P210, P216 |
おわりに
PART3が生々しくてとても参考になりました。（わたしのすぐそばで似たような現象を観測したりするので）
この本にもありましたが、想像力というものがとても大切なような気がしました。今どんな状況か、あの人は何を思っているのか、この先どうなりそうか。
技術はAIに置き換わるかもしれないからこそ、こういった人として考えなければいけないことが大事になってくるんだろうなって。（技術で解決できるものはとてもかんたんなことになるかもしれないですね）
EMになりたてのわたしにとって、改めて良い本でした。