海外の大手顧客から届く不具合報告のフォーマットが8Dだったとき、正直なところ最初は面食らった記憶がある。八つのステップを埋めるだけの単純作業に見えて、実際には論理の一貫性を厳しく問われる文書だ。今回は設計者として8D報告書を書く際の勘所を、実務の視点から丁寧に解説していきたいと思う。国内向けのなぜなぜ分析とは異なる緊張感を持って向き合う必要がある文書だ。
8Dとは何か——8つのステップで構成される是正処置手法
8Dは「Eight Disciplines」の略で、不具合発生時の是正処置を体系的に進めるための八段階の手法だ。もともとは自動車業界で広まった手法だが、今では機械・電機業界を含む多くの製造現場で標準的なフォーマットとして使われており、特に海外顧客とのやり取りでは避けて通れない文書になっている。D1のチーム編成から始まり、D2の問題定義、D3の応急処置、D4の原因究明、D5の恒久対策の選定、D6の対策の実施と検証、D7の再発防止、D8の活動の終結とチームの評価まで、順を追って進めていく構成になっている。各ステップには前のステップの結論を引き継ぐという明確な連鎖があり、途中を飛ばしたり順番を入れ替えたりすると、途端に文書全体の論理が破綻してしまう。
私が初めて8D報告書の作成を任されたのは、海外顧客向けの部品で不具合が発生したときだった。それまで社内向けのなぜなぜ分析には慣れていたが、8Dは英語での記述に加え、各ステップの記述内容に対して顧客側の品質担当者から厳しく指摘が入るという点で、まったく別の緊張感があった。特に印象に残っているのは、D4の原因究明の記述が甘いと、D5以降の対策すべてが差し戻されるという構造の厳格さだ。なぜなぜ分析のような柔らかい形式ではなく、各ステップが論理的につながっていることを常に問われる。
当時の私は、社内向けの報告書を書く感覚のまま8Dの草稿を提出し、顧客の品質担当者から「このステップとこのステップの整合性が取れていない」という指摘を立て続けに受けた。国内の取引先であれば多少の曖昧さは目をつぶってもらえる場面もあるが、海外顧客、特に自動車業界出身の品質担当者は、8Dの型を知り尽くしている。型から外れた記述は容赦なく突き返される。この経験を通じて、8Dは単なる報告書のフォーマットではなく、論理的思考力そのものを試される場なのだと痛感した。
D1〜D3:チーム編成と問題の明確化
D1のチーム編成では、設計・製造・品質保証など関連部門から適切なメンバーを集める。私が経験した中で失敗しやすいのは、形式的にメンバーを列挙するだけで、実際にはほとんど関与しない名前だけの参加者を並べてしまうケースだ。私は8D活動を主導する立場になったときは、各メンバーに具体的な役割と期待するアウトプットを最初に伝え、名前だけの参加にならないよう気をつけている。
チーム編成でもう一つ気をつけているのは、権限を持つメンバーを最低一人は含めることだ。原因究明の途中で設計変更や工程変更の判断が必要になった際、権限者がチームにいないと、その都度承認を取りに行く手間が発生し、活動全体のスピードが著しく落ちる。私は8D活動の立ち上げ時点で、誰が最終的な意思決定者になるのかを明確にし、その人物を最初からチームに組み込むよう提案している。この一手間だけで、活動全体のリードタイムは体感で二割以上短縮できると感じている。実際、権限者不在のまま進行した過去の活動では、承認待ちの停滞だけで通算一週間近くのロスが生じたこともあり、それ以来チーム編成の段階で必ず確認する項目として定着させている。
D2の問題定義とD3の応急処置も軽視されがちだが、実はここでの記述の精度がその後の展開を大きく左右する。入口が曖昧なまま先に進むと、後段のステップすべてに歪みが波及してしまう。D2では「いつ、どこで、何が、どのように」不具合が発生したかを、5W1Hに沿って具体的に記述する必要がある。私が過去に見た報告書には「不具合が発生した」としか書かれておらず、発生時期や発生台数、発生率といった定量情報が欠けているものが多かった。定量情報がないと、顧客側はこの不具合がどの程度深刻なのか、緊急対応が必要なのかどうかを判断できない。私はD2を書く際、必ず発生台数と検査対象台数から発生率を計算し、可能であれば同種の過去事例と比較した位置づけまで示すようにしている。この一手間があるだけで、その後のやり取りの優先度づけがスムーズになる。D3の応急処置は、恒久対策が決まるまでの間、不良品の流出を防ぐための一時的な措置であり、私は必ず「いつまでこの応急処置を続けるか」という終了条件までセットで記述するようにしている。応急処置はあくまで暫定的な措置であり、それ自体が目的化してはならないというのが私の基本姿勢だ。
終了条件を明記しない応急処置は、恒久対策が決まったあとも惰性で続けられてしまい、現場に無駄な工数を強いることになりかねない。私が過去に見た現場では、応急処置として導入した全数目視検査が、恒久対策実施後も半年以上そのまま残っていたことがあった。理由を聞くと、誰も「もうやめてよい」という判断を下せず、なんとなく続けていたという。8D報告書のD3にきちんと終了条件を書き込んでおけば、こうした無駄な継続は防げたはずだ。
D4:原因究明——なぜなぜ分析との接続
D4は8D報告書の中でも最も重要なステップであり、ここでなぜなぜ分析の考え方がそのまま活きてくる。私は8Dの原因究明を進める際、発生原因と流出原因を分けて記述することを徹底している。発生原因は「なぜ不具合が発生したか」、流出原因は「なぜその不具合が検査をすり抜けて顧客まで届いたか」という、まったく別の問いだ。この二つを混同して一つの原因欄にまとめてしまう報告書を、私はこれまで何度も見てきた。混同したまま対策を立てると、発生防止か流出防止のどちらか一方に偏った対策になり、結局は不十分な是正処置で終わってしまう。
私が担当したある搬送用治具の不具合では、発生原因は「部品の寸法公差の設定ミス」、流出原因は「その寸法を検査項目に含めていなかったこと」という、まったく異なる二系統の原因だった。この二つを分けて記述したことで、対策も発生防止の設計変更と、流出防止の検査項目追加という二本立てになり、顧客からの評価も高かった。原因の記述は英語で行うことが多いため、私は専門用語だけでなく、なぜその原因に至ったかの論理展開が伝わるよう、平易な表現を心がけている。
発生原因と流出原因を分ける作業は、実は日本語でなぜなぜ分析をする段階から意識しておくとスムーズになる。私は社内でのなぜなぜ分析の時点で、あらかじめ「発生」と「流出」の二本立てで問いを立てるようにしている。こうしておけば、後から8D報告書のD4に転記する際に、改めて整理し直す手間がかからない。逆に、なぜなぜ分析の段階でこの区別を意識せずに進めてしまうと、8D報告書を書く段階になって発生原因と流出原因が絡み合ったまま整理できず、二度手間になることが多い。
D5〜D6:恒久対策の立案と検証
D5では恒久対策の候補を複数挙げ、それぞれの効果とリスクを比較検討したうえで最終案を選ぶ。私が気をつけているのは、対策候補を一つしか挙げず、いきなり結論だけを書いてしまわないことだ。顧客側の品質担当者は、なぜその対策が最適だと判断したのかという比較検討の過程を重視する。複数の選択肢を提示し、コスト・実施期間・効果の確実性という観点で比較した表を添えると、説得力が格段に増す。
私が実際に作成した比較表では、対策候補ごとに「設計変更の要否」「追加コストの概算」「実施までの期間」「見込まれる効果」の四項目を並べ、最終的にどの案を採用したかとその理由を明記した。この表があるかないかで、顧客側の品質担当者からの質問の数が大きく変わる。表がないまま結論だけを提示すると、なぜ他の案を採用しなかったのかという質問が必ず飛んでくる。あらかじめ比較の過程を可視化しておくことで、こうした後戻りの質問を未然に減らすことができる。
D6は対策を実際に実施し、その効果を検証するステップだ。私はここで、対策実施前後のデータを定量的に示すことを重視している。「対策を実施しました」だけでは不十分で、対策実施後に一定期間、実際に不具合が再発していないことを示すデータが必要になる。私が担当した案件では、対策実施後の量産数百台について寸法データを継続的に取得し、工程能力指数の改善をグラフで示すことで、顧客からの信頼を得ることができた。対策前は工程能力指数がおおむね一を下回っていたのに対し、対策後は一・三程度まで改善しており、この数値の変化だけで対策の妥当性を客観的に示すことができた。数値による裏付けのない対策報告は、どれだけ立派な文章を書いても説得力を持たない。
私はD6の検証データを準備する際、対策実施前のデータと実施後のデータを同じグラフの中に並べて示すことにこだわっている。この一手間を惜しむと、せっかくの良い対策も相手に伝わりにくくなってしまう。別々のグラフで示すと読み手が比較の労力を強いられ、印象に残りにくい。一枚のグラフで「対策前はこれだけばらついていたものが、対策後はこの範囲に収まるようになった」と一目で分かるように工夫すると、顧客側の担当者からの評価も高く、承認までのやり取りが短縮されることが多い。見せ方一つで、同じ内容でも伝わり方がまったく違ってくると実感している。
私が経験した8D報告書のトラブル事例
苦い経験も紹介したい。私が関わった案件で、D4の原因究明が不十分なまま報告書を提出してしまい、顧客から三回にわたって差し戻しを受けたことがある。最初の提出では「作業者のミス」という記述で終わっていたが、顧客からは「なぜそのミスが起きたのか、なぜそれを防ぐ仕組みがなかったのか」という指摘が返ってきた。二回目の提出でも掘り下げが浅く、ようやく三回目で「作業手順書に重要な注意点が明記されておらず、かつダブルチェックの仕組みがなかった」という真因にたどり着いた。
この経験から学んだのは、8Dの原因究明はなぜなぜ分析と同じかそれ以上の深さが求められるということだ。国内向けの報告書であればある程度の曖昧さが許容される場面もあるが、海外顧客向けの8Dでは論理の飛躍が一切許されない。以来、私は8D報告書を書く前に、必ず社内でなぜなぜ分析を先に完了させ、その結果をD4に転記する形を取るようにしている。この順序を守るようになってから、差し戻しの回数は大幅に減った。以前は一件あたり平均で二、三回の差し戻しを受けることが珍しくなかったが、なぜなぜ分析を先に完了させる運用に切り替えてからは、一回の提出で承認される案件が半数を超えるようになった。
三回の差し戻しを受けたこの案件では、顧客側との英語でのやり取りにも苦労した。原因究明の深さについての指摘は、翻訳のニュアンスによっては意図が正確に伝わらないこともある。私はこの経験以降、原因記述の英語表現については、専門の翻訳者に頼るだけでなく、自分自身でも技術英語の言い回しを学び、少なくとも自分が書いた日本語の意図と英語の記述にずれがないかを確認できる程度の英語力は維持するよう心がけている。
D7:再発防止——横展開の重要性
D7では、今回の対策を他の類似製品や工程にも展開できないかを検討する。私がこのステップで重視しているのは、同じ設計要素や同じ工程を持つ他機種への横展開だ。ある機種で発覚した問題は、同じ設計思想で作られた別機種にも潜在していることが多い。私は8D活動が完了した段階で、必ず社内の設計データベースを検索し、同種の構造を持つ他機種がないかを確認するようにしている。
実際に、先述の搬送用治具の寸法公差の問題では、横展開の調査によって、同じ公差設定を使っていた別の三機種が見つかった。これらについても先んじて設計変更と検査項目の追加を行ったことで、同じ問題が別機種で発覚する前に未然に防ぐことができた。もし横展開をせずに放置していたら、同種の不具合が三機種それぞれで個別に発覚し、対応工数は少なくとも数倍に膨らんでいたはずだと振り返って思う。D7を単なる形式的なチェック項目として済ませず、実際に手を動かして横展開先を洗い出すかどうかが、8D活動の真価を左右すると私は考えている。
横展開の調査は、設計データベースの検索だけでなく、他機種を担当している設計者への直接のヒアリングも欠かせない。データベースの図面番号や部品名だけでは、同じ設計思想を持つ部品を漏れなく拾い切れないことがある。私は8D活動のたびに、社内の関連部署に簡単なアンケートやメールで「同様の公差設定や構造を使っている機種はないか」と問いかけるようにしている。この地道な確認作業が、見えないところに潜む同種のリスクを掘り起こす鍵になる。
D8:活動の終結とチームへの評価
D8は8D活動の締めくくりとして、チームの取り組みを評価し、活動を正式に終結させるステップだ。形式的には簡単な記述で済ませられるが、私はここで、活動を通じて得られた教訓を今後の設計プロセスにどう反映するかまで書き込むようにしている。単に「活動を終了する」だけでなく、「今後は設計レビューのチェック項目にこの観点を追加する」というように、組織的な学びとして残すことを意識している。
チームメンバーへの評価も軽視できない部分だ。8D活動は関係部門を巻き込む負荷の高い作業であり、協力してくれたメンバーへの感謝や貢献の記録を残すことで、次回同様の活動が必要になった際の協力体制が築きやすくなる。私は活動終結時に、関わったメンバー一人ひとりの貢献を簡潔にでも記録するようにしている。小さな一言でも、書き残すかどうかで受け取る側の印象は大きく変わる。地道な配慮だが、長期的な信頼関係の構築に効いてくると感じている。
外部から常駐する設計者という立場だと、8D活動が終わったあとに関係者から明確な感謝の言葉をもらう機会は意外と少ない。だからこそ、私自身がチームの功績を書面に残すことで、協力してくれたメンバーの努力が正式な記録として組織に残るよう心がけている。特に、普段は目立たない検査担当者や現場作業者が、原因究明の決め手となる情報を提供してくれた場合には、その貢献を具体的に報告書に書き込むようにしている。こうした積み重ねが、次の不具合対応でも快く協力してもらえる関係につながっていく。
8D報告書を書く際に設計者が陥りやすい失敗
最後に、設計者が8D報告書を書く際に陥りやすい失敗を整理しておきたい。最も多いのは、各ステップの記述に一貫性がないことだ。D2で定義した問題と、D4で特定した原因、D5で選んだ対策が、読み返すと微妙に論点がずれているケースがよくある。私は報告書を書き終えたら、必ず最初から通しで読み返し、各ステップの記述が矛盾なくつながっているかを確認する作業を欠かさないようにしている。
もう一つの落とし穴は、専門用語や社内独自の略語をそのまま使ってしまうことだ。8Dは海外顧客とのやり取りに使われることが多く、社内でしか通じない表現は誤解を招く。私は報告書の草稿を書いたあと、その分野に詳しくない同僚に一度読んでもらい、意味が通じるかを確認するようにしている。第三者の視点を挟むだけで、独りよがりな表現に気づけることが多いというのが、これまでの経験から得た教訓だ。この一手間が、結果的に差し戻しの回数を減らし、顧客との信頼関係を築くことにつながると実感している。第三者レビューを挟むようになってから、社内独自の略語に起因する質問はほぼゼロになり、顧客とのやり取りも技術的な論点に集中できるようになった。
最後にもう一つ付け加えるなら、8D報告書は一度提出して終わりではなく、顧客からのフィードバックを受けて何度も改訂する前提で臨むべきだ。最初から完璧な報告書を書こうと気負いすぎると、提出までに時間がかかりすぎて応急処置の期間が長引いてしまう。私はまず骨子となる各ステップの記述を素早く固め、顧客とのやり取りの中で肉付けしていくという進め方を採るようにしている。骨子さえ固まっていれば、細部の修正はやり取りの中で柔軟に対応できる。完璧を目指すよりも、対話を重ねながら精度を上げていく姿勢のほうが、結果的に良い報告書に仕上がると、これまでの経験から感じている。
コメント