SIerで積んできた経験は、事業会社でも通用するのか。運用やインフラ、リリース対応といったスキルは、大規模サービスの現場でどう生きるのか。キャリアを広げたいと考えたとき、多くのエンジニアが一度はこうし...

はじめに こんにちは、セーフィーのたかぎです。 新卒エンジニア向けの研修プログラムをより充実させたいと思いつつも、新しい講座を通常業務の傍らで一から用意するのはハードルが高いものです。 今回、Claude Codeを活用することで、これまで手が出せなかった新しい教材の作成に踏み切ることができました。 この記事では、Claude Codeを使って新卒研修の教材を実際に作った過程と、そこで得た知見を共有します。 なぜ今回できたのか 結論から言うと、生成AIの性能向上により教材のハードルが大幅に下がったからです。 単純に教材を1から作っていくとなると記述量が膨大になります。 教材を自前

はじめに：AIに 取って代わられる 恐怖よりも、エンジニアとして学ぶべきことの多さに恐怖している 4月で、エンジニアとして4年目に突入しました。まだまだ、エンジニアとして未熟だと痛感する毎日でございます。私は、プロダクト開発に関わる傍ら、AIを組織に導入したりその後の活用を推進するプロジェクトにも属していました。 プロジェクトの進行で必要な知識をつけるために、AIモデルプロバイダーが発信する知識や、LT会・カンファレンス・社外の事例の記事を調べています。その中で感じているのは、エンジニアとして学ぶべきことの多さです。AIについて調査すればするほど、取って代わられる恐怖よりも、「これからエンジニアとしてこんなに学ばないといけないのか…？」と学ぶべきことの多さに戦慄しています。 2026年4月22日（水）に Sansan株式会社Eight主催のテックリードカンファレンス に参加しました。本記事では、そこで感じたことを、それを増強するための書籍・動画で発信されている知識と組み合わせてお伝えしようと思います。 左: 和田 卓人氏(タワーズ・クエスト株式会社　取締役社長)　右: 佐藤 治夫氏(株式会社ビープラウド　代表取締役社長) なお、本記事は 4ヶ月前に書いた記事(AI時代も変わらない、ソフトウェア開発の基礎) の続きという位置付けでもあります。基礎の重要性を改めて確認し、より具体的な「ではどうするか」に踏み込んでいく内容です。 TL;DR（この記事のまとめ） 「AIに取って代わられる恐怖」や「AI爆速開発の焦り」への対応は、分からないことを放置せず基礎をコツコツ学び続けること。 AIは「簡単さ（Easy）」を極限まで高めたが、システムを「シンプル（Simple）」にしてはくれない。複雑性を切り分け制御できるのは、ドメインや技術を深く理解している人間の役割である。 「1人でAIと爆速開発」というリソース効率の罠から抜け出し、モブプログラミングや Agent Skills による「チームでの意思決定と暗黙知の言語化」へ向かう。 AIエージェントとの関わり方：物的生産性から離れ、対象物を深く理解する カンファレンスでハッとさせられたのは、和田卓人氏の「 AIによる物的生産性に血眼になっているのではないか？ 」という問いかけでした。 AIによってコードの記述スピードは劇的に上がりましたが、だからこそ「誰もいらないものを高速に作っても意味がない」状態になっています。和田氏は講演の中で、AIの登場によってプロトタイプを用いた価値の検証が容易になり、「 価値探索とプログラミングがかなり紐づいてきた 」と語っていました。コードを速く書くことではなく、対象物を深く理解し「何を作るか」を探索することに、エンジニアの主眼は移りつつあります。 この「 スピード（簡単さ）に溺れず、理解を優先する 」という姿勢の重要性は、世界的なソフトウェアエンジニアリングの潮流とも完全に一致しています。Netflix のエンジニア Jake Nations 氏による講演「 The Infinite Software Crisis 」では、次のように指摘されていました。 簡単（Easy）はシンプル（Simple）を意味しない。簡単とはシステムに素早く追加できることであり、シンプルとは自分のやった仕事を理解できることだ。簡単を選ぶたびに、私たちは「今のスピード」と引き換えに「後々の複雑さ」を選んでいる。AIは簡単さを極限まで高めたが、シンプルさを生み出すわけではない。 何を作るかを理解し設計することの難しさは、どのツールも排除できません。 また、「 Software Fundamentals Matter More Than Ever 」という講演でも、次のように語られていました。 「コードは安い」という言説は誤りである。悪いコードは今まで以上にコストが高い。変更しにくいコードベースは AI の恩恵を受けられない。 これは私が4ヶ月前に書いた記事でも触れた DORA レポートの「AI は増幅機」という主張と重なります。良いコードベースであるほど恩恵を受けやすく、悪いコードベースであるほど機能不全が拡大する。基礎の重要性は、AI 登場後にむしろ高まっています。 この点について、『ソフトウェアエンジニアガイドブック』（Gergely Orosz 著）の日本語版特別付録インタビュー（p.557）でも、次のように語られていました。 「問題は、経験の少ないエンジニアがAIに『主導権を握らせ』、AIが何をしているのか理解しないまま仕事を全部任せてみたくなるように誘惑されることです。したがって、『AIと共に学び続け、思考をAIに外注しないエンジニア』への需要は増加するものの、その供給はおそらく減少します！奇妙な時代が訪れることでしょう」 理解を放棄してAIに主導権を渡さない姿勢こそが、これからのエンジニアの価値を左右しそうです。 では、AIに主導権を渡さず、自分たちの理解を保ちながら開発するにはどうすればいいのか？  その具体的な対策として和田氏が推奨していたのが、 Test First でやる場所と、Red-Green-Refactor のように小さなサイクルで回す場所を分ける  ことでした。 エージェントに任せても良いと判断した領域では、ざっくりとした Test First で問題ない。一方で、人間がリアルタイムにレビューして品質を担保したい領域では、Diff（差分）の小さい TDD のステップを強制する方がよい。これは、人間が何千行ものファイルを一気にレビューして理解するのは現実的ではないからです。 AIの爆速な出力に流されず、人間の認知負荷を意図的に下げるために、理解できる範囲に留める仕組みとして、非常に納得感がありました。 開発速度の見直し：モブプログラミングの再評価とリソース効率の罠 AIの登場により、コーディング工程は劇的に短縮されたように感じる場面が多くなったのではないでしょうか。しかし、Tech Lead Conference 2026 でのSansan株式会社（笹川裕人氏）のセッションでも指摘されていたように、開発プロセス全体のボトルネックは「コーディング」から「レビューやテスト」へと移動しています。 かつてGitHubが普及した頃、「1人1ブランチで開発できる＝リソース効率100%」という発想が、プルリクのレビュー待ちというボトルネックを生みました。今、「コーディングエージェントをN列並列で動かす」という発想も、全く同じパターンにはまる危険性があります。 真のボトルネックは、コードを書くことではなく、人間側の判断・レビュー能力です 。 この点について、和田卓人氏は別の対談動画（ AI疲れとジュニアエンジニア育成、モブプログラミングの役割 ）で、次のように語っています。 コーディングエージェントによって、実行責任はエージェントへ、説明責任・品質保証は人間へ、という役割分担になっていく。テックリードが担っていた判断の負荷が全員に降りてきた。 AIが多様な要求に対して提案を返してくる中で、その判断を一人で全部こなすのは現実的ではありません。そこで和田氏が推奨していたのが、 モブプロの実施 です。 AI によってコード生成は十分に速くなっていたとしたら、人間はペアやモブを組む余裕があるはずです。複数人でエージェントと関わり、即時に判断していく。この判断を複数人ですることで、知識移転（教育）も行える可能性について言及していました。 そして、この「リソース効率からフロー効率への転換」と「教育」の重要性は、別の動画（ シニアのゲームに巻き込まれるな ）でも触れられています。 「AIで1日のプルリク量が何倍に」「数日で個人開発アプリを完成」という SNS 投稿に踊らされてはいけない。シニアには元々の積み上げがあるため同じ土俵では勝てない、という主張は、私としては耳が痛い話でした。 圧倒的な積み上げがあるシニアエンジニアと同じ土俵で戦おうとすれば、経験の少ないエンジニアは疲弊し、学びの機会を失います。私も、特に言われたわけではないですが、物的生産性にとらわれて、AIにコード生成させたりレビューさせて、そのまま使うみたいなことがありました。これを、意図的にやっているというより、誰からも要求されていないのに、無理して成果を出そうとしていたなと反省しています。物的生産性を多少下げてでもモブプログラミングの場にジュニアを巻き込み、「チームとしての判断力」と「教育」を両立する構造を作ることが、AI時代には不可欠ではないかと考えています。 開発プロセス：変わらないものと、Agent Skills による専門知識の言語化 AI時代になっても、チーム開発のプロセス全てがひっくり返るわけではありません。Sansan株式会社（笹川裕人氏）のセッションでも、「スクラム等のプロセスの本質（経験的に起きる課題への対処法）は変わらない」とはっきり言語化されていました。 一方で大きく変わるのは、AIという新しいメンバーへの指示の出し方です。合同会社Have Fun Tech代表の曽根武友氏は、「 AI時代における具体と抽象の往復 - 日常にチャンスがある 」というセッションの中で次のように語っていました。 AIへの指示も、結局は人間同士のコミュニケーションと同じ原理。「いい感じにして」が伝わらないのは、プロンプトの抽象度と相手（AI）の抽象度が一致していないから。 具体化には知識が必要であり、相手のドメインで話すにはそのドメインの知識が要る。 この「『いい感じに』という抽象的な指示を具体的な手順に変換するための知識」の重要性は、Anthropicの講演「 Don't Build Agents, Build Skills Instead 」でも強く主張されています。エージェントという曖昧な存在にすべてを丸投げするのではなく、特定のタスクを遂行するための「Skills（専門知識のパッケージ）」を構築すべきだというのです。 AIに的確な指示を出すための「Agent Skills」の整備は、単なるツールの設定ではありません。 チーム内の暗黙知を言語化し、共有知にしていくプロセスそのもの なのです。 国内の企業では、すでにこの「個人の暗黙知から組織の共有知へ」という取り組みが始まっています。 株式会社タイミーでは、「 Agent Harness Group 」という組織を立ち上げ、「個のAI活用」から「組織のAI駆動開発（AI-DLC）実践」へと協業を推進しています。また株式会社LayerXでは、モバイルチームで「 Claude Code Subagents祭 」と題した社内イベントを開催し、属人化しがちなAIへの指示やプロンプトをチームの共有知へと昇華させています。 私自身が推進しているAIエージェント活用においても、ここが最大のポイントになると感じました。単にAIツールを導入するだけで終わらせるのではなく、 Agent Skillsという機能を、AIというメンバーに暗黙知を伝える手段や、組織のベストプラクティスを誰もが簡単に再現できる方法として利用するための仕組みを作っていきたい と考えています。それこそが、AI時代における組織の長期的な競争力の源泉になるはずです。 学習：焦らず、理解を放置しない AIエージェントがコードを爆速で生成してくれる時代において、私たちが個人として取り組むべき最も重要なアクションは、「分からないところを放っておかない」という基本的な学習姿勢です。 Tech Lead Conference 2026でのセッションを通じて、登壇者三者の主張が見事に一致していたのが、この「継続的な学習の重要性」でした。和田卓人氏は、学習について次のように語っていました。 新人は、焦らずに学んでいく必要がある。自分がわからないところを放っておかずにやっていく必要がある。質を下げればスピードが上がるわけではない。トレードオフなのは教育である。質とスピードを担保させるために、教育することが必要になる。 曽根武友氏も、AI が発展しても変わらないこととして「 抽象と具体の往復スキル、ドメイン知識、継続的な学習 」を挙げていました。仕事の形は変われど、この往復の精度を上げることが本質である、と。 さらに、Sansan株式会社 のセッションでも、エンジニアのキャリアパスについて語られていたところで、「 仕事の総量は変わらない——AI で効率化されても別の仕事が生まれる。継続的な学習の必要性は変わらない 」という言葉がありました。この三者の主張は完全に一致しています。 『良いコード／悪いコードで学ぶ設計入門』の著者であるミノ駆動氏も、AI時代に漠然とした不安を抱えるエンジニアに対して、動画（ AI時代に“伸びる人・終わる人”の決定的な差 ）で次のように指摘しています。 漠然と不安に思っている人は、技術を学んでスキルアップすることが不安の解消に繋がっていると思えていないのではないか。不安を覚えるのなら勉強しましょう。 ミノ駆動氏は、AIは「ネット上の学習内容の平均」に収束する傾向があるため、設計的に問題のある構造でも技術知識がなければ素通りしてしまうと語っています。 AIが60〜70点のものしか出せないのは、指示する人間の基礎力（問題を見抜く力）が足りていないから でもあるのです。 また、ファインディ株式会社の高橋氏の動画（ ジュニア育成と組織学習 ）では、AI時代のエンジニア評価について、次のような組織側の変化が語られていました。 機能を何個作ったかっていうよりも、何を学んだかをアピールする時代になってきている。 これは個人の姿勢だけでなく、組織側にも問われることです。アウトプットの量だけを評価指標にすると、生成AIでいくらでも量産できてしまい、本当の力が見えなくなります。「何を学んだか」を評価し、基礎力を高め続ける仕組みを持っているかが、これからの人材育成の分かれ目になります。 最後に、和田卓人氏が別の対談動画の結びで語った、若手エンジニアに向けた言葉を引用します。 自分の能力をコツコツ上げていくことが、自分の競争力を上げていくことにそのままより大きく繋がる時代になってきたと思ってください。…（中略）… 焦らずにコツコツやっていけばいい。希望を持つ上でのコツは、人と比べないことです。比べるのは過去の自分です。 SNSを見れば、AIを使って爆速で開発している人がいくらでも目に入ります。しかし、そこで焦って理解を放棄するのではなく、自分の分からないところを放置せずにコツコツと基礎を積み上げていく。それこそが、AI時代を生き抜くための最強の生存戦略なのだと、改めて心に刻みたいと思います。 まとめ：教育とフロー効率を両立する3つの方向性 4つの観点を通じて感じたのは、ひとつの共通したメッセージでした。 AI は「理解の代替」ではなく「理解の加速器」として使う。 そのために、私たちが明日から取れる具体的なアクションは、以下の3つに整理できると考えています。 1. 物的生産性に流されず、対象への「理解」を深める姿勢と仕組み化 AIによる爆速なコード生成に流されず、「自分が理解できないもの」を放置しないことが第一歩です。分からない概念があればAIに説明させて基礎をコツコツ積み上げる「個人の学習姿勢」を持つと同時に、Test First でざっくり任せる領域と、Diffの小さいTDDのサイクルで回す領域を分け、人間の認知負荷を意図的に下げる「開発の仕組み」を取り入れること。アウトプットの量ではなく、「何を学び、どう理解したか」を重視する姿勢が問われます。 2. モブプログラミングによる判断とレビューの分散 一人がエージェントと対話して爆速で開発するリソース効率の罠から抜け出し、複数人のチームで専門性を持ち寄りながら判断するモデルへ。チームにジュニアが参加することで意思決定の OJT にもなる——教育とフロー効率の両立策として、今後試していきたい方法論です。 3. Agent Skills による組織のベストプラクティスの再現 「いい感じに」という抽象的な指示を具体的な手順に変換する Agent Skills は、単なるツールの設定ではありません。 チームのベストプラクティスを「AIという新しいメンバー」に伝える手段 として捉え直す必要があります。 実際に、株式会社タイミー では「 Agent Harness Group 」を立ち上げて AI との協業を組織的に推進していますし、株式会社LayerX では「 SubAgent 勉強会 」という知識共有の場を作っています。誰もが組織のベストプラクティスを簡単に再現できる仕組みを、社内でも作っていきたいと考えています。 おわりに AI にとってかわられる恐怖よりも、学ぶべきことの多さに恐怖している——というのは、裏返せば「学べば学ぶほど武器になる」ということでもあります。Tech Lead Conference 2026 で登壇者たちが口を揃えて言っていたのは、「 基礎知識を持つ人間がこれまで以上に価値を持つ 」ということでした。 特に4年目という、中途半端な立ち位置にいる自分にとって、和田卓人氏の「焦らずコツコツ自分の能力を上げていけば、それがそのまま競争力につながる時代になってきた」という言葉は、強い励みになりました。 焦らず、分からないところを放っておかず、基礎をコツコツ積み上げていく。その上で、AI を理解の加速器として使う。それがAI時代にエンジニアとして今後も活躍するための必要な考えかもしれません。 最後まで読んでいただきありがとうございました。