今は営業のお仕事をしていてIT業界未経験ですが、IT技術者になれるかな？
私も元々は異業種の営業職からIT技術者に転職したんです！
きっと貴方もなれます！
実体験を紹介するので参考にしてください
今回は、営業職でIT経験が全く無い状態からITエンジニアに転職した自身の経験を紹介しつつ、ITエンジニアを目指す際のポイントを紹介していきます。
営業からITエンジニアになるまで
当項では営業のお仕事からITエンジニアに転職するまでの流れを振り返って紹介します。
かなり長い話ですし内容も古く当時と今では状況が異なっているものもあるかとは思いますが、一応実話なので参考がてら目を通していただけると幸いです。
営業のお仕事をしていた頃の話
もう十数年前ですが、私は金融系の個人を相手にした営業のお仕事をしていました。
営業職は一般的には「技術職」のカテゴリーには含まれませんが、実際には営業として顧客や見込み客を相手に有利に事を運ぶための話法だっり、考え方だったり、有形無形の技術やテクニックは多くあります。
そういった知識を本で仕入れては実践して効果を試すといった繰り返しが面白く、自分なりにやりがいを持って働いていました。
ただ、営業のお仕事では当然目先の売り上げを作ることが目的の仕事であり、売り上げが唯一無二の業務評価対象です。
また自身の営業成績は累積されて評価されるものではなく、一ヶ月毎や隔月、四半期毎になどでキレイにリセットされて、新たな気持ちで売上獲得レースを同僚と繰り広げていかないといけません。
その繰り返しが将来も続いていくことが急に不安になり、後先考えずに辞めてしまいました。
ハローワークの職業訓練へ申込み
会社員として雇用保険が給料から徴収されている人は、失業すると「失業給付金」がもらえます。
失業給付金は前職でもらっていた給料の5割から8割にあたる金額を失業者本人に一定期間給付し、その間に次の仕事を見つけてもらう制度です。
国民のセーフティネットとしてとても大事な相互扶助の仕組みです。
解雇や倒産などの会社都合による失業の場合は退職してから一週間ほどで給付が開始されますが、私のように自己都合による退職では約３ヶ月後からしか給付を受けられません。
ただ、自己都合であってもすぐに給付が受けられるケースが有ります。
職業訓練校で開催される学科には色々種類があり、名目上、再就職を支援するために税金を使って実施される為、電気技師の養成科や溶接技師の養成科など堅実な「手に職」的な学科が多かった記憶が有ります。
因みに、最近の状況はわかりませんが、当時は特定の時期に県がプロポーザル形式で職業訓練開催校の委託企業を募集し、民間のスクール系の企業やIT系企業が応募します。
企業が提案する学科やカリキュラム、スクールとしての設備や体制などをもとに応募企業を点数付けして、高得点を取れた企業が職業訓練校の委託案件を受注できる仕組みです。
当時私が受講することにしたのは、ITのネットワーク関連の知識習得、及びLinuxのサーバー構築に関する知識を習得し、「LPIC」の資格習得を目標にしつつ、IT技術者を目指すといった学科でした。
当時はパソコンを人並みにしか扱えず、全く専門的な知識も有りませんでしたが、これならパソコンの勉強にもなるだろうし、パソコンの前に座っているだけだから楽だろうという安易に考えで当学科を選択したのですが、そこが人生の大きな分かれ道でした。
ネットワークの論理的な仕組みやLinuxで作るサーバーが楽しい
受講した学科は、全体で四ヶ月間の間、平日の日中に毎日実施され、最初の三ヶ月間は座学で学び、最後の一ヶ月間は現場実習として、訓練生の受け入れに協力してくれる企業のなかで実務を経験させてくれます。
当時受講した学科は50歳以下の比較的若年層を対象にした学科で割と周りの人と年齢が近かったり、同じ学科を選択した事もあり、考え方や志向が似ている人も多く、すぐに仲の良い人たちもできて、すっかり気持ちは学生時代に戻った感じで楽しく通っていました。
当時の思い出深い授業では、例えば「telnet」サーバー構築の授業の時も同じ教室の受講生のパソコンにtelnetでこっそり接続し、唐突にCDドライブを勝手にイジェクトする。
更にCDドライブをイジェクトする「Shell Script」を作り、それを人のPCの「cron」で勝手にスケジュール化し、10秒毎に本人の意思とは関係無くCDドライブがイジェクトするといった様々なイタズラを行いながら、ネットワークやLinux自体も習得していきました。
LPIC(Linux技術者認定試験)に合格
対象の学科の最終目標はもちろん就職なのですが、もう一つの目標として、Linux技術者認定資格である「LPIC レベル1」に合格するというお題目がありました。
LPICは初級のレベル1から高度なレベル3まで有り、今は更に分野ごとに分かれたLPIC関連の試験があるようです。
LPICレベル1自体はそれほど難易度の高い資格ではない為、実機を触り、ある程度真面目に勉強していれば誰でも合格することは可能です。
ただ、TCP/IPといったネットワークの基礎知識も必要になり、一般の人にはあまり馴染みのないコマンドラインでOSを操作することが必要になる為、ITのド素人が合格するのは簡単ではありません。
学科での授業が始まり二か月ほどすると、早い人はLPICの受験をしだします。
当時の当学科には約十数名ほどが受講しており、なかには元IT技術者の人もおり、そういう人は当然ながら習得も早く、さっさと受験をして合格してきます。
一人が受験して合格してきた話を聞くと、当時の受講生たちは、後れをとるまいと競うように受験に挑むように雰囲気になります。
私もその空気に影響され、当時の受講生の受験レースにおいて、先頭から3番目ぐらいの早いタイミングで無事合格することができました。
IT業界ではどんな資格を持っていようが実務経験が第一であり、IT技術者のなかには「資格取得の勉強は時間の無駄」と言い切る人も多くいます。
ただ、私は資格取得を目指して勉強し、ドキドキしながら受験をして合格を勝ち取ることで、ある一定の物差しにおいて自分の努力や能力が保証され認められたという成果を得ることができ、それは自身の自己肯定に繋がり大きな自信を得ることになります。
そういった経験はとても重要であり、私は今でも資格習得を目指す人たちを積極的に応援しています。
さて、対象の学科でLPICをいち早く合格した人たちは、次の目標としてCisco社の認定技術者試験の「CCNA」を目標にするように勧められます。
CCNAは主にCiscoのルーターなどのネットワーク機器を扱う為に必要となる知識を測るための資格であり、一般的にLPICよりも難しいと認識されており、実際に合格難易度はだいぶ上がります。
私も周りの人たちより早くにLPICに合格したため、お先に失礼とばかりに学科の終盤はCCNAの学習を始めておりました。
その頃には、座学期間は終了に近づいており、現場実習を迎えるための準備などが始まっていきます。
現場実習で実務のお手伝い
当時の学科では、現場実習の受け入れ先企業がいくつかあり、訓練生がそのなかから希望する受け入れ先を選択するという形式で現場実習先が決まりました。
当学科の講師は、とある独立系のシステム開発会社から講師として派遣されており、そのシステム開発会社も現場実習の受け入れ先企業に含まれておりました。
その講師とも気が合い、当時仲の良かった訓練生の仲間は講師も誘って頻繁に飲みに行っていたこともあり、私はその講師が所属していたシステム開発会社を自身の受け入れ先として選択しました。
現場実習といっても、三か月程度の資格取得を目的とした勉強をしただけの素人に割り当てられる仕事がそれほどあるわけではありません。
よって、日によっては割り当てられる仕事がなく、資格取得の勉強でもしててくださいと言われて、それで一日が終わる日もなかにはありました。
そのシステム開発会社では、受託開発も受けていたので、システムで使うテストデータの作成やら、社内で使うLANケーブルのを自作したり(先端の処理をしていないLANケーブルを任意の長さで切断し、内部の銅線をばらして、適切に端子を圧着して取り付けることで、LANケーブルは自作出来ます。)、社内の雑用をのんびりとこなしていました。
現場実習先の会社から正社員雇用をお誘い
現場実習が始まって半月ほど経った頃に、現場実習先の会社から、職業訓練が完了したあとは正社員として自社で働かないかとお誘いをいただきました。
因みにそのシステム開発会社は、自社内で講師を養成し、教室用のスペースなども確保し、職業訓練を積極的に受託していましたが、以下のようなビジネスモデルがその根底に有ります。
- 講師のコストは職業訓練を受注した利益で賄う(委託費は結構安い)
- 職業訓練開催中に訓練生のなかから見込みがある生徒に目星を付ける
- 見込みのある訓練生を自社にスカウトし、未経験職種として低賃金で雇う
- 職業訓練校は再就職できた人数が実績になり、その実積は次回のプロポーザルで有利になる
- 雇用後は先輩技術者のいる現場に低単価で派遣、又は人数制限の無い業務委託系受注先の現場に突っ込み現場経験を積ませる
このビジネスモデルを実現させるには、それなりの準備や手間が必要で簡単では有りませんが、私が居た会社ではこのモデルが上手く回っており、今ほどでは無いが当時もそれなりに優秀な技術者を集めるのは大変だったのですが、その会社では人の採用に関しては一切コストを掛けなくても済んでおりました。
一見すると、完璧なモデルにも見えますが、実はひとつ欠点があります。
それは、「職業訓練校は必ず受託できるとは限らない」という点です。
最近の状況はわかりませんが、当時の職業訓練校開催の案件は、プロポーザル形式で校正に採点されて選定されていました。
県などから募集が発表されると、自社での開校を希望する企業は、自社で実施したい学科内容や予定しているカリキュラムなどを事前に決めて県などに提示します。
県などの委託元では、各企業から提示された学科内容やカリキュラム内容などを精査し、その企業の職業訓練校としての設備(トレイは男子用と女子用とで分かれているかとか、何席分確保できるか、休憩スペースはあるのか、など)や、過去に開催した経験があればその実績などを複合的に見て採点していきます。
応募する企業が増えれば、当然自社が受注できる可能性も下がります。
職業訓練校では、朝から夕方までの昼間部だけではなく、なかには夜間部を前提とした募集もありました。
その為、職業訓練校の受注が上手くいっているときには、昼間部の訓練校を開催した後、同じ教室で同日中に夜間部を開催するといったケースもありました。
ただ、毎回その様に都合よく受注できる訳ではなく、プロポーザルの結果、受注できないケースも当然発生し、その場合、次の職業訓練校の応募まで教室スペースは空いたままになり、講師職として雇っている社員は社内の受託開発案件を手伝ったり、他社の開発案件の現場に派遣に出されたりします。
また、毎年行政の失業者に掛ける予算は異なります。
年によっては、職業訓練に関する予算が減らされるケースもあり、その場合は職業訓練を委託する先も減らされたり、職業訓練の委託では生徒一人につき数万円を県などが委託費用として職業訓練開催先に支払うのですが、その金額が減る場合もあります。
その時々の行政の状況や監督官庁の政策で職業訓練のまつわるビジネスも不透明だったりします。
そういったことが色々影響したのかはわかりませんが、私が昔働いていたシステム会社では、ここ数年は職業訓練は受注していないようなので、もしかしたら職業訓練関連の事業は辞めてしまったのかも知れません。
当時、現場実習先としてそのシステム開発会社を選択した訓練生は7～8人ほどおり、そのなかで何名かに声がけをしたようです。
そのなかの私を含め2名がその誘いを受け入れ、そのシステム開発会社に就職することになりました。
給料は非常に安く、世間一般の新卒社員レベルの金額でしたが、IT技術者として何の経験もない以上、妥当な金額としてその条件で納得しました。
システム開発会社に就職してITエンジニアのキャリアスタート
現場実習先のシステム開発会社は、職業訓練校を開催するための教室用のスペースがあり、後は事務所があるぐらいの小規模がオフィスで、社内に常駐する社員は社長と事務員、数名の技術者で、その他の社員は他社のシステム開発現場やシステム運用系の現場に派遣されており社内にいない、所謂SES(システムエンジニアリングサービス)系の会社でした。
システム開発会社と名乗ってはいますが、実態は派遣会社のようなもので、今もそういったシステム会社は多いですが、当時は多重派遣についての規制も緩かったこともあり、もっと多かったと記憶しています。
因みに当時、他社の現場にSESで派遣されることを「出向」と呼んでいました。
よって、以降の文章で出てくる「出向」とはSESだと理解しながら読んでください。
あと、SESについて、参考までにWikipediaの記事も抜粋して紹介します。
システムエンジニアリングサービス契約 -Wikipedia-
システム開発会社を名乗りつつ実態はSESが殆どという会社では、待遇があまりよくなかったり、スキルアップできる機会が少ない場合が多く、今でもあまりおすすめはしませんが、ただ、まったくIT業界での就業経験が無い場合は、比較的就職しやすいそういった会社でIT技術者として経験を積むことは選択肢として悪くないかと思います。
さて、当時の話に戻りますが、入社直後はまだ出向先の現場もなく、社内で現場実習の頃と同じような雑用をやりつつ、パソコンにインストールされていたExcelでVBAを触ってみたりして独学で何となく勉強をしていました。
また、CCNAの取得も目指して勉強していた時期だったため、社内でCCNAの勉強もさせてもらっていました。
そんなこんなで入社して2～3か月後に、私が参加できる現場が決まりました。
その現場は当時結構多かったシステム系技術者派遣の仲介専門の営業会社(自社の技術者を社外の現場に出したいシステム会社と他社の技術者を呼んでプロジェクトなどを手伝ってもらいたいシステム会社の間に入り、仲介手数料として人月単価の数パーセントを毎月取っていくといった業態でしたが、多重派遣に対する規制が厳しくなり、現在はそういった事業はできない)を経由した案件で、PCやサーバー故障時の部品交換などをDELLなどのメーカーから委託されて請け負っている会社の、今でいう「フィールドサポートエンジニア」の仕事でした。
ただ、その現場では3か月ほどお世話になりましたが、パソコンを一台与えられて、資格の勉強でもなんでも好きなことをしてて良いと言われて、周りが忙しく仕事をしている最中、私はパソコンで好きなことをしているという謎の案件でした。
現場の責任者の部長さんからは、何も仕事が与えられない状況になってしまい申し訳ないと何度も謝られ、私に任せたい仕事を作るから待ってほしいと言われていました。
当時はよくわかっていませんでしたが、今にして思えば多重派遣が厳しくなった頃だったため、元々予定していた私の仕事は、DELLなどの大手メーカーからの委託を受けている仕事でありコンプライアンス的にも多重派遣で呼んだ技術者に作業をしてもらうことができなくなり、「フィールドサポート」職以外の案件を作って、そこで私に動いてもらうと考えていたと思われます。
で、その現場に入り、3か月ほど経過して、ようやくその現場の部長さんからお声が掛かり、サーバー構築のプロジェクトを始めるので、それに今後関わっていってほしいと話をいただきました。
これまでの生殺しの状況から(とは言え、仕事が無く余りに暇だったおかでで、Excel VBAの基礎的なものを習得し、CCNAの学習もだいぶ進めることができていました)解放され、技術者らしい仕事ができると私は喜んだのですが、そのタイミングで自社の営業から新しい現場が見つかったから、次はそっちに行ってほしいと依頼がきました。
個人的には現在の現場でようやく始まる新しい仕事に関わりたくて、そのように要望しましたが、新しい現場の方が単価が高いらしく聞き入れてもらえませんでした。
新しい現場は某有名企業の内部SE
新しい現場はとあるメーカー企業内部の情シスのような部署でした。
ただ、この部署は特殊で、そこの会社が外注で作ってもらっている受発注システムを、その会社の取引先に導入してもらい、そのシステムの導入作業や取引先の人たちへの操作説明、導入後のヘルプデスクといった業務を自社の社員ではなく、社外の技術者に常駐してもらい運用しているという部署でした。
そこでは、そのシステムそのものや、付随するパソコンやネットワークなどへの質問やトラブル関するヘルプデスクをやりながら、取引先のシステム導入が決まったら全国各地の取引先まで訪問し導入作業や説明会を実施します。
また、その部署は情シス的な役割もあったため、その企業の社内で使用する簡易システムをAccessで作ったりしていました。
そういった比較的初心者向けの現場に入ったのですが、私の知らない大人の事情で、その現場には上記のシステム導入用の人員として将来的に受け入れるが、当面は緊急で開発してもらいたいAccessのシステムがあり、そのAccess開発のエンジニアとして現場に入って常駐しながら作ってほしいと言われました。
「もともとネットワークとかLinuxの勉強しかしてないし、Accessなんてまともにちゃんと触ったことも無いんですが…」
Access開発者という無茶振りと格闘の日々
Accessは確かに少しは触ったことはありました。
それは、自社内でお手伝いとしてAccess内のローカルテーブルにデータを手入力で投入した程度で、指示された通りに作業しただけで、Accessが何なのかもわかってはいませんでした。
「リレーション」ってなに？
そもそも「データベース」って何ですか？
というのが最初の状況でした。
ただ、私は現場に「Accessの開発者」として呼ばれているので、当然現場にいる間は「Accessを知ってる風」を装わないといけません。
Access技術者として現場の会議や打合せにも参加させられていました。
また、Accessで作ってほしいと依頼されていたシステムには納期があり、そのタイミングで新しい業務がスタートするらしく、遅れることも許されない状況でした。
多分今の私なら一週間も有れば余裕で作れるボリュームのシステムでしたが、当時のド素人の私には、途方もなく彼方にあるゴールでした。
現場での支援が期待できないなら、当然そんな現場に無理やり突っ込んだ自社に責任があるため、自社に支援をしてもらおうと思いましたが、自社内のシステム開発の技術者は「Accessはわからない」という人ばかりで、社内の誰かに教えてもらうという当たり前の支援も受けられませんでした。
追い込まれた私は、自社からAccessのインストーラーを借りて自宅のパソコンにインストールし、昼間に現場で上手くいかなかった処理を自宅のAccessで再現し、夜な夜な深夜まで対応方法を調べて、翌日に現場でその調査結果や対応方法を試して開発を前に進めるといった仕事漬け、Access漬けの日々を送りました。
技術的に躓き、自己解決が難しい時はインターネット上の掲示板やQ&Aサイトに頼りました。
あの頃の苦しかった時期は今でも昨日のことのように思い出せます。
その結果、今にしてみれば相当拙いアプリケーションでしたが、表面上は何とか動く代物が期限内にできあがり、その後予定通りその現場の正式なシステム導入運用サポートメンバーとして迎え入れてもらえることになりました。
システム導入運用サポートの現場で習得した技術や知識
システム導入業務やヘルプデスク、システム運用などを経験し、ITのド素人だった私は以下のような技術や知識を習得しました。
- パソコン全般に関するユーザーレベルの基本的な知識
- 有線LAN、無線LANに関するユーザーレベルのネットワーク基礎知識
- リレーショナルデータベースのユーザーレベルの基礎知識
- システム開発と運用に関するシステム管理者視点の知識や経験
- AccessやExcelとVBAを組み合わせた業務アプリケーションの開発技術
ITエンジニアとしてはまだまだ未熟ですが、最低限の実務経験を積みました。
最初に習得した各知識や技術は、開発者というよりユーザー寄りの内容でしたが、下手に開発業務にどっぷり浸かるよりも、ユーザー系の業務経験を積んだことで、何事もユーザー目線でプロジェクトを進めたりシステムを設計したりすることができるようになり、今にして思えばこれらの経験はその後のITエンジニアとしての仕事に大きな影響を与えてくれたと感じます。
自社に戻りプロジェクトリーダーからプロジェクトマネージャーへ
私が出向したシステム導入運用サポートの案件も気がつけば参加して２、３年ほど経過し、その現場に自社社員の増員もできましたが、私はもっと技術者として高度な仕事に関わらないと不味いのではないかと焦りだしていました。
どんどん新しいことを覚えて高度な技術を習得していかないと、一人前の技術者として立身出世はできません。
それに、何より刺激がなくて退屈でした。
そんなことを思いながら出向先の現場で仕事をしていた頃、私が所属するシステム会社が頑張って交渉し、私がお世話になっていた現場から、ユーザー直受けの業務システムの受託開発案件を取ってきました。
対象のシステムは比較的小規模ですが、短納期、且つ要件が状況よってコロコロ変わる可能性もある危険な案件でした。
そのため要件定義を可能な限り短縮し、現場側の要望などをレスポンス良く開発者に伝達していくには、自社に常駐して自社の状況を良く理解している技術者の所属しているシステム開発会社に発注するのが最適と顧客側で判断したようです。
そうすると、昼間は出向先の現場で、本業のシステム導入運用サポート業務をやりながら、システムの発注側の立場で新システム関連の調整業務をこなし、夕方からは自社に出社して、システム開発会社の社員として開発業務やプロジェクト管理を手伝うといったダブルワーク状態に陥っていきました。
このように文章で説明すると、辛い毎日のように感じるとは思いますが、当時の私はこれまでの刺激の少ない仕事から、一気にこれまでの経験したことのない技術者らしい仕事に関わることができるようになり、やりがいを持って働いていました。
また、その多忙な状況について、出向先であり、システム開発の顧客でもある現場の社員(所謂プロパー)の皆さんや現場のメンバーの皆さんからも応援や支援をしていただき、例えば徹夜明けで出向先に遅刻して出勤しても笑顔で許してくれるといった特別待遇で接していただけていました。
※周りの人たちはそんな私を哀れんで優しくしてくれたのかも知れませんが…。
そんな毎日を繰り返していくなかで、なんとかシステムを納品することができ、そこで自社と顧客企業とで信頼関係も生まれ、次の受託開発の案件も取れて、私は同じような立ち回りをしていきながら、徐々に業務のウエイトが自社内のプロジェクトを回すことにシフトしていきました。
システム開発の顧客側でもある出向先の現場でも、自社の業務や内情を理解している技術者が業務システムを作ってくれる方が効率的だったり無理も効くということもあり、出向は終了して自社に戻ってシステムを作って欲しいと要望されて、晴れて私は業務システムのプロジェクトマネージャー兼SEとして、出向先から自社のシステム開発会社に戻ることになりました。
その後、数々業務システム開発などのプロジェクトを経験し、それらのプロジェクトのなかで、元々IT技術者を目指していた頃に志望していたネットワーク構築やサーバー構築系のプロジェクトも併せて経験していき、システム開発プロジェクトやネットワーク、サーバー構築プロジェクトの両方に関われるプロジェクトマネージャーとして更に多忙な毎日を送ることになりました。
その後、長年勤めたシステム会社を辞めて社内SEとして新しい環境や職場で活躍していくのでした・・・。
営業職などの非IT職種からITエンジニアを目指す場合のポイント
前項では長々と過去の自身の経験や経緯を紹介しましたが、当項では、私のようにIT以外の職種からITエンジニアへ転職する場合のポイントを紹介していきます。
給料条件の優先度を下げよう
ITエンジニアと聞くと、一般的には給料が良いイメージが有ります。
実際業界別の賃金統計を見ると、IT業界はその他の業種のなかでも上位の平均賃金です。
また、求人サイトの広告などでもIT業界の高い年収をアピールし転職を煽ります。
メディアはデータサイエンティストやAI技術者など尖ったスキルの持ち主の破格な年棒を紹介します。
しかし、異職種からIT業界への転職する場合、実務経験もなく、スキルもまだまだ未熟な状態です。
ITエンジニアは技術職で、非IT職の人にはできない高度な技術と知識を使って仕事をします。
その技術や知識が高度であればあるほど、それが賃金として加味されます。
その高度な技術と知識を持ち合わせていなければ、やはり高い賃金は貰えません。
それどころか、元々勤めていた会社での業務経験や業務知識、昇給などの待遇向上などをまるっと捨てることになり、給料が下がる可能性も大いにあります。
もし非IT職からIT業界にエンジニアとして転職する場合は、給料が下がることは覚悟し、給料よりも仕事内容などの別の条件を優先させましょう。
なんでも良いのでIT系の資格を取っておこう
IT技術者において「IT系資格」は、まったく評価対象にしない人もいれば、重要視する人もいて資格保持者に対する受け取りかたは様々です。
IT技術者は所謂「士業」とは違い、その職業に就くのに資格は一切必要ありません。
IT系の資格は、国が認定する国家資格に、各ベンダーが独自に制度化しているベンダー系資格などがあり、種類も豊富です。
何ができれば、又は何を知っていれば「IT技術者」と名乗れるという決まりやルールが特に無いがために、無形の「IT技術」や「IT知識」を測るためのひとつの物差しとして、こういったIT系の資格が活用されています。
さて、そのIT系資格ですが、もし非IT職種からIT業界に転職したいのであれば、必ず何らかの資格を事前に取得しておくことをお勧めします。
私はIT系の資格を取得することで、以下のようなメリットや効果があると考えています。
- その資格に関連するITの最低限の知識を有しており技術的な話が通じる
- IT業界で頑張っていきたいという意気込みを感じる
- 何らかの目標に対して地道に努力をする真面目さを持っている
- 取得した資格の種類や分野によって、本人の志向や希望する職種が明確になる
IT業界未経験であれば、その人のこれまでの経験や持っているスキルで評価をすることはできません。
そのため、少なくても何らかのIT系資格を取得していることで、評価は大きく変わると考えています。
ここで重要なのは、その資格の難易度はあまり重要ではないということです。
もちろん国家資格系であれば「高度情報技術者試験」レベルの資格を取得していれば感心しますし、ベンダー系資格でも上位の資格であれば、それなりに努力をして取得したのは理解できます。
ただ、IT業界未経験で難易度の高い資格を取得できたとしても、それは試験勉強が得意なだけという見方もできてしまい、その資格の難易度に見合う評価が面接の場でもらえるかといったらそういう訳ではありません。
上記で列挙した資格取得のメリットや効果は難易度が低い資格であっても高度な資格と同等に得られます。
また、資格の取得は面接時のアピールポイントとしても有効ですが、他にも、自分自身の自信にも繋がります。
その資格の難易度にもよりますが、試験勉強をして試験に臨み、晴れて合格すると、やっぱりそれなりにうれしいですし、自分の知識に対して公式に合格をもらえたという事実は確実に自信に繋がります。
色んな意味で、資格取得を推奨したいです。
IT業界未経験者におすすめの資格
お勧めの資格というのは、本人がIT業界で何をやっていきたいのかという志向によってかわるため、一概にこの資格を取ると良いと指定することはできませんが、IT業界で何をやりたいかは置いておいて、取り敢えず何かIT系の資格でも取ろうとした場合は、国家資格の「基本情報技術者」が無難です。
難易度はそれほど高くなく、また一度取得すれば一定期間で失効するといったこともなく、ずっと履歴書に書けます。
問題の内容はシステム開発者寄りですが、パソコンなどのハードウェアやネットワークなど出題されるジャンルも広く、幅広い知識が問われます。
その為、基本情報技術者の試験勉強をすることでIT系の基礎的な幅広い知識が身に付くことが期待できます。
また、もし基本情報技術者の内容があまりに難しく感じるなら、その下位資格の「ITパスポート」でも良いかと思います。
ITパスポートは基本情報技術者と出題範囲は似ていますが、より問題の難易度が下がっており、合格率も高く資格の名前の通りIT業界入門のパスポートのような資格です。
後は、自身の進みたい職種ややりたい分野が明確になっているなら、その職種や分野に合わせたベンダー系資格でも良いです。
システム開発系であれば「Oracleマスター」「JAVA」といったベンダー資格の入門系下位資格。
ネットワーク、サーバー系であれば「CCNA」「LPIC」などがベンダー資格の入門系下位資格です。※因みに比較的取得者も多く人気のあったMCPなどのマイクロソフト系のベンダー資格は、最下位の資格「MTA」とOffice系の資格の「MOS」を除いたそれ以外の全ての資格制度が廃止されました。
過去に取得した資格は有効ですが、現在は新しく取得することはできません。
また、他にも様々なIT系の資格が世の中にはあり、ものによってはまったく知名度がなく、取得していることがアピールに繋がらないものもあったりします。
よって、資格取得を目指すなら、スクールなどで対象の資格取得専門のコースが用意されていたり、対象の資格の学習用サイトが多く存在しているような、ある程度知名度のあるメジャーな資格を選択するようにしてください。
残業や休日出勤も覚悟しよう
IT業界というのは、昔から「IT＝ブラック」というイメージがあり、最近では技術者不足も深刻だったり、企業経営に関して「コンプライアンス」が重要視されるようになり、かなり改善されてきていますが、それでもIT業界固有の風土や特性もあり、まだまだ根深くブラックな職場は存在しています。
また、会社や自部署はブラックではないとして、例えば自身が関わっているシステムが110番などの緊急通報を管理するシステムだった場合、そのシステムが不具合で止まればそれが原因で人が死ぬかも知れません。
そんな時にのんびり自宅でくつろいでいる訳にはいかないので、緊急で遠隔対応をしたり、急遽会社に出勤したりする場合もあります。
そういった仕事振りも見方によっては「ブラック」に映るかもかも知れません。
もちろん会社や部署によっては、常に定時帰れて、社内の雰囲気も和気あいあいとし、拘束も緩く、無理な量の仕事も振られない天国のような職場もあるでしょう。
よくシリコンバレーのIT企業の職場なとがメディアでも取り上げられますが、一見するとホワイト企業の最たるもののように感じます。
ただ、そういった天国のような職場では、優秀な技術者しか採用しません。
天国のような職場は、あくまで高い生産性を技術者に維持してもらうために様々な工夫をして居心地の良い労働環境を作っています。
IT業界未経験の新米エンジニアでは高い生産性は期待できません。
なのでそういった人材はそもそも雇いません。
IT業界は人手不足ではありますが、そういった労働環境の良い職場は採用基準もシビアです。
実際面接の場でもそういったアピールができれば、IT業界は意外と根性論も蔓延してますし、どこの会社も人手不足なのは事実なので、アッサリ採用までこぎ着ける可能性も高いです。
ただ、肉体的、精神的に過酷な職場では、その辛さ次第ではいつかは心や体を壊します。
実際に壊れてしまった技術者を私も多く見てきました。
よって、そういった環境に身を置き、しっかりと技術や経験を身につけて、数年後にはもっとホワイトな会社に転職できるように計画的にスキルアップや業務経験を積み上げていきましょう。
楽かどうかで会社や職種を選ぶのは危険
今は転職希望者向けの口コミサイトも多くあり、気になった企業の口コミから応募の可否を判断することも多いです。
また、IT業界では様々な職種があり、インターネット上ではその職種毎に業務内容や労働環境などの情報も色々と転がっています。
そういった情報は積極的に収集して、自身の転職活動に役立てるべきですが、職種や会社によっては「仕事が楽」というアピールだったり、SNS上の書き込みをだったりを見ることもあります。
その発想になること自体は至極当然だとは思いますが、そういった不安から「仕事の楽さ」を最優先に会社や職種を決めるのは間違いです。
例えば、IT系の職種でも楽という観点で有名な職種があります。
よく聞くのは「監視オペレーター」です。
仕事内容は色々なケースがありますが、例えば大企業の社内の基幹系システムでは、日中もそうですが、特に深夜から朝方にかけて、大量のバッチ処理がスケジューリングされて動いています。
これらのバッチ処理は万が一エラーなどで異常終了したり止まってしまった場合に、必要なデータが作成されなかったり、データの整合性が崩れてしまったりと大きな問題になります。
事業規模が大きければ大きいほど、動いているシステムも巨大になり、僅かなエラーでも即座に適切な対応を取らないいけないケースがあります。
そんな重要なバッチ処理の実行状況を常に監視し、トラブルが起こった場合に適切な対応をするお仕事が「監視オペレーター」です。
適切な対応と書きましたが、実際にはオペレーターが独自に判断して何らかの対応をすることは許されておらず、基本的に作業マニュアルに沿って対応します。
不測の事態でマニュアル内で対応方法が存在しなければ、予め指示されている連絡先に連絡を取り、指示を仰ぎます。
また、トラブルが無ければ、バッチの実行状況を報告書にまとめて、後はボーッとしているだけの職場も多くあります。
日勤もありますが、夜勤の方が多いので、監督する人もおらず気楽だったりします。
すべてのオペレーターの仕事がそうとは言えませんが、基本的には「誰でも務まる」業務内容の場合が大半です。
他にもデータセンターのオペレーターなんかも似たような仕事です。
データセンター内のラックを巡回して、ハウジングでラックを契約している場合は、バックアップ用のテープ交換をしたり、サーバー筐体の物理的なランプ状態を確認したり、データセンター内の死活監視用の画面を確認し、異常があれば指定された連絡先に連絡をします。
また、トラブル時もやはり対応マニュアルに沿ってサーバーの電源を落としたり、ディスク交換をしたりします。
やはりバッチ監視と同じようにオペレーターが独自の判断で対応することは許されていません。
これらの職種は、確かにIT系の仕事ではありますが、エンジニアとして第一線で通用するスキルが身に付くような仕事ではない場合がほとんどです。
せっかく相応の覚悟で未経験のIT業界に飛び込んでも、ITエンジニアとしての技術の習得や専門的な業務経験が積めないのであれば、リスクを取って転職してきた意味がありません。
よって、異業界からIT業界に転職する際には、その仕事が楽かどうかや、自分でも務まりそうかどうかといった低い次元の視点で選択するのではなく、自身が成長できそうな仕事や環境かどうかや、その仕事についてどのような技術を身に付けたいかといった5年先、10年先も見据えた視点で職種や会社を選択してください。
最後に
久々に長々と記事を書きました。
過去の体験談を書いていると、当時のことを色々と思い出してとても懐かしく思いました。
自身の人生の「IF」をあれこれ考えても今が変わるわけではなく無駄だと基本的には思っていますが、少なくても過去の自分が選んできたあらゆる選択は、今の自分の状況から考えると、それほど大間違いはしていないじゃないかなと思います。
今回の記事がどこかの誰かの背中を押したり、勇気付けたりすることがあれば嬉しいです。
それでは皆さん、ごきげんよう。
PS Googleさん、discover向きの記事になったと思うので、Google砲を期待しています！
因みに、その後私はSIerを辞めて社内SEとして非IT企業の情報システム部署に転職しました。
その時には転職エージェントのdodaさんにお世話になりました。
