エンジニアリングマネージャーからテックリードに戻ってみて役に立った３つの考え方

こちらは Voicy Advent Calendar 2021 9日目の記事です。

こんにちは、Voicyの元エンジニアリングマネージャーで現テックリードのみっきーです。2020年1月に入社して紆余曲折があり、2020年8月からはテックリードの役割で働いています。紆余曲折な出来事は、人事勝村がAdvent Calendarの6日目の記事モチクラ偏差値47だったVoicyがAAA獲得までにやった５つのことで書かれており、いろいろ会社に変化があったのでご興味がある方はこちらを読むのをオススメします。個人的な変化は会社のブログで書くのもアレなので気になる方はMeetyでお話しましょう。

本記事では、一度会社でマネージャーになると、現場に戻る道がたたれ、再度新しい技術を習得するには、転職するしかない！と考える人に向けて今後のキャリアの参考になることを書きました。数多くの面接をしていると、転職理由の中にマネージャーになってしまい技術力が足りなくなると思い、このままエンジニアとしてのキャリアが詰めないと考えて転職する方が少なからずいます。自分もマネージャーからエンジニアに戻るキャリアチェンジを複数回しているので気持ちはよくわかります。最近、巷では、エンジニアリングマネージャーからIC(Individual Contributor)にキャリアチェンジになることも話題になりました。

私も40代間近のシニアエンジニアですので、40歳以降のキャリアを考えるきっかけにもなりました。新卒からWeb開発をしてもう16年、最新のテクノロジーの進化に対して自分の技術の伸び悩みには強く共感しました。ICはメンバーの管理責任を追わない専門職の従業員のことだそうです。会社によってはテックリードと呼ばれていることもあると思います。管理者ではないとはいえマネージメントの仕事がすべてなくなってコードだけを書いているわけではなく、マネージメント対象の割合が変わったと考えるのが適切です。そして、マネージメントと一言で言いがちですが、実際はいくつかに分けることができます。自分がマネージメントをするときに、非常に参考になったnoteのマガジンにVPoE Handbookというのがあります。この中ではVPoEの仕事は４つに分解しています。VPoEとは、エンジニアリング部門のマネージメント責任者で、会社にCTOがいる場合は、テックとピープルのマネージメントを分けたりします。

Project Management
Process Managmenet
Team Build
People & Culture Managemenet

これらはVPoEに必要な役割として定義されており、自分の経験の中でマネージメントに必要な役割は５つに分類しています。

Project Management
Process Managmenet
Team/People Management
Culture Management
Technology Management

それぞれ

1は、目標どおりに機能などをリリースするために開発計画を立て期限までに実行すること。
2は、開発の生産性やデリバリー速度をあげるために、標準化や仕組み化をおこない改善すること。
3は、採用したエンジニアのチームの配置、仕事のアサイン、採用、育成すること。
4は、エンジニア組織の文化づくり。最近だと社内勉強会や輪読会、テックイベントの開催、テックブログ執筆などでお互い切磋琢磨できる仕組みを作ること。
5は、技術負債の返済、技術標準化、技術選定、システム連携など複数のサービスを結合したり、連携したりすること

これらは別のスキルであり、役割によって求められる期待値レベルが異なります。エンジニアリングマネージャやVPoEだと1,2,3,4で特に3と4にかなり時間をさくことが多く、テックリードは5が中心で会社全体の技術に底上げをおこないます。これらは、私は1がかなり苦手で、4,5,3,2,1の順で強みを発揮してきました。CTOになると経営視点にたち全体をバランスよく見ながら、それぞれの役割にもっとも強みを持った人に仕事を移譲できると気持ちも楽になっていきます。今後、マネージメントを学んでいくなかで、エンジニアとしてコードを書き続けるとしても、フリーランスではなく、組織の中で働くことを選んだ人に向けて、なかなか仕事をこなす中では身につきにくいが、意識すると視座が上がることを３つご紹介します。

1. 技術選定と面接は似ている。ソフトウェアのように柔軟に変化する人が活躍する

面接経験は会社が面接担当官に指名しないと経験を積むことが難しいのですが、技術選定は割と簡単に機会を得ることが出来ます。例えば、個人サービスを作ろうと思ったときにどの技術を採用するかは１人でも考えることができるからです。活躍できる人を選ぶことと、自社のサービスにSaaSやライブラリのインストールをしてプログラムに活躍してもらう点では同じ感覚になると思っています。（ただ勘違いしてほしくないのは、優秀な学生を安くバイトで使うという発想になるのはダメです）会社もOSと考えると、OSにソフトウェアをインストールすることと、組織に人を採用することは同じです。どちらも優秀な人/ソフトウェアを入れると、出来ることが増えますし、古い考え方/バージョンが残ったままだと時代の流れに対応できないこともあります。組織にインストールしたときに自らバージョンアップできれば活躍できる機会は増えますし、アップデートできなければ時代の変化に対応できないですが、安定したソフトウェアとして保守される続けることもあるので一長一短です。会社をOSで見たときに、自分がホーム画面に選ばれるようなソフトウェアになれるか、OSとして基盤を支えるものを作っていくかを考えると見方が変わります。マネージャーになることはわりとOSやライブラリを作ることに近く、より高度な技術を磨くためにも一度マネージャーを経験すると良いと思います。

2. コンウェイの法則を意識する

コンウェイの法則とは、「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」ことです。「エンジニアリング組織論への招待」などいろんな開発マネージメントの本に出てくる法則です。１つのサービスに閉じて作っていると、拡大していく中で必要な開発人数も多くなるが、人が増えるとコミュニケーションするパスが増えて開発効率は落ちます。最近のマイクロサービス化の流れも、コミュニケーションパスを小さくするために、一つのチームサイズを小さくする必要があり、その結果サービスを分割せざるをえないことになります。システム構造に合わせて組織を作ることをを逆コンウェイの法則と呼び、組織の拡大に合わせて人やソフトウェアを柔軟に変えていく必要があります。より上流工程に関わりたい人は、人を見ることとソフトウェアをうまく分割することの両方の経験が必要になります。そのためにもマネージャーとしてエンジニアリング組織を作るの経験と横断的なソフトウェア開発する経験を２つを意識して経験をつむと良いです。