--- title: 読後メモ『エンジニアリングマネージャーのしごと』 slug: engineering-manager-job-book-review created_time: 2022-10-02T00:00:00.000Z last_edited_time: 2023-12-30T10:05:00.000Z category: Diary tags: - 雑記 - 読書 published: true locale: ja --- https://www.amazon.co.jp/dp/4873119944 [O'Reilly Japan \- エンジニアリングマネージャーのしごと](https://www.oreilly.co.jp/books/9784873119946/) 今年オライリーから発売された『エンジニアリングマネージャーのしごと』を読み終わったので、あとでまた思い出したいエッセンスをいくつか書き残しておく。 ## 3章 人間と関わる ### 3.3 上司との連携 > 毎週時間を取って状況をまとめるというシンプルな活動は、強力な治療効果があります。 取り組んでいる問題からちょっと離れて、紙の上で扱えるようになります。そうすると、問題もそれほど 重大でないとか、難しくないことがわかります。 自分の生活を記録することは、気分や健康の改善に良い影響があるという研究もあります。 仕事を毎週記録することで、 仕事でも同じような効果があるのです。 > > うまく書けないなら、4つのPというアプローチを試しましょう。 > > - 進捗 (Progress): 前回の記録から何が起こったか? > - 問題 Problems) どんな問題が起こったか、対処が必要なものは何か? > - 計画 (Plans):問題に対してどのように取り組む予定か? > - 人 (People) : チームの人はどうか。 全員良い状態か? 辛い状態の人はいないか? 何を改善できるか? > (p56) 自分のマネージャーとしてのパフォーマンスや健康状態について上司と話をするために、ふりかえりと計画を端的に、定期的に記録する。 サマリーの書き方としておすすめされている「4つのP」も、この文脈に限らず汎用性のありそうなので覚えておきたい。 ## 4章 1on1 ### 4.3 コントラクティング：最初の1on1 > コントラクティングとは最初の1on1で扱う単純な質問一式で、あなたと部下が期待することについての会話を誘発するものです。 両者から期待することを出します。 このエクササイズにより、 お互いのニーズを構造化された安全な方法で話せるようになり、率直で透明性の高い会話ができるようになります。(p65) 部下との最初の1on1で、コントラクティング（contracting, 契約）というエクササイズを行うことで、その後両者が互いに何を期待し、どのように関わるかについて合意をつくることができる。 似たようなことは今までにメンターとして1on1をするときにやっていたが、この節のガイドのおかげで今後はもっといいコントラクティングができそうだと思った。 ## 10章 人間って難しい ### 10.3 ムチとニンジン > 処理能力を向上させる本当のリーダーシップは、チームのなかで目的と情熱を育むことで生まれ ます。 エンジニアが組織内での自分の目的と会社のために形勢を変える方法がわかれば、本来のパ フォーマンスを発揮できるようになります。 仕事に情熱が持てれば、もっと良い仕事ができるようになります。 本質的に楽しめる人たちだからです。 > > （中略）パフォーマンスの問題ではないと仮定してですが、もしチームの仕事に対するモチベーションが低いとか、あなたの思うような動きをしてくれないといった場合は、チームがよく機能する一団となっていける状況を作り出す必要があります。 > > これに役立つモデルがあります。 **自律性**、**熟達**、**目的**です。 (p186) チームにとってニンジン（それによってやる気が湧いて一生懸命働くようになるもの）となるのは、それが自律性・熟達・目的の3つの条件を満たすようなものであるという考え方のモデル。 チームの成果に課題を感じるとき、まずこのモデルで考えてみようと思う。そのチームの前にニンジンはぶら下がっているか？ムチで叩いてしまっていないか？ ## 12章 情報の証券取引所 ### 12.3 社内政治 > あなたが情報をうまく扱っているとしても、仕事はそこで終わりではありません。 マネージャーとして、人に情報を把握しておいてもらう義務があります。誰も置いていかないようにしましょう。 > > 共有する情報の一貫性を継続的に示すべきです。（中略）プライベートなインタラクションと全体への周知の両方を使って、誰も置いていかないようにしましょう。 (p223) チームやメンバーが情報の流れから置いていかれないように、必要な情報を確実に把握しておいてもらうことはマネージャーとしての義務である。 「チームを適切な情報のループに入れておく」という考え方はなるほどと思った。点での情報共有ではなく、確実なループを作ることを意識してみようと思う。 ## 14章 良いハウスキーピング ### 14.4 問題を学習の機会に変える > 先ほどは、ソフトウェアに問題があったときに何をするかを見てきました。 では、プロ セスに問題がある場合はどうすべきなのでしょうか？チームが、ブラットフォームのアーキテクチャーに関するドキュメントや新しいサービスを作るときのベストプラクティスを記したガイダンスを見つけるのが難しいような場合です。 これは単にチームにとどまらない問題であり、答えを見つけるのは難しいかもしれません。 また、このような問題は、士気の低下にもつながります。手に負えない状況の場合、 人はどうやって変化をもたらせるのでしょうか? > > このようなときに、**マネジメントバグ**に取り組んではどうでしょうか? eBay が急成長していたときリーダーシップチームは現場からどんどん離れていってしまいました。 小さくて機敏な文化は、急激に大企業的になりました。 CEOはこの問題を正したいと考えて、オフィスの人通りの多い場所に意見箱を置きました。 誰でもメモを箱に入れることができ、全社ミーティングのときに箱を空にしました。すべての意見や提案が、従業員全員の前で読み上げられ、 回答されたのです。 (p266) マネジメントバグという方法ははじめて知ったが、つまりプロセスやマネジメントの課題についての目安箱だということだろう。特徴的なのは、それがすべて全員の前で読み上げられ、マネージャーがすべてに回答するという徹底的な透明性へのコミットメントだと思う。投げ込んだチケットが無視されず回答されると信頼できるからこそ、真剣に意見を上げてくれるのだろう。会社全体の課題じゃなくとも、小さい規模でやってみたいと思った。 ## 16章 現代の職場環境 ### 16.2 リモートワークへの移行 > 非公式なやりとりが減ってくると、スタッフのために価値と目標をきちんと設定することはより重要になります。 > > - **価値**はチームの働き方を定義するため、メンバーは統一された方法で非同期に進捗を出せます。（中略） > - **目標**はチームの狙いを定義するため、みんなの足並みがそろいます。 分散チームではスタッ フが自律的に働けるため、目標の重要性が増します。 チームの価値と目標についてそれぞれ別の効果のために設定する。価値は何を大事にするかという、チームの働き方を規定するための土台になるもので、具体的な行動指針として記述されればそれがワーキングアグリーメントということになるだろう。 一方で、目標はチームがなんのために働くのか、何がそのチームの勝利・成功なのかということの基準になるものであって、イテレーションの中で追跡していくものになる。この2つを混同せず、どちらも欠けていないようにチームを保たなければならないだろう。 --- ## 感想 エンジニアからマネージャーになったことで、個人としての自分のアウトプット、パフォーマンスの見えにくさによって自己効力感や自己肯定感を失い始めている人に、本書をおすすめしたいと思う。繰り返し出てくるフレーズがあるのだが、これがこの本で一番伝えたいこと、覚えて帰ってもらいたいことなのだろうと思う。 > マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット とはいえ、このことを頭で理解していても、実際に心で納得できるほどになるには精神的な成熟が必要だと思うし、このことに悩んでいる人は実際に周りでもたくさん見ている。 僕個人はこのことには悩んでいないが、それはそもそもマネージャーじゃなかったとしても、そんじょそこらのエンジニアでは個人で生み出せる価値なんて大したものじゃないと思っているし、結局チームとして価値を出せるかどうかだけが拠り所だと割り切っているからかもしれない。なので、マネージャーをやり始めて日は浅いがこの方程式はしっくり来ている。それがうまく言語化されていて腑に落ちた本だった。