Contents
まとめ（この記事で得られること）
- Jira Service Management (JSM) のインシデント管理 がどのように ITIL に沿って構築されているかを把握できる
- 標準ワークフローや SLA・キュー自動化 を実装する具体的手順が分かる
- ITIL テンプレート の活用方法と、インシデントから問題・変更管理へスムーズに連携させるベストプラクティスが理解できる
本稿は Atlassian 公式ドキュメントを基に構成しています。実際の設定画面や最新機能については、Atlassian のヘルプセンターをご確認ください。
1. JSM におけるインシデント管理の全体像
JSM は ITIL 標準に合わせた インシデント管理フロー を UI 上で可視化し、サービス復旧までの一連の作業を効率化します。本セクションでは、公式ドキュメントが示す「インシデント」の定義と、主要コンポーネント（プロジェクト・キュー・SLA）の役割を整理します。
1‑1. インシデントの定義と基本フロー
インシデント とは「サービスの中断または品質低下」を指し、JSM では次の４段階で管理されます。
| フェーズ | 主な作業 |
|---|---|
| 報告 | エンドユーザーや監視ツールがインシデントを作成 |
| 記録 | インシデントキー・タイムスタンプが自動付与、SLA が開始 |
| 分類・優先度付け | カテゴリ・ラベル付与、優先度算出（例：影響範囲×復旧期限） |
| 解決・クローズ | 根本原因記録、対応結果入力、インシデントを閉じる |
公式ガイドはこの流れをベストプラクティスとして提示しています【Atlassian 製品ガイド – Incident Management】。
2. インシデント管理のベストプラクティスとワークフロー設計
実務で使えるベストプラクティスは、標準ワークフローをカスタマイズしつつ他プロジェクト（問題・変更）との連携を確保 することです。ここではステータス遷移の設計ポイントと自動化手法を解説します。
2.1. 標準ワークフローの構成
標準ワークフローは以下の４つのステータスで構成されます。
- 受理（Open）
- 調査中（In Progress）
- 解決済み（Resolved）
- クローズ（Closed）
2.1‑1. 条件付きトランジションとエスカレーション
条件付き遷移を設定すると、たとえば 優先度が「Critical」以上 のインシデントは自動的に上位チームへエスカレーションされます。これにより対応漏れを防止できます。
設定例：
調査中 → 解決済みへの遷移条件として「SLA が開始から30分以内でない」場合、Automation が担当者へリマインダーを送信（公式ガイド参照）【Best Practices for Incident Management】。
2.2. 問題・変更管理へのリンク活用
インシデントから派生した 根本原因分析（Problem） や 修正作業（Change） は、JSM の Issue Link 機能で紐付けます。
- メリット：インシデントのステータス変更が自動的に関連課題へ反映され、情報整合性が保たれる
- 実装例：インシデント画面の「リンク」ボタンから
Problem課題を作成し、フィールドマッピング（インシデント ID ↔ Problem の根本原因）を設定。問題解決後に自動でインシデントがクローズへ遷移
3. ITIL テンプレートで始めるインシデントプロジェクト作成手順
JSM が提供する ITIL テンプレート は、数クリックでベストプラクティスに沿ったプロジェクトを構築できる入口です。以下ではテンプレート選択から SLA・キュー自動化までの具体的な設定フローをご紹介します。
3.1. テンプレート選択と初期設定
- プロジェクト作成 → 「テンプレートを使用」
- 「ITIL インシデント」テンプレート を選択
- プロジェクト名・キーを入力し、デフォルト SLA（例：P1 は 30 分以内解決）を有効化
テンプレートは Atlassian が ITIL に基づいて設計しているため、標準フィールド・ステータス・SLA が自動的に適用されます。詳細は公式ヘルプの「Create a project using an ITIL template」をご参照ください。
3.2. SLA とキュー自動化の具体例
カスタムキュー作成
| キュー名 | 表示条件 |
|---|---|
| P1 重大 | priority = P1 AND status != Closed |
| ネットワーク系 | component = Network AND status = In Progress |
Automation ルール例
- トリガー：インシデント作成時
- 条件：
priority = P1 - アクション：担当者を「オンコールチーム」に設定、Slack の #incident-alert に通知
Automation の設定は公式ドキュメントの「Automation rules for JSM」に詳しく掲載されています。
SLA カスタマイズ例
| SLA 名称 | 対象優先度 | 目標時間 |
|---|---|---|
| P1 SLA | P1 | 30 分以内解決 |
| P2 SLA | P2 | 4 時間以内解決 |
SLA が超過した場合は自動でエスカレーションメールが送信されます。
4. インシデントライフサイクルと実装チェックリスト
本章ではインシデントの 4 ステップ（報告・記録・分類・解決）を時系列で整理し、各フェーズで必要な設定項目をチェックリスト形式で提示します。
4.1. 各ステップの要点
| フェーズ | 主な作業 | 推奨設定 |
|---|---|---|
| 報告 | エンドユーザー／監視ツールがインシデントを入力 | カスタムフィールド「影響サービス」「検出元」追加 |
| 記録 | キー・タイムスタンプ自動付与、SLA 開始 | 「作成日時」自動設定、SLA 起動トリガー |
| 分類・優先度付け | カテゴリ／ラベル付与、優先度算出 | ラベル network/database、優先度マッピング表（影響範囲×復旧期限） |
| 解決 | 根本原因記録、対応結果入力、クローズ | 「根本原因」テキストフィールド必須化、解決コメントのテンプレート化 |
4.2. カスタムフィールド・ラベル・通知ルール例
- カスタムフィールド
- 影響サービス（シングル選択） – 「メール」「Web」など
-
復旧目標時間 (RTO)（数値） – SLA 計算に利用
-
ラベル活用例
-
network,database,securityでフィルタリングし、キュー画面の「ラベル別」ビューを設定 -
通知ルール
- トリガー：
priority = P1に変更されたとき - アクション：Slack の #incident-alert へメンション＋オンコール担当者へメール送信
これらの設定はすべて Atlassian の公式ヘルプページに手順が掲載されています。リンク先で最新情報をご確認ください。
5. 今後の展望と注意点（2026 年以降の機能追加）
現在、JSM が提供する AI ベースの自動トリアージ はベータ版として一部顧客に試験的に提供されていますが、公式リリースノートで正式な機能追加がアナウンスされるまで、実運用環境への導入は推奨しません。代替策として以下を活用してください。
| 代替手段 | 内容 |
|---|---|
| Automation + カスタムフィールド | 過去のインシデントデータを元に条件分岐を作成し、優先度や担当チームを自動割り当て |
| 外部 AI ツールとの連携 | Atlassian Marketplace の認定アドオン（例：Automation for JSM）を利用し、自然言語解析結果を JSM にインポート |
| 手動レビューのフロー強化 | 「新規インシデント作成時」に必ず担当者が確認するステップを追加し、誤分類リスクを低減 |
公式情報は常に Atlassian の「Release notes」で更新されますので、導入前に必ず確認してください。
おわりに
Jira Service Management を ITIL に沿って正しく設定すれば、インシデントの可視化・自動化が進み、SLA 達成率や顧客満足度の向上につながります。本稿で紹介した ワークフロー設計、テンプレート活用、Automation 設定 を順に実装し、組織に最適なインシデント管理基盤を構築してください。質問や具体的な設定支援が必要な場合は、Atlassian コミュニティや公式サポートをご利用いただくとスムーズです。