品質疑義とインシデント対応：いつ止め、誰に報告するか
Stage 4 — 第2章 | データマネジメント入門 推定学習時間：45〜55分 | 難易度：★★★☆☆
この章で学ぶこと
品質 6 軸で 何が悪いか は分かりました。 現場では次に、どう動くか が問われます。
返品 CSV 2 日欠損——さくら商事では、経理からの疑義が出てから初めて原因が特定され、経営会議用ダッシュボードは そのまま公開されたまま 2 日間走り続けました。
この章を終えると、こんなことができるようになります：
- 品質疑義（Quality Issue）とインシデントの 違いとエスカレーション を説明できる
- 検知 → 調査 → 修正 → 再発防止 → 通知の流れを設計できる
- いつ公開を止めるか の判断基準を持てる
- さくら商事の返品欠損をインシデントとして処理する手順を説明できる
1. 疑義が出てから動く問題
| 日 | 出来事 |
|---|---|
| 月 | 返品 CSV 取込失敗（アラート未設定） |
| 火 | 経理が Looker 数字を ERP と照合、差拡大 |
| 水 | 佐藤さんが Slack で「データおかしい」 |
| 水 15 時 | 鈴木さんが原因特定。火・水の会議数字は 未修正のまま使用 |
経営・木村
「火曜の会議、返品抜けの数字で決めたってこと？」
疑義対応が遅い = 意思決定が汚れたデータの上で進む リスクです。
2. 疑義 vs インシデント
| 概念 | 定義 | 例 |
|---|---|---|
| 品質疑義 | 「この数字信じていい？」という 問い | 経理からの Slack |
| 品質インシデント | 影響範囲・重大度が確定し 対応プロセスが起動 した状態 | 公式売上マートの Completeness 欠損 |
疑義は 入口。インシデントは 正式対応 です。
2.1 重大度（例）
| レベル | 条件 | さくら商事の対応 |
|---|---|---|
| S1 critical | 公式 KPI 誤り、外部報告影響 | 公開停止、経営報告 1h 以内 |
| S2 major | 部門 KPI 誤り、会議使用 | 該当ダッシュボード停止、24h 報告 |
| S3 minor | 探索用、影響限定 | チケット、次営業日対応 |
返品 2 日欠損で 公式 mart_finance に影響 → S1〜S2 相当です。
3. 疑義が出たら
次のフローは、さくら商事が返品欠損後に 正式導入 した手順です。
返品CSV 0件"] S2["2. 調査
影響期間特定"] S3["3. 停止
公式KPI停止"] S4["4. 修正
再取込・更新"] S5["5. 再発防止
runbook"] S6["6. 通知
経理・経営"] S1 --> S2 --> S3 --> S4 --> S5 --> S6 classDef detect fill:#fef2f2,stroke:#dc2626,color:#1f2937 classDef act fill:#eff6ff,stroke:#2563eb,color:#1f2937 classDef stop fill:#fef2f2,stroke:#dc2626,color:#1f2937 classDef fix fill:#eff6ff,stroke:#2563eb,color:#1f2937 classDef prevent fill:#f0fdf4,stroke:#16a34a,color:#1f2937 classDef notify fill:#f5f3ff,stroke:#7c3aed,color:#1f2937 class S1 detect class S2 act class S3 stop class S4 fix class S5 prevent class S6 notify
多くの組織で抜けるのは 公開停止 と 関係者通知。 修正 SQL より先に、汚れた数字の流通を止めます。
3.1 各ステップの担当
| ステップ | 担当 | アウトプット |
|---|---|---|
| 1. 検知 | DE 監視 / アナリスト | アラート、疑義チケット |
| 2. 調査 | DE + AE | 原因、影響期間、影響マート |
| 3. 公開判断 | データオーナー + ガバナンス | 停止 / 注記付き継続 |
| 4. 修正 | DE / AE | 再取込、マート再実行 |
| 5. 検証 | AE + スチュワード | 品質ルール再パス |
| 6. 通知 | オーナー | 経理・経営・利用者へ |
| 7. 再発防止 | DE | アラート、runbook 更新 |
Stage 1 の ロール がここで効きます。「SQL 直して」だけでは閉じません。
4. いつ止めるか：判断表
| 状況 | 止める？ | 理由 |
|---|---|---|
| 公式売上の Completeness 欠損 | 止める | 意思決定に直結 |
| マーケ探索用 sandbox のみ | 注記で継続可 | 非公式 |
| 原因不明・調査中（公式） | 止める or 暫定注記 | 説明責任 |
| 軽微な Timeliness（1 時間遅延） | 用途次第 | 在庫 vs 月次 |
現場メモ
「止めたら困る」は 止めない理由にならない ことが多いです。 暫定注記付き公開 > 無注記継続、が説明責任ではマシです。
5. さくら商事の改善後 runbook（抜粋）
タイトル: 返品取込失敗
- アラート:
bronze_refunds日次件数 0 → PagerDuty - 自動: Looker「公式売上」ダッシュボードに 警告バナー
- 15 分以内: DE が調査開始、#data-incident チャンネル開設
- 影響
mart_finance期間を特定 → オーナー（佐藤）が公開停止承認 - 修正・再実行・Q-001〜004 再パス
- 経理・経営へ 影響期間と修正後数字 をメール
- ポストモーテム（再発防止）
6. ポストモーテムで書くこと
| 項目 | 返品欠損の例 |
|---|---|
| 何が起きたか | CSV パス変更、取込 0 件 |
| なぜ検知遅れたか | 件数アラート未設定 |
| 影響 | 6/12–13 公式売上が過大 |
| なぜ止めなかったか | 公開停止ルールなし |
| 再発防止 | アラート、runbook、Q-001 |
責任追及だけで終わらせず、システムとプロセス を直します。
体系コラム：カリキュラム上の位置づけ
| 項目 | 内容 |
|---|---|
| Stage / 章 | Stage 4 — 第2章「品質インシデント」 |
| 今回の論点 | 疑義 → インシデント → 止める・伝える・直す の型 |
| DAMA 領域 | データ品質、データガバナンス（エスカレーション） |
| ライフサイクル | 活用段階で問題が顕在化。加工段階の再発防止へ |
| 前章との接続 | 品質 6 軸 で検知した異常を 運用 する |
| 次章への伏線 | 野良マートと SSOT — インシデントの温床となる 非公式経路 |
コラム：さくら商事メモ — 返品欠損の 72 時間
火曜朝、山田さんがダッシュボード更新。返品反映前の売上が経営向けに表示されました。水曜の会議で木村さんが数字を引用。木曜、経理の佐藤さんが「返品 2 日分が入っていない」と指摘—— 止めるルールがなかった 72 時間です。
模範的な動きはこうです。疑義発生 → 鈴木さんが Q-001 アラート → 公開停止 → 佐藤さん（オーナー）判断 → 修正後に再公開 → ポストモーテム。実際は「忙しいからそのまま」が個人判断に委ねられました。
改善後の runbook では、公式系ダッシュボードに 品質フラグ NG なら自動非表示 を入れました。インシデント対応は英雄頼みではなく、誰が何をいつ止めるか を先に書く活動です。
まとめ
| ポイント | 内容 |
|---|---|
| 疑義 | 信頼への問い。放置すると意思決定リスク |
| インシデント | 正式プロセス。止める・伝える・直す |
| 公開停止 | 公式 KPI では躊躇しない |
| 担当 | DE/AE だけでなくオーナー・ガバナンス |
この章のキーメッセージ：
品質問題は バグ修正 だけでなく 通信と停止判断 を含む運用です。 修正が終わるまで、汚れた数字を会議に流さない——それがデータマネジメントの現場力です。
次に読む
- 前章: データ品質の 6 軸
- 次章: 野良マートと SSOT 崩壊
- 関連: 誰が何を担うか
確認問題
問題 1
公式売上マートに Completeness 欠損が判明。修正に 4 時間かかる見込み。 最も適切な初動 はどれですか。
A. 修正完了まで黙って作業。ダッシュボードはそのまま
B. インシデント起票、公式ダッシュボード停止、影響期間をオーナー経由で通知
C. マーケだけに口頭で伝える
D. 欠損を埋めるため Bronze を手編集（監査ログなし）
正解: B
解説: 停止と通知 が先です。A/C は意思決定リスク、D はリネージ・監査を壊します。
問題 2
探索用 sandbox のみに Timeliness 1 時間遅延。公式マートは正常。 重大度として最も適切 なのはどれですか。
A. S1 critical。全社停止
B. S3 minor。チケット対応、公式は継続
C. インシデント不要
D. 経営報告必須
正解: B
解説: 影響が sandbox に限定なら major/critical ではありません。公式正常なら全社停止（A）は過剰です。
問題 3
返品欠損のポストモーテムで「鈴木さん個人のミス」とだけ記録した。 データマネジメントとして不足している点 はどれですか。
A. システム要因（アラート未設定）とプロセス（公開停止ルール）の改善が書かれていない
B. 問題ない。個人のせいにすれば再発しない
C. SQL の書き方だけ直せば十分
D. ポストモーテム自体が不要
正解: A
解説: 品質インシデントは 再発防止設計 が目的です。個人帰結だけでは組織は学習しません。
用語メモ（この章）
| 用語 | 意味（この章での使い方） |
|---|---|
| 品質疑義 | データへの信頼を問う指摘 |
| 品質インシデント | 正式対応プロセスが起動した品質事象 |
| runbook | 障害・品質問題時の手順書 |
| ポストモーテム | 事後レビューと再発防止 |
| 公開停止 | 汚れた公式数字の配信を止める判断 |