「なぜ?」で掘り下げる“問題の定義”:ユーザー視点で再構築
この記事が役立つ人
- 様々な思考法について学んで実践したい人
- 駆け出しのエンジニア
デザイン思考における「定義」とは、ただ現象を言い換えることではありません。
ユーザー観察や共感から得られた情報をもとに、本質的な課題を「行動可能な問い」に翻訳する作業です。
1. なぜ「定義」が重要なのか?
プロジェクトが迷走する一番の原因、それは「そもそも問いがズレていた」ケース。
たとえば…
- 「売上を伸ばすには?」
- 「広告予算を増やすには?」
このような問いに飛びついてしまうと、根本の原因を見誤ることになります。
実際には、「売上減少」という現象の裏に、
- ユーザーが途中で離脱している
- そもそも欲しいと感じていない
- 最初の印象でつまづいている
…といった深層の問題が隠れているかもしれません。
2. 「なぜ?×5回」で構造を掘る
トヨタの「なぜを5回」 にヒントを得て、表面的な問題の裏にある構造を掘り出します。
問題解決の際、「なぜ?」 という問いを繰り返すことで、根本的な原因を明らかにし、効果的な解決策を導き出す方法です。
このアプローチは、特にビジネスやUXデザインの改善において有効で、単に表面的な問題を修正するのではなく、根本原因を特定して深層的な改善を目指します。
例えば、売上減少の問題が発生した際、単に売上データを改善するのではなく、その原因となるユーザー行動の変化を探り、最初の体験や価値伝達方法に焦点を当てて問題を解決します。
ここでは、ユーザーが初回体験で価値を理解できなかった背景を掘り下げ、その解決策を設計する方法を示します。
このアプローチにより、課題をより深く理解し、実行可能な解決策に結びつけることが可能になります。
例:「売上が落ちてきた」
- なぜ売上が落ちた?
→ ユーザーが継続して使っていない - なぜ継続しない?
→ 最初の体験で満足していない - なぜ満足しない?
→ 価値が分かりにくい - なぜ分かりにくい?
→ 導入時のナビゲーションが弱い - なぜナビゲーションが弱い?
→ 最初の設計段階でUXを考慮していなかった
ここまで掘ると、 焦点は「売上」ではなく「初期UX体験の改善」 にあることが見えてきます。
◆ 売上減少の原因を構造的にひもとく
5Whysを活用した問題解決アプローチを理解したところで、次にその具体的な適用方法を見ていきましょう。
以下の図解では、売上減少という問題を取り上げ、5Whysを使ってその原因を深掘りし、最終的に問題の本質にたどり着くプロセスを示しています。
まず、問題を「なぜ?」と繰り返し問い直すことで、表面的な要因から一歩踏み込んだ根本的な課題に迫ります。
この手法を用いることで、解決策の策定がより明確になり、効果的な改善策を実行できるようになります。
フローチャート
疑似言語
もし「売上が減少している」ならば
なぜ「ユーザーが継続して使っていない」か?
→ 「最初の体験で満足していない」
なぜ「最初の体験で満足していない」か?
→ 「価値が分かりにくい」
なぜ「価値が分かりにくい」か?
→ 「導入時のナビゲーションが弱い」
なぜ「ナビゲーションが弱い」か?
→ 「最初の設計段階でUXを考慮していなかった」
解決策として、最初の設計段階でUXを考慮する必要がある
prolog
% 売上減少の原因
原因(売上減少, ユーザーが継続して使っていない).
原因(継続して使っていない, 最初の体験で満足していない).
原因(満足していない, 価値が分かりにくい).
原因(分かりにくい, 導入時のナビゲーションが弱い).
原因(ナビゲーションが弱い, 最初の設計段階でUXを考慮していなかった).
% 課題解決への問い
課題解決_問い('どうすればUXを向上させられるか?') :-
原因(ナビゲーションが弱い, 最初の設計段階でUXを考慮していなかった).
3. 課題解決の力
深掘りした課題を「どうすれば我々は◯◯できるか?」に言い換えると、
チーム内でアイデアが出やすくなり、建設的な議論に進めます。
- この方法で議論を始めると:
→ ネガティブな問題が、ポジティブな探求の入り口に変わる
4. 課題解決の具体例と書き換え
ケース1:売上減少
- Before:「売上を回復したい」
- After:ユーザーがサービスの価値を自然に感じられる体験をつくれるか?
ケース2:レビューが低い
- Before:「低評価レビューを減らしたい」
- After:初回利用時に期待を超える体験を提供できるか?
ケース3:導入数が伸びない
- Before:「導入社数を増やしたい」
- After:最初の一歩が不安なく踏み出せる導線を設計できるか?
5. チームで共有すべき問いとは?
本質的な問いを見つけても、それがチーム全体で共有されていないと意味がありません。
以下のような工夫が有効です。
- 課題解決への問いを1文に明文化して貼り出す
- 「何を改善しようとしているのか?」を定期的に確認する
- 問いがズレたままアイデア出しが暴走しないようにする
6. まとめ
- 問題は、見えている「現象」ではなく、隠れた「構造」にある
- 「なぜ?」を繰り返して、ユーザーの本当の困りごとに近づく
- 問いを「どうすれば我々は◯◯できるか?」に変換することで、前向きな議論が生まれる
- 良い問いは、良いプロダクトと良いチームの出発点になる
Discussion