この記事について
生成AI導入プロジェクトに関わる中で感じた違和感を言語化したものです。
統計データや成功事例集ではなく、「現場でモヤモヤしていること」を整理した思考メモとして読んでください。
共感できる部分があれば、あなたの現場の話も聞かせてください。
感じている違和感
AI導入プロジェクトを見ていて、こんな会話をよく聞きます：
「エンジニアがもう一人いれば進むのに」
「リソースが足りない」
「人を増やさないと無理」
でも本当にそうなのか？と思うことがあります。
増えた人は、具体的に何をするのか？
この問いに明確に答えられないまま、
「人手不足」という言葉で思考停止しているケースが多い気がしています。
見えてきたパターン：3つの「誰もやらない仕事」
複数のプロジェクトを観察する中で、
次の3つの仕事が誰の担当か曖昧なまま放置されているパターンに気づきました。
1. 業務とAIの境界線を引く仕事
よくある状況:
- ChatGPTやClaudeを触り始める
- 「これ便利だね」で盛り上がる
- でも「具体的にどの業務で使う？」が決まらない
- 気づけば数人が個人的にプロンプト工夫して終わり
誰もやっていない仕事:
- どの業務プロセスに組み込むかの設計
- AIと人間の責任分界点を決める
- 失敗時の対応フローを作る
「プロンプト書く人」は増えても、
「業務フロー全体を設計し直す人」が不在なまま進んでいる印象です。
2. レガシーシステムと向き合う仕事
よくある状況:
- 「新しいAIツール導入しよう」
- 「モダンなアーキテクチャで」
- でも既存システムとの接続は「後で考える」
- 結局、統合の複雑さで止まる
誰もやっていない仕事:
- 既存システムの影響範囲を地道に調べる
- ステークホルダーに泥臭く説明する
- 段階的な移行計画を現実的に作る
派手なAI活用の影で、
この地味な作業を引き受ける人がいないことが、
実はボトルネックになっている気がします。
3. 仕事の総量を調整する仕事
よくある状況:
- 「AI導入で効率化しよう」
- でも既存の仕事は減らない
- AI検証の時間も「業務の合間に」
- 結果、担当者が疲弊して続かない
誰もやっていない仕事:
- やらない仕事を明示的に決める
- 優先度を下げるタスクをリスト化する
- チームの負荷を定期的にモニタリングする
生成AI導入は、短期的には仕事を増やします。
（ツール検証、社内説明、セキュリティ確認...）
この「増えた仕事」に対して、
「減らす仕事」を決める役割が明確でないと、
現場は簡単にオーバーフローします。
なぜこれらは「誰もやらない」のか
個人的な仮説ですが：
評価されにくいから
- プロンプトエンジニアリング → 見える、新しい、評価されやすい
- レガシー調査 → 見えない、地味、評価されにくい
- 仕事を減らす → むしろ「やる気ない」と見られるリスク
結果として、誰も明示的に担当しないまま、
プロジェクトが進んでいく。
そして「人が足りない」と言われる。
問いかけ
もしかすると、足りないのは「人」ではなく、
「この仕事は誰がやるのか」という明示的な設計なのではないか。
次の質問に、あなたの現場は答えられますか？
Q1: 業務プロセスとAIの統合設計は誰が担当？
Q2: 既存システムの影響分析は誰が？
Q3: プロジェクトの「やらないことリスト」を決めるのは誰？
小さな実験：「役割マップ」を書いてみる
もし上記の質問に答えられないなら、
試しに次のような簡単なマップを作ってみるのはどうでしょう。
# プロジェクト：役割マップ（仮）
## 業務×AI設計
- 担当者候補: [名前 or ?]
- やること: 業務フロー見直し、責任範囲決定
- 週に必要な時間: ?時間
## レガシー対応
- 担当者候補: [名前 or ?]
- やること: 影響調査、移行計画
- 週に必要な時間: ?時間
## 負荷調整
- 担当者候補: [名前 or ?]
- やること: やらないこと決定、優先度調整
- 週に必要な時間: ?時間
「?」が多いほど、「誰もやらない仕事」が多いということです。
まとめ（というか現時点の考え）
- 生成AI導入で「人手不足」と感じる前に
- 「この仕事、誰がやるの？」を明確にする
- 特に「地味で評価されにくい仕事」ほど、担当が曖昧になりやすい
これは仮説段階の考えです。
あなたの現場ではどうですか？
似たようなパターン、または全く違う問題に直面していますか？
コメント欄で教えてください。
関連して考えていること:
- なぜ「やらない仕事を決める」役割は軽視されるのか
- AI時代の「アーキテクト」の定義は変わるべきか
- プロジェクトの「見えない仕事」をどう可視化するか
この辺りも、また別の記事で整理したいと思っています。