エンジニアからエンジニアリングマネージャーへ：実際に何が変わるのか

昇進ではなく、キャリアチェンジ

実は近いうちに、自分自身がこの転身をすることになりました。それもあって、ここしばらくは経験者に話を聞いたり、手に入る本を読んだりしています。今のところ一番はっきりした学びはこれです。エンジニアからエンジニアリングマネージャーになるのはステップアップではなく、まったく別の仕事への横移動だということ。自分のアウトプットはコードではなくなり、チームが生み出すものすべてになります。誰もがそう言うのに、誰もがその大きさを見誤るらしいのです。

実際に何が変わるのか

技術的な問題を自分の手で解く仕事から、人にまつわる問題を解く仕事に変わります。カレンダーは1on1と計画ミーティングとチーム間調整で埋まり、採用もパフォーマンスレビューも自分の机にやってきます。仕事の中心は、チームが仕事に集中するために必要なもの、つまり背景情報と明確な優先順位、そして余計なノイズの少なさを確保することになります。

厄介なのは、アーキテクチャの議論についていけて、まともな技術判断を下せるだけの技術力は保ちながら、「コードを書くのは自分ではない」と受け入れなければならない点です。両方やろうとしたマネージャーを何人か見てきましたが、たいてい両方とも中途半端になっていました。

エンジニアとエンジニアリングマネージャーを並べてみる

経験者からいちばんよく釘を刺されるのが、このフィードバックループの行です。エンジニアなら、ほぼ毎日なにかしら小さな手応えがあります。マネージャーにも手応えはちゃんとあるのですが、届くのが遅い。自分の判断が正しかったのかどうか、しばらくわからないままでいることに慣れる必要があります。

大事になりそうなスキル

仕事の大半はコミュニケーションです。チームとプロダクトと経営層のあいだの通訳になり、この3者が同じ話をしているかを確かめるだけで、驚くほどの時間が過ぎていきます。どんなプロセスより効くのは信頼です。「ここが壊れています」と安心して言ってもらえない限り、問題を一番最後に知るのは自分になります。カレンダーは油断すると本当に予定で埋め尽くされてしまうので、考える時間とチームのための時間を守るのは終わりのない戦いです。そして、会社が何を達成しようとしているのかを理解していなければ、チームをまともな方向に向けることもできません。

肩書きが来る前の準備

繰り返し聞いたアドバイスで、自分でも保証できるのがこれです。肩書きをもらう前からリードを始めること。プロジェクトを回す、誰かのメンターになる、何かを立ち上げる。私自身、この1年ほどプロジェクトリードとしてやってきましたが、その経験がどんな本よりも効いています。とはいえ本も役に立ちます。Camille Fournierの “The Manager’s Path” はみんなが薦める一冊で、読んでみて理由がわかりました。技術力も磨き続けてください。アーキテクチャ論争はなくなりませんから。そして、すでに転身を経験したメンターを見つけること。後から見れば当たり前に思える失敗を、事前に避けさせてくれます。

トレードオフ

ものづくりの方向性への影響力は増えますが、自分の手で作ることはほとんどなくなります。それが気持ちいい日もあれば、コードが恋しくてたまらない日もあるはずです。経験者は口を揃えて「それが普通」と言います。半年後にまた聞いてください。