この記事でわかること
-
いち開発者からマネージャーへ移行する際の「焦り」や「不安」との向き合い方
-
技術だけでは解決できない「人・組織」の課題を解決する思考法
-
「エンジニアリングマネージャーの視点」を取り入れるメリット
エンジニアとして経験を積む中で、多くの人が直面するのが「マネジメント」へのキャリアパスです。現場でコードを書き続けたい思いと、エンジニアリングマネージャー（以下EM）への挑戦との間で葛藤し、「コードが書けなくなるのでは」「人や組織の課題を解決できるか」と不安を抱える方は少なくありません。
今回は、株式会社LayerXでEMを務める新多真琴氏にインタビュー。新多氏は『エンジニアリングマネージャーお悩み相談室』（翔泳社）の著者でもあり、現場のEMが日々抱える葛藤と、それを乗り越えるための具体的なアドバイスを発信し続けています。
本記事では、マネジメントを目指すエンジニアや現役EMの「リアルなお悩み」をピックアップして、課題を乗り越える思考フレームや、「EMの視点」をインストールして市場価値を上げる方法まで、詳しく語っていただきました。
新多 真琴
株式会社LayerX エンジニアリングマネージャー
ソフトウェアエンジニアとしてキャリアをスタートし、前職では執行役員CTOを務めた。現在はLayerXにてマネジメント支援のプロダクト開発を行いつつ、コミュニティ「EMゆるミートアップ」、カンファレンス「EMConf JP」を運営している。著書に「エンジニアリングマネージャーお悩み相談室 日々の課題を解決するための17のアドバイス」。
エンジニアリングマネージャーお悩み相談室 日々の課題を解決するための17のアドバイス
出版社：翔泳社 著者：新多 真琴
https://www.shoeisha.co.jp/book/detail/9784798189840目次
開発現場からエンジニアリングマネージャーへ。広がる視野と「AIネイティブ」な次世代マネジメント
まず、LayerXにおけるこれまでの役割やミッションについて教えていただけますか。
入社してからは、EMとエンジニアのロールを行き来しながら仕事をしてきました。これまではAIエージェントサービス「バクラク」の事業部で、プロダクトの共通基盤や経費精算プロダクトの開発担当として、ピープルマネジメントはもちろん、プロダクトのロードマップ策定や技術投資方針の決定などを担ってきました。
また、チーム内だけでなく関係各所とのステークホルダーマネジメントも重要な役割の一つでした。経営陣や他部署、時にはお客さまなど、立場の異なる関係者と意見を調整し、プロジェクトを円滑に進めるための業務です。自身もエンジニアとして手を動かしながら、チームやプロダクトの成長フェーズに合わせて柔軟に対応してきました。
急成長する組織の中で、現在はどのような業務を担っているのでしょうか。
現在はプロダクトづくりの最前線のマネジメント業務から少し離れ、社内向けに目標設定から評価までのマネジメントサイクルを「AIネイティブ」に再構築するプロジェクトを推進しています。
目標設定や評価をAIで構築するというのは非常に先進的な取り組みですね。マネジメントの領域にまでAIが入ってくることに驚きを感じますが、どこまでAIに任せるような想定なのでしょうか。
人の手を完全に介さないようにするというよりは、より事業や会社、そして個人のやりたいことが接続されるような「支援」をAIに行わせるという方向性です。目標を立てるプロセスには、企業や個々の「意思」が反映されるべきだと考えています。
例えば、メンバーがこれまでどんな開発を行ってきたのかという実績をAIで簡単に収集・整理できるようにする。それをもとに、マネージャーとメンバーが同じ情報を見て、成果に対して同じように判断できるようになるためのサポートですね。現在は、その構想を社内で活用できる状態まで落とし込もうとしている段階です。
AIを「マネジメントの意思決定をより正確にするためのインフラ」として活用するわけですね。こうした新しいプロジェクトを牽引されている新多さんですが、そもそもプレイヤーからマネジメント職へキャリアを移行した際、ご自身の中でどのような変化がありましたか？
一番の変化は、見るべき範囲や自分が動かしていい範囲が広がるということです。プレイヤー時代は「自分のこと」を中心にチームを考えていましたが、マネジメントに移るとそれが逆転します。まずチームや事業を主軸に置き、個人はその後に位置づけるというように、視野が大きく広がりました。
予算をどう決めるか、採用人数に対して事業活動が生み出すキャッシュとのバランスが合うかなど、最初は判断の感覚をつかむのに苦労しました。ただ、「現状を観察し、仮説を立て、行動して、評価する」という仕事のアプローチ自体は変わっていません。
| 項目 | 開発者（プレイヤー） | マネージャー（マネジメント） |
| 主軸となる考え方 | 自分のタスクや成果を中心にチームを考える | チームや事業を主軸に置き、個人をその後に位置づける |
| 主に意識する範囲 | 自身の開発タスクや担当する技術領域が中心 | 予算策定、採用計画、事業とキャッシュのバランスなど広範に及ぶ |
| 仕事の基本アプローチ | 現状を観察→仮説を立てる→ 行動する→評価するのサイクル | 対象が広がるだけで、基本サイクルは開発者時代と変わらず同様に回す |
| 問題解決の視点 | プロダクトを動かす技術的な仕組みにアプローチする | 組織を動かす仕組みにアプローチする |
現場を離れ「エンジニアリングの勘」が失われる不安との向き合い方
視野の変化に戸惑いつつも、仕事の基本サイクルは変わらないというお話は、これからマネジメントを目指す方にとって心強いメッセージですね。ここからは、現場のEMやEMを目指すエンジニアからの「リアルなお悩み」について、新多さんに具体的なアドバイスを伺っていきたいと思います。
最初のテーマは、開発者からマネジメント職へ移行する際、多くのエンジニアが抱える「コードを書けなくなる焦り」や「現場を離れることでエンジニアリングの勘が失われる恐怖」についてです。新多さんご自身は、そうした不安を感じることはありましたか？
私自身はプレイヤー時代から、個の集団として何かをするより、それぞれの活動がシナジーを持ってチームの成果につながる方が良いと考えていました。そのため、「チームでうまくやる」ことへの関心の延長としてマネジメントにも興味を持ち、トライしてみたという感覚に近いですね。そのため、「マネージャーになるならエンジニアリングを手放さなければいけない」といった二項対立のようには捉えていませんでした。
もともとチームの成果最大化に目が向いていたのですね。とはいえ、現場から離れることに焦りや不安を感じるエンジニアには、どうアドバイスされますか？
マネジメントのキャリアパスに進んだからといって、何もエンジニアに戻れないわけではありません。マネジメントかエンジニアリングかの二者択一ではないんですよね。これまで培ったものを生かして何ができるかを、その時々で考えていくことが一番大事です。
また、その「怖い」という感情がどこから来ているのかを掘り下げることも重要です。人間は生存本能として、わからないものに対して恐怖を感じるようにできています。自分が変化することへの恐れなのか、それとも例えば「人を評価しなければならないこと」への恐れなのか、恐れの質によって対処すべきアプローチは異なります。
| ステップ | 目的・アクション | 具体的な考え方 |
| 1. 恐怖の根源を言語化する | 漠然とした不安を可視化する | 放置せず、「自分は何がわからないから怖いと感じているのか」を自己分析する。 |
| 2. 恐怖の「対象」を見極める | 不安の正体を特定する | 自分が変化しコードを書けなくなることへの恐れか、あるいは他者を評価することへの恐れなど別の要因かを見極める。 |
| 3. 役割は「二者択一」ではないと知る | キャリアの柔軟性を理解する | マネージャーになってもエンジニアに戻ることは可能。これまでの経験を活かせる道をその時々で探る。 |
| 4. マネジメントも一つの技術と捉える | 新たなスキルの獲得と捉える | コードを書く代わりに、人や組織を動かす技術を身につけていると考え、スキルの獲得を楽しむ。 |
なるほど。恐怖の正体をまずは見極めるということですね。マネジメントにおける「人を評価すること」に対して恐れを抱くエンジニアも多いと思います。新多さんは評価をどのように捉えていますか？
評価とは、マネージャーなどの評価者が一方的にメンバーなどの被評価者を断罪するものではありません。お互いが合意した目標に対して、成果としてそれを満たしたかどうかを一緒に点検し、振り返るプロセスです。
極端な例だと、「いい感じに頑張って」と曖昧な指示で送り出して、期末に「思っていたのと違った」と言うのは、ただメンバーを振り回しているだけです。目標という同じものを見て、期中に現在地について話すことができていれば、自然とお互いにギャップを認識できるようになるので、恐れは軽減されるはずです。
期中に期待値を擦り合わせておくことで、期末の評価が「断罪」にならずに済むのですね。
はい。面接の場などでも「人が人を評価するとはどういうことか」と身構えてしまう方がいますが、あくまで「お互いにした約束に対して、定められた期間の動きを見てどうだったか」を一緒に振り返るものだと捉えれば、向き合い方は大きく変わると思います。
急激な環境変化でチームの方向を見失ってしまった時のゴール再設定
評価とは「一緒に振り返るプロセス」という言葉は、プレッシャーを感じているエンジニアにとって非常に気持ちが楽になる考え方ですね。
続いてのお悩みは、急成長する組織において経営方針の急な変更などでチームの目標がブレてしまい、現場のEMがリアルな葛藤を抱える状況についてです。メンバーの向きもバラバラになってしまう中で、マネージャーはどのようにゴールを再設定すればよいのでしょうか？
環境が変わったことで、もともと持っていたチーム目標の有効性が下がってきている状態ですね。まず最優先すべきは、マネージャー自身が「状況が変わった」という事実を認識し、チーム全体で共通認識を持つことです。昨日までの自分たちと今日からの自分たちでは、目指すべき方向が変わったんだと合意できる状態にすることが第一歩になります。
いきなり新しいタスクや開発手法を押し付けるのではなく、まずは「前提が変わった」という目線合わせから始めるのですね。このステップを飛ばしてしまうと、メンバーの不信感にも繋がりそうです。
これを怠ると「状況は変わった気がするけれど開発の進め方は今まで通り」というちぐはぐな状態になってしまいます。経営陣から「このままではダメだ」と言われても、具体的にどうすればいいか現場が分からないケースは多いですよね。
そういう時は、マネージャーが何かしらの「たたき台」を作って、「チームとしてはこういう方向に変えていこうと思う」と提示し、全員で議論しながら新しいゴールを合意・設定していくプロセスが有効だと思います。
| ステップ | アクション内容 | 目的・効果 |
| 1. 状況変化の認識と共有 | マネージャー自身が環境変化を認識し、チーム全体で「状況が変わった」という事実を共有する。 | チーム内にくすぶる「このままでいいのか」という不安を払拭する。 |
| 2. 方向性の転換の合意 | 昨日までと今日からで目指す方向が変わったことを、チーム全員でしっかりと合意する。 | メンバー全員の目線を新しいゴールへと向ける。 |
| 3. 新たなゴールの叩き台作成 | 経営方針などを踏まえ、抽象的な課題を具体化し、マネージャーが新たな方向性の叩き台を作成する。 | 議論の土台を作り、スムーズな意見交換を促す。 |
| 4. チーム全体での議論と決定 | 叩き台をチームに提示し、全員で議論しながら新しいゴールを合意・設定し、納得感を高める。 | チームとしての当事者意識（オーナーシップ）を醸成する。 |
| 5. 日々の活動との紐づけ | 再設定した目標と日々のタスクがどう結びついているか、スプリント等の単位で定期的に確認する。 | 目標の形骸化を防ぎ、日々の業務の意義を実感させる。 |
急成長する組織では、情報量が多くキャッチアップだけでも大変かと思います。目標のブレを防ぐために工夫されていることはありますか？
目標は立てて終わりになりやすいため、定期的に振り返る場を設けるようにしています。例えば、スクラム開発でのスプリントごとの振り返りのタイミングで、一旦目標を見直し、この期間でやってきたことが目標にどう紐づいたかを確認します。
また、四半期や半期の単位では、チーム全体で「半年前と比べてこんなことができるようになったね」と属人化の解消やスキルの向上を可視化し、みんなで称え合うような文化を大切にしています。
相手にとって耳の痛い「フィードバック」がうまくできない時の考え方
目標との紐づけを定期的に行い、成長を可視化して祝う文化は素晴らしいですね。
最後のお悩みは、モチベーションの低下や評価の不満など、技術では解決できない「人」の課題についてです。価値観の異なるメンバーに対して、指摘される側にとって受け入れがたい課題の指摘（ネガティブなフィードバック）をするのが苦手だというマネージャーは多いです。こうした耳の痛い指摘には、どう臨めばよいのでしょうか？
どこを目指したいかについてお互いの合意ができていれば、その進みを妨げる要因について話し合うことは自然にできるはずなんです。「指摘しなければならない」と意気込むのではなく、「自分からはこういうふうに見えるよ」と伝え、相手の解釈を聞き、一緒に考えるステップにすることが大切です。
相手を言い負かそうとするのではなく、あくまで「自分からの見え方」という事実と解釈を共有して対話する姿勢ですね。この視点の切り替えは非常に実践的だと感じます。どうしても感情的になりそうな場面でも冷静になれそうです。
「相手に厳しく指摘しなければ」と身構える必要はありません。また、相手が不機嫌になるだろうと分かっているケースは確かにつらいのですが、それは「相手がネガティブな反応をすることで自分ががっかりしたり、嫌な思いをしたりする」のを避けたいという心理でもあります。
自分が嫌な思いをするのを避けるために問題の解決を後回しにすると、チームの状態がさらに悪化してしまいます。
| 項目 | よくあるNGな考え方 | 目指すべきOKな考え方 |
| ① 目的の転換 | 人格や性質を否定し、相手の悪いところを正して言い負かそうとする。 | 目標達成を妨げる要因について、自分からの見え方（解釈）を共有する。 |
| ② 心理的ブロックの解除 | 相手が不機嫌になるのが怖く、波風を立てることを避けてしまう。 | 自分が嫌な思いをしたくないという自己保身に気づき、チームの成果を優先する。 |
| ③ アプローチの転換 | 自分の考えを押し付け、一方的に行動の改善を要求し続ける。 | 相手の解釈を聞いて一緒に考える。難しい場合は役割変更など仕組みで解決する。 |
| ④ チーム全体での最適化 | 本人の努力不足だと断定し、個人の力だけで問題を解決させようとする。 | 強みを生かし弱みを補えるよう、横にサポート役をつけるなどチーム構造を見直す。 |
なるほど。個人の対立ではなく、チームの成果を妨げる要因を取り除くという観点に立つことが重要なのですね。
はい。また、どうしても改善が難しい場合は、本人が変わることを期待し続けるのではなく、その状態を抱えたままチーム全体が良くなるための仕組みを考えるのも一つの手です。突破力はあるけれど細かい作業が苦手な人には、細かいところが得意な人がサポートに入るなど、弱みを補い合い強みを活かし合えるチームを作ることもマネージャーの役割です。
チームの枠を超え、事業や経営の視点を身につけるための思考エクササイズ
ここまでマネージャー視点でのお話を伺ってきましたが、現在いち開発者として働いていて、目の前の開発課題に追われている中堅エンジニアが、事業や経営といった広い視点（EMの視点）をインストールするためには、どうすればいいのでしょうか？
第一歩としては、自分が上げた直近の成果を「1段階抽象化して語る」練習がやりやすいと思います。例えば、チームマネージャーであれば、一段上の部長の視点に立って、「この部全体に対して、自分たちのチームの成果はどう効いたのだろうか」と考えてみるんです。
つまり、現在の自分の役職の一つ上のレイヤーが、事業計画などを見据えて考えているであろう少し先の未来の視点に立って物事を捉え直してみる、ということですね。
なるほど。いきなり「経営視点を持て」と言われると難しく感じますが、一つ上の役職の視点で自分の成果を捉え直すというエクササイズなら、明日からでも実践できそうです。
そして、上長との1on1などの場で、「自分はこう考えたのですが、実際のところどうですか？」と答え合わせをすると良いでしょう。このように一段視座を上げて成果を語ることを繰り返す中で、事業や経営の視点とはどういうことなのかをボトムアップ的に身につけていけると思います。
| ステップ | アクション | 得られる効果 |
| 1. 直近の成果の把握 | 自分が達成した具体的な開発成果やリリース内容を言語化する。 | 自身の貢献度を正しく認識できる。 |
| 2. 1段階の抽象化 （上位役職の視点） | 「この成果は、部全体や事業部全体にとってどのような意味や効果があったか？」と上位者の視点で考える。 | チームの枠を超えた「事業貢献の視点」を持てるようになる。 |
| 3. 上長との答え合わせ | 1on1ミーティング等で、自分の解釈を上長に伝え、事業方針と合致しているかフィードバックをもらう。 | 経営陣やマネージャーとの認識のズレを修正できる。 |
| 4. 視点の定着 | このサイクルを反復し、常に「より広い範囲で成果を捉える」思考の癖をつける。 | 視座が一段上がり、評価される人材へと成長できる。 |
| 5. フォロワーシップの発揮 | 得られた視点を活かし、チームの課題解決やマネージャーへの改善提案を主体的に行う。 | 組織全体への影響力が増し、市場価値の向上につながる。 |
マネージャーの視点を持つことは、仮にプレイヤーのままであっても大きな武器になりそうですね。
間違いないですね。一度マネージャーの立場を経験したり、その視点を持ったりすると、効果的な「フォロワーシップ」が発揮できるようになります。例えば、メンバーが評価を気にして言いにくい意見を代弁したり、マネージャーから見えていない現場の「やりにくさ」を拾って改善提案を出したりできる。
また、会議の進行や部分的なリーダーシップも、必ずしもマネージャーだけがやらなければならないものではありません。持ち回りでやってもいいわけです。マネージャーの視点を知ることで、チーム全体の成果に大きく貢献できるようになります。
最後に、マネジメントに進むべきか、技術を極めるべきかで悩んでいる中堅エンジニアに向けて、メッセージをお願いします。
「マネージャーになろうとしてなる」というよりは、「目の前の業務に向き合っていたら、気づいたらなっていた」という状態の方が健全な気がするんですよね。最初から「マネージャーにならなきゃ」と肩肘を張るのではなく、目の前のチーム課題に全力で向き合い、どうすればもっとチームの成果を出せるかを考えて行動しているうちに、周囲から自然とマネージャーの役割を任されていた、という流れの方が、本人のモチベーションとしても無理がありません。
そして、「強いエンジニアになれないからマネージャーへ」といった後ろ向きな理由だと苦しくなりやすいと思います。ですから、まずは目の前で任された仕事を全力でやりきり、「自分は何を任されているのか」を客観的にメタ認知するところから始めてみてください。 そうした一段上の思考を持てるようになれば、将来マネジメントに進む上でも必ず役立ちます。マネジメントに必要なスキルは、必要になったタイミングで学ぶ方が吸収率が良いものですし、迷っているなら一度チャレンジしてみて、違ったら引き返せばいいと思います。
ライター
