本記事では、エンジニア（SE）として数年間経験を積んだ筆者が、
仕事ができないエンジニアの特徴と行動パターンというものを語っていこうと思う。
仕事ができないエンジニアの特徴と行動パターンまとめ
まずは最初に、仕事ができないエンジニアの特徴と行動パターンをまとめてみる。
- 作業見積もりを立てないまま行動する
- 作業に優先順位がつけられない
- 時間に対する意識がとにかく甘い
- どこか当事者意識に欠ける・責任感がない
- 取り掛かりが遅い、全て理解してから動こうとする
- 求められた以上のアウトプットをしない
- 変に完璧主義なところがある
実際はもっとあるが、書き切ろうと思うととてもじゃないが書ききれないので、筆者が特に重要だなと感じた上記①〜⑦の項目に絞って、それぞれ解説していこうと思う。
①作業見積もりを立てないまま行動する
仕事ができないエンジニアの最も代表的な特徴として、
作業見積もりを立てないまま行動するという特徴がまず挙げられる。
エンジニアである以上、作業見積もりを立てることは、全ての行動に共通する基本だと筆者は考えている。
もちろん作業の大小はあると思うので、全ての作業においてきっちりと「この作業の工数は○人日で〜」と見積もる必要があると言っているわけではない。どんなに小さな作業だとしても、「不足の事態はないか、他の作業に影響はないか」など反射的に考えるのものではないかという至極当然の話である。
しかし、そもそも、そんなレベルの話ではなく、
仕事ができないエンジニアというのは、作業見積もりをしない・または、したがらない生き物なのだ。
作業見積もりを立てないエンジニアの心理
では作業見積もりを立てないエンジニアの心理とは一体どんなものなのだろうか。
以下のような理由が挙げられると筆者は考えている。
- 作業見積もりをするのがそもそも面倒だ
- 作業見積もりを立てて、その通りに行かない場合責められるのが怖い
作業見積もりをするのがそもそも面倒だ
作業見積もりを立てないエンジニアの心理として、
「作業見積もりする時間があったらさっさと作業に取り掛かって終わらせた方が良い」という思考がまずは前提にある。
一見分からなくもない思考回路だが、問題は、大小の切り分けをしないまま、上記思考で作業に取り組んでしまう点だ。
作業量が小さい場合、上述した通り、考えるよりも先に行動した方が作業が早く終わる可能性が高いケースはある。
しかし、それは結果オーライというもので、真に理解しておかなければいけないことは、作業見積もりが甘いせいで生じるスケジュールの乱れの深刻さを無視するための、都合の良い言い訳でしかないという点だ。作業見積もりをするのは大変だし頭も使う作業だからめんどくさいのは分かる。しかし、作業見積もりをちゃんとやらないと、後々さらに苦しい状況を招いてしまう事態になるため、絶対にある程度の見通しを立ててから作業を始めるように心がけよう。
作業見積もりを立てて、その通りに行かない場合責められるのが怖い
「作用見積もりを立てる＝作業時間に拘束が課される。言った以上は時間以内に終わらせなければならない」という発想から、責任を逃れたいという心理が働いて、作業見積もりを立てたがらないというケースも存在するようだ。要は「〇〇日くらいで終わります」と断言するのが怖いのだ。
実際は、見積もりの段階では完璧な作業時間などわかるはずもないし、上司もそれは理解している。
それよりも、どんな見立てで作業に臨んでいるのか分からない状態の方がよっぽど怖いのだ。後々になって収集が着かず、巻き取り作業に追われて他人のスケジュールにまでを影響を及ぼすタイプの人というのは間違いなくこの作業見積もりを立てないタイプの人なのだ。
うまくいけば問題は露呈しないが、問題が露呈した場合、すでに手遅れという状況は大体このタイプの人が関わっていることだろう。なので、作業見積もり＝拘束という考え方はやめて、むしろ逐一進捗は報告し、周りとの連携をとるようにしよう。その方が結果としてチームの透明性が上がり、自身の信頼度の確立にもつながるからだ。
②作業に優先順位がつけられない
次に挙げる仕事ができないエンジニアの特徴は、
作業に優先順位がつけられないという特徴だ。
全ての作業には優先順位が存在する。当然のことだ。
しかし、これを理解していながら、行動に移せるかという点はまた別物なのだ。特に、仕事ができないエンジニアというのは、この「作業に優先順位をつける」という作業がとにかく苦手、または優先順位をつけたがらないというケースが非常に多い。
作業に優先順位がつけられない例
筆者の実体験となるのだが、今でも忘れられない「優先度がつけられないエピソード」があるので紹介する。筆者が入社したての頃の、研修期間のお話だ、ITエンジニアとしてのお話である。
「チームに分かれて、課題のシステム開発を協力して行う」と言う研修内容だったが、同じチームに優先度がつけられないタイプのA子さんと言う方がいた。
A子さんはお世辞にもプログラミングの飲み込みが良いとは言えない方だったが、一方で、明るく、コミュニケーション能力には人一倍長けるものがあった。そのため、電話対応や来客対応と言ったいわゆる「雑務」に関しては誰よりも上手だったし、本人もその自覚はあったらしい。普段から積極的に「得意分野」の仕事を受け入れ、こなしていた。
そしてチーム開発も佳境を迎えようとした頃、皆、それぞれのタスクの期限に追われていた。
そんな中、最も進捗が遅いA子さんが何を思ったか、突然、「来客対応当番表の作成」みたいな雑務の依頼を「ウチやるよー」的な軽いノリで引き受けたのだ。本人も悪気があって依頼を受けたのではないが、当然、チーム一同「今、君だけは引き受けるな、、」と言うツッコミを心の中で入れたのは、言うまでもない。
上記A子さんのお話で重要なことは、、A子さんは優先順位の判断が正常にできていなかった点だ。少なくとも本人は「進捗が遅れている」と言う認識があったにもかかわらず、優先度の低いタスクを受け入れてしまったのだ。その背景には、「普段からこれだけは私の仕事」「いつも通り仕事を受け入れるべき」と言う潜在意識があったからに違いない（または、現実逃避したいと言う気持ちが少なからずあったのかは定かではない、、）。
上記のように、端から見ればおかしいと思える判断であっても、状況や本人の心境次第では、優先度の入れ違いが発生してしまうと言うことである。
優先順位をつけないと、自分だけでなくチームにも悪影響が出る
上記A子さんの話でお分かり頂けたかと思うが、
優先順位を正常につけないと、自分だけでなく、チームにも悪影響が出る。
システム開発は基本、チーム作業なので、「一人の判断ミス＝チームのミス」に繋がりやすい。このような状況で、個人の状況や心情によってタスクの優先順位を変更させられては、チーム全体の不平不満と言った悪影響が出ることは間違いないだろう。
このことから、作業の優先度をつけると言うことは、個人の問題のみならず、チームでの作業を前提とするエンジニア業務にとって必要不可欠な能力なのである。
例えどんな理由があろうとも、タスク毎に優先度を正しく割り振ると言う意識はエンジニアとして常に持っておかなければいけない。
③時間に対する意識がとにかく甘い
次に挙げる仕事ができないエンジニアの特徴は、
時間に対する意識がとにかく甘いという特徴だ。
時間の使い方が下手と言い換えても良いだろう。具体的に落とし込むと、以下のような特徴がある。
- 時間の見積もりをしない
- ゴールから逆算しない
- 時間に見切りをつけられない
- 時間が無くなってから時間が無いと言う
時間に対する意識がとにかく甘いエンジニアの特徴を、順番に説明して行く。
①時間の見積もりをしない
作業時間の見積もりをしないことは上述で詳しく解説したので割愛させてもらう。
ただ、かなり重要なことなので、特徴としては再掲。
②ゴールから逆算しない
ゴールから逆算しないというのも時間に対する意識が甘いエンジニアの特徴の一つだ。
普通は、一つのタスクがあったとして、タスクを完了するためには、「Aという作業をいついつまでに終わらせて、Bという作業をいついつまでに終わらせて〜〜（以下同）」という、ゴールからの逆算で物事を考えるものだが、時間に対す意識が甘いエンジニアは、特徴として、このゴールからの逆算をしない・できないという特徴を持っている。
理由は作業見積もりを立てない心理と似ていると思っていて、単に逆算する作業自体が面倒くさいか、逆算することで時間的な拘束感が発生するのを嫌っているかのどっちかだろう。
③時間に見切りをつけられない
時間に見切りをつけられないというのも時間に対する意識が甘いエンジニアの特徴の一つだ。
例えば、よく若手エンジニアに向けて「15分考えて分からないことは先輩に質問するように」という類の言葉があるだろう。この言葉の真意は、「個人で解決に努める姿勢は第一として重要だが、チームの利益を優先することはそれ以上に重要なので、頃合いを見て見切りをつけなさい」ということだ。
他にも、作業遅れの巻き取りを依頼するケースや、完璧を求めるあまり不要の工数を積んでしまうケースなどにも上記の考え方は非常に重要だ。
だが、時間に見切りをつけられないタイプのエンジニアは、
- 「もう少し考えれば、絶対いけるはず」
- 「多少遅れても、あとで取り返せば良い」
- 「ここまで頑張って考えてきたのに、最後に頼るなんて情けない」
と言った、自分にとって都合の良い理由を頭の中で作り上げては、チーム事情よりも個人の感情を優先させ、結果として、正しい見切り時を誤ってしまうケースが多い。
株式投資にストップロス（損切り）という言葉があるが、これと似ていて、ある程度勇気を持って、ストップロスをすることは、後々、深手を負わないためのコツなのである。
④時間が無くなってから時間が無いと言う
時間が無くなってから時間が無いと言うというのも時間に対する意識が甘いエンジニアの特徴の一つだ。
正常な心理？であれば、「時間が足りなくなりそう」と感じた時点で、軽めのアラートを上げるなり、リスケを実施するなり、時間が無くなる前に対策を図るものだ。
しかし、時間に対する危機管理能力が低い人はなぜか、時間を全て使い切るまでは何も言わず、いざ時間を全て使い切ってから「時間が無い」と言うのである。にわかに信じがたい心理だが、実際結構いるのでびっくりする。
理由としては、③の心理と似ているのかなと思っていて、変に自分の中で楽観的な理由を考えては報告のタイミングを先延ばしにした結果だろうと思う。
④どこか当事者意識に欠ける・責任感がない
次に挙げる仕事ができないエンジニアの特徴は、
どこか当事者意識に欠ける・責任感がないという特徴だ。
筆者の経験上、仕事ができないエンジニアというのは、もれなく、どこか当事者意識に欠ける、または仕事に対して責任感がないという特徴を持っていた。
具体的に落とし込むと、以下のような特徴が挙げられる。
- 結局は誰か（上司）が何とかしてくれると思っている
- 自分には能力がないので仕方ないと思っている
- 受け身である
①結局は誰か（上司）が何とかしてくれると思っている
第一に挙げたいどこか当事者意識に欠ける・責任感がないエンジニアの特徴として、
結局は誰か（上司）が何とかしてくれると思っているという特徴が挙げられる。
そのままやんけ！と思った方もいると思うが、この表現が最も適切だと感じたので、そうした次第である。結局は誰か（上司）が何とかしてくれると思っているという人の特徴は、以下の点で感じることが多いので、参考にして見て欲しい。
- 作業に明らかに本人の「抜かり」に起因する落ち度が多い。
- 話を聞く態度がどこか第三者的、メモを取らない。
- 受け身、求められた以上のことは考えない。
長くなるので詳細は割愛するが、上記でピンと来た人は要注意だ。結局のところ、上に立つ人というのは、自身のタスクに対して、果たすべき最低限のハードル・責務と言った境界線を明確に把握できる人であり、かつそれを結果で示せる人だ。
どこか他責・他力の傾向がある人は、上記で挙げたハードルが低いゆえに、「抜かり、第三者目線、受け身」と言った特徴を持っている。
②自分には能力がないので仕方ないと思っている
次に挙げたいどこか当事者意識に欠ける・責任感がないエンジニアの特徴として、
自分には能力がないので仕方ないと思っているという特徴が挙げられる。
まあ言い換えれば言い訳思考のようなものだ。本人たちの心理を考慮するならば、できない時の精神的緩衝材として、事前に心に言い聞かせておくようなものだと思っている。誰だって失敗は怖いし、自分の能力不足を受け入れるのは容易なことではない。それは理解できる。
しかし、重要なことは、上記のような言い訳思考では、何一つ、チームのためにならないという点である。
あくまで客観的な見方をするのであれば、上記は保身的かつ自己中心的な考え方であり、本質的には、チーム全体のプラスになる考え方でない。
③受け身である
次に挙げたいどこか当事者意識に欠ける・責任感がないエンジニアの特徴として、
受け身であるという特徴が挙げられる。
求められた以上のアウトプットをしないという話と関連してくるのだが、
⑤全て理解してから動こうとするため、取り掛かりが遅い
次に挙げる仕事ができないエンジニアの特徴は、
全て理解してから動こうとするため、取り掛かりが遅いという特徴だ。
エンジニアという仕事は基本、エラーや予期せぬ不具合と一生付き合っていくものだ。エラーや不具合自体は調査や解決策考案ため、全てを理解してから手を動かしたいという気持ちは分からなくもない。
しかし、優秀なエンジニアほど、まず先に手を動かすものだ。ある程度の理解が済んでいるならば、まずは手を動かす。そうすると、当然理解が浅いことが原因で、何かしらのエラーや不具合にぶち当たることになる。しかし、このエラーや不具合に対してのアクションもまた早い。こうしてグルグルとトライアンドエラーを繰り返すサイクルを構築することで、結果として、完璧でなければ動けないエンジニアよりも、仕事も成長も早いのである。これが優秀なエンジニアの特徴だ。
⑥求められた以上のアウトプットをしない
次に挙げる仕事ができないエンジニアの特徴は、
求められた以上のアウトプットをしないという特徴だ。
仕事ができないエンジニアほど、言われた以上の仕事はしないし、自発的な付加価値の提案をするという習慣がない。
一見すると角がなく、言ったことを過不足なくこなしてくれるため、扱いやすいという印象を受ける。
しかし、多少ガツガツしていても、「ここはこうした方が良い」「これは悪い」と言った意思表示や提案をチーム内やお客さんにできる人の方が、最終的に良い仕事ができる（※むやみやたらにガツガツしろという訳ではなく、必要なところで必要な意思表示ができるのが大事と言っている）。
上記のようなエンジニアの方が、結果として、物事の良し悪しの区別の付け方が上達すること、また、仕事に対する意識面で「しっかりしているな」という評価を受けやすいことがメリットだ。
⑦変に完璧主義なところがある
次に挙げる仕事ができないエンジニアの特徴は、
変に完璧主義なところがあるという特徴だ。
変に完璧主義なところがあることのデメリットは、以下の二つだ。
- 要らない工数や手間をかけてしまう。
- 10割まで先に進まないより、8割で先に進むことの方がメリットが大きいので、損をしている。
①要らない工数や時間をかけてしまうというのは、例えば、分かれば良い表やグラフの作成に、デザインまで凝ってしまうと言った類の話である。
②10割まで先に進まないより、8割で先に進むことの方がメリットが大きいので、損というのは、これはエンジニアに限らず完璧主義の人全員に伝えたいことなのだが、8割〜10割の2割は最も負荷が大きいということを認識しておいてもらいたい。そのため、8割までこなした時の感覚で10割を目指そうとすると、最終的に予想外に時間がかかると言ったことが起きてくる。完璧主義な人はこのことに何の疑問も持たずに、10割を目指してしまう傾向が強い。
そして、8割で先に進んでしまうことを繰り返した方が、長期的に見て仕事が早いのだ。残りの2割が気になるのはわかるが、次の仕事にまた8割でスピード感を持って仕事をした方が、一つ一つの仕事を10割でこなそうとする人よりも、結果としてこなせる仕事量に大きな違いが出てくるのだ。
「その２割で問題が起きたらどうするの」という反論もあるかと思うが、例え10割こなしたと思っても、問題は必ず問題は出てくるし、何より大事なのは、「最後の2割をこなすこと」と「ある程度で見切りをつけてさらなる成果を生む」ことを天秤に掛けた時に、後者の方が価値が高いということが理解できているかどうかである。
参考記事
「仕事ができないエンジニア」に関連して、以下
「エンジニアとしての良い質問の仕方・悪い質問の仕方」についてまとめた記事もあるので、よければ読んでいただきたい。
