欠陥追跡からクローズまでのCAPAタスク付きNCRアプリ

NCRとCAPAプロセスが実際に解決すること

不適合報告（NCR）は、要件を満たしていなかった事実を記録するものです。その要件は図面、仕様、作業指示、あるいは顧客の期待かもしれません。目的は誰かを責めることではなく、事実を新しいうちに記録して同じ問題が繰り返されないようにすることです。

CAPAはCorrective and Preventive Action（是正および予防措置）の略で、NCRが記録された後に行う一連の対応です：なぜ起きたかを調査し、当面の問題を直し、防止策を導入します。良いシステムでは、NCRがトリガーでCAPAがフォローアップになります。

NCRとCAPAを組み合わせることで、問題の一貫した記録、明確な責任者の割当、期日による期限管理、意思決定の追跡可能性、そして再発防止といった実務的な課題に対応できます。

一般的なトリガーは見つけやすいです：顧客クレーム、工程内での不良、最終検査の不合格、供給者の書類不備など。コストが高い繰り返しが予想される場合は、ヒヤリハットでもNCRを残す価値があります。

簡単な例：バッチの寸法検査に落ちた場合。NCRには部品番号、ロット、測定値、写真、発見者を記録します。CAPAでは根本原因分析、是正措置（封じ込めと修正）、予防（工程変更や訓練）、検証を割り当ててからクローズします。

NCRで何を記録すべきか（必要なフィールド）

NCRは意思決定に役立つ情報だけを記録するのが有用です：何が起きたか、規模はどれくらいか、次に何をすべきか。フォームがテストのようになると、人は記入を避けたり「メール参照」と書いたりします。

多くのチームでは次の五つのグループでうまく回ります：

• 識別情報：拠点やライン、日時、報告者、シフト、どこで見つかったか（受入、工程内、最終、現地など）。
• 品目情報：製品、部品番号、改訂、供給者（該当する場合）、ロット/バッチ。
• 欠陥の詳細：平易な説明、カテゴリ、重大度/優先度、影響数量、検出方法。
• 一次封じ込め：すぐに行った対応（保留、選別、手直し、交換）、承認者、現在の保管場所。
• トレーサビリティのリンク：PO、作業指示、顧客注文、必要な場合のみシリアル番号。

添付ファイルは長文より重要です。ひび割れた筐体の写真1枚と許容外の測定を示す検査メモがあれば、後で何時間も節約できます。供給者関連の問題なら、供給者の証明書や書類を添付してください。

例：受入検査員がバッチB-104の12個を指摘した場合、NCRにPO、部品改訂、重大度「高」、封じ込め「隔離ラックQ2に保留」と記録すれば、次の担当者が文脈を探さずに根本原因作業を始められます。

作る前に簡単なNCR→CAPAワークフローを設計する

画面を作る前に、誰もが従えるシンプルなフローで合意してください。明確なワークフローは次の二つの問題を防ぎます：NCRが宙ぶらりんになること、そして小さな問題にすべてCAPAを開いてしまうこと。

実際の作業の動きに合う少数のステータスを選びます（例：Draft、Submitted、Containment、RCA、CAPA、Verification、Closed）。名前は現場の言葉に合わせておくとオペレーター、品質、管理者が同じ解釈をします。

誰がNCRを前に進められるかルールを明確にしてください。例：報告者は保存と提出、品質は受理とルーティング、生産は封じ込めタスクの完了、供給者品質は供給者RCA、管理はハイリスクの承認。

ステータス変更の前提条件（ゲート）をいくつか設けます。最小限に、しかし重要なところは厳格に：

• 封じ込めが記録されるまでRCAを開始しない（何を隔離したか、再作業したか、安全な出荷範囲はどこか）。
• 根本原因が証拠付きで示されるまではCAPAを開始しない。

また、いつCAPAを開くか、いつ軽微な問題としてクローズするかのルールも決めておきます。単純な基準が有効です：欠陥が繰り返される、顧客に影響する、安全に関連する、供給者に体系的な問題がある場合はCAPAを開く。一度だけで完全に封じ込められ、再発リスクが低ければ短い理由を記して閉じます。

承認の流れも早めに決めておきます。多くのチームは軽量なチェーンを使います：品質がNCRを承認、製造が実現可能性を確認、供給者品質が供給者の約束を確認、管理がリスクとクローズをサインオフ。

受け入れられる役割、所有権、権限

人々が役割やルールを信頼しないと、システムの抜け道を作ります。単純に：各NCRに一人の明確な所有者と、委任しても責任を失わないタスクを用意してください。

実務的な役割モデル例：

• 報告者：欠陥と証拠を記録する。
• 品質責任者：NCRの全体責任を持ち、次の対応を決める。
• 担当者（Assignees）：根本原因ステップやアクションタスクを完了し、証拠を添付する。
• 承認者：封じ込め、アクション、クローズなどの主要ゲートを承認する。
• 閲覧者：マネージャ、監査人、他チーム向けの読み取り専用アクセス。

NCRの所有は一人にしておき（多くは品質）、必要ならタスクを再割当てできるが、NCR自体は頻繁に移動させない方が監査対応が楽になります。

権限は実際の作業に合わせます：

• 提出後、報告者は主要事実（日時、製品、欠陥タイプ）を編集できないが、コメントは追加できる。\n- 品質責任者だけがステータス、期日、処分を変更できる。\n- 担当者は自分のタスクだけ編集可能。\n- 承認者は承認または却下でき、却下時はコメント必須。

監査証跡は必須です。ステータス、期日、割当変更など重要な変更について「誰がいつ何を変えたか」を記録し、期日変更などの敏感な変更には理由を残します。

供給者や外部関係者にはシンプルなアクセスを：割当タスクだけに限定するか、内部の代理（多くはSupplier Quality）が供給者の更新を記録する方法が実務的です。

ステップバイステップ：コアなNCRアプリの画面とデータを作る

まずはデータから始めます。テーブルが明確なら画面設計が楽になります。

実務的なコアオブジェクト：NCR（報告）、NCR Item（不良品目）、Task（実施すべき作業）、Comment（議論）、Attachment（写真、PDF、測定値）。一つのNCRは複数のアイテム、タスク、コメント、ファイルを持つことが多いです。タスクは常にNCRを参照するようにして、作業から文脈へワンクリックで戻れるようにします。

コアデータと画面を作る順序

シンプルな構築順序：

• オブジェクトを作る：NCR、NCR Item、Task、Comment、Attachment。\n- 関係を追加：NCR -> Items/Tasks/Comments/Attachments（1対多）。\n- 画面を3つ作る：NCR一覧（フィルタ＋検索）、NCR作成（短い入力フォーム）、NCR詳細（全情報を一画面）。\n- ステータスアクションのためのガードレールを追加（例：「In review」にする前に少なくとも1つのNCRアイテムが必要）。\n- NCR詳細画面からタスク作成と割当ができるようにする。

Create NCRは短く保ちます。作業を始めるのに必要な最小限だけを集める：部品番号、欠陥説明、場所、重大度、検出者、日付。残りは詳細画面で埋めます。

ステータス変更と検証を追加

ワークフロールールでステータス変更を制御し、基本的なチェックを入れます。誰かが提出したら必須項目を検証し、ステータスを設定して提出時間を刻印します。誰かがクローズする際は必須タスクが完了していてクローズノートがあることを確認します。

例：オペレーターが擦り傷のNCRを提出。監督がNCRを開き、封じ込めと調査の2つのタスクを作り担当を割当て、写真を添付します。タスク、コメント、ファイルが同じNCR下にまとまるので、記録は読みやすいままです。

根本原因分析タスクを実効あるものにする

RCAは単なる一つの大きなテキスト欄にすると失敗します。より良いパターンは、再現可能な少数のRCAタスクタイプを用意し、それぞれ明確な成果物を持たせることです。

典型的には3〜5種類のRCAタスクを選び、ほとんどの欠陥に当てはまるように一貫させます：

• 5 Whys要約（短い因果連鎖と最終的な理由）
• フィッシュボーンドラフト（人、方法、機械、材料、環境、測定）
• データチェック（測定値、バッチ履歴、試験結果）
• 工程レビュー（手順ごとにどこが壊れる可能性があるか）
• オペレーターの陳述（何をいつどんな状況で見たか）

タスクは「完了/未完了」で判定できるように書きます。「問題を調査する」は曖昧すぎます。代わりに「Lot 24で使用したトルク範囲を確認し、トルクログを添付する」のように検証可能にします。

すべてのRCAタスクで証拠を必須にします。添付か短いメモのどちらかで、さらに構造化された「Root cause」フィールド（原因、なぜ許したか、証拠）を用意して明確さを強制します。

1つのゲートを設けて早すぎるアクションを防ぎます：RCAが承認されるまではCAPAタスクを始められないようにします。

有効性のテスト：新しい人が証拠をたどって論理を再現できれば、RCAは機能しています。

CAPAタスク：是正、予防、検証、クローズ

是正と予防は似ているようで実務では違います。是正はこの問題の原因を取り除く（今直す）こと、予防は同じ失敗が他の製品やライン、拠点で起きないようにすることです。

NCR/CAPAアプリでは是正と予防を分けて扱ってください。混ぜるとチームが手早いパッチでCAPAを閉じてしまい、翌月に再発することがあります。

アクションを実効にするフィールド

各アクションは第三者が実行できるように書きます。最低限のフィールド例：

• アクション所有者（1人）
• 期日（変更時は理由）
• 受入基準（「完了」が何を意味するか）
• 必要な証拠（写真、試験結果、改訂文書、研修記録）
• 影響範囲（製品、工程ステップ、供給者、顧客）

検証と有効性（多くのチームが飛ばす工程）

検証は即時チェックです：我々は約束したことをやったか、受入基準を満たしているか。可能なら所有者と別の検証者を割り当て、証拠を必須にします。

有効性レビューは後日行うもので、変更が時間を通じて機能したかを確認します。リスクに応じて30〜90日のウィンドウを設定することが多いです。例：「梱包後にラベルのにじみがない」「60日間顧客クレームがない」など。

クローズは感覚ではなくルールにします。すべてのアクションが検証済みで、有効性レビューが完了または正式に免除され、必要な承認が記録されている場合にのみクローズします。

期日、リマインダー、エスカレーション（しつこくしない方法）

期日は公平に感じられると機能します。すべてのタスクが「明日期限」だと人はシステムを信用しなくなります。重大度に基づく妥当なデフォルトを設定し、所有者が変更する際は理由を求めます。

多くのチームが受け入れやすい出発点：

• 重大（Critical）：封じ込め24時間、RCA3日、CAPA14日
• 主要（Major）：封じ込め3日、RCA7日、CAPA30日
• 軽微（Minor）：封じ込め7日、RCA14日、CAPA60日

リマインダーは静かで予測可能に：期日前の1通、期日当日の1通。タスクが「進行中」でコメントが付いている場合は日次通知を避けます。

エスカレーションは停滞リスクを防ぐためのもので、恥をかかせるためではありません。行動につながるルールにします：

• タスクが2日遅延したらNCR担当者に通知
• 7日遅延でタスク所有者のマネージャーに通知
• 続行するには新しい期日と理由を必須に
• 必要な検証が完了するまではクローズをブロック

未処理の蓄積を止めるために「遅延中」を見逃さない工夫を。各役割のホーム画面に遅延タスク数を出すと効果的です。タスク所有者は自分の、NCR所有者は自分の責任分を見られます。

またサイクルタイム（提出→封じ込め、封じ込め→RCA、RCA→クローズ）を追い、単に期日を追うのではなくプロセス改善につなげてください。

日常管理のためのダッシュボードと監査証跡

良いダッシュボードはシステムを落ち着かせます。現場は今日対応すべきことが見え、管理者は重大リスクを監査で指摘される前に察知できます。

まず誰でも素早く使えるNCR一覧を作り、一貫したフィルタを用意します。一般的なフィルタ：ステータス、重大度、製品/工程領域、供給者、現在の責任者。

マネージャービューには次の三つの疑問に答えるタイルを：何が遅れているか？何が古くなっているか？何が繰り返されているか？役立つ表示例は遅延中のRCA/CAPAタスク、30日以上開いているNCR、カテゴリ別の上位欠陥と重大度。

監査証跡は組み込みにします。各NCRとCAPAアイテムについて、誰がいつ何を変えたかの履歴を保存します。最低限、ステータス変更（再オープン含む）、承認、コメントと添付、期日変更（理由付き）、所有者の再割当を記録してください。

報告と監査を楽にするために、重大度、欠陥カテゴリ、根本原因手法、処分などは制御されたリストを使ってください。フリーテキストは重要ですが、それだけに頼らないこと。

例：発見からCAPAのクローズまでの一連

受入検査員が200個中12個のステンレス製ブラケットにバリがあり作業者が怪我をする可能性があると発見。彼女はNCRを記録し写真と供給者ロット番号を添付し、安全リスクとしてタグ付けします。

品質リードは同日中にレビューし、封じ込め措置を決定：該当ロットを隔離し、そのロットを使う作業指示を停止し、生産と購買に通知。現場には「Lot L-4821を使用しない。部品は保留エリアAにあり。」という短い連絡が出ます。

根本原因分析は明確な担当者付きの小さなタスク群として始まります：

• 過去3回分の受入検査記録を確認（品質技術者、期日：水曜）
• 供給者に工程変更履歴と直近の工具保守ログを依頼（購買、期日：木曜）
• QCと受入の5 Whysセッションを行い根本原因を記録（品質リード、期日：金曜）

金曜までにチームは根本原因と合意します：「供給者がバリ取りホイールを変更し、立ち上げ時の初品検査を省略してバリが見逃された」。

CAPAタスクは期日と期待される証拠付きで割り当てられます：

• 是正：供給者が初品チェックリストを更新しオペレータを訓練（供給者QA、期日＋7日、研修記録を添付）
• 予防：受入でブラケットのバリ高さのゲージチェックを追加（品質リード、期日＋10日、更新された作業指示を添付）
• 検証：次の3ロットを厳格サンプリングで検査し結果を記録（受入検査員、期日＋30日、検査ログを添付）

検証がパスしたらのみクローズ。承認者はCAPAを「有効」とマークし、最終検査報告と供給者署名入りのチェックリストを添付してNCRを明確な監査証跡とともにクローズします。

NCRとCAPA追跡を設定する際の一般的なミス

最大の失敗は報告が面倒になりすぎて人が報告をやめることです。NCRフォームで最初から完全な根本原因を求めると、未完成の記入や提出されない事態になります。最初のステップは何が、どこで、いつ、誰が見つけたかに集中し、詳しい調査は後でタスクにしてください。

二番目に多いのは所有権のあいまいさです。「チームに割当」とすると大抵「誰もやらない」になります。各段階で名前のある責任者が必須です。

不明確なルールは混乱を招きます。重大度が感覚任せだと類似欠陥がバラバラに扱われ監査が面倒になります。簡単な例で重大度を定義し、CAPAが必要な条件（繰り返し、顧客影響、安全リスク、工程崩壊）を明示してください。

その他、静かにプロセスを壊す誤り：

• 証拠なしに調査やアクションを完了扱いにする。\n- 是正と予防を混同して結果が分からなくなる。\n- 期日だけ設定してリマインダーやエスカレーションが無く、遅延が常態化する。

また「作業した」という活動だけで閉じるのではなく、結果に基づいて閉じること。"完了"と"有効性検証済み"は同義ではありません。検証を必須ステップにして合格/不合格の明確な判定を求めてください。

すぐ使えるチェックリストと次のステップ

NCRとCAPAタスクがある簡単なアプリは、各レコードが次を答えられることが重要です：何が起きたか、誰がそれを担当しているか、次に何が期日か、そして修正の証拠は何か。

最初の構築は小さく始めます：

• NCRの必須：欠陥説明、製品/ロット、発見日、場所、報告者、重大度、一次封じ込め
• 明確なステータスフロー：New、Under review、RCA in progress、CAPA in progress、Verification、Closed
• 所有と期日：各ステップに一人の責任者、見える期日
• 証拠と承認：写真/ファイル、調査ノート、承認フィールド、クローズ署名
• トレーサビリティ：NCR、RCAタスク、アクション、検証結果のリンク

パイロットは一本のライン、一拠点、または一つの製品群で2〜3週間が適当です。どのフィールドが飛ばされるか、どのステータスが混乱を招くか、引き継ぎがどこで切れるかが学べます。

アプリをどこで動かすかも早めに決めてください。パイロットにはクラウドが最速の場合が多いです。ソースコードのエクスポートやセルフホスティングが必要なチームは、通知やアクセスルールを確定する前にその選択をすると楽です。

AppMaster上で作る場合、NCR、タスク、所有者、期日をデータオブジェクトとしてモデル化し、視覚ワークフローで「RCA承認前はCAPA開始不可」などのゲートを実装できます。実ユーザーで素早くテストしたいチームには、AppMaster (appmaster.io) がコードを書かずに構築・反復する現実的な手段です。