「AI で仕事がなくなる」「いや、AI を使えば生産性が上がるから大丈夫」。この 2 つの極論の間で、現場のエンジニアは止まりやすくなっています。脅威論を読んでも具体的に何をすればよいか分からず、楽観論を読んでも自分の業務にどう当てはめてよいか分からない。SES として客先で働いている方も、プロパーとして社内システムを担当している方も、運用保守やインフラの現場にいる方も、同じ位置で立ち止まっています。
この記事はその停止を解くための入口記事です。結論から先に書いておくと、危ないのは AI そのものではなく、AI で代替しやすい作業だけを続ける位置に固定されている立場です。SES だから危ない・プロパーだから安全という雇用形態の二分論は、AI 時代には有効な判別軸になりません。代わりに有効なのは、自分が判断責任を持つ位置にいるか、それとも入力と出力が固定された作業を処理する位置に留まっているか、という別の軸です。
本記事ではまず、企業の AI 導入で実際に何が起きているのかを国内外 6 社の事例で確認し、AI で置き換えやすい作業と置き換えにくい仕事の境界線を整理します。そのうえで SES・プロパー・社内 SE・業務システム・運用保守・インフラ・アプリ・PM 補佐・個人開発者の 9 職種ごとに「価値が下がる作業 / 価値が上がる仕事 / 危険な固定位置」を提示し、読者が自分の現在地を見立てられる構造を用意しました。
最後の節では、今日からできる 1 つだけの行動として、自分の業務を入力・処理・出力の 3 列で書き出す作業を案内します。本記事はシリーズの入口位置として位置の確認までを担い、各能力の詳細は後続記事に委ねます。読み終えたとき、自分が AI 時代のどのレイヤーに立っているかという地図と、まずどこに動けばよいかという最初の一手を持ち帰っていただける構成です。
AI 時代の危機感は「仕事がなくなる」ではない
本セクションでは、巷の脅威論や楽観論で読者が止まる地点を整理し、本記事が扱う論点 (危ないのは AI そのものではなく作業者ポジション固定であること) を読者の現在地に接続します。
エンジニア向けの AI 記事は、大きく 2 つのトーンに分かれて流通しています。1 つは「AI でエンジニアの仕事は消える」と煽る脅威論、もう 1 つは「AI を使えば誰でも生産性が上がる」と装う楽観論です。どちらの記事を読んでも、自分の業務に何が起きるのかは具体的になりません。脅威論は読者の不安を引き出すだけで行動指針を残さず、楽観論は「AI を使いましょう」というツール操作の話で終わり、業務の何を AI に渡すべきかは扱わないからです。
この記事の論点は、その 2 つの極論の間にあります。AI 時代の本当の危機は仕事の消失そのものではなく、AI が同じ作業を素早く処理できることで自分の作業に希少性がなくなる差別化喪失です。そして差別化喪失の本質は、AI で代替しやすい作業だけを続ける位置に固定されていることに集約されます。雇用形態が SES かプロパーかは、この危機の判別軸にはなりません。判断責任を持つ位置にいるかどうかが、AI 時代の市場価値を分けます。
本記事はシリーズの入口記事として、この 1 つの観点を読者の現在地に接続することに集中します。職種ごとの具体例・企業導入の実態・必要な能力の概観までを扱い、各能力の詳細手順や深掘りはシリーズ後続記事に委ねる構成です。
「仕事がなくなる」より怖い差別化喪失
AI 時代の本当の不安は仕事の消失そのものではなく、AI が同じ作業を素早く処理できることで自分の作業の希少性が消える点にあります。本セクションでは若手・初級層に出始めている影響と、速度差が差別化軸として崩れていく構造を整理します。
Stanford AI Index と Goldman Sachs が示す若手・初級層への影響
米国のソフトウェア開発者雇用統計と労働経済推計の数字を起点に、定型作業を担う層から影響が出始めている事実を確認します。
Stanford AI Index 2025 が示す米国データでは、22〜25 歳のソフトウェア開発者の雇用が 2022 年ピーク比でおよそ 20% 減少したと整理されています。Goldman Sachs の 2025 年推計では、米国で AI に起因するとみられる雇用減が月あたり 16,000 件規模に及び、20〜30 代の技術系で失業率が 3 ポイント程度押し上がっているとされています。これらは米国データであり、日本市場の状況にそのまま当てはめることはできませんが、定型作業から代替が始まるという傾向の強さを示す材料にはなります。
ここで重要なのは、影響が出始めているのが定型作業を中心に担う若手・初級層であるという点です。経験の浅い層が担当しがちな実装の繰り返し、テストの定型部分、ドキュメントの一次整備といった業務は、AI が一定の品質で生成できる範囲に直接重なります。日本市場で同じ規模感の数字が出ている根拠はまだ薄いものの、構造としては同じ方向に動きやすい領域です。
「AI で速くなる」だけでは差別化にならなくなる構造
コードを書く速度や定型処理の所要時間が AI で平準化される結果、市場価値の判定軸が成果物の量から文脈と判断に移っていきます。
これまで現場のエンジニアは、コードを書く速度・テストを通す速度・ドキュメントを整える速度といった作業速度で差別化していました。AI コーディング支援ツールが標準化すると、その速度差は底上げされ、誰が書いても一定以上の速度が出る状態に近づきます。すると、速度そのものは差別化軸として機能しなくなります。
差別化軸が成り立たなくなったとき、市場側が見るのは「何をどう作るか」を決めた人と、「決まったとおりに作る人」の差です。前者は文脈を理解し、判断を担い、責任を持ちます。後者は決められた入出力を処理する位置にいます。AI 時代に作業者ポジションのままでいることが危ないのは、この差が以前より大きくなるからです。仕事そのものは消えなくても、作業者ポジションだけで市場に出ていく場合の希少性が薄くなります。
企業の AI 導入で実際に何が起きているか
経営側ナラティブと現場実態を分けるため、本セクションでは国内外 6 社の動きを 4 つの方向に分類して提示します。読者は自社・自プロジェクトに最も近い事例を起点に、自分の業務への影響を見立てられます。
Klarna — 量は代替できても複雑例外は人間に戻った事例
Klarna の AI カスタマーサービス導入と人間再雇用の経緯から、量の代替は可能でも複雑例外は人間が必要という限界を読み取ります。
スウェーデンの金融サービス企業 Klarna は、AI 顧客対応の導入で月 230 万件・人間 700 人相当の対応を処理したと公表しました。一方で品質低下を理由に、その後人間スタッフの再雇用に動いたことが報じられています。再雇用の規模や対象業務の詳細は公表されていないため、ここで読み取れるのは「量の代替は可能でも、複雑な例外対応は人間が必要だった」という定性的な限界です。AI に渡しやすいのは入力と出力が固定された一次対応の領域で、判断と例外を含む複雑案件は人間に戻った、という構造として理解しておけば十分です。
Amazon・IBM — 管理層・バックオフィスから削減が始まる
Amazon コーポレート 14,000 人削減と IBM HR 200 人 AI 代替の経営側発言から、最初の削減対象が現場ではなく管理層・調整職に集中する傾向を整理します。
Amazon は CEO の Andy Jassy 氏が「AI で人数が減る」と発言し、コーポレート部門で 14,000 人規模の削減を発表しました。IBM は CEO 発言ベースで HR 部門 200 人分を AI チャットボットで代替したと公にしています。これらは経営側ナラティブで、解雇規模の細かい数字や対象業務の詳細は確認できないものの、削減の起点が現場の実装担当ではなくコーポレート・バックオフィス・管理層であるという方向性は一致しています。
調整・報告・定型対応を担う管理層・バックオフィスは、入力と出力がフォーマット化された業務が多く、AI に渡しやすい領域です。「現場のエンジニアはまだ大丈夫」と読み解くのではなく、最初に削減が始まるのは判断責任を持たない調整職・報告職であるという構造として読むほうが正確です。
Duolingo — 業務委託・外注から先に削減される構造
正社員解雇は否定しつつ業務委託契約を削減する Duolingo の動きから、解雇ではなく契約終了から AI 化が進む構造を確認します。
語学学習アプリの Duolingo は、正社員の解雇は否定しつつ、業務委託・外注契約を削減し、AI で代替できないときに限って業務委託を採用する方針を示しています。これは「解雇」という形を取らず、契約終了という形で AI 化が進む構造です。正社員ではない働き方 (業務委託・外注・請負・SES の一部) で、定型作業を切り出されて受けている層は、解雇統計の外側で先に契約打ち切りに動かれる可能性が高い領域に入ります。
日本の SES 市場や請負契約に直接当てはめる根拠はまだ薄いものの、構造としては同じ方向に動きやすい領域です。雇用形態が安全性を保証しないのは、こうした契約打ち切り経路でも同じことが言えます。
SoftBank・三菱 UFJ — 日本企業の「使う側に回す」動き
SoftBank の 2 万人 AI エージェント 250 万作成と三菱 UFJ の文書 AI 活用 (2023 年試算値) から、日本企業も方向としては全員を使う側に回す方針に傾いている点を整理します。
SoftBank は社員 2 万人を対象に 2.5 ヶ月で 250 万件の AI エージェントを作成する取り組みを進めたと公にしています。9 割が「業務理解が深まった」と回答したとされ、社員を「使う側」「作る側」に位置づける方針が読み取れます。三菱 UFJ 銀行は、行員 4 万人が ChatGPT Enterprise を利用し、月 22 万時間削減という試算を公表しました。ただしこの「月 22 万時間削減」は 2023 年発表の試算値であり、最新の実績値ではない点に注意が必要です。
日本企業も方向としては全員を AI を使う側に回す方針に傾いています。「日本だから AI 化が遅い」という前提で構えると、現場の業務再設計に乗り遅れやすくなります。むしろ「全員が使う側に回る」設計が進んだとき、AI を使わせるだけで終わるか、使う側として業務を設計し直す側に回るかが、社内での位置づけを分けることになります。
AI で置き換えやすい作業の共通点は「入力と出力が固定されている」
AI に任せやすい作業の特徴を 1 つの軸に集約し、読者が自分の業務をふるい分けるための共通言語を提供します。本セクションでは作業側の特徴と、その代表例を整理します。
入出力が固定された業務はそのまま AI に渡せる
議事録要約・メール分類・テスト雛形・ボイラープレートなど、入力と出力のフォーマットが決まっている作業は AI 移行の最有力候補になります。
入出力が固定されているとは、「何を受け取り、何を返すか」がフォーマットレベルで決まっており、判断や例外処理がほとんど混入しない状態を指します。代表例として次のような作業があります。
- 定型レポート・議事録要約
- 一次問い合わせ・メール分類
- ボイラープレートのコード生成
- テスト雛形の生成
- ドキュメント要約・ナレッジ検索
- 運用手順書のたたき台
- 調査結果の整理 (項目立てが決まっている場合)
これらは「同じ入力に対して同じ出力フォーマットで返す」という性質を持っているため、AI 移行の最有力候補です。現場で時間を取られている作業のうち、ここに該当するものほど、AI に渡したときの効果が出やすい領域になります。
「定型」と「機械的」は別物として捉える
一見定型に見えても判断や例外処理が混ざる業務は AI が誤りを生み続ける領域になるため、入出力が本当に固定かを確認する手順が必要です。
実務でよくある誤りは、「毎日やっている = 定型業務 = AI に渡せる」と判定してしまう読み方です。毎日やっている業務でも、その中に「顧客ごとの例外」「過去の経緯を踏まえた判断」「他部署との調整結果」が混ざっていると、入力が同じでも出力が変わります。こうした業務に AI を当てると、表面上はそれらしい出力が返ってきますが、判断部分でずれた結果が混入し続けます。
定型と機械的は別物です。機械的に処理できる業務 (入力 → 出力が同じ規則で写像できる業務) のみが AI 移行候補で、定型に見えても判断が混ざる業務は、判断部分を分離するか人間が判断ステップを残す設計が必要です。後者を見落としたまま AI に丸投げすると、誤った出力に対する責任の取り方を設計できません。
AI で置き換えにくい仕事の共通点は「文脈・判断・責任が必要」
一方、AI に渡しにくい仕事は文脈・判断・責任のいずれかを必須とします。本セクションでは置き換えにくい仕事の共通点と、その代表的な業務を整理します。
仕様整理・業務整理は AI に任せきれない
業務全体の入出力を定義し、責任分界を決め、例外を判断する作業は、社内固有の文脈と関係者の利害が絡むため AI 単独では完結しません。
仕様整理・業務整理は、AI に渡せる粒度の作業を生み出す前段の仕事です。具体的には、業務全体の入出力を定義する、関係者間の責任分界を決める、例外パターンを洗い出して判断ルールを設計する、といった内容を含みます。これらは社内固有の文脈と関係者の利害が絡むため、AI に対して情報を整理して渡しても、最終的な判断と合意形成は人間に残ります。
仕様整理ができる人材の市場価値が上がるという方向性は妥当ですが、日本市場での単価上昇の一次データは現時点で確認できていません。方向性として妥当であることと、定量的な裏付けがあることは別々に扱う必要があります。
本番作業判断・例外対応は人間にしか取れない責任を含む
トラブル時の本番作業可否や顧客への説明判断は、組織として誰が責任を取るかが問われる領域で、AI の出力をそのまま採用する設計にはなりません。
本番環境への作業可否、トラブル時の影響範囲判断、顧客や関係部署への説明判断は、組織として誰が責任を取るかという論点を含みます。AI が出力する候補は参考情報として有効ですが、最終判断者として AI を立てる設計を取る組織は基本的にありません。AI 出力を採用する場合でも、人間が「採用する」という判断を行い、その結果に対する責任を負う構造になります。
この性質は、見積前提整理・利害調整・顧客折衝といった上流工程にも同じく当てはまります。判断と責任が紐づく業務は、AI 時代に価値が下がるどころか、AI を業務に組み込むほどむしろ重要性が上がる領域です。
SES もプロパーも安全ではない構造的理由
雇用形態で安全性を判定する議論を一度脇に置き、本セクションでは判断責任ポジションにいるかという別の軸で見ると SES・プロパー両方に共通の脆弱性が見えてくることを整理します。
雇用形態軸ではなく「判断責任ポジション」軸で考える
SES だから危ない・プロパーだから安全という二分論を、判断責任を持つ位置にいるかという 1 軸に置き換えると、業界・契約形態を問わない見方ができます。
「SES は AI で真っ先に切られる」「プロパーなら社内に守られている」という議論は、表層的にはもっともらしく聞こえますが、AI 時代の判別軸としては有効に働きません。SES でも要件整理に踏み込んで判断側に回っている方は十分に残りますし、プロパー社員でも社内調整・定型報告・問い合わせ対応・定例議事録だけを担当している場合は作業者ポジションに固定されています。Amazon コーポレート 14,000 人削減や IBM の HR 部門 AI 代替は、「社内にいるだけでは安全ではない」ことを示す材料になります。
雇用形態という表層を 1 段抜いて、「業務全体を判断する位置に立っているか、入出力が固定された作業を処理しているか」という 1 軸に置き換える。これが本記事の中核軸です。SES・プロパー・社内 SE・業務委託・個人開発者のいずれであっても、この 1 軸の上では同じ位置に立つことがあり得ます。
指示待ち位置の脆弱性は雇用形態に依存しない
ション固定の状態にあります。
SES の現場で「客先のルールで AI 利用が制限されている」「指示書通りに動くのが契約上の前提」という制約はあります。これは事実です。しかし同じことが、プロパー社員でも社内のルーティン報告・定型問い合わせ・定例議事録に閉じている場合に起きます。外側から見れば、両者は同じ作業者ポジション固定の状態にあります。
雇用形態を変えれば判断側に回れる、という単純な処方箋にはなりません。SES のままでも社内文書を読み込んで仕様の問題を早期発見する、プロパーのままでも社内変革推進の側に回る、というように、現在の契約形態を維持したまま位置を選び直す動き方があります。位置の選び直しは、雇用形態の変更ではなく業務の選び方・関わり方の変更で進められます。
9 職種別影響マトリクス — 自分の位置を確認する
抽象論で終わらせないため、SES・プロパー・社内 SE・業務システム・運用保守・インフラ・アプリ・PM 補佐・個人開発者の 9 職種ごとに「価値が下がる作業 / 価値が上がる仕事 / 危険な固定位置」を提示します。読者は自職種の行を起点に他列を読むことで自分の位置を見立てられます。
職種別マトリクスの読み方
自分の職種行を起点に、現在業務がどの列に偏っているか、隣の列に動く余地があるかという順で読むと、行動の足がかりが見つかります。
下の表は 9 職種それぞれについて、AI 時代に価値が下がる作業・価値が上がる仕事・危険な固定位置を 1 行で並べたものです。読み方は次の順を推奨します。まず自分の職種行を縦に読み、現在業務が 3 列のどこに偏っているかを確認します。次に隣の列 (「価値が上がる仕事」列) に書かれた仕事のうち、自分が 0.5 歩でも踏み込める領域があるかを探します。最後に「危険な固定位置」列で、自分が無自覚に固定されていないかを確認します。
| 職種 | AI で価値が下がる作業 | AI で価値が上がる仕事 | 危険な固定位置 |
|---|---|---|---|
| SES エンジニア | 指示書通りの実装・定型テスト・手順書通りの作業 | 要件整理関与・自動化設計・仕様問題の早期発見 | 指示待ち・作業者固定・判断を持たない |
| プロパー社員 | 社内報告書・定例議事録・定型問い合わせ | 社内変革推進・AI 導入の業務設計・利害調整 | 社内調整・ルーティン報告のみ |
| 社内 SE・情シス | 定型問い合わせ・ハードウェア管理 | AI 導入支援・社内システム AI 連携・ガバナンス整備 | ヘルプデスク的業務に完全固定 |
| 業務システム担当 | 既存仕様書転記・定型データ移行・手作業バッチ確認 | 業務フロー設計・AI との業務統合設計 | 言われた通りに動かすオペレーター位置 |
| 運用保守担当 | 定型監視・手順書通りの一次対応・定期報告集計 | アラート設計の見直し・障害対応判断フロー整備 | 手順書を実行するだけの位置 |
| インフラエンジニア | 手作業のサーバー構築・定型設定変更 | IaC 設計・AI 活用のインフラ最適化 | 手作業の構築・変更のみ |
| アプリケーションエンジニア | ボイラープレート・定型 CRUD・テスト雛形 | AI 補助前提のアーキ設計・AI 出力レビュー | コードを書く速度だけで価値を出す |
| PM 補佐・進捗管理 | 定例報告・ガントチャート更新・課題管理表整理 | 利害調整・スコープ変更判断・リスク管理設計 | 管理作業の実行者の位置 |
| 個人開発者 | 定型コード・LP 作成・コンテンツ制作の繰り返し | 高速プロトタイプ・業務自動化受注・仕様整理支援 | ツール制作の単価競争 |
SES・社内 SE・運用保守は構造的に判断機会が限られる前提を踏まえる
SES の客先制限、社内 SE のヘルプデスク固定、運用保守の手順書消化などは判断機会が構造的に少ないため、別ルートで判断側経験を積む必要があります。
SES エンジニアは契約上、客先の指示書通りに動くことが前提になりやすく、社内変革を直接担う機会は限定されます。社内 SE はヘルプデスクや問い合わせ対応に時間を取られ、AI 導入の設計に踏み込む余裕が出にくい現場が多くあります。運用保守は手順書通りの作業を消化することが評価軸になりやすく、判断ステップを増やすこと自体が業務外と扱われる場面があります。
これらの職種では、現在の業務時間内だけで判断側経験を積もうとするとボトルネックに当たります。現実的な動き方は、業務外の時間で自分の業務を入出力単位で書き出してみる、社内勉強会や副業・個人開発で仕様整理の場数を踏む、社内提案として「自動化対象の選定書」を作って提出する、といった別ルートの確保です。構造的な制約を前提にしたうえで、その外側に判断側経験の足場を作る発想が必要になります。
「使う側に回る」とは何か — 5 つの能力の概観
「使う側に回る」をツール操作の習得と誤読すると行動が空回りします。本セクションでは判断責任ポジションに必要な 5 つの能力を概観として提示し、各能力の詳細はシリーズ後続記事に委ねます。
5 能力の段階構造 — 業務分解／仕様整理／自動化対象選定／AI 出力検証／判断責任設計
業務を入出力単位で分解する力を起点に、仕様整理・自動化対象選定・AI 出力検証・判断責任設計の段階を踏むことで、ツール操作とは別軸の使う側スキルが組み上がります。
判断責任ポジションに必要な能力は次の 5 つに整理できます。これらはツール操作とは別軸で、段階構造を持って積み上がります。
- 業務分解力 — 自分が担当している業務を、入力・処理・出力の単位に分解する力
- 仕様整理 — 業務全体の入出力を定義し、責任分界と例外パターンを言語化する力
- 自動化対象選定 — 分解された業務のうち、どれを AI に渡すかを費用対効果とリスクで判断する力
- AI 出力検証 — AI の出力が文脈と判断基準に照らして正しいかを評価し、誤りを検出する力
- 判断責任設計 — AI が判断してよい範囲と人間が確認すべき範囲の境界を設計する力
業務分解力 (1) が起点になります。業務を入出力単位で分解できなければ、何を AI に渡すかの議論にも入れません。仕様整理 (2) はその分解を社内文脈に接続する作業で、自動化対象選定 (3) は分解された業務のうち効果が出やすい領域を選び抜く作業です。AI 出力検証 (4) は LLM が自信を持って誤回答を出す前提に立った検証設計で、判断責任設計 (5) は AI 出力をどこまで採用してよいかという責任分界の設計です。
ツール操作の習得は (1) 〜 (5) のいずれにも属しません。「ChatGPT を使えるようになる」「Claude のプロンプトに慣れる」だけでは、使う側に回ったことにはなりません。AI を使う側に回るとは、これら 5 能力で AI の前後を設計できる位置に立つことを指します。
各能力の詳細はシリーズ後続記事で扱う
本記事は入口位置として 5 能力の輪郭だけを示し、各能力の具体的な手順・落とし穴・受注事例はシリーズ後続記事で個別に深掘りしていきます。
本記事はシリーズの入口位置にあるため、ここでは 5 能力の輪郭を提示するに留めます。各能力の具体的な手順・現場で発生する落とし穴・社内導入時の進め方・受注として外部に提供する場合の事例については、シリーズ後続記事で個別に深掘りします。本記事を読み終えた段階では、自分の現在地が 5 能力のどこから着手すべきかの当たりを付ける、という使い方を想定しています。
まず自分の業務を入出力単位で書き出す
抽象論で終わらせないため、本セクションでは読者が今日からできる行動を 1 つに絞って提示します。最初の入口は自分の業務を入出力の単位で書き出す作業です。
入力・処理・出力の 3 列で 1 業務を書き出す
自分の業務を 1 件選び、入力 (何を受け取るか)・処理 (どう加工・判断するか)・出力 (何を渡すか) の 3 列で書き出すだけで、AI に渡せる粒度が見えてきます。
最初の一手は、5 能力のうち業務分解力 (1) に該当する作業です。今日担当している業務のうち、毎日または毎週繰り返している業務を 1 件選んでください。それを次の 3 列で書き出します。
- 入力 — 何を、誰から、どのフォーマットで受け取っているか
- 処理 — どう加工し、どこで判断しているか (判断ステップは別行で書き出す)
- 出力 — 何を、誰に、どのフォーマットで渡しているか
このとき、処理列の中で「判断」と書ける箇所が出てきたら、それは AI に丸投げできない領域です。判断列が少なく、入力列と出力列のフォーマットが固定されている業務ほど、AI 移行の有力候補になります。逆に、判断列が多い業務は判断責任ポジションの仕事になり、AI 出力検証や責任設計の対象として残します。
なお、AI を業務に組み込み始めるときに「ChatGPT 月額・API・ローカル LLM のどれを使えばよいか」という選択でも詰まりやすい領域があります。3 種類の使い分けの整理は別記事に切り出してあるので、業務の入出力単位の書き出しと並行して必要に応じて参照してください (ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類ある)。
書き出せない業務は「整理側に回る」入口になる
入出力を言語化できない業務はそのままでは AI に渡せませんが、その言語化できなさ自体が業務整理・仕様整理という判断側の仕事の入口になります。
3 列で書き出そうとして、入力や出力が言語化できない業務に当たることがあります。「過去の経緯を踏まえて判断している」「関係者の合意で毎回内容が変わる」「例外対応が業務の中身そのもの」といったケースです。このとき、その業務をそのまま AI に渡すことはできません。一方で、その言語化できない領域こそ、仕様整理・業務整理という判断側の仕事の入口です。
「書き出せない」は失敗ではなく、判断責任ポジションの仕事が眠っているサインです。入出力に分解できない業務を抱えているなら、それは整理する側に回る余地が残っているということでもあります。書き出した結果と書き出せなかった結果の両方が、自分の現在地を可視化する材料になります。
まとめ
本記事の論点を 1 つに圧縮すると、危ないのは AI 自体ではなく作業者ポジション固定です。読了後の最初の一手は、自分が作業者ポジションに固定されていないかを職種別マトリクスで確認することです。
ここまでで扱った内容を 1 つに圧縮すると、「危ないのは AI そのものではなく、AI で代替しやすい作業だけを続ける位置に固定されていること」になります。SES かプロパーかという雇用形態の二分論は AI 時代の判別軸として有効に働かず、有効なのは判断責任を持つ位置にいるかという 1 軸です。9 職種別マトリクスは、その 1 軸を自分の職種に落とし込むための補助線です。
読了後の最初の一手は、9 職種別マトリクスで自分の行を確認し、「価値が下がる作業」列に偏っていないかをチェックすることです。次に、「行動の入口」で示した 3 列の書き出しを、繰り返し業務 1 件に対して試してみてください。書き出せた業務は AI 移行候補になり、書き出せなかった業務は判断責任ポジションの仕事として手元に残ります。この 2 種類の山が見えれば、5 能力のどこから着手するかの当たりが付きます。
業務分解・自動化対象選定の進め方が自社の業務に当てはめにくいと感じた場合は、Beエンジニアのお問い合わせフォームより気軽にご相談ください。シリーズ入口記事の段階では受注を強く案内する位置ではないため、まずは自分の業務を入出力単位で書き出すところから始めていただければ十分です。
