はじめに
今回はこれからのエンジニアの学習について、私の考えをまとめてみたいと思います。
これまで、組み込み、単体テストから始まり、Laravelを中心としたバックエンド、フロントエンドはSPA中心に触れてきたキャリアでしたが、生成AIの登場により、同じように学習し続けても、これまでのようにキャリアを積むことが難しくなってきたと感じています。
これからは、生成AIを活用しながら、より効率的に学習することが求められる時代になってきました。特に自分の得意領域をより伸ばすこと、その周辺領域の知識もある程度キャッチアップして技術の幅を広げることが重要だと考えています。その上で事業ドメインを中心に活動していかないと、単なる技術だけの領域を担当しているエンジニアは後数年で仕事を失う可能性があると感じています。実際には社会に浸透するまでに時間がかかると思いますが、今後のキャリアを考える上で、生成AIの登場は大きな転換点になると考えています。
現在の現場での実装と理解の両立のはたん
生成AIにある程度実装を任せられるようになって、学習について考え始めました。
AIで開発する中で、成果物の完成と、自分が理解したことを分けて考える必要を感じる場面が度々登場します。ほとんどの場合はAIに適切にゴールを設定することができれば、任せることができるのですが、ゴールの設定や成果物の妥当性の判断が徐々に難しくなってきています。
これまでは実装・調査・デバッグの途中で得ていた経験値が、AIに任せることで得られなくなってきているのです。実装の過程で得られる経験値は、理解を深める上で非常に重要です。理解が浅いまま実装を進めると、成果物の妥当性を判断することが難しくなり、結果として不具合や設計の問題に気づかずにリリースしてしまう可能性があります。
また、個人の学習と、チームで人を育てることの両方を考える必要が出てきます。
個人の学習についてはある程度簡単な部分があります。自分自身が一番簡単に変えられます。自分自身の学習のために、AIを活用しながら、理解を深めるための学習方法を考えることができます。
自分自身の学習の方向性として意識していくことは、これからも自分の中に持っておきたい知識は何か、ということです。おそらく現在存在するほとんどの知識はAIの方が詳しく、学習する意味を感じなくなるかもしれませんが、職業エンジニアとしては結局要求を具体化するための業務・ドメイン知識や出力の妥当性を判断するための設計、データ、認証、並行処理などの基礎、そして、失敗したときに仮説を立て、切り分けるための知識は、AIに任せることができない部分です。これらの知識は、AIを活用する上で必要な知識であり、今後も自分の中に持っておく必要があると考えています。
また、アーキテクチャ的な部分の意思決定の結果はエンジニアが責任を持つ形が当面の間は続くのではないかと考えています。特に採用した理由と、採用しなかった選択肢を説明する力という部分で技術に対しての理解、説明責任という部分の仕事は数年は残りそうです「AIに聞けば分かる」で済ませられる範囲と、質問や検証のために頭に必要な範囲を分けて考える必要があります。
自分自身もそうですが、チームで人を育てることは、個人の学習よりも難しいです。個人の学習は自分自身の意思で進めることができますが、チームで人を育てる場合は、相手の理解度や学習速度に合わせて、適切な課題を与えたり、フィードバックを行ったりする必要があります。さらに、AIを活用することで、個人の学習と同様に、チームでの学習も効率化できる可能性があります。
例えば、作れることと、理解していることをどう見分けるか、というテーマがあります。
これについては同じ題材で、理解の深さを具体化する必要がありそうです。
例：OAuthの認証フローを実装した場合- フローを自分の言葉で説明できるか
- stateとPKCEが、それぞれ何を防ぐか説明できるか
- 条件が変わったときに設計を変えられるか
- 不具合の原因を予想し、確かめる方法を考えられるか
実装の完了に加えてこれらについて検討、理解、議論できるような基礎知識の理解が必要です。実装の完了だけでは、理解の深さを測ることはできません。
また、学ぶ側と教える側の両方の立場で、AIを活用しながら学習することが重要です。
学ぶ側：AIを使いながら、自分で考える工程を残す
何を説明できるようになりたいか、目標を決める必要があります。
- 資料を読み、まず自分の説明や仮説を書く
- AIに誤り・根拠不足・説明の抜けを指摘してもらう
- 一次資料へ戻り、自分の言葉で修正する
- 別の例や小さな実装で、理解が使えるか試す 常にこの手順を強制するのでなく、初めて学ぶ領域など、理解を育てたい場面で使う。
教える側：完成したコードに加えて、判断の過程を見る- 課題には「作るもの」と「学んでほしいこと」を別々に書く
- レビューで、設計理由・代替案・壊れる条件を聞く
- 障害調査、仕様変更、設計比較など、判断が表に出る課題を用意する
- AIのフィードバックと、先輩が持つ業務上の判断基準を組み合わせる
- 既習の作業はAIで進め、新しく身につけたい部分では本人に説明・検証してもらう 新人のAI利用を一律に制限する話にせず、学習目標に応じて使い方を設計する話にする。
こうした学習を支える仕組みとしてKakudoという自作アプリを週末でちまちま作っています。
自分がエンジニアとしてのキャリアの転換点や迷った時に参考にしていたDeveloper Roadmaps - roadmap.shを元に、教える側として実際にブログなどの形で残せるものが欲しいなと感じていました。
また、後から見返した時にも学習マップ：知識のつながりと目標を見えるようにするようなものとして活用ができるようにしたいと考えています。
- Markdown：自分の理解を言葉にする
- 引用・出典：自分の説明と他者の根拠を区別する
- AIレビュー：ファクト・論理・目標に対する抜けを確認する
- 本文生成を持たせない理由：自分で説明する工程を残したいから ここは機能紹介を短くして、「どんな学び方を支えたいか」を中心に。学習効果が実証できたとは書かず、実際に使って確かめたい仮説として扱う。
これまではroadmap.shを確認して関連書籍を数冊読んで次の領域に移っていましたが、これからはより一層自分自身で文章にまとめ、理解の深さを確認していくことが、自分自身の成長のためにも、他人に何かを教えるためにも重要だと考えています。
楽をしようと思えばいくらでもできる時代に、自分自身のために負荷をかけて理解度を上げていく作業から逃げないことが、これからのエンジニアとしての成長に必要だと考えています。
まとめ
自動化が進むほど、学習の機会を意識して作る必要があります。
業務を速く進めることと、人が成長する機会の両立はこれまで通りのフローでは難しくなってきました。レビュワー、レビュイー共に学習の機会を意識して、学習のための課題やフィードバックを設計する必要があります。
- 個人は理解を確かめる習慣を持ち、組織は判断を経験できる課題とフィードバックを用意する
- 自分でもKakudoのようなツールを作って使い、そのやり方を検証していく
