問題管理モジュールの運用手順書

繰り返す障害の根本原因を、担当者はどの画面で・何を入力し・どのボタンで次へ進めるのか。この記事は、そのまま自社の運用手順書として使える形で手順をまとめたものです。Australia の PDI で実在する問題レコードを段階ごとに確認し、各状態で入力する項目と、状態を進めるボタンの構成を確かめたうえで作成しています。

手順書に含む内容

• 起票からクローズ・Known Error化までの作業手順

• 各段階で入力する項目と記入例

• Stateを直接動かせない仕組みと、専用ボタンの構成

• 重複・中止・リスク受容・差し戻しの判断基準

• クローズ前に確認する項目

手順書として押さえること

• 問題管理の作業は6状態・9段階のSTEPで構成される

• Stateはドロップダウンでは進まず、専用ボタンでのみ進む

• Cause notesとFix notesの必須制御は、RCA到達時ではなくFix in Progress到達時に効く

• 問題管理にはSLAタイマーが付かず、滞留はOOTBレポートで監視する

• major_problemのチェックはreview_outcomeの記入を求める仕組みで、判定基準は事前に合意しておく

1. 本手順書の目的

問題管理の担当者は、繰り返す障害を1件の問題として受け付ける。原因を特定し、恒久対策を打ち、記録を確定するまでの作業を、迷わず同じ品質で実施できるようにする。

記録の品質を保つことを目的に含める。問題の記録はKnown Errorとして再利用され、同じ障害の次のインシデント対応を短縮する。原因と対策の記述が粗いと、この再利用価値が失われる。

各項目の定義そのものを先に押さえたい場合は、次の記事でstate・problem_stateなどの主要フィールドを扱っている。

• 参考：Problem（problem）の読み方 … stateとproblem_stateの構造

2. 適用範囲と前提条件

2-1. 適用範囲

本手順書は、ServiceNow の問題管理モジュールを使用する日常運用を対象とする。Problem Model機能を使ったカスタム状態モデルの運用は対象外とする。

2-2. 前提条件

項目内容対象バージョンAustralia対象テーブルproblem / problem_task必要なロールitil（担当者、書き込み権限を自動で持つ）／sn_problem_read（参照のみ）割り当てルール3件が有効（CIの種別・Business Serviceで自動振分）SLAタイマー付与されない（contract_sla 0件）Problem Model有効（未設定のProblemは既定モデルの制御に従う）

Assignment Ruleが有効なため、対象CIがDatabase・Software・Networkのいずれかに該当すれば担当グループは自動で決まる。該当しない場合は、STEP2で担当者が手動で選ぶ。problem・problem_taskともtaskテーブルを直接継承する構造で、impact／urgency／priorityなど基本項目の型はIncidentと共通している。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … problem／problem_taskが継承する共通基盤

3. 対象者と役割

役割担当する作業問題コーディネーター起票・評価・担当割り当て・クローズの判断調査担当（problem_task_analyst）原因調査・恒久対策の実施・記録問題マネージャ全体の進捗と品質の確認、Canceled・Risk Acceptedの再評価権限一般担当者（itilロール）専用ロールが無くても起票・記録・状態変更ができる

itil ロールは自動的に sn_problem_write を含む。専用ロール（problem_coordinator〜problem_admin）を追加しなくても、itilロールを持つ担当者はProblemを作成・更新できる。専用ロールが持つ追加権限は、リスク受容や中止からの再評価など一部の操作に限られる。

4. 作業の全体像

問題管理の作業は6状態・9段階のSTEPで構成される。

Stateはフォーム上のドロップダウンでは進められない。 New/Assess/Root Cause Analysis/Fix in Progress/Resolvedの各画面ヘッダには専用ボタンが表示される。Assess/Confirm/Fix/Resolve/Completeのいずれかを押して、はじめて次へ進む。実機で状態別のボタン構成を確認したところ、状態ごとに表示されるボタンは次のとおりだった。

New状態にはAssessボタンしかなく、横道（Mark Duplicate等）は選べない。単発の障害を誤って起票してしまった場合でも、Assessへ進めてからでないとCancelできない。 この構成は起票直後の取り消しやすさに関わるため、5章の判断基準とあわせて押さえておく。

実機のProblem一覧をStateでグループ化すると、各状態にレコードが分布している。

24件のうち2件はState: (1)・State: (2)という、現在の選択肢定義（101〜107）には無い値で残っている。移行時の旧task標準state（1=Open、2=Work in Progress）がそのまま残ったデータと見られる。新規に起票する問題がこの2値を持つことはない。

4-1. 優先度は入力せず、導出される

起票のとき、影響度（Impact）と緊急度（Urgency）を入力する。優先度は入力せず、この2項目から自動で決まる。

Impact/Urgencyの公式説明を確認すると、次のとおりだった。

（訳：impact＝問題が業務に与える影響。urgency＝問題の解決がどれだけ遅延に耐えられるか）

引用元：/sys_documentation_list.do?sysparm_query=nameINproblem,problem_task^hintISNOTEMPTY

優先度マトリクスはdl_problem_priorityという専用テーブルで、Impact×Urgencyの3×3＝9パターンで構成される。

Impact・Urgencyともに未入力のまま起票すると、priorityの既定値は上書き設定により5 - Planning（最低優先度）から始まる。実機のレコードもImpact/Urgencyを個別に入力しない限りPriorityは5のままだった。Incidentと違い、Problemには優先度に応じたSLAタイマーが付かない。 期限の管理は6章のレポート監視で代替する。

4-2. 状態を変えると裏側で起きること

問題管理にはstate（101〜107、105は欠番）とは別に、problem_stateという整数型のもう1つの状態フィールドがある。両者はビジネスルール「Copy State to Problem State」と「Copy Problem State to State」で常に同期しており、操作するのはstateだけでよい。この記事で扱う以外にも保存のたびに動くビジネスルールが複数あり、件数は次の記事で実測している。

タイムスタンプ系の項目（confirmed_at／fix_at／resolved_at／closed_atとそれぞれの_by）は、ACLの書き込み権限が役割nobodyに設定されている。人間が画面から直接編集することはできず、状態遷移のたびにビジネスルールが自動で書き込む。 STEP3でConfirmを押すとconfirmed_atが、STEP6でResolveを押すとresolved_atが、それぞれ自動で入る。

• 参考：ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 … 状態同期を支えるBusiness Ruleのタイミング

• 参考：ServiceNowの保存で実際に動くBusiness Ruleは何本か？ problemテーブルで定義と実測を比べる … 1件保存で実際に発火するBusiness Ruleの件数

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … role=nobodyのようなACL条件の読み方

5. 作業手順

STEP1（New）：【問題コーディネーター】繰り返す障害を1件の問題として起票する

操作：左メニューから Problem > Create New を開く。

入力する項目

欄記入例補足Problem statementVPN認証失敗が複数ユーザーで断続的に再発必須。検索で見つかる言葉で書くDescription過去2週間で同種インシデントが複数件発生。一時対応で閉じているが再発が続いているいつ・何が・どれだけ繰り返しているかを書くCategoryNetworkAssignment Ruleの振分条件にもなるConfiguration item対象のCIDatabase/Networkに該当すると担当グループが自動で決まるOrigin taskきっかけとなったIncident番号first_reported_by_task。空でもよいImpact / Urgency2 - Medium／2 - Medium6-1の基準で判定する

確認する項目

• Priorityが自動で入力されていること（未入力なら5 - Planning）

• 同じ障害を追っている問題が既に存在しないこと（重複はSTEP9でMark Duplicate）

• 対象CIがDatabase／Network／Software（Business Service）に該当すれば、Assignment Groupが自動で入ること

実施してはならないこと

• 単発で終わる障害を起票する。繰り返す事象だけを問題管理の対象にする

• 原因の推測をProblem statementに混在させる。起票時点では症状のみを書く

STEP2（Assess）：【問題コーディネーター】担当を割り当てて評価する

操作：ヘッダの「Assess」を押す。Assignment groupとAssigned toを入力して保存する。

確認する項目

• Assigned toが入っていること（Assess以降はデータポリシーで必須になる）

• 自分たちで調査を進める価値があるか、この段階で判断する

横道の選択肢

• Mark Duplicate：既存の問題と同じ障害と判明した場合

• Cancel：調査しても対策コストに見合わないと判断した場合

STEP3（Assess→Root Cause Analysis）：【問題コーディネーター】Confirmで調査対象として確定する

操作：ヘッダの「Confirm」を押す。

成功条件：State欄がRoot Cause Analysisになり、confirmed_atとconfirmed_byが自動で記録される。

注意点：Confirmを押した直後はCause notesが空でも保存できる。データポリシーによるCause notesの必須制御は、この時点ではまだ効いていない。 詳細はSTEP4・実機で気づいたことで扱う。

この記事の有料部に含まれるもの

STEP4以降の作業手順と、判断基準・横道アクションの使い分け・確認項目を記載します。

• STEP4〜STEP9：原因特定・恒久対策・解決・クローズ・Known Error化・横道アクションの操作と記入例（画面つき）

• 第6章 判断基準：Known Error化の3条件、重複・中止・リスク受容の使い分け、滞留の監視

• 第7章 異常時の対応：差し戻しの原因と防止策、担当が決まらない案件への対応

• 第8章 補足：problem_taskの使いどころ、通知の生成条件、クローズ前チェックリスト

分量は本文の後半およそ4,800字です。記入例をそのまま自社の様式に置き換えれば、運用手順書として使えます。

💰 ここから先は有料エリア