【IT企業の現場のリアル】エンジニアのマネジメントの実態を暴露

【IT企業の現場のリアル】エンジニアのマネジメントの実態を暴露 エンジニアの紹介
【IT企業の現場のリアル】エンジニアのマネジメントの実態を暴露

こんにちは。

この記事を読んでいるあなたは、

「エンジニアのマネジメントってどんなことをやるのか?」
「30代後半になり、年齢的にマネジメントをやったほうがよいのか?」

このような点に悩んでいるのではないでしょうか?

30代に差し掛かると、マネジメントをするのが一般的なんてことも言われることもあります。
一方、特にエンジニアとして働いていたり、これからエンジニアになろうと思う人の多くは、あまりマネジメントに興味がなかったり、マネジメントにならないといけないのか?迷っていることでしょう

そこでこの記事では、僕自身のマネジメントの経験も踏まえつつ、あなたの悩みを解決できるような、以下の内容を解説します。

この記事を読んで分かること
・IT企業でのエンジニアのマネジメントの赤裸々な仕事内容と実態
・エンジニアのマネジメントに求められるスキル
・エンジニアはマネジメントをすべきか?

この記事を最後まで読んでいただくことで、エンジニアのマネジメントの全体像やIT企業での実態、そしてマネジメントをすべきか?などを知ることができます!

  1. IT企業で僕が直面しているマネジメントの実態を踏まえて、この記事を書いています
    1. 僕は、IT企業で企画チームのマネージャーとして、日々忙しく働いている
    2. 僕のまわりにいるエンジニアのマネジメントも、同じくらい大変そう
  2. エンジニアにマネジメントが必要な理由
    1. チームの成果を最大化するため
    2. エンジニアと並走して、エンジニアのスキルやキャリアアップをする
    3. 組織的な問題の解決をするため
  3. エンジニアのマネジメントの仕事内容の実態8つ
    1. チームの開発環境を整える
    2. 1on1の実施
    3. 半期ごとの目標設定や評価の実施
    4. 出勤管理
    5. 採用面接の実施
    6. 業務委託をしている会社のコントロールや予算管理
    7. チーム内外で起きている問題の解決
    8. プレイヤーとしての作業
  4. エンジニアのマネジメントで大変なところ4選
    1. 個性的な人が多く、なかなかチーム全体がまとまらない
    2. 複数の事業にどのように人を割り当てるか?が難しい
    3. エンジニアの採用ができない
    4. 自分のプレイヤーとしての作業に忙殺される
  5. エンジニアのマネジメントで求められるスキル4選
    1. チームのマネジメントスキル
    2. 高い技術力
    3. ハードワークできる体力
    4. 人に興味を持つスキル
  6. エンジニアはマネジメントをすべきか?
    1. [結論]マネジメントをするべき・する必要がない、は人による。
    2. マネジメントをした方がいい人: より大きい仕事をしたい人
    3. マネジメントをしない方がいい人: プレイヤーとして今後も頑張っていきたい人
  7. [最後に]エンジニアのマネジメントができるようになると、選択肢が一気に広がる

IT企業で僕が直面しているマネジメントの実態を踏まえて、この記事を書いています

IT企業で僕が直面しているマネジメントの実態を踏まえて、この記事を書いています

僕は、IT企業で企画チームのマネージャーとして、日々忙しく働いている

現在、僕はIT企業のマネージャーとして働いています。

日々、組織の問題を解決したりチームメンバーからの質問を受けたりと、バタバタしています。
朝から夕方までミーティングがギッシリ詰まっていることも多く、ふと気づくと夕方6時・・・なんてこともしょっちゅうです。

やりがいを感じつつも、マネジメントの大変さを実感する毎日です。

マネージャーとしてチームメンバーの目標設定や評価を行うのはもちろん、日々発生する社内承認を行ったりします。
他のチームを含めた問題も頻繁に起きるので、その都度解決をする必要があります。
また、今後チームを拡大するための採用活動も行っています。
さらに、自分が担当している業務も同時にこなす必要があります。

マネジメントって仕事が多くて本当に大変だな・・・と、つくづく思います。

僕のまわりにいるエンジニアのマネジメントも、同じくらい大変そう

僕のまわりには、エンジニアチームのマネジメントをやっている人も数多くいます。

彼らの様子を見る限り、エンジニアだろうが企画チームだろうが、かなりの部分(おそらく9割以上)は共通しています。
エンジニアチームのマネジメントも、非常に大変そうです。

彼らも僕と同じように、日々時間に追われながらチームメンバーの目標設定をしたり問題を解決したり、採用を行ったりしています。

この記事では、そんなIT企業におけるエンジニアのマネージャーの実態を踏まえつつ、エンジニアのマネジメントに関して紹介します。

エンジニアにマネジメントが必要な理由

エンジニアにマネジメントが必要な理由

それではまず、僕の経験も踏まえつつエンジニアにマネジメントが必要な理由を説明します。

チームの成果を最大化するため

マネジメントの本質は、「チームの成果の最大化」です。

マネジメント不在の状況だとそれぞれのメンバーがバラついていたり、適正やスキルレベルなどが合っていないと100%のパフォーマンスが発揮できないことがあります。
また、各自がどれだけ頑張ったとしても、チーム全体で110%、120%のアウトプットは出ません。

そこでマネジメントの出番です。

エンジニアのマネージャーが適切なアサインを行うことで、各自のアウトプットのレベルを向上させます。
また、各メンバー間で衝突していたり二度手間が発生したりしているポイントを解決したり、ボトルネックになっているポイントを発見・解決することで全体のアウトプットの総量を上げていきます。

このように、マネジメントが入ることで各自のアウトプットのレベルが上がりますし、チーム全体の成果も向上する効果が見込めます

エンジニアと並走して、エンジニアのスキルやキャリアアップをする

マネジメントには、各メンバーのコーチ的な役割もあります。

マネージャーは、各メンバーが今後やりたいことやキャリアプランなどを聞きつつ、次にどのようなことをやればそのキャリアプランが実現できるか?を各メンバーと一緒に考えることになります。

また、マネージャーは、会社や組織がそのチームに求めていることを各メンバーにお願いして遂行する役割もあります。

そこで、会社や組織から求められていることと、各メンバーのやりたいことや今後のキャリアの交わるような仕事を探し出し、それをお願いすることになります

こうすることで、各メンバーからすると「マネージャーに言われただけのやらされ仕事」から、「今後やりたいと思っていることを満たした魅力的な仕事」に変化します。

「会社や組織としてやるべき仕事をいかに魅力的な仕事として各メンバーに伝えられるか?」も、マネージャーの重要なスキルの1つとなります。

組織的な問題の解決をするため

特にIT企業など、変化の激しい業界や会社では、事業の状況に応じてチームの規模を増やす必要が出てくることがあります。

事業目標が突如切り替わったりするため、それに臨機応変に対応する必要があるのです。
そこで活躍するのが、エンジニアのマネージャーとなります。
事業的にどのくらいの開発が必要か?を見積もり、その見積もりに応じた採用などを行う必要があります。

場合によっては正社員の獲得をすることがありますし、一時的だったり、正社員の採用をする時間的余裕がない場合は業務委託やフリーランスエンジニアを雇うこともあります。
エンジニアのマネージャーは、このように、チームの拡大をするような動きも必要になります。

エンジニアのマネジメントの仕事内容の実態8つ

エンジニアのマネジメントの仕事内容の実態8つ

続いて、IT企業におけるエンジニアのマネジメントの仕事の実態がどのようなものか?を紹介したいと思います。

僕の近くにいるエンジニアのマネージャーは、実際に日々、こういった業務をこなしています。

企画チームのマネージャーである僕も、ほぼ似たような業務を行っています。なので、エンジニアかどうかによらず、ここに書いてあるものは共通と思っていただいてよいでしょう。

チームの開発環境を整える

チーム内のメンバーのパソコンの調子がおかしい場合は、新しいパソコン購入の承認を行います。
また、開発のために新しいツールを利用するためには、そのツールを利用するための権限を付与することがあります。

比較的事務作業寄りの仕事ではありますが、こういったチームメンバーから日々上がってくる環境系のトラブルを解決したり、申請を承認したりすることも、マネージャーの仕事の1つです。

実際、現場で働いていると、ビックリするくらい、こういったトラブルの相談や承認の依頼が飛んできます。
メンバーの数にもよりますが、1日で5件くらいはこれらの相談や承認をしている感じです。

1on1の実施

チームメンバーと1週間〜2週間に1回、1on1(ワンオンワンと読みます)と呼ばれる2人だけのミーティングを実施します。

そこでは、最近の仕事の近況を聞いたり、何か困っていることの解決を行う他、チームメンバーのスキルアップのための気付きを与えたりすることがあります。

チームメンバーのモチベーションをコントロールしたり、チームのアウトプットを最大化するために1on1は非常に重要な時間です。

いろいろなマネージャーやのチームメンバーとの関係性を見ていると、この1on1の回数が少ないチームは、あまりチームとの関係性がうまく行っていなかったりします。
業務が忙しいと1on1の実施を負担に感じてしまうのですが、チーム全体のパフォーマンスを上げるためには重要な活動となります。

僕も過去、忙しすぎて四半期に1回くらいしか1on1をやらなかったことがあります (今思えば言い訳ですが)
結果、メンバーとの距離感が生まれてしまいチームが崩壊、結果的にプロジェクト自体が解散されることになってしまいました。
こんな失敗経験もあるので、今では意識的にチームメンバーとの1on1を実施するようにしています。

半期ごとの目標設定や評価の実施

マネージャーとして、メンバーの目標設定や評価も行う必要があります。

ほとんどの企業で、半期ごとに評価を行うため、その期のはじめには、各メンバーと一緒にどのような成果を出すことを目標とするか?を相談します

マネージャーは、各メンバーのスキルレベルを踏まえつつチーム全体の目標と各メンバーの目標を照らし合わせて、今季の目標が適切か?を考えることになります。
メンバーによって、目標のレベルが高すぎたり低すぎたりすることがあるため、そのコントロールをすることが非常に重要です。

また、期の終わりには、各メンバーとその期の評価面談を行います
査定は、マネージャーとしては非常に神経を使う仕事になります。

いい査定を提示できる場合はよいのですが、悪い査定の場合、部下への伝え方など非常に気を遣うことになります。

僕も過去、数人悪い査定をつけたことがあるのですが、そのときは胃がキリキリしていました。
マネージャーとしても、悪い情報を伝えるのは辛いものです。

出勤管理

出勤管理

マネージャーは、日々、各メンバーが何時くらいに業務を始めて何時頃に業務を終えているのか?を管理します。

IT企業の多くは裁量労働制だと思うのであまり神経質になる必要はないかもしれません。
ただ、特に勤務状況の悪いメンバーがいた場合、その理由を聞いたり、場合によっては注意をしたりする必要もあります。

出勤管理はチームメンバーがきちんと働いているかを確認するために必要な指標です。
ただ、エンジニアなど高度にクリエイティブな仕事の場合、会社で机に座っている時間の長さは重要ではない気もしています。
優秀なエンジニアは業務時間外も技術的なことを調べていますし、勤務時間とそれ以外の時間の区別が曖昧になってきています。
そういう意味で、マネジメントをする側としても「現在は労働時間がどのくらいか?」「社員が何時から何時まで働いているか?」ではなく、「どんなアウトプットを出したか?」の方を重要視した方がよいでしょう。

採用面接の実施

会社や事業の方針を踏まえて、チームメンバーの数が不足していると思われる場合は採用の面接を行います。

マネージャーがこの作業をサボっていると、「エンジニアの数が足りなくて事業が成長しない!」ということにもなるので、特に事業を拡大している会社にとって、採用活動は重要です。

採用面接は、人事担当と連携しつつ行うことになります。
マネージャーは、人事が求人サイトで見つけた良さげな人と面接をしてみたり、社内で異動したいと言っている人とカジュアル面談という形で話をしたりすることになります。

業務委託をしている会社のコントロールや予算管理

上記の採用活動とも似ているのが、「業務委託をしている会社のコントロールや予算管理」です。

仕事の内容や会社の状況によっては、社員のエンジニアを採用するのではなく、業務委託として一時的に雇い入れることもあります。

業務委託の人を使う理由
これは社員として採用すると、日本においては簡単に首を切れないのが理由です。
特に今後の事業の規模が読めなかったり、不確実性が高い場合は社員エンジニアではなく、業務委託の人を利用することが多いです。

チームのマネージャーは、チームで利用している業務委託にどのくらいのコストがかかっているか?や、アウトプットが出ているか?などの管理をすることになります。
もしこの費用対効果が高い場合は、業務委託先の管理監督者と相談してアウトプットを上げるための議論を行ったり、場合によっては別の業務委託会社に切り替える判断をすることもあります。

チーム内外で起きている問題の解決

チーム内外で起きている問題の解決

エンジニアのマネジメントは、チーム内にいるメンバーのマネジメントだけに限りません。

チーム外の人と何か問題が起きた場合は、マネージャーとしてその問題を解決する必要があります。
また、開発の遅延が起きた場合は、どのようにリカバリするか?をマネージャーとして検討する必要があります。

解決方法は状況次第ではありますが、スケジュールを延ばしてもらったり、人を追加することで解決を図ることもあります。
もし特定の人に問題がある場合は、その人をプロジェクトから外すなどの思い切った判断を迫られることもあります。

プレイヤーとしての作業

最後に、マネジメント自身が持っている、プレイヤーとしての作業です。

エンジニアのマネジメントになる人は、ほとんどの場合、チームのメンバーからマネジメントに昇格することがほとんどでしょう。

チームのメンバーのときに持っていたタスクを誰か他の人に渡すことができれば問題ないのですが、実際、完全に渡し切ることはほとんどありません。

一部は他の人に渡せたとしても、残りのタスクはマネジメントをしながら自分でも手を動かして対応をすることになります。
僕の周りにいるエンジニアのマネージャーの人も、ほとんど例外なく自分の作業を持っています。

こうやって、「忙しすぎるマネジメント」が量産されることになります。
僕のいる会社でも誰もがどうにかしたいと思っている一方、全体的に人不足であるため、各マネジメントの頑張りで不足分を補っている、というのが実情です。

エンジニアのマネジメントで大変なところ4選

エンジニアのマネジメントで大変なところ4選

続いて、ここまでに説明してきたエンジニアのマネジメントの業務を踏まえて、具体的にどのあたりが大変なのかを説明します。
僕のまわりにいるエンジニアのマネージャーは、これらのポイントで日々、悪戦苦闘しています。

個性的な人が多く、なかなかチーム全体がまとまらない

IT企業では働くエンジニアは、人によって考え方が様々です。

・その会社に長く居たいと思うか?ステップアップの踏み台にしか思っていないのか?
・仕事とプライベートの比重はどのように考えるのか?
・現在のスキルレベルはどのくらいか?
・今後のキャリアはどのように考えているのか?

こういった多様性のある人たちが集まっているので、チームの方針をまとめるのが大変です。
特に、エンジニアには他の職種よりもクセの強い人も多いため、そういった人のマネジメントは非常に苦労します。

また、最近では、トップダウンによる指示があまり通用しなくなってきています。
これは、

・チームメンバーの方が目の前の業務に詳しい
・事業の不確実性が高くなってきていることもあり、トップダウンだとその変化に耐えられない

などが理由です。

トップダウンで「xxxしなさい」という指示をするのはマネジメントとしては楽でした。
自分の言いたいこと・お願いしたいことだけをチームメンバーに言っておけばよかったからです。

一方、現在はチームメンバーと常に向き合い、彼らの言うことにも耳を傾けつつその時に応じて臨機応変に方針を変える必要があります。

昨今のエンジニアのマネジメントは、非常に難易度が高まっています。

複数の事業にどのように人を割り当てるか?が難しい

特にIT企業では、複数の事業が同時多発的に成長することがあります。
エンジニアのマネジメントは、そんな複数の事業成長を加速するため、人の割り振りをする必要があります。

人が潤沢にいればあまり難易度は高くないかもしれません。

ただ、現実は、

・基本的に人手不足
・人がいても、プロジェクトの難易度的にアサインできない人もいる
・それぞれの人がやりたいこと・やりたくないことがあり、やりたくない仕事をお願いするとパフォーマンスが落ちる

このような状態です。

ですので、マネージャーは、走っているプロジェクトを成功させるために、誰に何をお願いするのか?を必死で考えることになります
割り当てる作業は、さながらパズルのようです。

「Aさんをプロジェクト1に割り当てて、Bさんは・・・スキル的に考えるとプロジェクト2は厳しいからプロジェクト3に入ってもらい・・・」

なんてことを考えるのも、エンジニアのマネジメントで重要な仕事です。

エンジニアの採用ができない

エンジニアの採用ができない

今、どの企業でも優秀なエンジニアを募集しています。
僕が所属している会社でも、優秀なエンジニアの採用は本当に苦労しています。

年中採用をしているものの、なかなか希望するレベルの人を採用することができていません。
そして、採用する場合も他の会社とどちらがどのくらい高い年収を出すのか?の勝負になって、企業の体力が奪われます。

毎日かなりの数の候補者と面接をしているようですが、実際に入社してくるのは3ヶ月に1人もいません。

募集に苦労するケースとは?
募集する人に対してあまり高いレベルを求めない場合は、比較的簡単に採用できます。
ただ、採用する側がある程度優秀な人材を求める場合、そういった人は企業間の獲得合戦が行われるため、採用が難航します。

自分のプレイヤーとしての作業に忙殺される

エンジニアのマネージャーをやる場合、他の人のマネジメントだけやっていればいいわけではありません。

あなた自身で手を動かしてプロジェクトを進める、プレイヤーとしての役割も同時に期待されます。

あなたのプレイヤーとしての仕事が忙しいと、本当はマネジメントとして、チームのメンバーとの会話の頻度を増やしたい場合であっても、その頻度を増やせないことがあります。

本当は、マネジメントをやるのであれば、マネジメントの仕事だけにフォーカスした方が余裕がでます。

ただ、会社の状況的にマネジメントだけをやらせてくれることはほぼないと言ってよいでしょう。

また、最近はプレイングマネージャーができることがキャリアアップの重要なポイントだったりします。
ですので、マネジメントをやりつつプレイヤーとして手を動かす状態は、キャリアの観点では非常に良い状態かもしれません。

エンジニアのマネジメントで求められるスキル4選

エンジニアのマネジメントで求められるスキル4選

続いて、そんなエンジニアをマネジメントする際に必要となるスキルを紹介したいと思います。
これらは、僕がIT企業で働いていていて、実感を持って絶対に必要だな、と思っているものです。

チームのマネジメントスキル

最も分かりやすく必要になるのが、チームのマネジメントスキルです。

マネジメントスキルは、あなたが担当者として仕事をしていたときとは全く違って必要になるスキルです。

逆に、担当者として優秀だった人は、仕事ができない人のことが理解できなかったりします。
担当として仕事ができることが、マネジメントをする上では弊害になることもあります。

ここまで紹介してきたように、マネジメントをするときは、チームメンバーの目標設定をしたり、評価をしたりします
また、彼らに日々気付きを与えることでスキルアップの機会を提供したりします。

こういったチームのマネジメントスキルは、エンジニアとして最も重要なスキルの1つといえるでしょう。

高い技術力

マネージャーが全てのメンバーの細かい作業まで完全に管理することはできません。
開発を行っているシステム自体については、各メンバーの方が詳しいことが多いでしょう。

一方で、各メンバーの作業の方針が間違っている場合は、マネージャーから指摘や注意をする必要があることもあります。

あまり詳しくない開発内容に関しても的確なコメントや指摘ができるような高い技術力が必要となります。

とはいえ、プロジェクトの最新の状況に関してはチームメンバーの方が知っていることでしょう。
ここでマネジメントに求められる技術力は、チームメンバーが持っていないような広い視野と、ソフトウェア開発をする上での普遍的な知識やノウハウだったりします。
この2つがあれば、チームメンバーが気づけないような観点の示唆を出すことができます。

ハードワークできる体力

一般的に、ほとんどの企業ではマネジメントになると残業代が出ません。
おそらく月に35時間などのみなし残業だったり、「マネジメント手当」のような形で、毎月定額の金額が支給されるかと思います。

一方、仕事量はここまで説明してきたとおり、多岐にわたります。
これまでの自分の仕事をこなしつつ、マネジメントの仕事が追加されるため、圧倒的な忙しさになることでしょう。
場合によっては、朝10時から夕方20時まで休み時間ゼロでミーティングをしているなんてこともあります。

一部で「マネジメントをする人には人権がない」と言われるのも、このハードワークが起因します。

マネジメントをする人は、このくらいの忙しさを乗り越えてハードワークできる体力が必要になります。

もちろん会社によってもっと楽なマネジメントもあるでしょう。

特に年功序列の会社だと全く状況は違うと思いますが、今後必要となってくるのは、ここで僕が説明したような、ハードワークできるようなマネジメントになってくると思います
そのくらい全力で仕事をしないと、どの企業も生き残れない状態になってきています。

人に興味を持つスキル

最後は意外に思われるかもしれませんが、マネジメントは、「チームメンバーに興味を持てる」ことも重要なスキルです。

これまでエンジニアのプレイヤーとして仕事をしてきた人は、興味の範囲が、目の前のシステムや開発に関するものがメインであり、あまり人のことに興味を持つ必要がなかったのではないでしょうか。

一方、エンジニアのマネジメントをするのであれば、チームのメンバーや隣のチーム、上司についても興味を持ち、「今、自分は何をすべきか?」を常に考えておく必要があります。

もしマネジメントとなった人が人に興味を持っていなかった場合、

・チームメンバーは何をやっても上司からのフィードバックがなく、仕事の方向性に迷う
・上司からの指示を無視してチームを間違った方向に導いてしまう
・隣のチームからの期待値を考慮できず、それらのチームとの溝ができてしまう

こういったリスクが高まります。

マネジメントになったのであれば、プレイヤーのときとは違って人に興味を持つのが非常に重要です。

エンジニアはマネジメントをすべきか?

エンジニアはマネジメントをすべきか?

それでは最後に、ここまでの内容を踏まえてエンジニアはマネジメントをするべきか?を説明したいと思います。

[結論]マネジメントをするべき・する必要がない、は人による。

まずは結論ですがマネジメントをすべきかどうか?は人によると考えます。

これまでは年功序列の考え方がメインであったため、ある程度年齢とキャリアを重ねた後は、少しずつマネジメントにシフトするのが普通でした。
一方、現在45歳くらいで早期退職の声がかかったり、転職の「35歳定年説」が薄れつつあったりと、これまでの年功序列・終身雇用の時代とは大きく変わってきています

ですので、マネジメントをするべきかどうかは、「あなたが今後どのようなキャリアを築きたいかによる」ということになります。

マネジメントをした方がいい人: より大きい仕事をしたい人

チームマネジメントの本質は、「チーム全体を動かして自分ひとりでは出せない成果を出す」ことにあります。

つまり、チームのマネージャーになることであなた一人では出せなかったような大きい成果を出すことができます。
もちろんその成果を出すことに対する責任も伴うのですが、大きい裁量を持って仕事ができるのが、マネジメントをする醍醐味の1つです。

「今後、自分で手を動かすだけではなく、より大きい規模の仕事をしたい」と思うのであれば、マネジメントを目指してみるのがよいでしょう。

もちろん、より大きい成果が出せることはあなたの給料アップにもつながるため、あなたの今後の年収を上げられる可能性が高くなります。

現場のエンジニアだと年収が上がらないのか?
海外のIT企業だと、現場のエンジニアでも数千万円の年収を得ることができるのですが、少なくても現在の日本においては、マネジメントをした方が年収を上げやすい傾向にあります。

マネジメントをしない方がいい人: プレイヤーとして今後も頑張っていきたい人

今後もプログラミングを主体的にやったり、現役のエンジニアとしてバリバリやっていきたいのであれば、マネジメントになるのはオススメしません。

マネジメントになるとどうしても管理系の仕事の比重が増え、プログラミングをしたり最新の技術に触れる機会が減ってしまうからです。

エンジニアのスキルは非常に時代の流れが早いため、常に最新の技術動向をチェックして、身につけておくのが重要です。

エンジニアとして手を動かし続けると、今後のキャリアが大丈夫なの?という心配があるかもしれませんが、問題ありません。

実際、ほとんどのIT企業ではマネジメントをするエンジニア以外にも、現場で手を動かせる優秀なエンジニアを募集しています。

そして今後もスタートアップや新規事業をやっている会社を中心に、即戦力として手を動かしてくれるエンジニアを募集する企業は増えてくると予想されます
ですので、マネジメントをしなかったとしても、手を動かせるエンジニアとしての価値は、これからも高まり続けます。

手を動かせるエンジニアとしての最大の価値は、どれくらい技術があるか?と、どれくらい最新の技術情報にキャッチアップできているか?です。

技術力を磨いたり情報収集をする時間を確保するためにも、もしあなたが手を動かし続けたい場合は、マネジメントにならない方がよいでしょう。

[最後に]エンジニアのマネジメントができるようになると、選択肢が一気に広がる

[最後に]エンジニアのマネジメントができるようになると、選択肢が一気に広がる

この記事では、エンジニアのマネジメントに関して僕の経験談も踏まえて説明してきました。
エンジニアをマネジメントするのがどのような内容か、どのような大変さがあるのかが伝わったのではないでしょうか。

エンジニアのプレイヤーとして手を動かすのは、1つの立派なキャリアです。
一方、僕はマネジメントをするのも、同じくらい立派なキャリアだと思います。

特に日本ではマネジメントをした方が年収が上がりやすい傾向にありますし、ある程度の年齢になると転職時にマネジメント経験の有無も確認されるようになります。

もしあなたが「マネジメントは絶対にやりたくない!」ということでなければ、一度マネジメントも視野に入れて行動してみるとよいでしょう。
きっと、あなたの新しい可能性が見えてきますよ。

この記事は以上です。
ここまで読んでくださり、ありがとうございました!

コメント

タイトルとURLをコピーしました