プロダクト開発を迷走させないための「WHY・WHAT・HOW」の境界線

プロダクト開発の現場で「WHY・WHAT・HOWを意識しよう」という言葉、よく耳にしますよね。 エンジニアとして経験を積み、ただ目の前のコードを書くだけのフェーズを抜けてくると、自然とこういったレイヤーの違いを意識する場面が増えてくるはずです。

しかし、実際のミーティングでは「この機能はReactで書き直すべきか？」というHOWの議論と、「そもそもユーザーはこの機能を求めているのか？」というWHYの議論がごちゃ混ぜになり、結論が出ずに時間が溶けていく……なんてことが日常茶飯事なんです。

これらの層が混同されると、プロジェクトは間違いなく迷走します。 今回は、ソフトウェアエンジニアやマネージャーが絶対に押さえておくべき「WHY・WHAT・HOW」の境界線を整理します。 合わせて、これまでエンジニアがどこに注力してきたのかを振り返りながら、今後のキャリアにおいて「自分はどのレイヤーで価値を発揮していくべきか」を考えるためのヒントをお届けします。WHAT・HOW」の境界線

WHY（なぜ作るのか？）

すべてはここから始まります。プロダクトや機能が存在する「理由」であり、解決すべき「ユーザーの課題」や「生の要求」です。

WHYが不在の開発は、誰も使わない高度なシステムを生み出すだけの無駄な作業なんです。WHYがブレれば、その後のWHATもHOWも全てがドミノ倒しのように崩壊します。

• 該当する開発工程: 企画、要求定義
• 現場のキーワード: ユーザーの課題、目的、ビジネスの目標
• 明確なスタンス: ここで技術（HOW）の話は絶対にNGです。ひたすら「なぜそれをやるのか」という本質的な価値にだけ向き合うべきなんです。

WHAT（何を作るのか？）

WHYで定義された課題を解決するために、「具体的なシステムやサービスとして何を提供するのか」を定義するフェーズです。

「こういう機能が欲しい」という漠然とした要求（WHY）を、システムとして実装可能な「仕様」に翻訳するのがWHATの役割ですよね。

• 該当する開発工程: 要件定義、仕様策定、UIデザイン
• 現場で表現される言葉: 機能要件、仕様書、APIのインターフェース設計
• 明確なスタンス: 「WHAT（何をする機能か）」が決まっていない状態での実装は、ただのギャンブルです。要求を満たす過不足のない要件を定義することが、手戻りを防ぐ唯一の手段です。

HOW（どう作るのか？）

定義されたWHAT（要件・仕様）を、どのような手段で実現するのか。簡潔に言えば「実装」そのものです。ここがエンジニアの主戦場であり、一番テンションが上がる領域なんです。

• 該当する開発工程: 技術選定、アーキテクチャ設計、コーディング、インフラ構築
• 現場で表現される言葉: 技術スタック、DBスキーマ設計、ソースコード
• 明確なスタンス: 最適なHOWは、WHATとWHYの制約の中で決まります。解決すべき課題に対してオーバースペックな技術選定を行うことは、システムの複雑性を無駄に上げるだけのアンチパターンです。

これまでのエンジニアの主戦場：圧倒的な「HOW」への偏重

これまで、私たちITエンジニアが最も注力し、重要視されてきたのは圧倒的に「HOW（どう作るか＝実装）」のフェーズでした。

ビジネス側やPdMが定義した要件（WHAT）を受け取り、それをいかに美しく、高速で、スケーラブルなコードに落とし込むか。最新のアーキテクチャや技術スタックを駆使して、複雑な仕様を堅牢なシステムとして実装することこそが、エンジニアの腕の見せ所であり、最大の価値だとされてきたんです。 「要件を満たすシステムを作る手段」に特化することに、これまでは多くのリソースが割かれていました。

結論

プロダクト開発において、WHY、WHAT、HOWは明確に分離して思考する必要があります。 今、チームが議論しているのは「課題」なのか、「仕様」なのか、「実装手段」なのか。このレイヤーを全員がメタ認知し、議論のスコープを揃えることが大前提となります。