この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の実践編 #02 です。
- 導入編はこちらからどうぞ。
- 実践編 #01 「全員がAIを使える」チームは、なぜ崩壊するのか
- 実践編 #02 誰もやらなかった仕事をやる人が、次の時代のキーマンになる ← 今ここ
- 実践編 #03 「AIネイティブチーム」の現場で何が起きているか
- 実践編 #04 PGからプロンプトアーキテクトへ。キャリアを変えた人たちの話
- 実践編 #05 組織がAIを導入して半年後、生き残ったエンジニアの共通点
キーマンは「スキルが高い人」じゃなくなってきた
少し前まで、チームのキーマンといえば「一番コードを書ける人」でした。難しい実装を任せられる人、バグをすぐ直せる人、設計を任せられる人。
でも今、少し違う人がキーマンになりつつある現場が出てきています。
「コードを書く量」は多くないのに、なぜかその人がいないとプロジェクトが回らない——そういう人。
その人たちに共通しているのは、「誰もやりたがらなかった、でも実は重要だった仕事」を自然にやっていたということです。
「誰もやらなかった仕事」とは何か
具体的に見ていきます。
① AIアウトプットの一次レビュー担当
チームにAIが導入されると、コードやドキュメントの量が一気に増えます。「とりあえずAIに出させた」ものが積み上がっていく。
それを誰が最初に目を通すか——この役割、最初は「面倒くさい仕事」に見えます。でも実際にやってみると、ここには大きな価値があります。
AI特有のミスパターンがわかる。どのプロンプトだと品質が高いか・低いかの知見が溜まる。チームの「AIの使い方の水準」を底上げできる。気づいたら「この人がいないと品質が担保できない」存在になっていた、というケースが実際に起きています。
② AIとユーザーの「通訳者」
ユーザーやビジネスサイドの要望を、AIへのインプットに変換する人。
「なんとなくこうしてほしい」という言葉を「AIがうまく処理できる粒度の要件」に落とし込む。これ、地味に難しいんです。
要件定義の上流スキルと、AIへのプロンプト設計スキルの両方が必要。でもどちらもそこそこできれば成立する。「SEとしても中堅、AIも使える」くらいの人が意外にハマる役割です。
③ AIの使い方を「言語化・共有する人」
チーム内でAIを一番うまく使っている人の知見を、他のメンバーに広める役割。
「こういうプロンプトで出した方がいい」「このケースはAIに任せるより自分で書いた方が早い」という現場知識を、ドキュメントやランチタイムの共有会でチームに伝える人。
これ、誰も「自分の仕事だ」と思っていないから、大抵放置されています。でもやった人の評価は、じわじわ上がっていく。
④ AIが作ったシステムの「運用品質担当」
AIを使って作ったシステムは、従来の開発よりも「動き始めてからの挙動が予測しにくい」という特性があります。
特にLLMを組み込んだシステムは、同じ入力でも出力が変わる。本番環境でどう振る舞うかを継続的に監視し、問題を見つけて対処する——この役割は、AIが普及するほど需要が増します。
QAエンジニアとSREが融合したような役割で、まだ名前もついていないけど、確実に必要とされています。
なぜ「誰もやらなかった仕事」が価値を持つのか
これには理由があります。
AIが普及すると、「誰でもできる仕事」のコストはゼロに近づく。逆に言うと、「誰もやっていない仕事」には競争相手がいない。
希少性の原理です。
コードを書く、という仕事は今や「AIでもできる」ゾーンに入りつつある。でもAIのアウトプットをレビューする、AIとユーザーの間を橋渡しする、チームのAI活用を設計する——これらはまだ「人間しかできない」ゾーンにある。
しかも「誰もやっていない」から、少しやるだけで目立てる。
新しいキーマンへのなり方、3つのステップ
「でも自分には向いているかわからない」という方のために、具体的なステップを書きます。
STEP 1：チームの「困りごと」を観察する
今のチームで、「誰もやっていないけど、やった方がいいよね」という仕事はどこにありますか？
AIのアウトプットのレビューが属人化していないか。AIの使い方がメンバーによってバラバラで、品質にムラがないか。ユーザーとエンジニアの間でAI関連の翻訳ができていないか。
まずはそれを観察することから始めます。「誰かがやるべきだが誰もやっていない」ポイントが、あなたのポジションになり得る場所です。
STEP 2：小さく「引き受ける」
いきなり大きな役割を取りにいかなくていい。
「AIのレビュー観点をまとめたドキュメント、作ってみますね」「チームのプロンプト集、Notionに整理してみます」——こういう小さな「引き受け」で十分です。
最初は本業の片手間でいい。やってみると「この仕事、自分に向いてるかも」「逆に全然向いてなかった」という手応えが分かってきます。
STEP 3：言語化して、発信する
「自分がやっていること」を言語化して、チームや外に発信することで、その役割があなたのものになっていきます。
Qiitaでもいいし、社内の勉強会でもいい。「自分はこういう観点でAIアウトプットをレビューしている」「こういうプロンプトがうまくいった・うまくいかなかった」を発信し続けることで、「あの人に聞けばわかる」という認識が生まれる。
それがキーマンへの最短ルートです。
「誰もやらなかった仕事」は、怖くない
最初はそういう仕事って、損に見えることがあります。「なんで自分がやるの？」と思うこともある。
でも考えてみてください。コードを書くスピードで競うなら、相手はAIです。AIと速さで勝負するのは、なかなか分が悪い。
でも「チームの中でAIを一番うまく使う設計をする」という仕事なら、競争相手は今のところほとんどいない。
キーマンへの道は、「まだ誰も名前をつけていない仕事」の中にある気がしています。
まとめ
- AIの普及で「コードを書ける人がキーマン」という図式が変わりつつある
- 「誰もやらなかった仕事」——AIレビュー・通訳・知見共有・運用品質管理——に価値が生まれている
- 希少性の原理：「誰でもできる仕事」はコストゼロに近づき、「誰もやっていない仕事」に競争優位が生まれる
- なり方は「観察→小さく引き受ける→言語化して発信」の3ステップ
次回 #03 では、実際に「AIネイティブなチーム」の現場で何が起きているか、具体的な事例をもとに書きます。
「自分の現場でも似たような役割が生まれつつある」「こんな仕事が出てきた」という話、コメントで教えていただけると嬉しいです。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。