⏱ 15秒で読む結論

対象読者

データ移行プロジェクトの最中、エラーで処理が停止したとき「これはインシデントか？課題か？それともプログラムの故障か？」と現場で議論が始まってしまうことがあります。

一見するとただの言葉の定義に見えますが、分類が決まらないと以下のような問題が起きます。

トラブル対応で最も避けるべきは、「どう分類するか」に時間を取られてプロジェクトが停滞することです。

分類の本来の目的は「次にどう動くか」を決める交通整理です。現場での迷いをなくすために、以下の3つの判断軸と二層構造の捉え方を整理して運用しました。

分類	判断の軸	具体例	発生するアクション
故障（不具合）	本来正しく動くべきプログラムが壊れているか？（仕様との乖離）	仕様通りの正常データなのに処理エラーになる	プログラムの修正
インシデント	現在、サービスや移行工程が阻害されているか？（運用上の異常）	想定外の形式のデータが混入し、処理が停止した	復旧・影響最小化を最優先（暫定対応）
課題	今後も再発するリスクがあり、仕組みの変更が必要か？（構造的問題）	移行元システムのデータクレンジングが不十分	設計や運用ルールの見直し（恒久対策）

2.「二層構造」で捉えて同時に走らせる
現場でよくあるミスのひとつが、1つの事象を「インシデント」か「課題」のどちらか一方だけに当てはめようとすることです。実際には1つの事象に対して2つの側面からアプローチするのが正解です。

移行対象外のデータが混入したら、まずはそのデータを手動で隔離・除外して、全体の処理を速やかに再開させる。

「なぜ対象外データが抽出されたのか」の抽出ロジックや運用の不備を分析し、次回のリハーサルや本番に向けた再発防止策を講じる。

この切り分けができると、現場は「まずは動かす（暫定）」と「後で直す（恒久）」を両立できるようになります。

データ移行におけるトラブル対応では、「その場ではインシデントとして迅速に処理し、構造的には課題として冷静に管理する」という二層構造の視点が大切です。

分類を素早く終わらせ、チームが「今、何をすべきか」に集中できる環境を作っていきましょう。

この記事は社内ナレッジをもとに作成しました。