失敗から学ぶ品質改善：KPTと出荷後フィードバック

概要

品質計画を立案・実行していても、当初想定外の事象により品質トラブルは発生する。重要なのは発生した失敗を組織知に変える仕組みと、出荷後の品質を把握する仕組みの両方を持つことだ。

想定し得ないことが発生することを前提として、他のプロジェクトや組織の失敗事例を学び、再発防止策を取り入れることが重要になる。

プロジェクトの節目にKPTを用いて失敗に至った必然性を明らかにし、次工程以降へのチャレンジに変える。

KPTを使って組織に失敗事例を教訓として共有する際、以下の点に注意が必要。

叱責が目的になると、失敗が隠蔽され組織知として蓄積されなくなる。心理的安全性の確保が前提。

開発部門が作業を完了し、検査部門もチェック項目を完了し「品質問題なし」と判断して顧客へシステムを提供したにもかかわらず、稼働後数か月してから重大問題が発生してエスカレーションされることがある。

背景として以下が考えられる：

ソフトウェア開発組織が成長し、開発部門・検査部門・顧客サポート部門に分かれて役割分担されるようになると、顧客で発生しているトラブルや問題の情報共有が少なくなる傾向がある。

各部門が自分たちの責任でトラブルや問題を解決しようと真摯に取り組めば取り組むほど、情報が他部門へ伝わらなくなる。

対策として、トラブルや問題の発生する背景まで踏み込んで根本原因への対処を行う仕組みが必要になる。

フェーズ	取り組み	目的
プロジェクト節目	KPTによる振り返り	失敗を組織知として蓄積する
サービスイン後	出荷後品質の情報収集	実際のユーザー影響を品質改善に反映する

出荷前の品質活動（テスト・レビュー）だけでなく、出荷後のフィードバックループが閉じて初めてQMSが機能する。