こんにちは！代表取締役 兼 AIサービス開発室の鈴木生雄です。

このブログの過去の投稿で以下のように書いて以来、AI時代の人材育成方法についてずっと考えていました。自分なりの考えがまとまってきたので、今回はAI時代の開発・人材育成方法というテーマの記事をお届けしたいと思います。

近いうちに、エージェントネイティブな人材の定義やスキルセット、育成方法について、深く考えてみたいと思います。
名古屋ではたらく社長のITポッドキャスト（2026年2月19日）

AI時代に活躍できる人材とは

まずは「AI時代に活躍できる人材」からスタートしたいと思います。

これについては私は、LayerXのCTO松本さんの言葉を借りて、エージェントネイティブ、すなわち、「AIを道具として使いこなしつつ、価値を創る判断を下せる人材」だと考えています。

私は、新卒やジュニアの採用を継続しつつ、彼らをエージェントネイティブな人材として育成していくことが、これからの組織にとって不可欠だと考えています。ここで言うエージェントネイティブとは、AIエージェントを道具として自然に使いこなしながら、その上で設計判断やプロダクトの方向性を自ら考えられる人材のことです。
AIエージェント時代の人材戦略 — 採用の二極化と”意図的な育成”の必要性 – Matsumoto Yuki note

では、AIを道具として使いこなしつつ価値を創る判断を下せる人材とは、どういう知識・技能を持った人でしょうか。シンプルに「AIを使いこなす能力 × 価値を創る判断を下す能力」と因数分解して考えてみます。

AIを使いこなす能力

まず、「AIを使いこなす能力」は以下をおさえた上で、実践を通じて工夫・改善を継続できることだと思います。

• AIの基本的な動作原理
• AI産業のプレイヤー（チップ／インフラ／データ／アプリ／サービス）の動向
• 他ユーザーの活用事例

なお、チームや会社といった組織レベルで業務フローにAIを取り入れていくためにはまた別の要素が必要になると思います。あくまでここでは個人レベルでの「AIを使いこなす能力」を構成する知識・技能を考えています。

価値を創る判断を下す能力

次に「価値を創る判断を下す能力」ですが、これを構成する知識・技能は、対象にする業務によって変わるため一般化はできません。

従って、ここは各組織が独自に定義するべきところだと思います。ちなみに、かく言う当社には、成長シートという職種ごとに必要な能力や求められる成果等をまとめたツールがあります。届けるべき価値は何か、そのために必要なプロセスは何か、知識・技能は何か、これらの定義と継続的なメンテナンスは、コストをかけてでもやるべきことです。

ここまでの読んでお茶を濁されたと感じる方もいるかもしれませんが、ここで私が言いたい事の本質は「AIを使いこなす能力 × 価値を創る判断を下す能力 」という式です。以降では、右辺に「価値・成果」を置いて「AIを使いこなす能力 × 価値を創る判断を下す能力 ＝価値・成果」を最大化するための育成戦略について述べていきます。

コーディングエージェントの登場の影響

さてここからは、システム開発の会社らしく、職種をシステムエンジニア（SE）に絞って話を展開していきます。

SEの職種においては、コーディングエージェントの登場によって「AIを使いこなす能力」の価値が高騰しています。なぜなら、コーディングエージェントは高速にコードを生成できるので、これを使いこなせるかどうかで生産性に雲泥の差が出るからです。ただし、私はここには二つの注意点があると考えています。

コーディングエージェント活用の優位は一過性

一つ目は、コーディングエージェントを使えることは一過性の優位にしか過ぎないということです。本格的なコーディングエージェントの登場は、2025年5月 Claude CodeのGAと言えるでしょう。今はそれからまだ1年も経っていないので、持たざる者と持つ者、過去と未来のアービトラージで優位が築けるというだけで、早晩コモディティ化して「AIを使いこなす能力」でつく差は小さくなっていくと思います。

「価値を創る判断を下す能力」がないと意味がない

二つ目は、いくらコーディングエージェントが使えても、「価値を創る判断を下す能力」がなければ意味がないということです。先に示した「AIを使いこなす能力 × 価値を創る判断を下す能力」に当てはめると、「価値を創る判断を下す能力」が仮に０だとすると、「AIを使いこなす能力 」がどれだけ大きくても計算結果は０。つまり、お客様のために役立つものは作れないということです。先に「使いこなせるかどうかで生産性に雲泥の差が出る」と言いましたが、それは「価値を創る判断を下す能力」がある人同士の話です。

「価値を創る判断を下す能力」は経験が織りなす総合力です。コーディングエージェントの主戦場である設計以降の工程でいえば、ビジネス要件に合わせたシステムアーキテクチャの決定や、データ量やアクセスパターンに合わせたデータモデルの決定などがあるでしょう。当然ながら育むためには長い時間がかかります。

これらの点から導き出せるのは、短期目線では「AIを使いこなす能力」を、長期目線では「価値を創る判断を下す能力」を身に着けるための取組みを並行して実施していくことが必要という結論です。

コーディングエージェントは開発現場をどう変えるか

ここからは長い時間がかかる「価値を創る判断を下す能力」をどう育成していくかを語っていきたいと思いますが、その前にコーディングエージェントが開発現場をどう変えるかを考えてみます。

コーディングエージェント（というか、生成AI全般）のすごいところは、

• 持っている知識の量が莫大
• アウトプットの速度が爆速

な点です。

これをシステム開発に当てはめると、どんな技術（プログラミング言語・フレームワーク・ライブラリ）だろうが、爆速でコードを生成してくれるということです。この知識量と出力速度は人間の比ではありません。しかし、そもそも要件がAIに正確かつ十分に伝えられていないと当然ながら出力結果は本当に欲しかったものにはなりません。例えば、ビジネスをスケールさせるための拡張性や不具合をトレースするためのオブザーバビリティ等の非機能要件が見落とされ、それによって保守・運用の段階で打ち取られるといったケースは容易に想像することができます。そのため、多面的な観点でのレビューをしてコードベースにマージしていく作業が必要になります。このレビュー／マージの工程にかかる負担をAIの力で軽くするサービスはいろいろ出てきてはいますが、いずれにしても中身を理解せずにリリースすることはできませんから、基本的には人間の仕事になります。

では、これまではどうしていたかというと、リーダーが要件を設計に落とし込み、プログラマーが実装、リーダーがレビュー／マージするという所謂サンドイッチワークフローを実践してきたはずです。そしてコーディングエージェントを活用する場合も基本構造は同じです。つまり、リーダーが要件を設計に落とし込み、コーディングエージェントが実装、リーダーがレビュー／マージをするというふうに変わるだけです。要はプログラマーがコーディングエージェントに置き換わっただけですね。

この場合、安直に考えると必要な人手が減るいうふうに考えられます。しかし、そうはならないでしょう。なぜなら、AIは（エネルギーや半導体がボトルネックになるまでは）無限に存在する一方で、要件を設計に落とし込んだりレビュー／マージしたりできるSEは希少だからです。爆速でコードを生成したところで設計やレビュー／マージがボトルネックになるわけですから、短期的にみれば人を減らすというトレンドに向かうことはあるかもしれませんが、長期的には設計やレビュー／マージを担う人の需要は残る。ゆえにそういう人材を育成する仕組みはどう考えても必要です。

また、爆速でコードを生成するAIと速度を合わせて、強度の高いレビュー／マージをするのは認知負荷が高い作業なので、担当する人がバーンアウトする（燃え尽き症候群になる）リスクも高くなります。そういう意味で、AIを使って既存の高スキル人材のリソース効率を高めることだけで、生産性を上げることは健全ではありません。

さて、コーディングエージェントが開発現場をどう変えるかを踏まえ、ここからは便宜的に「価値を創る判断を下す能力」を要件を設計に落とし込む能力とレビュー／マージを行う能力として話を進めていきたいと思います。（他にも様々な能力が挙げられると思いますが、わかりやすさを重視します。）

AI時代の開発・育成方法の在り方

これまでSEは、一行一行コードを書いたり、リーダーのレビューを受けることを通じて、設計やレビュー／マージを行う能力を磨く機会を得ていたにも関わらず、その機会はAIによって奪われてしまうことがほぼ確定しています。そういう状況下のため、育成戦略はまさに経営の中心に据えるべきテーマだと考えています。なぜなら、パラダイム転換期の難しい状況では戦略が成否を分けるからです。

シンプルな方法論としては、「AIなし」縛りや逆にAIを講師にする形での研修が思いついてはいましたが、他に良い方法はないかと探していたところ、とても興味深い動画に出会いました。以下に動画とGeminiによる動画の要約を貼っておきますが、まさに私が先のようにぼんやりと感じていた課題を明快に言語化した上で、進むべき方向のヒントを与えてくれました。

この動画は、テクノロジーメディア「Newbee」によるもので、著名なエンジニアである t_wada（和田卓人）氏をゲストに迎え、AI時代のエンジニアの働き方、教育、そして「AI疲れ」の本質について深く掘り下げた対談です。

主な内容は以下の5つのポイントに要約されます。

1. 「AI疲れ」の2つの正体
和田氏は、昨今のエンジニアが感じる「AI疲れ」を2種類に分類しています。

情報過多による疲れ: 日々更新されるAIツールや新機能、SNSでの活用法を追いかけ続けなければならないという「キャッチアップ疲れ」。

判断の濁流による疲れ: コーディングエージェント（AI）が爆速でコードを生成するため、人間は絶え間なく「これで良いか」という判断を求められます。判断には責任が伴うため、精神的な強度が上がり、心が休まらなくなる現象です。

2. ジュニア不要論と教育の危機
「AIがあれば熟練者だけで開発できる」というジュニア不要論に対し、中長期的には組織の多様性と永続性が失われるリスクがあると警鐘を鳴らしています。

教える側の喪失: AIは教わる側（ジュニア）にとっては最高の家庭教師ですが、それにより先輩が「教える機会」を失うことが問題です。「教えることによる学び」が失われるため、実は中堅層の成長が止まるリスクが高いと指摘しています。

3. 「バイブコーディング」の革命と限界
自然言語でノリ（バイブス）のままにアプリを作る「バイブコーディング」は、非エンジニアが自分の問題を解決するための真の革命であると評価しています。

ただし、社会的責任を伴うシステムや、セキュリティ・保守性が重要な領域では、従来のソフトウエアエンジニアリングの知識が必要であり、そこがエンジニアの新たな専門性の境界線になると述べています。

4. AI時代の解決策としての「モブプログラミング」
AIの圧倒的なスピードと判断のプレッシャーに対抗するため、「モブプログラミング（複数人で1つの画面を見て開発する手法）」が再び重要になると予測しています。

判断の分散: 1人でAIに向き合うのではなく、チームで判断を分担することで精神的負荷を下げ、同時にリアルタイムのOJT（教育）も実現できるため、AI時代の「フロー効率」を高める鍵となります。

5. AI依存症への警鐘
「AIを動かしていない時間が損失に感じる」という強迫観念や依存傾向についても触れています。

FOMO（取り残される恐怖）: 常にAIを使い倒さないと損をするという感覚は不健全であり、意識的にデジタルデトックスを行い、自分の状況を客観的に認識（メタ認知）することが大切だと説いています。

私はこの動画で紹介されている「フルサイクルデベロッパー」という概念と、それを具現化するのに適した「モブプログラミング」という開発手法が、設計やレビュー／マージといったボトルネックをなくすとともに、それら作業を担える人材を育成するための処方箋になりえると直感しました。

フルサイクルデベロッパー

フルサイクルデベロッパーは、設計・開発・テスト・デプロイ・運用・サポートまで、ソフトウェアのライフサイクル全般に責任を持つ開発者という概念です。2018年にNetflixが提唱しました。「作った人が運用する」という考えの下、工程ごとに縦割りにするのではなく一つのチーム体制にすることで、各工程で織り込む性能や品質課題を統合的に扱えるようになります。また、各工程での学びやフィードバックをチーム全体で共有できるため育成効果も期待できます。

Full Cycle Developers at Netflix — Operate What You Build

画像出所：Full Cycle Developers at Netflix — Operate What You Build

一方で、個々のSEの工程上の守備範囲を拡張する必要があるため、個々のSEの負担が増える（要は広い範囲の知識・技能を身につけないといけない）という問題はあります。ただ、AIを活用することでコーディングやコンフィグレーションを自動化できる分、2018年当時に比べて実践しやすくなったのではないかと思います。つまりAIによる自動化で減らした分の工数を議論や学びに使うのです。

それに、プロジェクト内の各SEの得意・不得意や関心事の濃淡は人それぞれ違います。そういう特性の違う人たちの多様性を結集する仕組みを持つことは、いかなる問題にも対応できる強いチーム作りにつながります。

ちなみに蛇足ではありますが、多様性をビジュアライズしたらどんなふうになるかな…と思って探してみたら、NoteのCXO深津さんの投稿にちょうどいいイメージを見つけたので貼っておきます。なんとなくですが、こういうイメージの中の一部が自分であるというふうに考えると、他のメンバーと協働しやすくなるような気がします。

画像出所：多様性と均一性のちがいについて – 深津 貴之note 

モブプログラミング

モブプログラミングは、3人以上のチームが1台のPCを囲み、全員で対話しながら1つの課題を同時並行でコーディングする手法です。百聞は一見に如かず、まずは以下の短い動画を見てイメージをつかんでもらうとよいと思います。

動画をみてもわかると思いますが、モブプログラミングでは「タイピスト」（1人）と「その他モブ」（その他全員）という二つの役割を10分程度の時間枠で交代しながらコードを作成していきます。

タイピスト

タイピストはその他モブに言われたことをタイピングして実装を進める役です。タイピストには以下のことが求められます。

• その他のモブがしてくれと頼んだことを理解すること
• 要請の意味がはっきりしないときには、はっきりさせるための質問をすること
• してくれと頼まれたことをコードの形に実装すること
• その他のモブを信頼し、自分では通常試さないようなアプローチを躊躇せずに試すこと
• ショートカットキーやほかの人のツールの活用方法などの新しいことを学ぶこと

その他モブ

その他モブはタイピストに対して、実装を進めるための具体的な指示を出す役です。その他モブには以下のことが求められます。

• 問題解決につながる次の論理的ステップを見つけるために力になること
• 理解できるまで質問をすること
• モブ全体の理解の水準を上げるために貢献すること
• 眼の前の問題に集中すること
• ほかのメンバーの意見を聞くこと
• 必要な情報を予測すること
• システムのなかの改善すべき部分を探すこと

なお、モブプログラミングの実践ノウハウは「モブプログラミング・ベストプラクティス」に詳しく書いてありました。この本はとてもおすすめです。プロジェクトへの導入ステップ、参加する際の心構え、適切なファシリティ環境、参加者同士のスキル差が大きい場合の対応方法など実践的な内容が充実していたので、ガイドとして使えるという手ごたえを感じました。

モブプログラミングが提唱されたのは2012年頃ですから、当時にコーディングエージェントはありません。そのため、コーディングエージェントにコーディング等の生成作業は行わせる前提で、実践ノウハウをアレンジする必要はあります。そもそも、タイピストの役割がコーディングではなくて、AIへのプロンプティングになることからして違いますからね。しかし、考え方はそのまま流用可能です。

なぜ今モブプログラミングか

私がなぜ今モブプログラミングが有望と考えているかというと、以下２点に整理できます。

• AIの仕事は広範かつ高速過ぎるので一人の人間だけでAIの成果物の採否判断するのは難しい。
  ➡ 多様性を持った人材を集結すればより良い判断を下せる。また、負担を分散できる。
• 「価値を創る判断を下す」能力を養う上で重要なコーディングの機会はコーディングエージェントに奪われる。
  ➡ AIへのプロンプト入力や結果の承認／否認をリアルタイムで協働することが新たな育成機会になる。

これらの点は賛同が得られそうな気がする反面、「同じ作業を複数人でやったら生産性が落ちるじゃないか？」という懸念の声が聴こえてきそうな気もします。これに対しては人材の「リソース効率とフロー効率」という概念を持ち出した上で、どちらを重視すべきかを検討する必要があります。

リソース効率 VS フロー効率

リソース効率とは、個人の稼働率のことです。リソース効率を最大化するためには、個人の知識・技能に合わせてタスクを分割して手空きにならないようにディスパッチするという行動をとることが自然です。

このアプローチは一見すると問題ないように思えますが、オーケストレーションを上手くやるのが難しいという問題があります。わかりやすく言えば、一部のタスクの進捗が遅れると、それに引きずられて他のタスクが遅れてしまうということが起こりやすい。例えば、フロントエンドの実装とバックエンドの実装で担当者を分けた場合、いくらフロントエンドの実装が早く完成しても、バックエンドの実装が遅れた場合、全体の完成はバックエンドの実装完了に引きずられてしまうという具合です。また、このアプローチにはもう一つ問題があります。それは、知識・技能がサイロ化するという問題です。これも例を挙げた方がわかりやすいでしょう。例えば、フロントエンドの開発が誰よりも早いAさんと、別の得意分野を持つBさんがいるとします。リソース効率を重視する管理職は、作業を安く早く進めるために、フロントエンドの仕事をすべてAさんに集中させます。しかし、この方法ではＡさんだけがエキスパートになり、もしフロントエンドの仕事が急増したりＡさんが休んだりすると、そこで作業がストップし、チーム全体のボトルネックになってしまいます。

フロー効率とは、（簡潔な表現が見つからなかったのですが、）作業が滞らずに流れている時間割合のことです。フロー効率を最大化するためには、同じタスクを多様な人材に同時に割当て、問題が発生してもすぐに専門技能を有する人的リソースを使える状態を作ることが重要です。

フロー効率重視のアプローチでは、個人の能力を100%引き出すこと（リソース効率）は下がる代わりに、オーケストレーションはシンプルになります。また、知識・技能が共有されることによって、たとえ誰かが休んだとしても、他のメンバーがサポートして作業を続けられるため、仕事の手が止まることはありません。

まとめると、モブプログラミングは、複数人で1つの課題に取り組むため一見するとコストパフォーマンスが悪く見えますが、実はこの「フロー効率」を高め、仕事を早く終わらせるための手法なのです。

以下は、リソース効率を重視するアプローチ（高速道路で自動車（＝細分化されたタスクを割り当てられた個人）が渋滞）とフロー効率を重視するアプローチ（高速道路で自動車（＝まとまったタスクを割り当てられたチーム）が流れている様子）を比較するイメージ図です。最終的にたくさんある荷物を目的地に早く届けられるのはどちらかというふうに考えると「リソース効率 VS フロー効率」の話を思い出しやすくなると思ったので載せておきます。

画像出所：モブプログラミング・ベストプラクティス

まとめ

だいぶ長くなりましたので、要点をまとめておきます。

• 「AIを使いこなす能力 × 価値を創る判断を下す能力 ＝ 価値・成果」の最大化をするべき。
• コーディングエージェントの登場によって、人間による設計・レビュー／マージのタスクがボトルネックになる。
• 広範かつ高速に仕事をこなすAIと協働するためには「フルサイクルデベロッパー」と「モブプログラミング」が有効。
• モブプログラミングはコーディングエージェントに奪われたプログラミングやレビューに代わって新しい育成機会になり得る。

今の段階では、まだ私一人による思考実験の域を出ませんが、社員のみなさんにもこの意見を聞いてもらった上で筋が良さそうであれば、実証や社内研修での実践、最終的には現場適用というふうに段階的に推進していきたいと考えています。

読み返してみると我ながらまだまだ粗削りな主張だと思うところはありますが、AI時代の人材育成は経営の中心に据えるべきテーマですので、引き続きタックルしていきたいと思います。

最後までお読みいただきありがとうございました。