こんにちは。
デカチワです。
私は大手Slerにて、SE(システムエンジニア)として４年間勤めた後、システム監査人へ転職しました。
SEとして働いていれば、悩みや苦悩を抱え、SEを辞めたいと思う人も多くいるのではないでしょうか。
そんなSEへ向けて、私がSEを辞めた理由を３つに絞って伝えたいと思います。
また決して、SEを否定している訳ではありません。むしろ、IT未経験者がSEをファーストキャリアとして選択するメリットはあると考えています。
今回はあくまで、私の実体験を元にSEを辞めた理由を解説し、同じ悩みや苦悩を抱えている人の役に立てればと思い書き上げました。
目次はこちらです。
それでは、順を追ってお話ししていきます。
SEはゴールではない、通過点である
SEはあなたにとってゴールですか？
そう問われたら、あなたはどう答えますか？
「はいゴールです。」と答える人も当然いるかと思います。素晴らしいです。それはもう天職です。この先もSEとして活躍してほしいと切に願います。
一方で、「分からない・・・」、「いや違うよ」という人も多くいると思います。人間ですから、人それぞれに葛藤や苦悩を抱え、それゆえ意見も様々だと思います。
私の場合、「いや違うよ」とはいかないまでも、「う～ん、ちょっと違うよな～」という思いが心の奥に漂っている状態でした。考えを巡らせた結果、私はSEはゴールではなく、通過点であると結論付けし、転職という行動をしました。あなたはどうでしょうか。
私がSEはゴールではなく通過点であると考えた理由は３つあります。
- 心がSEはゴールではないと言っているから
- レガシーな技術を採用しており、将来的にできる仕事が限られてくるから
- 技術のライフサイクルが早くなるため、技術を覚えることよりも、どう利用するのか考える側へ変化した方が良いから
１つ目は、単純且つシンプルです。
私の場合、自分の心が直観的にSEはゴールではないと言っていました。
つまり、心の声というやつですね。
子供や学生の頃は、自分はこうしたい、こうありたいと自然に感じ、実行に移せてましたよね。これは私だけでなく、みなさんも同じかと思います。
ですが、大人になるにつれて不思議と変化が怖くなります。なんででしょうね、理由は未だに分かりません。
ただ、はっきり言えることは、「変化は損失ではなく、利益だ」ということです。
変化は避けるものではなく、向き合うものではないでしょうか。
SEがゴールである理由を自然と探してしまうも多くいると思いますが、まず自分の心の声に耳を傾けましょう。それが、この問いの本質です。
２つ目は、SEが実務で習得する技術に関してです。
基本的にSlerに勤めるSEが利用するメイン技術は古いです。
私の場合、メーカーを親会社としたSlerで仕事をしていましたが、基幹システムの歴史が古いため、利用する技術も古いものでした。
その上で、基幹システムの規模が大きいため、会社はIT基盤の刷新がなかなかできません。段階的に数年かけて刷新したと思ったら、プロジェクトが完了したころには、その採用した技術やバージョンはすでにレガシーになっていることもあります。
そのため、将来性という観点から見れば、携わるシステムの規模が逆にボトルネックになっていると感じていました。
また、レガシーな技術も需要があるのでは？という意見もあると思います。
一理ありますが、私はレガシーなIT基盤を再利用することは将来的になくなり、ビジネス自体をデザインし直し、スピーディーにシステムを構築できる技術が採用されるようになると考えています。
そのため、結果的にレガシーな技術は価値がなくなると思っています。
３つ目は、２つ目と関連しますが、技術のライフサイクルが早く、１つや２つの技術を習得できたからといって、いつ需要がなくなるのか分からないということです。
それゆえ、技術を習得することにこだわるのではなく（キリがないので・・・）、どう技術を利用するのかを考える立場へシフトした方が良いなと思いました。
以上が、SEはゴールではなく通過点であると感じた理由です。
SEは超マルチタスク
「マルチタスク」とは、Wikipediaによると「複数の作業を同時にもしくは短期間に並行して切り替えながら実行することをいう」と定義されています。
マルチタスクの反対は「シングルタスク」と言います。定義はマルチタスクの逆で、「１つの作業に集中する」という意味合いで使われます。
私の経験から考えるに、SEがキツい、忙しいと言われる根本的な原因は、業務がマルチタスクであるからだと思います。
具体的に説明します。
まず、SEの仕事はシステムの「開発・保守」と「運用」に分かれるのが一般的です。
次に、SEの開発・保守の業務フェーズを挙げると下記になります。
- 企画・要件定義
- 外部設計
- 内部設計
- プログラミング（コーディング）
- テスト（単体、結合、システム、受入、移行）
- 移行・リリース
開発手法はウォーターフォール型がメインで、アジャイル型を取り入れているプロジェクトもありますが、基本的なフェーズの構造に大きな相違点はありません。反証のサイクルが早いかどうかの違いです。
SEの仕事はこれでけではありません。
同時にマネジメントも進めていく必要があります。
マネジメントの対象は、「人・モノ・金・情報」の４つですね。これを、コストを適切にコントロールしながら納期を守り、かつセキュリティ等のコンプラを守るためにマネジメントしていきます。
きちんと会社として役割を明確化し、業務を定義しているのならば良いのですが、大手～中小含めておそらく、ほぼすべてに同時的に携わっている人がほとんだと思います。
こう見るとSEって超マルチタスクですよね。
私は数年であれば勉強になるので、良いかなと思っていましたが、長期的に考えると超マルチタスクを続けるのは厳しいなと感じていました。
シングルタスクと比べて、マルチタスクは40%ほど生産性が下がり、徹夜した際と同等の集中力しか発揮できないという研究報告もありますが、実際に体験してほんとだなと当時を思い返します。
例を挙げると
ボクシングってリング上で１対１で戦いますよね。
SEは、リング上で１対Nで戦っている感覚です。マニー・パッキャオに四方八方塞がれて、詰め寄られているところを想像してください。勝ち目ほぼないですよね。
今では、システム監査人に転職し働いていますが、だいぶリング上で戦う相手が絞られているいるなあという感覚です。SEの時は今考えると異常でしたね。
意外？SEは働く時間と場所に縛られる
SEをITという枠で括ると、テレワークなどで時間と場所に縛られないで働けるとイメージする人も多いのでないでしょうか。
SE経験者の方は理解できると思いますが、SEはむしろ時間と場所に縛られます。
理由は単純です。金融分野の大企業は特にですが、セキュリティ要件が厳しいため、テレワークが許されないことがほとんどです。
場所の観点から言うと、テレワークが許されても基幹システムにアクセスできない、全員にテレワーク用のPC端末、システム環境が提供されないなど制限があったりします。ゆえに出社する必要があるわけです。
また、時間の観点で言うと、開発・保守では土日祝日や夜間などにシステムをリリースしたりします。システムの大小に関わらずユーザの業務時間外に対応する必要があるためです。
運用業務では、夜間にシステム障害が発生した場合、テレワークが許可されていないと、自宅から会社へ出社し、対応しなければなりません。
SE時代は深夜にスマホが鳴るのが、怖かったですね・・・
このような理由から、SEは働く時間と場所に縛られていると考えています。
SEから、システム監査人に転職した今は、時間と場所の制約からある程度解放されました。
