pdca-improvement

PDCA 改善サイクル

使用するタイミング

PDCA は、次の場合に使用します。

• 継続的な改善活動（問題への対応ではありません。その場合は 8D を使用します）
• 結果が不確実なプロセス最適化の実施
• 全面的な展開の前に変更を試験的に導入する場合
• 教訓や監査所見をもとにした体系的な改善
• 新しいアプローチを必要とする品質目標の達成

8D との主な違い： PDCA は、先を見越した改善や、時間をかけて進める改善に使用します。8D は、特定の欠陥や不具合への対応に使用します。どちらも根本原因分析を行いますが、PDCA はより広い範囲を対象とし、全面展開の前にパイロットを実施するステップがあります。

是正処置に PDCA を使用する場合（例：監査所見や繰り返し発生する NC への対応）：ISO 9001 §10.2 に従い、根本原因、処置、VOE を記録するため、是正処置要求（CAR） も開始する必要があります。PDCA は改善手法であり、CAR はガバナンス記録です。

前提条件

• 改善目標が定義されている（目標指標を含む）
• ベースラインデータが利用できる（現在のパフォーマンス）
• 担当者とリソースが割り当てられている

---

ワークフロー

PLAN — 分析し、アプローチを定義する

1. 現状を定義する

   • 問題または改善の機会は何ですか？
   • 現在測定されているパフォーマンスはどの程度ですか？（ベースライン）
   • 目標は何ですか？（SMART：具体的、測定可能、達成可能、関連性がある、期限が明確）

2. 根本原因を分析する

   • フィッシュボーン分析 と 5 Whys を使用して、現在のパフォーマンスが目標を下回っている理由を把握します
   • データを活用します：パレート図、ランチャート、工程能力調査

3. 改善計画を策定する

   • ギャップを埋めるための具体的な処置は何ですか？
   • 各処置の担当者は誰ですか？
   • スケジュールはどうなっていますか？
   • どのようなリソースが必要ですか？
   • 変更によってどのようなリスクが生じますか？該当する PFMEA を確認します。この変更によって故障モードが追加または削除されますか？既存の予防管理または検出管理に影響しますか？

4. パイロットの範囲を定義する

   • どのプロセス、ライン、またはエリアで変更を試験導入しますか？
   • 有効性を検証するために、どの程度の量または期間が必要ですか？パイロット開始前に定義してください。結果を見てから決めてはいけません。
   • 何を、どのように測定しますか？

パイロット量の目安： 最低限、パイロットではシグナルとノイズを統計的に区別できるだけの出力を得る必要があります。一般的な参考値：

• 工程能力の変化：新しい条件下で、最低 30 回連続のサイクルまたはユニット
• 不良率の低減：従来の不良率で少なくとも 5 件のイベントが予測される最低量（例：ベースライン不良率が 2％の場合、パイロットは最低 250 ユニット）
• 時間依存の改善：最低 4 週間にわたる、継続的なパフォーマンスデータ

Plan ゲート： 根本原因を把握できていますか？明確な量または期間の最低要件を含めて、パイロットの範囲を定義していますか？具体的な目標に対して成功を測定できますか？

---

DO — 実施する（パイロット）

1. 計画した変更をパイロットの範囲内だけで実施します
2. 影響を受ける担当者をトレーニングします
3. パイロット中に実施し、データを収集します
4. 実際に起きたことと計画との差異を記録します（逸脱もデータです）

この段階では広範囲に展開しないでください。 パイロットの目的は学習であり、確定することではありません。

---

CHECK — 結果を検証する

パイロットの結果を Plan の目標と比較します。

指標	ベースライン	目標	パイロット結果	ギャップは解消されたか？
[KPI 1]
[KPI 2]

確認事項：

• 変更によって期待した改善が得られましたか？
• 予期しない悪影響はありましたか？
• 改善は持続可能ですか（時間の経過とともに安定していますか）、それとも一時的な効果ですか？
• パイロットは代表的な条件下で実施されましたか（本番と同じ作業者、同じ材料、同じ環境でしたか）？

Check ゲート：

• 目標を達成した場合 → Act（標準化）に進みます
• 一部達成した場合 → Plan を見直し、Do-Check サイクルをもう一度実施します
• 達成できなかった場合 → Plan に戻り、根本原因を再分析します

---

ACT — 標準化または見直し

パイロットが成功した場合：

1. プロセス文書を更新します。作業手順書、管理計画書、PFMEAのすべてを改訂し、新しいプロセスを反映させます
2. PFMEAに改善したプロセス工程に関連する故障モードが含まれている場合、該当するS／O／D評価とAPを更新します
3. 該当するすべての領域に展開します（水平展開）。各領域を列挙し、展開が完了したことを確認します
4. 影響を受けるすべての担当者を訓練します。訓練記録が必要です
5. 改善が維持されていることを確認するため、継続的なモニタリングを設定します
6. 学んだ教訓を共有します。教訓共有レジスターに記録します

パイロットが失敗した、または結論が出なかった場合：

1. 学んだことを文書化します
2. Planを見直します（新しい根本原因の仮説、または新しいアプローチ）
3. サイクルを繰り返します

検証されていない変更を標準化してはいけません。 失敗したパイロットを標準化すると、問題が恒久的に組み込まれてしまいます。

---

必須のPDCA文書（ISO 9001 §10.3）

サイクルを監査可能にするため、完了時に以下の記録が存在している必要があります。

• データソースと日付を含むベースライン測定値
• 根本原因分析（特性要因図または5 Whyの結果）
• 明示的な最小数量／期間と成功基準を定めたパイロット計画
• パイロット実施データ（実施前／実施後の比較）
• 判定ゲートの決定（進行／見直し／再開）と、その裏付けとなるデータ
• 更新したPFMEA、管理計画書、作業手順書（該当する場合）。新しい改訂番号と承認日を含む
• 影響を受けるすべての担当者の訓練記録
• 水平展開ログ（評価した領域、実施した対応）
• 教訓共有レジスターへの記録

---

ゲートの概要

ゲート	主な質問	合格基準
Plan	根本原因が理解され、パイロットの範囲が定められていますか？	根本原因が確認され、目標が測定可能で、パイロットの数量／期間が定義されている
Do	パイロットは計画どおりに実施されましたか？	対応が実施され、計画に沿ってデータが収集されている
Check	変更によって目標を達成できましたか？	目標指標を達成または上回り、最小パイロット数量に達している
Act	文書が更新され、展開が完了していますか？	PFMEA／CP／WIが改訂され、訓練が完了し、水平展開が記録されている

---

よくある間違い

• Planを省略する — 根本原因を理解せず、いきなりDoに進む
• パイロット数量を定めない — パイロット後にデータが「十分」かどうかを決める。開始前に最小値を設定してください
• Checkを省略する — データを検証せずに、パイロット後に広範囲へ展開する
• Checkの前にActを恒久化する — パイロット結果が確認される前に標準化する
• サイクルを1回だけ実施する — PDCAはサイクルです。最初のサイクルで解決しない場合は、もう一度実施してください
• 緊急の不具合にPDCAを使用する — 顧客からの苦情や安全上の問題には、代わりに8Dを使用してください
• PFMEAを更新しない — PFMEAを更新せずにプロセスを変更すると、リスク登録簿が不正確なままになります

---

出力形式

使用を開始する際、毎回ユーザーに次のように尋ねます。

"出力はどの形式で受け取りたいですか？ A — 構造化されたMarkdown（書式設定済みの表とセクション。コピーしてすぐに使用できます） B — シンプルな表（ExcelまたはWord向けの簡略化した構成） C — 説明形式のレポート（正式な文書やメール向けの流れるような文章）

デフォルト：A。"

選択された形式に合わせて、すべての出力セクションを調整します。プラットフォームまたはセッションのコンテキストですでに形式の希望が定義されている場合は、この質問を省略します。

変更履歴

Version	Date	Author	Change
1.0	2026-06-01	@RBraga01	初回リリース
1.1	2026-06-04	@migmcc	PDCAサイクルのワークフローとD6検証の統合を改善