マネージャーになっても、コードを書ける自分でいたかった。
技術に詳しく、いざとなったら自分でも実装できる。
ヤフーでマネージャーとして働いていた僕はそう思っていた。
でも、障害対応や炎上プロジェクトの火消し、予算や評価の仕事が増えるにつれて、コードを書く時間は減っていった。
それとともに、自分が思い描いていたエンジニアの姿から、少しずつ離れていった。
たしかにコードを書く時間は減った。でも、よく相談は受けるし、決めなきゃいけないこともある。どうやら、僕の仕事はまだあるらしい。
コードを書く以外に、僕は何ができるだろう。
僕は、ヤフー、楽天、スタートアップで、チームリーダー、部長、CTOなどの立場から開発に関わってきた。
この記事では、僕の経験をもとに、エンジニアリングマネージャー（EM）の仕事を4つの領域（ピープル・テクノロジー・プロジェクト・組織）に分けて紹介する。仕事内容と一緒に、うまくいったこと、失敗したこと、そこから考えるようになったことを書いていく。
途中、昔の僕を知っている人には「お前が言うな」と思われる箇所があるかもしれない。僕もちょっと思う。
それでも、仕事をするうえで忘れたくないことはある。この記事には、そんな自分用の覚え書きも混ざっている。
この記事でいうEMは、自社開発チームのマネージャー
この記事では、僕の経験上、事業会社の自社開発チームでのEMを取り上げる。仕事は、次の4領域に分けて紹介する。
- ピープル：一人ひとりの成長や評価に向き合う
- テクノロジー：技術の課題を解決する
- プロジェクト：開発を前へ進める
- 組織：人・時間・予算を使ってチームをつくる
僕は、EMをこの4領域全体に責任を持つ役割として捉えている。ただし、いつも全部を自分でやるわけではない。
小さなチームなら、採用や予算などの組織面を上司に任せる形もある。
メンバーが5人、10人と増えてくれば、チーム内での分担も考える。技術の判断はテックリードに任せる。スクラムマスターがいれば、開発の進め方や、進行を妨げる問題の解消を分担する。人数だけで決まる話ではないし、誰に何を任せるかにも、決まった形はない。このあたりが、EMの難しいところでもある。
また、今回はプロダクトマネジメントを独立した領域として扱っていない。僕の経験では、ビジネスサイドや企画サイドが担当することが多かったからだ。
ピープルマネジメント――誰だって不完全なのに、誰かの上司をやっている
メンバーと目標を考え、日々の仕事や困りごとを聞く。仕事の成果や取り組みを見てフィードバックし、評価を伝える。次にどんな経験を積めるとよいか、本人の希望も聞きながら考える。ピープルマネジメントは、そうした関わりを続ける仕事だ。
ただ、僕は「人を育てる」という言葉に、少し身構えてしまう。
自分だって不完全なのに、そんな資格があるのか？
エンジニアリングマネージャとは単なる役割の名称だ。人間的に優れている証明ではないし、威張っていい権利でもない。だからまず、相手を知り、一緒に仕事をする人として信用してもらうところから始めたい。
正論を言って、そのとおりに動くなら、マネージャーはいらない
20代で初めてマネージャーになった僕は、正論をかざしすぎて、チームメンバーから総スカンを食らった。
その頃の僕は、物事の伝え方とか、受け取った方の気持ち、納得感みたいなものを完全に無視して、自分が正しいと思うことだけを口にしていた。でも、正論は、相手の事情を聞かずに渡しても受け取ってもらえるほど、便利なものではなかった。
楽天に入ったとき、当時の上司から受けた助言がある。
君なら、この会社のやり方を見て、おかしいと思うこともあるだろう。でも、最初の3か月は黙って同僚の話を聞いてほしい。少しずつ実績を出して、お互いに信頼関係ができてから提案していってほしい。そういう内容だった。
僕は、とてもいい助言だと思っている。
新しく来た人が、今までの経緯も聞かずに改善案を並べる。その案が正しくても、相手には相手の事情がある。過去に試して失敗したことも、やりたくてもできなかった理由もあるかもしれない。
最初の3か月を、ただ黙ってやり過ごすという意味ではない。話を聞き、自分も仕事をする。その積み重ねの中で、少しずつ意見を交わせる関係をつくる。
正しいやり方を伝えれば終わりなら、ずいぶん話は早い。そのやり方で進められない事情を聞き、一緒に変えられるところを探す。そこに、マネージャーの仕事がある。
聞かれていないアドバイスは、したくないし、されたくもない
僕は、チームメイトから聞かれないかぎりアドバイスをしないことにしている。
もちろん、仕事上必要な目標の共有や評価のフィードバックは伝える。それは役割だ。ただ、自分の好みや経験談まで、相手が必要としている助言だと決めつけたくない。
スタートアップ企業に勤めていたとき、新任マネージャーのチームに配属されたことがあった。
彼は、担当のプロジェクトの理解が進んでないのに、議事録のタイポや週次レポートの書式には細かい。会議が終わってから、アジェンダはこうしたほうがよかったと言う。実プロジェクトで何をすればいいか分からず、自分がマネージャーとしてできることを探していたのかもしれない。
でも実際にそういう振る舞いを見ると、僕は「じゃあ、その場で一緒にやってくれよ」と思う。それより「実プロジェクトの課題を解決してくれよ」と思う。
誤字が減るのはいいことだ。でも、チームが困っているときに、マネージャーができる貢献がそれだけでいいのか。正直、この指摘であれば黙っていてくれたほうが現場は助かる。
される側でそう感じるのだから、自分が言う側に回ったときだけ、ありがたい話になるとは思わないほうがいい。
チームメイトに参考にしてほしいことは、もっと雑談っぽく共有したい。「牛尾剛さんの本、面白かったよ」とか、「このClaudeのスキル、便利だったよ」とか。相手が面白がって、使えそうなものを持って帰ってくれればいい。
その人が持っている力を、どうしたら仕事で発揮できるのか。僕はそこを考えたい。「育ててやる」と胸を張るより、相談されたときに、一緒に考えられる人でいたい。
テクノロジーマネジメント――技術に詳しい。それで、何を解決できる？
エンジニアリングマネージャは、技術方針や設計上のリスク、品質、保守性にも責任を持つ。性能の検証は足りているか。古い設計が開発を妨げていないか。詳しいメンバーと課題を整理し、必要な検証や改善に時間を使えるようにする。目の前の機能を作るだけでなく、この先も開発を続けられる状態を考える仕事だ。
ここでいう技術力は、最新のLLMやツールを知っていることだけではない。その技術で、事業や開発現場の何を解決できるか。そこまでつなげたい。
最新技術を追いかけるのはいい。でも、EM本人が全部に詳しく、すべての設計で一番いい答えを出さなければならないとしたら、かなり忙しい。たぶん人類であることが、最初のボトルネックになる。
僕は、サッカーチームの監督をイメージしている。自分より優れた選手がいるなら、その力をチームで活かしたい。監督がボールを奪って自分でシュートし始めたら、選手も困る。
技術に詳しい人の話を聞き、何が分かっていて、何がまだ分からないのかを整理する。必要な検証に時間を使えるようにする。自分が答えを持っていないときにも、引き受けられる仕事はある。
そのGPU数、何を根拠に決めましたか？
自分が未知の領域でも、ちゃんと技術的な裏付けを用意して、解決に導けるだろうか？
今の職場で、LLMを自社で動かしてAPIを提供することになった。コストと性能を考えると、OSSのモデルで十分だった。
で、プロジェクト全体でGPU数の見積もりを求められたことがある。
そのとき、誰も必要な台数を答えなかった。インフラチームにも、僕ら開発チームにも経験がなかった。誰も見積もりの責任を引き受けたくないように見えた。そして、最終的に、そのプロジェクトオーナーがChatGPTに聞いた見積もりで進めようとしていた。
いや、それで本番を迎えるのは怖すぎる。ChatGPTは台数を答えてくれるが、その台数で足りなかったときにGPUを届けてくれるわけではない。
僕がしたのは、実際に使うものに近いパラメータ数のモデルとGPUをAWSで用意し、ベンチマークを計測することだった。実測を判断の材料にした。本番は、今のところ問題なく稼働している。
ChatGPTに聞いて、最初の当たりをつけることはできる。ただ、その数字を自分たちの環境で確かめないまま、必要台数の根拠にしてしまうのは怖い。
この場面で、僕が最初から正しい台数を知っていたわけではない。知らないから、確かめるところから始めた。
分からないと言ったあとで、何をするか。その先にも、技術の仕事はある。
優秀なエンジニアが「大丈夫です」と言ったら、ベンチマークは省いていいか？
ヤフーで、炎上しているプロジェクトに助っ人として入ったとき、検索チームからアラートが上がった。
僕が、チームの中でも特に優秀だと思っていた人たちだった。半年以上かかる大規模なプロジェクトで、プロジェクトの後半でようやくデータが集まり、本番相当のインデックスができた段階で、性能の問題が分かった。
その設計は実績があり、今回のプロジェクトで大きく改修しないので、問題が出ない見込みだった。それが落とし穴だった。検索パターンが増えているのに、古いインデックス構造のまま対応したため、性能問題が出た。そもそも再設計が必要だったのだ。
「あの人たちなら大丈夫」という期待は、性能検証の代わりにはならない。優秀なエンジニアにも、まだ計測していない数値は分からない。
検索インデックスや、DBの設計は、実際にデータを入れてベンチマークを測ってみないとわからないことが多い。優秀なエンジニアの言うことは信頼しつつも、数値が出るまでは改修が発生する可能性を見込んでおくべきだ。
もっと言うと、大きく改修する予定がなくても、データ量や検索パターンが変わる部分は、開発初期に検証環境で性能を確かめておいたほうがよかった。そんなことは、分かっているはずだった。
誰に任せるかを考えることと、何を先に確かめるかを考えること。その両方が必要なのだと思う。人を信用することと、リスクを見ないことを、一緒にしたくない。
プロジェクトマネジメント――誰もサボっていない。それでも、プロジェクトは燃える
エンジニアリングマネージャは、開発の順序や担当、期限を整理し、進捗を見ながら計画を調整する。仕様が決まらない、他チームの作業待ちになっている、見積もりの前提が崩れた。そんな問題を見つけ、必要な人と話し、次へ進める状態にする仕事だ。
忙しそうな人がたくさんいる。やることも山ほどある。だから順調かというと、そうでもない。全員が頑張っていても、決まっていない前提の上で作業を進めれば、まとめてやり直しになる。
努力の量と、前へ進んだ距離が一致しない。そこを何とかするのも、マネジメントの仕事だと思う。
仕様書を上から実装しても、プロジェクトは前に進まない
仕様書に書いてある順番と、実装すべき順番は、同じとは限らない。先に決めることや確かめることが残っていれば、着手できるところから手を動かしても、あとで作り直すことになる。
先ほど検索性能の問題を紹介した、ヤフーのプロジェクトの話だ。
当時のリーダーに状況を聞くと、WBSが300行くらいあった。WBSは、仕事を細かく分けて整理したものだ。僕は、本当にこれで管理できているのかと聞いた。返ってきたのは「こんなにやることがあるんです」という、不満のような主張のような説明だった。
さらに、こんなにタスクがあるのに「なかなか仕様を決めてもらえないし、すぐ変更されるので、全然実装が進まないんです」とも言う。
やることが多いのは分かった。仕様変更がつらいのも分かった。ただ、それだけでは、明日どこから手をつければ状況が変わるのか分からない。
もちろん、行数が多いことが問題なのではない。見つけたかったのは、ほかの作業を止めている具体的なボトルネックだった。
僕が最初に手を付けたのは、DBの仕様だ。これが変わると、その上に載るアプリケーション側の仕様も次々と変わってしまう。多少のカラム追加や変更はしょうがない。テーブル構成そのものが変わったら、それは別のアプリケーションともいっていい。
そこで僕は、まずDBの仕様を決めるために必要な要件を整理し、その部分を先に確定させた。それに関わる人たちには、このタスクを最優先の課題にしてもらった。すべてを一度に決めようとせず、後続の作業を動かすために必要な部分を切り出した。
どのプロジェクトでもDBから決めればいいわけではない。このときは、DBの仕様がほかの作業を左右していた。依存関係をあぶり出し、何を先に決めれば後続の作業を進められるのかを判断する。そして、関係する人たちが、その課題を優先できるように調整する。そこにも、マネジメントの仕事がある。
自分が全部やらなくても、君がいるから力を出せる人がいる
自分が書いたプログラムにバグがあって、問題箇所が見つからない。同僚に助けを求めようとして説明を始めた途端、解決策に気づくという経験は、エンジニアなら、思い当たる人も多いだろう。
時として、そんな役割が必要なときもある。
僕がスタートアップのCTOをやっていたとき、AWSのAuroraのメジャーバージョンアップが必要になった。使っていたバージョンのサポート期限が迫っていたからだ。サービスを継続するために、期限までに終える必要がある重要な作業だった。
その作業をあるエンジニアに任せた。おそらくスキル的には問題のない作業だった。ただ、プロジェクトの途中で弱音を吐き出した。「最後までやり遂げる自信がなくなりました」。
そこで僕は、彼と二人でこのプロジェクトを進めることにした。とはいっても、実装や移行の操作は彼が担当する。僕は一緒に計画をつくり、毎週進捗を確認し、問題があれば一緒に調査した。
- 検証用に新しいAuroraを起動する
- 既存のデータ全量をコピーするテストをする
- そのDBで既存のアプリケーションが動作するかテスト（チーム全員で確認）
- 小さいインスタンスで新DB起動・データ移行・新DB切り替えをやってみる
- 本番相当のインスタンスとデータで同じことをやってみる（本番想定の確認）
これだけだ。当時は、新しいDBを用意してデータを移し、切り替える方法で進めた。
もちろんリプレース当日は関係者に協力してもらい進めて、無事完了。僕は、移行の操作そのものはしていない。でも、ちょっとしたバディ役になることで、彼が安心して作業を進められるようになった。
自分の技術で引っ張る面白さもある。ほかの人の技術と自分の仕事がつながって、チームで前へ進める面白さもある。自分が全部を実装しなくても、プロジェクトに貢献することはできる。
誰も引き受けない問題を、誰が引き受けるのか
楽天で働いていたころ、僕は楽天市場の一機能を担当するチームにいた。そのシステムは古いシステムを引きずっており、しょっちゅう障害が起きていた。（まあ楽天市場自体がでかいシステムなんで、ある程度しょうがないんだが）。
当時の楽天市場では運用と開発をあえて分離しておらず、障害が発生したら開発担当チームの開発エンジニアが担当していた。もちろん障害対応はもっともやりたくない仕事の一つだ。それでも、障害対応に率先して取り組むエンジニアは同僚からもリスペクトされたし、難易度が高い障害対応は、システムと技術への深い理解がないと対応できない作業だった。
ただ、当時のマネージャーはトラブルの最中にはほとんど姿を見せず、ほぼ解決してから「どうなった？」と聞くというのが常だった。対応に時間がかかると現場を急かしてくることさえあった。
問題を解決するのは部下の仕事。自分の仕事は、上司への報告。僕には、そう考えているように見えた。
それでは、部下からの尊敬は得られないし、チームワークは生まれない。伝書鳩だけだったらマネージャーじゃなくても誰でもできる。マネージャーが本当にすべきなのは課題の解決だ。それができなかったらうわべだけの指示しかできないだろう。
ただ、課題を解決するといっても、全部のコードを自分で直すという意味ではない。技術的な対応ができるなら手を動かす。状況の整理や判断、ほかの部署との調整が必要なら、そこを引き受ける。できないことまで抱え込んで、もう一人のボトルネックになる必要はない。
誰も引き受けない仕事には、自分から入る。そこでシステムの課題も把握する。チームで分担できる仕事は、メンバーに任せ、自分は判断や調整が必要なところを引き受ける。それがマネージャーの仕事だと思う。
組織マネジメント――ヒト・モノ・カネを管理して、それで何を実現したかったんだっけ
エンジニアリングマネージャーは、チームの目標に対して、どんな人材が必要か、誰に何を任せるか、時間や予算をどこに使うかを考える。採用したい人の条件を整理したり、新機能の開発と基盤の改善のどちらを優先するかビジネス側と話したりする。限られた資源で何を実現するか、方針を立てる仕事だ。
新しいものを作るために、一度作るのをやめた
ヤフーで、新しい組織のリーダーになったときのことだ。
エンジニアに話を聞くと、設計が古く、インデックスの追加やDBの拡張に繰り返し追われているという。その対応が、通常の開発を妨げていた。
目の前の容量不足に対応しても、また次の対応が必要になる。その間も、新しい機能を作る仕事はある。
ここで「もっと効率よく頑張ってほしい」と言ったところで、作業が消えるわけではない。リーダーの励ましでDBが拡張するなら、僕もいくらでも声をかける。
僕はビジネス側と話し、新規開発を一時的に止めた。その間にインデックスの設計を根本から見直し、DBも、3年程度は対応できる見込みの規模へ拡張した。
まとめて対応を終えたことで運用コストが減り、エンジニアが新規開発に集中できるようになった。
技術的な改善ではある。でも、組織の仕事として大事だったのは、その改善に時間を使えるようにしたことだと思う。
新しい機能を作りたいから、その開発をいったん止める。目先の要求だけを順番に受けていたら、こういう選択はできない。チームがこの先何をできるようになるのか。そのために、今何を先に終わらせるのか。そこまで考えて、ビジネス側と話す必要があった。
予算も同じだ。数字を管理し、帳尻を合わせるのは必要な仕事だとして、そのお金で何を実現したいのか。そこが抜けると、管理だけが残る。
自分より優秀な人を採用するのは難しい。自分より給料が高いなら、なおさらである
採用も、事業とチームに何が必要なのかから考えたい。
事業のP&L、つまり売上や費用、利益の構造を理解すると、どの領域にどんな力が必要なのかを考えやすくなる。単に忙しいから人数を増やす、という話から一歩進める。
僕は、自分にない能力を持つ人に来てほしい。その人に僕より高い給料を払うことになっても、当然だと思っている。
サッカーチームの監督だったら、メッシやクリスティアーノ・ロナウドがいたら心強いだろう。「僕より給料が高いので不採用です」と言う監督には、ファンも何か言いたくなると思う。
自分より給料が低く、自分と同じことができて、自分よりは優秀ではない。そんな人ばかりを探していたら、チームは自分の能力の範囲から広がらない。
もっとも、自分より優秀な人を見極めて、入社してもらうのは難しい。ここで書いているのは、僕が大切にしたい採用の方針だ。口で言ったら採れるなら、採用はこんなに難しくない。
でも、自分より優秀な人を採用できなかったら、組織は死んでいくと思っている。自分にない知識や経験を持つ人が加わり、チームにできることが増えていく。採用では、そういう成長をつくりたい。
コードを書く以外に、僕らがチームにできること
コードを書くことがエンジニアの仕事だと思っていた。それが自分のアイデンティティだった。
でも、いまはそれ以外のことをしている時間の方が長い。
自戒の念を込めて、コードを書くこと以外で、僕はチームに貢献できているだろうか？
この記事では、いくつかのパターンで僕がエンジニアリングマネージャーの仕事だと思っていることを紹介した。
もちろん、全部を自分でやる必要はないし、これ以外にも仕事はある。
でも、僕と同じような事業会社の開発チームのマネージャーは、だいたいこんな仕事をやっているんじゃないだろうか？
もちろん、僕自身、得意なこともあれば苦手なこともある。
うまくいったことよりも、失敗したことの方が多いかもしれない。
そんな経験を振り返って、自信を持って言えるのは、コードを書く以外にも、チームに貢献できる仕事はたくさんあるということ。そしてそれは、好き嫌いはあるにせよ、それなりにやりがいもあるということだ。
正直、僕はいまでも「コードを書くだけだったらどんなにラクで楽しいだろうか」と思うことがある。
でも、この記事を読んで、一人でもエンジニアリングマネージャーの仕事に興味を持ってくれたら嬉しい。
いや、エンジニアリングマネージャーをやらないまでも、誰かが今日もやっている、コードを書く以外の仕事を「俺も手伝ってやろうかな」と思ってくれたら嬉しい。それがチームワークにつながると思う。
エンジニアリングマネージャーへの転職も気になってきたら、僕が使ってよかった転職エージェントと情報収集サービスも参考にしてほしい。
