『Team Geek』を読んだときのブログ記事にも書きましたが、今年の4月頃からデータ基盤チームのリーダーをやっているのですが、今までチームマネジメントについて興味関心がゼロだったのでアンテナを張って色んなところから学ばせてもらっています。
今年の8月に『エンジニアリングマネージャーのしごと』という本がO'Reillyから出版されたので読みました。私は読むのが遅く少しずつ読み進めて、昨月2周目の通読が終わりました。
オライリージャパン (2022-08-26T00:00:01Z)
￥7,480 (コレクター商品)
ryuzeeさんのブログ記事にあるスライドを読まれるとおおよその内容は把握できますので、本書を読む前に一読することをオススメします。
マネジメント系の本では、マネージャーのマネージャーや部長クラスの役職がメインで扱われていることがあるので共感できず途中で読むのが苦痛になってくるのですが、本書はチームリーダーにも適用できる内容が多かったです。特に1～4章は学びが多かったです。後半は採用や社内政治の話が入ってくるので今のところあまりしっくりこず。時間が経ったら再読しようとおもいます。
参考にしたい部分についてメモを取っていたのですが、すべてを紹介すると書籍の引用を超えてしまうため、個人的にとても気になった部分のみ紹介します。
第2章 まず自分を管理しよう
ToDoリストは、自分のタスクがある唯一の場所であるべき
ToDoリストにないものはやらない
頭の中がいっぱいになって思考停止になりがちなポンコツな私ですが、ToDoリストにないものはやらないという指針を持つことで、迷子にならずどんどんタスクをこなせていけそうです。今はSlackからの依頼や時間がかかりそうな返信があったときはToDoリストに転載するようにしています。
マネージャーのアウトプット ＝ あなたのチームのアウトプット ＋ あなたが影響を与えた他のチームのアウトプット
チームのアウトプットに対して最終的な責任を持つ
チームのアウトプットはあなた個人のアウトプットより重要
この方程式は本書の中で何度か登場します。そのぐらい重要です。マネージャーとして個人よりもチームとしての成果が問われるため、チームのメンバーに対して以下にアウトプットを多くできるようになるかが問われます。
第3章 人間と関わる
委譲について
説明責任：タスクを求められる品質で完了させる責任を持つ
実行責任：タスクの実行を行う責任を持つ
委譲とは、タスクの実行責任を他の人に託しつつ、説明責任を持つこと
説明責任は委譲できない。放棄したら丸投げになる
やってはいけないこと：丸投げ、他の人のやり方が自分と同じであることを期待すること、渡したタスクを取り返すこと
「自分でやったほうが早い病」に罹っている私ですが、自分ひとりでできることは限られているため、チームメンバーに委譲することが多くなります。単に仕事を任せるのではなく、どのぐらいまでコントロールしてどのぐらいまで委譲するかをタスクの難易度や委譲する人のスキルを考慮して判断しなければなりません。また、任せっぱなしにすると丸投げになってしまうので、そのタスクについて求められる品質で完了させる、上司に対して状況を説明できるように努めなければなりません。委譲って難しいですね。最低限としてやってはいけないことはやらないように注意をはらうようにしています。
第4章 1on1
1on1の間、共有ドキュメントにメモを取ったり、アクションをアサインしたりすると役に立ちます。ミーティングの最後に、アクションを見直しましょう。通常、私はノート PCを使って、直接共有ドキュメントに書き込んでいます。すべての会議室にディスプレイがあるため、そこに投影して、話しながらメモをとります。いずれにせよ、メモは秘密ではありません。
今まで1on1のメモは、自分にしか見えない場所に保管していたのですが、ここを読んでからGoogle Docsに移行して1on1の相手との共有設定をしました。リモートで1on1をすることが多いので、Google Docsを画面共有しながら話したことやアクションをメモしています。次回の1on1までにやること（アクション）は太文字にし、次回に確認するようにしています。
第13章 コントロールを手放す
コントロールの三分法
・自分がコントロールできるもの：自分の願望やゴール
・自分がまったくコントロールできないもの：天候など
・自分がある程度コントロールできるもの：試合に勝ちたい願望など
コントロールできないものに対して、外部ゴールではなく内部ゴールを設定する
⇒ 今置かれている環境で、自分なりのベストを尽くす
相手や周りの環境など自分で変えることができないもの対して心配をしたり不安を抱えるのではなく、自分なりのベストを尽くすことができれば良しとすることが大事です。相手に極度の期待をしないというのに似ていますね。
最後に
エンジニアからマネジメントするようになったときに必要なことを体系的に学ぶのに良い本だと思いました。難しいことは書いていなくてすぐに実践できそうなことばかりでした。定期的に読み直して実践しているかを確認していきたいと思いました。
