Why not login to Qiita and try out its useful features?

We'll deliver articles that match you.

You can read useful information later.

14
11

新卒入社約2年でSES・SIer業界の会社を退職した理由

Last updated at Posted at 2024-08-04

はじめに

タイトルにもある通り、2022年4月に中小のSIer・SES企業入社で2024年7月半ばに退職しました。巷でよく言われるSES・SIer業界の会社でした(メインはSES)。

軽く、自己紹介しようと思います。

  • 国立大学の情報工学科(理系)を卒業
  • 新卒でこの会社に入社
  • 現在年齢は満26歳(休学していたため大卒で1年遅く入っています)
  • 昔からコンピュータには非常に興味があり、大きな可能性を感じていた
    世の中のシステムはどのように動作しているのだろうか、どうやってプログラムされているかなど、小学生くらいのときから興味はあったものの、高校まではなかなか学べる機会がなかったです。大学に入ってはじめてプログラミングを学びました

大学5年間(休学1年)で一生懸命、情報工学(コンピュータサイエンス)を勉強してきたのでIT業界で働きたいと感じていました。しかし、就活はなんか気持ち悪く感じてしまい、頑張れませんでした。理由は以下。

  • なんで社会を知らない一学生がこんなふざけた就職活動で内定の合否が決まるのだろうか
  • なんで社会を知らない一学生が就活で合格しただけの会社に長く勤め続けららるのだろうか。入社予定企業の仕事の本質(闇の部分など)を全く知らないのにおかしくないか

以上のように思っていたため、実際に入社して働いてみないと社会(業界や会社、給与体系、仕事内容、社会人の働き方など)のことを理解できないから、一回働くことが大事だと考えました。なので、もしやめたければ退職する(ただし最低1年は働こうと思った)など柔軟に対応していこうと考えてました。
とりあえず、マイナビやリクナビに掲載された会社を探し、働いてみようと決意し入社しました。入社した会社は、日本によく見られるSES/SIer業界の中小企業だ。
実際約2年数か月働いてみましたが、当時のイメージよりも悪い業界と感じました。そして、今回退職した理由を述べようと思います

目次

  1. 退職理由
  2. 実際に働いて驚いたこと・気付いたこと
  3. 退職した感想
  4. 今後の展望

1.退職理由

主な退職理由は、トピックにある通りである。それぞれの退職に至った点を説明しようと思う。

1-1.給料が安い

ITと聞くと儲かるように聞こえるが、SES/SIerは実際にはそこまで儲からない。
原因は以下。

  1. ビジネスモデルの限界
  2. 多重下請け構造
  3. 会社に所属

1と2については、レガシーなゴミみたいなレガシーIT業界に嫌気で詳しく言及するが、簡単にまとめると

  • 一人が出せる売上に限界がある
  • 多重下請けで他社が無駄に利益を奪う
  • 最後に属している会社が利益を奪う

このように、自社含めさまざまな会社に利益とられてしまうため、最終的に手元に残る給料は少なくなってしまう。ゆえに、本来儲かるIT業なのに安月給となってしまうのだ。

1-2.未経験と同じ待遇

自分自身、情報系学部の出身なので、大学で専門分野を学んだうえで就職している。つまり、4年間その基礎を学んできて新卒で入社しているわけで、未経験の新卒社員と同じ待遇なのは少し腑に落ちない。コンピュータサイエンス(以下CS)というものは、易しい分野ではなく、専門性が高いのだ。大学4年間の差はかなり大きいと思うのだ。
アメリカでは、エンジニアとして働くにはCSの学位
(日本の大学では情報工学科などの学部卒が該当)を必要な場合がほとんどで、未経験採用はあまりないと聞く。本当に日本の新卒就活は不思議だ。

1-3.配属現場のミスマッチ

僕が3か月の研修を終え配属された客先常駐現場は、運用・監視を担当する業務だった。
完全にミスマッチで、運用保守と運用監視が主のため、正直つまらないことの方が多かった。主な業務は以下

  • 障害発生時の手順書の管理
  • 運用監視業務
  • Azureにアラートルールを設定
  • Azureの技術調査
  • Azureからリソースなどの情報取得
  • SSL証明書の設定

など、運用がメインの現場だったのでプログラミングなどをゴリゴリ行う業務でもなく、そこまでIT要素が強いとも言えない業務であった。
ただ、Azureなどのクラウドコンピューティングサービスに触れた経験は大きく、またすごく興味を持てた。
しかし、Azure以外の業務は正直興味を持てなくてつまらなかった。
人員不足でごくたまに、運用監視業務を行ったことがあったが、これは地獄のようなもので、

  • 8:00 - 20:00
  • 20:00 - 8:00

の2交代勤務シフトだった。12時間やり続けるのも地獄なのだが、もっと地獄なのが業務内容である。業務内容は

  • 頻繁にくるアラートメール
  • トイレや休憩に行きづらく座りっぱなし
  • 退屈すぎる業務
  • スマホなどは持ち込み不可
  • 時間の経過がかなり遅く感じる

といったように、退屈すぎる上に座りっぱなしで健康的によくないのだ。これは実際にあったことで、自分自身入るたびに体調が悪くなるし、本当に悪いときは、熱が出て1週間ほど体調不良で1か月ほど身体がだるくなったこともあった。
時間つぶしもできないし、モニターを12時間永遠に見るような業務(正確には休憩もあるが)。こんなことやるために、この業界に来たわけじゃないと。監視業務中は常にそのように心の中で叫んでた。もう二度とやりたくない業務だ。

しかしこんな現場でも良かったところはあって

  • システムの運用を知ることができた
  • 運用監視という地獄を知れた
  • 仕事があまりなく結構暇なので在宅中はIT関連の勉強をできた
  • Azureをはじめとするクラウドコンピューティングサービスに出会え詳しくなれた
  • Azureの資格を取得できた(AZ-900,AZ-104,AZ-204,AZ-305)

ただ、これ以上続けても得るものよりも失うものが多くなる感じはしたので、いいタイミングで退職できたと思っている。

1-4.客先常駐の弊害

客先現場に出るということは、以下に示すような勤務に対する柔軟性や自由度が低下することを意味している。

  • フレックス勤務といった柔軟な働き方
  • ドレスコードの緩さ
  • PCやPC周りの業務機器や設備
  • 作業場所の広さ
  • 自社社員(プロパー)の年の近い人がいない
  • フレックス勤務といった柔軟な働き方
    まず、勤務時間は基本的に客先に合わせるため、フレックスなどは難しい。
  • ドレスコードの緩さ
    客先現場のため、ドレスコードも厳しいことが多く、スーツ着用必須も多い。
    僕の現場はそこまで厳しくなくオフィスカジュアルのような感じだった
  • PCやPC周りの業務機器や設備
    客先業務のため、基本は客先からPCを支給されるが、スペックが微妙なことも多い。なかなか希望通りのPCはもらえない。僕がいた現場でも、貸し出されたPCはメモリ8GBで性能がよいPCとは言えなかった。なんなら、個人用で使ってるDellのPC(メモリ16GB、intel Corei7 vPro 8th Gen、メルカリ中古58000円)の方が断然動きが良好だった。
    PCと同様でPCまわりの業務機器(モニターやマウスなど)も乏しいことが多い。
  • 作業場所の広さ
    作業場所や作業机が狭かった。客先としては、業務委託の僕らにそこまで金をかけたくないのだろう。
    在宅勤務と出社が半々だったため、作業場所の広い自宅の方が作業が捗っていた
  • 自社社員(プロパー)に年の近い人がいない
    実際に働くとかなり痛感するのだが、年の近いプロパーは身近にいたほうが絶対に良い。気軽に相談できるからだ。悩んだときなども年の近い人や同期などの方が相談しやすいのは想像できるだろう。しかし、SESは派遣業務みたいなもので、プロパーも各現場に数人程度のことが多く、年の近い人がいないことも多い。同期もほぼ全員違う現場なことも多い。実際に僕の現場でも当初は僕と上司の二人で上司以外気軽にしゃべれる人がいなかった。

けれど、こんな環境でも1つだけ運が良かったのは、リモートワークが月の半分くらい実施できたことだ。万が一、リモートワークができなければ、2年も続いていなかっただろう。

また、客先現場ゆえに、退職時も大変だった。多重下請けだっただめ、客先現場において発注会社・受注会社にお菓子配ったり、あいさつする。そして、自社にも挨拶などもした。業務関係者が多いのも客先常駐業務の特徴だ。

1-5.現場レベルの低さ

客先現場に出て驚いたのだが、現場レベルがマジで低かった。特にひどいと思ったのは、Azure操作するときはいつでも、大量のリソースを作成するときだろうが必ずAzurePortalにてGUI操作(マウスポチポチ)で行っていたことだ。
大量のリソースを作成するのならば、人為的ミス防止や業務の効率化などを理由に、CLIを用いたスクリプトやIaC(Infrastructue as Code)などで自動的にリソースを作れる仕組みを構築するべきなのだが、現場ではプログラミングができないがゆえに、Azure Portalにてマウスをポチポチしてリソースを作成しているのだ(大量のリソースを作成、設定変更するときも)。こんな人たちが技術者を名乗ってよいのだろうか。

上司にも、上記に述べたCLIを用いたスクリプトやIaC(Infrastructue as Code)などを使えばどうですかと提案したものの、契約でGUIにて行うことになってるみたいな変なことを言われたので、こちらもかなりストレスになってた。

また、もう一点許せなかった点は、客先現場ではAzureの不明点はほとんどマイクロソフトサポートに丸投げし、自力で調べようとしなかったのだ。
自力で調べたうえで、確認を行うためにサポートに聞くのはよいと思うのだが、最初から調べずに丸投げはおかしい。
自分自身は、そんな姿勢が嫌だったので、Azureの調査業務を任された際は自分でリソースを構築して調べるようにしてた。

このような現場だったため、一時期メンタルをやられた。自分が一番最適だと思うやり方を回りのレベルが低いがために否定されてきたためだ。
本当にやめてよかったと退職した今強く感じている。
技術力は自分で練習してあげるほかない。

1-6.挑戦できる環境がない

結局は客先のシステムをいじって仕事しているので、挑戦をして失敗したらただ事にはならない。そのため、大きな挑戦はできず、実績のある方法や昔からのやり方が好まれる。
自分自身もそれを大きく痛感する出来事があった。

  • スクリプトを組んでリソース作成の自動化する作業を止められた
    Azureから情報を取得するだけならスクリプト組んでオッケーだった。それ以外は、ひとつひとつコマンドを実行するか、AzureならAzurePortalからGUI操作をしなさい。
  • 在宅勤務中はAzureリソースの作成禁止、読み取りのみ可
    このせいで、リソースを作成する際はわざわざ出社していた。しかも、自分のみ禁止で、周りの人たちは普通に在宅勤務でリソース作成していた。

これすらも挑戦できない。今考えるとだいぶ異常な現場だった。
それが、現場の技術力レベルの低さにつながっている1つの原因じゃないかと考えている。

1-7.ゴミみたいなレガシーIT業界に嫌気

こちらの記事から引用する。

「開発」と「運用・保守」を分離することは、「人月商売(にんげつしょうばい)」「多重下請け構造」と並ぶIT業界特有の問題となっている

レガシーなIT業界では、この3点が問題点であると引用記事には書かれているが、本当にその通りだと思う。この3点について実体験と感想を述べようと思う。

  • 多重下請け構造
  • 運用開発の分離
  • 人月商売

ちなみに、僕がいた現場でも、これら3点とも満たしていた。ひとつずつ見ていく。**

多重下請け構造

この業界の一番の闇はこの部分に尽きる。このせいで、この業界で働くエンジニア・作業者などは給料がだいぶ他の会社に吸い取られてしまい、安月給になってしまうのだ。もともとITを扱う業界は、儲かる業界であることに間違いないと思う。なぜならば、発注者は一人月100万円以上を普通に出してくれるからだ。では、なぜ会社員の大半は安月給になってしまうのかというと、この多重下請け構造に巻き込まれてしまうためだ。

実際に僕のいた現場でも、4次請けまであり、現場で働く4次請けの運用監視部隊に対して発注者は一人月200万円で一次受けに発注してもらっていたが、最終的に40-50万円で僕の所属していた会社(3次請け)が4次請けに発注してた。
そして、運用監視部隊の方に給与を聞いたところ、賞与なしで額面年収200万円台(月収約20万円)とのことだった。また、その方は僕よりも20個以上年上の方だった。つまり、一人月200万円発注なのに、最終的にその仕事をしている労働者には約20万円しか与えられないのだ。約10分の1である。

これを聞いて、非常にショックを受けた。こんなの、人権を無視していないかと。こんな世の中でいいのかと。何度も自問自答した。

なぜ多重下請け構造になるのか

日本におけるこの問いに対する結論は2点

  • 会社をなかなか潰せない
  • SESSIerは需要の波があるのに基本的に社員を解雇できない

しかし、疑問点も浮かぶ。なぜ多重下請け構造が出来上がってしまい、安月給でも仕事を受ける企業がいるのか。

  • 会社をなかなか潰せない
    以下のツイートを引用

    続きが見たい方は飛んでみてください。 簡単にまとめると、日本は再就職しにくい社会なので、会社がつぶれると社長が困る。そのため、安い報酬でも仕事を受けてしまう。そのため、多重下請け構造が起きやすくなる。 といった内容だ
  • 基本的に社員を解雇できない
    開発現場には需要と供給に波がある(企業側としては開発時に労働者が集まってほしく、開発終了時などは労働者をリリースしたい)が、日本は会社員を簡単に解雇できないため、柔軟に労働者の需要と供給を調整できない。
    そのため、日本のITを扱う仕事では発注者がSIerまたはSES企業(一次受け企業)に発注することで、発注者は需要と供給を調整する。
    そのようにしてSES企業(二次受け以下)にもオファーが来るのだが、これが問題である。
    労働者をたくさん要するときなら、二次受け以下にも仕事が回ってきて大丈夫なのだが、問題はシステムが完成する(開発終了)などして仕事がなくなったときである。
    SES企業は従業員をどこにも派遣できず売り上げがない状態になってしまうのだ。ならば、そのような仕事のない従業員を解雇すればよいのだが、日本はそれができない。
    そのような従業員に対しても会社は常に給料を払わなければいけなく、簡単に解雇できない。なので、安い契約になってしまっても契約せざるを得ないのだ。

これからわかるのは、日本において開発現場で会社員として働くITエンジニアは、あまりにも給与面・待遇が不利になる。アメリカのように、使えない労働者を簡単に解雇・レイオフできればよいのだが、日本の法律はそれを許さない。日本の雇用形態も多重下請け構造に大きく寄与していると働きながらしみじみと理解した。

以上のようにして、日本のSIer界隈は多重下請け構造が出来上がってしまったのだ。また、多重下請け構造似て1次請けや2次請けのような上流に位置する会社は、中抜きで簡単に儲けられるので、やめられないのだ。実際に僕がいた現場でも、中抜きだけで月に200万円近く儲けていた。これも多重下請け構造がなかなか崩れない原因の一つだと思ってる。

では、以上のように、安月給の原因となっている多重下請け構造に巻き込まれないためには、今後はエンジニアはどのように働くのがいいか。
自分自身が考えて出した答えは

フリーランスとして働く

のがベストだと思う。
レバテックのようなエージェント使うにしても多重下請けに巻き込まれないし、契約する企業側も普通に解雇できるので、高い報酬で稼働できる。開発現場の需要と供給に合わせた運用をできると思ってる。法律が変わらない以上、そして、このような構造上、フリーランスとして働くのがエンジニアも企業も一番幸せになれるのではないかと。
ただ、契約解除される可能性はあるので、しっかり技術力をつける必要はあるが、これはエンジニアとして働くうえでは当たり前なのでデメリットとは思わない。
むしろ、日本の会社員エンジニアが勉強しなさすぎであると思っている。
今の状況を見ていると、今後もっとフリーランスに発注する流れに世の中はなると思うし、もっとAIが活用されていくと思う。早く多重下請け構造は滅んでほしい。

開発と運用が分離している

開発と運用が分離していると、連携がうまくできないため、よい運用ができないと感じた。現場では以下のことが発生し、生産性が非常に悪いと感じた。

  • 監視設定時に開発側と連携するため非効率
  • 負荷テストなども開発側と連携するため非効率
  • 適切なアラートを作成できない。アプリの中身を知らない運用側が監視設定を行うため、詳細な設定を行えない
  • アプリのアップデートをする際にも、開発と運用が連携できてないため、監視設定とアラート時の手順書が古いまま

本当にひどいものだと個人的には感じた。このレベルで月に60-100万円の単価が出ていたのだから、ユーザ側(発注者)が不憫でならない。

実体験を述べたい。

  • 監視設定時に開発側と連携するため非効率

    • 自分自身、監視設定において開発側と連携を取るようなことはなかったが、客先現場の周りの人はそのような経験があった。それを横から見ていたが、開発側に連絡を取っても返信こないなど、非常に手間がかかっていた。
  • 負荷テストなども開発側と連携するため非効率

    • 負荷テストも同様に、開発側から返信こないなどをたびたび見かけたので、非常に効率が悪いと思った。
  • 適切なアラートを作成できない。アプリの中身を知らない運用側が監視設定を行うため、詳細な設定を行えない

    • とにかく、監視設定がざっくりになってしまっている。
    • CPU使用率やメモリ使用率は、ほぼ80%を超えるとアラートメールが運用監視部隊に飛ぶ。このように、どのアプリでも基本的に80%という固定値なので、アプリに合わせた運用ができていない。
    • たまに、自分自身も運用監視の業務を行ってきたが、どのアプリにも同じような設定がされているので、バッチ処理などで一時的に負荷が高くなるときでも、平気でアラートが飛んでくる。バッチ処理で負荷が高くなるのは当たり前なので、このような場合、アラートは不要なのである。
  • アプリのアップデートをする際にも、開発と運用が連携できてないため、監視設定とアラート時の手順書が古いまま

    • 対応手順も古いままのことが多かったため、監視業務時にアラートの対応するのが非常に大変なものだった。

そのため、いまではDevOpsといった、運用と開発の一体化が提唱されてきているが、当たり前になってくるであろう。そして、今後もDevOpsは重要な概念になると考えている。

人月商売

SES,SIerなどと聞くとかっこよく思えるが、簡単に言えば「IT技術者の派遣」に過ぎない。派遣なので、稼げる利益に限界がある。ITを正しい道具としてビジネスに適用できれば、利益は青天井になる。
実際に世界の時価総額上位を占めている企業の上位を見ると、ほぼIT企業なのだ。本当は利益順で算出したほうがよいが、時価総額と利益はほぼ比例するので、時価総額で見ていく。
上位を占めているのはマイクロソフト、アップル、エヌビディア、アルファベット、アマゾン、メタ。

image.png

https://www.180.co.jp/world_etf_adr/adr/ranking.htm

これからわかるように、ITをうまくビジネスに適用できれば利益は青天井に伸びていくことがわかる。
ITの本質とは人間がやっていた仕事(情報処理)をコンピュータに高速処理させることで、人件費を浮かし、良質なサービスを高速に正確に提供することだ。

しかし、SES・SIer企業は人売りでしかないため、出せる利益に限界がある。
自社開発のように、青天井に利益が伸びるわけではないのだ。ITは青天井に利益が伸びる可能性を秘めているのに、SES・SIerは最初からそれを否定しているのだ。

1-8.会社の方針に違和感

  • 昇進昇格の評価制度が結構謎
  • 昇進昇格の速度が遅い

SESのため、現場によってやってることも違うし、評価方法も上司によって異なる。
あってはならないことだが、上司に嫌われていたがゆえに、昇進が遅くなっているという悲鳴も一部聞こえた。
令和の時代にそんなことしているのは、まずくないか。

そして、昇進昇格が遅いのだ。入ってから給与の上がり幅が小さいため
結局、僕が所属していた会社の退職理由の大半は昇進の遅さ。これで、やめていった人をたくさん見てきた。

本来なら、技術力なども加味し、どれだけ会社に貢献できるかが評価の主な要因にならなければいけないが、それがあまり感じられなかった。
そのため、新卒で未経験とCS学部卒ではITの能力差にはかなり大きな幅があると思うのに、給料がほぼ変わらない。ましてや、入社数年経過でもCS卒より未経験者の給与の方が高くなっているという現象も起きている。
こういういことを目の当たりにすると、一生懸命大学で情報工学を勉強していたことが馬鹿らしくなってくる。

1-9.会社員としての生活に不満

これは個人的な所感だが、平日9時から18時まで働いて土日2日休みと決められるのが好きではなかった。もっと、自由で柔軟に働きたいと感じていたし、実際もっと柔軟に働けると思っている。
また、休みにおいても、土日祝休みだと、どこへ遊びにいっても混雑しており行く気が失せる。また、会社員では1か月単位の長期休暇をとることもなかなか難しい。
僕は休みを決められたくない人であり、柔軟な働き方を望んでいることが入社してから分かった。会社員に向いてないのだ。
また、税金的にも会社員は取られ放題なので、こちらも気に食わなかった。

1-10.視野が狭まる

ひとつの場所に居続けると間違いなく視野が狭まる。
僕自身これは非常によくないことだと考えている。人生は長い。だからこそ、経験をいろいろ積んで視野を広くして成長したいと自分自身考えている。視野が狭まると人間的にもつまらなくなりそうな気がする。自分がそうなるのは嫌なので、視野を広く持ちたい。
また、ひとつの場所に居続けると、当初異常だと思っていたことも、慣れてきてしまいそれが普通になってしまうという問題が起こる。ブラックな職場や、意味不明なルール、法律違反を平気で犯す企業。内部告発もできない雰囲気。外部から見れば異常なことも、内部に居続けたことで普通になっているではないか。これも視野が狭まっているから起こる一つの現象なのではないか。
多重下請け構造などは本当にいい例で、こんな下請けいじめと思えることが日本中で横行している。もうこの多重下請け構造に日本は慣れてしまっているから、何か起きないとこの構造は崩れないのかもしれない。
世の中をよくしていくためにも、視野を広くすることが重要と考える。

2.実際に働いて驚いたこと・気付いたこと

この2年間働いて、驚いたことを以下にあげていく。

2-1. プログラミングができない

僕がいた現場は運用メインだったためか、プログラミングできない人ばっかりだった。いや、別に必要ないならいいのだが、運用の自動化などを考えたときに必須となるスキルではないか。運用はプログラミングスキルがなくてもやっていけるといった話はよく聞くが、僕が経営者だったらそんな技術者はいらない。プログラミングができないということは、業務の効率化を図れないに等しいことなのだから。

現場業務でも結局、プログラミングができないがゆえに、先ほど書いたようにGUI操作で何十個何百個のリソースを作る羽目になっている。すごく馬鹿らしい作業なのだ。
業務を効率化するにはプログラミングの知識は必要不可欠だ。

また、これは開発現場の人から聞いた話で実際には見たことないが、
上流工程ではエクセルなどで設計図を作るので、プログラミングをやらないことが多い。そして、プログラミングできない人が設計図を書いていることも多いらしい。個人的に言わせれば、プログラミングできないやつが作る設計書なんて、品質がよいとは到底思えない。そんなやつが設計書なんか作るなと思うのだ。
最終的には、プログラミングに落とすための設計書なのに、なぜプログラミングできないやつが作るのか、到底不明である。

イーロンマスクも、当時のTwitter社を買収したときに、プログラミングをできない従業員を優先的に解雇したのだ。そのくらい、IT技術者にとってはプログラミングが重要なのであろう。これに関しても、僕は全面的に同意する。

2-2. 設計図やエビデンスがおかしい

設計図やエビデンスを作成する際、エクセルを使ってたことにまず驚いた。エクセルとは表計算ソフトのはずなのに、さすがに使い方を誤っているのではないかと感じた。もっと専用のソフトウェアがあると思うのに、あえてエクセルとは。非常に使いづらいし、設計図も作成しづらいだろう。
エクセルを使ってることにも驚いたのだが、さらに驚いたのは、エビデンスのほうだ。なんと、一枚一枚成果物に対してテストを行い、そのテストが成功したか否かのスクショをとり、それをエクセルにコピーし、テストが正しいことを証明しているのだ。

  • くそ面倒(何百枚も撮影する)
  • 普通に改ざんできる
  • 何百枚も撮影と長時間集中するため、テストの失敗を見落とす

なんと愚策な。まず、このやり方では一枚一枚スクショを撮影するので非常に時間がかかる。
そして、こんなエビデンスを提出させられた側は見づらくて仕方ないし、本当にあっているかわからない。
また、テスターも一枚一枚スクショをとっていたら、見落としてしまう気がする。本当にテストとして正しいのか疑問だ。

また、今では、テスト自動化ツールも多く、効率的に行えるのだ。そういったツールを導入しスマートにやるのが、ITの本質だ。
こんなことをしていては、日本のITは本当に衰退するばかりだ。

2-3. 手順書の作成と作業者の存在

これも不思議なのだが、手順書を見ながら、手順に書かれた専門知識のない作業者が実際に作業を行うこともよく目にした。手順作れるならば、スクリプトを組むなり自動化すべきだと思うのだ。
しかも手順書は管理が大変で、こちらも変更すべき点があっても放置されたままであることが多い。
僕がいた現場では、インフラはクラウドコンピューティングを中心に運用していた。僕自身はAzureを使うことが多かったのだが、Azureの画面UIは頻繁に変更される。そのせいで、実際の画面UIと手順書に貼ってある画面UIが違っていたせいで、作業ミスなども発生した(自分がミスしたわけではない)。
手順書などはあまり作るべきではないし、作業者はできるかぎり排除して、自動化すべきではないか。

2-4. やたら資格にこだわる

僕が所属していた会社では、資格取得が推奨され、合格すると試験費用と合格祝い金がもらえた。会社によりAZ-104(Azureの中級資格)の取得も指示されたほどだ。
資格自体を否定する気はないが、ITの資格は正直取る必要がないと思うのだ。
なぜなら、資格の勉強ができるからと言って実務ができると限らないからだ。
実務の方が明らかに難しいし、そんな資格取る暇あるならば、仮想マシンやネットワークを実際に構築していった方が実務に役立つ。

  • プログラミングならとにかくコーディングしてコンパイル実行
  • クラウドエンジニアならとにかくAzureなどをさわって実際にリソース作成
  • コンテナ学ぶなら、実際に環境をたくさん作成

など、手を動かして試行錯誤したほうが、よほどか自分のためになり、実務にも活かせる。
資格は暗記、実務は仕組みを理解と思っているので、資格にこだわりすぎるのも愚かなことではないか。

2-5. ITには向き不向きはある

未経験で入ってきた人もいれば、大学で情報工学を学んで入ってきた人もいる。けれど、入社して2年以内に辞めてしまう人もいて1割程度いて、大体が自分に向いてないという理由だった。
実際に思うのだが、ITは覚えることが多いので、好きじゃないとなかなか厳しい。業務時間中はなかなか勉強する暇もないので、結局は自分で休みなども勉強しないと技術が身につかない。特にITは次から次に新しいサービスが出てきており、技術の移り変わりは激しい。自分から勉強できないと、技術のトレンドにもついていけない。

3.退職した感想

今思うのは、本当にやめて正解だったと思います。退職に対して後悔は全くしていなく、ベストなタイミングだったと思います。もともと、数年で辞めようと思っていたので、しっかりやりきれた2年4ヵ月だったと感じています。これ以上続けても、あまりに自分のためにもならないし、業務もつまらないと感じてそろそろ限界を迎えてきていました。
しかし、この期間で学んだことは非常に多く、以下に学んだ内容を列挙すると

  • IT技術
    • インフラ技術
    • クラウドコンピューティングサービス
    • フレームワーク
    • システム運用
    • データベースの操作
      など
  • 社会人の生活
  • 給料・税金・社会保険料・年金のしくみ
  • 多重下請け構造などのレガシーなIT業界の問題点
  • ビジネスモデル
  • 勤務体系(固定給や有休、残業など)
  • 財務諸表の読み方

本当に勉強になりました。この点においては会社には非常に感謝していますし、退職日には社長に対してしっかりお礼を伝えてきました。
この経験を今後必ず活かしたいです。

また、仮に新卒でSES企業に入ってしまった場合は、2年くらいでやめるのをおすすめします。そこでしっかりITについて学び、もっと儲かる業界へ行くのが最適だと思います。2年で自信がなければ、3-5年くらい働いてもいいと思いますが、5年以上働くのはおすすめしません。もっと、給料アップを狙えますので、転職なり独立したほうがよいでしょう。

4.今後の展望

去年、業務でメンタルを病んでしまいました。そのときに、来年(執筆時点では今年)での退職を決意。退職したら北海道へ行きたいなとずっと考えていました。
なので、退職した2週間後には北海道へ飛び、2ヵ月の間北海道で住み込みで働く予定です。
そのあとは特に職場は決まっていないが、現時点ではフリーランスとして働いてみようと思ってます。
まずはエージェントに登録して挑戦してみようと思います。失敗しても全然いいので。

また個人的に作りたいシステムもあるので、それも同時並行でやっていこうと思います。
今までは敷かれたレールの上を全力で歩む人生だったのが、これからはレールを自分でつくってその上を全力で歩む人生になるでしょう。ここからが、ある種本当の人生のスタートだと思っていますので、後悔ないように楽しい人生を歩んできます。

長く読んでいただきありがとうございました。

14
11
2

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

Comments

No comments

Let's comment your feelings that are more than good

14
11

Login to continue?

Login or Sign up with social account

Login or Sign up with your email address