エンジニアリングマネージャーになって2年4か月ほど経った。いまだにこれでいいんだろうか？マネージャーとしてすべきことは？の正解を探しながら日々仕事をしている。
最近悩んでいることにマネージャーのセルフマネジメント（自己管理方法）にはどういったものがあるか気になっている。というのもマネージャーとしてのアウトプットってなんだろう？ICと違って目に見えるものじゃなかったりするよなとモヤモヤしていた。このような状況はあまり良くないと思っていてどう自分をコントロールするのがいいのか方法を探りたかった。
「エンジニアリングマネージャーのしごと」という有名な書籍があり、昔にほんのちょっとだけ読んだ記憶があった。マネージャーに関する本はたくさん積読しているのでなにかヒントが得られないかと思って目次から気になるところを読んでみたので雑にメモをする。
なお、メモはGeminiに音声で読んだ章の感想を伝えてそれをまとめてもらったのでそれを引用している。
第2章 2.3「アウトプットを測るには」より
【テーマ:マネージャー自身の成果の定義と、プレイヤーからの脱却への自信】
- 気づき・インサイト（マネージャーのアウトプットの定義）
- マネージャー自身の直接的なアウトプットではなく、「自分のチームのアウトプット」＋「自分が影響を与えた他のチームのアウトプット」の総量こそが、マネージャーの成果である。
- チームのアウトプットに対してマネージャーが最終的な責任を持つ。もしチームがうまくいっていなければ、それをリカバリーする（テコ入れする）のがマネージャーの仕事。
- マネージャーが時間を投資すべき優先順位
- 個人のアウトプット（自分がタスクを実行すること）よりも、チーム全体のアウトプットの方が遥かに重要。
- そのため、自分のタスクを進めることよりも、「権限の委譲」「コーチング」「メンタリング」といった、チームのレバレッジ（生産性）を高める活動に多くの時間を費やすべきである。
- 他チームへ影響を与える手段として、「コーチング（マッチング）」や「自らがロールモデルになること」が重要となる。
- 自己分析とマインドの変化（自信への繋がり）
- これまでの悩み 「自分自身のアウトプットをどう出すべきか」に頭を悩ませ、焦りを感じることもあった。
- これからのスタンス 「プレイングに走るのではなく、マネジメントをしっかりやり遂げることが正義である」と改めて理解できた。自分のやってきたアプローチが間違っていなかったと確信でき、大きな自信に繋がった。
第2章 2.4「活動分類して生産を高めるには」より
【テーマ:マネージャーの仕事の不確実性と、技術貢献への免罪符】
- 気づき・インサイト（マネージャーの仕事の性質）
- マネージャーの日常は、細切れのタスクやミーティング、脳内会議（抽象的な課題の具体化）に追われやすく、「やってやったぜ！」という目に見える明確な達成感（職感）を得るのが難しい。
- 目の前の小さなタスクを「自分でやった方がリソース効率が良いのでは？」と誘惑に駆られることもあるが、チームのために抽象的な課題を掘り起こして形にするのが本来の仕事である。
- 自己分析と現在のワークしている点
-「自分自身が手を動かして（コードを書いて）はいけない」という意識を強く持っていた。
- その「プレイヤーから一歩引く」強い意識があったからこそ、メンバーへの権限委譲がスムーズに進み、メンバー側からも不満が出ずに上手くワークしている（大きな強み）。
- 救いとなった一文（技術的貢献へのスタンス）
- 本書の「気持ちと時間があれば、技術面でも貢献しましょう」という一文に、精神的にとても救われた。
- 「絶対に手を動かしてはいけない」という極端なルールではなく、余力があるなら技術で貢献しても良いという「含み」があることで、技術者としてのアイデンティティや気持ちが楽になった。
第3章「人間と関わる」より
【テーマ:コミュニケーションの3つの媒体と「声のトーン」の盲点】
- 気づき・インサイト
- 言語コミュニケーション（※文脈から、非言語・身体言語を含むコミュニケーション全体の意）において、「ジェスチャー」「ボディランゲージ」「声のトーン」という媒体がある。
- なかでも「声のトーン」は、これまであまり意識してこなかった盲点であり、新鮮な気づきがあった。
- 深掘り・考察 -「落ち着いた声のトーン」で話す人は、それだけで「この人は話をしっかり聞いてくれそう」という安心感や信頼感（傾聴の姿勢）を相手に与えることができる。
- 今後のアクション・マネジメントへの応用
- メンバーとの1on1やミーティングにおいて、自分が発する「声のトーン」を意識的にコントロールしてみる。
第3章「他人の好みを尊重し、情報を伝えられる方法」より
【テーマ:モチベーションや称賛の「好み」は人それぞれ。思い込みの危険性】
- 気づき・インサイト
- 情報を伝える方法や、どう扱われたいか（称賛されたいかなど）の「好み」は人によって千差万別である。
- 「きっとこうすれば喜ぶだろう」というマネージャー側の一律の思い込みで判断するのは危険。
- 具体例・パターンの考察
- パブリック派: みんなの前で大々的に持ち上げられたり、評価を共有されたりするのが嬉しいタイプ。
- プライベート派: みんなの前で目立つのが苦手・好きではなく、個別（1on1など）でしっかり伝えてもらった方が響くタイプ。
- 今後のアクション・マネジメントへの応用
- メンバー一人ひとりが「どういう形でフィードバックや称賛を受けるのが心地よいか」を観察、あるいは1on1などで直接対話して把握する（個別のチューニング）。
第3章3.2「委譲」より
【テーマ:丸投げと委譲の違い、そして「説明責任」の本当の意味】
- 委譲の本質（切り分け）
- 実行責任（Responsibility） タスクを実際に動かし、完了させる責任。
- 説明責任（Accountability） タスクが求められる品質で完了することに対して、最終的な結果の責任を持つこと。
- 「委譲」とは、実行責任をメンバーに託し、説明責任はマネージャーが自分で持ち続けること。
- 委譲のグラデーション（ものさし）
- 委譲には「やるか・やらないか」のゼロヒャクではなく、コントロールの割合（幅）がある。
- 「自分でやる（委譲なし）」 ➔ 「やり方を示して並走する」 ➔ 「少しずつ任せる」 ➔ 「完全に委譲する」というステップが存在する。
- 委譲におけるアンチパターン（やってはいけないこと）と自己分析
- 丸投げ（説明責任の放棄） 「全部よろしく！」と結果への責任まで手放してしまうこと。
- 自分の振り返り: 割とまるっとお願いしてしまう傾向があり、もしかしたら「丸投げ」に近い状態になっていたかもしれない、という反省点。
- 自分のやり方を相手に期待する
- 自分の振り返り ここは早い段階から意識していなかった。「自分より相手（メンバー）の方がうまくできるだろう」という信頼・自信がベースにあったため、この罠には引っかからずに済んでいた（強み）。
- 任せたタスクを途中で取り返す
- 丸投げ（説明責任の放棄） 「全部よろしく！」と結果への責任まで手放してしまうこと。
- 「説明責任」への深い考察
- 日常で「説明責任を問われるシーン」はイメージしづらいかもしれない。
- しかし、任せた後も「最終的にどうなっているか進捗を追う」「ゴールにちゃんとたどり着くように見守る」という行動こそが、まさにマネージャーが「説明責任を果たしている（結果を放り出していない）」状態そのものである、という気づき。
セルフマネジメントに関する章はなさそうではあったが、マネージャーとしてやっていることが大きくは間違っていないように思えたし、特に技術貢献に時間を一切割いてはいけないということでもなかったのは安心した。
自分は一度経験してみてその答えを書籍に求めるタイプなので初手で読んでいても理解度が大きく違ったと思う。アレコレ悩むことは多いがこうして先人の知識・経験を参考にしながら少しずつ前に進みたいと思う。
See you next time:)
