mcpField
8
8d-problem-solving

8d-problem-solving

github.com/rbraga01テスト・品質4243 回インストール1 週間前に更新
リポジトリ

8d-problem-solving について

顧客苦情、工程内流出、その他の不適合に取り組む品質チーム向けの構造化された 8D 問題解決スキルです。緊急対応から根本原因の検証、是正処置、再発防止、正式な完了までを導きます。

主な機能

  1. 01D0~D8 の実行チェックリスト
  2. 02発生原因と流出原因の検証
  3. 03封じ込めと是正処置のガイダンス
  4. 04証拠に基づく効果検証
  5. 05品質文書の更新と横展開
  6. 06Markdown、表、文章形式の出力

活用シーン

  1. 01顧客報告の不具合調査
  2. 02出荷前の疑義品の封じ込め
  3. 03製造データによる原因の検証
  4. 04監査対応可能な 8D レポートの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rbraga01/quality-engineering-skills --skill 8d-problem-solving

インストール後、Claude Code で/8d-problem-solvingを入力して読み込まれたか確認します。

同梱ファイルassets/8d-template.mdreferences/d0-d8-guide.md

詳細

8D問題解決

目標

実証済みの根本原因と再発を防止する有効な是正措置を含む、検証済みで監査対応可能な8Dレポートを作成します。顧客に承認され、品質システムに登録されていることが必要です。

必須実行チェックリスト

エージェントおよび実務担当者向けのクイックリファレンスです。D8の完了前に、すべての項目を完了してください。

  • D0:安全および規制上のリスクを評価し、文書化する
  • D0:疑義のある材料を特定し、物理的に隔離する
  • D1:チャンピオンを特定したうえで、部門横断チームを編成する
  • D2:測定値、部品番号、数量、Is/Is-Notを用いて問題を記述する
  • D3:封じ込めを実施済みの形で記録し、日付と有効性の証拠を添える
  • D4:発生の根本原因を特定し、データまたは実験で検証する
  • D4:流出の根本原因を特定し、データまたは実験で検証する
  • D5:根本原因ごとにPCAを1つ選定し、検証計画を策定する
  • D6:PCAを実施し、検証データで再発がゼロであることを確認し、ICAを正式に解除する
  • D7:PFMEA、コントロールプラン、作業手順書を更新する(改訂番号を記録)
  • D7:水平展開を評価し、必要な措置を講じる
  • D8:チャンピオンの承認を取得し、完了を顧客に通知する

使用する場面

顧客から報告された不具合、下流工程に流出した社内不具合、市場での故障、または根本原因分析の文書化が必要なあらゆる不適合に8Dを使用します。自動車OEMの顧客苦情の大半で必須です(Ford 8D、BMW G8D、VW QMSS、Stellantis)。

前提条件

  • 不具合または故障が明確に特定され、定量化されている
  • 影響を受けた部品、工程記録、測定データにアクセスできる
  • 部門横断チーム(最低限、品質、生産、エンジニアリング)が参加できる

ワークフロー

D0 — 緊急対応(チーム編成前)

まず、次の質問をします。

  1. 安全または規制上の問題ですか?該当する場合 → 直ちにエスカレーションし、顧客に通知します
  2. 製品リコールまたは規制上の事象(安全、排出ガス、型式認証への適合)につながる可能性はありますか?
    • ある場合 → 標準の8Dスケジュールを中断します。直ちに経営陣および規制担当責任者にエスカレーションしてください。経営陣が認識したことを書面で記録するまで先に進まないでください。8Dを継続できるのは、経営陣の承認を得た場合に限ります。
  3. 疑義のある部品は、すでに顧客先または市場にありますか?該当する場合 → D1~D2を完了する前に、直ちに封じ込め(D3)を開始します
  4. 初期証拠を収集します:写真、バッチ番号、ロット追跡情報、測定データ

D0の完了条件:安全性を評価し、規制上のエスカレーション判断を文書化し、疑義のある材料を特定して識別済みであること。


D1 — チーム編成

部門横断チームを編成します。必要な役割:

  • チャンピオン(スポンサー。リソースを割り当てる権限を持つ)
  • チームリーダー(8Dの責任者。完了まで推進する)
  • 品質エンジニア(手法、文書化を担当)
  • 生産/工程責任者(工程に関する知識を提供)
  • エンジニアリング(設計または工程エンジニアリングを担当)

任意:サプライヤー品質、物流、顧客代表者。

記録する内容:氏名、部門、チームリーダー、開始日、完了目標日。

**検証:**影響を受ける工程ステップはすべて担当者が参加していますか?工程を変更する権限を持つ人がいますか?


D2 — 問題の説明

Is/Is-Not と 5W2H を使って、問題を正確に定義します。D2 が不十分だと、D4 も不十分になります。

Is/Is-Not による範囲の特定(is-is-not-scoping スキルを参照):

質問該当する該当しない
問題は何ですか?例:寸法が規格外表面の擦り傷
対象物/部品は何ですか?部品番号 X、リビジョン B部品番号 Y
どこで見つかりましたか?ステーション 3、受入検査最終試験
いつ発生し始めましたか?2026-05-12 のバッチそれ以前のバッチ
何個ですか?検査した 200 個中 47 個(23.5%)—
傾向はありますか?バッチの日付以降、一貫して発生急増なし

5W2H:

  • 誰が検出しましたか?いつですか?どこですか?
  • 不適合の内容を正確に示してください(測定値と仕様値の比較)。
  • なぜ問題なのですか?(顧客への影響)
  • どのように検出しましたか?何個が影響を受けていますか?

第三者が読んで、何が、何に対して、いつ、何個、サプライチェーンのどこで問題なのかを正確に理解できる状態になれば、D2 は完了です。


D3 — 暫定封じ込め処置(ICA)

D4〜D5 の実施中に、不適合品が顧客に届かないようにする必要があります。

一般的な ICA:

  • 疑わしい在庫(工程内・市場・顧客保有分)を選別/全数検査する
  • 対象期間のすべてのバッチの出荷を保留する
  • 出荷前 QC に特定の検査工程を追加する
  • (製品が流出した場合)顧客への通知と在庫の回収

ICA の妥当性確認 — 次の点を確認します:

  • この ICA は、不良品の流出を物理的に防止しますか?(「はい」か「いいえ」で回答します。「努力します」ではありません)
  • 有効に機能していることを示す証拠は何ですか?(検査記録、ICA 実施日以降の流出ゼロ)
  • 実施日と責任者を明記して記録されていますか?
  • 一時的な処置ですか?(ICA は恒久対策ではありません)

客観的な証拠をもって疑わしい製品を封じ込め、該当する場合は顧客に通知できれば、D3 は完了です。


D4 — 根本原因分析

根本原因を 2 つ特定します:

  1. 発生の根本原因 — なぜ不良が発生したのか?
  2. 流出(検出不良)の根本原因 — なぜ顧客/次工程に届く前に検出できなかったのか?

次のツールを使用します(参照先のスキルを参照):

根本原因の妥当性確認:

  • 根本原因を意図的に作り出すことで、不良を再現できますか?
  • 試験運用で根本原因を取り除くと、不良を防止できますか?
  • 意見ではなく、データに裏付けられていますか?

最終的な根本原因として、次の説明は認めないでください:

  • 「ヒューマンエラー」(体系的な原因ではありません。なぜエラーが起こり得たのかを確認します)
  • 「作業者が指示に従わなかった」(なぜ従わなかったのか、または従えなかったのかを確認します)
  • 「サプライヤーが不良部品を納入した」(なぜ受入検査で検出できなかったのかを確認します)

証拠に関するルール: 根本原因は、論理的な推論だけではなく、データまたは物理的な実験によって証明する必要があります。妥当だと論じることしかできない場合、それは仮説です。根本原因を発動させて不良を再現し、根本原因を取り除いて不良をなくします。両方の試験が必要です。

客観的な証拠によって両方の根本原因が検証され、意見に頼っていなければ、D4 は完了です。


D5 — 恒久是正処置(PCA)の選定

D4 で特定した各根本原因に対し、次の条件を満たす恒久是正処置を選定します:

  • 該当する根本原因に直接対処する(症状への対処ではありません)
  • 有効性を検証できる
  • 利用可能な時間とリソースの範囲内で実行可能である

評価マトリクス(候補となる PCA ごとに実施):

  • 根本原因に対処していますか?(はい/いいえ)
  • 有効性を測定できますか?(指標+目標値)
  • 実施に伴うリスクはありませんか?(FMEA で確認)
  • スケジュールは現実的ですか?

文書に記載する内容:PCA の説明、責任者、実施目標日、検証方法。

根本原因ごとに PCA を 1 つ選定し、検証計画とともに文書化できれば、D5 は完了です。


D6 — 実装と有効性の検証

PCA を実装します。実装後は、以下を確認します。

検証要件:

  • 統計的信頼性を確保できるだけの十分な生産数量を実行します。サンプルサイズは、観測された欠陥率とリスクレベルに基づいて定義してください(欠陥率が高い場合や安全に関わる欠陥の場合は、より大きなサンプルが必要です)。一般的な固定数を使用せず、必要な検出確率に合わせてサンプル数を設定します。
    • 目安:PCA 実施前の欠陥率が p の場合、p の欠陥が引き続き存在するときに欠陥がゼロ件となる確率が 5% 未満になるよう、検証サンプル数を設定します。式:n ≥ log(0.05) / log(1 − p)。
  • 元の欠陥指標を実施前と実施後で測定します。
  • 同じ欠陥モードが再発していないことを確認します。

記録する検証証拠:

  • PCA 実施後の工程管理図または検査データ
  • 実施前後の比較(欠陥率または測定データ)
  • 品質部門および生産部門による承認

ICA(D3)は、客観的な証拠をもってD6の検証が完了した後にのみ解除できます。

D6の完了条件:データによって欠陥の除去が確認され、ICAが正式に解除されていること。


D7 — 再発防止(システム化)

最も重要でありながら、最も省略されがちな規律です。同じ根本原因が他の場所で発生するのを防ぎます。

必要な更新:

  • PFMEA を更新:故障モードを追加/修正し、発生度と検出度の評価を更新
  • 管理計画書を更新:根本原因と流出に対する管理を追加
  • 作業指示書/SOP を更新して再発行
  • 受入検査を更新(サプライヤーまたは材料に関連する場合)
  • 教訓を文書化し、類似する製品ラインと共有
  • 該当する作業者/検査員にトレーニングを実施

水平展開:

  • 同じ根本原因が発生する可能性のある類似品番、工程、製品ファミリーはありますか?
  • ある場合 → それらの領域にも PCA を展開し、文書化します。

D7の完了条件:すべての工程文書が更新され、変更が生産現場で運用されていること。


D8 — チームの功績を称える

8D を正式に完了します。

  • チームリーダーが完了した8Dをチャンピオンに提示
  • チャンピオンが、すべての規律が証拠をもって完了していることを検証
  • チームの功績を正式に認める(金銭的な報奨である必要はありません)
  • 8Dレポートを品質記録システムに保管
  • 顧客起点の苦情の場合、完了を顧客に通知

D8の完了条件:チャンピオンが承認し、顧客に完了を通知していること。


検証 — 8D は完了していますか?

完了する前に、以下を確認します。

  • D2の問題の記述が客観的かつ定量化されている
  • D3の ICA に実施日と検証証拠がある
  • D4で2つの根本原因(発生+流出)が特定され、どちらも証拠によって検証されている
  • D5の PCA が D4 の根本原因に直接対処している
  • D6の検証データで、PCA 実施後に再発がゼロであることが示されている
  • D7:FMEA、管理計画書、作業指示書がすべて更新されている
  • D8:チャンピオンの承認と顧客への通知(該当する場合)が完了している

よくある間違い

  • D0を省略する: 顧客に疑わしい在庫が残っていないことを確認する前にD2へ進む
  • D2が不十分: 問題の記述が曖昧で、誤った根本原因につながる
  • D3をD6として扱う: 封じ込めを恒久対策として扱う(「全数検査を追加した」は PCA ではありません)
  • 症状を根本原因として扱う: 「機械の校正がずれていた」—なぜですか? 「サプライヤーが間違った材料を送った」—なぜ検出できなかったのですか?
  • D7の文書を更新しない: 監査で最もよく指摘される事項

出力形式

使用するたびに、まずユーザーに次のように尋ねます。

「どの形式で出力を受け取りたいですか? A — 構造化 Markdown(書式設定済みの表とセクション、そのままコピーできます) B — シンプルな表(Excel または Word 向けの簡略化した構造) C — 説明形式のレポート(正式な文書やメール向けの文章)

デフォルト:A。」

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

参考ファイル

変更履歴

バージョン日付作成者変更内容
1.02026-06-01@RBraga01初回リリース
1.12026-06-03@RBraga01必須実行チェックリスト、D レベル検証基準、OEM ゲートルールを追加

コメント