現役ITエンジニアの私が個人的に嫌いな仕事ワースト3

この記事に辿り着いて今読み進もうとしている方、ダメ系ITエンジニアの世界にようこそ。

私は無能でできないITエンジニアを名乗せてもらっている通称ダメ系です。

IT業界はうつ病になる確率が高いと言われている通り、私自身も例外ではなく、日々精神をすり減らしながら仕事をしています。

とくに嫌だ、嫌いだ、もうやりたくねーという仕事であればあるほど、精神的に辛くなってメンタルがやられます。

きっと、好きな仕事だったらこんな気持ちにもならないんだろうなと思いますが、この記事ではそんな無能な鷹の私が個人的に嫌いな仕事ワースト3を紹介します。

ぜひIT業界で働いている皆さんは自分のことと照らし合わせて見て頂けましたら幸いです。これからIT業界を目指す駆け出しエンジニアの人は参考程度に覚えておくといいかもです。

ワースト3位：複雑で面倒なテスト

IT業界の開発では、「設計→プログラミング製造→テスト→商用リリース」というのがウォーターフォール開発で想定される一般的な流れになります。

設計から上の作業は上流工程、プログラミング製造から下の作業は下流工程と呼ばれていて、設計はITの知識や仕様の理解力がないとできません。プログラミング製造はプログラミングスキルがないとできません。

テストはテスト仕様書に従って実施するだけなので比較的、初級エンジニアでもできる作業になりますので、炎上プロジェクトに参画することになった経験の浅いエンジニアはテスト要員として投入されることが多いです。

そこで私が嫌いな仕事ワースト3位は、複雑で面倒なテストです。

テストはシステムによって様々な手法があるのですが、システムが複雑であれば複雑であるほど、テストケースの数や手順は多くなって複雑になります。

あまり手順が多いシナリオ系のテストだけ途中で手順を間違ってしまうと最初からやり直しになってしまうこともありますし、テストの内容が複雑だとテストデータの作り方を考えながら実施しなければならないので骨が折れます。

そもそもテストが複雑でもテスト仕様書が分かりやすく作られているものだったら実施者は意識することなく、テスト仕様書の通りにテストを行えば良いだけなので頭を使うことはないのですが、テスト仕様書を作った人が実施者に優しくない仕様書を作ってしまうと実施する人は苦労することになります。

私はその実施者に優しくない仕様書で複雑で面倒なテストをしたときに、複雑すぎてかつテストデータの作り方がなかったので自分でテストデータを作成するのに1日かかってしまったり、何度もテストをやり直しになって頭がおかしくなりそうになった嫌な思いをしたことがあります。もう二度とあのテストはしたくないということでワースト3は複雑で面倒なテストになります。

ワースト2位：他人のプログラミングを引き継ぐ

プログラミングには人によって癖や特徴があります。

綺麗なソースコードを書く人がいれば、汚いソースコードを書く人もいます。

そして、実装した本人しか理解出来ないような保守性の悪いコードを書く人もいます。

何らかの理由によって撤退したメンバーがいたとき、障害が発生してプログラミングした人が不在で急遽対応しなくてはならないとき、運用保守で他の会社から引き継いだとき、他人の実装したソースコードを引き継いでプログラミングしなくてなりません。

そうなったときに、無能でできない私のようなITエンジニアの場合は他人のソースコードが読めないため、読解するところから始めないといけないので辛いです。とくに設計書がないシステムの場合はソースコードのみなのでコードが理解できないと話にならないです。

さらに、他人のソースコードの不具合修正や追加改修を行う場合には、改修する箇所以外への影響も考慮しなくてはなりません。

私がよくやってしまうのは、ある改修があってその部分のソースコードを修正して問題なしと判断したのに、テストで修正した機能と全く関係ないと思っていた機能で問題が発生してデグレードによるバグです。

自分でプログラミングしたソースだったら、

と事前に予測して気を付けることができますが、他人のコーディングしたプログラミングで浅い理解しかしていないときはデグレードを起こす確率が高くなります。

だから他人のプログラミングを引き継いで仕事をしたくないのがワースト2になります。

ワースト1位：本番障害対応

堂々のワースト1は本番障害対応です。

IT業界で起きる本番障害対応は、以下のようなものが考えられます。

• 開発システムの不具合障害
• アクセス数集中によるサーバー障害
• インフラ作業ミスによる障害
• サーバーの故障
• サーバー攻撃や不正アクセス

私はITエンジニアですが、Web系の開発エンジニアになりますので、開発システムの不具合の障害対応を行うことが多いです。

不具合による本番障害が起きるともうそれは地獄です。

何が地獄かというと、Web系ではソフトウェアの不具合によってデータベースに登録されたデータにも不整合が起きてしまうと、不具合を修正して急遽リリースすればいいというものではなく、不整合が起きた登録済みのデータも修正しなくてはなりません。

クライアントから

と言われたら至急やるしかないので、迅速に正確な対応を求められます。しかもテスト環境ではなく本番環境で、です。失敗は許されません。

そのときにクライアントからの恫喝やPMの圧力は豆腐メンタルの私には耐えられないので、本当に本番障害対応は嫌です。

システムの不具合が本番環境で起きてしまったときは、開発者のテスト漏れによるものが原因になりますが、最近ではクラウドサービスのAWSで障害が発生したときなど、外部的要因による障害対応をしたときはサーバーが停止していたときのリカバリ作業を急いで実施することになって大変でした。

ITエンジニアをしていて本番障害対応ほど緊張感のある作業はないと思います。

その緊張感がメンタルの弱い私には耐えられないので、本番障害対応はITエンジニアをやっていて全ての仕事の中でワースト1嫌な仕事になります。

まとめ

この記事では、現役ITエンジニアの私が個人的に嫌いな仕事ワースト3について紹介しました。

同じITエンジニアだと嫌いな仕事は人それぞれ違うと思います。

例えば、私がワースト1で本番障害対応が嫌いと挙げましたが、たまに本番環境で障害が発生すると血の気が騒いできたというやりがいを感じる職人気質の変態エンジニアがいます。そういう人はワースト1どころか本番で障害が起きたら俺に任せろという感じでやりがいを感じていると思うので、ベスト1と答える人もいると思います。

他人のプログラムを引き継ぐのも私は嫌いですが、有能なエンジニアだったらパズル的な要素で、たとえクソコードだったとして他の人がコーディングしたロジックを理解するのが得意だから好きな仕事だと答える人もいれば、テストに適性があるテストエンジニアの人だったら複雑なテストも面倒だと感じずに好き好んでやる人もいます。

そのため、この記事のワースト3はあくまで私の意見としてご理解ください。