プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。

例えば、よくあるものだと

• 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」

• 「検索結果を50件ずつ表示してほしい」

• 「削除ボタンを赤色にしてほしい」

といったものだったりします。
社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。
テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。

どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。

このnoteではなぜ、要望にはWhyが重要でHowが重要ではないか、どうしてWhyを書くと生産性が上がるのかを少し丁寧に解説していきます。

例： カレーの辛さ問題

例えば自分が飲食店の料理人で店長から「カレーをもっと辛くしてほしい」という要望があったとします。

これは典型的な「How」の要望となっています。
確かに「辛くする」という解決方法は書かれている。でも、なぜ辛くしたいのかがわからない。

• 個人的に辛いものが好きだから？

• 大切なお客さんが辛党だから？

• 競合店と差別化したいから？

• SNSでバズりたいから？

• 辛いカレーで流行っているお店がある？

理由によって対応は全く変わってくる。

Whyがないと起こる問題

料理人が「とりあえず辛くしました」で対応すると、こんな問題が起きる。

過剰対応のリスク： 激辛にしすぎて既存顧客が離れる
不適切な解決策： 本当は「選択肢が欲しい」だけかもしれない
機会損失： 辛さ調整機能があれば、もっと多くの人に対応できたかも

本当の解決策を見つけるために

もし「今後来店するインフルエンサーが辛いカレーが好きで宣伝してもらうために好みのカレーを作ってほしい」というWhyがわかれば、こんな解決策が考えられる。

• テーブルで辛さを調整できるトッピングを用意

• 個別に激辛オプションを常備

• 辛さレベルを選べるメニュー開発

単に「辛くする」より、ずっと価値があり、多くの人のニーズを満たせる解決策になります。

プロダクト開発での例

ユーザー一覧のCSVダウンロード

「ユーザー一覧をCSVでダウンロードできるようにしてほしい」という要望が来た際は、「このCSVは経理への提出用なのか？データ分析用なのか？広告配信に使用するのか？ただ見たいだけなのか？」、「ユーザー一覧にはどんな項目が必要なのか」ぱっと見ではわからず、
そもそも解決したい温度感もわからない。

結果、Whyを掘り下げると「新機能アップデートをメルマガで送りたいのでユーザー一覧が欲しくて、名前とメールアドレスの一覧がほしい」だけだったりする。
結果、実は別機能で代替できたり、社内のダッシュボードツールから出力できたりするので機能自体、必要なかったという可能性も充分ありえる。（実際、よくあります）

上記の例で言えば、ちゃんとWhyが書かれていてば作る必要がなかったり、
最低限のものを作るだけで充分な可能性が高い。

チャットツールでの削除機能

例えば、チャットツール（SlackやChatworkのようなもの）を提供していたとする。管理者から「ユーザー削除機能を実装してほしい」という要望が来た。

これは典型的な「How」の要望となっています。でも、チャットツールでユーザーを削除する場合は実はすごく複雑な話になり、考慮すべきことが山ほどあります。

• そのユーザーが投稿したチャットコンテンツはどうする？

• 過去のメッセージ履歴から完全に消す？

• 統計情報や監査ログはどう扱う？

• チャット内で表示される名前はどうなる？

  • 「削除されたユーザー」と表示？それとも完全に匿名化？

• このユーザーが作成したチャンネルの所有権は？

ここで「なぜユーザーを削除したいのか」というWhyがあれば、適切な対応が推測できる。

例えば「退職者が出たのでチャットツールに情報を見れないようにログインできないようしたい」というWhyがあったとする。
この場合、本当に必要なのは以下のようなことかもしれない。

• ユーザーのログインを無効化する（アカウントは残す）

• 過去のチャットコンテンツは業務記録として残す

• 表示名は実名のまま維持（誰の発言かわかるように）

• 新規メッセージの投稿や閲覧だけを制限

つまり「削除」ではなく「無効化」が正しい解決策になる。

B2B SaaSでよくある削除要望の難しさ

僕の経験上、B2B SaaSプロダクトで「削除」に関する要望は特に複雑になりやすい。

なぜかというと、削除対象のデータが他の多くのデータと関連しているから。そして、ビジネス上の要求と技術的な整合性のバランスを取る必要があるから。

実際にあった「削除」要望の例を挙げてみる。

「プロジェクトを削除したい」
→ 実は「アーカイブして検索に出ないようにしたい」

「古いデータを削除したい」
→ 実は「ストレージコストを削減したい」

「テストデータを削除したい」
→ 実は「本番データと混在しないようにしたい」

「契約終了した顧客データを削除したい」
→ 実は「法的要件を満たしつつ、分析用の匿名データは残したい」

どれも表面的には「削除」だけど、Whyを聞くと全く違う機能が必要になる。関連するデータも含めると複雑度ははるかに高くなります。

エンジニアがWhyを聞く理由

エンジニアがしつこく「なぜ？」と聞くのは、意地悪をしているわけじゃありません。"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。

「削除」一つとっても、論理削除、物理削除、アーカイブ、無効化、匿名化など、様々な実装方法がある。Whyがわかれば、最適な方法を選ぶことができます。

Whyがあるとなにが良くなるのか

ここまでWhyの重要性を説明してきたけど、改めて整理してみます。
Whyがあると、下記のようなメリットがあります。

1. 最適な解決策が見つかる

「カレーを辛くして」→「辛さ調整トッピングを用意」のように、より多くの人のニーズを満たせる解決策が見つかる。

2. 開発スピードが上がる

一見逆説的だけど、Whyが明確だとプロダクトの生産性は高くなる。
なぜなら、本当に必要な機能だけを作れる。

3. 将来の拡張が容易になる

設計を行う際にWhyがあることで将来の拡張性を見通した設計にしやすくなります。

4. チーム全体の共通認識が生まれる

Whyが共有されていると、開発中に判断に迷った時も「そもそもの目的は◯◯だから」と立ち返れる。これが意外と大きい。

5. 機能の削除判断が的確になる

将来「この機能要らないんじゃない？」となった時、当時のWhyが残っていれば判断しやすい。「このWhyはもう存在しない」と分かれば、自信を持って削除できる。

機能削除の重要性に関しては下記noteを参照してください

どうしてWhyを書くことができないか？

僕の経験上になりますが、Whyを書いてくれと伝えても要望にWhyが書かれていないケースは本当に多いです。
でも、それは悪意があるわけじゃないのです。
以下のような理由があります。

1. Whyを書く必要性を知らない

多くの人は「具体的な解決策を伝えることが効率的」だと考えています。「カレーを辛くして」と言えば、相手もすぐに理解して実行できると思っています。
でも実際は、その解決策が本当に適切かどうかは、Whyを知らないと判断できないのです。この認識の差は、職種や経験によるところが大きいと考えています。

2. 言語化することが難しい

「なんとなく不便」「何か違う」という感覚的な課題を、明確な言葉にするのは実は高度なスキルとなります。
日常業務で感じる違和感を論理的に説明するには訓練が必要。
エンジニアは日常的にドキュメントやコードで言語化を強いられるが、他職種はその機会が少ない。

3. 本質的な課題を理解していない

「Excelでダウンロードしたい」という要望の裏に「CRMにインポートしたい」という目的があることに、本人が気づいていないケースも多い。
日々の業務に追われていると、「今のやり方」に縛られてしまい、本当の目的を見失いがち。

4. 「機能のライフタイム」への期待値の違い

「とりあえず今だけ使えればいい」と思っている人と、「3年後も使い続ける前提で作る」と思っている人では、必要な情報の粒度が全く違う。
この期待値のズレが、「なんでそんな細かいこと聞くの？」という反応につながる。

どうしたらWhyを書いてもらうようにできるか

Whyを書いてもらうために僕が行ったもので効果があったものを書いてみます。
前提として

• Whyを必要性を労力をかけて理解してもらうこと

• いきなり完璧なWhyを求めないこと

が非常に重要です。

1. テンプレートを作る

すぐに実践できる方法です。
テンプレートがあるだけで少なくとも埋めなきゃいけないという気持ちが働きやすく、確認する人も埋まってなければすぐに気づくことができます。

Before（よくあるテンプレート）:

##タイトル## 詳細

After（Whyファーストテンプレート）:

## 目的なぜこの改善が必要なのか、目的を記載## 影響を受ける人## 現存する課題## 期待される効果## 解決策（なくても可）## 解決策を使うシーン（なくても可）

2. 一緒にWhyを作る

最初から一人で完璧なWhyを書くことはできないので一緒にWhyを作り上げてみる。一度一緒に作るだけで作り方や考え方を学んでもらうことができます。

3. 「困りごと」から始める

完璧なWhyを最初から書こうとすると挫折します。まずは「困っていること」を素直に書くことから始めてもらう。

悪い例：「ユーザー一覧をCSVでダウンロードしたい」
第一歩：「毎月、経理にユーザーデータを提出するのが面倒」
これだけでも、エンジニアは「定期的な経理提出」という文脈を理解できる。

4. 「5W1H」で掘り下げる

困りごとを書いたら、次はこの質問に答えてみる：

• Who（誰が）：経理部門が

• When（いつ）：毎月月末に

• Where（どこで）：管理画面から

• What（何を）：アクティブユーザーの一覧を

• Why（なぜ）：請求書作成のために

• How（どのように）：現在は手動でコピペしている

これを組み合わせると自然にWhyが書ける。（はず）

5. 「現在 → 理想」のギャップを説明してもらう

フォーマット：
【現在】毎月、管理画面を開いて、ユーザー情報を1件ずつコピペしている（30分かかる）
【理想】ボタン一つで必要な情報をダウンロードできる（1分で終わる）

このギャップがWhyになります。

6. 実際の作業を見せてもらう

言葉で説明するのが難しければ、今やっている作業画面を見せてもらう

要望を出す人に「今どうやっているか作業を画面共有して見せてください」とお願いすることで一緒にWhyを考える際の解像度が格段に上がります。

最初は下手でもいいから書いてもらい、一緒にWhyを書いていくことでWhyを言語化する方法を学んでもらいつつ、良い解決策が生まれるという成功体験を積んでもらうことで
常にWhyを書いてもらう文化にしやすいなと思っています。
（実際、最初はみんな、Whyを書くことができなかったのですが徐々に書くことができるようになりました）

最後に

プロダクトマネージャーやエンジニア、デザイナーは、Whyから本当の課題を見つけ出すプロフェッショナルです。彼らに正しいWhyを渡せば、想像以上の解決策（How）が返ってくるはずです。

プロダクトマネジメントにて、お困りごとありましたら、問い合わせいただけると幸いです。