AIがコードを書ける時代だからこそ、Jrエンジニアに「AIを疑う力」を育てた話

TL;DR

• AI時代のJrエンジニア育成では、AIを使う力だけでなく、AIの出力が意図とずれていないかを判断する力に着目しました。
• 本記事では、その力を「AIを疑う力」と捉え、教材・1on1・実務課題を通じて育てた実例を紹介します。
• 本記事はチーム内での個人的な実践であり、MonotaRO 全社としての標準的な育成方針を述べるものではありません。

はじめに

こんにちは。モノタロウでWeb広告運用を効率化・自動化するためのシステム開発を担当している広告システムチームの早川です。AIがコードを書く時代になり、Jrエンジニアの育成を任されたメンターやチームリーダーの立場で、こんな悩みに心当たりはないでしょうか。

• AIがコードを書いてくれる時代に、自分が新人時代にやってきたたくさん書いて身体で覚えるやり方を、そのまま勧めて良いのか自信が持てない
• AIが当たり前にコードを生成する前提だと、Jrエンジニアに最初に身につけさせるべき能力は、過去とは変わってきているのではないか
• 教えるべきこと（設計、テスト、Git、レビュー、ドメイン知識……）は山ほどあるなかで、何から優先して身につけてもらうかを決め切れない

私自身、広告システムチームでJrエンジニアの育成を任されたとき、まさに同じところで一度立ち止まりました。

本記事では、そこから当初の方針を組み直し、約半年間Jrエンジニアと一緒に「AIを疑う力」を中心に据えて取り組んだ育成設計と実例を紹介します。同じ立場で悩んでいる方の判断材料になれば嬉しいです。

当初は追体験式でいくつもりだった

立ち止まる前、Jrエンジニア育成を引き受けた直後にまず思い浮かべていたのは、自分自身が新人時代に通ってきた学び方を踏襲するアプローチでした。具体的には、自分の手でたくさんコードを書き、良いコードと悪いコードを身体で体感するという、いわば追体験式の学習です。

量を書くこと自体には価値があります。動く / 動かない、読みやすい / 読みにくい、後で困る / 困らない、といった感覚は、コードを実際に手を動かして書くことで身に付く部分があります。私自身も、苦労した量だけ判断の引き出しが増えた実感があります。

ただ、育成計画を立てる前に一度立ち止まって考えたとき、ここに引っかかりがありました。AIが当たり前にコードを書く時代に、Jrエンジニアの半年という限られた時間を、追体験のために使うのは本当に有効なのか。これからの実務では、JrエンジニアもまずはAIに書かせ、それを評価しながら手直ししていく、という進め方が標準になっていくはずです。そうした業務の中で価値を出すためには、自分の手でたくさん書くよりも、AI活用を前提にして、品質の高い成果物を生み出すスキルのほうが先に求められるのではないか。

そう考え直して、追体験式を一度棚に置き、AI活用を前提とした育成に方針を切り替えることにしました。

Jrエンジニアとマインドマップで必要なスキルを可視化した

方針は変えたものの、AI活用を前提とした育成と言葉で言うのは簡単で、中身を具体化しないと何をすれば良いのかが分かりませんでした。そこで、まずはJrエンジニア本人と一緒に、AI活用を前提にした業務でどんな能力が必要になるかを書き出すところから始めました。

情報整理のツールとして、マインドマップを活用しました。まず初めに、AIが進化しても陳腐化しない能力を中央に置き、Jrエンジニア本人へのヒアリング形式で進めていきました。

具体的には、次の方法でマップを広げていきました。

1. Jrエンジニアに、日々の業務で感じている課題や獲得したいスキルを一つずつ挙げてもらう（こちらから質問を投げかけることもある）。
2. それをメンターである私が受け取り、枝分かれとして描き足していく。

特に重要視したポイントとしては、AIを使って実装する状況をなるべく具体的に思い浮かべてもらいながら、ここで何ができないと困るかを一つずつ言葉にしていったことです。

書き出した項目を整理していき、最終的にAIが今後どれだけ進化しても陳腐化しないであろう能力を3つほどピックアップしました。社外向けに簡略化したものを示すと、おおよそ次のような形です。

それぞれを一行で言い換えると、こうなります。

• 基礎体力: 可読性、設計原則、テスト、型、例外設計など、ソフトウェアエンジニアリングの基礎を学ぶことでAIが出したコードを評価する土台を作る
• 批判的レビュー力: 動いていると意図に沿っているを別物として扱い、生成されたコードや設計を批判的に読み解く力
• ドメイン判断力: 業務要件や外部制約を踏まえて何を作るべきか／何を捨てるかを選び取る力

3つはどれも欠かせませんが、本記事はその中でも2つ目のAIを含むアウトプットを批判的に読むレビュー力を主役として扱います。理由は次の章で説明します。

また、マインドマップによる可視化によって、具体的に何をしていくかのイメージをJrエンジニア本人と合意できたことは、今振り返ってみると良かったポイントだと感じています。約半年間を通じて、1on1やPRレビューの場面で「今やっているのは、マインドマップで言うこの能力を伸ばすため」と都度立ち戻れたので、お互いに学んでいる対象がぶれませんでした。

主役に据えた「AIを疑う力」をどう定義したか

3つの能力の中で、なぜ批判的レビュー力を主役にしたのか。理由は単純で、AI活用を前提にした業務で、最初に詰まりやすく、かつ仕組み化しないと身につきにくいのがここだったからです。

AIに何かを依頼すると、たいていの場合、それらしく動くコードが返ってきます。しかし動く=意図に沿っているとは限りません。要件を詰めずに依頼すれば、どこかしら意図とずれたコードが返ってくる可能性は十分あります。にもかかわらず、初学者のうちは「動いた＝正しい」と受け取りがちです。ここで批判的に読み解けるかどうかが、後工程での手戻り量を大きく左右すると考えました。

本記事における「AIを疑う力」は、次の3点で定義しました。

• 設計や要求と照らし合わせて、AIのアウトプットを読むこと
• 「動いている」と「意図に沿っている」を別の判断軸として扱うこと
• 自分がなぜ受け入れたか、なぜ修正したかを言葉で説明できること

シンプルですが、この3点を満たすだけでも、AIと一緒に作業する際の品質はかなり安定します。逆にここが曖昧なまま進めると、AIを活用しているように見えて、実態は「AIが出してきたコードを後追いで直しているだけ」になりがちです。

これをJrエンジニアのうちから習慣にしてもらうのが、今回の育成設計のいちばんの狙いでした。

教材 × 1on1 × 実務課題の3本柱で能力を伸ばす

「批判的レビュー力」を中心に据えると決めたあとは、それを伸ばす仕組みを3本柱で組みました。教材、1on1、実務課題です。それぞれが別々のことを教えるのではなく、同じ能力を別の角度から鍛えるように設計しました。

実際の進め方は、ステップを区切って段階的に積み上げました。設計の物差しを書籍で固める → 開発環境とコーディングの基礎を整える → 可読性の語彙を揃え、AIを学習補助として併用する → AIに頼らない手で改善する → 上流の設計力を強化する → AI前提でアプリを作り切る、という流れです。

教材: 書籍2冊 → Python演習リポジトリの順で土台を作る

まず初めに書籍を読了してもらい、何が良いコードで、何が良い設計なのかの物差しを言葉として持ってもらってから、手を動かす演習に進むようにしました。

最初に読んでもらったのは、増田亨 著『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法〜』です。値オブジェクトをはじめとした設計の基礎概念を、業務寄りの題材で身につけてもらう狙いです。章ごとに理解度を確認しながら進め、読み流しを防ぐために章末の理解度テスト（簡単なもの）の全問正解を読了の目安にしました。

続いて『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』を読了し、可読性に関する語彙（命名、制御フロー、コメントの粒度、巨大な式の分解など）を揃えました。読書段階ではあえて一人で抱え込ませず、ChatGPTやNotebookLMを使って分かりにくかった節を要約してもらいながら、自分の理解をより深めていけるようにしました。

書籍2冊で物差しが揃ったところで、その物差しを使って実際にコードを直す演習として、Python演習用のGitHubリポジトリに進みました。このリポジトリは『リーダブルコード』の論点をPythonで実践するための題材集です。私がAIを使ったいわゆるバイブコーディング（AIに対話形式で指示を出しながら手早く組み上げる進め方）で作成し、章ごとの題材コード、課題説明、PRテンプレートを一気に揃えました。 演習リポジトリ作成のインプットには、私自身の読書メモ（章ごとのポイントを殴り書きしたもの）を使いました。

これは個人的な感想ですが、AIのおかげで、今までは腰が重かったことも手早くできるようになり、感動を覚えました。

運用は、1週間に1章のペースで進め、毎週PRベースでレビューする形にしました。PRテンプレートには以下のポイントを必ず記載するようにし、自分でやったことや考えたことを言葉にする訓練にも取り組みました。

• 変更内容の要約（どういった変更を実施したのか）
• そのようなコードを書こうと思った理由
• 動作確認で実施したコマンドやその結果
• 作業していて悩んだことや特にレビューして欲しいポイント

ちなみに、この時はあえてAIコーディングエージェントの利用を禁止し、自分で考えながら書くことを要求しました。

AI利用前提の実務課題に入る前に、自分なりの判断基準を持たせるため、あえてこの段階で自分でコードを書く体験を置きました。自分だったらこう書く、実際に書いてみるとそこからの改善点が見えるといった体験を通じて、より深い理解を得てほしいという私個人の思いがありました。もちろん、最終的にはAIが100%コードを書くことを前提とした学習を想定していますが、今このタイミングだからこそ自分で手を動かすこともできると考えました。

可読性をセンスとして扱わず、命名、制御フロー、巨大な式の分解、テストの読みやすさ、設計改善といった、レビューできる論点に分解しているのもこの教材の良さでした。各章でテーマが絞られているので、1on1でも「今週はここの観点で議論する」と論点を揃えやすかったです。

1on1: 進捗確認ではなく、設計レビューと内省の場に

1on1はあえて、進捗確認の場としては使いませんでした。代わりに、設計レビューと内省の場として運用しました。

具体的には、PRや作りかけのものを題材にして、できたコードだけではなく、なぜその分け方にしたのか、今のTODOは十分に小さいか、次にAIに何を渡すつもりかといったことを話しました。会話の中で、AIを使うときに渡すコンテキストの質、設計と実装の対応関係、判断のぶれが出ているところ、といった観点を整理しながら進めました。

進捗を「できた／できていない」で詰める時間ではないので、本人が今どこで判断に迷っているかが出やすくなりました。ここはAIに任せて良いと思った、ここは自分で考えるべきだと感じたなど、判断の根拠を言語化する時間としても有効だったと思います。

実務課題: AI前提で作り切る体験を通じて鍛える

教材と1on1で物差しと内省の場を整えたあとは、それらを実際に使い切る場として、Jrエンジニア本人が題材を選ぶ小さな実務課題に取り組んでもらいました。題材自体は業務に関連する小さな自走型ツールで、要求整理から実装、運用、社内発表までを一人で通すことをスコープにしました。

ゴールは何かしら動くものを作り切ることに置き、完璧さよりも完走を優先しました。一方で、完全に自由にはせず、期限、使う技術スタック、最終的な共有先だけは早い段階で制約として置きました。AI活用前提なら題材の自由度は上げてよい、ただし「いつまでに、どんな形で、誰に届けるか」を先に固める、という整理です。

進め方は、教材で揃えた語彙をそのまま現場で使えるように、要求定義 → 設計書 → TODO 分解 → 実装 → commit前のセルフレビュー → push前のAIレビュー、という流れをステップで区切って踏んでもらいました。各ステップの成果物（ラフな要求、設計書、TODOリスト、PR）を1on1の題材にし、「ここはAIに任せた、ここは自分で考えた」を都度言語化してもらう運用です。

ここで主役の「AIを疑う力」がはっきり鍛えられたと感じています。設計書とTODOを本人の言葉で書き起こすと、AIに渡すコンテキストの質そのものが判断対象になります。生成されたコードを、動くかどうかだけで受け取らず、自分が書いた要求や設計と照らして読まないと、ステップ間の整合が崩れてしまうからです。教材で覚えた可読性や設計の語彙が、ここでAI出力をレビューする物差しとして実地で使われる構図になりました。

最後はKPT（Keep/Problem/Try）で振り返り、本人の言葉で学びを整理してもらったうえで、チームに向けて成果物と取り組みを共有してもらいました。発表まで含めて1サイクルにしておくと、動かして終わりにならず、設計判断や詰まった点を言葉にして自身の取り組みを整理できたのが良かったと考えます。

うまくいったこと

まず良かったのは、教材と実務課題が分断されなかったことです。マインドマップで育成対象を最初に揃えたので、教材で扱ったコードを読みやすくするための手法や構造に関する用語が、実務課題のレビューでもそのまま共通言語として使えました。抽象的に設計を考えようと言うより、共通言語がある状態でレビューできたのは認識齟齬を軽減する意味で良かったと感じました。

次に、1on1の質が変わりました。「進捗どうですか」で始まる会話を、「今どこで迷っていますか」「何をAIに任せ、何を自分で考えていますか」に置き換えただけで、出てくる話の解像度が大きく上がりました。これはJrエンジニア本人にとっても、自分の判断を言葉にする練習になっていたと思います。

そして最大の収穫は、JrエンジニアがAIを使うだけでなく、疑えるようになってきたことです。AIが出力したコードに対して、何かしらの違和感（コードスメル）を自分の言葉で言えるようになっていきました。もちろんその内容は些細なことも多いですが、約半年間を通じてもっとも嬉しかった変化です。

難しかったこと

うまくいったことばかりではありません。今回の取り組みで見えた課題を2点ほど整理しておきます。

ひとつ目は、AIに渡すコンテキストの不足です。設計やTODOを十分に分解しないままAIに依頼すると、それらしいコードは返ってきますが、意図とのずれが時間経過とともに顕在化してきます。今回は途中で気付いて、設計書とTODOの粒度を細かくし、push前のAIレビューを挟む形に運用を寄せました。ここからの学びは、要件定義や設計のフェーズで、情報整理、実現したいこと、そこへ向けたタスクの洗い出しをどれだけ認識合わせできるかが重要だ、ということです。

ふたつ目は、Jrエンジニアの学習実績に対して、どのような評価をするかです。うまくいったことで挙げた「AIを疑える変化」は定性的には観察できましたが、これを定量的にどう測るかは今回の取り組みでは答えを出し切れませんでした。社内の業務評価も参考にしながらレベル感はある程度決められても、そこから現時点の状態を定量的に判断する方法はまだ見つかっていません。また、AIの進歩が早いため、初期段階で設定した項目も数ヶ月後には陳腐化するケースにも遭遇しました（今となってはもうAI側の精度が上がったから問題にならないよね、というニュアンスです）。結果的に、定性的な評価と取り組み内容の振り返りによる判断にとどまりましたが、ここもAIに依存しない評価項目や、定量的に判断できる確認方法を見つけられれば、より客観的な評価が可能になると思います。

まとめ

この取り組みを通じてAIの使い方はもちろんですが、それ以上にエンジニアとして求められるスキルを、AIを使ってどう拡張できるか、という視点が重要だと感じました。

とくにAIを疑えるレビュー力は、AIが今後どれだけ進化しても価値が下がらない能力だと思います。むしろ、AIが賢くなるほど、人間側に残る役割は最終的に意図とずれていないかを判断することに集約されていくと私は考えております。だからこそ、Jrエンジニアのうちから、この能力を中心に置いて育てる価値があると感じました。

今回は自前の演習リポジトリ、設計レビュー型の1on1、AI利用前提で小さなツールをゼロから作る実務課題、という組み合わせでしたが、それ以外にもさまざまな方法があると思いますし、それもAIの進化によりどんどんハードルが低くなってくることでしょう。

今後、AIがどこまで進歩するのかは未知数ですが、その時代に合った方法を都度見直しながら、達成したい目標に向かって成長していけるように、これからも学び続けていきたいと思います。

なお本記事の内容は、私がチーム内でJrエンジニア育成を担当した中での個人的な取り組みであり、MonotaRO 全社としての標準的な育成方針を述べるものではありません。同じような立場で悩んでいる方にとって、何かひとつでも参考になる部分があれば嬉しいです。

もし、私たちの取り組みに興味をお持ちいただけましたらカジュアル面談などお声掛けいただけるとうれしいです！

カジュアル面談で話を聞いてみる