「インフラエンジニアはオワコン」と言われることがあります。
その背景には、AI、クラウド、自動化などによって、これまで人が行ってきたインフラ業務の一部が変化していることがあります。
実際に、定型的な設定や監視、情報収集などは、ツールやサービスによって進め方が変わっています。
ただし、仕事の一部が変化することと、インフラエンジニアという職種そのものが不要になることは、同じ段階の話ではありません。
「オワコン」という評価を判断するには、技術の変化が実際の作業、担当業務、役割にどうつながり、職種そのものを不要にするところまで至っているのかを確認する必要があります。
また、自分自身が「オワコンなのでは」と不安を感じている場合は、職種全体の話だけでは判断できません。
自分が何を任され、どこを判断し、どこまで責任を持っているのかを確認したうえで、その仕事のどこが変化の対象になるのかを照合する必要があります。
結論：インフラエンジニアがオワコンだと、技術の変化だけで判断することはできません。
AI・クラウド・自動化によって作業が変化していても、それだけで担当業務や役割、職種そのものが不要になるとは限らないためです。「オワコン」という評価を判断するには、技術の変化が作業・担当業務・役割にどう及び、職種消滅までつながっているのかを確認する必要があります。自分自身については、現在任されている仕事・判断・責任を基準に、何が変化の対象になるのかを切り分けます。
この記事でわかること
- なぜ「インフラエンジニアはオワコン」と言われるのか
- AI・クラウド・自動化によって何が変化しているのか
- 技術変化から職種消滅まで、どの段階を確認する必要があるのか
- 自分の担当業務のどこが変化の対象になるのか
- 「オワコン」という不安が何を対象としているのか
- 職種消滅という結論を確定するために、どこまで根拠が必要なのか
なぜ「インフラエンジニアはオワコン」と言われるのか
「オワコン」という評価が出てくる材料として、インフラを取り巻く技術や環境の変化があります。
特に大きいのが、AI、クラウド、自動化です。
AIによって作業の進め方が変わる
AIを使えば、情報の検索や整理、設定内容の作成、ログの分析などを支援できます。
これまで人が情報を集め、内容を整理していた作業の一部を、AIを使った方法に変えられる場面もあります。
そのため、インフラ業務の中には、従来と同じ方法で人が直接行う必要がなくなる作業が出てきます。
クラウドによって扱う対象が変わる
クラウドでは、物理サーバーやネットワーク機器を自社で用意して管理する形とは異なる方法で、インフラ環境を構築・運用できます。
その結果、インフラエンジニアが扱う対象や作業方法も変わります。
物理機器の設置や設定だけではなく、クラウド上の環境を構成・管理する仕事が増える場合もあります。
自動化によって定型作業が変わる
監視、設定、デプロイ、バックアップなど、一定の手順を繰り返す作業は自動化の対象になります。
これまで人が手順に沿って実行していた処理を、スクリプトやツールによって自動化できる場合があります。
すると、人が直接行う作業の量や方法が変わります。
ここで確認できるのは、インフラを取り巻く技術が変化し、それによって具体的な作業の進め方も変わっているということです。
では、その変化だけで「インフラエンジニアという職種が終わる」と判断できるのでしょうか。
「仕事が変わる」ことから「職種が終わる」と言えるのか
「オワコン」という評価を職種消滅までつなげるには、途中の変化を分けて確認する必要があります。
その経路は、
技術の変化
↓
作業の変化
↓
担当業務の変化
↓
役割の変化
↓
職種消滅
です。
技術の変化から作業が変わる
AIや自動化によって、設定、監視、情報収集などの具体的な作業方法が変わることがあります。
たとえば、これまで人が手順書を確認しながら実行していた設定を、自動化された仕組みで処理するようになれば、その作業の方法は変わります。
作業の変化から担当業務が変わる
作業の方法や量が変われば、その作業を担当していた人の業務構成にも影響します。
定型的な作業に使っていた時間が減れば、その分だけ別の業務を担当することがあります。
ここで確認するのは、個別作業ではなく、担当している仕事の構成がどう変わるかです。
担当業務の変化から役割が変わる
担当業務の構成が変われば、インフラエンジニアとして担う役割にも変化が生じます。
たとえば、手作業による設定の比重が下がり、構成の確認、障害原因の調査、変更内容の判断などが担当業務の中心になることがあります。
ここで確認するのは、職種の中で何を担っているのかという役割です。
職種消滅まで判断するには何が必要か
職種消滅という最終段階を判断するには、インフラに関する役割そのものが不要になり、その役割を担う職種としてインフラエンジニアを必要としなくなったことまで確認する必要があります。
「オワコン」という評価を職種消滅という意味で成立させるには、技術変化から職種そのものが不要になるところまで、論理がつながっている必要があります。
ここで、職種全体についての検証を終了します。
「オワコン」という不安を自分の仕事に置き換える
ここからは、対象をインフラエンジニアという職種全体から、自分が現在担当している仕事へ移します。
同じインフラエンジニアでも、実際に任されている業務は異なります。
そのため、自分の不安を確認するときは、職種名ではなく、現在の仕事を具体的にします。
自分は何を任されているのか
最初に確認するのは、日常的に担当している仕事です。
たとえば、
- 手順書に沿った設定
- 監視
- 一次対応
- 障害対応
- 原因調査
- 構築
- 構成検討
- 変更作業
- 関係者との調整
などがあります。
必要なのは、自分の仕事を評価することではありません。
実際に何を任されているのかを具体的に切り出すことです。
その仕事のどこを判断しているのか
次に、その仕事の中で自分が判断している部分を確認します。
同じ「障害対応」でも、決められた手順を実行する場合と、状況を見て対応方法を選択する場合では、担当している内容が異なります。
たとえば、
- 手順どおり実行する
- 状況によって対応を選択する
- 原因を切り分ける
- 変更可否を判断する
- 構成を検討する
- 対応方法を決定する
といった部分です。
ここでは、判断が多い仕事を評価する必要はありません。
確認するのは、自分の担当業務の中で、どこまで判断を担っているのかです。
どこまで責任を持っているのか
さらに、その仕事について自分がどこまで受け持っているのかを確認します。
たとえば、
- 作業を実行する
- 実行結果を確認する
- 異常時に対応する
- 影響を確認する
- 関係者へ説明する
- 対応結果について責任を持つ
などです。
ここでも仕事の優劣を判断するのではなく、担当範囲を確認することが目的です。
技術変化を自分の仕事に照合する
ここまで確認したら、AI・クラウド・自動化による変化を、自分の現在の仕事に当てはめます。
確認する順番は、
現在の仕事
↓
変化する可能性がある部分
↓
変化によって変わる作業・方法・判断・責任
↓
現在の仕事のどこが影響を受けるのか
です。
たとえば、手順に沿った定型作業が中心なら、その実行方法が自動化の影響を受ける可能性があります。
障害対応が中心なら、AIによってログや情報を分析する方法が変わる可能性があります。
構成検討や変更判断を担当しているなら、利用する情報や判断方法が変わる可能性があります。
確認したいのは、どの仕事が「良い仕事」なのかではありません。
現在の担当業務のどの部分が、どの変化の影響を受けるのかです。
| 現在の仕事 | 変化を見るポイント |
|---|---|
| 定型的な作業 | 自動化・効率化によって方法が変わるか |
| 手順に沿った作業 | 実行方法が変わるか |
| 判断を伴う仕事 | 判断材料・判断方法が変わるか |
| 責任を伴う仕事 | 責任範囲・担い方が変わるか |
この照合によって、「インフラエンジニアだから不安」という状態から、自分の仕事のどこが変化対象なのかまで具体化できます。
「オワコン」と判断する前に、どこまで確認できたかを分ける
ここでは新しい論証を行いません。
ここまで確認した内容を、何を確認した結果なのかによって4つに分けます。
A｜職種全体で、変化はどこまで及んでいるか
判定対象：職種全体の変化の到達地点
技術変化が、職種全体のどの段階まで及んでいるのかを確認します。
- 作業までの変化なのか
- 担当業務まで変化しているのか
- 役割まで変化しているのか
判定：
技術変化が確認できた段階を、作業・担当業務・役割に分けて確定する。
Aでは、読者本人の仕事内容を判定しません。
B｜自分の担当業務では、どこが変化対象なのか
判定対象：本人の担当業務への照合結果
現在任されている仕事について、
- 何を担当しているか
- どこを判断しているか
- どこまで責任を持っているか
- そのどの部分が技術変化の影響を受けるか
を照合します。
判定：
自分の担当業務のうち、作業・方法・判断・責任のどこが変化対象なのかを特定する。
Bでは、職種全体の変化がどこまで進むかを改めて判定しません。
C｜「オワコン」という言葉で、何を不安に感じているのか
判定対象：本人の不安対象
不安が、
- インフラエンジニアという職種そのもの
- 現在担当している仕事
- 現在の仕事内容が変化すること
のどこに向いているのかを確認します。
判定：
「オワコン」という評価の中で、自分が実際に心配している対象を特定する。
Cでは、キャリア上の優劣や転職の必要性は判断しません。
D｜職種消滅という結論を成立させる根拠はどこまでそろっているか
判定対象：職種消滅という結論の根拠充足度
ここで確認するのは、「インフラエンジニアという職種が不要になる」という結論を出すために、必要な根拠がどこまでそろっているかです。
確認する対象は、
- 技術が変化している
- それによって一部の作業が変化している
- 担当業務そのものが変化している
- 役割・判断・責任まで変化している
- それらの変化によって、インフラエンジニアという職種自体が不要になることまで確認できる
という関係です。
判定：
- 根拠がそろっている
- 技術変化から担当業務、役割・判断・責任の変化まで確認でき、さらにインフラエンジニアという職種自体が不要になることまで確認できる。
- 職種消滅までの根拠が確認できない
- 技術変化から担当業務、役割・判断・責任の変化までは確認できるが、それによってインフラエンジニアという職種自体が不要になるところまでは確認できない。
- 職種消滅まで判断する材料が不足している
- 技術変化や一部作業の自動化などは確認できても、担当業務・役割・判断・責任への影響まで十分に確認できず、職種消滅まで判断できない。
Dで判定するのは、「オワコンかどうか」という結論そのものではありません。
職種消滅という結論を成立させるための根拠が、どこまで確認できているのかを判定します。
そのため、作業の自動化が確認できた場合でも、それをそのまま職種消滅の結論には置き換えません。
「オワコン」という不安の次に確認すること
ここまでで、「オワコン」という評価を、
技術の変化 → 作業の変化 → 担当業務の変化 → 役割の変化 → 職種消滅
という段階に分けて確認しました。
自分自身については、
何を任されているか → どこを判断しているか → どこまで責任を持っているか → 何が変化対象なのか
を照合しています。
ここから先は、オワコン論そのものとは別の判断になります。
自動化によって運用業務や役割がどう変化するのかを確認する場合は、インフラエンジニアは将来なくなる？自動化される運用と変わる役割で確認します。
現在の担当業務を基準に将来について判断する場合は、インフラエンジニアは将来性ない？見るべきは「今、何を任されているか」で確認します。
自分が現在どのような仕事を任されているのかを整理する場合は、インフラエンジニア現在地診断｜年数ではなく「今任されている仕事」で分かるで確認します。
現在の仕事がオンプレ運用を中心としている場合に、クラウド化との関係を確認する場合は、インフラエンジニアはクラウドに行かないと詰む？オンプレ運用中心の状態と考え方で確認します。
まとめ
「インフラエンジニアはオワコン」という評価を判断するときは、AI・クラウド・自動化による技術変化だけで結論を出すのではなく、変化がどの段階まで及んでいるのかを確認する必要があります。
確認する経路は、
技術の変化 → 作業の変化 → 担当業務の変化 → 役割の変化 → 職種消滅
です。
職種消滅という結論を成立させるには、職種そのものが不要になるところまで論理がつながっていることを確認する必要があります。
自分自身については、
- 何を任されているか
- どこを判断しているか
- どこまで責任を持っているか
- その仕事のどこが変化対象なのか
を照合します。
その確認結果は、
A＝職種全体の変化の到達地点
B＝本人の担当業務への照合結果
C＝本人の不安対象
D＝職種消滅という結論の根拠充足度
として分けられます。
「インフラエンジニアだからオワコン」と一括して判断するのではなく、自分の仕事のどこが変化し、その変化をどの段階まで確認できているのかを切り分けることで、不安の対象も具体化できます。
