8D/CAPAを“形だけ”にしない是正処置ワークフロー｜暫定→恒久→効果確認の詰まり対策

8DやCAPAは、作り方を知っていても回りません。
回らない理由はだいたい同じで、「暫定対策で止まる」、「効果確認がやられない」、「横展開が口約束で終わる」。
原因分析の手法（なぜなぜ、特性要因図）が正しくても、ワークフローが弱いと最後に崩れます。

1. 8D/CAPAが止まる“3つの場所”を先に潰す

• 暫定対策：やったが証跡が残らない／期限がない／誰が確認するか不明
• 恒久対策：設計変更や工程変更が絡み、ECO待ちで滞留
• 効果確認：確認タイミングが先送りされ、未実施のままクローズ

この3点は“人の頑張り”では解決しません。画面とステータスで固定します。

2. 1案件の基本構造：クレーム/不具合 → 原因 → 対策 → 効果 → 横展開

画面の背骨は単純です。複雑にすると入力が嫌われます。

• 発生（いつ、どこで、何が起きたか）
• 影響（顧客影響、出荷停止、在庫、再発頻度）
• 原因（仮説→確からしさ→確定）
• 対策（暫定／恒久、誰が、いつまで）
• 効果確認（いつ、どう測るか）
• 横展開（対象範囲、完了証跡）

原因の書き方そのものは現場の流儀がありますが、少なくとも「仮説」と「確定」を同じ欄に混ぜないだけで、読みやすさが変わります。

3. ステータス設計：曖昧な“進行中”を作らない

ステータスは細かすぎても回りませんが、雑だと止まります。8D/CAPAなら次くらいが現実的です。

• 受付（情報不足なら「追加情報待ち」へ）
• 暫定対策 実施待ち／実施済（確認待ち）
• 原因分析中（仮説）／原因確定
• 恒久対策 計画中／実施中／実施済（確認待ち）
• 効果確認 待ち／確認中／確認済
• 横展開 待ち／完了
• クローズ

「実施済（確認待ち）」を入れるのがポイントです。やった本人は完了のつもりでも、確認側から見ると未完了のことが多いからです。

4. 証跡（添付）を“あとから探せる”形で残す

是正処置は、文章だけだと説得力がありません。現場写真、手順書改定、検査記録、試験結果が揃って初めて強くなります。
添付を単に貼るのではなく、用途を選ばせます（後で探せる）。

• 暫定対策の証跡（写真、隔離記録、作業指示）
• 原因分析の証跡（測定ログ、解析レポート）
• 恒久対策の証跡（図面改定、工程変更、教育記録）
• 効果確認の証跡（トレンド、再発率、監査結果）

「探せる」状態を作るという点では、評価データ整理と同じ発想です。

5. 恒久対策がECO待ちで止まる場合の逃げ道

恒久対策が設計変更・工程変更に触れると、ECOが通るまで進みません。
ここでCAPA側を放置すると、結局、期限だけが過ぎます。
対策として、CAPAとECR/ECOをリンクし、どこで止まっているか見えるようにします。

• CAPA → ECOリンク（ECO番号、承認状況、切替日）
• CAPA側に「ECO待ち」ステータスを用意

ECR/ECOの設計そのものは 設計変更の申請フロー を土台にすると作りやすいです。

6. 横展開：対象リストを“作って終わり”にしない

横展開は、対象の列挙だけだと必ず漏れます。
「誰が確認し」「何をもって完了とするか」を、対象ごとに持てる形にします。

• 対象（工場、ライン、品番、工程、サプライヤ）
• 対応内容（点検、手順改定、教育、検査追加など）
• 完了証跡（添付 or URL）
• 完了日／確認者

インテンスでも、横展開は“良いこと”として扱われがちですが、実務ではここが一番漏れやすいので、画面側で手当てします。

まとめ

8D/CAPAを回す鍵は、原因分析のテクニックより、暫定→恒久→効果確認→横展開が止まらないワークフローです。確認待ちを明示し、証跡を用途別に残し、ECO待ちを見える化する。これで「形だけのCAPA」から抜けやすくなります。
品質領域の実装イメージは 製造業向けシステム開発例 とも近い話です。