✍️

「なぜ?」で掘り下げる“問題の定義”:ユーザー視点で再構築

に公開
この記事が役立つ人
  • 様々な思考法について学んで実践したい人
  • 駆け出しのエンジニア

デザイン思考における「定義」とは、ただ現象を言い換えることではありません。
ユーザー観察や共感から得られた情報をもとに、本質的な課題を「行動可能な問い」に翻訳する作業です。

1. なぜ「定義」が重要なのか?

プロジェクトが迷走する一番の原因、それは「そもそも問いがズレていた」ケース。
たとえば…

  • 「売上を伸ばすには?」
  • 「広告予算を増やすには?」

このような問いに飛びついてしまうと、根本の原因を見誤ることになります。

実際には、「売上減少」という現象の裏に、

  • ユーザーが途中で離脱している
  • そもそも欲しいと感じていない
  • 最初の印象でつまづいている

…といった深層の問題が隠れているかもしれません。

2. 「なぜ?×5回」で構造を掘る

トヨタの「なぜを5回」 にヒントを得て、表面的な問題の裏にある構造を掘り出します。
問題解決の際、「なぜ?」 という問いを繰り返すことで、根本的な原因を明らかにし、効果的な解決策を導き出す方法です。
このアプローチは、特にビジネスやUXデザインの改善において有効で、単に表面的な問題を修正するのではなく、根本原因を特定して深層的な改善を目指します。

例えば、売上減少の問題が発生した際、単に売上データを改善するのではなく、その原因となるユーザー行動の変化を探り、最初の体験や価値伝達方法に焦点を当てて問題を解決します。

ここでは、ユーザーが初回体験で価値を理解できなかった背景を掘り下げ、その解決策を設計する方法を示します。
このアプローチにより、課題をより深く理解し、実行可能な解決策に結びつけることが可能になります。

例:「売上が落ちてきた」

  1. なぜ売上が落ちた?
     → ユーザーが継続して使っていない
  2. なぜ継続しない?
     → 最初の体験で満足していない
  3. なぜ満足しない?
     → 価値が分かりにくい
  4. なぜ分かりにくい?
     → 導入時のナビゲーションが弱い
  5. なぜナビゲーションが弱い?
     → 最初の設計段階で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