どうも、無能なダメ系ITエンジニアとして客先常駐の界隈で生きている者です。
今日は無能すぎる自分ができないエンジニアだと感じる瞬間について紹介します。
有能なエンジニアであればあるほど該当しないと思いますので、あなたがもしエンジニアとしている人であれば、該当するか否かでできるエンジニアなのかできないエンジニアなのかを診断してみてください。
もし、全ての該当した方はできないエンジニアの可能性が非常に高いと思われます。と同時に私と近い境遇の方で友達になれそうなので、友達になりましょう！！
後半では、自分ができないエンジニアだと感じたときに取るべき行動について考えてみました。自分と同じ境遇のできないエンジニアの人に参考になったら幸いです。
自分ができないエンジニアだと感じた瞬間4選
1. 仕様が理解できなかったとき
IT業界の開発現場では、顧客の要求を適切な要件定義を言う形にして、設計、プログラミングによる実装、テスト、リリースという流れが一般的になります。（※ウォーターフォール開発の場合）
要件定義と設計は顧客の要求を明確にする必要があり、上流工程と呼ばれています。一方、上流工程で完成された要件や設計を元にプログラミング、テスト以降を下流工程と言います。
上流工程は開発するシステムのスケジュールや予算、下流工程を含むプロジェクト全体に関わる責任が重くかつ重要な工程になります。
そのため、上流工程は顧客の仕様を正確に理解できる高いスキルが必要になり、経験年数やポジションが上のエンジニアが担当することが多いです。いきなり新人や駆け出しエンジニアの人が上流工程の要件定義や設計を担当するようなことはないでしょう。
そこでダメ系の私の話になりますと、経験年数は10年以上になりますが、仕様が理解できないことが多いです。
顧客からの要求仕様書を見たり話を聞いても理解力が乏しいのか、頭が悪いのか、経験年数だけはあるのですが、理解ができません。
そのため、上流工程の要件定義を任されることなんてありません。次の工程の設計でさえ怪しく、要件定義を見ても理解がなかなかできず、何度も読み直したり、要件定義を担当した人に聞きまくったりしないと設計も的確にすることができません。
……できたとしても要件定義の内容を異なる内容を設計してしまうことも多く、仕様が理解できないときに、
ダメ系あー、俺できねえなあ……
と感じます。
一般的には下流工程より上流工程の方が収入やポジションが高いので、ある程度の経験年数を積んでいて設計ができないエンジニアになってしまうとエンジニア人生が積みます。
PLやPMができるマネジメントスキルか高レベルの技術スキルでもない限り……。
エンジニアとして詰んでしまうと取り返しのつかないことになりかねますので、注意してください。
2. 自分で判断ができなかったとき
エンジニアは様々な場面で判断を求められます。
- 顧客折衝時の最適な回答
- 障害発生等の緊急対応
- 採用する技術の選定
- 開発タスクの優先順位
私はこれらの判断を自分ですることができないので、経験年数10年以上のエンジニアにしてPLやPMに判断を聞いてからでないと行動することができません。
つまり、逆に言えば、PLやPMのポジションができないエンジニアであるということなので、将来のことを考えたら致命的なことで判断することが自分でできないエンジニアだと思ってしまいます。
3. 後輩にキャリアを抜かれたとき
エンジニア歴が長いと客先常駐エンジニアをやっていても自分と同じ所属の派遣元の会社から後輩が参画することもあるのですが、その後輩に抜かれていくことがよくあります。
その中には気づいたらマネージャーに昇格していたり、フリーランスとして独立して収入が私より遥かに上回ってしまっていたり、別業種から最初は駆け出しエンジニアとして参画した人だったのにエンジニアとしてのスキルが開花して客先からの評価が逆転して差をつけられてしまってたりと、後から入った後輩にキャリアを抜かれたときはできないエンジニアだと劣等感を感じてしまいます。
4. プロジェクトを強制退場になったとき
客先常駐先のエンジニアをたった1か月という短い期間でスキル不足を理由に強制退場になったことがあります。
客先常駐先のエンジニアには契約期間がありますが、技術的なスキル不足で1か月で退場になってしまうというのは致命的なことです。
職務経歴書には1か月という期間で契約解除になってしまった案件の経歴は残ってしまう訳ですし、次の案件でもまた契約解除になったらどうしよう？という不安感から自分はできないという気持ちになってしまい大きなダメージを受けてしまうことは必至です。
自分ができないエンジニアだと感じたときに取るべき行動
1. 理解力を訓練する
仕様が理解できなかったときは、システムの流れをメモでまとめたり、図に書いてみて自分で説明できるような訓練を繰り返すことで仕様の理解を深めることができます。
いきなりシステムに関するメモや図としてまとめるのが難しいのであれば、もっと身近な訓練方法として考えられるのは読書です。興味のある本を読んで（インプット）その本の説明を文章として書き出してみたり、人に説明できるような訓練（アウトプット）を鍛えることからから始めてみることで顧客からの要求定義を要件定義の理解度を高めることができるでしょう。
2. 判断力を訓練する
自分で判断ができなかったときは、誤った判断をしないようにプロジェクトメンバーに助言を聞くのはもちろんですが、どうしても自分で判断しなければならない状況下であるならば、小さな訓練を繰り返して論理的思考力を身に付ける努力をすると良いでしょう。
具体的には、現状置かれている立場を把握して複数ある選択肢を洗い出して、選択肢の中から優先順位をつけるだけでも決断力に差が出ます。
小さな訓練は日常生活の中で訓練することをおすすめします。例えば、休日にインドアでほとんど外に出ない人が、外に出ようとすると、映画館に、ラーメン屋に、テーマパークに、行くだけで様々なシーンで小さな判断の繰り返しが必要になります。
そういった小さな判断の繰り返しが論理的思考力の向上に繋がって仕事にも生かせるようになりますので、判断力をつけるためにリスクのない日常生活から訓練してみると良いでしょう。
3. 他人と比較しない
後輩にキャリアを抜かれたとき、スキルを磨いて自分の能力向上に努めるのが良いでしょう。
抜かれた後輩のことはあまり気にせずに他人と比較しない方が良いとは思います。自分より天才の人はいくらでもいますので、どんなに頑張っても努力しても敵わない人はいます。その類の人が後輩だったらとしたら遅かれ早かれキャリアが抜かれてしまうので、比較するだけ無駄です。
あえて言うなら後輩と比較するのではなく、参画したのが先だからというプライドは捨てて、後輩から学ぶことができるスキルや知識を吸収して自分のスキル向上に努めるようにした方が良いでしょう。
4. 気持ちを切り替える
プロジェクトを強制退場になったとき、スキル不足が原因であった場合には、スキルを磨いて勉強して次は退場にならないように努力するのが良いでしょう。
また、プロジェクトはメンバーとの相性や案件の得手不得手といった要素も関連しています。
もし、すぐに強制退場になった場合でも次に参画したプロジェクトでは相性が良く一転高評価されるということもよくある話です。
スキルと磨くことも大事ですが、退場になったことは引きずらないで次のプロジェクトに気持ちを切り替えていくと良いでしょう。
まとめ
この記事では、自分ができないエンジニアだと感じた瞬間と取るべき行動について紹介しました。
私のような無能なエンジニアはできないと感じてしまう瞬間は、この記事で書いた内容以外にもありますが、全てを書き出したらキリがないですし、日々できないと感じています。
できないと感じてしまうと気持ちは落ち込みますし、うつになりがちにもなりますが、他人と比較しないで気持ちを切り替えていくことも大切なことだと思います。
また、取るべき行動で紹介した通り、自分に足りないスキルを磨くことで『できない』から『できる』に変えていくことはできるので、日常生活を使って理解力と判断力を訓練することを習慣化してみても良いでしょう。
