mtx2s’s blog

エンジニアリングをエンジニアリングする。

エンジニアリングマネージャーという役割にどう向き合うか

エンジニアリングマネージャーとしての日々の仕事にやりがいを感じられない。そういう人は多いのではないか。

「マネジメント業務の中では達成感を得られず、自身の成長も感じられない」「会議や調整ばかりの毎日で、週末に一週間を振り返ってみても、明確なアウトプットもなく、自分が一体何をしていたのか思い出せない」といった声をきく。

やりがいを感じられないのは、やったことに対する明確な手応えを感じられないからだろう。エンジニアとしてソフトウェア開発に邁進していた頃とは違い、マネージャーとはそういうものだと半ば諦めてしまっているのかもしれないが、その認識は正しくない。ソフトウェアエンジニアがソフトウェアを開発するように、エンジニアリングマネジャーは、エンジニアリング組織を開発している。マネジメントをそう捉えると、様々な見え方が変わる。手応えも感じられるようになる。

手応えとは、言い換えれば「フィードバック」だ。ソフトウェアデリバリでは変更に対してフィードバックを得ることで学び、プロセスを素早く適応させる。このフィードバックループによって、ソフトウェアの価値を高め続ける。マネジメントにおいて手応えを感じられないのだとすれば、それは、エンジニアリング組織の価値を高めるための「変更」に取り組めていないのかもしれない。日々の業務に忙殺され、何をすべきか思考する時間を奪われてしまっているのではないか。

高めるべきエンジニアリング組織の価値とは何だろうか。それは、優れたソフトウェアを作り出す能力だと私は考える。そのためにはもちろんエンジニア一人ひとりの技術力向上も必要であるが、適切な組織構造やプロセスも必要となる。そして、コンウェイの法則によって組織構造に強く影響を受けるアーキテクチャについても考えなければならない。

それこそ、バックログを作り、優先順位を付けて、エンジニアリング組織の変更に取り組むのも良いだろう。その変更が成功したかどうかは、あらかじめ決めておいたメトリクスによって判断する。意図した通りにメトリクスの値が変化したならば、最高の達成感を得られるだろう。そうならなくても学びを得られる。もちろん全てを定量化できるわけではないので、そういったケースでは組織内外に変更結果についてヒアリングすれば良い。

エンジニアリング組織のマネジメントとは、まさにエンジニアリング組織に対するエンジニアリングだ。そういった観点から、エンジニアはそもそもマネージャーに向いているのではないだろうか

日々の業務に追われ過ぎると、組織について考える時間を取れない。組織改善に向けたバックログにアイテムを追加することすらできない状態に陥る。マネージャーには考える時間と、考えたことを実行し、その結果を評価する時間が要る。

エンジニアリングマネージャーとしての日々の仕事にやりがいを感じられないのなら、忙殺される毎日から抜け出すことが、まず最初にやるべきことになるだろう。エンジニアリングマネージャーとして、エンジニアリング組織の改革・改善に没頭できたなら、こんなにやりがいのある仕事はないと感じられると思う。

mtx2s.hatenablog.com

mtx2s.hatenablog.com