> 継続的なプロセス改善 > インシデント管理 > Jira Service Management > データテンプレート

インシデント管理データテンプレート

Jira Service Management

インシデント管理の属性 (23) インシデント管理のアクティビティ (15) 抽出ガイド (4)

インシデント管理データテンプレート

このテンプレートでは、インシデント管理プロセスの分析に必要なデータを体系的に収集できます。収集すべき重要な属性、追跡すべき主要なアクティビティ、さらにソースシステムから情報を抽出するための具体的な手順をまとめています。これにより、インシデント解決ワークフローの最適化に必要な要素をそろえられます。

収集を推奨する属性
追跡すべき主要なアクティビティ
Jira Service Managementからの抽出手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

インシデント管理の属性

インシデント管理プロセスを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 6 推奨 12 任意

	名前	説明
	アクティビティ ActivityName	インシデントで発生した特定のイベントまたはステータス変更の名称です。
説明アクティビティは、インシデント管理のライフサイクルにおける個別の手順またはイベントを示します。たとえば、「Incident Created」、「Incident Assigned」、「Resolution Proposed」などです。通常は、Jiraの課題履歴または変更履歴に記録されたステータス移行や特定の更新イベントから作成します。これらのアクティビティの順序と所要時間を分析することがプロセスマイニングの主な目的です。実際のプロセスフロー、ボトルネック、逸脱を明らかにできます。重要な理由アクティビティはプロセスマップの基盤となり、インシデントのライフサイクルを可視化して分析できます。入手先 Jiraの課題履歴と変更履歴のデータから作成し、ステータス移行や主要フィールドの更新を取得します。例インシデントの担当割り当て調査開始インシデント解決
	インシデントID IncidentId	Jira Service Managementの各インシデントチケットを一意に識別するIDです。
説明インシデントIDは、JiraでIssue Keyと呼ばれることもあり、報告された各インシデントを一意に識別する主要なIDです。作成から最終的なクローズまで、関連するすべてのアクティビティ、コメント、ステータス変更を結び付けます。プロセスマイニングでは、このIDを使って個々のインシデントのライフサイクルを最初から最後まで再構成できるため、プロセス全体を詳細に分析できます。重要な理由関連するすべてのイベントを1つのケースに関連付けるための中核となる識別子であり、プロセスマイニング分析の基盤です。入手先 Jira Service Managementの課題で使われる標準の「Key」フィールドです（例：「ITSM-123」）。例 INC-10234HELPDESK-5678OPS-9901
	開始時刻 EventTimestamp	アクティビティが発生した正確な日時です。
説明この属性には、インシデントのライフサイクルにおけるすべてのアクティビティのタイムスタンプを記録します。プロセス内の各手順間の所要時間、サイクルタイム、待ち時間を計算するうえで欠かせません。正確なタイムスタンプがあれば、パフォーマンスの詳細な分析、SLAの監視、ボトルネックの特定が可能になります。解決時間や診断時間など、すべてのパフォーマンス指標はこれらのタイムスタンプから算出されます。重要な理由タイムスタンプは、時間に基づくすべての指標を計算し、プロセスの所要時間を把握し、パフォーマンスのボトルネックを発見するうえで欠かせません。入手先これは、Jira課題の変更履歴または履歴に記録された各エントリに関連付けられた「created」日時です。例 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	ソースシステム SourceSystem	データを抽出したシステムです。
説明この属性はデータの取得元を示します。この場合はJira Service Managementです。複数のシステムのデータを統合してプロセス全体を把握する環境で、特に役立ちます。ソースシステムを指定すると、データの系譜が明確になり、データ品質や抽出に関する問題の診断にも役立ちます。このモデルでは、値は固定です。重要な理由データの取得元に関する重要な情報を提供し、特に複数システムを対象とした分析で、明確性と追跡可能性を確保します。入手先データ抽出時に追加する固定値です。例 Jira Service ManagementJira Cloud
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新された日時を示すタイムスタンプです。
説明この属性は、データセットが最後に更新された日時を記録します。プロセスを分析する際に、データがどの程度新しいかを把握するための重要な情報です。最新情報に基づく迅速な意思決定が求められる、継続的な監視用ダッシュボードでは特に重要です。通常、1回のデータ抽出バッチに含まれるすべてのイベントで同じ値になります。重要な理由データの適時性を把握できるため、分析の関連性と正確性の確保に役立ちます。入手先データ変換時に追加される、データ抽出処理の実行日時を示すタイムスタンプです。例 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	ステータス Status	インシデントのライフサイクルにおける現在の段階です。
説明ステータスフィールドは、定義されたワークフロー内でのインシデントの現在の状態を示します。「Open」、「In Progress」、「Pending Customer」、「Resolved」などが該当します。ステータスの変更は、プロセスマイニング用のアクティビティログを生成する主な情報源です。各ステータスに費やした時間を分析すると、ボトルネックを特定し、インシデントがどの段階に最も長く滞留しているかを把握できます。重要な理由インシデントの進捗を直接示し、プロセス手順と待ち時間を特定するための主な情報源です。入手先 Jira課題の標準「Status」フィールドです。例進行中顧客待ち解決済みクローズ済み
	作成日時 CreatedDate	インシデントがシステムで初めて作成された日時です。
説明この属性は、インシデントのライフサイクルの正式な開始時点を示します。総解決時間などの全体指標を算出する際の基準となるタイムスタンプです。作成日時は各インシデントに対する固定値であり、プロセスマイニング分析におけるケース全体の開始点になります。重要な理由エンドツーエンドのサイクルタイム計算とSLA測定の開始点になります。入手先 Jira課題の標準「Created」フィールドです。例 2023-10-26T09:58:12Z2023-11-01T15:20:05Z
	優先度 Priority	解決の緊急度を示す、インシデントに設定された優先度です。
説明優先度は、インシデントに対応する際に求められる速度を決定します。通常は影響度と緊急度を組み合わせて設定し、SLAの目標に直接影響します。優先度別にインシデントを分析すると、高優先度のインシデントが低優先度のインシデントより迅速に処理されているか、優先順位付けが一貫して行われているかを確認できます。プロセスパフォーマンスを絞り込み、比較するための重要な分析軸です。重要な理由 SLAパフォーマンスの分析や、最も重大なインシデントに適切にリソースが配分されているかの確認に欠かせません。入手先 Jira課題の標準「Priority」フィールドです。例最高高中低
	担当グループ AssignmentGroup	インシデントへの対応を担当するチームまたはグループです。
説明担当グループは、インシデントに割り当てられたチームを表します。「L1 Helpdesk」のようなサポート階層、「Network Operations」のような専門チーム、または開発チームなどが該当します。担当グループ間の遷移を分析すると、プロセスのエスカレーションや引き継ぎを把握できます。チームのパフォーマンスやチーム単位のボトルネック、チーム間の依存関係も分析できます。重要な理由チームのパフォーマンスや処理量、異なるサポート階層または専門グループ間の業務の流れを分析するうえで重要です。入手先通常は、Jiraの「Team」や「Assignment Group」などのカスタムフィールドとして実装します。Jiraのコンポーネントやプロジェクトロールから導出する場合もあります。例第1層サポートインフラストラクチャチームデータベース管理者
	担当者 Assignee	インシデントへの対応を現在担当しているユーザーです。
説明担当者は、特定の時点でインシデントを担当するエージェントまたはユーザーです。担当者の変更を追跡すると、引き継ぎの分析、業務量の分布の把握、特定のプロセス手順に関与した担当者の特定に役立ちます。この属性により、個人のパフォーマンスやサポートチーム内のリソース配分に関する問いにも答えられます。重要な理由担当者ごとの業務量を追跡し、特定のエージェントに関連するボトルネックを特定するとともに、引き継ぎが解決時間に与える影響を分析できます。入手先 Jira課題の標準「Assignee」フィールドです。例 John SmithEmily JonesServiceDeskAgent1
	解決日時 ResolutionDate	インシデントが解決済みとして記録された日時です。
説明この属性は、インシデントが初めて解決済みのステータスに移行した日時を記録します。アクティブな対応フェーズの終了時点を示し、解決時間の計算における終点になります。解決日時と作成日時を比較すると、プロセス効率を測る基本指標を算出できます。SLAの遵守状況を判定するうえでも重要です。重要な理由解決プロセスの終了時点を示し、総サイクルタイムとSLAパフォーマンスを算出できます。入手先 Jira課題の標準「Resolved」フィールドです。例 2023-10-28T11:20:30Z2023-11-02T10:00:00Z
	SLA違反 SlaBreach	インシデントの解決時間がSLA目標を超えたかどうかを示すフラグです。
説明この計算済みのブール属性は、インシデントが「Time to Resolution」SLAに違反したかどうかを示します。「IncidentResolutionCycleTime」が「TimeToResolutionTarget」より大きい場合にtrueになります。このフラグにより、分析と可視化が簡単になり、フィルタリングや集計によって全体のSLA違反率KPIを算出できます。SLAパフォーマンス監視ダッシュボードの主要な成果指標です。重要な理由 SLAパフォーマンスを明確な二値で示すため、違反率の算出や問題領域の特定を簡単に行えます。入手先（「IncidentResolutionCycleTime」＞「TimeToResolutionTarget」）として計算します。例 truefalse
	コンポーネント Component	インシデントの影響を受けたシステム、アプリケーション、またはインフラストラクチャの一部です。
説明コンポーネントは、Jiraプロジェクト内の課題を「User Interface」、「Database」、「API」などの小さな単位に分類するための区分です。コンポーネント別にインシデントを分析すると、システムのどの部分で問題が発生しやすいかを特定できます。この情報は根本原因分析に役立ち、サービス改善や技術的負債の削減に向けた取り組みの指針になります。重要な理由影響を受けた製品またはシステム領域に基づいてフィルタリングと分析を行い、問題が集中する技術領域を特定できます。入手先 Jira課題の標準「Components」フィールドです。例認証サービスレポート用ダッシュボードモバイルアプリ
	リンクされたProblem ID LinkedProblemId	このインシデントにリンクされたProblemチケットの識別子です。
説明より大きな根本問題の兆候であるインシデントは、Problemチケットにリンクされることがあります。このフィールドには、関連するProblemのIDを保存します。これらのリンクを分析すると、インシデントと問題の関係を把握し、問題管理プロセスの有効性を測定できます。また、恒久的な修正が必要な、繰り返し発生するインシデントも特定できます。重要な理由インシデントを根本的な問題に結び付け、将来のインシデントを防ぐために、組織が根本原因へどの程度効果的に対処しているかを分析できます。入手先この情報は、Jira課題の「Issue Links」セクションに保存されます。例 PROB-123PROB-456なし
	報告者 Reporter	インシデントを最初に作成または報告したユーザーです。
説明報告者は、インシデントを最初に記録した個人です。エンドユーザーや別のシステムである場合もあります。報告者別にインシデントを分析すると、問題を頻繁に経験しているユーザーや部門を特定できます。「Waiting for Customer」や「Customer Responded」などのアクティビティを分析する際には、コミュニケーションのパターンを把握するためにも利用できます。重要な理由インシデントの発生源を分析し、特定のユーザーや部門に関連するパターンを特定するとともに、顧客とのやり取りにおける遅延を把握できます。入手先 Jira課題の標準「Reporter」フィールドです。例 Alice JohnsonBob Williamsmonitoring-tool@example.com
	引き継ぎ回数 HandoffCount	インシデントが別のグループまたはユーザーに再割り当てされた回数です。
説明この計算指標は、インシデントのライフサイクル中に「Assignee」または「AssignmentGroup」フィールドが変更された回数を数えます。引き継ぎ回数が多い場合、プロセスの非効率、一次対応での解決不足、知識不足などが原因で、解決時間が長くなっている可能性があります。このKPIを分析すると、割り当てプロセスを効率化し、チーム間の連携を改善できます。重要な理由再割り当てによって生じるプロセス上の摩擦や非効率を数値化し、プロセス改善の機会を特定できます。入手先課題の変更履歴で「Assignee」または「AssignmentGroup」フィールドが変更された回数を数えて算出します。例 015
	手戻りあり IsRework	インシデントに手戻りが発生したかどうかを示すフラグです。再オープンなどが該当します。
説明この計算済みのブール属性は、インシデントがプロセスの前段階に戻されたケースを特定します。解決後に再オープンされたケースが最も一般的です。手戻りのループは、非効率や顧客の不満につながる大きな要因です。このフラグにより、手戻り率を簡単に算出し、初回に正しく解決できなかった理由に分析の焦点を当てられます。重要な理由繰り返し作業が必要なインシデントを示すことで、プロセス品質の問題と非効率を明らかにし、手戻り分析を直接支援します。入手先イベントログ内のステータス遷移の特定の順序（「Resolved」→「Reopened」など）を検出して算出します。例 truefalse
	根本原因カテゴリ RootCauseCategory	インシデントの根本原因を分類したものです。
説明この属性は、インシデントが発生した根本的な理由を記録します。「Software Defect」、「Hardware Failure」、「User Error」などが該当します。通常は調査後に入力され、問題管理や将来のインシデント防止に欠かせません。根本原因カテゴリを分析すると、組織的な弱点を特定し、改善施策の優先順位を決められます。「Unknown」が多い場合は、調査プロセスの改善が必要である可能性があります。重要な理由根本原因分析を可能にし、インシデントの発生源を特定して対処することで、事後対応型から予防型のアプローチへ移行できます。入手先 Jiraではほぼ必ずカスタムフィールドとして設定されます。フィールド名と選択肢は、組織固有の設定に大きく左右されます。例設定エラーネットワーク停止ソフトウェアバグ
	解決方法 Resolution	インシデントを解決した最終的な結果または理由です。
説明解決方法フィールドは、インシデントが解決済みの状態に移行した理由を示します。「Fixed」、「Duplicate」、「Won't Do」、「Cannot Reproduce」などが一般的です。解決方法の種類の分布を分析すると、受信した報告の品質や解決プロセスの有効性を把握できます。たとえば、「Duplicate」が多い場合、インシデントの作成またはトリアージの段階に問題がある可能性があります。重要な理由インシデントの結果に関する背景情報を提供し、解決方法を分類するとともに、インシデントがどのようにクローズされているかの傾向を特定できます。入手先 Jira課題の標準「Resolution」フィールドです。通常、課題が「Done」ステータスカテゴリに移行した際に設定されます。例完了修正済み重複修正しない
	解決時間目標 TimeToResolutionTarget	インシデントを解決するまでのSLA目標時間です。
説明この属性は、特定の優先度またはタイプのインシデントを解決すべき最大時間を定義します。実際の解決時間を測定し、SLAの遵守状況を判定する際の基準になります。通常は、優先度、重大度、課題タイプなどの条件に基づくルールによって動的に設定されます。SLAパフォーマンスを監視するダッシュボードに欠かせない値です。重要な理由 SLA遵守状況を測定する基準となり、インシデントSLA違反率KPIの基礎になります。入手先 Jira Service Management内のSLA設定から導出します。具体的な目標（例：「Time to resolution」）を特定する必要があります。例 4時間8時間3日
	課題タイプ IssueType	「Incident」、「Service Request」、「Problem」などの課題の種類です。
説明 Jiraでは、課題タイプによって異なる種類の作業を区別します。インシデント管理では主に「Incident」を使用しますが、「Sub-task」などが関係する場合もあります。この属性は、データセットをインシデントだけに絞り込むうえで重要です。分析対象を正しいプロセスに限定できます。重要な理由分析対象をインシデントに正しく限定し、サービスリクエストや変更など、他の作業種別と区別できます。入手先 Jira課題の標準「Issue Type」フィールドです。例インシデントITサポートバグ
	重大度 Severity	インシデントが事業に与える影響の大きさです。
説明重大度は、単一ユーザーへの影響から重大なシステム停止まで、インシデントが事業に与える影響の大きさを定義します。優先度が対応の順序を決めるのに対し、重大度は事業全体への影響を示します。重大度別に分析すると、事業への影響が大きいインシデントに対するプロセスパフォーマンスを把握できます。より詳細な分析のため、優先度と組み合わせて使うこともよくあります。重要な理由事業への影響を把握し、業務に最も大きな損害を与えるインシデントに焦点を当てて分析できます。入手先通常はJiraのカスタムフィールドです。標準のシステムフィールドではありません。Jira Service Managementのプロジェクト設定を確認してください。例重大大小軽微
	顧客リクエストタイプ CustomerRequestType	顧客がサービスポータルから送信したリクエストの具体的な種類です。
説明このフィールドは、Jira Service Managementポータルに表示される顧客視点のリクエスト分類です。たとえば「Report a system issue」などがあります。顧客にとって分かりやすいインシデント分類を提供しますが、社内の「Issue Type」とは異なる場合があります。この属性を分析すると、顧客が問題をどのように認識し、報告しているかを把握でき、ポータルの設計やサービス内容の改善に役立ちます。重要な理由顧客を中心としたインシデント分類の視点を提供し、需要の分析や顧客体験の改善に役立ちます。入手先 Jira Service Managementプロジェクト固有の「Customer Request Type」フィールドです。例 ITサポートを受ける＞システムの問題を報告メール＞アクセス申請

必須推奨任意

インシデント管理のアクティビティ

インシデント解決ワークフローを正確に発見・分析するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

7 推奨 8 任意

	アクティビティ	説明
	インシデントのクローズ	解決と検証が完了した後、インシデントチケットを最終的に事務処理上クローズしたことを示します。「Closed」へのステータス移行から推定します。
重要な理由これはプロセスの終端イベントです。「Resolved」から「Closed」までの時間を分析すると、事務処理上の後片付けやユーザー確認の遅れを明らかにできます。入手先課題のステータス変更履歴から推定します。最終的な「Closed」状態へステータスが移行した時点が、このイベントに該当します。取得ステータスが「Closed」に移行した時点のタイムスタンプを特定します。イベントタイプ inferred
	インシデントの再割り当て	初回の担当割り当て後に、インシデントが別の担当者またはグループへ移管されたときに発生します。「Assignee」または「Assigned Group」フィールドの変更から推定します。
重要な理由再割り当てを追跡することは、引き継ぎを分析するうえで欠かせません。再割り当てが多い場合、プロセスの非効率、知識不足、初期ルーティングの誤りなどが考えられ、解決の遅延につながります。入手先初回の入力後に「Assignee」フィールドが更新された箇所を課題履歴から検出して推定します。変更のたびに、再割り当てイベントとして記録します。取得初回の担当割り当て後に「Assignee」フィールドが変更された箇所を特定します。イベントタイプ inferred
	インシデント作成	インシデント報告が送信され、Jiraで新しい課題が作成された時点で、インシデントのライフサイクルが正式に始まったことを示します。システムで「Incident」タイプの新しい課題が記録された時点で、このイベントが明示的に取得されます。
重要な理由これはプロセスの主要な開始イベントです。このアクティビティから解決までの時間を分析することは、全体のサイクルタイムとSLA遵守状況を測定するうえで基本となります。入手先これは、Jiraのインシデント課題に記録された「created」タイムスタンプから明示的に取得されるイベントです。課題の作成イベントは、課題の履歴に記録されます。取得課題の作成日時を使用します。イベントタイプ explicit
	インシデント解決	インシデントが正常に解決され、サービスが復旧したことを確認するアクティビティです。「Resolved」への移行と同時に発生することがよくあります。
重要な理由これはプロセスにおける主要な成功の節目です。この時点までの所要時間は最も一般的なKPIであり、解決時間（TTR）を示します。入手先「Resolved」へのステータス変更から推定します。多くのワークフローでは、「Resolution Proposed」と同じイベントであり、主な解決時点を示します。取得ステータスが「Resolved」に移行した時点のタイムスタンプを特定します。イベントタイプ inferred
	解決策の提案	解決策が特定され、実施されたことを示します。インシデントは確認または最終検証を待っている状態です。「Resolved」へのステータス移行から推定します。
重要な理由これは、サポートチームによる実作業の終了を示す大きな節目です。SLAの計測が停止するイベントになることもよくあります。入手先課題のステータス変更履歴から推定します。「Resolved」または同等の状態にステータスが移行した時点が、イベントのタイムスタンプです。取得ステータスが「Resolved」に移行した時点のタイムスタンプを特定します。イベントタイプ inferred
	調査開始	割り当てられた担当者が、インシデントの診断に向けて実際の作業を開始したことを示します。通常は、インシデント課題のステータスが「Open」または「New」から「In Progress」に移行した時点から推定します。
重要な理由この重要な節目は、解決に向けた実作業の開始を示します。このアクティビティまでの時間を測定すると、初期の待ち時間やリソース不足の問題を特定できます。入手先課題のステータス変更履歴から推定します。イベントのタイムスタンプは、「In Progress」など、作業中を示す状態にステータスが移行した時点です。取得ステータスが「In Progress」に移行した時点のタイムスタンプを特定します。イベントタイプ inferred
	顧客の回答待ち	サポートチームが顧客からの情報や対応を待っている状態を示します。通常は、「Waiting for customer」など、専用の待機ステータスへの移行から推定します。
重要な理由この保留時間を分離することは、正確なSLA測定に欠かせません。保留時間は、解決時間の計算から除外されることが多いためです。顧客からの回答の遅れを分析するのにも役立ちます。入手先課題のステータス変更履歴から推定します。「Waiting for customer」または同様の状態にステータスが変更された時点が、このイベントに該当します。取得ステータスが「Waiting for customer」に移行した時点のタイムスタンプを特定します。イベントタイプ inferred
	Problemチケットへのリンク	根本原因分析のため、インシデントが「Problem」課題にリンクされたときに発生します。「relates to」または「caused by」リンクが「Problem」タイプの課題に作成された時点で、明示的に取得されるイベントです。
重要な理由このリンクを追跡することは、組織がインシデントの緩和から根本原因分析と再発防止へ、どの程度効果的に移行できているかを把握するうえで欠かせません。入手先これは課題のリンク履歴に記録される明示的なイベントです。リンクが作成されるたびにタイムスタンプが記録され、「Problem」タイプの課題へのリンクに絞り込めます。取得「Problem」タイプの課題への課題リンクが作成された時点のタイムスタンプを使用します。イベントタイプ explicit
	インシデントの優先順位付け	インシデントの優先度や重大度が設定されたことを示します。これらは緊急度と業務への影響を決定します。通常は、作成後に「Priority」または「Severity」フィールドが初めて入力または更新された時点から推定します。
重要な理由優先順位付けを追跡すると、インシデントが迅速かつ一貫して評価されているかを分析できます。この手順の遅れは、SLAの計算やリソース配分に直接影響する可能性があります。入手先すべてのフィールドの変更を追跡する課題履歴ログから推定します。課題作成イベント後に、「Priority」またはカスタムの「Severity」フィールドが初めて更新された箇所を確認します。取得課題履歴で「Priority」フィールドが初めて変更された箇所を検出します。イベントタイプ inferred
	インシデントの再オープン	解決済みのインシデントが、問題の再発や修正の不備によって再び有効化された状態を示します。「Resolved」または「Closed」からオープン状態へステータスが変更されたことから推定します。
重要な理由再オープンされたインシデントは、解決品質を直接示す指標であり、やり直しの主要な兆候です。これらのイベントを分析すると、早すぎるクローズや効果のない解決策を特定できます。入手先課題のステータス変更履歴から推定します。「Resolved」や「Closed」などの終端状態から「Open」または「In Progress」へ戻った時点で記録されます。取得「Resolved」または「Closed」からオープン状態へのステータス変更を検出します。イベントタイプ inferred
	インシデントの担当割り当て	このアクティビティは、インシデントが対応担当者または担当グループに初めて割り当てられたことを示します。「Assignee」または「Assigned Group」フィールドが初めて入力された時点を追跡して取得します。
重要な理由初期対応と担当割り当てにかかった時間を測定します。これはSLA指標の重要な要素です。調査が始まる前の遅延を特定するのにも役立ちます。入手先課題履歴から、以前の値が「Unassigned」である「Assignee」フィールドの最初の変更を特定して推定します。取得課題履歴で「Assignee」フィールドが初めて更新された箇所を検出します。イベントタイプ inferred
	コメント追加	ユーザーがインシデントチケットにコメントを追加する、あらゆる連絡またはメモの記録を示します。コメントが投稿されるたびに明示的に取得されるイベントです。
重要な理由コメントの頻度を分析すると、コミュニケーションのパターン、連携の効率、インシデントの複雑さを把握できます。過剰なコミュニケーションが必要なインシデントも明らかになります。入手先これは明示的なイベントです。Jiraでは、すべてのコメントがタイムスタンプと作成者とともに保存され、課題のコメント履歴またはAPIから取得できます。取得課題に追加された各コメントのタイムスタンプを使用します。イベントタイプ explicit
	回避策の提供	恒久的な解決策を開発している間にサービスを復旧するため、一時的な修正を実施したことを示します。ステータスの変更または特定のコメントから推定できます。
重要な理由回避策の提供までにかかった時間は、サービス復旧の速さを示す重要な指標です。一時的な緩和策と恒久的な解決を区別するのにも役立ちます。入手先多くの場合、これは推定イベントです。「Workaround Provided」へのステータス移行や、「workaround」などの特定のキーワードを含む公開コメントの追加から判断できます。取得特定のステータス移行またはコメント内のキーワードを特定します。イベントタイプ inferred
	専門チームへエスカレーション	インシデントが高度なサポートを行う専門チーム（例：Tier 2、開発チーム）へエスカレーションされたことを示します。カスタムの「Support Team」フィールドの変更、または特定の再割り当てから推定します。
重要な理由専門知識を必要とするインシデントを明らかにし、異なるサポートレベル間の流れを追跡できます。専門チーム内のボトルネックを特定し、エスカレーションのパターンを分析するのにも役立ちます。入手先担当チームを示すカスタムフィールドの変更を追跡するか、「Assignee」が既知の専門グループのメンバーに変更されたことを特定して、課題履歴から推定します。取得「Assigned Team」のカスタムフィールドの変更、または特定の担当者変更を検出します。イベントタイプ inferred
	顧客からの回答	顧客が求められていた情報を提供し、インシデント対応を再開できる状態になったことを示します。「Waiting for customer」からアクティブなステータスへ戻った時点から推定します。
重要な理由このアクティビティは、顧客に起因する遅延の終了を示します。「Waiting For Customer」からこのイベントまでの時間を分析すると、顧客の平均回答時間を把握できます。入手先課題のステータス変更履歴から推定します。「Waiting for customer」から「In Progress」などのステータスへ移行した時点に発生します。顧客がコメントを追加したことをきっかけに発生する場合もあります。取得「Waiting for customer」から「In Progress」へのステータス変更を検出します。イベントタイプ inferred

推奨任意

抽出ガイド

Jira Service Managementからデータを取得する方法

ステップ

前提条件の確認：この方法では、Better Excel ExporterやExporter for JiraなどのJira Marketplaceアプリが必要です。標準のCSVエクスポートには、プロセスのタイムライン再構築に必要な詳細な課題履歴（changelog）が含まれないためです。該当するアプリがインストールされ、利用権限があることを確認してください。
Advanced issue searchへ移動：Jira Service Managementのインスタンスにログインします。上部ナビゲーションバーで「Filters」を選択し、「Advanced issue search」を開きます。JQLクエリエディターを備えたIssue Navigatorが表示されます。
JQLクエリを実行：JQLクエリバーに、指定した期間内のすべてのインシデントチケットを選択するクエリを入力します。これが生のデータをエクスポートする際の基礎になります。一般的なクエリは、issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d"です。
エクスポート列を設定：エクスポート機能を探します。「Export」と表示されている場合や、アプリ固有のメニューに含まれている場合があります。CSVファイルを作成するよう設定してください。Issue Key、Created、Resolved、Status、Priority、Assignee、そして特に完全なChangelogまたはHistoryを含めることが重要です。エクスポートアプリでは、changelogの各項目を別々の行として出力できる場合があります。これは変換に適した形式です。
生のデータをエクスポート：エクスポートを実行し、生成されたCSVファイルをダウンロードします。このファイルには変換前の生のデータが含まれ、課題ごとではなく、課題の変更ごとに1行となる場合があります。
変換環境を準備：生のエクスポートデータを有効なイベントログに変換するには、提供されたPythonスクリプトが必要です。システムにPythonとpandasライブラリがインストールされていることを確認してください。ターミナルでpip install pandasを実行すると、pandasをインストールできます。
変換スクリプトを実行する準備：提供されたPythonスクリプトをファイル（例：transform_jira_log.py）として保存します。エクスポートしたCSVファイルを同じディレクトリに置きます。スクリプトを変更し、正しい入力ファイル名と出力ファイル名を指定してください。
スクリプトを実行：ターミナルでpython transform_jira_log.pyを実行します。スクリプトが生のデータを処理し、jira_incident_event_log.csvという新しいCSVファイルを生成します。このファイルはプロセスマイニングに適した形式になっています。
確認してアップロード：最終的なjira_incident_event_log.csvを開き、内容を確認します。問題がなければ、このイベントログをプロセスマイニングツールにアップロードできます。

設定

JQLクエリ：JQL（Jira Query Language）クエリは、データを選択するための主要なフィルターです。主なフィルターは次のとおりです。
- issuetype = Incident：インシデントチケットだけを抽出します。
- project = "[Your JSM Project Key]"：特定のサービスデスクプロジェクトにデータを限定します。プレースホルダーをプロジェクトのキー（例：「ITSUP」）に置き換えてください。
- created >= "-180d"：抽出期間を指定します。データ量と得られる情報のバランスを取るため、3～6か月（「-90d」～「-180d」）を推奨します。
エクスポートアプリの設定：Marketplaceのエクスポートアプリで、changelogを出力するよう設定する必要があります。理想的な出力形式は変更ごとに1行で、Issue Key、変更されたフィールド、変更前の値、変更後の値、変更日時を列に含めます。
エクスポートに必要なフィールド：少なくともIssue Key、Created、Resolved、Creator、Priority、Status、Assignee、[Assignment Group Custom Field]、[Support Team Custom Field]、完全なChangelog履歴（timestamp、author、field、from string、to string）を含めてください。
前提条件：この方法には、Jira Service Managementのライセンス、Issue NavigatorへのアクセスとJQLクエリ実行に必要なユーザー権限、詳細な課題changelogをエクスポートできるJira Marketplaceアプリが必要です。

a サンプルクエリ sql

import pandas as pd
import numpy as np
from datetime import datetime

# --- Configuration ---
# Specify the path to your raw CSV file exported from Jira
# This file should have one row per changelog item.
INPUT_CSV_PATH = '[Your-Jira-Export-File].csv'
# Specify the desired name for the final event log file
OUTPUT_CSV_PATH = 'jira_incident_event_log.csv'

# --- Main Transformation Logic ---
def transform_jira_to_event_log(input_path, output_path):
    """Transforms a detailed Jira changelog export into a process mining event log."""
    try:
        # Load the raw data, assuming common column names from Jira exporters.
        # Adjust column names here to match your specific export file.
        # 'Issue Key' -> Incident ID
        # 'Date' -> Timestamp of the change
        # 'Field' -> The field that was changed (e.g., 'status', 'assignee')
        # 'Original value' -> Old value
        # 'New value' -> New value
        # You must also include columns for 'Created', 'Resolved', 'Priority', etc., at the issue level.
        df_raw = pd.read_csv(input_path)
    except FileNotFoundError:
        print(f"Error: Input file not found at '{input_path}'. Please check the path.")
        return

    # Standardize column names for easier processing
    # Replace these with the actual column names from your export
    column_map = {
        'Issue key': 'IncidentId',
        'History Date': 'EventTimestamp',
        'History Author': 'Author',
        'Field': 'ChangedField',
        'From String': 'OldValue',
        'To String': 'NewValue',
        'Created': 'CreatedDate',
        'Resolved': 'ResolutionDate',
        'Priority': 'Priority',
        'Status': 'Status',
        'Assignee': 'Assignee',
        # Add mappings for your custom fields if necessary
        # '[Your Assignment Group Field]': 'AssignmentGroup'
    }
    df_raw.rename(columns=column_map, inplace=True)

    # Ensure timestamp columns are in datetime format
    df_raw['EventTimestamp'] = pd.to_datetime(df_raw['EventTimestamp'], errors='coerce')
    df_raw['CreatedDate'] = pd.to_datetime(df_raw['CreatedDate'], errors='coerce')
    df_raw['ResolutionDate'] = pd.to_datetime(df_raw['ResolutionDate'], errors='coerce')

    events = []
    # Group by incident to process each ticket's lifecycle
    for incident_id, group in df_raw.groupby('IncidentId'):
        # Sort changes chronologically
        group = group.sort_values(by='EventTimestamp').reset_index()

        # Get issue-level attributes from the first record
        first_record = group.iloc[0]
        created_date = first_record['CreatedDate']
        resolved_date = first_record['ResolutionDate']

        # 1. Incident Created Event
        events.append({
            'IncidentId': incident_id,
            'ActivityName': 'Incident Created',
            'EventTimestamp': created_date,
            'Assignee': first_record.get('Assignee'),
            'AssignmentGroup': first_record.get('AssignmentGroup'),
            'Status': first_record.get('Status'),
            'Priority': first_record.get('Priority')
        })

        assignee_set = False
        priority_set = False

        # 2. Process Changelog for other events
        for _, row in group.iterrows():
            activity = None
            field = row['ChangedField']
            old_val = str(row['OldValue'])
            new_val = str(row['NewValue'])
            timestamp = row['EventTimestamp']

            # Map changelog entries to activities
            if field == 'status':
                if new_val == 'In Progress' and old_val not in ['Waiting for customer', 'In Progress']:
                    activity = 'Investigation Started'
                elif new_val == 'Waiting for customer':
                    activity = 'Waiting For Customer'
                elif old_val == 'Waiting for customer' and new_val not in ['Resolved', 'Closed']:
                    activity = 'Customer Responded'
                elif new_val == 'Resolved':
                    activity = 'Resolution Proposed'
                    # Also add Incident Resolved at the same time
                    events.append({'IncidentId': incident_id, 'ActivityName': 'Incident Resolved', 'EventTimestamp': timestamp, 'Assignee': row.get('Assignee'), 'AssignmentGroup': row.get('AssignmentGroup'), 'Status': new_val, 'Priority': row.get('Priority')})
                elif new_val == 'Closed':
                    activity = 'Incident Closed'
                elif old_val in ['Resolved', 'Closed'] and new_val not in ['Resolved', 'Closed']:
                    activity = 'Incident Reopened'

            elif field == 'assignee':
                if not assignee_set and new_val != 'nan':
                    activity = 'Incident Assigned'
                    assignee_set = True
                elif assignee_set and new_val != old_val:
                    activity = 'Incident Reassigned'

            elif field == 'priority' and not priority_set:
                activity = 'Incident Prioritized'
                priority_set = True

            elif field == '[Support Team Custom Field]': # Placeholder for your escalation field
                activity = 'Escalated To Specialist Team'
            
            elif field == 'Link' and 'Problem' in new_val:
                 activity = 'Linked To Problem Ticket'

            # Other activities like 'Workaround Provided' and 'Comment Added' are not typically in the changelog
            # and would require different extraction methods (e.g., API calls for comments).

            if activity:
                events.append({
                    'IncidentId': incident_id,
                    'ActivityName': activity,
                    'EventTimestamp': timestamp,
                    'Assignee': row.get('Assignee'),
                    'AssignmentGroup': row.get('AssignmentGroup'),
                    'Status': new_val if field == 'status' else row.get('Status'),
                    'Priority': new_val if field == 'priority' else row.get('Priority')
                })

    # Create final event log DataFrame
    if not events:
        print("Warning: No events were generated. Check your input file and column mappings.")
        return
        
    df_events = pd.DataFrame(events)

    # Add required and recommended attributes
    df_events['SourceSystem'] = 'Jira Service Management'
    df_events['LastDataUpdate'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    
    # Merge issue-level details back to get created/resolved dates for all rows
    issue_details = df_raw[['IncidentId', 'CreatedDate', 'ResolutionDate']].drop_duplicates(subset='IncidentId')
    df_final = pd.merge(df_events, issue_details, on='IncidentId', how='left')

    # Calculate cycle time
    df_final['IncidentResolutionCycleTime'] = (df_final['ResolutionDate'] - df_final['CreatedDate']).dt.total_seconds() / 3600.0
    
    # Sort and write to CSV
    df_final = df_final.sort_values(by=['IncidentId', 'EventTimestamp'])
    df_final.to_csv(output_path, index=False)
    print(f"Successfully created event log at '{output_path}' with {len(df_final)} events.")

# --- Script Execution ---
if __name__ == '__main__':
    transform_jira_to_event_log(INPUT_CSV_PATH, OUTPUT_CSV_PATH)

ステップ

前提条件とアクセス権：オンプレミスのJira Service Managementデータベースへの読み取り専用アクセス権を取得します。データベースサーバーのアドレス、ポート、データベース名、ユーザー名、パスワードが必要です。DBeaver、SQL DeveloperなどのSQLクライアントをインストールしてください。
Jiraスキーマを理解：主要なJiraデータベーステーブルを確認します。この抽出で主に使用するテーブルは、コアとなるインシデントデータのjiraissue、課題履歴のchangegroupとchangeitem、コメントのjiraaction、他の課題へのリンクのissuelink、プロジェクトで絞り込むproject、「Incident」タイプの課題で絞り込むissuetypeです。
カスタムフィールドIDを特定：Assignment Groupなどの重要な属性は、Jiraのカスタムフィールドであることが多いです。customfieldテーブルをクエリして一意のIDを特定します（例：SELECT id, cfname FROM customfield WHERE cfname LIKE '%Assignment Group%';）。このIDをメインクエリで使用するために控えてください。
データベースに接続：SQLクライアントを開き、手順1の認証情報を使ってJiraデータベースに接続します。
SQLクエリをカスタマイズ：以下に示す完全なSQLクエリをコピーします。ご利用のJira設定に合わせてプレースホルダーを置き換えてください。[your_project_key]、[start_date]、[end_date]、[custom_field_id_for_assignment_group]などのカスタムフィールドIDを確認してください。
クエリを実行：SQLクライアントでカスタマイズしたクエリを実行します。Jiraインスタンスの規模と選択した期間によっては、完了まで数分かかる場合があります。
結果を確認：クエリが完了したら、出力を簡単に確認します。IncidentId、ActivityName、EventTimestampの各列に想定どおり値が入っていることを確認してください。ActivityName列にさまざまなアクティビティが表示されることも確認します。
CSVにエクスポート：SQLクライアントから結果セット全体をCSVファイルにエクスポートします。文字化けを防ぐため、UTF-8エンコーディングを選択してください。
ProcessMind用に整形：CSVファイルに、クエリで指定した正確な列名（IncidentId、ActivityNameなど）のヘッダー行があることを確認します。EventTimestamp列が、YYYY-MM-DD HH:MI:SSなど、ProcessMindに対応した形式になっていることを確認してください。
ProcessMindにアップロード：CSVファイルをProcessMindにアップロードし、新しいプロセス分析を作成できる状態になりました。

設定

データベース認証情報：Jiraデータを誤って変更しないよう、読み取り専用のデータベースユーザーとパスワードが必要です。
プロジェクトと課題タイプのフィルタリング：このクエリでは、p.pkey IN ('[your_project_key]')句によって、1つ以上の特定のJira Service Managementプロジェクトに絞り込めます。また、it.pname = 'Incident'によって「Incident」課題タイプにも絞り込みます。これはパフォーマンスと関連性を確保するうえで重要です。
期間：クエリを効率的に実行できるよう、まずは3～6か月程度の限られた期間から始めることを強く推奨します。[start_date]と[end_date]のプレースホルダーを適切に設定してください。
カスタムフィールド：Assignment GroupやSeverityなどの属性は、カスタムフィールドの場合があります。クエリ内のプレースホルダー（例：[custom_field_id_for_assignment_group]）を、Jiraインスタンスのcustomfieldテーブルにある正しい数値IDへ置き換えてください。
Jiraのバージョン：データベーススキーマは、Jiraのメジャーバージョンによって多少異なる場合があります。このクエリは一般的なスキーマ構成を前提としていますが、非常に古い、または新しいJira ServerやData Centerでは軽微な調整が必要になる場合があります。
パフォーマンス：大規模で稼働中のJiraインスタンスに対してこのクエリを実行すると、データベースリソースを大きく消費する可能性があります。Jiraユーザーへの影響を抑えるため、利用の少ない時間帯に実行することを強く推奨します。

a サンプルクエリ sql

WITH Incidents AS (
  SELECT
    i.id AS issue_id,
    p.pkey || '-' || i.issuenum AS IncidentId,
    i.assignee AS assignee_key,
    i.issuestatus AS status_id,
    i.priority AS priority_id,
    i.created AS CreatedDate,
    i.resolutiondate AS ResolutionDate,
    EXTRACT(EPOCH FROM (i.resolutiondate - i.created)) AS IncidentResolutionCycleTime
  FROM jiraissue i
  JOIN project p ON i.project = p.id
  JOIN issuetype it ON i.issuetype = it.id
  WHERE it.pname = 'Incident'
    AND p.pkey IN ('[your_project_key]') -- E.g., 'ITSM', 'HELPDESK'
    AND i.created BETWEEN '[start_date]' AND '[end_date]' -- E.g., '2023-01-01' AND '2023-06-30'
)
-- 1. Incident Created
SELECT
  i.IncidentId,
  'Incident Created' AS ActivityName,
  i.CreatedDate AS EventTimestamp,
  'Jira Service Management' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  au.display_name AS Assignee,
  cfo.customvalue AS AssignmentGroup,
  s.pname AS Status,
  pr.pname AS Priority,
  i.CreatedDate,
  i.ResolutionDate,
  i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN app_user au ON i.assignee_key = au.user_key
LEFT JOIN issuestatus s ON i.status_id = s.id
LEFT JOIN priority pr ON i.priority_id = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group] -- Placeholder for Assignment Group custom field ID
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id

UNION ALL

-- 2. Incident Prioritized (First Time)
SELECT
  i.IncidentId, 'Incident Prioritized' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, T.Priority, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, au_cg.display_name AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status, ci.newstring AS Priority,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN app_user au_cg ON cg.author = au_cg.user_key
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.field = 'Priority'
) T ON i.issue_id = T.issueid AND T.rn = 1

UNION ALL

-- 3. Incident Assigned (First Time)
SELECT
  i.IncidentId, 'Incident Assigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn = 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 4. Investigation Started
SELECT
  i.IncidentId, 'Investigation Started' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Open', 'New') AND ci.newstring = 'In Progress'

UNION ALL

-- 5. Comment Added
SELECT
  i.IncidentId, 'Comment Added' AS ActivityName, ja.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM jiraaction ja
JOIN Incidents i ON ja.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ja.actiontype = 'comment'

UNION ALL

-- 6. Incident Reassigned
SELECT
  i.IncidentId, 'Incident Reassigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn > 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 7. Escalated To Specialist Team
SELECT
  i.IncidentId, 'Escalated To Specialist Team' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, ci.newstring, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
JOIN customfield cf ON cf.cfname = '[Support Team Custom Field Name]' -- Placeholder for custom field name, e.g., 'Support Team'
JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
WHERE ci.field = cf.id

UNION ALL

-- 8. Waiting For Customer
SELECT
  i.IncidentId, 'Waiting For Customer' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Waiting for Customer'

UNION ALL

-- 9. Customer Responded
SELECT
  i.IncidentId, 'Customer Responded' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring = 'Waiting for Customer'

UNION ALL

-- 10. Workaround Provided
SELECT
  i.IncidentId, 'Workaround Provided' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Workaround Provided' -- Assumes this status exists

UNION ALL

-- 11. Resolution Proposed & 14. Incident Resolved
SELECT
  i.IncidentId, 'Resolution Proposed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Resolved'

UNION ALL

-- Also capture Incident Resolved from the resolutiondate field for cases where history might be missed.
SELECT
  i.IncidentId, 'Incident Resolved' AS ActivityName, i.ResolutionDate AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE i.ResolutionDate IS NOT NULL

UNION ALL

-- 12. Linked To Problem Ticket
SELECT
  i.IncidentId, 'Linked To Problem Ticket' AS ActivityName, il.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM issuelink il
JOIN Incidents i ON il.source = i.issue_id
JOIN jiraissue linked_issue ON il.destination = linked_issue.id
JOIN issuetype linked_issuetype ON linked_issue.issuetype = linked_issuetype.id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE linked_issuetype.pname = 'Problem'

UNION ALL

-- 13. Incident Reopened
SELECT
  i.IncidentId, 'Incident Reopened' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Resolved', 'Closed') AND ci.newstring NOT IN ('Resolved', 'Closed')

UNION ALL

-- 15. Incident Closed
SELECT
  i.IncidentId, 'Incident Closed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Closed'

ステップ

Python環境を設定：システムにPython 3.6以降がインストールされていることを確認します。pipで必要なライブラリをインストールします：pip install requests pandas python-dateutil。
Jira APIトークンを生成：Jiraアカウントにログインします。プロフィール設定で「Security」を選択し、「Create and manage API tokens」を開きます。新しいトークンを作成し、安全にコピーしてください。認証にはパスワードではなく、このトークンを使用します。
カスタムフィールドIDを特定：Assignment GroupやSeverityなど、多くのJira属性はカスタムフィールドです。内部IDを確認する必要があります。Jira Settings > Issues > Custom fieldsに移動し、対象のフィールドを探して「...」メニューから「View」を選択します。IDはURLに表示されます（例：customFieldId=10021）。これらを控えてください。
Pythonスクリプトを設定：提供されたPythonスクリプトをテキストエディターで開きます。## CONFIGURATION ##セクションのプレースホルダー変数を、JiraサイトのURL、メールアドレス、生成したAPIトークン、特定したカスタムフィールドIDに更新します。
JQLクエリを定義：スクリプトのJQL_QUERY変数を変更します。このJira Query Language（JQL）クエリで、抽出するインシデントの範囲を定義します。まずは特定のプロジェクトと限られた期間でテストしてください。例：project = 'ITSM' AND issuetype = 'Incident' AND created >= '-90d'。
抽出スクリプトを実行：コマンドラインでpython your_script_name.pyを実行します。スクリプトがJira APIに接続し、インシデントデータを取得して各チケットの履歴を処理し、イベントを生成します。
スクリプトの進行状況を確認：スクリプトは処理済みの課題数をコンソールに表示します。大規模なデータセットでは、APIのレート制限とデータ量により、完了までかなり時間がかかる場合があります。
出力ファイルを確認：スクリプトが完了すると、同じディレクトリにjira_incident_event_log.csvが生成されます。このファイルには抽出したイベントログが含まれます。
データを変換して整形：CSVファイルを表計算ソフトで開いて確認します。スクリプトはIncidentResolutionCycleTimeを自動計算します。EventTimestampの日付形式が一定で、ProcessMindの要件（例：YYYY-MM-DDTHH:MI:SSZ）に適合していることを確認してください。
ProcessMindにアップロード：生成されたCSVファイルをProcessMindにアップロードできます。CSVの列をProcessMindの対応する属性にマッピングします（IncidentIdはCase ID、ActivityNameはActivity、EventTimestampはTimestamp）。

設定

Jira URL：JiraインスタンスのベースURLです（例：https://your-company.atlassian.net）。
Jiraの認証情報：認証にはメールアドレスとJira APIトークンが必要です。スクリプトでパスワードを直接使用しないでください。
JQLクエリ：JQLクエリはデータ範囲を定義する最も重要な設定です。issuetype = 'Incident'と特定のプロジェクトで絞り込むことを強く推奨します。データ量を管理するため、createdフィールドに期間フィルター（例：created >= '-180d'）を設定してください。初回分析では3～6か月程度が一般的です。
カスタムフィールドID：スクリプトでは、ASSIGNMENT_GROUP_FIELD_IDなど、ご利用のJiraインスタンスで使用するカスタムフィールドの固有IDが必要です。対応する属性に値を設定するには、正しく構成してください。
ステータス名：スクリプトはステータス遷移に基づいてアクティビティを推定します。スクリプト内のステータス名（例：「In Progress」、「Waiting for customer」、「Resolved」）を、プロジェクトのワークフローで使用している正確な名称に更新してください。
ページネーション設定：API呼び出しのmaxResultsパラメーターで、1回のリクエストで取得する課題数を指定します。スクリプトはページネーションを自動処理しますが、レート制限が発生する場合は、値を小さくするとAPIへの負荷を抑えられます。

a サンプルクエリ python

import requests
import pandas as pd
import os
from datetime import datetime, timezone
from dateutil.parser import parse

class=class="hl-string">"hl-comment">## CONFIGURATION ##
class=class="hl-string">"hl-comment"># Your Jira instance URL
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
class=class="hl-string">"hl-comment"># Your email address used for Jira login
JIRA_EMAIL = class="hl-string">"[your-email@company.com]"
class=class="hl-string">"hl-comment"># Your Jira API token. Store this securely, for example as an environment variable.
API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"[Your_Jira_API_Token]")

class=class="hl-string">"hl-comment"># JQL query to fetch incidents. It is recommended to limit the date range.
JQL_QUERY = class="hl-string">"issuetype = Incident AND project = '[YOUR_PROJECT_KEY]' AND created >= '-180d'"

class=class="hl-string">"hl-comment"># Custom field IDs for recommended attributes. Find these in your Jira settings.
class=class="hl-string">"hl-comment"># Example: class="hl-string">'customfield_10021'
ASSIGNMENT_GROUP_FIELD_ID = class="hl-string">"[customfield_id_for_assignment_group]"

class=class="hl-string">"hl-comment"># Status names as defined in your Jira workflow
STATUS_IN_PROGRESS = class="hl-string">'In Progress'
STATUS_WAITING_FOR_CUSTOMER = class="hl-string">'Waiting for customer'
STATUS_RESOLVED = class="hl-string">'Resolved'
STATUS_CLOSED = class="hl-string">'Closed'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

def get_field_value_from_changelog(item):
    class=class="hl-string">"hl-comment"># Helper to get the actual value, which can be in different keys
    return item.get(class="hl-string">'toString') or item.get(class="hl-string">'to') or class="hl-string">''

def get_field_from_changelog(item):
    return item.get(class="hl-string">'fromString') or item.get(class="hl-string">'from') or class="hl-string">''

def calculate_cycle_time(start_str, end_str):
    if not start_str or not end_str:
        return None
    try:
        start_dt = parse(start_str)
        end_dt = parse(end_str)
        duration_seconds = (end_dt - start_dt).total_seconds()
        return round(duration_seconds / 3600, 2) class=class="hl-string">"hl-comment"># Return cycle time in hours
    except (ValueError, TypeError):
        return None

def fetch_jira_issues(jql):
    class="hl-string">"""Fetches issues from Jira API, handling pagination."""
    auth = (JIRA_EMAIL, API_TOKEN)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    issues = []
    start_at = 0
    max_results = 50

    while True:
        api_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_url, headers=headers, params=params, auth=auth)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            issues.extend(data.get(class="hl-string">'issues', []))

            total = data.get(class="hl-string">'total', 0)
            start_at += len(data.get(class="hl-string">'issues', []))
            print(fclass="hl-string">"Fetched {start_at} of {total} issues...")

            if start_at >= total:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Jira: {e}")
            if e.response is not None:
                print(fclass="hl-string">"Response content: {e.response.text}")
            break

    return issues

def create_event_log(issues):
    class="hl-string">"""Processes issues and their changelogs to create a structured event log."""
    event_log = []
    last_data_update = datetime.now(timezone.utc).isoformat()

    for issue in issues:
        incident_id = issue[class="hl-string">'key']
        fields = issue[class="hl-string">'fields']
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        created_date = fields.get(class="hl-string">'created')
        resolution_date = fields.get(class="hl-string">'resolutiondate')
        cycle_time = calculate_cycle_time(created_date, resolution_date)

        class=class="hl-string">"hl-comment"># Track current state for attributes
        current_assignee = fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None
        current_status = fields.get(class="hl-string">'status', {}).get(class="hl-string">'name')
        current_priority = fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name') if fields.get(class="hl-string">'priority') else None
        current_assignment_group = fields.get(ASSIGNMENT_GROUP_FIELD_ID)

        class=class="hl-string">"hl-comment"># Base attributes for every event of this case
        base_event = {
            class="hl-string">'IncidentId': incident_id,
            class="hl-string">'SourceSystem': class="hl-string">'Jira Service Management',
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'CreatedDate': created_date,
            class="hl-string">'ResolutionDate': resolution_date,
            class="hl-string">'IncidentResolutionCycleTime': cycle_time
        }

        class=class="hl-string">"hl-comment"># 1. Incident Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Incident Created',
            class="hl-string">'EventTimestamp': created_date,
            class="hl-string">'Assignee': current_assignee,
            class="hl-string">'AssignmentGroup': current_assignment_group,
            class="hl-string">'Status': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'Priority': current_priority
        })

        class=class="hl-string">"hl-comment"># 2. Comments Added
        if fields.get(class="hl-string">'comment', {}).get(class="hl-string">'comments'):
            for comment in fields[class="hl-string">'comment'][class="hl-string">'comments']:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': class="hl-string">'Comment Added',
                    class="hl-string">'EventTimestamp': comment[class="hl-string">'created'],
                    class="hl-string">'Assignee': current_assignee, class=class="hl-string">"hl-comment"># Note: Assignee at time of comment is not easily available
                    class="hl-string">'AssignmentGroup': current_assignment_group,
                    class="hl-string">'Status': current_status,
                    class="hl-string">'Priority': current_priority
                })

        class=class="hl-string">"hl-comment"># 3. Linked To Problem Ticket
        if fields.get(class="hl-string">'issuelinks'):
            for link in fields[class="hl-string">'issuelinks']:
                link_type = link.get(class="hl-string">'type', {}).get(class="hl-string">'name')
                if class="hl-string">'inwardIssue' in link and link.get(class="hl-string">'inwardIssue', {}).get(class="hl-string">'fields', {}).get(class="hl-string">'issuetype', {}).get(class="hl-string">'name') == class="hl-string">'Problem':
                     event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Linked To Problem Ticket',
                        class="hl-string">'EventTimestamp': created_date, class=class="hl-string">"hl-comment"># Approximation: link creation time is not readily available
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

        class=class="hl-string">"hl-comment"># Process changelog for state changes
        first_assignment = True
        first_prioritization = True

        for history in sorted(changelog, key=lambda x: x[class="hl-string">'created']):
            event_timestamp = history[class="hl-string">'created']
            author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

            for item in history[class="hl-string">'items']:
                field = item.get(class="hl-string">'field', class="hl-string">'').lower()
                activity = None

                class=class="hl-string">"hl-comment"># Track attribute changes over time
                if field == class="hl-string">'assignee':
                    current_assignee = get_field_value_from_changelog(item)
                    if first_assignment and get_field_from_changelog(item) is None:
                        activity = class="hl-string">'Incident Assigned'
                        first_assignment = False
                    elif not first_assignment:
                        activity = class="hl-string">'Incident Reassigned'
                elif field == class="hl-string">'priority' and first_prioritization:
                    current_priority = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Incident Prioritized'
                    first_prioritization = False
                elif field == class="hl-string">'status':
                    from_status = item.get(class="hl-string">'fromString')
                    to_status = item.get(class="hl-string">'toString')
                    current_status = to_status
                    if to_status == STATUS_IN_PROGRESS:
                        activity = class="hl-string">'Investigation Started'
                    elif to_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Waiting For Customer'
                    elif from_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Customer Responded'
                    elif to_status == STATUS_RESOLVED:
                        class=class="hl-string">"hl-comment"># This can represent both Proposed and Resolved
                        event_log.append({
                            **base_event,
                            class="hl-string">'ActivityName': class="hl-string">'Resolution Proposed',
                            class="hl-string">'EventTimestamp': event_timestamp,
                            class="hl-string">'Assignee': current_assignee,
                            class="hl-string">'AssignmentGroup': current_assignment_group,
                            class="hl-string">'Status': to_status,
                            class="hl-string">'Priority': current_priority
                        })
                        activity = class="hl-string">'Incident Resolved'
                    elif to_status == STATUS_CLOSED:
                        activity = class="hl-string">'Incident Closed'
                    elif from_status in [STATUS_RESOLVED, STATUS_CLOSED] and to_status not in [STATUS_RESOLVED, STATUS_CLOSED]:
                         activity = class="hl-string">'Incident Reopened'
                elif item.get(class="hl-string">'fieldId') == ASSIGNMENT_GROUP_FIELD_ID:
                    current_assignment_group = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Escalated To Specialist Team'
                elif field == class="hl-string">'resolution' and item.get(class="hl-string">'toString') == class="hl-string">'Workaround provided':
                    class=class="hl-string">"hl-comment"># This is one way to capture class="hl-string">'Workaround Provided', highly dependent on configuration
                    activity = class="hl-string">'Workaround Provided'

                if activity:
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': activity,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira incident data extraction...")
    issues_data = fetch_jira_issues(JQL_QUERY)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues to create event log...")
        event_log_data = create_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        class=class="hl-string">"hl-comment"># Sort by case and timestamp for a logical event log order
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        
        output_filename = class="hl-string">'jira_incident_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nExtraction complete. Event log saved to '{output_filename}'.")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

ステップ

Jira Service Managementで、インシデントプロジェクト用の自動化ルールを作成または選択します。新しいIncident課題にはissue-createdトリガーを、以降の変更にはissue-updatedトリガーを使用します。関連するプロジェクトと課題タイプでルールが実行されるよう設定し、正確なプロジェクトと課題タイプの設定には[Configure based on your system]を使用してください。
インシデント課題だけが処理されるよう、ルールの条件を設定します。ステータス、優先度、重大度、担当者、割り当てグループ、サポートチーム、コメント、解決、課題リンク、その他、以下に示すアクティビティの特定に必要なフィールドの更新を含めてください。
Webhookアクションを設定し、完全な課題ペイロードをJSON形式で[Your webhook endpoint]へ送信します。課題識別子、課題タイプ、タイムスタンプ、現在のフィールド、利用可能な場合はchangelogまたはフィールド変更情報、コメント、リンク、ステータス、担当者、割り当てグループ、優先度、重大度、サポートチーム、作成日、解決日を含めてください。受信エンドポイントが必要とする認証方式を使用します。
課題の作成時に1つ、条件に該当する更新ごとに1つのペイロードを送信するようルールを設定します。現在の課題スナップショットからアクティビティを推定する処理をProcessMindに任せないでください。受信サービスは各Webhookペイロードとイベント日時を保持し、必要なアクティビティをイベントログの行として出力できるようにする必要があります。
受信サービスでWebhookの署名または認証を検証し、生のJSONペイロードを保存してWebhookの受信時刻を記録します。Jiraのイベント日時は受信時刻とは別に保持してください。Jiraの課題識別子、利用可能な場合はWebhookイベント識別子、イベント日時、ペイロードハッシュを使って再送を重複排除します。
各ペイロードをイベントログのスキーマに変換します。インシデント識別子をIncidentId、アクティビティラベルをActivityName、ソースイベント時刻をEventTimestamp、Jira Service ManagementをSourceSystem、抽出更新時刻をLastDataUpdateにマッピングします。利用可能な場合は、Assignee、AssignmentGroup、Status、Priority、CreatedDate、ResolutionDateも設定してください。
新しいIncident課題が作成されたらIncident Createdを出力します。PriorityまたはSeverityが初めて設定または更新されたらIncident Prioritizedを出力します。AssigneeまたはAssignment Groupが初めて設定されたらIncident Assignedを出力します。ステータスがOpenまたはNewからIn Progressに変わったらInvestigation Startedを出力します。投稿されたコメントごとにComment Addedを出力します。
その後のAssigneeまたはAssignment Groupの変更にはIncident Reassignedを出力します。Support Teamが専門チームに変わった場合、または設定した専門チームへの再割り当て条件を満たした場合は、Escalated To Specialist Teamを出力します。ステータスが設定した待機ステータスに変わったらWaiting For Customerを出力します。その待機ステータスからアクティブなステータスに移行したらCustomer Respondedを出力します。設定した回避策ステータスまたはコメント条件を満たしたらWorkaround Providedを出力します。
ステータスがResolvedに変わったらResolution Proposedを出力します。Problem課題への条件に該当する課題リンクが作成されたらLinked To Problem Ticketを出力します。ステータスがResolvedまたはClosedからオープン状態に変わったらIncident Reopenedを出力します。通常はResolvedへの遷移など、解決確認の設定条件を満たしたらIncident Resolvedを出力し、ステータスがClosedに変わったらIncident Closedを出力します。1つのソース更新が複数のアクティビティルールに該当する場合は、業務設定で日時を明確に区別していない限り、同じソース時刻で別々の行を出力します。
順序、タイムスタンプ、識別子、アクティビティラベルを確認し、CSVまたはProcessMindが対応する別の形式でフラットなイベントログをエクスポートします。明示的に発生したアクティビティごとに1行を含め、必要な列を保持し、タイムゾーン付きの一貫したISO 8601形式のタイムスタンプを使用して、ファイルをProcessMindにアップロードしてください。現在の状態だけを示す課題テーブルは使用しないでください。ProcessMindはイベントログをそのまま読み込み、不足しているイベントを生成しないためです。

設定

トリガー範囲：関連するJira Service ManagementプロジェクトとIncident課題タイプに対して、issue-createdおよびissue-updatedの自動化トリガーを設定します。プロジェクト、課題タイプ、ステータス、フィールド、カスタムフィールドの識別子が異なる場合は、[Configure based on your system]を使用してください。
Webhook送信先：送信先を[Your webhook endpoint]に設定します。受信サービスの要件に従い、認証、TLS、タイムアウト、再試行、署名検証を設定してください。
変更履歴：Webhookの処理経路にchangelogまたはフィールド変更の詳細を含めます。現在の課題情報だけでは、初回割り当て、再割り当て、ステータス遷移、コメント、リンク、再オープンを確実に特定できません。
アクティビティルール：15個すべてのアクティビティについて明示的なルールを設定します。Incident Created、Incident Prioritized、Incident Assigned、Investigation Started、Comment Added、Incident Reassigned、Escalated To Specialist Team、Waiting For Customer、Customer Responded、Workaround Provided、Resolution Proposed、Linked To Problem Ticket、Incident Reopened、Incident Resolved、Incident Closedが対象です。
必須の出力列：すべての行にIncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateを含める必要があります。推奨列はAssignee、AssignmentGroup、Status、Priority、CreatedDate、ResolutionDateです。
期間：履歴データの基準値を作成する場合は、保持されている課題履歴からおよそ3～6か月分を処理し、その後はライブWebhookで取り込みを続けます。インシデントのライフサイクル全体と想定される再オープンを含む期間を選択してください。
フィルター：対象のJiraプロジェクト、Incident課題タイプ、インシデントの期間で絞り込みます。会社、サービス、チーム、環境のフィルターは、それらの値が利用可能で、プロセス範囲に必要な場合に限って適用してください。対応していないデータベースフィルターは使用しないでください。
タイムスタンプの処理：ソースのタイムスタンプをタイムゾーン情報付きで保存します。EventTimestampには実際の遷移、コメント、リンク、フィールド変更の時刻を使用し、LastDataUpdateには抽出または更新の時刻を使用してください。
順序と再試行：可能な限りソースの順序を保持しますが、最終イベントはIncidentIdとEventTimestampで並べ替え、同一時刻には決定的なタイブレーカーを使用します。Webhookの再送は重複排除します。ただし、正当な繰り返しコメントや、条件に該当する繰り返し変更は削除しないでください。
パフォーマンス：非同期でWebhookを処理し、受信ペイロードをキューに入れ、変換とエクスポートをまとめて実行します。受信ストアではIncidentIdとEventTimestampにインデックスを設定してください。ペイロードの保持期間と履歴の再取り込み範囲は必要最小限にします。
前提条件：Jiraの自動化ルールを作成・有効化する管理権限、インシデントのフィールド、コメント、changelog、課題リンクを閲覧する権限、Webhook受信サービスへのアクセス、ProcessMindが対応するアップロード経路が必要です。必要なJiraの自動化、API、監査履歴の機能は、Jiraのエディションと設定によって異なります。
設定上の依存関係：本番環境で抽出を有効にする前に、専門チームの正確な値、待機ステータス、アクティブなステータス、回避策の条件、Problem課題タイプ、対象となるリンクタイプ、解決確認ルールを定義してください。

a サンプルクエリ sql

WITH source_events AS (
    SELECT
        CAST(NULL AS VARCHAR(255)) AS IncidentId,
        CAST(NULL AS VARCHAR(255)) AS ActivityName,
        CAST(NULL AS TIMESTAMP) AS EventTimestamp,
        CAST(NULL AS VARCHAR(255)) AS SourceSystem,
        CAST(NULL AS TIMESTAMP) AS LastDataUpdate,
        CAST(NULL AS VARCHAR(255)) AS Assignee,
        CAST(NULL AS VARCHAR(255)) AS AssignmentGroup,
        CAST(NULL AS VARCHAR(255)) AS Status,
        CAST(NULL AS VARCHAR(255)) AS Priority,
        CAST(NULL AS TIMESTAMP) AS CreatedDate,
        CAST(NULL AS TIMESTAMP) AS ResolutionDate
    WHERE 1 = 0
), webhook_events AS (
    SELECT
        CAST([Your incident identifier expression] AS VARCHAR(255)) AS IncidentId,
        CAST([Your activity name expression] AS VARCHAR(255)) AS ActivityName,
        CAST([Your source event timestamp expression] AS TIMESTAMP) AS EventTimestamp,
        CAST('Jira Service Management' AS VARCHAR(255)) AS SourceSystem,
        CAST([Your extraction refresh timestamp expression] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Your assignee expression] AS VARCHAR(255)) AS Assignee,
        CAST([Your assignment group expression] AS VARCHAR(255)) AS AssignmentGroup,
        CAST([Your status expression] AS VARCHAR(255)) AS Status,
        CAST([Your priority expression] AS VARCHAR(255)) AS Priority,
        CAST([Your created date expression] AS TIMESTAMP) AS CreatedDate,
        CAST([Your resolution date expression] AS TIMESTAMP) AS ResolutionDate,
        CAST([Your issue type expression] AS VARCHAR(255)) AS IssueType,
        CAST([Your previous status expression] AS VARCHAR(255)) AS PreviousStatus,
        CAST([Your changed field expression] AS VARCHAR(255)) AS ChangedField,
        CAST([Your previous assignee expression] AS VARCHAR(255)) AS PreviousAssignee,
        CAST([Your previous assignment group expression] AS VARCHAR(255)) AS PreviousAssignmentGroup,
        CAST([Your support team expression] AS VARCHAR(255)) AS SupportTeam,
        CAST([Your previous support team expression] AS VARCHAR(255)) AS PreviousSupportTeam,
        CAST([Your comment identifier expression] AS VARCHAR(255)) AS CommentIdentifier,
        CAST([Your issue link type expression] AS VARCHAR(255)) AS IssueLinkType,
        CAST([Your linked issue type expression] AS VARCHAR(255)) AS LinkedIssueType,
        CAST([Your workaround condition expression] AS BOOLEAN) AS WorkaroundCondition,
        CAST([Your resolution confirmation expression] AS BOOLEAN) AS ResolutionConfirmation
    FROM [Your webhook event source]
    WHERE CAST([Your issue type expression] AS VARCHAR(255)) = 'Incident'
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) >= CAST([Your start date parameter] AS TIMESTAMP)
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) < CAST([Your end date parameter] AS TIMESTAMP)
      AND [Your company or scope filter expression]
), activity_events AS (
    SELECT IncidentId, 'Incident Created' AS ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Created'
    UNION ALL
    SELECT IncidentId, 'Incident Prioritized', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Prioritized'
       OR (ChangedField IN ('Priority', 'Severity') AND Priority IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Assigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Assigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (Assignee IS NOT NULL OR AssignmentGroup IS NOT NULL) AND PreviousAssignee IS NULL AND PreviousAssignmentGroup IS NULL)
    UNION ALL
    SELECT IncidentId, 'Investigation Started', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Investigation Started'
       OR (PreviousStatus IN ('Open', 'New') AND Status = 'In Progress')
    UNION ALL
    SELECT IncidentId, 'Comment Added', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Comment Added'
       OR (ChangedField = 'Comment' AND CommentIdentifier IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Reassigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reassigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (PreviousAssignee IS NOT NULL OR PreviousAssignmentGroup IS NOT NULL))
    UNION ALL
    SELECT IncidentId, 'Escalated To Specialist Team', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Escalated To Specialist Team'
       OR (ChangedField = 'Support Team' AND SupportTeam IN ('[Your specialist team value]'))
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND AssignmentGroup IN ('[Your specialist team value]'))
    UNION ALL
    SELECT IncidentId, 'Waiting For Customer', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Waiting For Customer'
       OR Status = '[Your waiting for customer status]'
    UNION ALL
    SELECT IncidentId, 'Customer Responded', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Customer Responded'
       OR (PreviousStatus = '[Your waiting for customer status]' AND Status <> '[Your waiting for customer status]')
    UNION ALL
    SELECT IncidentId, 'Workaround Provided', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Workaround Provided'
       OR WorkaroundCondition = TRUE
    UNION ALL
    SELECT IncidentId, 'Resolution Proposed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Resolution Proposed'
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Linked To Problem Ticket', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Linked To Problem Ticket'
       OR (IssueLinkType IN ('relates to', 'caused by') AND LinkedIssueType = 'Problem')
    UNION ALL
    SELECT IncidentId, 'Incident Reopened', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reopened'
       OR (PreviousStatus IN ('Resolved', 'Closed') AND Status IN ('Open', 'New', 'Reopened', 'In Progress'))
    UNION ALL
    SELECT IncidentId, 'Incident Resolved', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Resolved'
       OR (ResolutionConfirmation = TRUE)
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Incident Closed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Closed'
       OR (PreviousStatus <> 'Closed' AND Status = 'Closed')
)
SELECT
    IncidentId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    Assignee,
    AssignmentGroup,
    Status,
    Priority,
    CreatedDate,
    ResolutionDate
FROM activity_events
WHERE IncidentId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY IncidentId, EventTimestamp, ActivityName;

準備はできましたか？

このデータテンプレートを使ってインシデント管理を変革し、非効率を特定して、解決時間を短縮しましょう。今日からプロセスの最適化を始めてください。

改善ガイドに戻るテンプレートをダウンロード

インシデント管理を最適化し、解決を迅速化

プロセスを効率化し、MTTRを35％短縮してユーザー満足度を高めます。

無料トライアルを開始

クレジットカード不要・5分でセットアップ

インシデント管理データテンプレート

インシデント管理データテンプレート

インシデント管理の属性

インシデント管理のアクティビティ

抽出ガイド

Jira Service ManagementのIssue NavigatorからCSVをエクスポート

ステップ

設定

a サンプルクエリ sql

Jiraのオンプレミスデータベースに対する直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

データ抽出用のJira REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

ライブ抽出用のWebhookを使ったJira Automation Rule

ステップ

設定

a サンプルクエリ sql

準備はできましたか？

インシデント管理を最適化し、解決を迅速化

インシデント管理データテンプレート

インシデント管理データテンプレート

インシデント管理の属性

インシデント管理のアクティビティ

抽出ガイド

Jira Service ManagementのIssue NavigatorからCSVをエクスポート

ステップ

設定

a サンプルクエリ sql

Jiraのオンプレミスデータベースに対する直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

データ抽出用のJira REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

ライブ抽出用のWebhookを使ったJira Automation Rule

ステップ

設定

a サンプルクエリ sql

準備はできましたか？

インシデント管理を最適化し、解決を迅速化

プライバシーを大切にしています