Claude CodeからCodexへ。何度もピボットしながら気づいたこと

「また方向を変えることになりました。」

ここ数ヶ月、この状況を何度か繰り返しています。

プロダクトを作り始めて、MVPを作り切る前に「これじゃない」とわかって、方向を変える。これをすでに2回やりました。

恥ずかしいことではないと自分に言い聞かせながら、せっかくなので記録しておきます。

1回目：BtoBマーケティングのコックピットツール

最初に作ろうとしたのは、BtoBマーケ担当者のためのコックピットツールでした。

自社と競合のWebサイトを読み込んで、そこからマーケティングの改善提案を出す。自分のサイトと比較して「ここが弱い」「こういう打ち手がある」と教えてくれる仕組みです。

Claude Codeで作り始めて、基本的な機能はひと通り実装できました。Webサイトを解析して、提案を返すところまでは動きました。

ただ、MVPを触ってみて気づきました。

毎月使い続ける理由がない。

競合比較は、最初の1回で十分でした。一度見たら、そうそう見返すものじゃない。月額で課金するには定期的に使われる設計が必要なのに、そこを作りきれませんでした。

それがわかった時点で、方向を変えることにしました。

2回目：中小企業向けの経営伴走ツール

次に考えたのは、経営者向けの伴走ツールでした。

Webサイトを読み込んで課題を設定するという仕組みは前回から流用しました。そこに「経営者のことを学び続ける」機能を追加しました。

使えば使うほど、その会社の状況を蓄積していく。毎月使い続ける理由を、今度こそ設計に組み込みました。

継続利用の仕組みは作れました。

ただ、今度は別の問題が出ました。

アプリが重厚になりすぎたんです。

経営者の課題は多岐にわたります。財務、人材、マーケティング、競合、組織、キャッシュフロー……どれも重要で、どれも捨てられない。全部カバーしようとしたら、提案の範囲が広がりすぎて、焦点が定まらなくなりました。

「これ、何のツールなの？」という状態です。

作るほど重くなっていく感覚があって、途中で止めることにしました。

ピボットは失敗じゃないと思い始めました

2回の失敗を経て気づいたのは、どちらも作ってみなければわからなかった情報をくれたということです。

1回目は「継続利用の設計がない」。

2回目は「スコープが広すぎる」。

設計書を眺めていても気づけなかった。

動くものを触った時にわかりました。

作る速度が上がると、失敗のコストが下がります。

失敗のコストが下がると、試せる回数が増えます。試せる回数が増えると、学習が速くなります。

ピボットを「また失敗した」と捉えるか、「必要な情報を手に入れた」と捉えるか。ここ最近は、後者の感覚でいられるようになってきました。

そして、ツールもピボットしました

プロダクトだけじゃなく、使うツールも変えました。

Claude CodeからCodexへの移行です。

理由はシンプルで、AIとやりとりできる回数がCodexのほうが明らかに多いからです。ピボットを繰り返す中で「たくさん試せること」の価値を実感してきたので、ツール選びも同じ基準で変えました。

しばらくはCodexで試してみます。

Codexの使い始め方については、Coconalaで入門講座を出しています。「自分も試してみたい」という方はのぞいてみてください。