mcpField
8
8d-report-writing

8d-report-writing

github.com/rbraga01ドキュメント4246 回インストール1 週間前に更新
リポジトリ

8d-report-writing について

8d-report-writingは、調査完了後に顧客提出用の8Dレポートを作成するスキルです。問題解決手法ではなく、レポート構成、証拠、OEMごとの提出要件を扱います。

主な機能

  1. 01D0からD8までの記載漏れを確認
  2. 02最新のOEMテンプレートに準拠
  3. 03根本原因と対策の証拠を要求
  4. 04日付、申し立て内容、用語の整合
  5. 05Markdown、表、文章形式で出力

活用シーン

  1. 01完了した調査の8D顧客レポートを作成
  2. 02OEMチェックリストに沿ってレポートを確認
  3. 03封じ込めと是正措置の証拠を記録
  4. 04顧客指定の形式でレポートを作成

インストール

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

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

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

同梱ファイルreferences/oem-formats.md

詳細

8D 顧客レポートの作成

使用する場面

8D 調査が完了し、正式なレポートを顧客に提出する必要がある場合に使用します。このスキルでは、文章の品質と形式を扱います。方法論については、8d-problem-solving を参照してください。

8D レポートは、法的かつ商業的な文書です。顧客は次の目的で使用します。

  • 顧客からの申し立てに対応したことを確認する
  • 封じ込めによって顧客の生産が保護されたことを確認する
  • 是正処置の品質を監査する
  • BIQS スコアリング、PPAP ステータス、今後の取引判断に向けて、サプライヤーの品質レベルを評価する

是正処置の内容が優れていても、レポートの文章が不十分であれば、品質成熟度が低いと見なされます。

OEM 形式の参考情報

OEM形式提出システム
Ford8D(Ford 8D フォーム)Covisint / GSDB / portal
BMWG8D(Global 8D)SupplierPortal (SIM)
VW / AudiQMSS (Lieferantenselbstauskunft)SupplyOn
Stellantis (ex-FCA, PSA)8DCQMS
Mercedes-Benz8D / ATCSupplyOn
Toyota (TMMNA)8D または A3SMART

作成前に、必ずポータルから最新の顧客テンプレートをダウンロードしてください。テンプレートは変更されます。必ず該当する顧客の形式と必須項目に合わせてください。OEM テンプレートを変更してはいけません。


必須の 8D レポートチェックリスト

☐ 正しい OEM テンプレートを使用している(最新版を作成前にダウンロード) ☐ D2 は完全に定量化され、顧客の申し立ておよび NCR と完全に一致している ☐ D3 の封じ込めを証拠とともに実施済みである — 過去形のみを使用 ☐ D6 の検証が完了するまで、D3 の封じ込めが継続している ☐ D4 には発生原因と流出原因の両方が含まれ、それぞれが客観的証拠によって検証されている ☐ D5 の処置が各根本原因に直接対処している(RCO と RCE を参照) ☐ D6 には、サンプルサイズの根拠を示した客観的な検証データが含まれている ☐ D7 には、改訂番号を含む PFMEA、CP、WI の更新に加え、水平展開が含まれている ☐ D8 には、チャンピオンの承認と、クローズを顧客に通知した記録が含まれている ☐ すべての日付が時系列に沿い、D0~D8 を通して整合している ☐ すべての記述が、添付または参照された証拠によって裏付けられている ☐ 推測的、謝罪的、または主観的な表現を使用していない ☐ 時制が一貫している:完了した処置は過去形、現在の状態は現在形


分野ごとの記述ルール

D0 — 緊急対応

安全上または規制上の問題が確認されたかどうか、また、どのような緊急処置を実施したかを簡潔に記述します。

安全上または規制上のリスクの有無を、必ず明示してください。「安全上のリスクは確認されていない」または「安全上のリスクを確認 —[処置]」と記載します。

良い例:「安全上のリスクは確認されていません。2026-05-14 に顧客へメールで通知しました(添付参照)。サプライヤーロット 2026-05-12-A に出荷保留を設定し、2 件の納品書にまたがる 1,700 個を対象としました。」

悪い例:「問題の連絡を受け、迅速に対応しました。」

必要な証拠:顧客への通知メール、出荷保留記録。


D1 — チーム

氏名と担当機能を記載します。顧客は、部門横断的な関与を確認したいと考えています。

**良い例:**少なくとも品質エンジニア、生産監督者、工程/設計エンジニアを含めます。チームリーダーと顧客の連絡窓口(該当する場合)を明確に特定します。

悪い例:「品質チームが調査しました。」(氏名、担当機能、部門横断的なアプローチを示す証拠がない)


D2 — 問題の説明

最も読まれているセクションです。D2 が曖昧だと、顧客は報告書を受け入れません。

D2 は NCR および顧客のクレームの記述と完全に一致している必要があります。D2、NCR、顧客のクレームデータに不整合があると、信頼性を損ないます。

必須内容:

  • 測定値および仕様を含む、正確な不適合内容
  • 部品番号 + リビジョン
  • 顧客のクレーム参照番号
  • 数量:不合格数/検査数/リスク対象の総数
  • 検出箇所(顧客の受入検査、現場、生産工程)
  • 初回検出日

良い例:「コネクタハウジングのフランジ厚さを 1.8 mm と測定(仕様:2.2 ± 0.1 mm、DWG-12345 rev B)。2026-05-13 に顧客の受入検査で不具合を検出。検査した 200 個中 47 個が不適合(23.5%)。顧客クレーム参照番号:CL-2026-4471。」


D3 — 暫定封じ込め処置

顧客は、自社の生産が保護されていることを確認する必要があります。多くの SQE が最初に読む項目です。

封じ込めは、D6 の検証が完了し、有効性が確認されるまで継続する必要があります。

必須内容:

  • 実施した内容(選別、全数検査、出荷保留)
  • 実施日(D4、D5、D6 より前であること)
  • 実施者
  • 有効性の検証方法(ICA 実施後の流出がゼロであること、選別結果)

良い例:「顧客の手元にある疑わしい在庫を全数検査(200 個を 2026-05-14 までにすべて検査し、47 個を不合格、153 個を再検査後に合格として出荷可と判定)。当社倉庫に残る 1,500 個を出荷保留とし、2026-05-14 に物流部門が確認。ICA 実施後、新たな流出はゼロ。」

悪い例:「今後、全数検査を実施します。」(未来形は封じ込めではなく、約束です)


D4 — 根本原因分析

技術面で最も評価されるセクションです。顧客の SQE は、特に以下の点を確認します。

  1. 発生原因と流出原因の両方が特定されているか?
  2. 根本原因が十分に具体的か(「人的ミス」や「サプライヤーの問題」のような一般論ではないか)?
  3. 論理的な推論だけでなく、客観的な証拠によって検証されているか?

根本原因は、論理的な推論だけではなく、証拠(試験、データ、または実験)によって裏付けられている必要があります。

必須内容:

  • 発生原因(不具合が発生した理由)— 5 Whys の展開を含む
  • 流出原因(不具合が検出されなかった理由)— 5 Whys の展開を含む
  • 検証方法(試験、データ、再現実験など、根本原因をどのように確認したか)

良い例 — 発生原因:

D4 なぜなぜ分析(発生):

  1. なぜフランジ厚さが規格外なのか?→ ミーリング工程で除去した材料が不足していた
  2. なぜ除去した材料が不足していたのか?→ 送り速度が 0.03 mm/rev ではなく 0.05 mm/rev だった
  3. なぜ送り速度が誤っていたのか?→ 2026-05-10 の工具交換時に CNC プログラムのパラメーターが変更された
  4. なぜ変更を検出できなかったのか?→ 工具交換後のパラメーター確認手順がなかった 根本原因:工具交換後の CNC プログラムのパラメーター確認は、作業指示書で必須とされていない。 検証結果:再現試験により、0.05 mm/rev で不具合が発生し、0.03 mm/rev では不具合がゼロであることを確認。

悪い例:「根本原因:作業者のミス。作業者が誤った設定に変更した。」


D5 — 是正処置

各是正処置は D4 で特定した根本原因に直接対処し、発生原因(RCO)と流出原因(RCE)のどちらに対処するかを明記する必要があります。

必須内容:

  • 是正処置の説明
  • 対処する根本原因(RCO または RCE)
  • 実施日
  • 責任者

良い例:「WI-Milling-Station-2(rev C、添付)に、必須の CNC パラメーター確認手順を追加。作業者は工具交換の前後に CNC の表示を見て送り速度が 0.03 mm/rev であることを確認し、バッチログに記録する。[RCO に対処]」

悪い例:「作業者を再教育し、工程を改善します。」


D6 — 実施と検証

顧客が必要としているのは、対策が実施されたというだけでなく、対策が有効だったことを示す客観的な証拠です。

検証サンプル数は、欠陥率とリスクに基づいて正当化する必要があります。恣意的に決めてはなりません。

必須内容:

  • 各 PCA の実施日
  • 検証データ(量産時の実行結果、実施前後の比較)
  • 正当化されたサンプル数
  • ICA の解除日と確認

良い例:「PCA を 2026-06-04 に実施しました。検証運転:改訂版 WI を使用して 500 個を生産(欠陥率 0.235、信頼度 95% に基づきサンプル数を正当化)。フランジ厚さを 100% 測定し、すべて仕様内でした(平均 2.19 mm、±0.04 mm、公差 ±0.1 mm 以内)。欠陥は検出されませんでした。欠陥ゼロの量産結果を確認したうえで、ICA(100% 検査)を 2026-06-10 に解除しました。」

悪い例:「是正処置を実施しました。欠陥は見つかりませんでした。」


D7 — 再発防止(システム的対応)

これは、場当たり的な対応だけでなく、品質システムを適切に管理していることを顧客に示します。

すべての文書更新は、8D に記載するだけでなく、実施され、量産で有効になっている必要があります。

必須内容:

  • PFMEA の改訂(文書番号、改訂記号、日付)
  • 管理計画の改訂(文書番号、改訂記号、日付)
  • 作業指示書の改訂(文書番号、改訂記号、日付)
  • 水平展開(他のライン、製品、サプライヤーを評価し、対応したこと)
  • 教訓

良い例:「PFMEA-Milling-St2 を rev D に改訂(添付):故障モード『段取り替え後の送り速度誤り』を追加し、O=4、D=3、AP=L としました。CP-Milling-St2 を rev G に改訂(添付):段取り替え後のパラメーター確認を追加しました。WI-Milling-St2 を rev C に改訂(添付)。水平展開:類似する CNC ライン 3 本を評価し、WI-CNC-01、WI-CNC-02、WI-CNC-03 に同じパラメーター確認を追加しました。」


D8 — チームへの謝意

簡潔な結びの文を記載します。専門的かつ事実に基づく内容にします。

最終版の 8D レポートを添えて、顧客に正式に完了を通知する必要があります。

良い例:「責任者の承認を得て、2026-06-15 に 8D を完了しました。2026-06-15 に最終版 8D を添えて顧客に完了を通知しました(参照:メール添付)。2026-06-15 の部門会議でチームを正式に表彰しました。8D レポートは QR-2026-0047 として品質記録システムに保存しました。」


トーンと言葉遣い

避ける表現代わりに使う表現
「ご不便をおかけして申し訳ありません」発生した事象と実施した対応についての事実に基づく説明
「おそらく〜が原因です」「[試験] によって根本原因を確認しました:…」
「再発防止に努めます」「再発防止策を [日付] に実施しました:…」
「作業者がミスをしました」「作業指示書に必要なパラメーターが指定されていませんでした」
「今後は〜します」実施日を含む具体的な対応

時制を統一します。完了した対応には過去形、現在の状態には現在形を使用します。

8D レポートは技術文書です。謝罪調や曖昧な表現は、顧客の SQE からの信頼を損ないます。

8D のすべての記述は、添付または参照された証拠で裏付ける必要があります。写真、測定データ、WI の改訂、PFMEA の更新、試験結果など、裏付けとなる証拠をすべて添付してください。

出力形式

使用を開始するたびに、ユーザーに次のように尋ねてください。

「出力形式はどれにしますか? A — 構造化 Markdown(表とセクションを整え、すぐにコピーできます) B — プレーンな表(Excel や Word 向けの簡略化した構成) C — 説明形式のレポート(正式な文書やメール向けの文章)

デフォルト:A。」

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

参考ファイル

変更履歴

バージョン日付作成者変更内容
1.02026-06-01@RBraga01初回リリース
1.12026-06-03@migmccOEM 形式の要件と顧客提出チェックリストを追加

コメント