5 Whys（5回のなぜ）は、問題の表面的な症状ではなく、根本原因を掘り当てるための問いの連鎖技法です。問題定義フェーズで最もシンプルかつ強力なツールのひとつで、「なぜ？」という問いを5回繰り返すことで、思い込みを剥がし、本質的な課題を可視化します。

概要

ワークショップでよく起こるのは、チームが「問題だと思っていること」と「本当の問題」がずれているケースです。たとえば「ユーザーがアプリを使い続けない」という課題に対して、すぐに「UIを改善しよう」という解決策へ飛びつく。しかし実際にやってみると、なぜを掘り下げた先に「そもそも価値提供自体がずれている」という根本原因が見えてくることがよくあります。

5 Whys はもともとトヨタ生産方式の父・大野耐一が製造ラインの問題解決に用いたフレームワークです。デザイン思考では、ユーザーリサーチで得た観察や発言を起点に、インサイトを掘り下げるプロセスとして広く応用されています。

ステップ

Step 1：問題文を書く

ホワイトボードの中央に、観察された問題や行動をひとつ書きます。主語と動詞を含んだ具体的な文にすることが重要です。「アプリの離脱率が高い」ではなく「新規ユーザーの70%が3日以内にアプリを削除する」のように、数値や行動を入れると掘り下げが深まります。

Step 2：最初の「なぜ？」を問う

「なぜそれが起きているのか？」とチームに問い、思いつく理由を全員から引き出します。この段階では多様な視点を収集することが優先で、正解を急ぐ必要はありません。複数の「なぜ」が出てきたら、それぞれの枝を独立して掘り下げます。

Step 3：「なぜ？」を4回繰り返す

最初の答えに対して再び「なぜそうなるのか？」と問います。これを計5回繰り返すことで、原因の連鎖が見えてきます。 5回という数字は目安であり、3回で根本原因に到達する場合もあれば、7回必要な場合もあります。重要なのは「もう答えられない」というレベルまで掘り下げることです。

Step 4：根本原因を特定する

連鎖の末端にある原因が根本原因の候補です。「この原因を解決すれば、連鎖上のすべての問題が解決される」という確認を行います。根本原因はしばしば、組織のプロセス、インセンティブ構造、コミュニケーションのズレといった「システム的な問題」に行き着きます。

Step 5：How Might We へ変換する

特定した根本原因をHow Might We（HMW）の問いに変換することで、問題定義フェーズから創造フェーズへの橋渡しができます。「ユーザーが価値を認識する前に離脱してしまう」という根本原因なら、「どうすれば初日のユーザーに価値を実感してもらえるか？」という問いになります。

実例：飲食店の予約キャンセル問題

あるレストランでの事例を見てみましょう。

問題文： 予約当日のキャンセルが月20件以上発生している

なぜ？→ キャンセルの連絡をするのが面倒だから
なぜ？→ 電話しか受付手段がなく、営業時間中しか対応できないから
なぜ？→ キャンセル受付の仕組みを電話以外に整備したことがないから
なぜ？→ 「予約はリアルタイムで確認したい」という思い込みがスタッフにあるから
なぜ？→ 予約管理システムを導入したことがなく、手動管理が前提になっているから

根本原因： 予約管理の業務フローが「リアルタイム手動対応」を前提に設計されており、非同期のキャンセル受付を想定していない。

この例から分かるように、最初に見えている「キャンセルが多い」という症状と、根本原因の間には5ステップの距離があります。UIを改善しても、プロセスを変えなければ問題は解決しません。

ファシリテーションのコツ

チームで問うことの価値

5 Whys は個人で行うより、多様な視点を持つチームで行う方がはるかに質が高くなります。 エンジニア、デザイナー、ビジネス担当者が同じ問いに向き合うと、それぞれの専門知識から異なる「なぜ」が出てきます。この交差点に根本原因が隠れていることが多いです。

「なぜ」の品質を上げる問いかけ

「なぜですか？」という直接的な問いは、反射的な「分からない」を引き出すことがあります。代わりに「何がそうさせているのでしょうか？」「どんな状況がそれを引き起こしていると思いますか？」というプロセスを問う形に変えると、より深い考察が出やすくなります。

仮説と事実を分ける

5 Whys のセッション中に出てくる「なぜ」は、多くが仮説です。付箋の色を変えるなど、「確認済みの事実」と「チームの仮説」を視覚的に区別することで、後から検証すべきポイントが明確になります。

よくある失敗と対策

症状を問題文にしてしまう

「ユーザー満足度が低い」のような曖昧な問題文を起点にすると、「なぜ？」の答えも曖昧になります。問題文は観察された具体的な行動や数値から始めるのが鉄則です。ユーザーインタビューや行動データを参照して、問題文を具体化しましょう。

答えを誘導してしまう

すでに解決策を持っているファシリテーターが「なぜ機能が少ないのだと思いますか？」と誘導的に問うケースがあります。「なぜ」の答えはチームから引き出すものであり、ファシリテーターが用意するものではありません。 オープンな問いを保ち、全員の声を拾う場を作ることが重要です。

「分からない」で止まってしまう

根本原因に近づくにつれ、「なぜそうなっているか分からない」という状況が出てきます。これは根本原因への到達のサインでもあり、次に何を調査すべきかのヒントでもあります。「分からないこと」をホワイトボードに書き出し、リサーチのアジェンダとして扱いましょう。

ポイント

問題文を具体化する — 行動・数値・文脈を含んだ文から始める
チームで掘り下げる — 多様な専門性が「なぜ」の質を上げる
仮説と事実を区別する — 後の検証計画に活かす
5回は目安 — 根本原因に到達したと思えるまで継続する
HMWへつなぐ — 根本原因を問いに変換して創造フェーズへ進む

5 Whys で特定した根本原因は、How Might Weに変換して創造フェーズへと持ち込みます。また、ユーザーインタビューの分析時に親和図法（Affinity Diagram）と組み合わせることで、複数のインサイトを体系的に整理できます。

参考文献

Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988
Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018）
IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015