プログラミングエージェントがエンジニアリング、製品、デザインをどのように再構築するか

タイトル: プログラミングAgentがエンジニアリング、プロダクト、デザインをどう再構築するか

ソフトウェア企業におけるEPD（エンジニアリング、プロダクト、デザイン）の存在意義は、優れたソフトウェアを作ることです。役割は異なりますが、最終目標は同じです：ビジネス課題を解決し、ユーザーが使える機能的なソフトウェアを作ることです。結局のところ、アウトプットはコードです。この点を認識しなければなりません——なぜなら、プログラミングAgentによって、コードを書くことが突然、非常に簡単になったからです。では、EPDの役割はどう変わるのでしょうか？

プログラミングAgentの使用は必須である

優れたPMはより優れ、劣るPMはより劣る

誰もが、自分の役割がプログラミングAgentから最大の恩恵を受けると考えている——そして、それは間違っていない

PRD（プロダクト要件定義書）は、Claude以前の時代におけるソフトウェア開発の中核となるハブでした。EPDのプロセスはおおよそ次のようなものです：

1. 誰か（通常はプロダクトマネージャー）がアイデアを思いつく
2. デザイナーがPRDをもとにデザインを作成する
3. 

これは絶対的なルールではありません（スタートアップでは、これらのステップが混在し、最も優れた人が複数のことを同時に行うことがよくあります）が、教科書通りの標準的な方法です。

このプロセスが必要な理由は、ソフトウェア（およびデザイン）を作成するには多くの時間と労力がかかるからです。そのため、専門的な分業が生まれました。分業が細かくなるほど、部門間のコミュニケーションの必要性が高まります。PRDはすべての始まりであり、プロセス全体をつなぎます。バトンはデザインに渡され、言葉を美しいUIとスムーズなインタラクション体験に変えます。最後にエンジニアがそれを現実のものにします。

プログラミングAgentはこの流れを覆します。プログラミングAgentは、アイデアを直接実行可能なソフトウェアに変えることができます。私（および多くの人々）が「PRDは死んだ」と言うとき、本当の意味は次の通りです：PRDを書くことから始まるこの伝統的なソフトウェア開発の方法は、終わりを迎えたのです。

今では誰でもコードを書けるということは、誰でも何かを作れることを意味します。しかし、それが適切なアーキテクチャを持ち、正しい問題を解決し、使いやすいものであるとは限りません。エンジニアリング、プロダクト、デザインは、これらの側面のレビュアーおよびゲートキーパーとなるべきです。問題は、Agentが生成するコードが常に「十分に良い」とは限らないことです。EPDの仕事は、コードが「十分に良い」ことを確認するレビューに変わります。ここでの「十分に良い」にはいくつかの意味があります：

• エンジニアリングシステムの観点からアーキテクチャが適切か：コードは拡張性があり、高性能で、十分に堅牢か？
• プロダクトの観点から思考が十分か：これは本当にユーザーの課題を解決しているか？
• デザインの観点から使いやすいか：インターフェースは使いやすく、直感的か？

初版コードの生成コストは非常に低く、大量のプロトタイプが出現します。これらのプロトタイプは、議論とレビューの中心となり、プロダクト、エンジニアリング、デザインがそれらを中心に回ります。

問題は——コードの生成があまりにも簡単であることです。以前はコードを書くのに長い時間がかかり、レビュアーとして扱うプロジェクトの数は多くありませんでした。しかし、今では誰でもコードを書けるため、進行中のプロジェクトの数が急増しています。3つの職能すべてのボトルネックは、レビュー——プロトタイプを受け取った後、それらが十分に良いことを確認すること——に移行しました。

Claude以前のソフトウェア開発方法（PRDから始まる）は過去のものとなりました。しかし、プロダクト要件を記述するドキュメントは依然として不可欠です。

誰かがアイデアを思いつき、素早くプロトタイプを作成したと仮定します。次に、どうやってリリースするのでしょうか？EPDの他のメンバーによるレビューが必要です。このプロセスでは、テキストによる説明が常に役立ち、しばしば不可欠です。他の人がレビューするとき、コードの特定の部分が意図されたものか偶然書かれたものかをどうやって知るのでしょうか？意図を見る必要があります。意図を伝える方法がなければなりません。

私は、伝統的なPRDプロセス（PRD → デザイン → コード）は死んだと考えます。しかし、プロダクト要件を記述するテキスト自体は健在です。デリバリーのレビューに至る前に、このドキュメントはプロトタイプの必須のパートナーとなるべきです。

最も標準的な形式はドキュメントですが、興味深いアイデアもあります——例えば、生成された機能に使用されたプロンプトを共有してコミュニケーション手段とすることです。将来のPRDが、構造化されバージョン管理されたプロンプトであるとしたらどうでしょうか？

ここで言うジェネラリストとは、プロダクト、エンジニアリング、デザインの3つの側面すべてに対して優れた感覚を持つ人々のことです。これらの人々は常に価値があり、影響力がありました——しかし、プログラミングAgentがあることで、彼らはさらに力を発揮します。なぜでしょうか？

コミュニケーションはすべての中で最も難しい部分であり、すべてを遅らせます。一人でプロダクト、デザイン、エンジニアリングを同時にこなせる人は、3人のチームよりも速いです。なぜなら、コミュニケーションのオーバーヘッドが省かれるからです。

過去には、実装自体がボトルネックであり、ジェネラリストも他の人とコミュニケーションを取って物事を成し遂げる必要がありました。今では、彼らはAgentとだけコミュニケーションを取ればよいのです。これは、一人で行う影響力がこれまで以上に大きいことを意味します。

プログラミングAgentの使用は必須である

プログラミングAgentは実装コストを非常に低くし、それらを使用することは必須です。プログラミングAgentを効果的に使用できる人は、一人でより多くのことを成し遂げられます：

• プロダクトマネージャーは、要件定義書を書いて待つことなく、直接プロトタイプを作成してアイデアを検証できる
• デザイナーは、Figmaで描画するだけでなく、コード内で直接イテレーションできる
• エンジニアは、実装からシステム思考に時間を割ける

プログラミングAgentを使用することは必須です。なぜなら、習得は難しくなく、使用しない人は使用する人に置き換えられるからです。

優れたPMはより優れ、劣るPMはより劣る

優れたプロダクト思考はこれまで以上に価値があります——本当に役立つものを作れるからです。劣るプロダクト思考はこれまで以上に無駄です。もし誰かがひどいプロダクトアイデアを持っている場合、彼はプロトタイプを持って現れることができます——しかし、そのプロトタイプは役に立たない、または考え抜かれていない機能を示しています。これらのプロトタイプは今、より多くの人々によるレビューを必要とします——エンジニアリング、プロダクト、デザインすべてがレビューしなければなりません。これは大量の時間とリソースを消費します。そして、リリースへの慣性がより大きくなります（「もう作ってある！そのままマージしよう！」）。その結果、プロダクトはより悪くなるか、より肥大化する可能性があります。

実行コストが非常に低い世界では、システム思考が真の差別化能力となります。あなたはシステム思考を磨き、自分の分野における明確なメンタルモデルを構築することに集中すべきです：

• エンジニアリング：サービスアーキテクチャ、API、データベースをどのように設計するかについての明確なメンタルモデル
• プロダクト：ユーザーが本当に何を必要としているか（彼らが口で言う欲しいものではなく）についての明確なメンタルモデル
• デザイン：なぜあるものが使っていて見ていて感じるのが正しいのかについての明確なメンタルモデル

システム思考は常に重要でした——では、何が変わったのでしょうか？実装コストが大幅に下がったのです。何かを作ることはこれまで以上に簡単です——しかし、作られたものが良いとは限りません。優れたシステム思考は、着手する前に方向性が正しいことを確認させ、他人の仕事をレビューする際の判断力を高めます。両方の側面から、システム思考の重要性は高まっています。

プログラミングAgentは依然として、何をすべきかを指示し、伝える人を必要とします。もし間違ったことをさせた場合——あなたは他人にレビューすべきゴミを増やしていることになります。Agentに何をさせるべきかを知ること（つまり「プロダクトセンス」）は、基本的な要件です。そうでなければ、組織全体を遅らせることになります。これはエンジニアリング、デザイン、そして（明らかに）プロダクトに適用されます。

EPDの仕事の多くは、今やプロトタイプのレビューです。プロダクトセンスがあれば、デザインやエンジニアリングの内容をレビューする場合でも、レビューが容易になります。プロダクトセンスがなければ、プロトタイプとともに超詳細なプロダクトドキュメントが必要です。プロダクトセンスがあれば、機能の意図を理解するために簡単な説明だけで済み、コミュニケーション、レビュー、デリバリーを加速させます。

あなたはプログラミングAgentを使える必要があります。あなたはプロダクトセンスを持つ必要があります。すべての役割が融合しています。

役割の間には常に重複がありました。デザインとプロダクトは常に密接に関連してきました——AppleやAirbnbのような企業では、デザイナー自身がプロダクトマネージャーを兼ねています。「デザインエンジニア」（デザインとエンジニアリングの能力を兼ね備えた役割）は、Vercelなどの企業でますます人気が高まっています。

しかし、専門化には依然として余地があります。システムアーキテクチャに特化したシニアエンジニアは依然として価値があります。感覚的プログラミング (Vibe Coding) を学んでいなくても、顧客の課題と何をすべきかについて超明確なメンタルモデルを持つPMも同様です。ユーザージャーニーとインタラクションを理解しデザインできるデザイナーも、Figmaで作業しているとしても同様です。

ただ、専門化のハードルははるかに高くなりました。あなたは自分の分野で卓越しているだけでなく、レビューの速度が非常に速く、コミュニケーション能力が非常に高くなければなりません。そして、このような役割はどの企業でも多くはありません。

私たちは、EPD内で2つのタイプの役割が形成されているのを見ています。

第一のタイプ：ビルダー。 これらの人々は優れたプロダクト思考を持ち、プログラミングAgentを使用でき、基本的なデザイン直感を持っています。ガードレール（テストスイート、コンポーネントライブラリ）があれば、彼らは小さな機能をアイデアからリリースまで持ち込み、大きな機能の使用可能なプロトタイプを作成できます。

第二のタイプ：レビュアー。 大規模で複雑な機能には、EPDレベルの深いレビューが必要です。ハードルは高いです——あなたは自分の分野のトップレベルのシステム思考者でなければなりません。そして、速くなければなりません——レビューすべきものが多すぎるからです。

• もしあなたが現在エンジニアであるなら——システム設計を極めてアーキテクチャを自信を持ってレビューできるようにし、レビュアーの方向に進むか、プロダクトとデザインの能力を高めてビルダーになるかのどちらかです。
• もしあなたがプロダクトまたはデザインをしているなら——トップレベルのプロダクト/デザインメンタルモデルを構築し、主にレビューを行うか、プログラミングAgentに投資してプログラミングスキルを高めるかのどちらかです。

興味深いことに、役割は収縮しており、上の図からすべてのEPDの人々がこの図のどこかに分布していることがわかります。役割は融合し始めています——エンジニアはより多くの時間を持ち、プロダクトとデザインについてより多く考えることができます；プロダクトとデザインもコードを書けるようになりました。

誰もが、自分の役割がプログラミングAgentから最大の恩恵を受けると考えている——そして、それは間違っていない

Twitterには、どのような人々がプログラミングAgentから最大の恩恵を受けるかについての優れた投稿があります：

既存のプロダクトを直感的に理解している人——どこが弱点で、どこが強みで、どのようにイテレーションしてプロダクトをより鋭くするかを知っている人。 このような人々の最も希少なバージョンは、文化と深い技術の交差点に立っています。真の「バイリンガル」です。彼らは技術的に何が可能かを知っており、どの文化的潮流が本物で、どれが一過性のものかを識別できます。まさにこの組み合わせが、プロダクトを「当然あるべきもの」と感じさせるか、「寄せ集め」と感じさせるかを決定します。

この投稿はこの新しい世界を完璧に要約しており、かなりの広がりを見せました。それが広まった理由の一部は、読んだ誰もがそれが自分自身または自分の役割について言っていると感じたからです。私はプロダクトの人々がリツイートし、デザイナーもリツイートし、デザインエンジニアもリツイートし、創業者もリツイートしているのを見ました……誰もがそれが自分自身について言っていると感じています。

そして、彼らはおそらく間違っていません！私がこの新しい世界をエキサイティングだと思う理由は、出身背景がそれほど重要でなくなったことです。私は心から、このような人々はプロダクト、デザイン、エンジニアリングのいずれの方向からも来ることができると信じています。しかし、これは誰もがそのような人になれるという意味ではありません——言うは易く行うは難しです。真のジェネラリストは非常に稀です。

これはビルダーになる良い時代です :)