「表面的な問題」に時間を使っていませんか。原因を深掘りしないまま対応を繰り返すと、同じトラブルが再発し、チームの時間と信頼は失われます。本稿では、現場で即使える実務的な手順として「5回の『なぜ』」を解説します。理論的背景とリアルなケーススタディを通じ、あなたが明日から問題発見に取り組める方法を示します。
問題発見の重要性と「5回の『なぜ』」の位置付け
仕事の多くは「解決」より前に「問題を正しく捉える」ことが肝心です。正しく問題を設定できれば、解決策はシンプルになります。逆に問題設定が曖昧なら、解決策は場当たり的になり、効果は薄くなります。ここで紹介する「5回の『なぜ』」は、根本原因に到達するための最もシンプルで強力なツールです。
なぜ重要なのか
- 時間効率が上がる:表層対応を繰り返すよりも、一度で根本原因をつぶす方が長期的に効率的です。
- 品質が向上する:原因を潰すと再発率が下がり、顧客満足度が上がります。
- 学習効果を生む:チームが共通の原因理解を持てば、組織学習が進みます。
5回の『なぜ』とは何か
もともとはトヨタ生産方式(TPS)で広まった手法で、問題に対して「なぜ?」を繰り返すことで深層の原因を見つける技法です。名前のとおり「5回」が目安になっていますが、本質は「表面的な答えで打ち止めにしない」ことにあります。回数は状況に応じて柔軟に。
「5回の『なぜ』」の理論と実践的手順
手順自体は単純ですが、実務で効果を出すには細かな約束事と観察力が必要です。ここで示すフレームに従えば、誰でも一貫して深掘りできます。
基本手順(ステップ・バイ・ステップ)
- 問題を具体的に記述する:誰が、いつ、どこで、何をしたか。客観的事実に落とし込む。
- 最初の「なぜ?」を問う:表面の原因を洗い出す。答えは行動や状況として記述する。
- さらに「なぜ?」を繰り返す:各回答に対して「なぜそれが起きたのか」を問う。これを少なくとも5回繰り返す。
- 原因の検証:仮説として出た根本原因を現場やデータで確認する。
- 再発防止策を設計する:人の注意だけに頼らない仕組みを優先する。
- 実施とフォローアップ:対策を実行し、効果を測定する。
実務上の注意点
- 事実ベースで議論する:感情や推測は深掘りの妨げになります。記録、ログ、証言を整理してから始めてください。
- 原因と対策は分ける:原因特定段階で対策案を混ぜると深掘りが中断されます。まず原因を明確に。
- 複数の原因を認める:単一原因で説明できない場合は、複合要因として整理します。
- 「なぜ?」の質を高める:漠然とした「なぜ」では深掘りできません。具体的な事象にフォーカスする質問にします。
ケーススタディ:現場で使う実践例
理屈だけでは説得力に欠けます。ここでは実際の業務シーンを想定し、具体的な対話と判断を示します。あなたの職場の問題発見にも応用できるはずです。
ケース1:ITプロジェクトでのリリース遅延
プロジェクトAで、予定より2週間遅れてリリースがずれ込んだ。簡潔に「なぜ」を追いかけたやり取りを示します。
- 問題:リリースが2週間遅れた。
- なぜ1:テストで重大な不具合が見つかったから。→なぜ2:テストカバレッジが不足していたから。→なぜ3:要件の変更が頻発し、テスト設計が追いつかなかったから。→なぜ4:変更管理が曖昧で、関係者に情報が周っていなかったから。→なぜ5:意思決定のプロセスとドキュメント化が欠けていたから。
- 根本原因:変更管理プロセスの不備とドキュメント運用の欠如。
- 対策:変更管理ルールの明文化、レビュー権限の設定、テスト設計の早期着手、CIで自動テストを拡充。
この例で重要なのは、最初に見つかった“不具合”が原因でない点です。表層の事象を起点に深掘りすることで、組織のプロセス改善に結びつけられます。
ケース2:カスタマーサポートのCS低下
あるサービスで顧客満足度が急落。原因を現場のシフトミーティングで検討しました。
- 問題:CSスコアが前年同期比で大幅低下。
- なぜ1:応答時間が遅くなっているから。→なぜ2:問合せ数が増えているから。→なぜ3:新機能リリース後に予想外の問合せが増加したから。→なぜ4:リリースノートが顧客の利用者視点で不足していたから。→なぜ5:リリースに顧客対応チームが関与していなかったから。
- 根本原因:機能リリース時の内部調整不足と顧客情報伝達の欠如。
- 対策:リリース前にカスタマーサポートを巻き込む手順の導入、FAQの事前準備、セルフヘルプリソースの整備。
ケース3:製造ラインの歩留まり低下(短めの事例)
歩留まり低下が発生。迅速に現場で5回の「なぜ」を回し、再発防止策を打った。
- 問題:歩留まりが5%低下。
- なぜ1:特定工程で製品の曲がりが発生。→なぜ2:治具の磨耗が進行している。→なぜ3:定期交換サイクルが守られていなかった。→なぜ4:交換記録の共有が不十分で担当者が把握していなかった。→なぜ5:予防保全の手順が現場に浸透していなかった。
- 対策:交換リマインダの導入、作業チェックリストのデジタル化、日次の短い確認ミーティング。
よくある落とし穴と改善策
「5回の『なぜ』」は単純ですが、実務でよくあるミスがあります。ここを把握しておけば、成果が格段に変わります。
1. 答えを誘導する質問になる
調査者が結論を先に持っていると、意図的でない誘導が起きます。改善策:調査前に仮説は書き出しておくが、会話では事実確認を優先する。第三者のファシリテータを入れるのも有効です。
2. 単一の原因に固執する
現象は複合要因で起きることが多いです。改善策:原因を一次、二次に分類し、並行して対策を検討します。
3. 「人のミス」で終わらせる
最も陥りやすい罠は「ヒューマンエラー」で閉じることです。人の行動は環境や仕組みに起因する場合が多い。改善策:人のミスを見つけたら、なぜその行動が合理的に見えたのかをさらに深掘りする。
4. 対策が感覚的で検証されない
対策を導入しても効果測定をしないと無意味です。改善策:KPIを設定し、実施後のデータで効果を確認する。必要ならPDCAを回す。
実務で使えるテンプレートとワークショップ設計
ここでは、会議で実際に使えるフォーマットとファシリテーションのコツを紹介します。特に時間制約がある現場で役立つ構成です。
ワークショップの流れ(90分の例)
- 0–10分:現象の共有。ファシリテータが事実を提示。
- 10–30分:一人1分での観察共有。バイアス排除のため事実のみ。
- 30–60分:グループで「なぜ」を回す。ホワイトボードに因果連鎖を可視化。
- 60–80分:根本原因の検証計画を立てる。誰が何をいつまでに確認するか。
- 80–90分:次のアクションとKPI設定。フォローアップ日程の確定。
テンプレート(表)
| 項目 | 記述例 | 誰が担当 |
|---|---|---|
| 問題(事実) | リリースXが2週間遅延 | プロジェクトマネージャー |
| なぜ1 | テスト不備により未検出のバグ発生 | QAリード |
| なぜ2 | 要件変更の追随ができていない | プロダクトオーナー |
| 根本原因(仮説) | 変更管理プロセスが不備 | PMO |
| 対策 | 変更管理ルールの設定、リリース前チェックリスト | PMO、QA |
| KPI | リリース後30日以内の重大不具合数を50%削減 | PMO |
ファシリテーションのコツ
- 問いはオープンに:参加者が自由に観察を述べられるようにする。
- 視覚化:因果関係は図にする。矢印でつなぐだけで、論理の飛躍が見える。
- 時間管理:深掘りは時間を食う。ゴールと時間配分を明確化する。
- 役割分担:記録係、タイムキーパー、ファシリテーターを決める。
まとめ
「5回の『なぜ』」は道具として極めて実用的です。重要なのは道具を使う目的を忘れないこと。すなわち「再発しない組織的な改善」を目指すことです。本稿で示した手順、注意点、テンプレートを使えば、あなたのチームは表面的な対応から脱却できます。まずは次の週のミーティングで、実際に一つの問題をこの手法で深掘りしてみてください。結果を見て、驚くほど学びが出てくるはずです。
一言アドバイス
問題の深掘りは競争力の源です。「なぜ?」を5回投げる習慣をチーム文化にしてください。継続するほど、無駄な仕事が減り、本質的な仕事に集中できます。まずは今日の業務で小さな違和感を一つ選び、5回の「なぜ」を試してみましょう。明日からの行動が変わります。

