269
130

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

見逃しがちな信用できるエンジニアの特徴

Last updated at Posted at 2022-02-23

まえがき

組織に属している人には基本的に他者との協業がついてまわる。

エンジニアの振る舞いに関して、古い日本の価値観で測ると「和を乱す」、「空気が読めない」、「有害」などと見られがちな振る舞いが、本当は「信用できる」人間の振る舞いであることがたまにある。

逆に「印象が良い」、「優しい」と評価される振る舞いも「信用していいのか?」と疑いをもつ指標になるものもある。

今回はエンジニアとして働いていくなかで、凝り固まった古い価値観で、信用すべきエンジニアを見誤らないためにも、信用できるかもしれないと思えるエンジニアの特徴を書き記す。

実は信用できるかもしれないエンジニアの特徴

小さな問題に対しても熱議論ができる

社会人は同僚や上司と意見が割れることは少なくない。

特にエンジニアという職業に関しては、コードの実装方法や設計(モジュールの分け方や名前等)と普通の社会人ならそこまで気にしないようなことで言い合いレベルの議論に発展することもある。

そんなことで言い合いになるような人間は、上述した古い価値観で図ると「和を乱すエンジニア」と見られることもあるだろう。

しかし、エンジニアの世界ではたかが名前の一つや数十行あるファイルの中のたった1行をどう書くかの議論をおろそかにすることで、後で大きな問題に発展することもある。

流石にいちいち怒りが沸点に達するような議論の仕方をする人間は問題があるように思うが、
とりあげることが「たかがお名前」、「たかが1行のプログラム」とどんなに小さなことでもそれを話しの俎上に上げ、あるべき姿に向かって熱議論ができるエンジニアは十分に「信用できるエンジニア」であると考えられる。

最後までやらせる

エンジニアをしていると自分の技術力では作りきれない(期限内に終わらない)タスクに当たるといったことが度々ある。
そういったことがあると、スキルの高い別のエンジニアによってタスクを巻き取られてしまうということが発生する。

もちろんこれはビジネスとして、「価値のあるものを決まった期限内に生み出す」といった面でまちがった選択では決してない。

しかし、その決断に至るまで「スケジュールを後ろに調整できないか」、「適切なフォローを行えばやりきれるのではないか」といった点を考えなかったことは間違いである。

とくにエンジニアという職業は、上司や同僚にタスクを巻き取られてしまうと自分のスキルの低さに罪悪感を覚えたり、遅延したタスクを巻き取り続けるエンジニアを生み出してしまうといったことを発生させてしまう。

こういったときにたとえマネジメント層から言葉槍を刺されようとも、タスクをアサインしたエンジニアを信じて最後までやらせてあげるといった判断ができるエンジニアは、ヒトに投資ができるエンジニアだと思っていいだろう。

もちろんただやらせるだけで放置していては意味はないし、本当に巻き取るべきときにはそういう判断もしっかりできるという前提ありきだが。

話をひっくり返せる

ここで言う「ひっくり返す」は事実を捻じ曲げるだったり嘘を言うといったニュアンスの言葉ではない。
エンジニアは時として、実際の作業に入ってみると設計や要件といった、「過去に決まった/合意したこと」に対して違和感を覚えることもある。

一度決まったことをひっくり返すのは社会人として割と心理的なハードルが高いし、それに従っておいたほうが楽なケースも多い。

しかし、エンジニアが覚える違和感の中にはユーザの使い勝手やソフトウェアの生み出す利益に直結するものもある。

そういった際に、どんなフェーズでも決まったことをひっくり返しに行けるようなパワーのあるエンジニアは、そのタスクの先にあるものをしっかり見据えていて真摯に向き合ってる人だと思っていいだろう。

会議に出ない

年次やキャリアがあがってくると、一日のほとんどが会議で埋まってしまうということも度々あるだろう。

だが、そのような人こそ同僚や部下のフォローを行えるスキル水準ににあることがあったり、難しい作業を抱えていることが多い。
例えば、チームのタスクの進捗が芳しくなときに、脳死で参加依頼が来ている会議に参加するのではなく、あえて参加せずにチームメンバーとの時間や自身の作業時間を確保するといったことを優先することがある。

会議に出席しないということは、他の出席者の目線からするとあまり心象がよくないことだったりする。
「なぜ呼ばれているのに出てこない?」、「議論に関心がない?」、「怠慢か?」などと思われることもあるだろう。

しかし、そもそもすべての会議に主席する必要がそもそもあるのだろうか?決定事項がわかればとかったり、そもそも自分が呼ばれた背景すらわからないような会議も存在する。

そういったものをしっかり判断でき、そのときに本当に時間をかけるべきことに向き合う人は、自分のやるべきことを真に理解している人なのかもしれない。

おわりに

今回このような記事を書こうと思ったのは、筆者が若手の頃からよく一緒に働くいていた上司のエンジニアがきっかけでした。

その方は上述したような特徴を持つ方で、これらの振る舞いによってマネジメント層の方や他のチームのエンジニアから不名誉な評価を度々受けているような話を聞きました。

しかし、筆者としてはこの方のこれらの振る舞いによって、ここまで成長してこれたと思っており、こういうエンジニアがマイナスの評価を受けのは悔しいと思って筆を取りました。

これら以外でも、自分の上司や同僚で「ん?」となるような特徴をもつ方がいた際に、目に見える事実だけでその人を嫌厭したりせず「もしかしたらこっちのことを思ってくださっているのかも…」考えてるきっかけになれば幸いです。
(結果的に本当に害な場合ももちろんありますが)

筆が進んだらこの記事の逆パターンである、「いい人そうだけど信用してはいけないかもしれないエンジニア」も書こうかなと思います。

269
130
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
269
130

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?