こんにちは、細川です。

FLINTERSアドベントカレンダー3日目はエンジニアリングマネージャーについてのエッセイです。

私はエンジニアとして2018年に中途入社し、FLINTERS歴はそろそろ満5年、マネージャー歴は2年と少しになります。
嬉しいことに業務やプライベートにてキャリアパスのしばしば相談を頂くので、考えをさっと共有できるように書き出してみます。ひとつの事例として参考になれば幸いです。

なぜエンジニアリングマネージャーになったのか？

私の場合、社会人の当初からマネージャーという仕事に就きたかったとか人を導く仕事をしたかったというわけではありませんでした。FLINTERSに転職した目的もアジャイルやDDDしに来ました。

エンジニアリングの専門家として理想のシステム設計や開発手法を追求するために、結果的にマネージャーになりました。私にとってマネージャーという肩書きの持つ影響力と権限は手段です。

私がマネージャーになるまでの経緯は以下の３ステップです。

本やWebで現代的なシステム設計や開発手法を知り、価値観に共感し、自分が関わっている仕事に取り入れてみたい気持ちを抱く。
色んな場面で意見を発信したり行動する。並行して対人関係について学ぶ。
理想が周囲に共感され、強力な手段として会社からマネージャーを任される。

マネジメントとリーダーシップ

「リーダーシップの旅」という本は、マネジメントとリーダーシップが別の概念として定義しています。p.128にて、

マネジメントは複雑性に対処し、組織の安定性と持続性を維持するために機能する。
リーダーシップは創造と変革を扱う。見えないものを見て、その実現に向けて人々の価値観や感情に訴え、彼らの共感を得て、自発的な協働を促す。

と定義されています。
また本全体を通して、「リーダーはなろうと思ってリーダーになるのではなく、結果的にリーダーになるものだ」と強調されています。

リーダーシップを私の場合にあてはめてみると、

step1で「高度なシステム設計、開発手法の追求」という理想を抱き、
step2で理想の追求に向けたリーダーシップが養われ、
step3で結果的にリーダーとして認められた。副次的にマネージャーになった

と解釈することができます。

マネジメントとリーダーシップについて併記するなかで「技術、開発プロセスの高度なマネジメントを目指すリーダーシップ」というのは少々ややこしいですねｗ

マネージャーになり見る範囲が広くなって以降、私が持つ理想というものは自分や１チームや１システムに閉じない形で何個か増えており、事業、会社、社会に与える影響についてと少しずつ広がっていたりもします。

システムアーキテクトこそマネージャーになるべきだ

高度なシステム設計、開発手法を追求するのに、なぜマネージャーになるのが有効なのでしょうか。

チームトポロジーという組織設計の本に「システムアーキテクトこそマネージャーになるべきだ」という面白い提言があります。
アーキテクトがスペシャリスト、マネージャーがゼネラリストのような分類の仕方をすると一見逆説的に見えますが、この根拠はコンウェイの法則にあります。

コンウェイの法則はざっくり言うと「システム設計は組織構造に似る」です。
役割分担やコミュニケーションがうまくいってない部署が互いに作ったシステムは、うまく連携できなかったり、全体としてまとまりのないシステムになります。

この法則を逆手にとったのが逆コンウェイの戦略です。逆コンウェイの戦略は「適切なシステム設計になるように組織設計をする」ことです。
つまりシステムアーキテクチャの全体像を設計するシステムアーキテクトは、技術だけでなく組織構造や人事に対する影響力も必要とするのです。

能力のあるチームにはどんどん権限を委譲していくのが現代的な考え方ですが、組織構造や人事（必要スキルの定義、採用、教育、育成などなど）については多くの部分がマネージャーに留保されている場合が多いかと思います。
だからシステムアーキテクトこそマネージャーになるべきと言えます。

エンジニアリングマネージャーになってみてどうか

追求したい理想の面

理想的なシステム設計や開発手法の追求の点では、期待通り取り組めました。
なんでも自分で決定できるわけでは当然なく他者との調整がたくさん発生しますが、メンバーの時と比べてアクセスできる情報や参加できる議論は格段に増えました。

自分が直接コードを書く機会（楽しい）こそ減りましたが、もっと大きな課題に自分が取り組むために、人を通して成果を出す後方支援スタイルに変わりました。これもまた楽しいです。

負荷やスキルの面

負荷やスキルの面ではやってやれないことはなかったです。意外となんとかなりました。

エンジニアリングマネージャーは組織の成長に軸足を起きつつも、技術的な品質や開発プロセスにも責任を持ちます。
どこまで自分がやってどこからチームに任せるかはチームの力量とビジネス状況次第ですが、
チームとして失敗が許される、失敗から学べる、マネージャーとして緊急事態に対応できるだけの余白は確保するように動いています。

エンジニアリングマネージャーとして責任を果たしたり権限を有効活用したりするには、これまでに学んできた技術マネジメント、プロジェクトマネジメントに加えてピープルマネジメントも別途習得が必要になりました。
幸いにもピープルマネジメントの本は充実していたし、そのなかでもIT業界にフォーカスした本も多数ありました。なので大抵の勉強と同様、歴史や型から学ぶ→実践してみるでそれなりに形になりました。

新たにマネージャーに就くべき人を私が推薦する経験もしましたが、そもそも技術力のある人やリーダーシップのある人に声をかけるようにしています。
マネージャーへの道の声をかけられたけどやれるか心配な人は、声をかけられた時点でスキルにはある程度自信を持って良いのかなと思います。

感情の面

感情の面では、嬉しいときもあれば当然つらいときもあります。年間通すと嬉しい気持ちの方が多いです。
事業が成長したり持続性を向上できたときは嬉しいです。
メンバーや上司や関係部署の人や顧客が喜んでいたりすると、自分のことのように嬉しいです。
基本的に人とわかり合えることが楽しいです。

逆につらいときもあります。
「人間の悩みはすべて対人関係の悩み」という格言がありますが、（人との関わりが間接的な）システムと向き合う時間よりも、人と直接向き合う時間の方が多くなる分、悩み度は増幅されている気はします。
ただストレスマネジメントもスキルのうちというか、本を読んだり場数を踏んだ結果、ある程度折り合いをつけられるようにはなりました。

つらい気持ちと嬉しい気持ちが同時に起きることもありました。メンバーの退職です。
あるメンバーが仕事でやりたいWILLと、FLINTERSやグループの枠組みで提供できる業務がマッチせず話し尽くした末に退職に至ったのですが、
最後に「あなたが私のマネージャーで良かった」と言っていただいたときは凄く嬉しかったです。