問題管理モジュールの運用設計書

問題管理を動かすには、誰が問題化を判断し、いつ Known Error にし、いつクローズするかを決める必要があります。ServiceNow は6状態の遷移ボタンと resolution_code の仕組みを用意していますが、「何件再発したら問題にするか」「原因調査をいつ打ち切るか」は決めてくれません。この記事は、Australia の PDI の構成を前提とした運用設計書のサンプルです。章立てと記述の粒度を、そのまま自社の設計書に流用できる形にしています。

本書に含む章

• 運用設計書に必要な章立て

• 問題マネージャ・問題コーディネータ・RCA実施者という3層の役割分担

• SLA定義が0件という前提での時間管理の設計

• 起票基準とKnown Error化の判断基準

• Incidentとの自動連携の実態と、運用に反映すべき点

設計の前提

• ロール6件は、問題マネージャ・問題コーディネータ・RCA実施者の3層を想定した構成になっている

• SLA定義（contract_sla）はcollection=problemで0件が標準であり、時間管理はSLA以外の設計に委ねられている

• stateとは別にproblem_stateという整数フィールドが存在し、ビジネスルールで相互同期している

運用設計書の章立て

ServiceNow のモジュール運用設計書は、次の構成とする。

章内容1本書の目的と適用範囲2前提条件3運用体制4役割分担（RACI）5運用ルール6サービスレベル7エスカレーション8通知と報告9品質管理10会議体11教育と引き継ぎ12運用開始の準備13用語定義

開発設計書が「どう作るか」を定めるのに対し、運用設計書は「誰がどう回すか」を定める。両者で項目は重複させない。resolution_codeの選択肢は開発設計書に、事象に応じてどのコードを選ばせるかは運用設計書に記載する。

運用手順書は「どの画面で何を入力し、どのボタンで進めるか」という実行手順を定める。本書はその判断の根拠となる基準・体制・指標を定め、実行手順には立ち入らない。

• 参考：問題管理モジュールの運用手順書 … 起票からClosed・Known Error化までの操作手順と記入例はここで確認する

第1章：本書の目的と適用範囲

本書は、ServiceNow の問題管理モジュールを日常運用するための体制・役割・ルールを定める。

対象読者は、運用の責任者と各役割の担当者とする。システムの設定値と実装方式は、別途の開発設計書で定める。

適用範囲は、問題の起票から恒久対策の完了・クローズまでの日常運用とする。インシデントからの起票基準は第5章に、恒久対策に伴うChangeへの引き継ぎも第5章に記載する。

運用の目的は、同じ障害の再発を止めることにある。暫定対応で業務を今すぐ戻すのはインシデント管理の役割であり、問題管理は根本原因を絶って再発そのものを防ぐ。この分担を前提として、以降の章を定める。

第2章：前提条件

2-1. 製品が想定している役割分担

ロール6件の構成をもとに、体制を次のとおり定める。

層役割対応するロール起票者障害の再発や慢性障害を報告するitil（追加ロールなしでsn_problem_writeを自動保有）問題コーディネータ評価・割当・進行管理を担うproblem_coordinatorRCA実施者原因調査と恒久対策を実施するproblem_task_analyst問題マネージャ全体統括とAccept Risk承認を担うproblem_manager管理者設定の変更・削除を行うproblem_admin

problem_managerの権限範囲は、製品の説明に従う。

（訳: 問題管理プロセス全体に責任を持ち、設定の管理と問題コーディネータの代行ができる）

引用元: /sys_user_role_list.do?sysparm_query=nameLIKEproblem

problem_coordinatorは「作業を担当し、ライフサイクルを通じて管理する」役割、problem_managerは「その上位でプロセス全体を統括する」役割という位置づけである。本書ではこの2層に加え、実際の原因調査を行う担当をproblem_task_analyst（RCA実施者）として区別する。

2-2. Problem に SLA が無い前提での時間管理

contract_slaをproblemで絞ると0件になる。インシデント管理と異なり、問題管理にはOOTBのSLA定義もエスカレーションルールも存在しない。

SLA定義もエスカレーションルールも0件のまま維持する。恒久対策は原因調査から対策実施まで時間がかかる性質を持ち、期限を機械的に計測する設計にはなじまない。

有効な仕組みとして残るのは、Assignment Rule 3件（Database/Software/Network）による初動の自動振り分けだけである。時間の管理は、SLAではなく次章以降で定めるRCA・Fixの目標日数と滞留レポートに委ねる。

SLAが無い前提を体制設計に反映しないと、インシデント管理と同じ感覚で期限を約束してしまい、履行できない目標を掲げることになる。

• 参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 有効化の判断材料

2-3. 通知の宛先方針

有効な通知8件を確認すると、宛先はassigned_to・assignment_group・opened_by・work_notes_listの4種類に限られる。本設計もこの4項目で通知の宛先を構成し、固定の追加宛先は置かない。

問題管理には、インシデントの申告者（Caller）に相当する一般利用者向けの宛先が無い。通知は問題管理に関わる担当・グループ・起票者に閉じる設計とし、一般利用者への周知は必要に応じて手動で行う。

8件のうち2件（Problem Closed、Problem Closed inform Opener）は設定に不整合があり、実際には届かない可能性が高い。詳細と対処方針は第8章で定める。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う

第3章：運用体制

3-1. 基本方針

1. 問題マネージャ1名の下に問題コーディネータを置き、評価から恒久対策完了までの進行管理責任を持たせる

2. RCA実施者は二次対応チームが兼務し、専任は置かない

3. assigned_toの選択肢はロール保持者に絞り込まれているため、ロール付与を体制構築の起点にする

4. Assignment Rule 3件を有効化し、カテゴリ別の初動割り当てを自動化する

3-2. 概要図

起票された問題はAssignment Ruleで3チームへ自動振り分けされ、問題コーディネータが週次で評価する。打ち切りが必要な案件のみ問題マネージャへ相談する。

3-3. 設計項目

項目決定内容起票経路インシデントの再発検知・直接起票・監視からの慢性障害検知の3経路問題マネージャの人数1名問題コーディネータの人数2〜3名RCA実施者の分割Database / Software / Network の3チーム・各チームリードが兼務自動振り分けAssignment Rule 3件（CI種別・Business Serviceで判定）assigned_toの制約problemはproblem_coordinatorロール保持者のみ、problem_taskはproblem_task_analystロール保持者のみ選択可評価のサイクル週次の問題レビュー会でまとめて評価

3-4. 詳細設計

起票経路

起票経路は3つとする。同一カテゴリ・同一CIでインシデントが繰り返す再発検知、担当者が直接起票する経路、監視ツールが検知した慢性障害を取り込む経路である。経路ごとに起票の質が異なるため、第5章の起票基準はこの3経路すべてに共通して適用する。

問題マネージャの人数

1名を専任として置く。問題管理で中心になるのは、Accept Riskの承認や重大インシデントの問題化判断など、意思決定の一貫性が求められる場面である。複数人に分散すると、打ち切りの基準がぶれる原因になる。

問題コーディネータの人数

2〜3名とする。評価・割当・進行管理を担うため、RCA実施者からの相談を受けられる人数が要る。1名体制では不在時に評価が止まるため、最低2名を配置する。

RCA実施者の分割

Assignment Ruleの3分類（Database/Software/Network）と揃え、Database/Software/Networkの3チームとする。各チームのリードがRCA実施者を兼務し、専任の調査担当は置かない。専任を置くほど、日常の運用（インシデント対応）との切り替えコストが増えるためである。

自動振り分け

Database Problemはcmdb_ci.sys_class_name=cmdb_ci_database、Software Problemはbusiness_serviceがSoftware相当のとき、Network Problemはcmdb_ci.sys_class_nameがネットワーク機器のときにそれぞれ該当チームへ割り当てる。標準で3件とも有効であるため、CI種別とBusiness Serviceの対応関係を自社のCMDBに合わせて確認したうえでそのまま採用する。

assigned_toの制約

problem.assigned_toの候補はreference_qualによりproblem_coordinatorロール保持者に絞り込まれている。problem_task.assigned_toも同様にproblem_task_analystロール保持者に絞られる。ロールを付与していない担当者は、割り当て先の候補にすら現れない。体制図を描くだけでなく、実機でロールを先に付与しておかないと、割り当て作業そのものが止まる。

評価のサイクル

週次の問題レビュー会（第10章）で、その週に起票された問題をまとめて評価する。起票のたびに個別評価すると問題コーディネータの負荷が高くなり、緊急性の低い問題の評価が後回しになりやすいためである。

記入例（体制の運用イメージ）

本環境には、問題コーディネータとして「Problem Coordinator A」「Problem Coordinator B」の2名が登録されている。24件のProblemの大半を、この2名で分担している。問題マネージャは「Problem Manager」1名で、Priority 2-HighのPRB0000106（Webexアプリケーション障害）を直接担当する。この人数構成は3-4項で定めた「問題コーディネータ2〜3名・問題マネージャ1名専任」と一致している。本設計はこの構成を、最小体制の目安として採用する。

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

4章以降に、運用設計書の記述サンプルを掲載します。

• 第4章 役割分担：RACI（13作業ぶん）と作業ごとの割り当ての意図

• 第5章 運用ルール：起票基準・二重state運用・Known Error化基準・resolution_codeの使い分け

• 第6章 サービスレベル：SLA非採用の判断と、代替の時間管理設計

• 第7章 エスカレーション：滞留を起点にした報告基準6つ

• 第8章 通知と報告：通知8件の挙動と、incident.problem_idを使った自動連携の実態

• 第9章 品質管理：指標5つと集計方法

• 第10章 会議体：4種類の会議の頻度・参加者・議題

• 第11章 教育と引き継ぎ：教育項目と引き継ぎの書式

• 第12章 運用開始の準備：確認項目14件と分野別の完了基準

分量は本文の後半およそ11,000字です。自社で変えるのは起票基準の件数・打ち切りの目標日数・KPIの目標値の3つ。それ以外は据え置きでも運用設計書として使えます。

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