私たちは、たった1人のエンジニアがコードに触れる前に、何か月もかけてプロダクト戦略ドキュメントを書いていました。完璧なドキュメントを先に作って、それから構築する。ところがエンジニアリングが始まると、前提の半分が間違っていたことが判明し、ドキュメントはリリース前にすでに古くなった状態で棚に置き去りにされました。
私は別のことを試しています。まずは“最低の”初稿を、リーダーシップにレビューしてもらう。数週間以内に顧客向けにデモする。エンジニアには作って学んでもらう。そして実際に作ったことからしか得られない文脈をもとに、戦略ドキュメントを書き直すのです――実装上の設計判断、顧客の反応、そして同じアプリを両方のプラットフォームで作ろうとしたときにだけ見えてくる競合との差分。
落とし穴は、これが成立するのは、十分に速く反復できる場合だけだということです。1か月かけてストレステストする“最低の”初稿は、ただの“最低の”ドラフトです。そこでエージェントが登場します。
私は最初から、こうした仕組みを作るつもりはありませんでした。私は、顧客からのフィードバックが十数個のチャネルに散らばる状態で、2つのオープンソースの開発者向けツールをマネジメントしており、週に2回リリースするチームを持っています。私は溺れていたのでAIエージェントを使い始めました。途中で、プロセスそのものが変わっていったのです。
ここで学んだことを共有します。
1. 顧客から始める：PDD（プロダクト定義ドキュメント）のワークフロー
すべての新規プロジェクトは、今では同じやり方で始まります。私はオーケストレーターのエージェントと一緒に座って、PDD（Product Definition Document）ワークフローを実行します。数時間かかりますが、そのほとんどを最初の問いに費やします：誰が顧客なのか？
「開発者」ではありません。「フルスタックエンジニア」でもありません。エージェントは私に、もっと具体的にするよう迫ります。職種名は何ですか？ いま使っているツールは？ どんな瞬間に壁にぶつかるのですか？ それ以前に、私たちを見つけるまでに何を試しましたか？ 私のエージェントの1つ――私は「Impactful Jerk（インパクトのある意地悪役）」と呼んでいます――は、見知らぬ人が読んでも、私たちが誰に向けて作っているのかが明確に分かるくらいまで顧客の定義が研ぎ澄まされるまでは先に進ませてくれません。
そこから流れができます。何が問題で、解決策は何か。前提は何か。これが機能するために真である必要があるのは何か。エージェントはプロダクトドキュメントのドラフトを生成し、あらゆる主張をストレステストし、「裏付けがあるもの」と「推測にすぎないもの」を区別してフラグを立て、レビューの前に検証が必要な項目を優先度順のリストとして出します。
以前はこのステップを飛ばして、すぐに文章を書き始めていました。今は逆で、ここに一番時間を使っています。というのも、プロダクトドキュメント、ロードマップ、エンジニアリングの優先順位など、その後ろのすべては、顧客の定義の質にしか依存していないからです。
2. 共通の金庫：消えない意思決定
最初に変わった、構造的なポイントは、知識がどこにあるかでした。
以前はプロダクトの文脈が、頭の中、誰も読まないドキュメント、流れていってしまうチャットスレッド、そしてラップトップ上のファイルの中にありました。休暇に行けば文脈も一緒に持っていかれます。新しいエンジニアが入れば、「なぜXを決めたのか？」と2週間かけて聞くことになる。
今は、すべての意思決定、顧客からのフィードバックのすべて、プロダクトドキュメントのドラフトのすべて、ストレステストの出力のすべてが、markdownで入ったgitリポジトリがあります。エンジニアは自分のAIツールをそれに向けるだけで、誰にも聞かずにチーム全体の文脈を得られます。任意の機能のエンジニアリングドキュメントをアップロードしたり、デモコードをチェックインしたり、顧客とのミーティングのメモを追加したりできます。私がプロダクトドキュメントを書くときも、エージェントはすでに、私たちの顧客フィードバック、競合状況、そしてこれまでの意思決定を把握しています。
金庫は、顧客フィードバックの扱い方も変えました。以前は私はGitHubのイシューを手作業で読んでいました。いまは“スイープ”します――「私たちの設計意思決定に対応する、すべての未解決イシューを探す」といった具合です。エージェントはイシューを取り出し、引用箇所を抜き出し、それぞれを私たちが行った特定のアーキテクチャ上の判断に紐付けて、金庫に保存します。「この設定に何日も使ってしまって、コーディングに時間が回らない」という顧客の一言は、どんな社内の主張よりも価値があります。そして今では、それが検証している設計判断にリンクされた状態で、ノートPCを開く前から金庫に入っています。
あまり“人間向けではない”洞察：金庫は人間が読むためではありません。エージェントが消費するためのものです。人間にとっての利益は副作用として得られるだけです。
3. エージェント・ハイブによるテスティング：レビューの前にプロダクトドキュメントをストレステストする
プロダクトレビューについての話をします。人は数週間かけて書き、そして30分でリーダーシップがギャップを見つけて指摘する部屋に入ります。歩いて入る前に、その部屋をシミュレーションできたらどうでしょう？
私はマルチエージェントのループを構築しました――あらゆる主張をストレステストする「Impactful Jerk」エージェント、データを検証するリサーチャー、そしてドキュメントを生成するアーティファクト・ファクトリーです。彼らは並行して動きます。Jerkは、証拠が必要な主張にフラグを立てます。Researcherは、それらを検証して肯定／否定します。レビューに入る時点では、ドキュメントはデータが豊富で、明らかな疑問はすでに答えが出ている状態になります。
4. コンバージェンス・テスティング：実在の顧客の前に合成の顧客を
私たちは開発者向けフレームワークを作っています。では、出荷する前にDXが良いかどうかをどうやって知るのでしょう？
私は、同僚のRustの実験からアイデアを盗みました。フレームワークのドキュメントだけを使ってアプリを作ろうとする、独立した4つのAIエージェントを走らせます。3/4が同じ摩擦ポイントにぶつかったなら、それはフレームワークの問題です。4/4が摩擦ゼロで成功したなら、収束（converged）しています。
私たちは複雑さを段階的に上げてこれを実行しました。Tier 1（ブックマークマネージャー）では、4つのエージェントすべてが同一のアーキテクチャに収束しました。Tier 2（認証で保護されたレシピアプリ）では、4つのエージェントがそれぞれ独立に同じデータベースのキー設計を選びました。私たちが見つけたギャップ（delete()メソッドの欠落、ドキュメント化されていないクエリのフィルタリング）は実際の問題で、人間の顧客がそれに遭遇する前に修正できました。
最も興味深い発見は、私が依頼していなかったものです。あるエージェントが、特定の利用パターンでコストが予期せず跳ね上がっていることに気づき、プロンプト無しでそれをフラグ立てしました。私たちはコストを測るように頼んでいません――それでも測ったのは、実際のアプリを作っていて、起きたことに注意を払っていたからです。これは、通常のベータテストを通じて表面化させるのに何週間もかかったはずのカテゴリの問題で、それが単一の収束テスト実行で見つかったのです。
洞察：実在の顧客の前に合成の顧客を走らせられる。実際の顧客フィードバックは金ですが、出荷した後に届きます。収束テスティングは、その前にシグナルをくれます――しかも、時には、あなたがそもそも見ていなかったシグナルを示してくれることさえあります。
5. 書き直しの瞬間
私たちのプロダクトドキュメントの最初の版では、フレームワークは「意見が強いが柔軟だ」と主張していました。あいまいでした。エンジニアが最初の3つの機能を作り、収束テスティングを実行した後で分かったのは、エージェントが一貫して壁にぶつかる場面があったことです――デフォルト以外にカスタマイズする必要が出たとき、抜け道（escape hatch）を見つけられなかったのです。ドキュメントは思想を説明していました。コードはギャップを明らかにしました。そこで、位置づけを「段階的な開示（progressive disclosure）」から始めるように書き直しました。つまり、最初は意見が強い状態から始め、必要に応じて複雑さを明らかにする。というのも実装が実際にそうなっていて、エージェントが実際に体験したのもそうだったからです。
それがループです。まず作り、作る過程から学び、それからドキュメントを書く。ドキュメントは、願望ではなく現実を記述することで良くなりました。
6. コードが私のコミュニケーションツールになった――特に開発者体験（Dev Experience）で！
ここ2年間の物語は「コードは死んだ――やりたいことを自然言語で説明すればいいだけだ」というものでした。でも、私のワークフローでは、コードは（以前より）さらに重要になりました。単に、機械向けに書くのをやめただけです。
私は、人間とコミュニケーションするためにコードを書きます。
私たちがフレームワークのオンボーディングを代替案とどう比較するか議論していたとき、私は並列に並べた端末のリプレイを作りました。複数のプラットフォーム上で同じアプリを作った様子を、横に並べて見せるのです。各プロダクトのフローに慣れる必要はありません――エージェントが私の代わりにそれをやってくれました。会話は「私たちのDXのほうが良いと思う」から、「これをクリックして、どっちを選ぶか教えて」に変わっていきました。
私のエンジニアは今、各プロジェクトのdemos/フォルダ配下にある「デモ」を、保管庫（vault）へチェックインします。すべてのプロダクトに関する議論には、デプロイ済みのURLが含まれます。体験がどうあるべきかを議論する代わりに、リンクを指して「これ、動く？動かない？」と言うのです。
自然言語は、私がエージェントに話しかける方法です。コードは、私が人に話しかける方法です。
7. エージェントが自信満々に私に嘘をついたとき
この仕組みは魔法ではありません。本当に危険な形で失敗することがあります。しかも、そう見えるのです。
私はエージェントを使って毎月のビジネス・レビューを下書きしています。データ書き出しから指標を取り出し、物語の構成を組み立て、過去のレビューの文体に合わせる。そうすると数日分が節約できます。ところがある月、下書きに「前回のレビュー以降、Xアカウントを追加しました（+Y%）。」のような一文が入っていました。具体的な数値。割合。権威がありそうに見える。私はほとんど提出してしまいました。
そこで尋ねました。「前の期間の数値を、どこから取得したの？」
エージェントは、同じスプレッドシート内で任意に選んだ過去の期間のデータと、今回のデータを比較し、それを「前回のレビュー」と呼んでいました。保管庫には、前回のレビュー文書はありませんでした。合意されたベースラインもありません。エージェントは一見それっぽい数を選び、自信ありげに整形して、そのまま先へ進みました。
私が聞かなかったら、リーダーシップは「その差分はどこから来たの？」と尋ねたはずで、私は答えられなかったでしょう。エージェントは幻覚を見せたわけではありません。計算自体は正確でした。ただ、比較すべき地点が間違っていて、しかもそれが推測だと私に伝えなかったのです。
教訓：エージェントは、技術的には正しいのに文脈的に間違っているとき、最も危険です。 異常な（幻覚の）数字は見抜きやすい。間違った問いに対して本物の数字が適用されるのは、見抜きにくい。私は今、エージェントが生成したあらゆる指標を、ジュニアアナリストの最初の下書きと同じように扱っています。数式だけでなく、手法（メソッド）を検証するのです。
実際に変わったこと
PMの仕事は変わっていません。私は今もプロダクトのドキュメントを書き、レビューを行い、顧客と話し、優先度を決める判断をしています。変わったのはフィードバックループの速度です：
- 顧客の定義は、反復の数週間ではなく数時間で負荷テストされる
- 意思決定は、レビュー会議の中ではなく数分でストレステストされる
- 顧客のシグナルは、数日ではなく数秒で統合される
- 文書は、レビューの後ではなくレビュー前にデータ量が豊富になる
- フレームワークDXは、顧客が文句を言う前に検証される。後ではない
- 議論は、段落ではなくURLで決着する
もう一つのメタ教訓：AIは判断を置き換えたわけではありません。アイデアを持ってから、それが良いと分かるまでの時間を圧縮したのです。
セットアップ（試したいなら）
マークダウンファイルの共有gitリポジトリ— それが「保管庫（vault）」です。あらゆる意思決定、あらゆるフィードバック、すべてのストレステストの出力がここに集約されます。あなたのエージェントはここから読み、チームはここへ書き込みます。好きなように整理してください！
あなたの保管庫を知っているエージェント設定— 各エージェントのシステムプロンプトには、保管庫のパスとフォルダ構造が含まれています。そうすることで、文脈をどこから探してどこに保存すればいいかを理解できます。
PDDのワークフロー— 何より先に顧客を定義することを強制します。ここが最も時間を使う場所です。
マルチエージェントのループ— オーケストレーターがタスクを割り当てます。Context Gathererはチャット/ドキュメント/GitHubから取り込みます。Impactful Jerkがストレステストします。Researcherがコードで主張を検証します。Artifact Factoryがドキュメントを生成します。
収束テスト— 4つの並列エージェントが、あなたのドキュメントから構築します。コンセンサスの問題＝フレームワークの問題。エージェント固有の問題＝ノイズ。
すべてのプロジェクトにある
demos/フォルダ— CDNにデプロイしてURLを共有します。コミュニケーションとしてのコード。すべてを保存する習慣— 保管庫に入っていないものは、起きなかったのと同じです。
この一式は私のターミナルから動かします。特別なインフラは不要です。必要なのはAI CLIツールと、きちんと整理されたマークダウンファイル群だけ。
保管庫はgitにあります。エージェントはJSON設定です。デモはデプロイされています。プロダクトのドキュメントはデータが豊富です。そして、私は今でもこのブログ記事を書く時間を持てました。
