コンサル思考が個人開発者の足を引っ張るとき

「5 Whys」の罠：完璧主義という名の足かせ

コンサルティングの世界において、最も強力な武器の一つは「なぜ？」という問いを繰り返すことです。トヨタ生産方式に端を発する 「5 Whys（なぜなぜ分析）」 は、問題の表面的な現象ではなく、その奥底に潜む本質的な原因（Root Cause）を突き止めるための必須スキルです。

非エンジニアとして独学で開発を始めた当初、私はこのツールを「生存戦略」として握りしめていました。開発スキルが未熟な分、せめて企画だけは完璧でなければ失敗してしまうという防衛本能が働いたのです。

例えば、「ユーザー流入が少ない」という問題にこの思考を当てはめてみましょう。

1. なぜ？ - 宣伝が足りないから。
2. なぜ宣伝をしないのか？ - まだプロダクトが「完璧」ではないと思っているから。
3. なぜ完璧ではないと感じるのか？ - ユーザーを失望させるのが怖いから。
4. なぜ失望を恐れるのか？ - 熟練のエンジニアがつくるサービスに比べて、自分の実装が「素人臭い」と思われるのが不安だから。
5. なぜ「素人臭さ」に執着するのか？ - 非エンジニアというコンプレックスを、華やかな企画書で覆い隠そうとしているから。

コンサルの世界なら、この分析は「完璧なスライド」を生み出し、クライアントを納得させる材料になります。しかし、一人でサービスを作るビルダーの世界では、この「完璧な定義」こそが最大の敵となります。私は論理を使って、自分の「恐怖」を正当化していただけだったのです。

8ヶ月の沈黙：思考の沼にハマった時間

実際、現在公開しているサービスを形にするのに必要な純粋な作業時間は、それほど長くはありません。しかし、このサービスが世に出るまでに8ヶ月という月日が流れました。その空白は、技術的な難易度が高かったからではなく、私の中にある「失敗を許さないコンサル脳」と「失敗を前提とするリーンな実行力」が激しく衝突していたからでした。

独学エンジニアとして、私は常に不安でした。ベテランに比べてバグを直す速度は遅く、予期せぬエラーの解決には数倍の時間がかかる。それを自覚しているからこそ、「ミスを最小限に抑えなければ」という強迫観念が生まれ、それが「もっと徹底した企画」という言い訳に繋がったのです。

「バグを直すのに一週間かかるかもしれない。なら、企画段階でバグが起きない完璧なロジックを組まなければ」
この思考が、私を8ヶ月間デスクに縛り付けました。しかし、正解のない市場において、机上で導き出した「完璧な定義」は、実際のユーザーに触れた瞬間にあっけなく崩れ去ります。「なぜ？」を5回繰り返して辿り着いた結論が、ユーザーにとっては「どうでもいい機能」であることも少なくありませんでした。

コンサルの「パッケージング」とサービスの「実質価値」

コンサルタントは、既に決まった正解をいかに論理的に構造化し、魅力的にパッケージング（包装）して価値を伝えるかのプロです。クライアントはその鮮やかな思考の転換に価値を感じてくれます。しかし、プロダクトの世界は残酷です。ユーザーは開発者の論理的思考の深さなど、一ミリも関心がないからです。

私がどれほど「このサービスはこれこれこういう本質的な問題を定義して誕生した解決策です」とパッケージングしたところで、ユーザーがアクセスして3秒以内に自分の不満を解決できなければ、そのサービスは「失敗」です。最近、私はあえて思考を削ぎ落とし、がむしゃらに作るスタイルを試してみました。その結果、実行スピードは上がりましたが、同時に自分の強みであった「サービスを魅力的に見せる演出」まで抜け落ちてしまったのです。

今のドメインを見ると、荒削りな実装の中に、ユーザーを説得するための「戦略的な演出」が不足していると感じます。これこそが個人開発者のジレンマです。企画に集中すれば動きが止まり、実行だけに集中すればプロダクトの魂が失われる。このバランスをどう取るかが、最大の壁でした。

正解のない世界で「時間」を分配するルール

コンサル思考とリーンな実行力をどう組み合わせるべきか。試行錯誤の末、私は自分なりの「時間分配ルール」を設けました。

1. 企画のゴールデンタイム設定： 「なぜ？」を問う時間は最大3日（72時間）に制限する。それ以上長引くのは「企画」ではなく「迷い」です。
2. 技術的負債の許容： 非エンジニアにとってバグは宿命です。「バグのないサービスを作る」という傲慢さを捨て、「ユーザーと一緒に直していく」という柔軟性を持つ。企画に使う時間を10%削り、その時間をエラーログを読み解くスキルの習得に充てる方が、はるかに効率的です。
3. 価値と包装の分離： コアとなる機能は徹底的にリーン（質素）に作り、ランディングページやストーリーテリングといった「見せ方」にコンサル脳を集中させる。全体を完璧にするのではなく、ユーザーの視線が留まる場所にだけ戦略的エネルギーを注ぐのです。

ぶつかって分かること、ぶつからなくても分かること

もちろん、すべてを「当たって砕けろ」で解決はできません。戦略家として、やらなくても分かる失敗（明らかなUXの欠陥や、既に飽和しているモデルなど）は、企画段階で冷徹に排除すべきです。

しかし、個人開発において私たちが直面する悩みのほとんどは、「ぶつかってみなければ分からないこと」です。自分の定義が正しいのか、ユーザーがこのボタンを押すのか、マネタイズができるのか。これらはデプロイして市場に問うまで、誰にも分かりません。8ヶ月という時間は、私に「完璧な地図など存在しない」ことを教えてくれました。必要なのは立派な地図ではなく、コンパスを持ってジャングルの中を突き進む「生存筋肉」だったのです。

非エンジニアだからこそ、人一倍準備したくなる気持ちは分かります。しかし、その準備があなたを立ち止まらせるなら、それはもう「準備」ではなく「障害物」です。プロより遅いことを認め、その分だけ早く、何度も市場にプロダクトを投げ込むべきなのです。

結局、大切なのは「継続的なフロー」

このゲームに正解はありません。コンサル思考で内実を固めつつ、その思考が自分の足を重くしないよう警戒すること。完璧な定義よりも大切なのは、今日一日、ユーザーに届ける「小さな価値」を実際に形にすることです。

8ヶ月の停滞は無駄ではありませんでした。その時間を通じて、私は「思考の速度」と「手の速度」を同期させる術を学びました。もう、考えすぎて立ち止まることはありません。「なぜ？」を5回問い、6回目には迷わず「デプロイ」ボタンを押す。そうして生まれた無骨なサービスがユーザーの声に揉まれて磨かれるとき、コンサルの論理と開発者の執念が初めて一つになり、本物の価値が生まれるのだと信じています。