エンジニアリングマネージャーになって1年がたった
私は，あるスタートアップ企業でエンジニアリングマネージャー（の，1人）をしている。toB向けSaaSを提供している数百名規模の会社で，社名が少しずつ世の中に知られるようになってきたくらいのフェーズ。会社からはDirectorという肩書をもらっていて，トラディショナルな日本企業だといわゆる部門長の層にあたる。中間管理職の中では上のほうで，執行役員の下あたり，というと伝わりやすいだろうか。
様々な事情（会社が大きくなった，比較的社歴が長い，そこそこの業界経験値がある，自分の専門領域(*1)に社内のフォーカスがあたるようになり，チームをスケールする必要が出てきた，etc.）から，半ば必要にかられて，重い腰を上げてエンジニアリングマネージャーとして活動を始めたのがちょうど1年ほど前。
決してマネージャーとして早咲きのほうではなく，IT業界でのキャリアは15年くらいで，これまではずっとプレイヤー，または小さなチームのプレイングマネージャーをやっていて，特にマネージャー志向でもなかった。好きなコードを書いて，楽しく仕事ができればそれで良く，なるべく管理職にはなりたくないなと思っているような，エンジニアとしてはどこにでもいるようなタイプ(*2)。
自分自身の役割を「スタートアップにおけるエンジニアリングマネージャー」と定めてからの1年は，これまでの自分の仕事の仕方はぬるかったんだな…と思うくらいにはハードで，とにかく沢山の学びがあったので，稚拙ながら感想文をインターネットに放出しておこうと思う。
(*1) 専門領域は，検索システムのバックエンド開発（と検索エンジン）という比較的ニッチな分野で，周辺分野である自然言語処理や機械学習もかじっている。この記事の著者のエンジニアとしての実績に興味がある方はGitHubのプロフィールを見てほしい。
(*2) どうでも良い話だが，パーソナリティは結構はっきりとしたISTJ，星座はふたご座（なのでコミュニケーターとして一定の素質があるとプラセボ効果で思い込んでいる）。
EMになって１年間でやったこと
多くは現在進行形で継続中だけど，とりあえず時系列で書く。計画的に取り組んだわけではなく，その場その場で一番必要なことをやっていたという感じ。
採用活動
チーム内で自分以外にシニアエンジニアがおらず，自分自身がチームの持つポテンシャルのキャップになっている状態だったため，まずは経験を積んだエンジニアの採用に注力した。JDを書き，面談し，面接をし，オファーレターを書く，の繰り返し。これまでの採用実績はシニアクラス3名（機械学習エンジニア，テックリード，SRE）とミドルクラス2名。いい人材が来てくれて本当に良かったと思うのと，スタートアップの採用において，ハイアリングするマネージャー自身の業界内での人脈とか知名度はめちゃくちゃ大事。会社にブランドがまだないときは，ハイアリングマネージャー自身が広告塔を兼ねざるを得ない。
チームビルディングと開発体制づくり
人が増えると，採用した人材のオンボーディング，ポジションメイキングと開発体制づくりが急務となる。1on1で状況を把握する，既存メンバーの業務領域とバッティングしない新しいプロジェクトへアサインする，既存メンバーと少しずつ接点を持ってもらい，入社から3か月たった頃にはチームの主力として働けているように体制を作る，など。入ってくれたメンバーはみんな，それぞれの立場で着実に成果を上げてくれていて，チームの拡大に最初不安はあったものの頑張ってよかった…と思う。
2,3年後を見据えた技術戦略を考える
他の領域と同様に，自分の専門領域（情報検索）も，昨年秋に起こったGPT-3.5またはChatGPTから始まる大規模言語モデルの地殻変動に巻き込まれている。好むと好まざるとに関わらず，大波に吞まれないように，逆に波を乗りこなしていかないと，数年後にはチーム，引いては会社が緩やかに衰退していくことはすぐに予想できた。個人レベルで知識のあるメンバーはいるものの，チームとしてのノウハウはなく，一方で開発の主力を担うメンバーは日々の業務で多忙で，アドバンスなことに急に取り掛かる暇があまりない。まだ海のものとも山のものともわからないようなエッジな技術に関しては，まずはマネージャー自身が手を動かし，オリジナル論文など信頼できる情報にあたり，今後持つべき技術資産についての方針を見定める必要があった。組織がある程度大きければ，手が空いていて新しいことが好きなメンバーに丸投げできるかもしれないが，スタートアップにそういった余裕をいつも作っておくのは難しい（これはタイミングにもよる）。
事業戦略，製品戦略を考える
これは若干想定外であったものの，いわゆる事業戦略，製品戦略といわれる，会社としてのハイレベルな意思決定に関わる機会が増えた。このへんはセンシティブなので詳しく触れることはできないのだけれど，いち開発者の視点とは全く異なる視座を持つ必要があって，視野が広がったと思っている（というより，トップマネジメントの大事さにあらためて気付かされたというべきか）。
開発チーム，開発プロジェクトのマネジメントと人事評価
まあ，エンジニアリングマネージャーだからそれはそうｗ
なのだが，スタートアップ特有のあれやこれやの組織事情により，一時的に10人前後のチーム x 2のマネジメントをやっていた時は死ぬかと思った（さすがに無理があったため，組織のリファクタリングを急ぎ，今はあるべき状態に落ち着いている）。
開発マンパワーがない，または足りていないプロジェクトのヘルプ
スタートアップのエンジニアリングマネージャーは，「チームメンバーに指示を出してプロジェクトを進める人」ではなく，「チームで成果を出すために，必要なことを全てやる人」なので，必要ならもちろんプレイヤーとしてコードも書くしインフラも作る（なお，これが複数のプロジェクトで重なった時が一番ツライ）。
ジュニアメンバーのメンタリングと成長支援
勤務先の会社では，少しずつではあるが，若手のエンジニアやインターン生の採用も行っている。ジュニアの指導ができるミドル～シニアクラスのメンバーにメンターをお願いすることになるが，やはりこの層は忙しいし不足しがちなため，受け皿がない場合はマネージャーが引き受けることになる。成長が早い人とマイペースな人がいると思うが，新人エンジニアが自走できるようになるまでに通常だいたい2年くらいはかかるので，長期戦で丁寧に向き合うように心がけている。伸びしろが大きな若い頃って大事だからね（メンターがあまりに仕事を抱えすぎて，放置気味になってしまう時期もあって申し訳ない…）。
EMになって1年で学んだこと
今も，いろいろな葛藤を抱えながら試行錯誤中だけど，EMという重責を果たすにあたって，これは大事にしようと思っていることを書く。
Doerであること
安定したチーム運営を行うために先を読み，できうる最大限のリスクヘッジをする，というのが，EMとしてごく当たり前に求められる役割。一方で，「安定」とは逆行する「リスクを取る」行動をチームメンバーの誰よりも積極的に行うリーダーでありたい，と思っている。エンジニアは基本的に保守的な生き物で，「安全側に倒す」ことを好む。エンジニアとして数年も下積みを経験すれば，リスクを読んで前もって抑えに動く，という行動はおそらく誰でも取れようになるし，プレイヤーとしての自分も，基本的に開発上のリスクは極力取りたくない。でも，自身をマネージャーと定義するなら，リスクを取ったその先の大きな（小さくてもいいけど）夢をチームメンバーに見せたいなと思う。
先が見えない不安定な状況を楽しむ努力をすること
マネージャーになると，メンバーよりも社内から様々な情報が入ってくるようになると思う。エンジニアは基本的に心配性な生き物なので，責任が与えられたスコープに新しい情報が入ってくると，いろいろとネガティブな結果を予測して，過度に防衛的になってしまったりする。常に状況不安定という中で「最終的にはなんとかなる（多分）」という開き直りが，私のようなふつうのメンタル強度の人間がマネージャーとしてやっていくのに，一番大事かもと思う。
余談だが，メンバーを自分よりも不安定な状態に置くのはマネージャーないしリーダーとしては失敗だと思っている。これについては Don’t Create Chaos という記事に詳しいので，ぜひ一読をお薦めしたい。
チームメンバーのWillを（半ば強引にでも）引き出すこと
ピープルマネジメントの原則だけれども，人は，上司や誰かから与えてもらった仕事をしている時よりも，自分でやりたいと思ってスタートさせた仕事をしている時のほうが，辛くても投げ出さないし，圧倒的にいいパフォーマンスを発揮する。よっぽど特殊な技能を必要とする仕事でない限り，その人のコミットメント度合いが，プロジェクト開始時点のハードスキル以上に成果に大きな影響を与える。
ジュニア～ミドルクラスのメンバーは，まだ自身の強みと言える分野がなかったり，そもそも自分がどんなことに興味を持っているのかわかっていなかったりする。得意なこと，長期的に追及したいことを見つけてもらうために，いろいろな種類のタスクをアサインするのに加えて，たとえ答えが返ってこなかったとしても「あなたは何がしたい？」と問い続けるのは，大事かなと思っている（1on1とかで毎回のように聞くので，いい加減しつこいと思われている可能性はある）。
組織やカルチャーは変えられる（適切なレバーを引けば！）と信じること
数十人規模の小さなベンチャーである時期は，上下関係というのはあってないようなもので，フラットな組織でも十分に仕事が回る。その後お客さんがつき，資金調達がうまくいき，順調に会社が成長すると，あるタイミングで組織は階層化され，それ自体は必要なことだけれど，副作用として縦割りの弊害が生まれる。また，創業期から会社を支えてきたメンバーと新しいメンバーの間で考え方やエンゲージメントの違いも生まれ，コンフリクトが社内で多発する。
こうした成長痛は，どんな会社でも大きくなる過程で経験するのだけれど，組織というのは生き物であり，モラルが死んでいない限り，どんなに現状が悪く見えても，変える意思と力がある人が適切な働きかけさえすれば，歩みはゆっくりでも必ずいい方向に変わる。自分自身と自分の周囲の人が動きやすい環境を作るためにも，マネージャーとしての権限と社内人脈をフルに活用して，時に役割を飛び越えて動くのも一つ大事な仕事なんだろうと思う（組織に関する話はさすがに具体例を出せないので，だいぶ抽象的になってしまった）。
最後に
つらつらと雑文を書きなぐったけれども，世の中には「エンジニアリングマネージャーの教科書」と呼べる本が沢山あって，ここに書いたようなことは本の中でおおむね語りつくされているのだろうし，迷えるエンジニアリングマネージャーは，先達の知恵をまずは座学で学ぶと良いと思う。
- 「エンジニアのためのマネジメント入門」（技術評論社，2023年）
- 「エンジニアリングマネージャーのしごと」（O’Reilly Japan，2022年）
- 「遊ばせる技術」（日本経済新聞出版，2021年）
- 「エンジニアリング組織論への招待」（技術評論社，2018年）
- 「Team Geek」（O’Reilly Japan, 2013年）
なお白状すると，私自身はこういった本を1冊も読んでいなくて，この記事は実践のみからくる経験則であることを付け加えておく。1年たって，未熟ながらもエンジニアリングマネージャーとして経験を少しは積んだ，と言えるようになったので，これから，本を読みながら答え合わせをしていこうと思う。
（閑話）
ところで，エンジニアリングマネージャーをやっていて，今後ずっとマネージャーとして働きたい人ってどのくらいいるのだろう？キャリアに不安を抱えているエンジニアリングマネージャーは多いと思うが，私自身も，マネージャーとして働くようになって以降，OSS開発や技術ブログ／書籍執筆，イベント登壇，といった技術コミュニティに貢献する機会がぐっと減ってしまって，エンジニアとしてこの先やっていけるのかという漠とした不安と日々戦っている。仕事と技術的な個人活動のコンテキストスイッチが大きすぎるんだよね…。マネージャーをしながらでも，たまにはプレイヤーとしてプロジェクトを持ったり，趣味の開発をして，いちエンジニアとして現役でいられる，またプレイヤーに戻れる，サステナブルな仕組みづくりができるといいなあ。
