■ Whyがないと起こる問題:
過剰対応のリスク: 必要以上の機能を追加してしまう。
不適切な解決策: 根本的な問題解決につながらない。
機会損失: 別のより良い解決策を見逃す。
■ 具体的な例:
飲食店の「カレーを辛くしてほしい」という要望。Whyが「インフルエンサーのため」と分かれば、「辛さ調整トッピング」といったより価値のある解決策が生まれる。
プロダクト開発の例として、「ユーザー一覧のCSVダウンロード」や「ユーザー削除機能」。Whyを掘り下げることで、別の機能で代替可能だったり、「削除」ではなく「無効化」が適切な解決策であったりする可能性がわかる。
■ Whyを明確にすることのメリット:
最適な解決策が見つかる。
開発スピードが上がる。
将来の拡張が容易になる。
チーム全体の共通認識が生まれる。
機能削除の判断が的確になる。
■ Whyが書かれない理由と解決策:
理由: Whyの必要性を知らない、言語化が難しい、本質的な課題を理解していないなど。
解決策: テンプレートの作成、一緒にWhyを作る、「困りごと」から始める、5W1Hで掘り下げるなどのアプローチが提案されています。