AIコーディングツールなどの進化で開発の在り方が大きく変化する中、新卒や実務経験が1～3年ほどのジュニアエンジニアの育成をどのようにアップデートすべきか、明確な答えを持てずにいる方も多いのではないでしょうか。本記事では、開発組織を率いながらAI活用を進めてきたクラシル株式会社 執行役員CTOの大竹雅登さん（@masatootake）に、AI時代のジュニアエンジニア育成で重視している考え方や軸、同社の取り組みについて解説いただきました。
AIが一般に広く普及するきっかけとなったChatGPTの登場から、まだわずか3年です。この短期間で、AI以前の開発手法を思い出すのが難しいほど、エンジニアリングの在り方は劇的に変化しました。Claude CodeやCursor、DevinといったAIコーディングツールの台頭により、「近い将来、特にジュニアレベルのエンジニアは不要になるのではないか」という声も耳にするようになりました。
しかし、実際にはその逆だと私は考えています。新しいパラダイムに柔軟に適応できる若手エンジニアこそ、これまで以上に大きな影響力を発揮して活躍の場を広げていくと考えています。クラシルでは2026年入社から新卒エンジニアの採用をこれまで以上に強化しており、今後も安定的に採用数を増やしていく計画です。
AIがコードを書く時代に、あえて若手エンジニアの採用・育成に投資する理由は、ソフトウェアエンジニアリングそのものに「パラダイムシフト」が起こっているからです。AIという武器を積極的に活用し、最も速く、抵抗なく吸収するには、むしろ若手の方がチャンスがあると思っています。
パラダイムシフトはクラウドの普及時にも起きていた
「テクノロジーがエンジニアの役割を変える」という現象は、歴史を振り返ると今回のAIが初めてではありません。ちょうどクラシルを創業した2014年頃は、AWSをはじめとする「クラウド」が実用的になりつつあったタイミングで、大きな転換期でした。
AWSが登場する以前、Webサービスを作るにはオンプレミスでサーバーを契約し、ミドルウェアの設定まで含めた複雑なインフラを構築するスキルが必須でした。それがクラウドの登場により、すべてがAPI経由で完結するようになり、少人数のスタートアップでも大規模なサービスを迅速に立ち上げることが可能になりました。
実際に、レシピ動画サービス「クラシル」の立ち上げ期、エンジニアは自分一人しかいない状況でしたが、AWSのフルマネージドサービスを活用することで、サーバー構築や動画変換処理などの重たいタスクも含めて最速でプロダクトローンチまで到達することができました。
テクノロジーの進化は、常に「少人数で成し遂げられることの規模」を拡張してきた歴史なのです。そして、AIはおそらくクラウドよりも圧倒的に大きな波であることは間違いないでしょう。
「AIありき」の開発をゼロベースで吸収する力が強みになる
ここで重要なことは、当時クラウドへのパラダイムシフトに最も早く適応できたのは、オンプレミス環境を触ったことすらないような若手エンジニアや創業初期のスタートアップだったという事実です。当時学生起業だったクラシルも含めて、経験がないからこそ従来のやり方に縛られずに、積極的にAWS上にサービスを構築していきました。
現在のAI活用においても、全く同じことが起こっていると感じます。
すでに自分なりの開発手法を確立しているシニア層の中には、AIを前提とした開発パラダイムへとシフトすることに、少なからず心理的な抵抗を感じる人もいます（もちろん、例外は多くあります）。
一方で、私が最近の学生エンジニアの方々と接していると、もはや完全に「AIありき」の開発手法が当たり前になっており、新技術のキャッチアップスピードも非常に速いです。中途採用で出会うミドル〜シニア層の方々と比較しても引けを取らないどころか、むしろ学生の方がキャッチアップが早いとすら感じます。
このように、「新しいソフトウェアエンジニアリングのお作法」をゼロベースで、最短距離で吸収できることが若手の強みです。 このAIネイティブな感性を組織に取り入れ、開発の在り方をアップデートし続けること。それが、クラシルが新卒をはじめとする若手エンジニアを積極的に採用している大きな理由の一つです。
クラシルの開発チームでも当然、Claude CodeやCursor、DevinをはじめとするAIツールの利用を全開発メンバーに推奨しています。AIツールは使用料金が高くなることもありますが、クラシルでは1人当たり月額10万円まで利用可能にする「AI First」制度を導入し、日々変化するAIツールにキャッチアップできる環境を作っています。
AI時代にこそ「伝統的なソフトウェアエンジニアリング」の重要性が高まる
AIは人間と比べ物にならないスピードでコードを生成しますが、同時に「負債」を高速に生み出すリスクもあります。何も意識せずにAIに任せきりにすれば、これまでの数倍早いタイミングで技術的負債が溜まります。
イメージとしては、Vibe Codingで実装を全く読まずにauto-acceptする形で開発してみると、最初はスピーディーにそれっぽいものが出来上がりますが、細かい部分を詰めていく段階で上手くいかなくなる現象です。
ここで逆説的に重要性が増すのが、AI以前からある「伝統的なソフトウェアエンジニアリング」のスキルです。時間が経っても保守運用しやすいコードベースを維持するために、コーディング規約の順守、コードレビュー体制の運用、ドキュメントの整備、CI/CDの構築、テストの自動化といった基本を徹底する重要性が、これまで以上に高まっています。
さらに昨今は、AIによる高速な開発を支えるための周辺ツール（例：型バリデーション、テストフレームワーク等）も急速に発展しています。これらの新しい技術を素早く取り入れ、AIの実装スピードの速さとコード品質を両立するノウハウも吸収していく必要があります。
この辺りのスキルは、実務経験が多い分だけにシニア層が当然長けているでしょう。若手エンジニアはAIを徹底的に使い倒すのと同時に、伝統的なソフトウェアエンジニアリングもしっかり学んで身につけるべきだと思います。
AI任せの責任放棄には注意。チーム全体の生産性はかえって低くなる
若手エンジニアが肝に銘じておくべきなのは、AIが書こうが人間が書こうが、コードの最終責任は常に人間にあるというスタンスです。
AIを使えば、大量のプルリクエスト（PR）を出すこと自体は容易です。しかし、中身を十分に理解していない品質の低いPRを乱発すれば、それを受けるレビュアー（主にシニアエンジニア）の負担が大幅に増えてしまい、チーム全体の生産性はむしろ著しく低下することになります。
この問題を未然に防ぐため、クラシルでは「AI開発における品質の方針」というドキュメントを開発ポリシーとして全社展開しています。見かけ上のアウトプット数が増加する一方で、チーム全体の生産性が低下してしまう事態を避けるためのものです。
レビューで「なぜこの実装にしたのか？」と問われた際、「AIが出力したから」と答えるのは責任放棄であり、ググったコードを意味も分からずコピーアンドペーストするのと同義です。もっと言えば、そのような仕事しかしないのであれば、それこそ若手エンジニアではなくAIで代替できてしまいます。
AIを駆使して高速で実装しつつも、それがチームとしてのコーディング規約に沿っているか、長期的な保守に耐えうる設計なのかを本人がプライドを持ってセルフレビューを行い、品質を担保する。こうした姿勢を常に持っていないと、AI時代においてサバイブするのは難しくなると思います。
開発プロセスにおける「職種の壁」がなくなっていく
AIの進化により、エンジニア以外の職種も開発プロセスにより深く、直接的に関与できるようになっています。クラシルにおける象徴的な事例が、自律型AIエンジニア「Devin」の活用です。
Devinが提供する「Devin Search」は、単なる文字列検索ではなく、検索の背景や意図をAIが理解した上で、リポジトリを横断して関連情報を提示してくれる機能です。
曖昧なキーワードでも意図に即した回答が得られるため、プロダクトマネージャー（PdM）などの非エンジニアが、システム挙動の仕様確認やログの発火条件の調査などをエンジニアに依頼することなく自己解決できるようになりました。
クラシルでは、Slackbot経由でカジュアルにDevinへ問い合わせられる環境を構築しています。実際のデータを見ると、Devinの利用量が多い社員トップ10のうち、半分以上がPdMなどの非エンジニアという結果が出ています。
また、最近注力しているのは、クラウドデータ基盤のSnowflakeの「Snowflake Intelligence」を活用し、SQLを書かずとも自然言語でユーザー行動分析を完結させるAI環境の構築です。2026年1月現在はまだPoCフェーズですが、これが実用レベルになれば、非エンジニアが自ら試行錯誤してデータを深掘りできるようになり、仮説検証のサイクルが圧倒的に加速すると考えています。
このような変化に伴い、「言われたものを作るだけ」のエンジニアの価値は相対的に低下していきます。他職種と円滑にコミュニケーションを取りながら、エンジニア自身も事業成長のために何が必要かを考え、主体的に動く姿勢がこれまで以上に重要になっています。
単純なコーディングの代わりに求められるのは、「3方向の理解」
指示された仕様通りに実装する「単純なコーディング」のコストは、AIによって限りなくゼロに近づいていきます。この前提において、エンジニアが出せる付加価値は「何を作るべきかを考える」というレイヤーにシフトしていきます。
- この機能は、ユーザーのどんな負（不満や不便）を解決するのか？
- この施策は、事業のKPIをどう動かすのか？
- プロダクトとして、どのような体験を届けるのが正解なのか？
こうした「事業理解」「プロダクト理解」「ユーザー理解」を深め、仕様の決定プロセスから主体的に関与できることが、これからのエンジニアに求められるコアスキルです。いかにして「事業インパクト」というアウトカムを作れるかという、より上位のレイヤーで価値を発揮することが求められます。
この方向性に基づき、クラシルのチーム編成はエンジニア、デザイナー、PdM、マーケター、セールスなどが職種を横断する「スクラム体制」を基本としています。各スクラムには一つの事業KPIが設定され、多様な職種のメンバーが互いの領域を越境しながら、スピーディーに事業を推進しています。
この体制では、エンジニアは単にコードを書くだけでなく、ユーザーインタビューやデータ分析、セールスチームとの業務改善などにも臨機応変に取り組むため、自然と「何を作るべきか」という視点を持てるようになります。
アウトプットではなく「アウトカム」にコミットできるエンジニアに
AIは強力な武器ですが、それを使って何を作るか、どのような価値を生み出すかを決めるのは人間です。
AIによって「コードを書く」という作業のハードルが下がった今、エンジニアはいかに事業に貢献し、ユーザーに価値を届けたかという「アウトカム」を出すことにコミットするべきです。
若手エンジニアとしては、まずAIを徹底的に使い倒す開発手法を当たり前のものとして習得すると同時に、伝統的なソフトウェアエンジニアリングのスキルや経験も身につけて「技術力の土台」を鍛えましょう。
その上で、仕様に沿ってただ実装するだけの存在ではなく、「どうすれば事業が伸びるか」「どうすればユーザーに価値を届けられるか」という視点を持って貢献できるようになってほしいと思います。
事業への貢献を愚直に突き詰め、プロダクトに向き合い続ければ、将来的な「PdM（プロダクトの戦略を決める）」「EM（開発組織をつくる）」「テックリード（技術力をより尖らせて価値発揮する）」など、どのキャリアパスにも自然につながります。
実際にクラシルにおいても、こうした視点を持ち、開発の枠を超えて事業貢献にコミットしたメンバーが、それぞれのキャリアパスで大活躍しています。
例えば、クラシルにはエンジニア出身のPdMが数多く在籍しています。彼らはシステムの制約を深く理解しているため、事業的な検証事項に対しても「どこに複雑性を寄せれば、技術負債を抑えつつ最速で開発できるか」を解像度高く判断することが可能です。こうした専門的なバックグラウンドを生かしてコミュニケーションを行うことで、チーム全体の推進力はさらに加速していきます。
何よりも、変化の激しい時代において、AIの新しいパラダイムを楽しめる人が一番活躍していくと思います。テクノロジーの進化を誰よりも楽しみ、世の中に大きなインパクトを与えていきましょう。
