今更ながら最近EM.FM を聴いている。とても学びが多く、このような知見をオープンにしていただけているのは本当にありがたい。そして特に広木さんの言語化力には驚愕した。ここまで論理的にわかりやすく言葉にできるというのは、深い知識と深い理解が必要であり、ここまで来るのにどれだけの努力をしてきたのだろうか。私にはここまでの力は無いが、見習って努力していきたい。
その中に、「EMに求められる3つのスキルとは」という話があり、主にこの3つがあるとあった。
-
アーキテクチャマネジメント
-
プロジェクトマネジメント
-
ピープルマネジメント
そして、全てが密接に関係しており、理想的にはすべてできることであると話されていて、これは本当に同感だ。エンジニアリング組織で目の当たりにする課題は、概ねどれか一つで解決できるような簡単なものではない。もっというと、すべてが関係するという意味で、理想的にはプロダクトマネジメントやビジネスにも広がる必要もある。
少し、エンジニアリングマネジメント≒ピープルマネジメントというイメージが広がってきているような感じもしている。私自身、最近はあえて1on1や成長を前面に出しているので、多少加担している状態でもあり、改善が必要だ。ここの部分は微力ながらしっかり伝えていこうと思う。
今所属している会社では、実質エンジニアリングマネジメントをやっているのだが、ピープルマネジメントはほとんどしないようにしている。というのも、チームも大きくないし、ネガティブな状態でもないので、そもそも必要がないのだ。なので、プロダクトオーナーという形でプロダクトの方向性を作りながら、そのアーキテクチャも交えて考慮・設計し、開発を前に進めるためにプロジェクトマネジメントをしている。その上で、コーディングもしている。
以前のVPoEとしての経験も含め、やってみたり学んでみたりして思うのは、エンジニアリングマネジメントとして求められることが広すぎないか問題である。私は比較的ジェネラリストであり、物事を抽象的に考えるほうが得意なので3つやろうとしているが、それぞれがエキスパートかと言われると否だし、プログラミングがすごくできるわけでもない。一緒に働いている人を見ると、いつもすごいなぁとしか思わない状態である。つまり、中途半端感が否めない。
かといってそれで良いのかというのはそうではない。そうなると、それぞれ広く深く知識と理解があったほうが良くて、できればわかるだけでなくできる方が良い。となると、学ぶ時間が足りない。人生の時間は有限であり、凡人以下の私は学ぶ能力も早々に限界にぶち当たる。
やれることをやっていくしか無いわけではあるが、とはいえ絞る必要がある。自分の強みは抽象化とイメージする力だと思っているので、いかにそれぞれを構造的にシンプルに捉えられるか、それを時間空間も含めてどう表現できるか、ということは続けていきたいと思いつつ、そうするだめにはファクトが必要なので、広く学び続ける必要がある、ということに戻る。
答えはまだない。模索の日々である。皆さんはどのように学んでいるのだろうか。
