2022年8月26日に出版された、エンジニア組織のマネジメントを解説した書籍『エンジニアリングマネージャーのしごと』。
マネージャーとしての心構えから、日々のふるまい、採用や評価、そしてキャリアについての考え方などを網羅的に取り上げており、「マネージャーになったばかりで勉強になる部分が非常に多かった」「全エンジニアリングマネージャーが読むべき」と話題の1冊です。
今回は、本書の翻訳者のひとりである吉羽龍太郎氏に、見どころはもちろん、ご自身の経験も踏まえたエンジニアリングマネージャーがぶつかりやすい悩みに対する解決策についてもお話を伺いました。
マネジメントの一歩目「自分を管理しよう」に多くの反響
――さっそくですが、『エンジニアリングマネージャーのしごと』について、特に吉羽さんが重要もしくは興味深いと思われたポイントなどを伺ってもよいでしょうか？
吉羽龍太郎氏（以下、「吉羽」）：本書は全18章、索引を入れて376ページというボリュームですので（目次はこちら）、ポイントをまとめるのはなかなか難しいのですが、まずは本書の立ち位置についてお話できればと思います。
簡潔に言えば、初めてエンジニアリングマネージャーになった方向けのマニュアルです。エンジニアリングマネージャーに限らず、VPoEやCTOもそうですが、組織をマネジメントするときに必要なスキルや考え方について、会社で教育を受ける機会はほとんどありません。しかし、そのポジションに就いた途端やらなければいけない。試行錯誤したり、少し上のポジションの人がいれば、その人をロールモデルにして見様見真似でやってみたり、特にエンジニア組織のマネージャーというのはそうやってこなしているパターンが非常に多いんです。
そういった方たちに向けて、最初の一歩として、網羅的に必要な知識をまとめたのがこの本です。第1部・第2部までは、前提知識を書いているところですので、まずはそこを押さえていただくと「エンジニアリングマネージャーとしてどういう仕事をすればいいのか」「日々をどう過ごすといいのか」が分かると思います。
――ありがとうございます。本書に関するイベントなども開催されていると思いますが、読者の反応はどうですか？
吉羽：もちろん人によってさまざまではありますが、2章の「まず自分を管理しよう」に反応をいただくことが多いですね。
内容としては、日夜押し寄せる膨大な量の情報をカレンダーやToDoリスト、メールなどのツールを使ってどう整理するといいかを書いています。「『自分自身の整理ができていないと、人のマネジメントなんてできない』というところが身につまされた」とか、「グサッときた」とかおっしゃる方が多いようです。
――いっぱいいっぱいで回らないといった状況は、やはりマネージャーになりたてのときは特に陥りやすいですか？
吉羽：そうですね。そもそもエンジニアリングマネージャーの仕事の幅は、組織によって大きく異なりますが、仕事が多岐に渡るため時間が細切れになりやすいのは確かです。
エンジニアであれば、ひとつのプロダクトやプロジェクトで集中してコードを書いて、あまりコンテキストスイッチが起こらない中で仕事ができます。しかし、マネージャーになるとそうはいきません。1on1をはじめ各種ミーティングが入っていたり、かと思えばトラブル対応が発生したりと時間が細切れになって、自分のことをきちんと整理できていないとそれだけで押し潰されてしまいます。
「そうならないように」というのが2章の話で、自分事に感じる方が多かったのだろうと思います。
マネージャーはチームのアウトプットを最大化する存在
――続いて、これも悩む方が多いかと思うのですが、個人のアウトプットとマネージャーとしてのアウトプット、そしてチームのアウトプット、バランスをどう取るのか、もしくは明確な優先順位があるのか、そのあたりはいかがでしょうか？
吉羽：本書では、マネージャーのアウトプットというのは、自分のチームのアウトプットと、自分が影響を与えた他のチームのアウトプットを合算したものであると示しています。ですので、重要なのは個人のアウトプットではなく、チームのアウトプット、もしくは自分が関係した組織のアウトプットだとはっきり言い切っています。
――吉羽さんご自身のお考えはどうですか？
吉羽：おおむね同意見です。わたしは外資系の企業と国内企業と両方でマネージャーを務めた経験がありますが、特に外資系では社内教育でも上司からも「チームのパフォーマンスを上げるのがマネージャーの役割」と強く言われていましたし、「マネージャーの仕事は部下を昇進させることだ」と言われたりもしましたね。
要はチームとしてパフォーマンスを上げるには、チームメンバーに高いパフォーマンスを発揮してもらって、さらに昇進してもらえば「マネージャーとして仕事をした」と言えるということです。そのためマネージャーにとっては、採用も重要な仕事のひとつです。
ただ、国内企業の場合は自身のアウトプットも人事評価上求められつつ、メンバーの面倒を見るというのも評価軸に入っていますよね。国内外でそういった違いはあるかなとは思います。
――エンジニアの評価もまた難しいと言われるテーマですよね。吉羽さんとしては目標設定や評価についてどうお考えですか。
吉羽：わたし自身もマネージャーとしてメンバーの目標設定や評価面談をする立場でしたが、これも国内外で大きな違いがありました。
国内企業の場合、多くは目標設定シートに期の目標を書いて、それに対して「ここを具体的にしてください」「もっと高い目標を掲げてください」と言って決めていました。そして期末くらいになると振り返りをするわけですが、世の中の状況がまったく変わっていて「このプロジェクトは頓挫してやりませんでした」ということがありました。
外資系では、世の中の変化が激しいのは前提で、期初に設定した目標は1on1の中で定期的に見直すのが普通でした。目標はまだ有効か、もっと他に優先すべきことはないかを常に考えて、必要であれば目標や数値を修正していました。そのためマネージャーは誰がどんな目標設定をしているかを把握して、よりチャレンジングな仕事を割り振る、グローバルで目立つような仕事をしてもらうということにも気を配る必要があります。
目標設定は一過性のイベントではなく、つねに業務に即しているものです。目標設定と評価はセットで、継続した見直しが非常に重要だと考えています。
――さきほど1on1の話が出ましたが、エンジニアチームに限らず1on1を実施している企業は多いと思います。マネージャーとして意識したほうがよいことはありますか？
吉羽：どの職種でも共通ですが、まずマネージャー側から日程の変更やキャンセルをしないのは鉄則だと思っています。
急に大事なミーティングに呼ばれた、お客さまとの会議が入った…など、マネージャーは割り込みも多く非常に忙しいのは分かりますが、そこで1on1を犠牲にするというのは、チームやそのメンバーよりもその割り込みのほうが大切だという意思表示になってしまうんですね。しかし、マネージャーはチームがいないと成果が出せません。そう考えると、優先すべきはチームメンバーとなります。
――なるほど。耳が痛いと思う方もいらっしゃるかもしれませんね。メンバーが多いと結構大変だろうなと思いますが、吉羽さんはどうされていましたか？
吉羽：わたしの場合、毎週月曜・火曜に1on1を集中させて、それ以外の曜日に他のことをやると決めていました。
そもそもの話ですが、国内企業だと特に1on1の実施自体が目的になっていて、形骸化しているところも少なくないのではないでしょうか。外資系は実効性を重視するので、マネージャーはまず「なんのために1on1をやるのか」という目的設定について教えられます。改めて1on1実施の目的を明らかにしてみてもいいかもしれませんね。
――企業によっては、ロールモデルがおらず、自分がはじめてのエンジニアリングマネージャーという場合もあると思います。よく分からないまま踏み出さなければならない人は、最初にどういったアプローチでマネジメントのスキルを磨いていくとよいのでしょうか。
吉羽：さきほどお伝えしたとおり、国内企業ではマネージャーとして教育を受ける機会はほとんどありませんので、本を読むのはひとつの方法ですよね。ただし、コーディングと同じで、マネジメントも本を読むだけでは身につきません。
本から得た知識を実際に1on1の場で使ってみて、さらにもう一歩踏み込むのであればフィードバックサイクルを回す必要があります。たとえば、1on1の相手に「今回の1on1どうだった？」と直接フィードバックをもらって改善ポイントを探したり、もし会社にマネージャー経験者がいるのであれば横に座ってもらって、あとから個別にフィードバックを得たりすることで良し悪しが分かり、成長にもつながります。
技術的なスキルの必要性は？ポイントは「チームの信頼を得られるか」
――エンジニアリングマネージャーとしてキャリアを築いていく方にとって、技術は実際どのくらい求められるものですか？技術以外にも必要なスキルはたくさんありますよね。
吉羽：エンジニアリングマネージャーとして、技術的な意思決定をしないといけない場面もありますから「技術は必要ですか？」と聞かれたら「必要です」という回答にはなります。
また、チームメンバーから技術に関する相談を受けることもあるので、メンバーが何を言ってるかすら分からないとなると信用されなくなってしまいます。「この人に相談しても、どうせ分からないんだろうな」となったらマネジメントどころではありません。ですので、チームのエンジニアと技術的な会話ができる、もしくは話を聞けばある程度理解できるだけの知識やスキルは絶対に必要だと思います。
ただし、コードをバリバリに書けて、他のエンジニアよりも技術的に優れていなければ務まらないわけでもないんです。マネジメントスキルは、エンジニアリングとは別のスキルです。そのためエンジニアとして優秀な人がすぐに優秀なマネージャーになれるとは言い切れません。
技術は会話の土台としては必要ですが、マネージャーとしては、マネジメントのスキルを磨いていく必要があるというのがわたしの答えになります。
あと、もうひとつ重要な話で、日本企業ではマネージャーになるのは片道切符のイメージがありますよね。会社の給与テーブルを踏まえると、管理職にならないと給与が上がらないモデルになっているのが、これまでの日本企業のスタンダードでした。
――以前は「エンジニア35歳定年説」もよく耳にしました。
吉羽：そうですね。最近は変わりつつありますけど、マネージャーが最終のキャリアパスみたいな考え方はまだまだあると思います。
でもエンジニアを極めていった先にたくさん給与がもらえるパスがあってもいいですし、マネージャーとしてどんどん上がっていって給与がもらえるバスがあってもいいです。もしくは、エンジニアからマネージャーになったあと、2年ほどやってもう1回エンジニアをやりたくなったら戻れてもいいと思うんです。
わたしがいた外資系のクラウドベンダーではまさにそういったキャリアパスを取ってる人もいて、マネージャーを数年やったら現場で手を動かしたくなったと戻ってきて、また行ってと。学び続けることができれば、そういったキャリアの築き方もできるようになります。
ピープルマネジメントが他との兼務が難しい理由
――昨今、多くの企業がエンジニアの中途採用に課題感があり、「人が辞めない環境づくり」について考えているマネージャーも多いと思います。単に給与を上げればよいという話でもないとは思いますが、吉羽さんのご意見を伺ってもよいでしょうか。
吉羽：難しい話ですよね。給与だけではないとは言え、長くいて欲しいと思う人材に「給与は十分渡せないけどずっとうちにいてね」は通じないじゃないですか。もちろん市場から見てそれなりに見合った金額をすでに出しているのであればよいですが、まったく見合っていないのであれば辞められて当然となってしまいます。
現代は、いわゆる「エンジニアが命綱」と言っても過言ではなく、ITの力なしでは企業が存続できない状況にあります。給与テーブルを無視してエンジニアを優遇してでもつなぎとめる、そういった認識を経営者に持たせないといけません。メンバーの給与が適正になるよう、組織に働きかけるのもマネージャーの重要な仕事のひとつです。
実際、どれだけ仕事がおもしろくても、「倍の年収でうちに来ませんか」と言われたら移る人は多いんじゃないですか。これが1.1倍で興味のない仕事となったら留まると思いますが、外資系のベンダーのように圧倒的な差でオファーをしてくるところも少なくありません。
あとは、給与などの条件面は十分だろうというのであれば、おもしろい仕事ができるか、プロダクトに魅力があるか、一緒に働いて楽しいと思える仲間がいるかあたりが重要になってきます。エンジニアだとよくある話ですが、エースをいつも炎上プロジェクトの火消し要員にしていると、あっという間にいなくなってしまいます。
――組織の規模が大きくなるとピープルマネジメントにかかりきりになってしまうイメージがあります。やはりプロジェクトマネジメントやプロダクトマネジメントとは切り離したほうがよいと思いますか？
吉羽：ケースバイケースですが、プロジェクトマネジメントやプロダクトマネジメントとピープルマネジメントってコンフリクトしてしまう部分があるんですよね。
たとえば、プロジェクトは大体予算と期日が決まっていて、やるべきこともある程度決まっています。その決められた中で完遂する責任をプロジェクトマネージャーは負うわけです。一方でピープルマネジメントをする立場で考えると、チームに持続可能な形で仕事をしてもらって、成長を促すところに責任が発生します。そのため炎上プロジェクトでチームメンバーを朝から晩まで働かせたり、残業や徹夜をさせるのはよくないという見方になります。
ここでもしプロジェクトマネージャーとピープルマネージャーを兼任していると、多くの場合、上司や顧客から責められるのを回避するために、チームを犠牲にしてプロジェクトやプロダクトを何とかしようとします。そういった圧力がかかりやすい環境においては、バランスが非常に崩れやすいため兼任しないほうがいいですね。
もちろん持続可能なペースでやればいいという合意があるのであれば、両方をうまくやることはできます。
――規模がまだ小さいスタートアップでは、複数の役割、特にマネジメントにおいてはひとりが兼任している場合が多いと思います。そういったケースでよい解決策はありますか？
吉羽：銀の弾丸はないのが正直なところです。ただ、プロダクトって一瞬のものではなくて長くやっていくものですよね。そう思うと一時的に何かを犠牲にしてうまくいってもほとんど意味がなくて、いつも安定したペースで提供できるほうが価値が高いと思います。マネージャーとして、真っ先にチームを犠牲にするっていうのはやってはいけないとわたしは考えています。
お客さまに多少怒られてでも期限の延長を申し出てみるなど思いつく限りのオプションを試してみて、それでも駄目だったらチームに相談するでいいと思います。
困ったときに手に取る、リファレンスとして重宝する1冊
――改めて、この本を読もうと思っている方へメッセージをお願いします。
吉羽：本書はベストプラクティスと呼ばれているものの集合体で、真新しい内容で占められているわけではありません。どこかで聞いたことのある話も多々含まれているでしょう。ただ、ここまで網羅的にまとめられているものはこれまでなかったように思います。通して全部読む必要はなく、手元に1冊置いておいて、困ったときにリファレンスとしてつど読んでいただくだけでも十分役に立ちます。
もとの英文自体、非常にわかりやすい書き方をしてあるため、堅苦しい文章でもなく読みやすいと思います。ページ数は多いですが、読もうと思えばさらっと読めます。
――これからマネージャーを目指す方、駆け出しのマネージャーにとって、『エンジニアリングマネージャーのしごと』は手元に置いておくのにベストな1冊と言えそうですね。最後に、吉羽さんが考える、エンジニアリングマネージャーの魅力とはなんでしょうか。
吉羽：チームの成長を間近で見られるという点ですね。
たとえば、「半年前と比べてチームの能力が目に見えて上がって、成果も増えた」といった成長は、メンバー自身より一歩引いた立場にいる人のほうがよく見えるものです。それが見えたときはやはり嬉しいですし、その変化が楽しみでもあります。だんだん「もう自分がいなくてもみんなやっていけるんだな…」といった寂しさを感じたりもするんですけどね（笑）
メンバーが会社を辞めたあとでも「あのチームにいたおかげで成長できました」と言われると、マネージャーとしては本当にうれしいと思います。
――ありがとうございました。
