AIコーディングエージェントの普及に伴い、ソフトウェア企業のEPD（エンジニアリング、プロダクト、デザイン）組織に求められる役割が変わりつつある。LangChainのCEO、ハリソン・チェイス氏は同社ブログで、実装の比重が下がる一方、生成物を見極める評価・判断の重要性が増しているとの見方を示した。

チェイス氏は、コーディングエージェントがEPD組織と開発プロセスに与える変化について説明した。Claude以前の時代は、誰かがアイデアを出し、プロダクトチームがPRD（製品要求仕様書）を作成し、デザインチームがモックアップを用意し、エンジニアリングチームがコードとして実装する、という流れが一般的だったという。

実際にソフトウェアを作るには時間も手間もかかるため、分業が前提となり、その出発点としてPRDが機能していたとしている。

だが、コーディングエージェントの登場によって、この流れは変わった。アイデアから短時間で動くソフトウェアのたたき台を作れるようになり、開発のボトルネックも移り始めた。

チェイス氏は「いまや誰でもコードを書ける。EPDの役割は、生成されたものをレビューし、判断する側へ移っている。コード生成のコストが下がったことでプロトタイプは増え、レビューすべき対象も増えた」と述べた。

一方で、コーディングエージェントが普及しても、文書化の必要性がなくなるわけではないという。

同氏は「誰かがアイデアを持ち込み、プロトタイプまで作ってきたとしても、そのコードが本来意図したものなのか、意図せず入り込んだものなのかは、すぐには判断できない。意図を明確に伝える文書は引き続き必要だ」と説明した。

PRDを作成し、その後にモックアップ、コードへと進む従来の順序は薄れつつあるものの、製品要件を記した文書は、プロトタイプと並ぶ重要な資料として残るとみる。将来的には、PRDが構造化されたプロンプトの形を取る可能性もあるとした。

また、AIコーディングエージェントの時代には、プロダクト、エンジニアリング、デザインを横断して捉えられるジェネラリストの価値が高まると指摘した。

チェイス氏は「以前は実装の段階で他者の助けが必要だったが、いまはエージェントと対話すればいい。一人でこなせる仕事の範囲は広がっている」と語った。

さらに「コーディングエージェントは、もはや選択肢ではない。PMは仕様書を書いて待つのではなく、自らプロトタイプを作ってアイデアを検証できる。デザイナーもFigmaの中だけにとどまらず、コードを使って反復できる。エンジニアは実装そのものより、システム設計に多くの時間を割ける。使わなければ、使える人材に置き換えられる」と強調した。

同氏は、プロダクト感覚もあらゆる職種に共通する重要な要素になっているとみる。「エージェントに何を作らせるかを決めるのは人だ。方向性を誤れば、レビューの負担が増えるだけだ。役割に関係なく、プロダクト感覚は基本要件になった」と述べた。

システム思考の重要性も増している。実装コストが下がるほど、最初から正しいものを見極める判断力が差別化要因になるためだ。

チェイス氏は「エンジニアは、サービスやAPI、データベース設計について明確な全体像を持つべきだ。プロダクト担当者は、ユーザーが口にする要望ではなく、本当に必要としているものを見抜かなければならない。デザイナーは、なぜそれが使いやすいのかを説明できる必要がある」と指摘した。

その上で同氏は、AI活用が広がる中、今後のEPD組織では2つの役割が特に重要になるとみている。

1つは「ビルダー」だ。プロダクト起点で考えられ、コーディングエージェントを使いこなし、デザインの基礎感覚も備えた人材を指す。テスト環境やコンポーネントライブラリなど一定のガイドラインのもとで、小規模な機能であれば、アイデア創出からリリースまでを一人で担えるという。

もう1つは「レビューアー」である。機能が大規模かつ複雑になるほど、より深い検証が必要になるため、レビューアーには担当領域に対する高度なシステム設計力と、増え続けるレビュー依頼を迅速に処理する能力が求められるとした。

チェイス氏は「エンジニアは、システム設計に強いレビューアーになるのか、プロダクトとデザインの感覚を磨いてビルダーを目指すのかを選ぶ必要がある。プロダクトやデザインの担当者も、自らの専門領域で思考の枠組みを深めてレビューアーになるのか、コーディング能力を高めてビルダーへ進むのかを考えるべきだ」と述べた。