一生懸命コードを書き、徹夜でリリースしたプロダクトが、誰にも見向きもされなかった。
開発者にとって、これほど辛い経験はありません。
なぜ、悲劇は起こるのでしょうか？
それは、「なぜ（Why）」や「何を（What）」を突き詰める前に、「どうやって（How）」から作り始めてしまうからです。
家を建てる時、いきなりレンガを積み上げる人はいません。「誰が住むのか」「どんな暮らしがしたいか」という設計図なしに建てられた家は、誰も住みたくない場所になってしまいます。
プロダクト開発も同じです。成功の確率を劇的に高めるためには、Why What How の正しい順序で思考の階段を登る必要があります。
この記事では、迷える開発チームの羅針盤となる「3つの階層」について解説します。
参考
プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
1. Why：なぜ、そのプロダクトを作るのか？
問い：「誰の、どんな課題を解決するのか？ 我々の使命は何か？」
開発の旅は、IDEを開くことではなく、課題の探求から始まります。このフェーズでは、**「ユーザーの痛み（Pain）」と「自分たちの譲れない想い（Core/Mission）」**を言語化します。
「鍵穴」を見つける作業
素晴らしい解決策（鍵）を作る前に、まずその鍵を差し込むべき「鍵穴（課題）」の形を知らなければなりません。
- ターゲットは誰か？: 誰を助けたいのか。
- どんな課題（Pain）があるか？: 彼らは何に困っていて、既存の解決策ではなぜダメなのか。
- なぜ我々がやるのか（Core）: なぜ、今、自分たちがその課題に取り組む必然性があるのか。
ここを飛ばすとどうなる？
Whyが曖昧なまま進むと、**「誰も欲しがらないものを、完璧な技術で作ってしまう」**という、いわゆる「ビルド・トラップ」に陥ります。まずは、ユーザーインタビューや市場調査を通じて、「本当に解くべき課題」を特定しましょう。
Point: 「機能」ではなく、「ユーザーのストーリー」と「チームの情熱」を定義する。
2. What：何を提供するのか？
問い：「課題を解決する『最高の解決策』は何か？」
「解くべき課題（Why）」が明確になったら、次はその答えとなる**「解決策（Solution）」**をデザインします。ここで初めて、プロダクトの具体的な姿を描きます。
「鍵」を設計する作業
ユーザーの悩み（鍵穴）にカチッとハマる、解決策（鍵）を考えます。
- 提供価値（Value）: ユーザーが得られるメリットは何か。
- ソリューション: 具体的にどんな機能や体験で課題を解決するのか。
- ビジネスモデル: その価値に対し、ユーザーはどう対価を支払うか。
重要なのは「順序」
「こんな機能があったらカッコいい！」という思いつきから始めてはいけません。**「Why（課題）が確からしいと分かってから、What（解決策）をぶつける」**のが鉄則です。
バリュー・プロポジション・キャンバスなどのフレームワークを使い、課題と解決策のフィット（PMFの予兆）を徹底的に検証します。
3. How：どうやって実現するのか？
問い：「アイデアをどう形にし、どう届けるか？」
設計図（What）が完成して初めて、エンジニアリングの出番です。ここで技術選定、アーキテクチャ設計、実装計画といった**「実行（Execution）」**の話が始まります。
「模型」から作り始める
いきなり完成品の「豪邸」を建てようとしてはいけません。まずは**MVP（Minimum Viable Product）**と呼ばれる「雨風をしのげる小屋（模型）」を作りましょう。
- スモールスタート: 必要最小限の機能に絞る。
- 検証: 素早くリリースし、実際にユーザーに使ってもらう。
- 改善: データとフィードバックをもとに、高速で改善サイクルを回す。
この段階での最大の使命は、**「最小限のコストで、学びを最大化すること」**です。
まとめ：迷ったら「Why」へ戻れ
プロダクト開発は、一方通行ではありません。
コードを書いている最中（How）に行き詰まったり、機能の優先順位でチームが揉めたりしたときは、必ず**「一つ上の階層」**に戻って確認してください。
-
どの技術で実装するか (How) で迷ったら
-
What を確認。「そもそも、どんな体験を提供したかったんだっけ？」
-
どんな機能を作るか (What) で迷ったら
-
Why を確認。「そもそも、誰のどんな痛みを解決したかったんだっけ？」
Why What How。
このシンプルなリズムをチームの合言葉にすることで、あなたのプロダクトは「作られるだけのもの」から、「愛され、使われるもの」へと変わっていくはずです。