エンジニアリングマネージャー(以下EM)に対して思うことがあるので私見を述べる。
なお、ここでのエンジニアはいわゆるWebやSaaS業界で働いているITエンジニアをさし マネージャーはそのエンジニアをマネジメントする役割の人を指す
※よくエンジニアはITエンジニア以外もいるぞみたいなことがあるが、 あくまで本記事中のコンテキストであることをご認識いただきたい。
また、筆者はマネージャーの立場ではない
EMの4領域
よく言われるEMの4領域がある。 - qiita.com
- blog.stenyan.jp から4領域に関して引用する。
- テクノロジーマネジメント
- アーキテクチャやテストなど
- プロジェクトマネジメント
- 見積もりやアジャイル開発など
- プロダクトマネジメント
- ビジョンや仮説検証など
- ピープルマネジメント
- メンバーの成長やメンタリングなど
上記4領域に関して、会社によるところもあるが、
- テクノロジーマネジメントに関してはいわゆるテックリードやアーキテクトなどが務めることが多いだろう。
- プロダクトマネジメントはPdMがいる組織ではPdMが担うだろう。
- プロジェクトマネジメントの中でスクラム開発を行っているのであれば、スクラムマスターがプロジェクトマネジメントに関しては担うだろう
こうなるとEMが残された領域はピープルマネジメントとなる。
EMのもう一つの役割
によると、
「エンジニアリング組織の成果に責任を持つもの」 と定義している。 その中でマネージャーは 説明責任を求められることが多くなるとある。 なぜこうなったかを説明する義務がある。
そもそも、なぜ説明責任が必要なのかというところを考えてみる。
当たり前だが、会社は業績や利益を上げる必要がある。 その中で会社として戦略や方針・決定事項がありそれが各エンジニア組織に目標として与えられ、その目標に対してどうだったかという説明責任が必要となる。 すなわち、EMは会社としての戦略や方針を各エンジニアに説明する責任がある。 特に会社としての戦略や方針は抽象的であることが多く、それを具体的なものに落とし込んで説明する必要がある。 いわゆる なぜそれをやるのか という部分を説得力を持って伝える必要がある（と筆者は考える）
ピープルマネジメント
エンジニアのためのマネジメント入門にコミュニケーションを支える技術として メンタリング、ティーチング、コーチング、フィードバックの4つが紹介されている。 いわゆるメンバーに対しての説明責任を果たすためにはこの技術が必要となってくるだろう。
信頼貯金
さて、抽象的な会社の戦略を具体に落とし込むときには実際のプロダクトを知る必要が出てくる。 例えば、サイトを高速化することを戦略として置いたときに、すでにその戦略が手を尽くした後であった場合は無意味になる。 つまりEMといえどプロダクトの性質やプロダクトのアーキテクチャ、コード、そして一連のリリースまでという現場を理解している必要があると考える。 (ここの理解度は濃淡で関数レベルで知ってる必要はないとは思うがある程度どんな構造でどんな処理になっているかを知っている必要があるだろう）
さて、ここに2人EMがいる。 片方はコードを読んだことがなく、1行もコミットしたこともなく、1度もインシデント対応やハンドリングをしたことがない人と、 片方はある程度コードを読み込んでおり、何かしら機能開発をしている とする。
信頼に足るのはもちろん後者であろう。
前者で信頼される人の場合は、例えば該当プロダクトの知識は無くても、その領域のドメインに精通していたり、プロダクト開発自体に精通している人 もしくは理解に努めようとしている人であろう。
現場を知らないEMの言葉に、誰が耳を傾けるだろうか。 具体的な経験に基づかないEMの言葉は、ただの薄っぺらい机上の空論であり、メンバーのモチベーションを削ぐ要因となる。 上からの一方的な指示を下すだけのEMは、チームの成長を妨げるだけの不要な中間層以下である。
まとめ
- EMとはピープルマネジメントを中心にマネジメントを行い会社の戦略の説明責任をもつ
- それを伝えるコミュニケーションを行うためには信頼が必要である。
- 戦略を語るにしてもやはり信頼が必要であり信頼が失われるとメンバーは納得して動かないだろう
- 信頼を得るには、技術や能力が必要だったり一度現場の感覚がつかめていないと信頼されないだろう。そういうEMは今後どうなっていくのか。
