IT エンジニアの仕事内容はどうなってるんだろう？ 経験者にわかりやすく説明してほしいなぁ…。
IT エンジニアに興味はあるけど、仕事の実態が見えずに不安という方もいらっしゃいますよね。
この記事では IT 歴 20 年の経験の中で得た、それぞれの職種の仕事内容と、どのような人にオススメなのかをわかりやすくお伝えします。
この記事を読むことで IT キャリアの実態をイメージできるようになり、職種を選ぶ安心感が得られるようになりますよ！
- IT 歴 20 年のエンジニア
- 大学、研究所、自社開発企業でプログラミング、サーバ、ネットワーク、クラウド、社内情シスなどを多種の業務を経験
- 安定志向な性格で安心や安全が大好き
- 未経験者向けに 安定志向の IT キャリア入門 という情報発信中
- エンジニアに興味がある人に安心して IT キャリアを歩んでほしい！
りもじいが務めた IT エンジニア 4 種類
インフラエンジニア
インフラエンジニアは企業や組織の IT インフラストラクチャ（ハードウェア、ソフトウェア、ネットワーク、データセンターなど）を設計、構築、管理、保守する職種になります。
「インフラエンジニア」と表現される場合は、対象となるシステムは企業がお客さんに提供するサービスの基盤である事が多いようです。自社向けのシステムが対象であれば、後で述べる「情シス」に分類されることが多いです。
インフラエンジニアになった経緯
研究所から民間企業へと転職する際にどの職種を選ぶかを考えました。
30 代に入っており、ビジネスパーソンとしての実績もなかったため正直あまり余裕はなく、とにかく即戦力になれる事を優先することにしました。
プログラミングの経験はありましたが、IT 業界ですぐに通用する開発実績は持ち合わせていません。一方でサーバやネットワークの管理は大学や研究所で経験があり、何かしらすぐに役立てるイメージが持てました。
手持ちの経験との親和性が高かった職種がインフラエンジニアであったことから、その道を選ぶことになりました。
りもじい今にして思うと、とにかく民間企業へ転職せねばという思いが強く、自身の志向性や将来性みたいな事はほとんど考えられていませんでしたね。長く続けられたのは運が良かっただけかもしれません。
インフラエンジニアの仕事内容
自社開発企業でのインフラエンジニアのお仕事は、次のようなものでした。1人ではなくチームで対応していたものの、それなりに幅広く手掛けていたかなと思います。
- サーバ管理
-
自社サービスの基盤として利用しているサーバについて、機材の選定と購入に始まり、設置や設定などのセットアップに加えて、管理や保守も担当しました。必要に応じてサーバのメンテナンスやトラブルシューティングも行いました。
- ネットワーク管理
-
自社サービスの基盤ネットワークについてもサーバ同様に担当していました。通信の仕組みについて理解し、ネットワーク機器に特有な挙動も把握する必要がありました。
- データベースシステム管理
-
自社サービス向けに必要なデータベースシステムについても、その設計や導入を行いました。停止するなどの異常が生じると利用者に直接悪影響が出てしまうものなので、ハードウェアが壊れても動き続けるようにしたり、バックアップを数カ所に取るなど、設計には工夫が必要でした。
- ウェブやメールのシステム管理
-
自社サービスで用いられる、ウェブサイトを表示するためのソフトウェアや、メールを送受信するシステムの設計や導入も担当しました。日々の運用を通じて必要なパラメータの調整なども行い、サービスの安定化に努めていました。
- クラウドの管理
-
自社サービスのインフラ基盤相当のものとして利用するクラウドサービスについては、これの導入と運用の管理も行っていました。
- セキュリティ対策
-
個別の枠として記載しましたが、上で書いたサーバやネットワーク、データベースやクラウドなど、全ての領域でセキュリティは考慮します。ベストプラクティスと呼ばれる、「今どきはこれぐらいはやっておくのが基本」は押さえつつ、自社サービスに適した対策を講じます。
セキュリティは基本的にはトレードオフで、しっかりやろうとすればするほどお金や手間が掛かる事がほとんどです。関係者と相談しながら適切な落とし所を探るというコミュニケーションも必要になります。また、技術の進歩やセキュリティに関係する事件によって、数年前と常識が変わる事も多いので情報のキャッチアップも欠かせませんね。
- 資産管理
-
サーバやネットワークなどのハードウェアや購入したソフトウェアは自社の資産となるので、これらの台帳管理も行っていました。数多くの資産があるので、この管理を怠ると人の入れ替わりでどこに何があるのか分からなくなってしまいます。
- 安定稼働継続のための分析や提案
-
各システムの使用状況を中長期的にモニタリングし、自社サービスが将来的にも安定稼働する上で問題になりそうなことを分析する業務も担当しました。その分析結果を根拠にどのシステムの増強が必要かを提案し、最終的にはその導入の計画を主導するなどしていました。
インフラエンジニアの魅力とオススメの人
ハードウェアや機械いじりが好き！という人には向いているかなと思います。ラズパイでつい遊んじゃう人とか、合うと思います。ハードウェア自体も時代とともに進化していますが、個人で高価で精密な機器を入手するのは難しいですよね。仕事を通じてハードウェアの世界の奥深さに触れられるというのはインフラエンジニアの醍醐味かと思います。
また、長期目線で物事を考え、じっくりと取り組みたい人にも相性が良いかなと思いますね。インフラ基盤は一朝一夕では変えられない分、自社で提供するサービスの未来を想像する必要があります。先々を考えつつ次の一手をどうしようという考え方を身につけておくと、人に対して「これをやりたいんだ」を伝える際に「なぜなのか」も伝えられるようになります。自分から物事を動かす力もつけていくことができますね。
りもじいりもじい自身はあまりハードウェアには興味はない方だったのですが、長期目線で仕事に取り組む方は性に合ってました。長く続けられたのはそちらのおかげかもしれませんね。
インフラエンジニアの苦労とその対策
いわゆる縁の下の力持ちなので、同僚であってもチーム外では何をやっていたかを具体的に理解している人は少なかったかなと思います。
先々のための布石を打つことが望まれる仕事で、上手くいってる = トラブらないのであまり周りに意識されない、ということだったのかもしれませんね。
何してるか周りがよく知らないというのも寂しくはありますが、それ以上に危ういのは自分が何のために働いているかを見失い、モチベーション低下に陥ったり、自分の将来のキャリアの可能性を閉じてしまうことです。
対策ですが、別のチームの人や IT 部門外の人ともなるべく話す機会を持つのが良いかな、と思います。そもそもその仕事はなぜ必要なのか？、自分がいないと周りの人や会社はどう困るのか、ということを定期的にでも考える習慣をつけておくキッカケになります。
IT インフラの環境もこの 10 年で劇的に変わりました。仮想化技術の発達でクラウドの利用が一般的になり、インフラの選択肢が格段に増えたんですね。自分が今やってる仕事の位置付けを見失うと、自分の価値も見失う恐れがあります。それを避けるためにも、周りの人と積極的にコミニュケーションし、自分の立ち位置を意識することをオススメします。
基盤を支える人材は貴重なので、仕事の意義をしっかりと表現できる人材になればさらに希少性が高まり、多くの企業に求められる存在になれる職種ですね。
社内情報システム担当
社内情報システムの担当はよく「情シス」とも呼ばれ、企業内の IT 環境を整備し、維持管理する役割を担います。具体的には、スタッフが使うパソコンやソフトウェアの設定、ネットワークの管理、セキュリティの対応など、会社全体の IT インフラをサポートします。
また情シスは、スタッフが安心して仕事を進められるように、IT 環境を常に最適な状態に保つことも求められます。パソコンにトラブルがあってスタッフの業務に支障が生じれば、スタッフが日常業務を続けられるよう対処します。一方で、パソコンも古くなる前に定期的に入れ替えも必要なので、そのような計画的な業務も担う立場です。
情シスになった経緯
インフラエンジニアとして入った会社がそこまで大きな規模の会社ではなく、インフラチーム = 情シスも兼任、という組織形態になっていました。
りもじい自身は情シスについて特別にやりたい、とかやりたくない、があったわけではないのですが、インフラエンジニアを選んだ結果、就職先の業務分担的に情シスもやることになった、という状況でした。
情シスの仕事内容
情シスとしては次のようなことに取り組んでいました。実は仕事の種類という点ではインフラエンジニアより幅広く、社内情報システムに関するあらゆることを手掛けてましたね。
- インフラエンジニアのお仕事全般
-
社内情報システムのサーバやネットワークなどについて、インフラエンジニアのところで紹介したお仕事全般を含みます。
インフラエンジニアとの違いは、お仕事の対象がお客様向けのシステムではなく、社内の情報システムであるという点ですね。
- スタッフの情報システム利用に関するサポート
-
スタッフから IT 関連で分からないことや困り事があれば状況をヒアリングして対応します。パソコンやネットワークにトラブルがある場合もあれば、スタッフが使い方をよく知らなかったり誤解していることもあります。そんな中で改善要望を受けたりする場合もあります。スタッフがより快適に業務が行えるよう、ドキュメントを整備したりシステムの改善計画を検討したりもします。
新しいシステムを導入したり既存のシステムに大きな変更を加える際には、スタッフが混乱なく利用できるよう、資料の提供や問い合わせの受付を通じてトレーニングやサポートをするといったことも担当します。
- 社内情報システムの運用
-
社内情報システムにトラブルがあれば業務に悪影響が出ますので、このシステムの監視やトラブルへの対応も担います。またハードウェアもソフトウェアも古くなるとサポートを受けられず実質的に利用が難しくなるため、定期的にアップデートするなどメンテナンス対応も実施します。
情シスの魅力とオススメの人
人とのコミュニケーションが好きだったり得意な人は向いている IT 職種です。
今の時代ですと会社の業務は情報システムなしには成り立たないことがほとんどでしょうから、そういう意味では会社そのものを支える存在ですね。とても頼られるので、そういった点でやりがいを感じられる人も多いのではないでしょうか。
トラブルを解決することで相手から直接感謝してもらう機会も多いです。
IT の仕事内容としては似ているインフラエンジニアは直接お客さんとやり取りすることは少ないため、その点では対象的ですね。
情シスの苦労とその対策： ひとり情シスを乗り切る
人に頼りにされることは嬉しいことですし、困ってる人を手助けすることは悪いことではないのですが、それによって時間が費やされることも事実です。
情シスはスタッフのサポート以外にも多くの仕事を抱えているため、それらをバランスよくこなすことも求められます。スタッフのサポートに時間を費やしていて元々予定していた仕事がぜんぜん進んでない…、といったことも起こりがちです。
人手があれば分担するなどの対応も可能ですが、情シスは比較的少ない人数で構成されることが少なくありません。
りもじい中小企業では情シス 1 名といったことも珍しくありません。これは人件費対効果という点では妥当な場合も多いのですが、当事者にとっては不安は大きいですよね。少人数でやりくりしている情シスを応援するための ひとり情シス協会 という一般社団法人もあったりします。
対策の一つは各業務に割り振る時間のバランスを取るための工夫を仕組み化する、という方法です。
やり方は色々ありますが、例えば情シスの問い合わせを電話や口頭ではなくオンラインシステム化する方法があります。この方法ではスタッフからの問い合わせをオンラインシステムで受け付け、一定時間溜めておいて一日のある時間に集中して取り組む事ができるようになります。もちろん現実には緊急の問い合わせはすぐに受けざるを得なかったりするので完璧なわけではありません。またスタッフから見るとオンラインシステムで問い合わせることで対応までの時間が長くなるように感じられるかもしれません。情シスの状況を理解してもらう必要もありますね。
もう一つの大切なのは社外の情シスともつながることでしょうか。例えば 情シス Slack では 4,000 名を超える現役情シスや情シスに興味のある方々がコミュニケーションする環境を提供しています。知見や情報を交換できるだけでなく、お悩みの共感などができる点でも心強いですね。
現代は情シスはほとんどの会社に存在する職種になったのではないでしょうか。 IT と人とをダイレクトに繋ぐ分、大変な面も多いですが様々な面で成長できますし、頼られ感謝される職種でもあります。ぜひ検討してみてください。
クラウドエンジニア
クラウドエンジニアとは企業がインターネットを通じて使うクラウドサービスについて設計や導入、管理を行う職種になります。インフラエンジニアの一種と認識されることも多いようです。
今や世の中にはかなりの数のクラウドサービスが登場していますが、おそらく多くの企業における「クラウドエンジニア」は実際のところ「AWS エンジニア」と同じ意味ではないかなと想像しています。次点で GCP や Azure に詳しい人、を指すでしょうか。
クラウドエンジニアになった経緯
インフラエンジニアと情シスを中心に仕事をする中で、必要に応じてクラウドコンピューティング技術について学んだり業務に活用したりしていました。インフラエンジニアのお仕事の一覧にも載せていますね。
クラウドエンジニアと名乗った事はないのですが、最近注目される職種の一つになっており、内容を見ると「あぁ、これも実際にはやってたなぁ」ということでこちらも加えました。
クラウドエンジニアの仕事内容
クラウドは様々なシーンで利用しており、りもじいが手掛けていた主な仕事がこちらになります。
- オンラインストレージの活用
-
遠隔地へのバックアップを目的としてオンラインストレージを利用するための設定や管理を行いました。
一定期間でのデータ削除や、保存時の暗号化設定などデータのバックアップポリシーも確認し、それに準拠する設定を行うなどしていました。
- 仮想マシンのセットアップ
-
物理サーバセットアップのクラウド版ですね。
仮想マシンも様々な種類を選択できます。物理サーバのセットアップと同じく、何を目的にしたものかを把握し、それに最適なものを選ぶ必要があります。
- ネットワークの管理
-
オンラインでできるようになった点は大きな進歩ですが、ネットワーク自体も設定が不要になったわけではありません。
ネットワーク空間上で仮想マシン同士をどのように繋ぐのが適切かを検討し、設定を行います。
一社のクラウドで完結しない場合も多いので、その際はクラウド外や他社クラウドと連携します。他システムと安全に通信するために通信路の暗号化設定を行うこともありますね。インフラエンジニアと同様にネットワークセキュリティについて理解しておく必要があります。
- プログラムによるセットアップの自動化
-
クラウドサービスの特徴の一つがプログラマブル、つまりプログラムによって操作や制御ができるという点です。
皆さんが Amazon で支払い方法や配達方法を選択する際はアプリやウェブブラウザから管理画面もしくは設定画面へ移動して選択項目を変更したりしますよね。 クラウドサービスでももちろんそのような形でも設定は可能なのですが、このやり方は人が都度その操作を行う必要があります。
プログラマブルな仕組みだとそのような設定だけでなく、仮想マシンを作るといったこともコンピュータによって自動的に行わせることが可能です。例えば、とある目的に適した仮想マシンやネットワークをセットアップするという作業を行わせるプログラムを一度作っておくとします。そうするとあとはボタン一つでゼロからインフラのセットアップができるようになります。個人的にはこれがクラウドを用いる最も強力なメリットではないかなと感じています。
クラウドエンジニアの魅力とオススメの人
新しい技術がどんどん出てくる領域なので、新しもの好きな人は向いているかなと思います。
また、めんどくさがりの人も向いているかもしれませんね。IT エンジニアの中には「面倒だな…」ということに感度が高い人が多く、面倒なことは自動化して手放したいと常々考えています。クラウドを提供する企業もそれをよく分かっていて、エンジニアの面倒をなくすための機能開発に力を注いでいます。これは怠け者を楽させる、ということではなく、エンジニアが面倒から開放される分だけ生産性が高まり、その分企業も新しいものを作れるようになるというメリットを生みます。
1 年前には面倒だけどしかたなくやっていたことを、今は全部コンピュータにお任せできる、ということを体感する機会は得やすい職種と言えますね。
クラウドエンジニアの苦労とその対策
魅力とも表裏一体ですが、クラウドエンジニアの大変なところは技術が新しくなるのでそのキャッチアップが必要な事ですね。これまでの常識がいつの間にか時代遅れになることも多いです。また組織の中で「クラウドエンジニア」という立ち位置であるならば、多くの場合はクラウドの最新情報を自ら仕入れ、必要に応じてその技術を活用するという役割を担うことも期待されます。
対策としては、できるだけ自分に合ったスタンスで情報を得る方法を見つけることです。公式ブログや Podcast があればそれを RSS フィードに入れてチェックしたり、X や YouTube で情報提供があればフォローしておいて目にするようにしておく、などの方法が常套手段でしょうか。
この他にもイベントに参加するのも一つの手です。公式な大規模イベントから IT 勉強会といった小さいものまで様々なイベントが開催されています。普段の業務から離れてインプットに集中できますし、周りの熱量を感じる事でモチベーションを高められる可能性も高いです。
また、りもじい個人の見解としては、クラウドエンジニアはクラウドに精通してその知識や技能で周りの人や企業の問題解決をする人であって、「クラウド以外は知らなくて良いエンジニア」ではありません。
例えばよくあるのが、物理サーバやネットワークで構成されたシステムをクラウド化したい、という要望です。大抵の場合は、元の仕組みをそのままクラウドに移行しようとすると手間と無駄が余計に増える傾向にあります。要望を出す側と一緒になって元のシステムが果たしてきた役割が何であるのか整理し、クラウドでそれを実現するための最適な方法を提案したり、実現したりすることが期待されています。
そのためには、クラウドに限らず様々な知識を得て、経験を積むことも大切です。移行の計画に限らず、クラウド以外のシステムについて見聞きする機会があれば、「なぜそのようなシステムが存在しているのか」、「クラウドに移行するならどうするのがベストなのだろう」といったことをイメージしてみましょう。クラウドエンジニアの幅を広げるチャンスになるはずです。
IT エンジニアを長く続けていた肌感としても、今後クラウドの需要は更に伸びると感じます。クラウドエンジニアの需要もそれに伴って高まるでしょう。多くのインプットが求められる立場ではありますが、それだけ自己成長を感じる機会が多い職種とも言えます。移り変わっていく技術を乗りこなすことを楽しく感じることができそうな方はぜひ検討してみてください。
運用エンジニア
運用エンジニアは IT システムやサービスの安定稼働を支える立場になります。システムの監視やトラブルの解決、定期的なメンテナンスが主な仕事になります。普段の運用の経験を元にした改善提案を行う役割を担う場合もあります。
運用エンジニアになった経緯
インフラエンジニアとして入った自社開発会社では IT エンジニアは開発と運用を一体的に行うスタイルであったため、実質的には運用エンジニアも兼任していました。
正直なところ、クラウドエンジニアと同様、自分自身が運用エンジニアであるという自覚はあまりなく、インフラエンジニアってそういうものかなと思っていました。ですが、改めて現状の IT キャリアの職種分類を見るに別で扱われているようだったため別項目に分けた次第です。
運用エンジニアの仕事内容
IT システムやサービスが健全に動作しているかをチェックする定型的な仕事がメインでした。もちろん可能なものは自動化するものの、人の判断が必要な部分を対応するというイメージですね。
- システムの監視とトラブルの対応
-
次のような問題が生じていないかを常時監視します。
- システムが正常に稼働しているか
- パフォーマンスに異常はないか
- セキュリティ侵害などの問題はないか
- 利用しているハードウェアやソフトウェアに脆弱性は発見されていないか
- バックアップは正常に取得されているか
- などなど
異常を発見した場合、それが既知で対策が明確な場合はそのように対処を進めます。一方でその対策方法が不明な場合はエスカレーション、つまり関係するチームへの対処を委ねたり判断を仰いだりします。
生じている事象が利用者に影響を及ぼしている場合にはユーザーサポートのチームへ連絡を行うこともありますね。
監視は手動で行わっていたわけではなく、監視システムにより数十台以上の数の機器について、数千項目の内容を常時チェックさせていて、そこで検出された異常に対処する、というのが実際の作業でしたね。
- システムの定期メンテナンス
-
ハードウェアもソフトウェアも古くなると使えなくなってきます。もちろん食べ物のように腐るわけではないのですが、機械であっても古くなればどこかしらが傷んで故障が増えてきます。壊れた箇所を交換することでまずは対処するのですが、メーカーもいつまでも古い機材の交換部品を抱えておくわけにはいきません。いずれはサーバなど機材本体ごとの交換が必要です。
ソフトウェアは壊れるわけじゃないだろうしいつまでも使えるんじゃない？ と思うかもしれませんがこちらもやはり入れ替えが必要です。身近なもので言えば、多くの皆さんが使っている iPhone に搭載されている iOS も定期的にソフトウェアアップデートが行われますよね。古い iOS をいつサポート終了するか Apple は明示していないようですが、新しい iOS にアップデートできなくなった iPhone をサポート対象外とすることで古い iOS のサポートから手を離すようにしているようです。ソフトウェアのメーカーも提供する以上は適切で安全に動作することを保証する義務があります。古いもののサポートは極力止めていくため、利用者もそれに合わせて入れ替える必要があります。
このような様々な入れ替えは数多くの機種を抱えるシステムでは頻繁に起こります。このような入れ替えの保守対応、つまりメンテナンスの主役になるのが運用エンジニアになります。ただし、このような入れ替えの機会にシステムを改善したいという場合もあり、その際はインフラエンジニアや、場合によってはプログラマーらとも協力して進めることもあります。
- 監視やメンテナンス手法の改善
-
監視システムを最もよく使い、メンテナンスを最も多く行うのが運用エンジニアになるため、それらの改善を手掛けることもあります。
監視システムであれば監視対象の増減や異常を検出するためのパラメータの調整などですね。これによってサービスをより適切に監視できたり、無駄な検出に依る労力を削減できたりします。
メンテナンスであればより安全で効率的に作業ができるよう手順を見直すなどの改善を行ったりします。
運用エンジニアの魅力とオススメの人
初めはルーチン作業、つまり繰り返しの作業を多くこなすことになるため、そのような作業を飽きずにコツコツできる人が向いていますね。
どのような作業をこなすべきなのか、事前に具体化されていることが多く、その点も IT キャリアを始めたての状況ではメリットになります。初めのうちは「習うより慣れろ」という部分も大きいと思います。慣れるべき何かが明確であるということはそれだけ慣れやすくなりますからね。
ある程度慣れてきて周りが見えてくると、システムの裏側の品質について理解を深めるのに良い環境になってきます。運用がスムーズにできるのであればシステムは品質が高い筋の良い造りをしていることになりますし、逆にトラブルが多いとどこかそもそもの造りに問題を抱えていることが分かってきます。
サービスやシステムを作る際は利用者から見える機能に目が行きがちです。もちろんそちらはそちらで大切なのですが、ビジネスとして提供するサービスなのであれば、利用者から受け取る報酬に比べてシステムの維持にかかる費用が低ければ低いほど、スタッフの報酬を増やしたり、サービスの開発や改善に充てる金額を大きくできます。トラブルが多いということはそれだけ人件費がかかることになるため、システム維持の費用が実質的に高くなるということです。これはビジネスにとって直接のマイナスになりますよね。
運用の経験はシステムの裏側の品質の良し悪しを見極める目を鍛えてくれます。運用エンジニアはそのような力を磨く上では最良の環境と言えるのではないでしょうか。
運用エンジニアの苦労とその対策
皆さんは SNS を使う際は時間も曜日も気にせず使えますよね。それはつまり、 SNS のサービスを支える側は 24 時間 365 日、常に安定に稼働するよう運用をしている、ということです。皆さんがイメージするようなメジャーな SNS を運営している企業は世界でも極一握りではあるのですが、そういったメジャーなものではなくとも IT サービスは「常に稼働してて当たり前」といった雰囲気があります。
りもじいわたしとしても、オンラインサービスなのに「利用可能な時間帯は朝○時から夜○時まで」とか書いてあると正直ちょっとガッカリしちゃいます。
もちろん常に利用できることは利用者にとっては嬉しいことですが、運用を担う側にとっては大変なことでもあります。予期しないトラブルで緊急での対応を迫られることもあります。また夜間の業務にあたることも少なくないかもしれません。りもじい自身も夜間メンテナンスは何度も経験しています。
この他にも、ルーチン作業が多いことは先ほどメリットにも挙げましたが、慣れてしまえば飽きてしまうことにもつながります。これはデメリットとも言えますね。
そして何より意識しておきたいこととしては、運用エンジニアの場合は目の前にあるお仕事が突然無くなる事がありうるということです。先ほど運用のトラブルがない方がビジネス的にメリットがあるとお伝えしました。つまり会社としてはトラブルを減らすように動こうとするわけですね。
例えば、あなたが運用エンジニアとして入社した会社が運用トラブルだらけで、大変ながらも頑張って運用仕事をこなしていて、ある程度その仕事にも慣れてきて周りにも感謝されるようになってきたとします。ある日チームのリーダーがニコニコと「明日からもうこの仕事はしなくて良くなったよ！よくこれまでがんばってくれたね！」と伝えられる状況を想像してもらうとよいでしょうか。
もちろんリーダーにも会社にも悪意はカケラもありません。むしろあなたのためにもと思ってやってくれた改善の対応です。しかしあなたとしては「え、またゼロからやり直し…？」と足元が崩れるような絶望的な感覚を味わうかもしれません。
この時にあなたが自分の状況を俯瞰できていて、今の仕事の先で何をやっていくかイメージできていれば、リーダーからのメッセージは「やった！本来やりたかった仕事ができるようになる！」と希望を感じることができるようになるでしょう。
りもじいこういう事は初めからリーダーが伝えておいてあげられるのがベストなんですけどね。
わたしのように様々な役割を兼任する立場は、大変さはありましたがこういう点ではメリットも大きかったと思います。運用仕事を減らすことがインフラエンジニアや情シスの立場での生産的な仕事を手掛ける時間を増やすことにつながりましたので。
運用エンジニアを始めた際は、最初は右も左もわからずまずは慣れるところからになると思います。しかしある程度慣れてきたらその仕事の意義を見つめ直し、目的に対して最適なのかどうか、自分は今の仕事の先で何を取り組むのかを意識してもらうことをオススメします。
ある意味では運用の全てをコンピュータにお任せできる世界が理想ですが、そのような理想郷は現実にはなかなか無いようです。やはりこの世界のかなりのサービスは運用エンジニアによって支えられています。IT キャリアの入口として有力な選択肢である一方、お伝えしたようなトラップもあります。運用エンジニア+αを意識してチャレンジを検討してみてくださいね。
IT 業界でりもじいがご一緒した職種
ここまではりもじいが実際に体験してきた職種をお伝えしました。ここからは参考まで、りもじいが一緒に仕事をした職種についてちょっとだけ個人的な印象をお伝えしますね。
プログラマー
プログラマーは細かく分類すると様々なものがあるのですが、りもじいはそちらの専門職ではなかったのでここではザックリとプログラマーという分類でお話します。
自社開発企業で一緒に働いており、サービスの機能を開発してくれていました。インフラと全く分離しているわけではなく、プログラムがどのようにコンピュータのリソースを使うのかが変わるため、適したインフラを提供できるよう連携していましたね。
プログラマーは「何でも作れる」ことを羨ましいなと感じていました。もちろん制約が無いわけではありません。ただ、インフラエンジニアはどちらかと言えば用意されたものをどう組み合わせるか、といったニュアンスが強かったため、それに比べるとプログラマーの自由度の高さは素晴らしいなぁと感じていました。
ただ、その自由度の高さは不具合やバグと呼ばれる想定外の動作の生み出しやすさにもつながります。プログラマー自身も品質に意識をもってプログラムを作るにせよ、ある程度の規模の開発になると品質チェックやデバッグを行うエンジニアとの連携は不可欠ですね。
品質管理エンジニア (テストエンジニア)
利用者にちゃんとしたサービスを届けるために品質のチェックを行うエンジニアですね。こちらも一緒に自社開発企業で働いていました。
悲しいことですが規模の大きい開発になると不具合やバグをゼロにすることはどんなすごいプログラマーでも不可能なようです。ですが利用者に対して「そういうもんなんで」と開き直ることは難しいですよね。皆さんが使っているウェブサービスの設定が勝手に変わってたとか、注文したのと違う商品が届いたとか、保存してたデータが消えてました、となると大きなトラブルになり、利用者の立場としては他のサービスへの乗り換えを考えちゃいますよね。
品質管理エンジニアやテストエンジニアと呼ばれる職種は、様々な使い方を試して利用者に届く前にそういった問題を解消するために日々努力しています。
論理的にはあらゆるパターンを網羅的にやれば良いんじゃないか？ と思われるかもしれませんが、それには膨大な労力が掛かることが多く、現実的ではないのですね。りもじいが一緒に仕事をしていた方は経験や直感からどこを重点的にチェックするかイメージできる方で、「なんでそのバグ見つけられるんだろ…？」みたいなものを発見されたりもしていました。
利用者から見えるサービスの観点と、裏側で動作するプログラムの仕組みを程よく理解しつつ、的確に検査を行っていく様子は高度な技術を持つ職人的なイメージでしたね。
プロジェクトマネージャー (PM)、システムエンジニア (SE)
研究所時代には IT 企業の担当者と仕事をする機会がありました。りもじいは大学を出てすぐの頃で、研究者なのか IT 技術者なのか立ち位置も半端なころですね。その担当者の方々が正確に PM や SE だったかは忘れてしまいましたが、概ねそのような役割を担っていた印象でした。IT 企業はいわゆる SIer や受託開発企業と呼ばれる業種になります。
お客さんにあたる研究者の方とはとても頻繁に打ち合わせを行っていました。結構無茶なことを言われることがありつつも、傍から見ていると「仲が良い」ようにも見えていましたね。「ちょっと相談があるんだけど」といったところから仕事に発展する事もあったようです。
こう書くと営業の方っぽい印象もありますが、実務を担ったり IT 企業側のメンバーはチームで動いていたこともあり、PM 相当の方が研究者との関係性も構築していた、というのがりもじいが見ていた現場だったのかもしれません。
りもじい自社開発企業でも取引先の方と仕事をする際、営業の方はつなぎで、実務に入ると別の方とメインでやり取りするということも多かったです。
お客さんから仕事を請け負う形でプロジェクトを進める立場の PM は、何よりお客さんとの関係性が第一なのだろうなと感じますね。お客さんから「あの人と話してもしょうがない」となってしまったらプロジェクトの成功は極めて難しくなります。「とりあえずあの人に相談しよう」と頼りたいと思われるようになっておくと認識の相違も早いうちに気づけますしね。
ただこれは単に人当たりがよいとか、イエスマンであれば良いとかいう話ではありません。出来もしないことを「はいやります。任せてください。」と言っても、その場では良いかもしれませんが後になって関係が破綻してしまいます。
何ができるのかできないのか、IT 技術者としての知識や経験も必要です。またチームの状況も把握してメンバーとの関係もうまく構築するマネジメントの力量も重要です。お客さんの期待には最大限応えつつ、会社の利益を最大化することも意識しなければなりません。
当時のわたしとしても色々頼りにした方々だったのですが、いま改めて思い出しても SIer さんって多面的な能力を持っていてすごいなと思いますね。
IT キャリアの種類を選ぶことの 2 つの意味
ここまでりもじいが経験したり、近くで見ていた IT の職種についてお伝えしました。
おそらくこれを読んでおられる方の多くは IT キャリアを検討されていて、どのように職種を選ぼうかを検討中かと思います。りもじいは職種を選ぶことは 2 つの意味を持つと思っていて、そちらについてお伝えします。
① 即戦力として何で活躍するかという意志
新しい職場を選ぶ際、それは自分がそのような立場で会社に対して価値貢献をするよ、を意思表示することになります。会社としてもその立場で価値を提供してもらえると思うからこそ、給料を払うことを決めるわけですよね。
既に実績を残している人の採用は、会社としても安心して即戦力として期待できますね。
② これからどのようなキャリアを拓くのかという意志
もう一つが、自分がこれからどのように成長したいかを示すという意味合いです。いわゆるキャリアチェンジと呼ばれるものは、従来の職種や業界を変えることを意味します。既に何かの経験がある場合でも、他の何かについては未経験の領域へ踏み込むことになります。
こちらは ① に比べて会社にいくらかのリスクが生じます。期待通りの成長が遂げられなければ提供される価値に見合わない給料を払っていかなければならなくなります。
会社によってはそのリスクを下げるため、初めは支払う給与を低めに抑え、成長に応じて給与を増やすことを仄めかすといったこともあるかもしれませんね。
両者のバランスを意識した職種の選択を
りもじいの場合、性格もあって転職の際にはかなり ① を強めで選ぶ傾向がありました。幸いにして色々と兼務する職場だったので自然と IT キャリアとしての幅を広げることができましたが、役割が縦割りの企業であれば自分の可能性を広げることが難しくなった可能性もあります。
IT キャリアに未経験で飛び込む際には ② が 100% になると思われるかもしれませんが、必ずしもそうではありません。経験のある業界内での IT 職を探したり、仕事の内容がイメージのつきやすい職種を選ぶことで ① 要素を高める事も可能です。
①と②、ゼロイチで考えてしまうとどちらに進んでも不安が大きいと思います。自分に合ったバランスで職場や職種を選ぶことで安心感を高めることができます。
年収で職種を選ぶ際の注意
職種について調べていると〇〇エンジニアの平均年収は〇〇万円、といった情報はよく目にしますよね。仕事をする第一の目的は生活のためのお金を得ることですから、IT キャリアを検討する人がそれを調べること、そしてそれに応える情報が提供されることは合理的と思います。
この記事ではその点について触れてきておらず、物足りない方もおられるかもしれませんね。
この記事に職種ごとの年収に関する情報がない理由は、りもじいのキャリア的にあまり参考になる情報がないためです。
複数の職種を兼務する仕事を長く続けてきたため、職種ごとに転職する、みたいな経験がないんですよね。「転職ごとに年収が〇〇万円にアップ！」みたいな経験があれば何かの参考になったと思うのですが。
ただ、IT キャリアを始めようとする人が職種をその平均年収の多寡で決めようとしているのであれば、りもじいとしては「ちょっと待った！」を伝えたいなと思っています。
IT エンジニアの年収に関してこちらの記事にまとめていますので、年収の実態が気になる方や給料の上げ方を知りたい方はチェックしてみて下さいね。
未来の自分の姿を想像して職種を選ぼう！
今回の記事ではりもじいが経験してきた職種を中心に、仕事の内容や魅力、苦労した点や克服の方法など、あくまで私見の範囲内ですがお話をさせてもらいました。
りもじい自身は IT エンジニアはこの時代においてとても魅力的なキャリアだと感じています。一方で IT エンジニアになりさえすれば誰しもがバラ色の人生を歩めるというものでもないと思っています。
人それぞれに個性があり、望む人生に至る IT キャリアも人それぞれになるのが自然です。仕事に面白さとやりがいを得ることは成長への近道になりますが、何に楽しさを感じるかは個性によりますよね。
IT 未経験な人が将来の自分の姿を明確にイメージすることは難しいでしょう。りもじいもぼんやりとしたイメージの中で始めました。しかし、比較的イメージしやすいものから選んだ方が安心して始めやすいのは確かです。
始めてみたら期待したものと全く違ったということもあるかもしれません。そんな時でも「職種選択を失敗したぁ…。」と捉えるのではなく、「すぐに気付けた自分ってステキ」とポジティブに捉えて次へのステップを進めてしまいましょう。
この記事を通じて、IT エンジニアの実態が少しでも実感でき、安心して IT キャリアへの歩みを進めてもらえれば幸いです！
りもじいそれでも色々と不安があるなぁ、という方はぜひこちらの記事を参考にしてくださいね。IT キャリアに感じる不安の原因を 7 つに分類してその対策をお伝えしています。
コメント