【PR】この記事にはアフィリエイト広告が含まれます。
市場からの不具合報告は、月末になると山になる。
担当者はExcelに手入力し、集計は本人の経験と勘に頼っている。同じ不具合でも、報告書によって書き方がバラバラだ。
これは担当者の怠慢ではない。仕組みが個人に依存している証拠だ。
フィールドデータ集計でよくある3つの失敗
私がいた現場でも、似たような光景があった。
1つ目は、不具合報告のフォーマットがバラバラなことだ。自由記述欄に長文で書く人もいれば、「異音あり」の一行で終わる人もいる。集計する側は、毎回文章を読み込んで自分なりに分類し直すしかない。
2つ目は、月次でまとめてはいるが「件数の推移」しか見ていないことだ。同一ロット、同一部品、同一操作パターンといった切り口で見ないと、傾向は浮かび上がらない。件数だけの報告は、開発部門にとって「で、原因は何なのか」がわからない資料になる。
3つ目は、集計に時間がかかりすぎることだ。実際にあった話だが、月次報告のために担当者が3日間かけてExcelのピボットテーブルと格闘していた。傾向が見えた頃には、次のロットがすでに市場に出ている。
なぜその問題が起きるのか
これは個人の能力や努力の問題ではない。情報設計と運用の仕組みが未整備なままだからだ。
まず、不具合の分類コードが統一されていない。「不具合モード」「発生部位」「原因区分」といった項目が、担当者や拠点ごとに違う言葉で入力されている。同じ現象でも、ある人は「作動不良」、別の人は「動作停止」と書く。これでは集計しても同一事象として拾えない。
次に、集計作業がExcelの手作業に依存している。ピボットテーブルの組み方、マクロの中身、集計ロジックが特定の担当者の頭の中にしかない。その人が異動や退職をした瞬間、集計の再現性が失われる。
さらに、QA部門と開発部門の間で、データの受け渡し形式が決まっていないことも多い。QA側は「報告した」つもりでも、開発側が欲しい粒度と合っていない。結果、開発部門が独自にデータを読み直す二度手間が発生する。
この属人化の構造は、点検記録や修理履歴の管理にも共通して見られる。[担当者ごとの判断基準がばらつく理由](/maintenance-quality-variation-customer-request-risk/)も、根っこは同じ情報設計の問題だ。
放置すると何が起きるか
まず品質面への影響が出る。同一原因の不具合が複数件発生していても、分類がバラバラだと再発に気づくのが遅れる。CAPA(是正予防処置)の着手も後手に回る。
次に残業が増える。月次報告の締切前になると、集計担当者が深夜まで手作業でデータを突き合わせる。これが毎月繰り返される。
引き継ぎにも支障が出る。集計ロジックがブラックボックス化していると、担当者が変わるたびに一から作り直しになる。これは[属人化がもたらすリスク](/medical-device-maintenance-solo-dependency-risk/)そのものだ。
顧客対応や社内外への説明にも影響が及ぶ可能性がある。不具合の傾向を根拠を持って説明できないと、問い合わせへの回答が遅れる。どの程度の対応が求められるかは案件ごとに異なるため、最終的な判断は品質保証部門の責任者が行う必要がある。
傾向分析を仕組み化する判断基準
すべての現場がすぐにツールを導入すべきというわけではない。件数と複雑さで判断するとよい。
まだ手作業でよい場合は、月間の不具合件数が少数で、機種数も限られているケースだ。この規模なら、Excelでも十分に把握できる。
テンプレで十分な場合は、件数は増えているが分類コードが統一されていれば対応できるケースだ。固定フォーマットのシートと関数だけで、傾向はある程度見える。
ツール導入を検討すべきなのは、複数機種・複数拠点でデータが分散している場合、傾向分析に毎月何十時間もかかっている場合、そして集計ロジックが特定の担当者に依存している場合だ。この状態が続くと、[担当者の個人差が残業時間の差になって表れる](/maintenance-personalization-overtime-cause/)ことが多い。
今日からできる改善手順
Step 1: 分類コードを棚卸しする
過去半年分の不具合報告書を集め、自由記述で書かれている表現を洗い出す。似た表現をグループ化し、統一した分類コード(不具合モード、発生部位、原因区分など)を作る。
Step 2: 必須項目を固定したテンプレートを作る
発生日、機種、ロット、不具合モード、原因区分、対応内容といった項目を固定したフォーマットにする。自由記述欄は残してよいが、分類は必ずコードで入力させる。
Step 3: 月次集計を自動化する仕組みを試す
まずはスプレッドシートの関数やピボットテーブルのテンプレート化から始める。件数が多く手に負えない場合は、BIツールや専用のフィールドデータ管理ツールの導入を検討する。
おすすめの次アクション
分類コードの統一とテンプレート化は、明日からでも着手できる。
一方で、属人化した集計作業を仕組みに落とし込む部分は、既存の記事も参考になる。[脱属人化のための業務設計](/medical-device-maintenance-depersonalization/)や、[修理・点検の品質差が生まれる原因](/maintenance-quality-difference-machine-sound/)も合わせて読むと、フィールドデータ管理を「個人の技量」から「組織の仕組み」に変える全体像がつかみやすい。
集計したデータを読み解く力を学びたい方へ【PR】
記録を分類して集計できても、「どの不具合から優先して調べるか」「数値の変化をどう説明するか」で迷うことがある。分析手法の選び方を基礎から学びたい場合は、通信教育も選択肢になる。
JTEXの「事例で学ぶExcelを使った統計的手法」（C44）は、入門・初級向けの3か月の通信講座。公式の講座案内では、データのまとめ方、パレート図、管理図、検定・推定、相関・回帰分析、解析報告書の作成などを扱っている。
集計表を作るだけでなく、データを読み解いて根拠の伝わる報告にまとめたい人は、カリキュラムを確認してほしい。一方、記録用の表を1枚作りたいだけなら、まずはこの記事の分類コードの統一とテンプレート化から始めればよい。
本講座は分析方法を学ぶ通信教育であり、集計を自動化するツールではない。学習にはExcelのソフトウェアとインターネットに接続できる機器が必要だ。ここでは公式情報をもとに学習内容を紹介しており、受講体験のレビューではない。
JTEX「事例で学ぶExcelを使った統計的手法」の講座内容・受講条件を確認する
受講料・教材・必要な環境などの最新情報は、リンク先の公式ページで確認してほしい。
よくある質問
Q1. 傾向分析はどのくらいの不具合件数から始めるべきか
件数の多寡よりも、分類のばらつきが放置されている期間の方が重要だ。件数が少なくても分類がバラバラなら、後から傾向を追いかけるのが難しくなる。件数が少ないうちに分類コードを統一しておくと、後の負担が小さくなる。
Q2. Excelのピボットテーブルだけで十分か
機種数や拠点数が少なく、分類コードが統一されていれば、当面はピボットテーブルで対応できる。ただし集計ロジックが特定の担当者にしか扱えない状態になっていないか、定期的に確認した方がよい。
Q3. 開発部門への報告書はどんな形式が伝わりやすいか
件数の推移だけでなく、ロット・部品・使用条件などの切り口を添えると、開発側が原因を絞り込みやすくなる。文章での説明よりも、分類コードごとの集計表とグラフを併記する形が実務では扱いやすい。
Q4. ISO 13485やQMS省令との関係で、集計の仕組みはどう位置づければよいか
フィールドデータの収集・分析は、一般に品質マネジメントシステムの一部として位置づけられることが多い。ただし、具体的にどの文書体系にどう組み込むかは、社内のQMS責任者や品質保証部門の判断に委ねられる。本記事の内容は実務上の工夫の紹介であり、規制適合や監査対応を保証するものではない。制度上の解釈が必要な場合は、必ず社内の責任者に確認してほしい。
ツール紹介
分類コードの統一とテンプレート化まで進めたら、次は集計作業そのものを軽くする段階だ。手作業の限界を感じ始めたら、以下のようなアプローチを検討する価値がある。
表計算ベースの自動集計テンプレート
すでに使っているExcelやスプレッドシートの延長で始められる。分類コードごとに関数で自動集計する仕組みを組んでおけば、月次報告の作業時間を大きく減らせる。まずは自社で使っている報告書をベースに、集計用シートを1枚作るところから試すとよい。
クラウド型の苦情・不具合管理システム
複数拠点・複数機種でデータが分散している場合は、クラウド型の管理システムが選択肢になる。入力時点で分類コードを固定でき、集計や傾向分析がリアルタイムに近い形でできる製品も増えている。導入を検討する際は、自社の分類体系にどこまで柔軟に対応できるか、既存の報告フローとどう接続できるかを比較検討することをおすすめする。<
コメント