⏱ 15秒で読む結論
-
トラブル時の「これはインシデント？課題？」という議論で移行作業を止めない
-
故障（仕様との乖離）、インシデント（現在の阻害）、課題（構造的リスク）の3軸で切り分ける
-
1つの事象を「暫定対応＝インシデント」「恒久対策＝課題」とする二層構造で管理する
-
分類は目的ではなく「誰が・どの優先度で・再発防止が必要か」を決める交通整理
対象読者
-
データ移行やシステム移行プロジェクトに携わるエンジニア・PM・情シス
-
トラブル発生時に「言葉の定義」や「管理区分」で議論が紛糾した経験がある人
背景・課題
データ移行プロジェクトの最中、エラーで処理が停止したとき「これはインシデントか？課題か？それともプログラムの故障か？」と現場で議論が始まってしまうことがあります。
一見するとただの言葉の定義に見えますが、分類が決まらないと以下のような問題が起きます。
-
対応の責任範囲があやふやになり、誰も動けない
-
優先度の判断が遅れ、移行のタイムリミットが削られる
-
「とりあえず直す」と「根本原因を潰す」のバランスが崩れる
トラブル対応で最も避けるべきは、「どう分類するか」に時間を取られてプロジェクトが停滞することです。
解決策
分類の本来の目的は「次にどう動くか」を決める交通整理です。現場での迷いをなくすために、以下の3つの判断軸と二層構造の捉え方を整理して運用しました。
- 迷わないための「3つの判断軸」
| 分類 | 判断の軸 | 具体例 | 発生するアクション |
|---|---|---|---|
| 故障（不具合） | 本来正しく動くべきプログラムが壊れているか？ （仕様との乖離） |
仕様通りの正常データなのに処理エラーになる | プログラムの修正 |
| インシデント | 現在、サービスや移行工程が阻害されているか？ （運用上の異常） |
想定外の形式のデータが混入し、処理が停止した | 復旧・影響最小化を最優先 （暫定対応） |
| 課題 | 今後も再発するリスクがあり、仕組みの変更が必要か？ （構造的問題） |
移行元システムのデータクレンジングが不十分 | 設計や運用ルールの見直し （恒久対策） |
2.「二層構造」で捉えて同時に走らせる
現場でよくあるミスのひとつが、1つの事象を「インシデント」か「課題」のどちらか一方だけに当てはめようとすることです。実際には1つの事象に対して2つの側面からアプローチするのが正解です。
- 暫定対応（インシデント管理）
移行対象外のデータが混入したら、まずはそのデータを手動で隔離・除外して、全体の処理を速やかに再開させる。
- 恒久対策（課題管理）
「なぜ対象外データが抽出されたのか」の抽出ロジックや運用の不備を分析し、次回のリハーサルや本番に向けた再発防止策を講じる。
この切り分けができると、現場は「まずは動かす（暫定）」と「後で直す（恒久）」を両立できるようになります。
注意点
-
分類自体を目的化しない：分類に時間をかけるくらいなら、まずは「インシデント」として暫定対応を進め、移行処理を止めてしまわないことを優先してください。
-
すべてを課題管理票に載せない：軽微なインシデントの暫定対応で閉じるものまで「課題」に上げてしまうと、本当に重要な構造的課題が埋もれてしまいます。
まとめ
データ移行におけるトラブル対応では、「その場ではインシデントとして迅速に処理し、構造的には課題として冷静に管理する」という二層構造の視点が大切です。
分類を素早く終わらせ、チームが「今、何をすべきか」に集中できる環境を作っていきましょう。
この記事は社内ナレッジをもとに作成しました。