5回の「なぜ」で深掘りする問題発見の実践

「表面的な問題」に時間を使っていませんか。原因を深掘りしないまま対応を繰り返すと、同じトラブルが再発し、チームの時間と信頼は失われます。本稿では、現場で即使える実務的な手順として「5回の『なぜ』」を解説します。理論的背景とリアルなケーススタディを通じ、あなたが明日から問題発見に取り組める方法を示します。

問題発見の重要性と「5回の『なぜ』」の位置付け

仕事の多くは「解決」より前に「問題を正しく捉える」ことが肝心です。正しく問題を設定できれば、解決策はシンプルになります。逆に問題設定が曖昧なら、解決策は場当たり的になり、効果は薄くなります。ここで紹介する「5回の『なぜ』」は、根本原因に到達するための最もシンプルで強力なツールです。

なぜ重要なのか

  • 時間効率が上がる:表層対応を繰り返すよりも、一度で根本原因をつぶす方が長期的に効率的です。
  • 品質が向上する:原因を潰すと再発率が下がり、顧客満足度が上がります。
  • 学習効果を生む:チームが共通の原因理解を持てば、組織学習が進みます。

5回の『なぜ』とは何か

もともとはトヨタ生産方式(TPS)で広まった手法で、問題に対して「なぜ?」を繰り返すことで深層の原因を見つける技法です。名前のとおり「5回」が目安になっていますが、本質は「表面的な答えで打ち止めにしない」ことにあります。回数は状況に応じて柔軟に。

「5回の『なぜ』」の理論と実践的手順

手順自体は単純ですが、実務で効果を出すには細かな約束事と観察力が必要です。ここで示すフレームに従えば、誰でも一貫して深掘りできます。

基本手順(ステップ・バイ・ステップ)

  1. 問題を具体的に記述する:誰が、いつ、どこで、何をしたか。客観的事実に落とし込む。
  2. 最初の「なぜ?」を問う:表面の原因を洗い出す。答えは行動や状況として記述する。
  3. さらに「なぜ?」を繰り返す:各回答に対して「なぜそれが起きたのか」を問う。これを少なくとも5回繰り返す。
  4. 原因の検証:仮説として出た根本原因を現場やデータで確認する。
  5. 再発防止策を設計する:人の注意だけに頼らない仕組みを優先する。
  6. 実施とフォローアップ:対策を実行し、効果を測定する。

実務上の注意点

  • 事実ベースで議論する:感情や推測は深掘りの妨げになります。記録、ログ、証言を整理してから始めてください。
  • 原因と対策は分ける:原因特定段階で対策案を混ぜると深掘りが中断されます。まず原因を明確に。
  • 複数の原因を認める:単一原因で説明できない場合は、複合要因として整理します。
  • 「なぜ?」の質を高める:漠然とした「なぜ」では深掘りできません。具体的な事象にフォーカスする質問にします。

ケーススタディ:現場で使う実践例

理屈だけでは説得力に欠けます。ここでは実際の業務シーンを想定し、具体的な対話と判断を示します。あなたの職場の問題発見にも応用できるはずです。

ケース1:ITプロジェクトでのリリース遅延

プロジェクトAで、予定より2週間遅れてリリースがずれ込んだ。簡潔に「なぜ」を追いかけたやり取りを示します。

  1. 問題:リリースが2週間遅れた。
  2. なぜ1:テストで重大な不具合が見つかったから。→なぜ2:テストカバレッジが不足していたから。→なぜ3:要件の変更が頻発し、テスト設計が追いつかなかったから。→なぜ4:変更管理が曖昧で、関係者に情報が周っていなかったから。→なぜ5:意思決定のプロセスとドキュメント化が欠けていたから。
  3. 根本原因:変更管理プロセスの不備とドキュメント運用の欠如。
  4. 対策:変更管理ルールの明文化、レビュー権限の設定、テスト設計の早期着手、CIで自動テストを拡充。

この例で重要なのは、最初に見つかった“不具合”が原因でない点です。表層の事象を起点に深掘りすることで、組織のプロセス改善に結びつけられます。

ケース2:カスタマーサポートのCS低下

あるサービスで顧客満足度が急落。原因を現場のシフトミーティングで検討しました。

  1. 問題:CSスコアが前年同期比で大幅低下。
  2. なぜ1:応答時間が遅くなっているから。→なぜ2:問合せ数が増えているから。→なぜ3:新機能リリース後に予想外の問合せが増加したから。→なぜ4:リリースノートが顧客の利用者視点で不足していたから。→なぜ5:リリースに顧客対応チームが関与していなかったから。
  3. 根本原因:機能リリース時の内部調整不足と顧客情報伝達の欠如。
  4. 対策:リリース前にカスタマーサポートを巻き込む手順の導入、FAQの事前準備、セルフヘルプリソースの整備。

ケース3:製造ラインの歩留まり低下(短めの事例)

歩留まり低下が発生。迅速に現場で5回の「なぜ」を回し、再発防止策を打った。

  1. 問題:歩留まりが5%低下。
  2. なぜ1:特定工程で製品の曲がりが発生。→なぜ2:治具の磨耗が進行している。→なぜ3:定期交換サイクルが守られていなかった。→なぜ4:交換記録の共有が不十分で担当者が把握していなかった。→なぜ5:予防保全の手順が現場に浸透していなかった。
  3. 対策:交換リマインダの導入、作業チェックリストのデジタル化、日次の短い確認ミーティング。

よくある落とし穴と改善策

「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回の「なぜ」を試してみましょう。明日からの行動が変わります。

タイトルとURLをコピーしました