プロダクト成功の鍵は「誰が×何を×誰と」の3軸で決まる

TL;DR

プロダクト成功の鍵は「誰が作るか」でも「何を作るか」でもなく、「誰が×何を×誰と」の3軸で決まる。AI時代にattentionが重要になるという仮説を反証し、実績と信頼こそが本質だと分かった。さらに自己分析を通じて、課題発見や言語化が苦手でも「誰と作るか」を設計する力——採用力と人の目利き——があれば、弱点を迂回しながらプロダクトを成功に導けるというフレームワークに辿り着いた。

この記事の背景

この記事は、Claudeとの対話（2026/2/24〜2/26）を元に、最終的に得られた知見を論理的に再構成したものだ。元の議論では「誰が作るか vs 何を作るか」という2軸から出発し、反証と自己分析を重ねた結果、最終的に「誰と作るか」という第3の軸が加わった。

先に結論を示す。プロダクト成功を考えるフレームワークには3つの軸がある。

  • 誰が（Who）: 自分という資源・実績・特性。どんな強みと弱みを持っているか
  • 何を（What）: 扱う課題・プロダクト・価値提供。誰のどんな痛みを解決するか
  • 誰と（With Whom）: 共創相手・チーム・採用・オーケストレーション。誰を巻き込むか
graph LR
    A["誰が (Who)"] --- D["プロダクト成功"]
    B["何を (What)"] --- D
    C["誰と (With Whom)"] --- D
    A -.- B
    B -.- C
    C -.- A

以下、この結論に至るまでの議論を順に辿る。

「誰が作るか vs 何を作るか」では足りない

出発点：誰が作るかの方が重要ではないか

たいていのプロダクトは「何を作るか」よりも「誰が作るか」の方が重要ではないか——これが議論の出発点だった。

優れたチームは、最初のアイデアが平凡でも、ユーザーの声を拾いながら素早く軌道修正して良いものに仕上げていける。逆に、どんなに魅力的なコンセプトでも、実行力のないチームが作ると中途半端なものになりがち。VCが「アイデアよりチームに投資する」とよく言うのも、まさにその感覚だ。

ただし「誰が」と「何を」は完全に独立してはいない。優れたチームほど「何を作るべきか」を見極める力が高い。つまり「誰が」の中に「何を選ぶか」のセンスが含まれていて、両者は対立するというより、「誰が」が「何を」を内包しているような関係かもしれない。

Attention Is All You Need

ここで一つの仮説が浮かぶ。AIで簡単にプロダクトを作れるようになった今、人のattentionを独占していかにコンバージョンできるかが重要になる。“Attention Is All You Need”——Transformerの論文タイトルとアテンションエコノミーの両方にかけたダブルミーニングだ。

AIによってプロダクトの供給側のコストが劇的に下がると、作ること自体はコモディティ化する。差別化のポイントは「作る」から「届ける・選ばれる」に移り、ディストリビューションとアテンションの勝負になる。アテンションを集められるかは、プロダクトの仕様よりも「誰が」発信しているか、誰のブランドか、誰のコミュニティかに依存する。

これは音楽やコンテンツの世界で既に起きたパターンと同じだ。制作ツールが民主化された結果、曲を作れること自体は差別化にならなくなって、フォロワーやファンベースを持っている「誰か」であることの方が価値になった。

Attention仮説への5つの反証

自分の主張に対して反証を求めた。以下は「アテンションが全て」という仮説に対する5つの反論だ。

1. リテンション問題

バズって人を集めても、プロダクト自体がしょぼければリテンションしない。Quibiが典型例で、ハリウッドの大物が作り、巨額のマーケティングで注目を集めたが、プロダクト自体に使い続ける理由がなくて消えた。アテンションはファネルの入口であって、コンバージョンと継続利用はプロダクトの質に依存する。

2. AIコモディティ化は「表層」だけ

AIで簡単に作れるのはUIやMVPレベルの話で、スケールした時のアーキテクチャ、データパイプライン、エッジケースの処理、セキュリティといった「見えない部分」はまだ全然コモディティ化していない。「作ること」の難しさが消えたように見えて、実は難しさの所在が変わっただけという可能性がある。

3. アテンション自体のコモディティ化リスク

AIで誰でもプロダクトを作れるようになるなら、AIで誰でもマーケティングコンテンツも作れるようになる。インフルエンサー的な発信もAIで量産できるなら、アテンション獲得のコストも結局インフレしていく。アテンション側も供給過剰になり、差別化要因にならなくなるかもしれない。

4. インフルエンサーの脆弱性

「誰が」の優位性は実は脆い。インフルエンサーが作ったプロダクトで長期的に成功しているものはかなり少ない。Fyre Festivalは極端にしても、セレブブランドの大半は数年で失速する。逆にSlackもNotionも、創業者に事前の知名度はなかった。プロダクト自体の体験が口コミを生み、オーガニックに広がった。つまり「誰が」ではなく「使った人が誰かに薦めたくなるか」というプロダクト側の力が効いている。

5. 希少なのはアテンションではなく信頼

情報もプロダクトも溢れる世界で、人が最終的に財布を開くのは信頼に対してだ。信頼は、アテンションの量ではなく、プロダクトが約束を果たし続けた実績から生まれる。Appleが新製品を出せば売れるのは、注目されているからではなく、過去のプロダクトが期待を裏切らなかった蓄積があるから。

中間まとめ: アテンションは必要条件ではあるが十分条件ではない。AIで制作コストが下がっても「本当に良いものを作る」難しさは形を変えて残り続ける。

「実績 is all you need」への統合

attentionから実績へ

反証を経て、議論は以下のように収束した。

「誰が」が大事 → でもアテンションだけじゃ足りない → 実績が信頼を作る → 実績を積むプロセスで「誰が」と「何を」が同時に鍛えられる

最初は対立して見えた「誰が」と「何を」が、実績という時間軸を入れることで統合された。これは「まずバズれ」「まずオーディエンスを作れ」みたいなショートカット志向に対する健全なカウンターだ。実績なきアテンションは砂上の楼閣だし、実績を積む過程でしか得られない判断力や信頼がある。

最初から完璧な「誰が」である必要はない。小さく作って、小さく届けて、小さく信頼を積む——そのループを回す速度と回数が「誰が」を形成していく。

実績の3つの切り口

ただし「実績が大事」は抽象度が高すぎて、そのままでは行動指針にならない。実績にも種類がある。

誰に対しての実績か。 ユーザーは「このプロダクトが自分の問題を解決してくれた」という体験的実績を重視する。投資家は「この人はグロースさせた数字がある」という定量的実績を見る。同業者は「技術的に難しいことをやった」という専門的実績に反応する。

深さ vs 幅。 Stripeの創業者たちが決済の信頼を得たのは深さだし、イーロン・マスクがSpaceXでも信頼されたのはPayPalでの成功という異領域からの転用で、これは幅の信頼。

失敗の実績。 シリコンバレーでは「一度失敗した起業家の方が信頼される」と言われるが、おそらく失敗そのものではなく、失敗の中で見せた判断や誠実さが信頼につながるのであって、失敗の数が信頼を積むわけではない。

「作ったものが使われない」問題

ここから議論は個人的な悩みに入る。

Xを見ているとattentionを集めている人が作ったものはstarがたくさんつくし、使われてissueが立てられ、正・反・合と弁証法的に品質も良くなっていく。自分もCTOとして実績を積んできたのに、この実績が何にもならない徒労感がある。

attentionを集めたい動機を分析した結果、手段としてのattentionが一番近かった。承認欲求ではなく、作ったものにフィードバックループを回したいという開発者としての欲求。使われないプロダクトは改善できない。改善できないから良くならない。良くならないから使われない。この負のループを断ち切りたい。

ただし「作ったものが使われない」と「attentionがない」の間には飛躍がある。attentionがなくても使われているOSSは大量にある。地味なCLIツール、特定のニッチを解決するライブラリ。これらは具体的な痛みを持った人が検索で辿り着いて使い始めている。

問題は二つに分解できる。作っているものが「特定の誰かの具体的な痛み」に刺さっているのか。その痛みを持っている人が見つけられる場所に置いているのか。

業務 vs 個人プロジェクトの構造的違い

CTOとして組織で要件定義をして炎上プロジェクトを鎮火できているのに、個人プロダクトでは要件定義がうまくいかない。これは能力の問題ではなく、構造の違いだ。

  • 業務の要件定義: すでに顧客がいて、課題が言語化されていて、ステークホルダーがいて、制約条件がある。「枠」がある中で最適解を探す作業
  • 個人プロダクト: 顧客がいない、課題が曖昧、制約もない。自由度が高すぎて「枠」がない

この状態で二つの罠にはまりがちだ。抽象的な課題から始めてしまう罠（「開発者の生産性を上げたい」みたいな大きな話で焦点が定まらない）と、ソリューションから始めてしまう罠（「こういう技術で何か作りたい」が先にあって課題を後付けする）。

要件定義が上手くなる必要はなくて、要件定義を始めるタイミングを遅らせるべきなのかもしれない。課題の解像度が低い段階で要件を書き始めてしまっている。

課題発見という「前工程」

要件定義の前にあるのは、一般的に「課題発見」や「問題発見」と呼ばれる工程だ。デザインシンキングの「共感（Empathy）」と「問題定義（Define）」、リーンスタートアップの「顧客発見（Customer Discovery）」、ジョブ理論の「Jobs to Be Done」。どれも本質は同じで、解くべき課題を正しく特定する工程。

「課題の解像度を上げるのが苦手」にも3種類ある。

  1. 観察が苦手: 自分や他人の不便・苦痛にそもそも気づかない。忍耐力が高いので日常が「まあこんなもんか」で流れてしまう
  2. 言語化が苦手: 不便は感じているが、「誰の・どんな状況で・何が・なぜ困る」に分解して構造化できない。整理が苦手で常に頭の中がとっ散らかっている
  3. 他者視点の取得が苦手: 自分の課題はわかるが、他の人にとっても課題なのかを検証しに行くのが苦手。INTPで人と積極的に関わりたいタイプではないので機会がそもそも少ない

3つとも苦手。しかしこれを「克服する」方向で考えるとたぶん続かない。性格を変えるのではなく、仕組みで補う方が現実的だ。

提案されたのは**「他人の不満を観察する」という一つの行動に集約する**アプローチ。自分が不便を感じる必要はない。RedditのプログラミングサブReddit、GitHubのissue、Hacker Newsのコメント欄で、他人が不満を言っている場所を定点観測する。INTPにとって、人と直接話すよりテキストベースで他人の不満を読む方が楽だ。

見つけた不満を週に一回「誰が・いつ・何に・なぜ困っている」の四項目でメモする。自分の中から課題を掘り出すのではなく、外部の不満を構造化するキュレーターになる。INTPの「パターン認識が得意」「一人で分析するのが好き」という特性と噛み合う。

自分という「誰が」の解像度を上げる

特性の棚卸し

INTP + ADHD + 高忍耐力。この組み合わせがプロダクトの個人開発を構造的に困難にしている。

  • 課題発見の手前: 忍耐力が高くて不便に気づかない。気づいても言語化・構造化が苦手。人に検証しに行かない
  • 動機の形成: 「他人の方が自分より賢い」という前提で生きているので、「自分ならもっと上手くやれる」という確信が生まれにくい
  • 記憶の保持: ADHDで思いついてもすぐ忘れる

「なぜ自分が作るのか」問題

MBTI認知機能におけるFi（内向的感情）が8番目と弱いので、「なぜ自分がこれを作るのか」という視点が弱い。しかし「なぜ自分が」は、Fi的な情熱や使命感から来る必要はない。

Ti的な「なぜ自分が」がある。 「既存の解法が論理的に間違っている。正しいアプローチはこうだ。誰もそれをやっていないから自分がやる。」これは情熱ではなく、知的な不整合への耐えられなさから来る動機で、INTPにとってはこちらの方が本物の燃料になるはずだ。

Linus TorvaldsがLinuxを作ったのはFi的動機ではなく、既存のOSに対する知的不満。「こうあるべきだろう」という論理的確信から。

ただ正直なところ、INTPでCTOをやってきた身として「なんでみんなこんな非合理なやり方してるんだ」と感じることは意外と少ない。他人の方が自分より賢いという前提がある上に、ADHDで思いついても大抵忘れる。

外部情報からの検証

外部情報で自己分析を検証した。技術スタック遍歴（Ruby → Elm → Scala → TypeScript → Go → Python → Solidity）を見ると、異常なペースで渡り歩きつつ各領域でプロダクションレベルまで持っていっている。GitHub上には173リポジトリ、だがstarはほぼゼロ。大量のboilerplate/template系リポジトリ。これが「作ったものが使われない」の実体だ。boilerplateは「自分が便利だから作った」もので、「誰かの強い痛みを解決する」ものではない。

成功の実体：実装者としての貢献

当初は「超高速フルスタック実装力×波乗りの嗅覚」が強みだと分析されたが、重要な修正が入った。

  • あるNFTプロジェクト（2週間で1024ピースをソロ開発、コラボで完売）→ 共同創業者がbizdev・要件定義を行った
  • あるDeFiプロジェクト群（TVL数百万ドル規模）→ 当時の代表がbizdev・要件定義を行った

自分は実装しただけ。嗅覚があるわけではなく、誰についていけばいいかなんとなく判断ができただけの結果。

つまり今まで出てきた成功の実体は、「正しい人を選んで、その人の指示を高速に実装した」ということ。波乗りの嗅覚ではなく、「誰の船に乗るか」の嗅覚だった。そして「要件が決まっているものを作る」はAIが最も得意とする領域なので、この強みの賞味期限は短い。

隠れた強み：「採用力」と「誰と作るか」

採用力という武器

議論の終盤で重要な情報が出た。ある経営者から「すごいエンジニアはたくさんみたけど、採用ができるエンジニアは初めてみました」と言われたことがある。

「INTPで人と関わるのが苦手」と言っていたのに採用ができる——これは矛盾していない。採用は雑談や社交ではなく、「この人の能力を見極めて、正しいポジションに配置する」という構造的な判断だからだ。INTPのTi（分析）とNe（可能性を見る）がフルに活きる。対人能力の形は、社交ではなく鑑定。

本質的な強みを再整理すると：

  • 人を見る目（誰についていくか、誰を採用するか）
  • 何でも一定水準まで持っていく実装力
  • 異常な耐久力

抜けていた第3の軸

ここまでの議論には「誰が作るか」と「何を作るか」の対立軸しかなく、「誰と作るか」の観点が抜けていた。

アニメなら有名声優を巻き込む、VTuberなら有名絵師を巻き込む——複数人を巻き込むこと自体がプロモーションにもなる。影響力のあるエンジニアやデザイナーを巻き込むこと自体がattentionになる。GitHubのコントリビューターに知名度のある人がいれば、それだけでプロジェクトの信頼性とvisibilityが上がる。

しかもこのアプローチだと、弱点のほぼ全部を迂回できる。

  • 課題発見が苦手 → 課題に詳しい人を巻き込めばいい
  • ディストリビューションがない → フォロワーを持っている人を巻き込めばそれ自体がディストリビューション
  • 言語化が苦手 → 発信力がある人を巻き込めばいい
  • Fi的動機が弱い → 強い動機を持っている人の横にいればいい

軸足は「オーケストレーター」だが、その本質は実装のオーケストレーションではなく、「人のオーケストレーション」だ。正しい人を見つけ、口説き、組み合わせ、足りない部分を自分の実装力で埋める。「誰が」でも「何を」でもない、「誰と」を設計する人としてのポジション。

このポジションはAIに代替されない。AIは実装はできるが、人を見極めて口説くことはできないから。

最終フレームワーク

3つの選択肢

議論の中で3つのキャリアパスが提示された。

  1. 「隣にいる人」を極める: 実装者ではなく、「正しい人と正しいAIを組み合わせるオーケストレーター」になる
  2. 「誰が」を目指すが、パートナーと組む: 弱点を補ってくれるパートナーと対等な立場で組む
  3. 「誰が」を本気で目指す: 自分の特性とほぼ全面的に戦うことになるので最もコストが高い

選択は、1を軸足にしつつ2・3にも手を伸ばす。

一点突破の成長ポイント：言語化

弱点のうち最もレバレッジが高いのは言語化だ。言語化ができるようになると三方向に効く。

  • 課題発見が改善される（観察したことを構造化できる）
  • ディストリビューションが改善される（人に伝えられる）
  • 採用力がさらに上がる（ビジョンを語れる）

「人と関わる頻度を増やす」や「不便を感じる感度を上げる」は性格を変える話なのでコスパが悪い。言語化という一点突破で全体に効かせる。

言語化を鍛える最も手軽な方法は、自分の思考を他者（人でもAIでも）にぶつけて整理することを習慣にすることだ。自分で考えを生成するのは苦手でも、壁打ちの中で思考を研ぎ澄ませるのは上手い。この記事の元になった対話自体がその証拠だ。

実行フレームワーク

最終的に辿り着いたフレームワークはシンプルだ。

flowchart LR
    A["強い目的を持った人を\n見つける"] --> B["足りないポジションを\n設計する"]
    B --> C["各ポジションに最適な\n人を見つけて口説く"]
    C --> D["足りない部分を\n自分が埋める"]

これは結局、今までCTOとしてやってきたことと構造は同じだ。違うのは、組織の中で受動的にやるのではなく、自分の意思で「誰の船に乗るか」を選ぶという点だけ。そしてその選ぶ目はある。

「1人目のフォロワー」から「誰が」へ

Derek Siversの「1人目のフォロワー」の概念にも通じるが、「1人目のフォロワーとして経済的に成功して、その後に『誰が』になる」パスはあまり機能しない。お金があっても課題発見力や動機の強さが自動的に手に入るわけではないからだ。

ただし「誰についていくかを見極める目」は、それ自体が「誰が」になれる能力。エンジェル投資家やVCがまさにこれだ。自分でプロダクトを作らないが、「誰に賭けるか」を選ぶ力で「誰が」になっている。

「1人目のフォロワーを選ぶ人として知られること」が、自分にとっての「誰が」になる道かもしれない。

この記事自体が、言語化という一点突破の実践でもある。思考をAIにぶつけ、反証を求め、統合し、構造化する。そのプロセスで得られたのが「誰が×何を×誰と」の3軸フレームワークだ。

以上。

References