エンジニアリングマネージャー(以降、EM)のしごとを読んだので、総括していこうと思います。

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

経緯

エンジニアとして仕事をするにあたって、 EMの仕事を知っておくことで相互作用を起こすような働きができたらと思ったところが始まりでした。

現在自分はEMではなく、EMとしての知識はほぼ0なので、知識だけでも少し詰め込まねばというところでググったところドンピシャなタイトルのこの本が出てきたので読み始めました。

どうせ読むならメモ代わりに、自分が参考になりそうなところを書いていこうと思ったのでピックアップして記事を書くことにしました。

読んでみて

感覚的に分かっていた事は言語化されていて、半信半疑だったものは明確になりました。

自分は全然知識がなかったのでどういったことをマネージャーが行うのかどういう考え方が必要なのかなどが断片的なものでしか見聞きしていなかったので知っているものも含めて体系的に知る事ができたのは良かったと思います。

教育や独学で学んできたエンジニアリングと違って、EMは事前の学習などがない状態で就任する人が多いです。

何をしたらいいのか、どんな問題が待ち構えているのか、どのように解決していくのかというのが未知の状態で進むことが多く、この本で事前にある程度事前学習できたら、少しでもそのキャリアを諦めないように進めるような道標が詰め込まれている本になっています。

ただ、マネージャーとしてすでに経験のある人にとっては既知の情報が多いかと思うので、あくまでこれから就任すると言う人や、就任直後の人向けの内容になっているのではないかなと思います。

要所ポイント

マネージャーのアウトプット

本書の中で一貫して使われる言葉です。

マネージャーのアウトプット = 自分のチームのアウトプット + 自分が影響を与えた他のチームのアウトプット

1on1

マネージャー就任時にまずやらないといけないこと、かつ継続して行っていく必要のある最重要事項です。何より情報が必要な仕事であるため、1on1から情報を集めていく必要があります。情報というのは

チームメンバーの考えや感情、性格
プロジェクトの進行状況、ボトルネックとなっている部分、プロジェクトの文化
上司が持つ「組織の中での自分の役割」

こうした情報を週に1度、1on1を設定し、通して集めていき、適用していくことが理想となります。就任直後や、入社直後のマネージャーはプロジェクトの状態が全く頭にない状態でスタートするため、情報収集のため、この辺りから始めるのが良いです。

上司との1on1

上司との1on1では、上司から言われる前の行動によって、より成長の機会を増やすことに繋がります。 - 組織内で１階層上がったレベルでの懸念事項について話す - 他のチームへの状況の確認ができ、アドバイスをする機会を得ることで、上司を助けることができる - 自分の興味が現在の業務の範囲外にもあるということを伝えるなどなどができます。

自分の状況、関心を伝える上で、週次の1on1の前に30分程度サマリーを作成する時間を設けるのは良い方法です。その中に、（前回からの）進捗、問題、問題へのアプローチ、メンバーの状況を書き連ねておくのが良いです。終わったら上司に送るなどをしておくと良いです。

ナッジング

EMとしての自分の観点を提供することで決定に影響を与えること。意思決定を下すわけではなくても、決定に影響を与えることができるため、自由に意見ができる時はその事を念頭に置いておく必要があります。

委譲

タスクの責任を他人に委譲することを指します。委譲には、アンチパターンが２つあります。 - 委譲できてないパターン - 丸投げパターン

委譲できていないパターン

優秀なエンジニアからEMになった時になりがちなパターン。自分がやった方が早いであったり、精度を高められるという点から、重要な部分は自分でやってしまうという状況。これにより、中途半端な委譲によって仕事の品質が下がりイライラしたり、メンバーも信頼されていないと感じることに繋がります。イライラしたからといって、スタッフに委譲したタスクを取り戻すようなことをする事も良くないことです。

丸投げパターン

逆に、委譲し切ってしまい、タスクの存在すら忘れてしまうパターン。これによって、タスクの状況も忘れられ、品質の管理もされないため、品質が保証されず期限も守られないということになり、お互いに良くない状況に繋がります。

説明責任

上記のような極端なパターンがアンチパターンになるため、バランスを取る必要があります。そこで出てくるのが説明責任になります。説明責任とは、タスクを求められる品質で完了させる責任を持つということ。 EMとしては、この説明責任を持ち続ける事が理想となります。

対となる言葉に、実行責任があります。タスクを実際に自分で行うことです。実行責任は、スタッフに委ねられるものになり、スタッフにとってチャレンジングなくらい委譲されるものであるべきです。そうすることで、スタッフも挑戦し、成長することで、一緒に成し遂げられるようになります。

欲求の階層

上昇思考の強い人は今の仕事をより良くしようと思っています。エンジニアのスタッフの人たちもそのように感じることが多いです。その人たちにEMの立場からできることとして、マズローの欲求階層に当てはめて考えることができます。

生理的欲求: 自分がしたことへの適性な給与が欲しい
安全欲求: 安定安全な労働環境が欲しい
所属の欲求: チームや上司といい関係を築きたい
- EMができること: ・自分とスタッフと組織をうまくつなぎ、チームが大きな何かの一部であると感じられるようにする。
承認欲求: 自分がしたことへの評価を公式・非公式双方でしてもらいたい
- EMができること: ・賞賛と批判を通して、確実に評価する。・スタッフのレベルに合わせて職位と責任を持たせる・スタッフが自信を深め能力向上できるように指導と誘導
自己実現欲求: 継続的にスキルの向上のため挑戦していきたい。次のキャリアがあるというのを実感したい。
- EMができること: ・トレーニングやカンファレンスへの参加を通して、新しいスキルを学ぶための機会の提供・スタッフが選ぶ方法で問題解決への自由を与える

大聖堂とバザール

このモデルのイメージに近いものは、トップダウンとボトムアップに近しいものを想像してもらうのが良いかと思います。

個人レベル

大聖堂モデルとバザールモデルは個人レベルでも当然当てはまる考え方で大聖堂モデルのような考えの人もいれば、バザールモデルのような考えの人もいます。ただ、そこに良いも悪いもなく、個々人の考え方によって、マネージャーとして適切な委譲、与える機会、働く環境を考える必要があります。

大聖堂

プロジェクトの保守管理は、長いプロジェクトになればなるほど、初期に関わっていたメンバーやコアなメンバーによって意思決定が行われ、他の意見などの雑音を少ない状態で、しっかりと管理されているような状態です。

エキスパート気質なところが多く、深く学ぶことを得意とし、深く学ぶまで新しいものに手を出さないようなタイプです。自分がエキスパートとなった領域を他の人に伝えることで恩恵をもたらし、楽しみます。

バザール

プロジェクトの保守管理は変化が起こるものとして捉え、その中でバグが出たとしても多くのコントリビュータによって、即座に対応できるという考えの元、管理する状態。その方がメンバーのモチベーションも高まるとされている。

多くの新しいものを試したがります。それに伴って、プロトタイプなども構築しては捨てるというような試行を繰り返すことが好きなタイプです。大聖堂モデルとは違って、変化を好むタイプなので、長期に渡るプロジェクトというよりは定期的に考えが異なるようなプロジェクトへの機会を持たせるのが良いです。

機密情報

当然ですが、情報の共有には非常に慎重になる必要があります。 1on1を通して話したこと、たまたま立ち会った立ち話で聞こえてきた話、組織の決定について全てにおいて誰にどのタイミングで伝えるか、もしくは伝えない方がいいのかといったことについては細心の注意が必要になります。

これも三つの領域に分けて考えると分かりやすいです。 - 完全機密: 1on1などの関係ある特定の人以外には知られてはいけない情報。 - 密閉箱: 存在は知っているが、詳細は知るべきではないこと。(例えば、給与テーブルなどは誰もが知っているが、個人の給与については知られてはいけない) - 解放箱: みんなに知られるべき、知られても良い情報

PIP

この概念は、日本にはないものだったので少し衝撃的だったため書こうと思いました。人が去っていくことは、避けられないことであり、受け入れるしかないことではあるのですがそれにも2つの原因があります。 - 自発的な離職 - 不本意な離職

になります。前者は説明がなくても理解はできるかもしれないですが、後者については日本においてあまり意識しないこともあり、想像し難いものかもしれないです。 PIPは、Performance Improve Plan の略で、不本意な離職の際に行われるものです。

パフォーマンスの悪いスタッフに対して、改善提案を行い、改善が見られなかった場合に解雇や契約解除ということにすることを意味します。しかし、これは最終手段なので、あらゆる他の手段で改善を試みて、改善が見られなかった場合に行われるものになります。

PIPを行うにもいくつか注意を払う必要があります。 PIPの内容では、その人がなぜPIPの対象になってしまったか、いつまでPIP期間となるかなどが記載されるのは当然ですが、どうなったら改善されたかということの記載と、その改善はその人にとって無理難題なものではないことが明確になっていることが重要になります。

まとめ

自分にとって特に重要そうな箇所についてピックアップしてメモとして書いたものですがそれ以外にも参考になる内容が多く、入門としても良い本だと思いました。

将来EMとしての道に進むかどうかは別として考え方を知っておくのは誰にとっても損にはならないと思うので、時間に余裕があって考え方に幅を広げたいと思う方は読んでみても良いかと思います。

ugo's 読書感想文

読んだ本のまとめや学んだことを書いていきます。

エンジニアリングマネージャーの仕事

経緯