■ 1. 48年間の開発環境の変化
- 自身の経歴:
- 1978年4月にプログラミングを学び始め、48年以上ソフトウェア開発に携わり現在も続けている
- 生成AIによる今回の変化は、これまで経験してきた変化とは少し違う
- 技術書とマニュアルの時代:
- インターネットがなく、分からなければ技術書やマニュアルを調べ、自分で考えて試すしかなかった
- IDEはなく、エディタで書きコンパイラでコンパイルしていた
- 80文字×24行しか表示できない端末で開発していた時代もある
- 現在は複数ウィンドウでソースコード、ドキュメント、ブラウザ、ターミナルを同時に表示するのが当たり前
- インターネットの普及:
- 手元の書籍や周囲の詳しい人に頼っていた情報を、世界中から探せるようになった
- 検索エンジンでエラーメッセージを検索すれば、同じ問題に遭遇した人の情報が見つかるようになった
- 技術情報サイトやQ&Aサイトの登場で、情報を得る時間は大幅に短縮された
- それでも見つけた情報を理解し、自分の問題への適用可否を判断する必要があった
- 設計、コーディング、動作確認は自分で行い、ソフトウェアを作る主体はあくまで人間だった
- 開発支援ツールとプロセスの進歩:
- エディタとコンパイラからIDEへ移行した
- コード補完、ソース間移動、リファクタリング、デバッガで開発効率が大きく向上した
- ビッグバンインテグレーションから継続的インテグレーションへ変わった
- 現在はCI/CDでビルド、テスト、デプロイを継続的に行うのが当たり前
- 新しい道具や手法が登場するたびに、開発は速く効率的になってきた
■ 2. 生成AIはこれまでの道具と何が違うか
- 生成AIによる生産性向上:
- 生産性が大きく向上することにはあまり疑問を持っていない
- 仕様を伝えればコードを書き、テストも書かせられる
- エラーの原因調査と修正を任せられる
- 既存コードを読ませて変更箇所を探させられる
- これまでの道具の性質:
- インターネットで情報を得ても、理解して自分の問題に適用するのは人間だった
- IDEが補完しても、何を作りどう設計するかは人間が考える必要があった
- CI/CDで自動化しても、何を実装し何をテストするかを考えるのは人間だった
- 多くの道具は「人間が考え、人間がソフトウェアを作る作業を支援するもの」だった
- 生成AIの性質:
- 人間の知的作業そのものをAIに任せられる
- 設計、コーディング、テスト、エラー原因の調査、修正方法の検討を任せられる
- 「考えて、作って、失敗して、直す」過程のかなりの部分をAIに任せられるようになりつつある
■ 3. 仕様から実装までの時間と経験の差
- 従来の仕様から実装までの過程:
- 設計を考え、技術を調べ、コードを書き、コンパイルしてテストする
- 思い通りに動かなければ原因を調べて修正する
- 経験による生産性の差:
- 経験あるエンジニアは、設計、ライブラリ選定、エラー原因の判断を素早くでき、時間を短縮できる
- 経験の少ないエンジニアは、調べ、試し、間違え、やり直しながら実装する
- 同じ仕様から同じ機能を作っても、経験や知識で生産性に大きな差があった
- AIによる時間の短縮:
- 経験差で生じていた仕様から実装までの時間を、AIで大幅に短縮できる
- これは経験の少ないエンジニアにとって大きな助けになる
- ただし若手とベテランの生産性の差が縮まるとは限らず、別のところで差が広がる可能性もある
■ 4. ベテランの経験を増幅するAI
- AIの生成物を評価する力:
- 経験あるエンジニアは、動くとしてもこの設計にはしたくないと判断できる
- エラー処理の不十分さやテストの重要ケースの欠落に気づける
- 今は問題なくても将来変更が難しくなる作りを見抜ける
- 問題を見つければAIに修正させられる
- 実装速度の制約の解消:
- これまでは適切な設計を思いついても、人間のコーディング速度の限界で実装に時間がかかった
- AIはその制約を大きく取り除く
- 経験や知識を持つエンジニアが、それをAIで高速にソフトウェアへ変換できるようになる
- AIの二面性:
- 経験の少ない人を助ける道具であると同時に、経験ある人の能力を増幅する道具でもある
■ 5. 経験はどう身につくのか
- 経験の形成過程:
- 知識や判断力のうち、本から学んだものと仕事で身についたものはきれいに分けられない
- 設計し、コードを書き、失敗し、デバッグし、書き直す
- 分からないことを調べ、よいと思ったコードをレビューで指摘される
- 本番環境で思いもしなかった問題が起きる
- 新しい技術を学び、実際に使ってみる
- 過去の設計判断の正否を何年も経ってから知る
- これを48年以上繰り返した積み重ねが現在の判断力を形成している
- AIによる経験獲得機会の省略:
- AIはこの過程のかなりの部分を省略し、生産性の観点では素晴らしい
- しかし省略される過程には、経験を獲得してきた機会も含まれている
- 何時間も調べたり、バグの原因を自分で突き止めたりする必要はなくなっていく
- 省略した試行錯誤に、将来の判断に必要な経験が含まれていなかったとは言い切れない
- 仕事を続けても育つとは限らない:
- 従来は自分で実装しなければ仕事が終わらず、長く続ければ経験は自然に蓄積された
- AIが代行すると「仕事を長く続けることと、経験を積むことが、以前ほど同じではなくなる」可能性がある
- AIで10年開発したエンジニアが、AI以前に10年開発したエンジニアと同じ種類の経験を持つとは限らない
■ 6. AIを使いながら経験を得る方法
- AIを使わない修行の否定:
- 優れた道具を意図的に使わせないことがよい育成方法だとは思えない
- これからのエンジニアにはAIを使って開発する能力そのものが必要
- 問題は使うか否かではなく「AIを使いながら、どうやって経験を獲得するか」
- 教師としてのAI:
- AIをコード生成の道具ではなく学習の道具として使える
- 設計の理由、代替案、コードの問題点、他の方法との長所と短所を問える
- 設計が将来問題になるケースを問える
- 自分で考えた設計をAIに批判させられる
- 従来は経験豊富なエンジニアが近くにいなければ得られなかった助言を、いつでも得られる可能性がある
- 使い方次第で、AIは学習を加速する道具になり得る
- 短縮できない「時間の経験」:
- 以前「AIがコードを書く時代でも、エンジニアの熟達は早くならないのではないか」という記事を書いた
- 実際に時間が経過しなければ得られない経験がある
- よいと思った設計が数年後に変更を難しくする
- 利用者が増えて初めて性能問題が現れる
- 何年も機能追加を繰り返して初めて設計上の問題が表面化する
- 障害が発生して初めて運用設計の問題に気づく
- AIは他者の類似事例を教えられるが、自分の判断の結果を数年後に自ら経験することは高速化できない
■ 7. 次世代のベテラン像
- 問いの立て方の見直し:
- 現在のベテランと同じエンジニアをどう育てるかと考えること自体が間違っているのかもしれない
- AI時代のベテランは、現在とは違う経験や能力を持つ人になる可能性がある
- 新しい熟達の構成要素:
- 大量のコードを書いた経験ではなく、AIが生成した大量のコードや設計を評価してきた経験
- 実装方法の記憶ではなく、何を作るべきかを考えAIへ正確に伝える能力
- 生成されたものが本当に正しいかを判断する能力
- AIの答えをそのまま受け入れず「何かおかしい」と気づく能力
- 現在のベテランの特殊性:
- AIがない時代に長い時間をかけて経験を積み、その状態でAIを使える
- 「長年蓄積した経験 × AI」という組み合わせを持つ
- AIの生成物を経験に基づき評価し、指摘し、修正させるサイクルを非常に高速に回せる
- これから始める人は最初からAIが存在し、現在のベテランと同じ道筋はたどらない
■ 8. 結論:速度と熟達は別物
- これまでの変化の共通点:
- 端末からマルチウィンドウ、IDE、インターネット検索、CI/CDへと変化し、そのたびに生産性が向上した
- それでもエンジニア自身が考え、実装し、失敗し、修正するという基本構造は残っていた
- 生成AIはその部分まで変えようとしている
- 未確定の見通し:
- 今回の変化を従来の開発環境の進歩と同じものとして考えてよいかは、まだ分からない
- AIによりはるかに短期間で熟達するエンジニアが現れるかもしれない
- 逆に、AIに任せることで自然に得られていた経験の機会が減るかもしれない
- 現在のベテラン像とはまったく違う、新しい種類のベテランが生まれるかもしれない
- 自分にはまだ答えがない
- 確かなこと:
- AIによってソフトウェアを作る速度が上がることと、エンジニアが熟達することは同じではない
- 今後考えるべき問い:
- AIでどれだけ速く作れるかだけでなく、AI時代にエンジニアはどう経験を積み熟達していくのかを考えるべき
- これは若手だけでなく、若手を育てる立場の人やAIを使って成長しようとするすべてのエンジニアの課題