底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

部下を一度も持たないまま30代半ばに突入しているエンジニア

これまでいくつもプロジェクトには参画してきたが、部下を持たずにきた。

  • 若手エンジニアに業務でもなんでもなにか指示や指導をする
  • 作業が遅れないようにスケジュール管理する、遅れそうなときはフォローする
  • なにかあれば相談に乗ってやる

・・・といういずれのこともできていない。さすがにそれはまずいだろうという気持ちが最近特に溢れてきている。

 

これは非常に恥ずかしい話なのだけど、技術的に未熟なまま年齢だけを重ねてしまった私のようなエンジニアの場合、下手に部下(≠作業指示を行うような対象と言い換えてもいい)がつくと、正しい形で部下を導くことが出来ず、その部下の成長も阻害してしまうのではないかと思ってしまう。

 

誤った方法論、スケジュール管理、プログラミングに関する知識、業務知識etc...

 

自分ひとりが上記のような正しくないことをプロジェクト内で行っていた場合は、「これは違いますよ」と指摘されて直すことも容易いと思うけれど、それを管理すべき部下に伝えていた場合、「前に教えた○○だけど、間違っていたみたい」って何度も修正することになるのが目に見えていて怖い。

 

以前PMOとしてスケジュール管理を任されたことがあったけれど、スケジュール管理だけでなく技術的なフォローもするようなことがあればすぐに破堤するのが見えている。なにせ、技術的な部分で教えられるようなことは何もないからだ。そりゃあ一日の長があるので、新卒丸出しのエンジニアだったら初歩的な部分で指導することも可能だけど、2年目3年目のエンジニアに対して、こちらからアドバイス含めてなにかしてあげられることなど何もない。

 

非常にフラットな立場なのだ。そんな奴が人を管理して導くことなど出来はしない。

 

こんな私なのに、「今日私の部下でこんなことがあって~」などと言って部下の愚痴を聞かされることがある。そういった場合に合ってるかどうかは別にしてアドバイスをしてあげることもある。そんな時、「あぁ、もしかしたらこんなわたしでも部下を持っても大丈夫かも」などと思うこともあるが、相談されたような1ケースに対してアドバイスをしただけであって、実際業務で持ち上がってくるであろう多種多様なケースに対応できるはずもないのだ。だって実際やってないんだから。

 

最初このエントリーを書くにあたって、「部下を持たないエンジニア」の分類を「規模の小さい会社ならでは」みたいに書き始めていたのだけど、実際規模の大小はあまり関係なく、個人の資質に係る問題だなぁと思いなおしてその部分は消した。

 

いい加減、業務履歴書に「メンバーとして参加」以外のプロフィールも書きたい。どうすればいいの。

 

 

はじめて部下ができたときに読む本

はじめて部下ができたときに読む本