はじめに
Claude CodeやGitHub Copilotなど、これらのAIを活用した開発はもはや語るまでもなく日常的なものとして定着しています。やりたいことを自然言語で伝えれば、かつては調べたり試行錯誤したりしながら時間をかけて書いていたコードが、一瞬で生成される時代です。
経験豊富なエンジニアにとって、これは純粋な生産性向上を意味します。彼らはすでに技術的な抽象構造や長期的なリスクを熟知していて、ビジネス要求との文脈的理解を持った上で、AIを自分の代わりにコードを書いてくれる高速なツールとして安全に使いこなせるからです。
（もちろん、ベテランエンジニアも油断していると必要な考慮が抜け落ちることはあります…）
しかし、これからエンジニアとなり技術を学ぼうとする者にとっては、この便利さは却って成長機会を奪ってしまう側面もあります。なかには「分かったつもりになっていないか」と、ある意味健全な不安を抱く人もいると思います。
この問題の原因は、本来セットであるはずの「結果」と「過程」が速度差によって切り離されてしまうことにあります。「(AIが)コードをアウトプットするスピード」に「人がその中身を理解し、自分の知識にするスピード」が追いついておらず、目の前に動くコードはあるのに頭の中にはその仕組みが入っていないという、理解の空洞化が生まれやすい環境になっています。
このようなアウトプットと理解のギャップを埋め、エンジニアとして本質的な土台を築いていくために、個人や組織としてどう向き合っていくか、あるいはエンジニアとして"何"を学ぶか、少し考えてみます。
エンジニアリングの本質
本題に入る前に、そもそもエンジニアがモノを作るときに、頭のなかで何が行われているのか整理してみます。ウォーターフォールであれアジャイルであれ、開発手法に関わらずエンジニアリングには必ず以下の思考プロセスが存在します。
- Why（ビジネス・要求）: なぜ作るのか？誰のどんな課題を解決するのか？
- What（要件・設計）: なにを作るのか？どんな機能や振る舞いが必要か？
- How（構造・詳細）: どう実現するか？データ構造やアルゴリズムはどうするか？
- Do（実装）: 実際にコードを書く
- Check（検証）: 意図した通りに動くか？バグはないか？
エンジニアリングの本質が課題解決である以上、これらの問いを避けて通ることはできません。たとえ個人で「明日の天気予報をSlackに通知するスクリプト」を書く場合でも、一瞬のうちに頭のなかでこれら全ての工程（「何時に通知がほしいか？」、「APIは何を使うか？」など）を行っています。実際の開発現場でもチームによる差はあれど、これを暗黙的に行っているか、ドキュメントとして明示的に行っているかの違いになります。
重要なことは、この思考プロセスが"全体"にも"部分"にも自己相似的に存在しているということです。つまり、プロジェクト全体を通して現れるものに加え、たった一つの関数やクラスを実装する際にも、「どんな責務を持つか？（Why）」「何を受け取り、何を返すか？（What）」「どんなロジックで処理するか？（How）」というように同様の思考プロセスが現れます。
エンジニアリングの重心変化
先ほどの思考プロセスを視覚化したものが、ソフトウェア開発の古典的な図式である「V字モデル」です。
これまでの開発においてエンジニアリングの時間の多くは、V字の底にある「詳細設計（How）」と「実装（Do）」に割かれていました。それは単純作業としてコードを書くという時間ではなく、詳細なロジックに悩み、自らの手でコードとして具体化する試行錯誤の時間です。
AIの登場後もそういった時間が無くなった訳ではなく、この領域が開発の中心であることには変わりありませんが、間違いなくAIにより大幅に効率化され、エンジニアの仕事が「AIが提示した設計・実装が正しいかを見極め、統合する作業」へとシフトしています。
その結果、エンジニアリングの重心は詳細を詰めながら手を動かす領域から、「問いを立て定義する領域（Why/What）」と「責任を持って検証する領域（Check）」へと、よりV字の両端へ移り変わっています。そして、AIの適性がさらに抽象的な領域へ拡張されることで、この重心移動はますます加速していくことと思います。
思考プロセスの省略による副作用
こうした環境変化により、エンジニアリングの思考プロセスが省略されやすくなっていると感じます。省略されているからこそ効率化されているわけですが、省略されているもののなかにはエンジニアとして必要な学習や成長機会も含まれてしまっています。
この問題を分かりやすくするため、少し極端に考えてみます。
- Before
- What(要件) → How(設計・調査) ⇄ Do(実装・試行錯誤) → Check(検証)
- やりたいことを理解し、どう実現するのが良いか？と悩み、社内外のドキュメントを調査したり他の人と壁打ちしながら、実際に書いてエラーが出たり懸念があれば他の方法と比較検討する
- 「迷いながら調査し、失敗して修正する反復プロセス」が（時間はかかるが）必然のものとして存在する
- After
- What(指示) → [How(設計)とDo(実装)がブラックボックス化] → Check(動作確認)
- やりたいことを理解し、AIに「〇〇を実装して」と指示すると、瞬時に妥当そうな設計とロジックのコードを提示してくれる
- 「なぜその設計か？」「他の選択肢は？」といった、How(設計)の思考プロセスが省略されている
実際にはBeforeとAfterの間には当然グラデーションがありますが、本来そこにあったはずの「技術的な選択肢の比較検討と試行錯誤」というプロセスを、無意識のうちに省略させてしまいやすい構造です。結果的に、「動くコード（具体）」は手元にあるのに、その背景にある「構造や意図（抽象）」が頭に残らないという、理解の空洞化が起きてしまいます。
大事なことは、エンジニアリングの思考プロセスが持つ自己相似性ゆえに、この問題があらゆる粒度で発生するということです。そして、粒度が細かく具体に近い領域であるほど省略される範囲も広くなる傾向があり、たった一つの関数くらいであればWhyからCheckまで全て省略されることもあると思います。
省略された思考プロセスを逆算する力
このような環境だからこそ、以前にも増して重要な能力があります。それは、目の前にある具体のコードから、その背後にある抽象構造や将来的なリスクを逆算して読み解く力です。AIが出力したコードであれ、チームメンバーが書いたコードであれ、「動く実装（Do）」を見て「省略された設計意図（How）」を頭のなかで理解できなければいけません。
そのために大事なスタンスは、今あるコードやAIのコードを正解として扱うのではなく、あくまで自身が思考するための材料として捉え直す姿勢です。「動いてはいるけれど、本当にこれでいいんだっけ？」と、一度立ち止まって意識的に考えてみることです。
具体的な実践として、以下のようなことを意識してみると良さそうです。
-
自分なりの答えを持ち、"疑って見る"
- 正しさにはこだわらなくて良いので、やりたいことに対して「(今の)自分ならこう書く」という予測を持っておきます
- その予測と目の前のコードとの差分こそが思考すべきポイントになります
- 「なぜその設計なのか？」「自分が想定していた選択肢ではなぜダメなのか？」というような比較検討のプロセスを後追いで行うことで、省略された思考を取り戻せます
-
隠れた前提を特定し、"変化や例外を想像する"
- 目の前のコードは往々にして「データ量が少ない」や「通信が必ず成功する」といった「現在の都合の良い前提（Happy Path）」が隠れています
- そのような前提を特定し、そこに含まれない変化や例外を意識的に考えてみます
- 「将来データ量が10倍になったら？」「通信がタイムアウトしたら？」というような、今の前提には含まれていない将来起き得る変化や例外ケースを想像することで、見落とされていたリスクや構造的な脆さを検知できます
この「疑う力（批判的思考）」と「想像する力（仮説思考）」を養えば、AIによって思考が省略されてしまうのではなく、むしろAIが思考の幅を広げてくれる最良のツールになると思います。
思考プロセスの学習機会を作る
とはいえ、これからエンジニアとして成長していこうとする者にとって、個人で主体的にこれらの力を養うことは言うほど簡単なことでは無いと思います。そもそも「自分なりの答え」を持つには引き出しとなる知識が必要で、「変化や例外を想像する」ためには失敗も含めた実践経験が必要不可欠です。そのため、これから学ぶ人にとっては「何が分からないかが分からない」という状態になるのはある意味当然のことです。
個人の努力として「疑おう」「想像しよう」というマインドセットを持つことは大事ですが、組織として彼らの成長を支援するためにどのような機会や環境を提供できるでしょうか。個人的には、研修などを通した体系的な知識の獲得と、"ペアプロ"を通した思考プロセスの実践的学習という座組が良さそうと考えています。
まず、「疑い想像する」ために必要な基本的な知識（判断基準）を学べる機会を作ります。目の前のコードが良いか悪いかを判断するためには、その比較対象となるセオリーを知っておく必要があるからです。
一般的にどんな設計原則やデザインパターンがあるのか、目の前のプロダクトはどんな設計思想で作られているのか、これらを学ぶことで「それは良くない設計ではないか？」と疑うことができます。また、「過去にDBのインデックス不備で障害が起きた」「非同期処理の排他制御漏れでデータ不整合が起きた」といった、組織内や業界の失敗事例（ポストモーテム）を学ぶことで「将来のリスク」を想像することができます。これは体系的な研修を通して共有しても良いですし、チーム内の勉強会のなかで共有しても良いと思います。
そして、獲得した知識を実務でどう適用するかを学ぶために"ペアプロ"を併せて実施します。これは生産性向上を目的としたものではなく、あくまで思考プロセスの学習機会としての"ペアプロ"です。
この目的で"ペアプロ"を実施する際に大事なことは、2人で開発を進める中で「思考の過程を言語化して共有する」ことと、AIが出力したコードに対して「どんな判断基準でどう評価したかを共有する」ことを意識的に行うことです。現場の文脈に応じた思考と判断を丁寧に伝えていきます。これをプロダクト開発のスピード感とバランスを取りつつ、メンバーの組み合わせをローテーションしながら実行するのが良さそうです。
あくまで個人的な考えではありますが、組織としては「疑い想像するための知識」を学べる場と「思考するための現場」を一緒に共有し、インプットとアウトプットの両輪が回る環境を戦略的に構築しておくことで、これからのエンジニアが本質的な土台を育てていくことができるのだと思います。
少し先の未来で求められる力
最後に、少し先の未来についても想像してみます。それは、AIが「技術的に完璧な設計と実装」を出せるようになった世界です。このとき、エンジニアに求められる力はどんなものになるでしょうか。
この世界では、V字モデルで言うところの基本設計より下の工程を概ねAIに任せきることができると思います。その結果、エンジニアが注力する領域がV字モデルの両端へ二極化するため、「そもそも解決すべき課題は何か？」という問いを正しく立てる力、作られたモノがユーザーの課題を解決しているか責任を持って確認する力の重要性が増していきます。
また、この「解決すべき課題は何か？」という問いを正しく立て、その結果に責任を持つためには、ビジネスや組織に対する理解が必要不可欠となります。解決すべき課題の内容や優先度はビジネスの状況によって変化し、解決するために何をどう作るかはチームの状況によって変化するためです。このような現実的に存在する文脈を抑えた上で、「課題 - 技術 - 結果」を正しく接続できる力が必要になりそうです。
そのため、足元ではエンジニアとして本質的な土台を育てていきつつ、視座を上げて「課題を定義する」「正しく問いを立てる」力も同時に育んでいくことが求められます。
（ちなみに少し先の未来とは言いつつ、2~3年後くらいのそう遠くない未来だと思っています）
おわり
これからのエンジニアがどう成長していくか今考えていることを書き出してみたのですが、思ったより長くなってしまいました。書いてみると、あまり新しいことは何も言っていないように感じます。技術を理解し、ビジネスや解決したい課題と正しく接続できるようになること。エンジニアリングの本質は変わっていないですが、AIの登場によってそのサイクルに求められる速度は間違いなく加速していると思います。
記事が長くなったので、改めて大事なことをまとめます。今の環境は、これまで必然のものとしてあったエンジニアリングの思考プロセスが省略されやすく、その中には成長機会も含まれてしまっています。だからこそ、いま自分が"何"を省略しているのか正しく見つめ直し、意識的に成長機会を取り戻すことが必要です。もちろん、今すぐ完璧にできる必要はありません。求められるスピードが速いからこそ、焦って思考をスキップするのではなく、周りの支援も得ながら「本質的な土台」を着実に積み上げていけば良いのだと思います。
一方で、なんでもかんでも理解しようとする必要もないと思っています。キャリアの志向性や時代の潮流ともバランスを取りながら、エンジニアとして"何"を学ぶか、自らの決断で取捨選択していくことが大事です。
組織としては、これからのエンジニアが本質的な土台を築けるように成長機会を作り、彼らが正しく決断できるように支援する責任があります。人を大事にし人を育てられる組織のみが、事業を大きくしていけるのだと信じています。
ちなみに私は、「とにかく目の前で向き合っていることを精一杯がんばる」というシンプルなマインドも好きです。泥臭く課題に向き合い続けられる姿勢が課題解決には一番必要な要素であり、その過程で必然的に学習機会が生まれ、周りにいる人との信頼関係も築かれると思います。
Discussion