# AIがPM・デザイナー・エンジニアを一人に束ねるとき、誰が異を唱えるのか > AIによって一人でプロダクト・デザイン・エンジニアリングを担えるようになった。だが、自分の方向性を問いただすのは誰か。実体験・プロダクトリスク・ポパーの反証精神をもとに、着手前の需要確認・最小バージョンでの操作観察・継続投資前の成果確認という三つのチェックを論じる。 - Author: Paul Kuo（郭曜郎） - Date: 2026-10-25 - Pillar: 知性と秩序 / Intelligence & Order - Tags: スーパーソロ, 人と機械の協働, プロダクトマネジメント, ユーザーテスト, 検証と確認, ポパー, 反証精神 - Canonical: https://paulkuo.tw/ja/articles/one-person-triad/ - Language: Japanese (日本語) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/one-person-triad.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- 今年二月、私はまだTerminalを使えなかった。コンピューター上のコマンドライン・ツールのことだ。Claudeと12日間協働した後、四言語対応のウェブサイトと一連の自動化システムを作り上げた。かつてはエンジニアに頼んでいた作業を、自分で引き受けられるようになった（[その12日間の記録](/ja/articles/super-individual-case-study)）。 だが、作れるようになってから、もう一つの問いが生まれた。自分が方向を間違えているとき、誰がそれを判断するのか。 あの12日間、Claudeが書いた最初のバージョンの記事を私は半分削った。提案されたデータベース設計を二度覆した。どの判断も私が下した。しかし一人で自分の理解できる誤りを拾い上げられるからといって、自分の不慣れな問題まで見えるとは限らない。 Thorsten Ballがソフトウェア開発の未来について述べた予言の中に、PM・デザイナー・エンジニアの分業はなくなるという一項がある。この数カ月の自分の働き方が頭に浮かんだ。エンジニアリング・デザイン・プロダクトの意思決定を、AIと一緒にこなす場面が増えている。 彼の判断は理解できる。しかし三つの役割が一人に収まったとき、テーブルの向こう側に座って問いを投げてくれる人も、一緒に消えてしまうかもしれない。 では、誰が異を唱えるのか。 ## AIが作業を束ねたとき、プロダクト判断も一人で担えるか？ Thorsten Ballは2026年9月19日、[ソフトウェア開発の未来についての16の見解](https://thorstenball.com/blog/2026/09/19/what-i-believe-about-the-future-of-software-development/)を書き記した。 以下は原文の順序に沿った日本語の要約であり、各予測に対する彼のトーンを残している。これらは2026年9月時点における彼の観察と判断であり、業界の確定的な結論ではない。 この記事で主に取り上げるのは、表で太字にした4・5・10の三点だ。分業の形が変わるかもしれないこと、プロダクト判断の重要性は変わらないこと、そして要件そのものが誤っている場合があること。 | 番号 | Thorsten Ballの見解（日本語要約） | | --- | --- | | 1 | コードを一行ずつレビューする習慣は消え、人間はシステム全体の確認へ移行する。 | | 2 | ユニットテストも消える可能性がある。 | | 3 | 手でコードを書く技術は失われる。 | | **4** | **ソフトウェアでビジネス上の問題を解決し、リリースを判断し、フィードバックを得ることがより重要になる。** | | **5** | **多くの誤りはコードのバグではなく、要件の誤りから生じるようになる。** | | 6 | AIが誤り発見に参加できるようになり、現行のオープンソースのあり方は合理性を失う。 | | 7 | 人間によるパフォーマンス最適化が必要な場面は少数にとどまる。必要なときはモデルが対処できる。 | | 8 | 人間はコマンドラインやエディタなどの開発ツールを直接使わなくなる。 | | 9 | トークンが新たな計算パラダイムになる。 | | **10** | **PM・デザイン・エンジニアリングの三者分業は消滅する。アジャイルとScrumは退場し、チケットを渡すだけのエンジニアは価値を失う。** | | 11 | 大企業と小企業の開発スタイルはさらに乖離し、スタートアップが大企業の手法をそのまま真似ることはますます的外れになる。 | | 12 | 人間による保守のしやすさを前提とした「良いコード」の基準は、重要でなくなるかもしれない。 | | 13 | 十分なトークンを確保するコストが、一部の人の競争力を奪う。 | | 14 | 安価なモデルが使われるかは不透明だ。より賢いモデルの方がミスが少なく、往復回数も少ない。 | | 15 | モデルはインターフェースをリアルタイムに生成するようになり、固定メニューや設定ページへの需要は減る。 | | 16 | 旧来のソフトウェアから新しいものへの移行には一世代かかる。10年後もコードを書く人はいるだろう。 | 私の読み方では、彼が重視する判断は消えていない。ただ、ソフトウェアを作る人間が自ら背負うことになる。もう一つの予言の方が気になる。将来の多くの誤りは、最初から間違ったものを要求したことに起因するという点だ。 一人でできることが増えると、かつて複数の人間に分散していた責任が自分に集中する。私の経験から言えば、確かに三人で分担する必要のない作業は出てきた。しかしそれだけでは、業界全体で三つの職種がどれだけ減るかを判断する根拠にはならない。 私がより気にしているのは別のことだ。提案・制作・評価をすべて自分でこなすとき、方向が間違っていると気づかせてくれるものが、まだ残っているかどうか。 ## PM・デザイナー・エンジニアは、それぞれ何を防いでいたのか？ プロダクトアドバイザーのMarty Caganは[「The Four Big Risks」](https://www.svpg.com/four-big-risks/)の中で、プロダクトリスクを四種類に分け、主に三つの役割が担うとした。このうちPMは、需要があるかと、ビジネスとして成り立つかの二つを担う。平たく言えば： - **PMが問う：** 使ってもらえるか、あるいは対価を払ってもらえるか？ビジネスとして成り立つか？ - **デザイナーが問う：** ユーザーは理解でき、操作の仕方がわかるか？ - **エンジニアが問う：** 今ある時間・技術・リソースで実現できるか？ この四つのリスクは、人数が減っても消えない。ユーザーに求められ、操作しやすいプロダクトでも、維持コストが高すぎれば続けられない。 分業には、もう一つの価値があると私は思っている。それぞれ異なる問題のために声を上げる人がいることだ。エンジニアが「作れる」と言っても、デザイナーは「ユーザーに理解できない」と指摘するかもしれない。両者が納得しても、PMがさらに「投資する価値があるか」と問う。 三つの席が一つになると、そのやり取りは同じ頭の中で起きる。自分と議論して自分が負けることは難しい。負けるのはたいてい、自分が最も不慣れな側だ。わからない種類の誤りは、代弁する声も持ちにくい。 ![4コマ漫画：PM・デザイナー・エンジニアは、それぞれ何を防いでいたのか？ それぞれ異なる問題のために声を上げる人がいることだ。 使ってもらえるか？対価を払ってもらえるか？ビジネスとして成り立つか？ ユーザーは理解でき、操作の仕方がわかるか？ 今ある時間・技術・リソースで実現できるか？ エンジニアが「作れる」と言っても、デザイナーは「ユーザーに理解できない」と指摘するかもしれない。両者が納得しても、PMがさらに「投資する価値があるか」と問う。 三つの席が一つになると、そのやり取りは同じ頭の中で起きる。 自分と議論して自分が負けることは難しい。負けるのはたいてい、自分が最も不慣れな側だ。 一人でできることが増えるほど、自分の判断が覆される機会を残さなければならない。](/images/articles/one-person-triad/01-three-chairs-v2-ja.svg) ## コードが正常に動いていても、プロダクトが間違っている理由 AIで予約システムを作ったとしよう。日付が選べて、データが保存でき、通知が届く。これらの機能が要件どおりに動いていることを意味する。 しかしユーザーはアカウント登録を嫌がり、結局電話で予約するかもしれない。機能がすべて正常でも、プロダクトがユーザーの問題を解決しているとは限らない。 ソフトウェアエンジニアリングでは[「検証」と「確認」](https://www.nasa.gov/ivv-overview/)という二種類のチェックが区別される。検証はプロダクトが仕様に合致しているかを問い、確認は実際の使用上の需要を満たしているかを問う。前者を通過しても、後者が通過するとは限らない。 私はOpenAIのCodex・xAIのGrok・GoogleのAntigravityを使ってClaudeのアウトプットをレビューし、テストと組み合わせながら重要な事実は一次情報源に照合している。この手法と踏んできた失敗については[「AIにより大きなことをやらせたいなら、先に誤りを捕まえる仕組みを作れ」](/ja/articles/ai-ambition-is-infrastructure)に書いた。複数モデルによるレビューは誤り発見を助けてくれる。しかし複数のモデルが同意しても、結果が正しいことにはならない。 特に需要の判断については慎重でなければならない。Anthropicが[2023年の研究](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)で、テストした五つのAIアシスタントが四種類のテキスト生成タスクにおいてユーザーの意見に迎合する傾向を示すと報告している。これが今日のすべてのモデルの振る舞いを直接示すわけではない。それでも私は、モデルの賛同を需要が成立した証拠として扱うべきではないと考える。 四月に[「人月神話の終わり」](/ja/articles/beyond-man-days)を書いた際、AI協働力の評価フレームワークを複数のモデルに反論させ、三ラウンドのストレステストを行った。議論は論証の穴を見つけるのに役立ったが、実際に使いたい人がいるかどうかには答えられなかった。その答えは、ユーザーから直接得るしかない。 ## 異を唱えてもらうことを、本物の検証に変えるには？ 箴言27章17節にある。「鉄は鉄をもって砥ぎ、人はその友をもって砥ぐ。」人は他者によって磨かれる。しかし反対意見があれば正しいとは限らない。反対意見の価値は、検証すべき問いを見えるようにしてくれる点にある。 ここでポパーの反証精神を思い起こす。一つの考えが信頼に値するためには、現実によって覆される機会が与えられなければならない。 だから、誰かに異を唱えてもらうだけでは不十分だ。私はまず明確にする必要がある。このプロダクトは誰のどんな問題を解決すると信じているか。どんな結果が現れたとき、自分の判断が間違っていたと認めるか。そのうえで世に出し、ユーザーに試してもらい、結果を受け取る。 AIはアイデアの量産を助け、検証の設計も手伝える。しかし結果が予期に反したとき、判断を変える意志を持つかどうかは、依然として自分の責任だ。 ポパーは『推測と反駁』のこの[抜粋](https://tildesites.bowdoin.edu/~j.knockel/falsification/)で、科学理論がどのように検証を受けるかを論じている。私がプロダクト開発に借用したのはこの態度だ。どんな結果が自分の主張に疑問を投げかけるかを事前に示し、真剣に試みる。暫定的に反証されていなくても、永遠に正しいとは言えない。 たとえば、あるツールが作業を速くすると信じているなら、ユーザーに従来の方法と比べてもらい、学習時間や修正作業の時間も含めて計測すべきだ。速くならなければ、自分がどの部分を誤って判断したかを検討する。一度のテストがうまくいかなくても、方向性全体が間違っているとは限らない。しかし毎回、元の仮説を守るための言い訳を探していてはいけない。 ## 一人でプロダクトを作るとき、三つのチェックをどう残すか？ この考えを日常の作業に組み込むとしたら、三つのタイミングから始める。毎回、元の判断・見えた結果・次に変えることを書き留めておく。 ### 着手前：問題が本当に存在するか確認する まず一文を書く。「誰のために、どんな状況で、どんな困りごとを解決するのか？」次に、その問題を実際に経験した人を探し、前回どうやって対処したか、どこが不便だったかを聞く。 「このアイデア、どう思いますか？」という問いかけは、遠慮がちな賛意を引き出しやすい。「前回この問題に遭遇したとき、どう解決しましたか？」の方が、具体的な経験を引き出せる。相手がそもそもその困りごとを持っていなければ、機能を足す前に需要や対象ユーザーを見直す。AIはインタビューの整理を手伝えるが、話者の経験をモデルが代わりに埋めることはできない。 ### 最小バージョンを作った後：ユーザー自身に操作してもらう まずプロダクトが最も重要な一つのことを完結できる状態にする。許容できる時間とコストの範囲内で安全に動かせることを確認してから、ユーザーに操作してもらう。タスクを伝えた後は、手順を逐一教えずに、どこで止まり・誤解し・諦めるかを観察する。 このステップは、デザイナーが本来投げかけていた問いを補う。自分にとって当たり前の操作が、他者にも伝わるか。詰まった箇所を直し、また試してもらう。機能テストと実際の操作観察は、どちらも記録に残す。 ### 継続投資の前に：振り返り、続ける価値があるか確認する 試用前に、この一回で観察する結果と期限を決めておく。プロダクトの用途に応じて、タスクにかかる時間が減ったか・次回また使いたいと思うか、事業として取り組む場合は実際に対価が発生しているか・サービスや維持のコストが負担できるかを見る。 これらの結果を、制作に関与しておらず率直に問題を指摘できる人に見せ、こう尋ねてもらう。「今ある証拠は、継続投資を支えるに足りるか？」その人が代わりに決定する必要はない。しかし自分が言い訳を始めていないか、達成できなかった目標を「重要ではなかった」と言い換えていないかを気づかせてくれる。 証拠が不十分なら、範囲を絞って再試行する。需要が成立していなければ、方向を変えるか止める。三つのチェックは修正の根拠を与えてくれるが、プロダクトの成功を保証するものではない。 ## 私も旗を立てておく Thorstenは自分の予言を公開し、後で答え合わせができるよう残した。私も今この瞬間の仕事の原則を残しておきたい。一人でできることが増えるほど、自分の判断が覆される機会を残さなければならない。 AIはアイデアを形にしやすくしてくれる。自分には、そのアイデアが作る価値がないかもしれないと気づく機会を、自分で残しておく責任がある。 [知性と秩序](/ja/topics/ai/)のテーマページから、このシリーズの他の記事も読める。