【もんだいれこーど】
問題レコード とは？
最終更新:
💡 原因の調査と対策を、引き継げる記録にする
問題管理で、インシデントの原因や潜在的な原因について、調査と対策の情報を追跡する記録。関連するインシデント、分かったこと、回避策や対応の判断などを更新していく。
📌 このページのポイント
- 原因がまだ分からない段階から、調査の情報を記録できる
- 関連するインシデントと結び付け、症状や影響を整理する
- 調査結果、回避策、対策とその判断を更新していく
- ITIL 4の既知エラーは、分析済みで未解決の問題を指す
ひよこ 原因が判明してから作るの？
ペンギン先生 原因がまだ分からなくても、問題として調査する情報を記録できるよ。何を調べ、何が分かり、何が未確認かを引き継げるようにするんだ。
ひよこ インシデントの記録とは違う？
ひよこ どんな情報を書くの？
ペンギン先生 症状や影響するサービス、関連するインシデント、担当者や調査状況、判明した原因、回避策や対策などが例だよ。未確認の仮説を確定した原因として書かず、分かったことに応じて更新しよう。
ひよこ 原因が分かると既知エラーへ昇格する？
ペンギン先生 ITIL 4では、分析済みで未解決の問題が既知エラーだよ。原因と回避策が両方そろうことだけを条件にした「昇格」と説明すると狭すぎる。記録や状態をどう管理するかは、組織やツールの運用に合わせるんだ。
ひよこ 必ず恒久対策をしてクローズするの？
ペンギン先生 対策の効果や費用、影響を踏まえて対応を判断するよ。すべてを直ちに修正するとは限らない。解決、保留、クローズなどの基準は運用で定め、見送る場合も判断の理由と残るリスクを記録しておこう。
まとめ：ざっくりこれだけ覚えればOK！
「Problem Record」って出てきたら「障害の原因の調査と対策を追跡する記録」と思えばだいたいOK！
📖 おまけ：英語の意味
「Problem Record」 ＝ 問題の記録
💬 Problemは問題、Recordは記録だよ。ここでの問題は、インシデントの原因または潜在的な原因を指すんだ。