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が語るエンジニアリング判断の一部になります。
Kentによれば、オーナーシップは「立ち止まって、これから行うと約束したことがもたらす影響や、その後の波及効果について考えることを強いる」ものです。
エージェントは、ある変更が可能だと教えてくれます。プロダクトエンジニアは、その変更が存在すべきかを決め、出した答えに責任を持ちます。
構文だけでなく、システムをレビューする
Kentの現在のワークフローは、この役割を具体的に示しています。
「エージェントを実行させると、実装を書き、PRにして、その後レビューが入ります」とKentは言います。そのうえで、CIと有効なレビュー指摘への対応をエージェントに続けさせ、そのループにおけるレビュアーの一つとしてCodeRabbitを使っています。Kentがタスクに戻る頃には、プルリクエストはすでに複数回の実装とレビューを経ています。
Kentは、何が変わったのか、どんな新しいプリミティブが導入されたのか、そしてシステム全体へ影響する可能性のあるマイグレーションかを確認します。この種のレビューには、変更前のシステムを理解し、変更後にどうあるべきかという意見を持つことが必要です。
最終的な目標は、エージェントが実装とレビュー作業をより多く担う中でも、責任ある判断をループの中に保つことです。
ツールへの習熟は、沈みゆく足場である
開発者は今後も、コーディングエージェントの使い方を学ぶ必要があります。Kentは、一つのツールを選んで生産的に働けるようになること、そして分野の変化を把握し続けることを勧めています。
一方でKentは、ワークフローの基本について、何か月もかけて磨き込むことには懐疑的です。
1年前、開発者はプロンプトエンジニアリングやエディタールール、手作りのオーケストレーション、Ralphループに取り組んでいました。Kentはエージェントプラットフォームがこうしたワークフロー技法を組み込み機能としてすぐに吸収できると考えています。
Kentは、この種のツールへの習熟を沈みゆく足場にたとえます。
「今それを学ぶために使うお金は、次の足場へ進むためのものにすぎません。そして、その足場は沈んでいます」
Kentはこうしたワークフローを学ぶ価値を認めながらも、ツール側に間もなく組み込まれるかもしれない技法を深く追いすぎないよう注意を促しています。
開発者のための実践的なカリキュラム
開発者、特にジュニア開発者は今、何を練習すべきでしょうか。
- リリースできるまで一つのエージェントワークフローを学ぶ コーディングエージェントを一つ選び、生産的に働けるまで習得しましょう。新しいモデルやハーネス、ワークフロー技法をすべて追いかけることに時間を使い切らず、分野の変化を把握し続けてください。
- 一つの技術システムについて強固な理解を築く 深さは今も重要です。実際のコードベースについて、フレームワークやアーキテクチャ、運用上の制約を学びましょう。エージェントが適切なプリミティブを再利用したのか、それとも同じ問題を解く二つ目の方法をひそかに持ち込んだのかを判断できれば、エージェントはより役に立ちます。
- 問題発見を練習する ソフトウェアの影響を受ける人と話しましょう。サポートに時間を使って顧客との通話に耳を傾け、解決策へ飛びつく前に、問題を明確にする質問をしてください。
- 差分だけでなく、判断をレビューする 意味のある変更ごとに、どんな新しいワークフローがシステムへ入ったのかを問いましょう。マイグレーションや保守性のコスト、下流への影響も確認してください。技術的に妥当な実装でも、システムとしての判断が悪いことはあります。
- リリースした後も何かに責任を持ち続ける オブザーバビリティやユーザーフィードバックを使って、その後に何が起きるかを確認しましょう。学んだことは、次の判断に活用してください。オーナーシップは最初の判断と、それがユーザーやシステムにもたらした影響を結びつけます。
開発者の仕事は広がっている
エージェントが実装をより多く担うにつれ、ソフトウェアエンジニアの役割はより広くなっていきます。Kentの主張は、その方向を指し示しています。
プロダクトの文脈と技術の文脈を橋渡しできるエンジニアは、ユーザーとシステムの両方を理解しています。エージェントが力を発揮できる環境を整え、何を作るかを決め、リリース後も責任を持ち続けます。
対談の最後に、私はこの考えをKentへこう投げかけました。
「2030年、最高のプロダクトエンジニアは、何を作るべきかを理解できる人になるでしょうね」
Kentはこう答えました。「それ以上、簡潔には言えませんね」
