- AIがポジションを丸ごと消すことはありません。定型的な細かい作業を、1つずつ引き受けていきます。
- 判断する前に、ポジションを細かな作業に分けてください。システムに任せるべき部分と、人に残すべき部分がはっきり見えてきます。
- 価値が上がるのは、責任を負うこと、人間関係を築くこと、マニュアルにないケースで判断することが求められる仕事です。
1. 職種名を予想する前に、タスクを分析する
「営業事務」というポジション1つをとっても、実際には十数種類の細かな作業でできています。同じデータを繰り返し入力する作業もあれば、怒っている顧客に電話をかけてなだめる作業もあります。ポジション全体をまとめて「置き換えられる」「置き換えられない」と判断すると、どちらに決めても間違えます。
営業事務の仕事には、リード(見込み客)の受け付け、CRMへの入力、書類の準備、アポイントの調整、進捗の確認、顧客との連絡調整などが含まれます。大部分を自動化できるタスクもあれば、人間関係が欠かせないタスクもあります。ポジション全体を置き換えられるかどうかだけで評価すると、仕事を設計し直す機会を逃してしまいます。

タスクを、定型的な情報処理(Routine Information)、変化のある情報処理(Variable Information)、身体を使う作業(Physical)、対人関係(Relationship)、責任(Accountability)の5つに分けます。読む、写す、分類する、要約する、書類を作るといった作業は、AIが引き受ける場面が増えていくでしょう。影響に責任を負う、交渉する、現場に出向く、信頼を築くといった仕事には今後も人が必要ですが、その人たちもAIから受け取る情報が増えていきます。
2. 縮小する、または大きく形を変えそうな仕事
先に減っていく仕事には共通点があります。読む、写す、分類する、次へ渡す、という作業であることです。残るのは、マニュアルにない状況で判断が求められる仕事です。
データ関連の事務作業(データ入力、ファイル整理、書式のチェック、レポートの取りまとめなど)は、エージェントがシステム同士をつなぎ、さまざまな書類を扱えるようになるにつれて減っていきます。定型的なコンテンツ制作(商品説明文、キャプション、要約レポートなど)は、1本あたりにかかる人手が減ります。ただし、方向性を決めて事実を確認する人は引き続き必要です。
進捗の確認と調整、つまり誰がどこまで進んだかを聞いて回り、情報を次へ渡す仕事は、ワークフローに置き換えられていきます。一次サポートは、FAQへの回答から、感情が絡むケース、リスクのあるケース、例外的なケースへの対応に変わります。若手が担う分析業務のうち、データ集めやスライド作りが中心のものは数が減るかもしれません。その場合、新人には実際の仕事を通じて学ぶ新しい方法が必要になります。
縮小の度合いは業界によって異なります。データがデジタル化されていない仕事、ルールが複雑な仕事、規制のある仕事は、変化が遅いかもしれません。経営者は自社の業務プロセスのデータをもとに判断すべきで、ネットで見つけた職種リストで人を判断してはいけません。
3. 価値が上がる仕事と役割
システムに教えられる業務の専門家は、手順どおりに作業できても理由を説明できない人より価値が高くなります。組織は、知識をルール、事例、評価の仕組みに変えていく必要があるからです。業務プロセスの設計者は、ビジネス、テクノロジー、顧客体験をつないで、引き継ぎをなくしていきます。

開発チーム向け · 技術的な詳細
AI Quality and Riskの担当者は、テストセット、抜き取り検査、インシデント、バイアスを管理します。Customer Specialistは、AIでは解決できない状況を引き受け、判断する権限を持ちます。Product Experimenterは、AIを使ってアイデアを素早く形にして試しますが、どれを選ぶかは市場での裏づけをもとに決めます。
分析的に考える力、創造性、柔軟性、リーダーシップ、協働する力といった人間のスキルは、これからも大切です。下書きを作るコストが下がると、価値は、どの問題に取り組むかを選ぶこと、トレードオフを判断すること、結果に責任を持つことへ移るからです。
4. 一律に削減せず、Workforce Matrixで仕分ける
| グループ | タスクの特徴 | 方針 |
|---|---|---|
| Automate(自動化) | 繰り返しが多く、ルールが決まっていて、件数が多く、確認しやすい | 作業時間(Touch Time)を減らし、欠員は補充しない |
| Augment(人を支援) | 分析が必要だが、データで支えられる | AIの使い方を身につけ、1人あたりのアウトプットを増やす |
| Human-led(人が主導) | 人間関係、責任、例外対応 | 優秀な人材を引き留め、判断の権限を広げる |
| New Work(新しい仕事) | エージェント、データ、評価、ガバナンス | 新しい役割やスキルをつくる |
各部門の責任者に、すべての役割についてグループごとの時間数を書き出してもらいます。そのうえで、25%、50%、70%を自動化できた場合のシナリオを作り、処理能力(キャパシティ)と増やすべき役割を計算します。こうすると、縮小するポジションと、変化の妨げになりかねないスキルギャップの両方が見えてきます。
5. 2029年に働く人に求められるスキル
- Problem Framing:大きな目標を、システムが理解できるタスク、基準、制約に落とし込む
- Data Judgment:どの情報源が信頼できるかを見極め、欠けているデータに気づき、根拠以上の結論を出さない
- Process Thinking:仕事を最初から最後まで見渡し、ルール、AI、人の判断に切り分ける
- Evaluation:よい事例を作り、品質を確かめ、誤りを分類する
- Exception Handling:情報があいまいなときや影響が大きいときに判断する
- Customer Empathy:顧客の状況、信頼、書かれていないニーズを理解する
- AI Safety Literacy:機密データ、権限、プロンプトインジェクション、トレーサビリティについて理解している
プロンプトを書くことは基礎的なスキルにすぎず、プロンプトはツールが自分で書く場面も増えていきます。長く通用するのは、ビジネスを理解し、結果が「状況に合っていて、価値を生んでいるか」を判断する力です。

6. リスキリングは実際のワークフローと結びつける
1日だけの一般的なAI研修では、社員はAIを試してはみるものの、仕事のやり方は変わりません。実際のワークフローを1つ選び、チームに導入前と導入後の姿を設計させ、システムを試させ、KPIに責任を持たせます。受講者は利用を許可されたデータを使い、評価の仕組みを作り、ビジネス上の成果を発表します。こうして、学んだことが会社の資産になります。

開発チーム向け · 技術的な詳細
レベルを分けます。全員向けのAI Literacy、利用者向けのWorkflow Practitioner、構築する人向けのBuilder、リスクを管理する人向けのOwnerです。社内認定は受講時間ではなく、提出された成果物をもとに出します。実践コミュニティ(Community of Practice)をつくり、テンプレートやインシデントの事例を共有します。
7. シナリオ別に人員計画を立てる
開発チーム向け · 技術的な詳細
Base、Accelerated、Constrainedの3つの計画を作ります。それぞれに業務量、生産性の向上幅、自然減、採用凍結、配置転換、新しい役割を書き込みます。削減できた時間を、そのまま人員削減として数えてはいけません。その時間を合計するとFTEで何人分になり、会社がその価値をどう回収するのかまで確かめる必要があります。
定型業務のポジションには採用ゲートを設けます。増員を承認する前に、業務プロセスを見直し、自動化を検討したことを示してもらうのです。一方、Human-ledのポジションでは、人材の引き留めとAIを使うスキルの育成を急いでください。成果に大きな差を生むのは、この人たちだからです。
8. 経営者と人事部門のための12か月計画
- 第1四半期:主要なワークフローについて、業務の棚卸しを行い、Workforce Matrixを作ります。
- 第2四半期:2つの業務プロセスでAutomateとAugmentを試験導入し、実際の仕事をもとにした研修を組みます。
- 第3四半期:職務記述書、KPI、採用ゲート、キャリアパスを見直します。
- 第4四半期:実際の生産性の結果をもとに、2028〜2029年の人員シナリオを作ります。
まとめ:定型的な情報処理と調整の仕事は縮小し、業務上の判断、業務プロセスの設計、顧客からの信頼、AIガバナンスの価値は上がっていくでしょう。会社は人員の配置をポジション単位で考えるのをやめ、タスクとワークフローの単位で考え、実際の仕事を通じたリスキリングを進めるべきです。そうすれば、必要以上の採用も、将来のスキル不足のリスクも減らせます。
人員計画を、勘に頼らずデータで決められるものにする
どのポジションを増やし、減らし、役割を変えるべきかという答えは、実際の仕事を知っている人事部門と現場の責任者から出てくるものです。ソフトウェア会社が出せる答えではありません。そこで私たちは、社内のチームがすでに知っていることを整理するお手伝いから始めます。1つのポジションを細かなタスクに分け、タスクごとに、かかる時間、裏づけとなるデータ、求められる判断のレベル、間違えたときの影響の大きさを書き出します。このデータが会社全体で同じ形式にそろえば、部門同士を比べられるようになります。
人事部門と現場の責任者が、同じ情報を見て話せるシステム
その次に私たちが作るのは、たいてい業務の棚卸しとWorkforce Matrixのための社内向けWebアプリケーションで、各チームのリーダーが自分で入力できます。役割に応じた表示(Role-based View)によって、人事部門は全体像を、各リーダーは自分のチームだけを見られます。生産性が20%、40%、60%上がった場合に人数と役割がどうあるべきかを試算するシナリオ機能もつけます。納品は短いサイクルで行い、2〜3の部門から始めて組織全体へ広げます。タスクのデータがないまま増員を決めようとしているなら、最初のデータの枠組みづくりからお手伝いしますので、ご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語を知っておくと、人材データのシステムについて開発チームと的確に話せます。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Role-based View | 1つのシステムの中で、ユーザーの役割に応じて表示するデータを変えること | リーダーは自分のチームだけを、人事部門は会社全体を見られる | 誰がどのレベルのデータを見られますか?異動したとき、権限はどう変わりますか? |
| Data Model | どんなデータがあり、データ同士がどう関係しているかを表す構造 | 1つのポジションに複数のタスクがあり、タスクごとに時間とリスクがある | 後から新しい切り口を追加したくなったら、システムを作り直す必要がありますか? |
| Scenario Modeling | 複数の前提を置いて結果を試算し、選択肢を比べること | 20%、40%、60%を自動化できた場合の人員を試算する | 前提は実際のどのデータから来ていますか?誰がそれを確認しますか? |
| Capstone | 研修の修了時に受講者が提出する実務の成果物で、研修を終えたことより、実際に仕事ができるかを測るために使う | チームが自分たちのワークフローを設計し直し、導入前後の成果を測る | 学習の成果は、実際の仕事で測っていますか?それともテストで測っていますか? |
| Adoption Analytics | 人がシステムを実際にどれくらい、何のために使っているかを示すデータ | 業務の棚卸しを毎月更新しているリーダーが何人いるかを見る | 実際の利用状況を測っていますか?それとも開設されたアカウントの数を数えているだけですか? |
