トップ > テクノロジー > じぶんが管理職になれるわけないじゃん、ムリムリ! (※ムリでもやるんだ!!)

じぶんが管理職になれるわけないじゃん、ムリムリ! (※ムリでもやるんだ!!)

テクノロジー 事例紹介 セキュリティ アドベントカレンダー

この記事は、 NTT docomo Business Advent Calendar 2025 の15日目の記事です。

皆さまどうもこんにちは、@strinsert1Na という人です。以前は株式会社エヌ・エフ・ラボラトリーズという会社に出向しながらバリバリ「脅威インテリジェンス」のお仕事をしておりまして、今年の7月からはNTTドコモビジネス 情報セキュリティ部の管理職として新たなキャリアを歩んでおります。

ここまで書くと「なんだ、ただの順調にキャリア形成している人のめでたい話か」と思われてしまいそうですが、そんなことはありません。正直なところ、ほぼ毎日「(あんなやり方でよかったんだろうか…)」という不安の言葉が頭の中を駆け巡るような日々を過ごしており、半年経過した現在でもプレイヤーと管理職のロール/責任の違いにてんてこまいな状態です。 この記事では、社会人人生をずっと”エンジニア(プレイヤー)”としてだけバリューを出し続けてきた筆者が、管理職になって発生した苦悩やモヤモヤ、そしてそれを解決するためにとったアプローチについてまとめたいと思います。 もし同じような境遇になって苦しんでいる人や、これからエンジニアリングマネージャーのキャリアを目指す人にとって何かしらの希望になれば幸いです。

ひとよひとよに管理職(マネージャー)…

まずは筆者がプレイヤー時代にどんな働き方をしていたかについて、経歴を含めて紹介します。 一言でまとめると「子会社出向して技術力とアウトプットの魅せ方に注力を置いていたら、プレイヤーとして高く評価された」といった状況です。

  • 旧NTTコミュニケーションズに入社、新入社員研修を終え1年目で株式会社エヌ・エフ・ラボラトリーズへ出向
  • そこから約6年間、エンジニアリングチームでセキュリティプロダクトの開発・運用・マルウェア解析、脅威インテリジェンスの生成業務をプレイヤーとしてひたすら頑張る
  • チームメンバーはマネージャーを除くと20代から30代のみで、技術獲得に対するモチベーションが非常に高い
  • 雑談の場でも共通の話題で盛り上がりやすい
  • マネージャーっぽい動きはほとんどしてこず、ただただ向上した技術力で顧客が喜ぶモノを高打率で作れるようになったことと、アウトプットの魅せ方が多少うまかったという理由だけで良い評価をいただく場面が多かった

こんな状況が現場でしばらく続いた結果、とんとん拍子で昇格して社会人8年目でターニングポイントが来ました。 それはスペシャリストになるかマネージャーになるかの選択です。 ここまで読んでいただいた方は「いやいやそんなに技術一本でやっていくならスペシャリスト選択しろよ」と思うかもしれません。 しかしながら、NTTドコモビジネスの場合はスペシャリストのロールにリーダーとしてチームをリードするまでの権限がなく、チームを作っていきたいと思うならマネージャーの道を選ぶ必要があります。 筆者はこれまで仕事をしていく中で技術をとことん極めるというよりも「よいエンジニアリングチームを作っていきたいなぁ」という気持ちが勝り、マネージャーとなる選択をしました。

選択をした当時は「これまでのマネージャーの動きやチームビルディングの方法論は知っているし、大丈夫なはず!」と思っていました。 ですが筆者はこの7年間でたった2つの(しかもバリバリのエンジニア集団のみで構成された)チームしか知りません。この考えが浅はかすぎるということを、筆者は後々知ることとなります。

ふたやく以上での立ち回り…!?

このような背景のもと、筆者は親会社のNTTドコモビジネスに戻り晴れてそこで10人チームのマネージャーをすることになりました。 「さて、これから良いチームを作っていくぞー」と意気込んだところですぐ問題に直面します。

「……あれ、タスクってどうやってメンバーに振っていけばいいんだろう?」

……何を言っているんだこいつは? と思った方がいらっしゃるかもしれませんが、実は筆者はこれまでの仕事で「タスクをトップダウンで割り振る」ということをしたことがありませんでした。 筆者が所属していたチームはこれまでスクラムで業務を行っており、みんなが実施するタスクはスクラムボード上に作られたバックログで管理され優先度が高い順にメンバーが自主的にとっていく形式をとっていました。 しかしながら、任されたチームにはそもそもタスクが可視化されているボードがありませんでした。 全ての仕事はマネージャーが管理していて、それを適切にメンバーに分配、進捗報告会で状況把握と方向性を決めていきます。 つまり、楽しそうな仕事も面倒な仕事も、全てはマネージャーの決断によってメンバーの誰が作業をするかが決まる組織体系だったのです。

それでは「じゃあ個人にダイレクトメッセージを送ってタスクをお願いしていくぞ!」という気持ちで再スタート…..しようとして、すぐに手が止まります。 それは、管理職研修で何度も聞かされたエンゲージメントやメンタルヘルスケアの問題です。 おそらく JTC で管理職になった皆さんは、成り立ての頃に嫌というほどさまざまな ”管理職研修”というものを受けたのではないかと思います。 筆者も例外ではなくもちろん多くの研修を受けましたが、現状大企業の多くには「エンゲージメント向上」に関する研修も含まれているかと思います。 エンゲージメントとは企業や仕事との結びつきを数値化した概念でこのスコアが高いほど生産性の高さなどにつながると言われていますが、厳しいことに近年のチームのKPIにエンゲージメントスコアの向上も含まれております。 「『複数あるチャネルから該当の項目数数えろ』なんて面倒な仕事をバンバンお願いしてエンゲージメントスコア下がったらヤバイのか…?」そんな、本職とは全く関係ないことが頭をチラつくのです。 組織構造と組織文化と筆者自身の特性が全く噛み合わず、判断がバグり始めます。

結論どうなったかというと、巷でよく聞く「プレイングマネージャー」の爆誕です。 筆者がインターネット上でよく聞くケースは「仕事量が膨大でプレイングをせざるを得ない」というケースなのですが、もしかしたら筆者のような「エンゲージメントなどの新たなベクトルで生まれたKPIの未達を恐れて、面倒なタスクはマネージャーが巻き取る」ケースもそこそこいるのではないかなと思っております。 ただしこうなると、マネージャー業務がどんどん溜まっていって首が回らなくなっていきます。「こういう時はどうすればいいんだ…? せや! 管理職研修でやらされた “1on1” で興味関心を聞きながら、仕事をお願いしていったらええやん!!」

みつめられてもなんにも出ないですよ…? (1on1の話題)

そんなモチベーションで始まる 1on1 も、多くの JTC 管理職を悩ませた(ている)施策ではないでしょうか。 最近の管理職研修には 1on1 の実施そのものが含まれていて、おそらく多くの JTC では半強制的に導入されていることでしょう。この記事を読んでいる皆さまも、1on1をすでに経験されたことがあるかと思います。 筆者自身もこれまで何度も上司にセッティングされた1on1に参加し、何1つ苦に感じることなく会話をしてきました。 ですが、実はセッティングする側になってみるとなかなか難しいことがわかります。

何が難しいかというと、前述のような筆者のモチベーションで1on1をセッティングすると、社員の成長よりも「筆者自身がどう仕事をうまくアサイン/コントロールするか」に焦点がいってしまう点です。 こうなってしまうとメンバー視点の1on1は「面倒な仕事が振ってくる場所」になってしまって成長よりも遥かに「苦痛の場」です。

なので、なるべく筆者の事情は伏せてうまく仕事の悩みや最近の出来事などを引き出そうとするんですが……会話が中々出てこないんですよね。 以前筆者が所属していたチームは皆年齢層が近い職場で専門性も熟知していたので、好きな技術スタックの話やネットミームを口から垂れ流していれば楽しみながらモチベーションの向上や成長へつながる方向に会話が弾みました。 しかしながら、筆者が新たに着任したチームの年齢層は20代から50代までさまざまであり、メンバー全員テクニカル領域が好きなわけではありません。 筆者の浅い経験では会話の種に詰まったり、「(自分よりも倍以上の社会人経験がある人にコーチングするのも、プレッシャーがあるな…)」と勝手に対話に難しさを感じたりして、自身が経験してきた「感触の良い1on1」を実現できている気が全くしませんでした。

また、筆者のケースではセキュリティエンジニアとして同期入社した人もチームメンバーに含まれており、コンプライアンスの都合で上司としての立場の発言は慎重にならなければならないと教えられる昨今では、どういう心持ちで1on1の場に臨めばいいのかも悩みの1つになりました。

このような背景から、1on1中は「(この後どういい方向に持っていったらいいんだろう…..)」と考えるシーンが増え、結果としてお互いみつめあう無言の場面やおそらく仕事の成長につながらないであろう話が続いて1on1を終えることもあります。 会社側からも月に1回程度の1on1は推奨されているし過去の経験からも1on1は重要な場であると理解しているのですが、「自分がやっている 1on1 はメンバーの成長の糧になっているんだろうか」と、毎回1on1をセッティングする度に考えるようになりました。

ウェルカムトゥ影(ダーク)サイト

このような事象が2~3ヶ月くらい続いた結果、筆者は俗に言う「インポスター症候群」と呼ばれる状態になりました。 直訳すると、自身の上司やメンバーから「この人全然マネージャーの仕事できてないじゃんって思われてるんだろうなぁ…」と考えながら仕事をする状態になったということです。 メンバー視点で見ると、発言や決断に自信がない管理職なんて不安になるだけです。 そのため、この症状を抱え続けていてもチーム全体の士気は下がりますし自身のパフォーマンスも悪くなるだけなので回復させたいのですが、ここでプレイヤーとマネージャーの大きな違いが壁として立ちはだかります。 それは、ポジティブ/ネガティブ両側面でのフィードバックをもらう機会が極端に少なく、具体的にどこをどう変えていけばいいのかがわからないということです。

プレイヤー時代は上司との面談を通して自身の良かった行動や成長のためのフィードバックが定期的に返ってくるため、その機会を通して自身の貢献を実感したり改善点に対してアプローチをかけることができました。 しかしながら、マネージャーになると目標達成に対するフィードバックはありますが、行動に対するフィードバックをもらえる機会はほぼありません。 それではチームメンバーから貰えるかというと、1on1で「何か筆者に対するリクエストあったら言ってね!」と発言して反応が返ってきたことはないですし、「(そりゃあ部下視点で面と向かって改善点を上司に話せるわけないよな)」とも発言する側視点でも思います。 つまり、自身のマネージャーとしての振る舞いは「セルフマネジメント」をすることによってその良し悪しを振り返り、改善をする必要があります。 これは多くの管理職にとっては常識なのでしょうが、これまで他者からのフィードバックで生きていた筆者にとってはすぐにセルフマネジメントの技術を身につけることができませんでした。 ですが、チームのパフォーマンスを出すためにもセルフマネジメントの技術を少しずつ身につけ、改善していく必要があります。

超絶進化のマネージャー生活この手につかむ!

それでは、プレイヤーから上がったばかりの筆者は具体的にどう改善していったのか? というのを2点ほど書いていきたいと思います。

1. チームのふりかえりで出た良し悪しを自身の良し悪しへ転換する

1つめは主にメンタル面での改善です。 本来は行動の良し悪しを自己で振り返って評価し、改善するのが望ましい姿なのでしょうが、気持ちが落ち込み気味の状態で始めても上向きになるには時間がかかります。 そこで筆者は、チームに「ふりかえり(レトロスペクティブ)」の概念を導入し、チームメンバーの力を借りながらフィードバックを得る方向性にしてみました。 ふりかえりのフレームワークとして KPT/YWT などがメジャーなものとして存在しますが、これらのフレームワークではチームが試してみて”よかったこと”や”改善してほしいこと”などが各々のメンバーから率直な意見として表現されます。 これはチームの改善活動として非常に有意義なのですが、それとは別にチームが改善してみて”よかったこと”を筆者のマネジメントとして”よかったこと”へ、逆に”改善を要望している”部分を筆者のマネジメントにおける”改善のためのフィードバック”として捉えさせてもらうようにしました。

個人的には、ふりかえりの結果をこのように捉えるだけでマネージャーとしての仕事が格段にしやすくなりましたし、最もメンタルの改善にも効果的だったと思います。 新人マネージャー向けの研修を受けると「成果を出さなければと思っているメンタルモデル/固定観念を捨てよう」や「チームのためを思えば!」のような精神側へのアプローチが出てきますが、正直なところ精神が落ち込み気味のところでこのような言葉をもらってもほとんど回復はしませんでした。 それよりも、筆者のような他者からのフィードバックを事実として受け止めて改善したい人は、チームメンバーや上司から率直なフィードバックが出るような場をセッティングした方が、例えネガティブフィードバックが多くても、インポスター症候群を長引かせることなく改善に向かっていけるのではないかと思います。

2. 自身がしっくりくる “エンジニアリングマネージャー” の型にそっくりハマるよう動いてみる

2つめは行動面での改善です。 筆者が受けた管理職研修の多くは「大切な軸はこれ! でもマネジメントに正解はないから、課題出すからみんなで考えてみてね!! (完)」という形式が多く、「何かしら方法論を提示して欲しい、それに沿ってやってみるから」と思ったのが個人の感想になります。 その一方で、JTC の場合はさまざまな職種やコンテキストを持った人間が同じ管理職研修を受けるので、ベストプラクティスを一般化しにくいといった問題もあるのだろうとは思いますので納得もします。 しかしながら、ずっとエンジニアリング業務をしていた筆者にとっては経験ベースよりもまずは「何かしらのベストプラクティス」に沿って物事を始めていかないとモヤモヤするタイプですし、そこから改善するとしても元となる改善の土台が理に適っているかすらわからないと改善の方向性を決めるのも自身にとっては困難です。 そこで、一般的には”よくないこと”と言われそうですが、自身が最もしっくりくる「エンジニアリングマネージャー論」の型を探し、そこにハマるようにして動いてみました。

具体的には、一般的に提唱されている エンジニアリングマネージャーの4領域 ごとに自身の業務ドメインで必要となるカテゴリを洗い出し、それぞれのベストプラクティスに則る(例えば、1on1ならば「互いに事前に話す内容やトピックを共有しておいて、メモとして残しておく」など)とともに自身の得意領域を分析、その領域を強みとして自身のマネジメントの軸が構築されていくよう意識してみました。 具体的な4領域とその領域に含まれるカテゴリの例は以下です。1

  • ピープルマネジメント (例: 1on1、チーミング)
  • テクノロジーマネジメント (例: DevOps)
  • プロジェクトマネジメント (例: アジャイル)
  • プロダクトマネジメント(例: 仮設検証)

この4軸を意識することで、「プロダクトマネジメントは苦手だけどやらないとエンジニアリングマネジャーとして最低限の仕事をこなせないから学ぼうか」「あのセキュリティの領域はテクノロジーの部分に入れてリードを取るのが必要だな」「1on1のカテゴリはほぼ必須要件だからこの本のやり方を模倣するか」といった自身の方向性と方法論が明確になり、1のふりかえりと合わせて格段に業務がクリアになりました。 特に筆者のような「理論がわからないと動くのが難しい」という方には、このような守破離の”守”を1つ作ってみることをお勧めします。 守を作っていく方法はさまざまあると思いますが、もう1つ私がよく参考にしていた本として エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 があります。 業界ではメジャーな本で上記の4領域よりもスコープが広いですが、マネージャーになると避けては通れない道が全て入っているのでお勧めです。

それ(憧れのマネージャー)目指して歩き出してきたんです確か…

新人エンジニアリングマネージャーの悩みを、徒然なるままに書かせていただきました。 罰ゲーム化する管理職 なんて本が世間で話題になった通り、管理職に求められるロールが年々増えてきて単純に業績を出す以上の負荷がかかっているのは事実かなと思います。 某ギャングの幹部になった人が「『任務は遂行する』『部下も守る』両方やらなくっちゃあならないってのが辛いところだな」なんて言葉を発していましたが、現代だとそれ以上にやることが増えていて本人もビックリすることでしょう。

その一方で「じゃあマネージャーリタイアしたいの?」と言われるとそんなことはありません。 筆者は社会人2年目で心から尊敬するエンジニアリングマネージャーに出会えたことでエンジニアリングの考え方が変わりました。 おそらくその人に出会わなければ筆者は技術にそこまで注力して向き合うこともなかったし、このような表舞台に出ることもなかったでしょう。 いいマネージャーとの出会いはその人の成長速度だけでなくエンジニアリングの考え方の根底そのものを変えるほどの強い影響力を持っていると筆者は信じています。 その人はもうドコモビジネスから去ってしまいましたが、筆者の目指す姿の1つがその人から学んだ「エンジニアリング組織と文化の土台を作れるエンジニアリングマネージャー」像として残っています。

筆者はまだまだその領域には至っていませんが、懇親の場で「マネージャーが変わってもう少しここで学んでいきたいと思いました!」という言葉をいただくと「あぁ、もしかしたらチームに何かいい影響を与えられたのかもしれないな」と小さな成長を感じることもできました。 まだまだ道は遠く管理職の仕事はムズカシイことばかりですが、かつて憧れていた存在にまた一歩近づくことを目指して、少しでもチームに良い影響が与えられるよう精進していきたいと思います。 あまりまとまりのない話でしたが、同じような境遇になっている人、キャリアを目指している人の何かしらの参考になれば嬉しいです。

明日は「AIロボット部で出たハッカソンの話と副賞で頂いた競馬の冠レースの話」です! お楽しみに!!

  1. エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド, https://qiita.com/hirokidaichi/items/95678bb1cef32629c317↩