AIで「人月モデル」は崩壊する それでも“若手エンジニア不要論”が危険な誤解である理由：AI駆動開発は、かえってエンジニアの価値を高める（2/2 ページ）

[鍋島理人（Innerstudio），＠IT]

経験学習モデルで思考力を鍛え、モブプログラミングでナレッジを育てる

　AI時代に若手エンジニアをどのように育成すればいいのか。漆原氏は、育成の手掛かりとしてデイヴィッド・コルブ氏が提唱した「経験学習モデル」を紹介した。これは、座学だけでは得られない、実体験を通じた学びの仕組みを体系化したものだ。

　まず、「やってみる」という具体的な経験を積む。次に、「なぜこの結果になったのか」「もっとうまくやるにはどうすればよいか」と、その経験を内省的に振り返る。そこから「次はこうすればうまくいく」といった、他の場面にも応用できるコツを導き出す。次の機会には、学んだことを能動的に試してみる。こうしたサイクルを繰り返すことで、実践に役立つスキルを高めていくのが、経験学習モデルの基本的な考え方だ。

デイヴィッド・コルブ氏の経験学習モデル（漆原氏の講演資料から引用）

　従来のエンジニアは、コーディングやデバッグ、本番環境での障害対応、リリース判断といった現場経験を通じ、このサイクルを自然と回してきた。意思決定に伴う責任と緊張も、判断力を育てる機会になった。しかしAIに指示するだけで成果物が完成すれば、こうした経験を積む機会が失われてしまい、学習も成長も止まってしまう。

　カーネギーメロン大学とMicrosoftの共同研究でも、AIへの過度な依存が批判的思考力を低下させることが報告されている。

　AIを使って高校生に数学を学ばせた実験では、答えをそのまま教えるAIを使ったグループは、AIを取り上げた途端に成績が大きく落ちてしまった。一方、解き方のヒントだけを与えるAIを使ったグループは、自力でも一定の実力を保っていた。答えを簡単に教えるAIは、学習を阻害するのだ。

　こうした知見を踏まえ、漆原氏はAI時代における若手エンジニアの育成手法を提唱する。その軸となるのが、AIに頼り切るのではなく、レビューと意思決定を通じて経験を積み重ねるという学習設計だ。

　まずは若手に自分なりの案を出させた上で、AIが生成した結果をレビューさせる。要件やタスクを分解し、設計案やリスク、テスト方針、仮説、不明点などを自分の言葉で示すことが重要だ。誤りを発見した際には、単に修正するだけで終わらせず、誤りである理由まで説明させる。要件定義や顧客との対話、設計、リリース判断、セキュリティレビュー、障害対応や振り返りなど、実環境での意思決定に若手を参加させることが重要だと、漆原氏は言う。

　「若手だからといって現場から遠ざけて学習だけさせるのではなく、むしろ最初から現場に引っ張り出すべきだ」

　その際には、アジャイル開発の現場で育まれたさまざまなノウハウを応用できる。一例として、漆原氏はモブプログラミングの手法を紹介した。モブプログラミングでは、1つの端末を先輩や若手を含むメンバー全員で共有し、一人がコードを書く過程を全員で見ながら開発を進める。これにより、若手は先輩の思考過程を追体験し、判断の仕方や考え方を学ぶことができる。

　漆原氏は、AI時代には開発者だけでなく、ビジネス担当者やデザイナーなど、各分野の専門家もモブプログラミング的な取り組みに参加し、知見を持ち寄ることが重要だとも提唱する。AIによってシステム開発の効率が大幅に向上すれば、チームが向き合うべき課題はビジネス開発へと広がっていくからだ。そこでは、ビジネスなど、より上流の視点での思考に加え、モラルや倫理、サービス提供の意義といったリベラルアーツの観点からの議論も求められる。

　こうした議論の過程を必ず記録に残すことで、そこで得られた知見をチームの資産として蓄積できるようになる。アーキテクチャ設計においても、設計そのものだけでなく、「なぜその判断をしたのか」という背景や理由をADR（Architecture Decision Record）に残すことが重要だ。

個人の経験や暗黙知をメンバー間で共有し、互いの学びや新たな気付きにつなげる（漆原氏の講演資料から引用）

クラフトマンシップを育み、エンジニアが輝く時代へ

　若手を育成する上で、もう一つ重要なことがある。それが「クラフトマンシップ」を養うことだと、漆原氏は言う。美しい設計を追求し、その美しさに自分自身が心を動かされるような、ものづくりへの誇りこそがエンジニアの原動力だ。

　こうした姿勢は、単にプロジェクトマネジャーの下に若手を配属するだけでは育たない。育成が得意な先輩の下で、徒弟制度的に学ぶ仕組みが必要だという。ビジネスサイドとも、技術の話だけの関係ではなく、「これからもずっと一緒に仕事をしたい」と互いに思える長期的な関係性を築くことが重要だと、漆原氏は訴えた。

　人月モデルの崩壊後、システム開発はどのような形に向かうのだろうか。漆原氏が提示する方向性は以下の4つだ。

　第1は、少人数チームとAIエージェントによる、生産性が非常に高い開発だ。SIerの売り上げは下がる可能性がある一方、利益率は高められる。第2は、透明性を保ちつつ品質を保証する請負型の開発だ。第3は、月額や年額でチームの開発力を定額で提供するサービス型のモデルだ。第4は、顧客と価値を分かち合う成果報酬型だが、これはどのように設計すればよいか、漆原氏自身も手探りの状態だという。いずれか1つに収束するのではなく、案件の特性に応じた組み合わせになっていくと、漆原氏は予想する。

システム開発におけるビジネスモデルの未来（漆原氏の講演資料から引用）

　最後に漆原氏は、次の言葉で講演を締めくくった。

　「AIツールは誰でも使えるものだからこそ、逆に人とチームを育て続ける企業こそが競争力を持つ。人月モデルが崩壊することで、望ましくなかった構造が解消され、より健全で透明性があり、みんながワクワクできるチームが輝く時代が来ることを心から願っている」