「問題が発生した。原因を分析したい。でも、なぜなぜ分析とFTAのどちらを使えばいいのか分からない」
品質管理や安全管理の現場で、こんな悩みを抱えている方は多い。どちらも根本原因分析(RCA)の代表的な手法だが、アプローチがまったく異なる。
本記事では、なぜなぜ分析とFTAの違いを徹底比較し、現場で使い分けるための判断基準を解説する。
結論:ボトムアップ vs トップダウン
最も重要な違いは、分析の方向性である。
| 手法 | アプローチ | 開始点 | 適した問題 |
|---|---|---|---|
| なぜなぜ分析 | ボトムアップ | 発生した問題 | 単一の事象、現場の改善活動 |
| FTA | トップダウン | 想定する障害 | 複雑なシステム、予防的分析 |
なぜなぜ分析は「すでに起きた問題」から出発し、「なぜ?」を繰り返して根本原因を掘り下げる。
**FTA(Fault Tree Analysis)**は「起きてほしくない障害」を頂上に置き、論理的に原因を分解していく。
なぜなぜ分析とは(おさらい)
なぜなぜ分析は、1930年代にトヨタ自動車の豊田佐吉氏が考案し、大野耐一氏がトヨタ生産方式(TPS)の中核手法として体系化した。
特徴
- シンプル:紙とペンがあればすぐに実施可能
- 迅速:慣れれば30分程度で完了
- 柔軟:あらゆる問題に適用可能
- 現場向け:専門知識がなくても実施できる
向いている場面
- 製造現場での不良品発生時
- サービス業でのクレーム対応
- IT運用でのインシデント対応
- 日常業務での改善活動
FTA(故障の木解析)とは
FTA(Fault Tree Analysis)は、1961年にベル研究所のH.A. Watsonが、ミニットマンミサイルの安全性評価のために開発した手法である。その後、ボーイング社が航空機の安全性分析に採用し、原子力産業でも広く使われるようになった。
論理ゲートの仕組み
FTAの核心は、ANDゲートとORゲートで原因の関係を表現することにある。
ORゲート(論理和)
- 「いずれかの原因が発生すれば」障害が起きる
- 記号:盾型(∨)
- 例:電源喪失は「停電」または「配線故障」で発生
ANDゲート(論理積)
- 「すべての原因が重なった場合のみ」障害が起きる
- 記号:平底型(∧)
- 例:飛行機墜落は「両エンジン故障」かつ「緊急着陸失敗」で発生
FTAの構造
┌─────────────┐
│ 頂上事象 │ ← 防ぎたい障害
│(Top Event)│
└──────┬──────┘
│
┌──────┴──────┐
│ ORゲート │
└──────┬──────┘
┌───────┼───────┐
▼ ▼ ▼
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ 中間事象 │ │ 中間事象 │ │ 基本事象 │
└────┬────┘ └────┬────┘ └─────────┘
│ │
┌────┴────┐ ┌────┴────┐
│ANDゲート│ │ ORゲート│
└────┬────┘ └────┬────┘
↓ ↓
基本事象 基本事象
FTAが向いている場面
- 航空宇宙産業の安全性分析
- 原子力発電所のリスク評価
- 自動車の機能安全(ISO 26262)
- 医療機器の故障分析
- 複雑なシステムの予防的分析
7つの観点で徹底比較
1. 分析の方向性
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 方向 | ボトムアップ | トップダウン |
| 開始点 | 発生した事象 | 想定する障害 |
| 終着点 | 根本原因 | 基本事象(最小単位の原因) |
2. 適用タイミング
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 主な用途 | 事後対応(再発防止) | 事前予防(リスク評価) |
| タイミング | 問題発生後 | 設計・計画段階 |
| 頻度 | 問題発生ごと | プロジェクト初期・変更時 |
3. 複雑さへの対応
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 単一原因 | ◎ 最適 | ○ 可能だが過剰 |
| 複数原因 | ○ 分岐で対応 | ◎ 論理ゲートで表現 |
| 複雑なシステム | △ 限界あり | ◎ 網羅的に分析 |
4. 定量分析
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 確率計算 | × 不可 | ◎ 故障確率を算出可能 |
| リスク評価 | 定性的 | 定量的 |
| 数学的根拠 | なし | ブール代数に基づく |
5. 所要時間
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 準備時間 | 数分 | 数時間〜数日 |
| 実施時間 | 30分〜1時間 | 数日〜数週間 |
| 専門知識 | 不要 | 必要 |
6. チーム規模
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 最小人数 | 1人でも可 | 3人以上推奨 |
| 必要スキル | ファシリテーション | システム工学、確率論 |
| 外部支援 | 不要 | 専門家が必要なことも |
7. アウトプット
| 観点 | なぜなぜ分析 | FTA |
|---|---|---|
| 成果物 | 原因チェーン、対策案 | フォルトツリー図、故障確率 |
| 再利用性 | 低い(個別事象向け) | 高い(システム全体に適用) |
| 規格対応 | 一般的なQC活動 | ISO 26262、IEC 61025など |
使い分けフローチャート
現場で迷ったときは、以下のフローで判断しよう。
問題が発生した?
│
├─ YES → 単一の事象か?
│ │
│ ├─ YES → なぜなぜ分析
│ │
│ └─ NO → 複数システムが関与?
│ │
│ ├─ YES → FTA
│ └─ NO → なぜなぜ分析(分岐対応)
│
└─ NO → 予防的分析が目的?
│
├─ YES → システムの複雑さは?
│ │
│ ├─ 高い → FTA
│ └─ 低い → FMEA または予防的なぜなぜ
│
└─ NO → まず問題を特定
判断基準まとめ
なぜなぜ分析を選ぶべきケース
- すでに問題が発生している
- 原因が比較的シンプル
- 迅速に対策を打ちたい
- 現場主導で改善活動を行いたい
FTAを選ぶべきケース
- 複雑なシステムの安全性を評価したい
- 故障確率を定量的に算出したい
- 規格(ISO 26262など)への適合が必要
- 設計段階でリスクを事前に洗い出したい
両手法の併用パターン
実務では、なぜなぜ分析とFTAを組み合わせて使うことも多い。
パターン1:FTAで全体像 → なぜなぜで深掘り
大規模なシステム障害が発生した場合、まずFTAで障害経路を網羅的に洗い出し、特定された各経路をなぜなぜ分析で深掘りする。
パターン2:なぜなぜで発見 → FTAで検証
なぜなぜ分析で特定した根本原因が、本当にシステム全体に影響するかをFTAで検証する。
パターン3:日常はなぜなぜ、重大事故はFTA
軽微な問題はなぜなぜ分析で迅速に対応し、重大事故や安全に関わる問題はFTAで徹底分析する。
AIを活用した効率化
従来のなぜなぜ分析やFTAには、以下の課題があった。
- なぜなぜ分析:属人的になりがち、分岐の管理が複雑
- FTA:専門知識が必要、作成に時間がかかる
こうした課題を解決するのが、AI支援ツールである。
📱 WhyTrace Connect - AIなぜなぜ分析ツール
業種と問題を入力するだけで、AIが自動的になぜなぜ分析ツリーを生成。分岐する複数原因も自動で整理し、対策案まで提案する。
- 10業種対応の専門フレームワーク
- 複数原因の分岐を自動管理
- FTA的な網羅性をなぜなぜのシンプルさで実現
まとめ
なぜなぜ分析とFTAは、どちらも根本原因分析の強力なツールである。
- なぜなぜ分析:発生した問題から根本原因を掘り下げるボトムアップ手法。シンプルで迅速、現場向け。
- FTA:想定する障害から原因を論理的に分解するトップダウン手法。複雑なシステムの予防的分析に最適。
どちらか一方が優れているわけではない。問題の性質、分析の目的、利用可能なリソースに応じて、適切な手法を選択することが重要だ。
現場の改善活動にはなぜなぜ分析、システムの安全性評価にはFTA。この使い分けを意識することで、より効果的な問題解決が可能になる。