What would the last software engineer still need to do?の意訳です。
CodeRabbitの最新のThe Mergeで、ソフトウェアエンジニア兼教育者のKent C. Doddsと対談しました。Kentはキャリアの多くを、より良いソフトウェアの作り方を開発者に教えることに費やしてきました。JavaScriptのテスト、React、フルスタックWeb開発、そして最近では、AIツールを使ってどう働くかを教えています。
私たちは、AIツールが急速に進歩し、エージェントが変更を実装し、プルリクエストを開き、レビューのフィードバックを受けて反復するようになるのを見てきました。そこで、多くの開発者が抱いているかもしれない、Kent自身も自問した疑問が浮かびます。「では、今の私はここで何をするのか？」
Kentは、思考実験を通じてソフトウェアエンジニアリングの未来を捉えています。AIが実装作業をより多く担うようになったとき、「最後のソフトウェアエンジニア」には、なお何をする必要があるのかという問いです。
彼の答えは簡潔です。「何を作るべきかを知ることだと思います」
すべての矢が当たるなら、標的を選ぶことが技術になる
何十年もの間、開発者の価値の大部分は、定義されたアイデアを動くソフトウェアへ変えることにありました。チケットを受け取り、要件を理解し、コードを書き、変更をリリースする。その繰り返しです。
エージェントが実装を担うほど、エンジニアの役割は、何を作るかを決め、システムを形作り、結果を判断する方向へ移っていきます。
Kentは開発者を弓の射手になぞらえます。「一人の射手をほかの射手より優れた存在にするのは、どの標的を射ることに最も価値があるかを知っていることです。矢が必ず当たるなら、どの標的に当てることが最大の価値を生むのかが重要になります」
Kentがソフトウェアエンジニアに見ている進化はこれであり、彼はそれをプロダクトエンジニアリングと呼んでいます。
プロダクトエンジニアは、アーキテクチャ、データモデル、マイグレーション、インフラストラクチャ、そして技術スタックの限界を理解しています。しかし、それらの制約をユーザーの問題へ直接結びつけます。Kentはその判断を「できるか」と「すべきか」の違いとして表現します。
「そのためにシステムを拡張する必要があるのか？」
Kentによれば、エンジニアは、システムが既存のものを再利用または統合できるのか、それともその変更に本当に新しいプリミティブが必要なのかを判断しなければなりません。
解決策ではなく、問題を愛する
Kentがプロダクトエンジニアリング講座のために設計している演習は、よくある依頼から始まります。サポートチームがあまりにも多くの返金を手作業で処理しており、誰かがサポート画面に返金ボタンを追加することを提案します。
実装を優先する開発者なら、その依頼を受けて作り始められます。Kentの演習は、エンジニアを一歩上流へ押し戻します。「なぜ、これほど多くの返金依頼が来るのか？」
「なぜ」と問うことで、返金ボタンが根本的な問題に対処するのか、それとも既存の処理を速くするだけなのかが見えてきます。Kentが伝えたいのは、技術的に妥当な解決策でも、問題そのものを捉え損なうことがあるという点です。
この問題への集中は、エンジニアがプロダクトマネージャーとどう働くべきかというKentの考えにもつながります。プロダクトマネージャーはエンジニアがドメインを理解する助けになりますが、エンジニア自身もユーザーが経験している問題に直接触れる必要があります。顧客との会話を聞いたり、サポート業務に時間を使ったりすることも含まれます。
「ドメインを深く理解し、問題を深く理解する必要があります」と彼は言います。
Kentの言葉を借りれば、「私たちは解決策に夢中になってしまう……本来は、問題にこそ夢中になるべきです」
Kentの捉え方では、エンジニアは二つの視点を結びつけます。プロダクトの文脈は、どの成果が重要で、その理由が何かを説明します。技術の文脈は、システムが何を支えられ、それぞれの選択にどんなコストがかかるかを説明します。
実装の両側を担う
コードは、変更の中間にあるものにすぎません。
上流では、誰かがユーザー、ドメイン、ビジネス上の制約、そしてその作業に注力すべき理由を理解しなければなりません。下流では、誰かがマイグレーション、保守コスト、インフラストラクチャの要件、ユーザーの反応と向き合うことになります。
Kentはその責任をこう表現します。「実装の両側にあるすべてを理解する」
エージェントは、その中間で多くの仕事をこなせます。リポジトリを調査し、変更を実装し、テストを実行し、プルリクエストを開き、有効なレビュー指摘に対応できます。エンジニアは、その判断と結果に責任を持ちます。
だからこそ、オーナーシップはKentが語るエンジニアリング判断の一部になります。
Kentによれば、オーナーシップは「立ち止まり、これから行い、実行すると約束することの影響や、その後に起こる波及効果について考えることを強いる」ものです。
エージェントは、変更が可能かどうかを伝えられます。プロダクトエンジニアは、その変更が存在すべきかを決め、その答えに責任を持ちます。
構文だけでなく、システムをレビューする
Kentの現在のワークフローは、この役割を具体的に示しています。
「エージェントを実行させると、実装を書き、PRにして、その後レビューが入ります」とKentは言います。彼はさらに、CIと有効なレビュー指摘への対応をエージェントに続けさせ、そのループのレビュアーの一つとしてCodeRabbitを使っています。Kentが戻る頃には、プルリクエストはすでに複数回の実装とレビューを経ています。
Kentは、何が変わったのか、どんな新しいプリミティブが導入されたのか、そして広いシステムへ影響する可能性のあるマイグレーションを確認します。この種のレビューには、変更前のシステムを理解し、変更後にどうあるべきかという意見を持つことが必要です。
最終的な目標は、エージェントが実装とレビュー作業をより多く担う中でも、責任ある判断をループの中に保つことです。
ツールの熟練は、沈みゆく足場である
開発者は今後も、コーディングエージェントの使い方を学ぶ必要があります。Kentは一つのツールを選び、それで生産的に働けるようになりながら、分野の変化を把握し続けることを勧めています。
一方で、ワークフローの一つの要素を何か月もかけて磨き込むことには、より懐疑的です。
1年前、開発者はプロンプトエンジニアリング、エディタールール、手作りのオーケストレーション、Ralphループに投資していました。Kentは、エージェントプラットフォームがこうしたワークフロー技法を組み込み機能としてすぐに吸収できると考えています。
Kentは、この種のツール熟練を沈みゆく足場にたとえます。「今お金を使って学ぶことは、次の足場へ進むためのものにすぎません。そして、その足場は沈んでいます」
Kentはこうしたワークフローを学ぶ価値を認めながらも、ツール側に間もなく組み込まれるかもしれない技法を深く追いすぎないよう注意を促しています。
開発者のための実践的なカリキュラム
開発者、特にジュニア開発者は今、何を練習すべきでしょうか。
- リリースできるまで、一つのエージェントワークフローを学ぶ。 一つのコーディングエージェントを選び、生産的に働けるまで習得します。新しいモデル、ハーネス、ワークフロー技法をすべて追いかけることに時間を使い切らず、分野の変化は把握し続けます。
- 一つの技術システムについて、強固な理解を築く。 深さは今も重要です。実際のコードベースのフレームワーク、アーキテクチャ、運用上の制約を学びます。エージェントが適切なプリミティブを再利用したのか、それとも同じ問題を解く二つ目の方法をひそかに持ち込んだのかを判断できれば、エージェントはより役に立ちます。
- 問題発見を練習する。 ソフトウェアの影響を受ける人と話します。サポートに時間を使い、顧客との会話を聞き、解決策へ飛びつく前に問題を明らかにする質問をします。
- 差分だけでなく、判断をレビューする。 意味のある変更ごとに、どんな新しいワークフローがシステムへ入ったのかを問います。マイグレーション、保守性のコスト、下流への影響を確認します。技術的に妥当な実装でも、システムとしての判断が悪いことはあります。
- リリース後も何かに責任を持つ。 オブザーバビリティとユーザーフィードバックを使い、リリース後に何が起きるかを確認します。学んだことを次の判断へ戻します。オーナーシップは、最初の判断と、それがユーザーやシステムにもたらした影響を結びつけます。
開発者の仕事は広がっている
エージェントが実装をより多く担うにつれ、Kentの主張はソフトウェアエンジニアの役割がより広くなることを示しています。
プロダクトの文脈と技術の文脈を橋渡しできるエンジニアは、ユーザーとシステムの両方を理解しています。エージェントが力を発揮できる環境を整え、何を作るかを決め、リリース後も責任を持ち続けます。
私は最後に、Kentへこのように投げかけました。
「2030年の最高のプロダクトエンジニアは、何を作るべきかを理解できる人になる」
Kentはこう答えました。「これ以上、簡潔には言えませんね」
