前回、「AIにコードを触らせるときの実用限界は、ファイルの数ではなく案内の質だ」という話を書きました。そして、その案内の作り方は、システム開発が昔から積み上げてきた作法とほぼ同じものだった、と。
そこまで書くと、次の疑問が出てきます。その作法は、これから業界に入ってくる人にどう教えればいいのか。
新人研修やSE研修の講師を長年務めてきた立場から見ると、ここ1〜2年で研修の前提は確実に変わりました。今回はその変化を、カリキュラムの話として具体的に整理します。
変わったのは「最初に任される仕事」
かつて新人が最初に任されたのは、仕様書を渡されて小さな機能を実装する、いわゆる下働きの実装でした。手を動かすうちに読み書きの型が身につく、という育ち方です。
いま、その工程はAIがかなりの部分を担えます。結果として新人が最初に置かれる立場は、「自分で書く人」から「AIに書かせて、その結果に責任を持つ人」へと前倒しになりました。
これは実は、入社1年目にいきなりレビュアーの席に座らされているのと同じ状態です。従来なら数年かけて到達したポジションに、初日から立たされている。だから難しいし、だから研修の内容も変わらざるを得ません。
ただし「コードは書けなくていい」ではない
ここはよく誤解されるところなので、はっきり書いておきます。AIが書くから読めれば十分、ではありません。
出てきたコードが妥当かどうかを判断するには、自分でも書ける程度の理解が要ります。書けない人のレビューは、たいてい「動いたからOK」になります。AIは自信満々に、それらしく間違えます。その「それらしさ」を見抜けるかどうかが、そのまま品質の上限になります。
変わったのは「書けなくていい」ではなく、書く力の使いどころが、生産から検収へ移ったということです。
厚くしたい5つの力
そのうえで、いまの新人研修で比重を上げるべきだと考えているのが次の5つです。
1. 読む力を、書く力より先に置く
差分を読む、他人のコードの意図を推測する、レビューで指摘を言語化する。従来は実装演習の後回しになりがちだった領域を、前に持ってきます。最初の演習を「白紙から書く」ではなく「わざと欠陥を仕込んだコードを渡して直させる」形にするだけでも、狙いはかなり達成できます。
2. 曖昧さを残さずに書く力
前回の記事に書いたとおり、AIには「よしなに」「適宜」が通じません。これは要件定義の訓練そのものです。やりたいことを、解釈の余地なく文章にする——長らくベテランの技とされてきたこの力が、1年目から必要な基礎技能になりました。
指示文を書かせて、その指示だけを見た別の人（またはAI）に作らせ、ズレを突き合わせる。この往復は、研修演習としてよく機能します。
3. 検証を先に設計する
「何ができていれば完成か」を、作る前に書く。受け入れ条件とテストの考え方です。AIは指示されたものは作りますが、それが正しいかどうかの基準は持っていません。基準を持ち込むのは人間の側の仕事です。ここを教えていないと、「動いているように見えるもの」で完了報告が出ます。
4. 記録を残す作法
命名規約、コミットメッセージ、設計判断の記録。かつては「几帳面な人がやる余分な仕事」に見られがちでした。いまはAIが状況を正しく把握するための入力そのものです。守らない実害がはっきりしたぶん、教える側も説得しやすくなりました。
5. 止める判断とエスカレーション
AIは分からないときも答えを返します。新人がそれを鵜呑みにすると、誤りが速度に乗って広がります。「ここから先は自分では判定できない」と言えること、そしてそれを早い段階で言えることを、評価される行動として明示的に教える必要があります。技術ではなく態度の話ですが、実害の大きさで言えば最重要です。
薄くしてよいもの、むしろ厚くすべきもの
| 領域 | 扱い | 理由 |
|---|---|---|
| 文法の細部・API名の暗記 | 薄くしてよい | 調べれば出る。覚えていることの価値が下がった |
| 定型コードを手で書く反復 | 薄くしてよい | AIが担う領域。時間対効果が落ちた |
| データベース・ネットワーク・OSの原理 | むしろ厚く | AIの出力を疑うための土台。原理を知らないと誤りに気づけない |
| セキュリティの基礎 | むしろ厚く | 生成されたコードにそのまま脆弱性が入る。判定できるのは人だけ |
| 設計・要件定義の考え方 | むしろ厚く | AIへの指示の質＝成果物の質。1年目から効く |
一言でいえば、「調べれば分かること」は薄く、「知らないと疑えないこと」は厚くです。基礎が要らなくなったのではなく、基礎の使い道が「作るため」から「見抜くため」に移りました。
演習のやり方そのものを変える
カリキュラムの中身より、実は形式のほうが変更を迫られています。
AI禁止の演習は、もう目的を果たしません。 現場で使う道具を取り上げて測っても、測れるのは現場と違う能力です。そこで有効なのが、使わせたうえで説明させるという形式です。
- AIに書かせてよい。ただし、なぜその実装を採用したかを口頭で説明させる
- 説明できない箇所は、採用しなかったものとして扱う
- 提出物には、指示文（プロンプト）と、そこから何を直したかを添えさせる
不正対策としてではなく、説明責任の訓練として設計するのがポイントです。現場でレビューを通すときに求められるものと、そのまま同じ形になります。
もうひとつ効くのが、順番の固定です。「自分の仮説を先に書く → AIに聞く → 差分を確認する」という順番を守らせる。逆にすると、考える工程がまるごと消えます。同じAIを使っていても、先に自分の答えを持っているかどうかで、身につくものがまったく違います。
受け入れる側の設計も要る
研修が変われば、配属後の受け入れ方も変わります。
新人が最初からレビュアー的な立場に立つということは、判断の基準を渡しておかないと機能しないということです。前回の記事で書いた「AIに渡す地図」——全体構成の説明、設計判断の記録、用語集——は、そのまま新人に渡す地図でもあります。
ここが今回いちばん言いたいところです。AI向けに環境を整える作業と、新人が育つ環境を整える作業は、ほとんど同じ作業でした。地図のない現場は、AIも新人も同じように迷います。逆に、地図を整えた現場は両方が立ち上がりやすい。片方のための投資が、そのまま両方に効きます。
まとめ
これからの新人に求められるのは、コードを書ける人であること以上に、AIにもチームにも、迷わせない指示と記録を出せる人であることです。
- やりたいことを、解釈の余地なく書ける
- 出てきたものを、根拠をもって判定できる
- 判定できないときに、止めて聞ける
- やったことを、次の人（と次のAI）が読める形で残せる
並べてみると、どれも新しい能力ではありません。優秀な人が昔からやっていたことです。違うのは、それが一部の人の美徳ではなく、1年目から求められる基礎技能になった点です。前回の記事の結論と、きれいに同じ形になりました。人が働きやすい作法は、そのままAIが働きやすい作法であり、そして人が育ちやすい作法でもあった、ということです。
当社では、長年のIT研修・SE研修の講師経験と、自社サイトをAIで再構築している現在進行形の実務の両方から、この領域の知見を蓄積しています。新人研修のカリキュラムをAI前提で組み直したい、あるいは受け入れ側の体制から見直したい——そうしたご相談にも対応しています。