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

問題管理データテンプレート

Jira Service Management

問題管理の属性 (20) 問題管理のアクティビティ (14) 抽出ガイド (2)

問題管理データテンプレート

このテンプレートは、Jira Service Management内の重要なデータ項目とプロセス上の節目を特定し、ITサービス管理のワークフローを分析するための詳細な道筋を示します。チームが潜在的な問題や根本原因をどのように扱っているかを把握するために必要な属性とアクティビティを、体系的に整理しています。これらのガイドラインに沿ってデータ収集を効率化し、プロセスマイニングから具体的な改善案を得られるようにしてください。

詳細な分析に推奨される属性
イベントログに記録するプロセス上の節目
データ抽出に関する技術ガイダンス

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

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

問題管理の属性

問題管理ライフサイクルを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 5 推奨 10 任意

	名前	説明
	アクティビティ ActivityName	問題レコードで発生した特定の操作またはステータス変更です。
説明この属性は、問題管理ライフサイクル内で発生したイベントまたは状態遷移の名称を記録します。例として、「Problem Logged」、「Status Changed to Investigating」、「Root Cause Identified」などがあります。プロセスフローのマッピングと、問題解決までに実行されたステップの順序の特定に欠かせません。プロセスマイニングでは、これらのアクティビティがプロセスマップのノードになります。重要な理由プロセスマップのステップを定義し、プロセスバリアントを分析できます。入手先 Jiraの変更履歴（履歴）または課題ステータスの遷移例問題レコードを作成調査を開始根本原因を特定回避策を更新問題レコードをクローズ
	ソースシステム SourceSystem	データの取得元となったシステムの名称です。
説明プロセスデータを抽出したソフトウェアシステムを特定します。この場合、値は一貫して「Jira Service Management」です。複数のシステムを利用する環境では、データソースを区別するために特に役立ちます。ただし、このビューでは主にデータの系譜を示す固定識別子として機能します。重要な理由特に他のITサービスマネジメントデータと統合する際に、データの取得元に関する情報を提供します。入手先ハードコードまたはシステム設定例 Jira Service ManagementJira CloudJSM-Prod
	タイムスタンプ EventTimestamp	アクティビティが発生した正確な日時です。
説明この属性は、アクティビティが実行された正確な時点を記録します。イベントを時系列に並べ、ステップ間の所要時間を算出するために使用します。正確なタイムスタンプは、「Problem Logged」から「Root Cause Identified」までの時間など、サイクル時間の算出や、時間の経過に伴う処理量の分析に欠かせません。重要な理由時間に基づくすべてのKPIを算出し、イベントを正しい順序に並べられます。入手先 Jiraの変更履歴作成日時または課題作成日時例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	最終データ更新 LastDataUpdate	データが抽出された時点、または最後に更新された時点のタイムスタンプです。
説明データセットが稼働中のJira Service Management環境と最後に同期された時点を示します。これにより、分析担当者はデータの鮮度を把握できます。分析がプロセスの最新状態を反映しているかを確認し、データの遅延が発生している可能性を特定するために使用します。重要な理由データの鮮度を保ち、分析結果への信頼性を高めます。入手先 ETLタイムスタンプ例 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	問題レコード ProblemKey	Jira Service Managementで問題レコードに割り当てられる一意の識別子です。
説明この属性は、プロセスマイニング分析における中心的なケース識別子です。Jira Service Managementで新しい問題レコードを作成した際に生成される一意のキー（例：PM-1001）を示します。関連するすべてのアクティビティ、ステータス変更、更新を一つのエンドツーエンドのプロセスインスタンスにまとめるために使用します。この属性を分析すると、初期検知から調査、最終クローズまで、問題のライフサイクル全体を可視化できます。重要な理由プロセスフローを再構築し、特定の問題レコードを追跡するために必要な基本キーです。入手先課題テーブルの「Key」または「Issue Key」項目例 PM-1023PM-4099PRB-3321PM-5001
	ユーザー UserKey	アクティビティを実行したユーザーの一意の識別子または名前です。
説明特定のアクティビティを実行した担当者またはシステムアカウントを記録します。レコードを更新した「Assignee」や、ステータス変更を行った「Author」などが該当します。このデータを使って、リソースの利用状況やユーザー間の引き継ぎにおけるボトルネックを分析し、問題管理プロセスにおける説明責任を確保できます。重要な理由引き継ぎ、職務分掌、リソースの負荷を分析するうえで欠かせません。入手先変更履歴のJira「author」フィールド、または課題の「assignee」フィールド例 j.smithsystem_automationm.doe
	優先度 Priority	問題レコードに設定された重要度です。
説明問題の緊急度と影響度を示し、通常は「Low」から「Critical」までの範囲で設定されます。このフィールドを使って分析を分類し、優先度の高い問題がSLAの目標時間内に解決されているかを確認します。この属性を分析すると、「SLAコンプライアンスと目標推移」ダッシュボードで、重要なビジネスリスクに適切な優先順位が付けられているかを確認できます。重要な理由ビジネス上の重要度に応じて、プロセスのパフォーマンスを分類できます。入手先課題の「Priority」フィールド例最高高中低
	割り当て済みサポートグループ SupportGroup	現在、問題の調査を担当している技術チームまたはグループです。
説明イベント発生時点で問題レコードを担当していたチームを特定します。Jira Service Managementでは、「Component」または「Support Group」などのカスタムフィールドに割り当てられることが一般的です。この属性は「サポートグループ間の引き継ぎにおけるボトルネック」ダッシュボードに欠かせません。問題がチーム間をどのように移動し、どこに最も長く滞留しているかを分析できます。重要な理由組織のプロセスマイニングや、チーム間の連携上の摩擦を特定するうえで欠かせません。入手先課題の「Component」フィールド、または「Support Group」カスタムフィールド例データベース管理ネットワーク運用アプリケーションサポートレベル2
	問題の概要 ProblemSummary	問題レコードの短い説明またはタイトルです。
説明問題レコードの概要を見出しとして記録します。主にテキスト情報ですが、プロセスマイニングツールで個別のケースを確認する際の背景情報になります。キーワード検索や、記録された問題の種類に関する定性的な分析にも利用できます。重要な理由ケースIDの内容を人が読み取れる形で補足します。入手先課題の「Summary」フィールド例 EU地域でのデータベース接続タイムアウトメールサービスの遅延急増注文処理キューの停止
	根本原因カテゴリ RootCauseCategory	問題の根本原因を分類したものです。
説明問題を引き起こした技術上またはプロセス上の障害を、「Software Bug」「Human Error」「Hardware Failure」などに分類します。Jira Service Managementでは、カスタムフィールドとして設定されることが一般的です。この属性は「根本原因カテゴリの分布」ダッシュボードを支えます。再発防止に向けて、インフラストラクチャやトレーニングへの投資先を判断できます。重要な理由組織的な問題を特定し、予防策の方向性を定めるうえで重要です。入手先「Root Cause」または「Root Cause Category」カスタムフィールド例ソフトウェアのバグ設定エラー容量の問題ベンダーの問題
	PIRを実施 ReviewStatus	実装後レビュー（PIR）が実施されたかどうかを示します。
説明ケースに「Post Implementation Review」アクティビティまたはフラグが存在するかを追跡します。「実装後レビューのコンプライアンス」ダッシュボードに欠かせません。継続的な改善に関するガバナンス要件を組織が遵守しているかを確認できます。重要な理由組織の学習状況を測るコンプライアンス指標です。入手先「PIR Status」カスタムフィールド、または「PIR」アクティビティの有無例完了保留中不要
	SLA違反ステータス SlaBreachStatus	問題レコードがサービスレベル合意に違反したかどうかを示します。
説明解決時間が合意した目標時間を超えたかどうかを示す真偽値またはステータスフィールドです。「SLAコンプライアンスと目標推移」ダッシュボードで利用します。組織をコンプライアンス上のリスクやペナルティにさらすケースを明らかにします。重要な理由コンプライアンスとパフォーマンスの監視に欠かせません。入手先 Jira Service ManagementのSLAフィールドロジック例達成違反一時停止
	リンクされたインシデント数 LinkedIncidentCount	この問題レコードにリンクされたインシデントの数です。
説明問題レコードに関連付けられたインシデントチケットの件数です。この属性により、問題がユーザーに与えた影響を定量化できます。「インシデントから問題へのリンク深度」KPIで利用し、サポートチケットを最も多く発生させている問題を優先します。重要な理由インシデント件数に基づいてビジネスへの影響を定量化します。入手先「issuelinks」テーブルで、typeが「Problem/Incident」のリンク数例 011550
	リンクされた変更要求 LinkedChangeRequest	この問題にリンクされた変更要求の識別子です。
説明恒久的な修正を実施するために作成された変更要求（RFC）のIDを保存します。このリンクは「変更要求の開始遅延」ダッシュボードに欠かせません。問題管理プロセスと変更管理をつなぎ、プロセス横断の分析を可能にします。重要な理由調査と、変更管理プロセスにおける是正対応をつなぎます。入手先 typeが「is fixed by」などの課題リンク例 CR-404CHG-1099CR-5512
	作成日 CreatedDate	問題レコードが作成された日付です。
説明問題がシステムに初めて記録された時点のタイムスタンプです。イベントのタイムスタンプがアクティビティの時刻を扱うのに対し、この属性は「第1四半期に作成された問題をすべて表示する」といった大まかな絞り込みによく使われます。経過期間の分析における基準点になります。重要な理由経過期間と受付件数を分析するための基準日です。入手先課題の「Created」フィールド例 2023-01-012023-06-15
	再オープン済み IsReopened	クローズ後に問題が再オープンされたかどうかを示すフラグです。
説明問題レコードがクローズ状態からオープン状態に戻った場合にtrueになる真偽値フラグです。「問題の再オープン率分析」を支えます。再オープン率が高い場合、恒久的な修正の品質に問題があるか、検証手順が不十分である可能性があります。重要な理由修正の有効性を示す品質指標です。入手先ステータスの遷移から導出例 truefalse
	回避策の有無 WorkaroundDetails	問題に対する回避策が文書化されているかどうかを示します。
説明一時的な回避策の説明が存在するか、公開されているかを記録します。これにより、組織は「回避策の公開速度」を追跡できます。このフィールドを分析すると、恒久的な修正が見つかる前に、チームがどれだけ速くサービスを安定した状態に戻せるかを確認できます。重要な理由ビジネスに提供した暫定的な救済策の速さを測定するうえで重要です。入手先「Workaround」カスタムフィールド例サービスを再起動ブラウザーのキャッシュを消去提供なし
	報告者 ReporterName	最初に問題レコードを登録したユーザーです。
説明問題レコードを作成した個人を特定します。担当者とは異なります。報告者を分析すると、問題がどこで検出されているか（例：サービスデスク担当者、システム管理者）を把握できます。「プロアクティブ検出とリアクティブ検出」の分析に背景情報を加えます。重要な理由問題の受付元を特定します。入手先課題の「Reporter」フィールド例 monitoring_servicehelpdesk_leadnetwork_admin
	検出元 DetectionSource	問題がどのように特定されたかを示します（例：Proactive、Reactive）。
説明問題を特定した経緯を示します。一般的な値には、「Proactive Monitoring」「Service Desk Incident」「Vendor Notification」などがあります。この属性は「プロアクティブ検出とリアクティブ検出」ダッシュボードで、問題管理プロセスの成熟度を測定するために使われます。重要な理由プロセスの成熟度と監視システムの有効性を測定できます。入手先「Source」または「Detection Source」カスタムフィールド例プロアクティブ監視インシデントのエスカレーションサプライヤーへの通知
	解決コード ResolutionCode	問題の解決方法を示すコードです。
説明問題レコードの最終的な結果を、「Fixed」「Won't Fix」「Duplicate」「Cannot Reproduce」などで示します。これを使って、正常に解決された問題と、管理上の理由でクローズされた問題を分けて抽出できます。「Mean Time to Root Cause」などのKPIを正確に算出するうえで役立ちます。重要な理由有効な修正と、管理上のクローズを区別できます。入手先課題の「Resolution」フィールド例完了実施しない重複再現不可

必須推奨任意

問題管理のアクティビティ

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

8 推奨 6 任意

	アクティビティ	説明
	インシデントを問題にリンク	関連するインシデントチケットを問題レコードにリンクする操作です。課題リンクテーブルまたは履歴から取得します。
重要な理由問題の影響と範囲を判断します。「インシデントから問題へのリンク深度」KPIの算出と、業務への影響に基づく優先順位付けに欠かせません。入手先 Jira課題リンク：「causes」または「relates to」タイプのリンクを作成取得課題リンクが作成された時点で記録イベントタイプ explicit
	サポートグループに割り当て	問題レコードを特定の技術チームまたはサポートグループに割り当てる操作です。「Support Group」カスタム項目の変更、またはグループを使用していない場合は「Assignee」項目の変更によって追跡します。
重要な理由チーム間の引き継ぎとボトルネックの分析に欠かせません。転送率が高い場合、振り分けに非効率がある可能性を示します。入手先 Jira課題履歴：「Support Group」または「Assignee」項目が変更取得割り当て項目が変更された時点で記録イベントタイプ explicit
	問題レコードをクローズ	問題ライフサイクルの最終終了です。ステータスが「Closed」に変更された時点で明示的に取得します。
重要な理由プロセスインスタンスの確定した終了点です。総サイクル時間とクローズ率の算出に必要です。入手先 Jira課題履歴：ステータスを「Closed」に変更取得ステータスがClosedに遷移した時点で記録イベントタイプ explicit
	問題レコードを作成	問題チケットがシステム内で作成された際に発生する最初のイベントです。課題履歴には、作成時刻として明示的に記録されます。
重要な理由問題管理ライフサイクルの開始点を示し、件数分析を可能にします。処理量と受付率の算出に欠かせません。入手先 Jira課題テーブル：作成日時のタイムスタンプ、または履歴タブ：課題作成イベント取得課題の作成処理が確定した時点で記録イベントタイプ explicit
	回避策を更新	「Workaround」テキスト項目への入力または更新です。一時的な修正が文書化されたことを示します。
重要な理由業務への影響を軽減するまでの速さを測定します。「回避策提供リードタイム」KPIに欠かせません。入手先 Jira課題履歴：「Workaround」項目が変更（nullではない）取得 Workaround項目が変更された時点で記録イベントタイプ explicit
	根本原因を特定	根本原因が正式に記録された時点です。「Root Cause Identified」へのステータス変更、または「Root Cause」項目への入力から推定します。
重要な理由調査段階を終える重要なマイルストーンです。「根本原因特定までの平均時間」の算出に欠かせません。入手先 Jira課題履歴：ステータスを「Root Cause Identified」に変更、または「Root Cause」項目に入力取得ステータス項目を比較、または項目への入力を確認イベントタイプ inferred
	解決を検証	修正によって問題が効果的に解決されたことを確認します。「Resolved」または特定の「Verified」状態へのステータス遷移から推定します。
重要な理由修正が機能することを確認する品質ゲートです。ここでの遅れは、テストまたはユーザー受け入れにボトルネックがあることを示します。入手先 Jira課題履歴：ステータスを「Resolved」または「Verified」に変更取得ステータス項目の更新を比較イベントタイプ inferred
	調査を開始	問題のステータスをアクティブな調査状態（例：「Under Investigation」または「In Progress」）に変更する遷移です。アクティブな作業段階の開始を示します。
重要な理由調査サイクル時間の計測を開始します。バックログでの待ち時間と、実際の分析にかかった時間を区別できます。入手先 Jira課題履歴：ステータスを「Under Investigation」または「In Progress」に変更取得ステータス項目の更新を比較イベントタイプ inferred
	SLA違反	問題の解決時間が定義されたサービスレベル合意を超えたことを示すイベントです。SLAの目標日時と解決日時を比較して算出します。
重要な理由コンプライアンスレポートに欠かせません。どの優先度やカテゴリーで目標未達が頻発しているかを特定できます。入手先 Jira Service ManagementのSLAログ：「Time to Resolution」＞目標値、または計算値取得 SLA項目のデータから導出、または期限日と解決日を比較イベントタイプ calculated
	問題の優先度を変更	問題レコードのPriority項目を更新する操作です。履歴タブで「Priority」項目の変更を監視して取得します。
重要な理由問題のエスカレーションまたは優先度引き下げを示します。分析することで、初回トリアージの精度と高優先度バックログの滞留期間を把握できます。入手先 Jira課題履歴：「Priority」項目が旧値から新しい値に変更取得 Priority項目が更新された時点で記録イベントタイプ explicit
	問題を再オープン	問題のステータスを「Resolved」または「Closed」からアクティブなステータスに戻す遷移です。修正の失敗または解決の却下を示します。
重要な理由主要な品質指標です。再オープン率が高い場合、根本原因分析またはテストが不十分である可能性があります。入手先 Jira課題履歴：ステータスを「Closed」または「Resolved」から「Open」または「In Progress」に変更取得ステータス項目の順序を比較イベントタイプ inferred
	変更リクエストをリンク	変更リクエスト（RFC）を問題レコードにリンクする操作です。恒久対応プロセスの開始を示します。
重要な理由原因の特定から是正対応の開始までの遅れを測定します。「変更管理への移行遅延」KPIを支援します。入手先 Jira課題リンク：「is fixed by」タイプのリンクを作成、または「Change」課題タイプにリンク取得 Change課題タイプへのリンクが作成された時点で記録イベントタイプ explicit
	実装後レビュー	修正適用後にレビューを実施することです。「In Review」へのステータス変更、またはPIR固有項目の更新によって取得します。
重要な理由得られた教訓を記録するためのコンプライアンス活動です。「実装後レビューのコンプライアンス」分析を支援します。入手先 Jira課題履歴：ステータスを「In Review」に変更、または「PIR Notes」項目を更新取得ステータス項目またはPIR項目の更新を比較イベントタイプ inferred
	恒久対応を適用	解決策が実装されたことを示す遷移です。通常、「Implementing」または「Fixed」へのステータス変更から推定します。
重要な理由技術的な是正作業の終了を示します。実装サイクル時間の測定に使用します。入手先 Jira課題履歴：ステータスを「Implemented」、「Pending Verification」、または「Fixed」に変更取得ステータス項目の更新を比較イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Problem ManagementプロジェクトでBrowse Projects権限を持つアカウントを使用し、WebブラウザーからJira Service Managementのインスタンスにログインします。
上部のメニューバーでFiltersを開き、Advanced Issue SearchをクリックしてIssue Navigatorを開きます。
まだ選択されていない場合は、検索モードをBasicではなくJQL（Jira Query Language）に切り替えます。
以下のQueryセクションに記載されたJQLクエリ文字列を入力し、Problemレコード（例：project = 'Problem Management'）に絞り込みます。システムのエクスポート上限に適した期間を指定してください。
Searchボタンをクリックし、想定したProblemレコードが課題一覧に表示されることを確認します。
Issue Navigator画面の右上にあるExportボタンを探します。
ドロップダウンメニューからExport XMLを選択します。標準のCSVエクスポートは現在の状態データしか提供せず、プロセスマイニングに必要な変更履歴ログが含まれないため、CSVは選択しないでください。
生成されたXMLファイル（例：jira_export.xml）を、処理環境からアクセスできるローカルディレクトリに保存します。
必要なライブラリpandasがまだインストールされていない場合は、Python環境にインストールします。
Queryセクションに記載されたPythonスクリプトを実行し、ファイルパス変数が保存したXMLファイルの場所と一致していることを確認します。
スクリプトはRSS/XML構造を解析し、Createdタイムスタンプ、ステータス・優先度・担当者の変更を示すHistoryエントリー、関連インシデントを示すIssue Linksを抽出します。
スクリプトは解決日と期限日を比較してSLA違反を計算し、ProcessMindで使用できる形式のCSVイベントログを出力します。

設定

エクスポート形式：CSVではなく、XML（RSS）形式でエクスポートする必要があります。XML形式には、プロセスフローの再構築に不可欠な<history>および<issuelinks>タグが含まれます。
行数上限：Jiraの標準エクスポートは、1回あたり1,000件に制限されることがよくあります。大規模なデータセットでは、JQLの日付範囲（例：created >= '2023-01-01' AND created < '2023-02-01'）を調整して抽出を分割し、複数回エクスポートしてください。
JQLフィルター：projectキーが、問題管理プロジェクト固有の識別子（例：PROB、PM）と一致していることを確認します。
システムのタイムゾーン：エクスポートを実行するユーザープロファイルのタイムゾーンが、システムのタイムゾーンと一致していることを確認し、タイムスタンプの一貫性を保ちます。
フィールド権限：遷移とインシデントリンクを取得するには、変更履歴とリンクされた課題を表示する権限が必要です。
カスタムフィールド：「Root Cause」または「Workaround」がカスタムフィールドの場合は、スクリプトのフィールド名照合ロジックが、Jiraインスタンス内の実際のフィールド名と一致していることを確認します。

a サンプルクエリ sql

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

ステップ

前提条件の準備：Python 3.xとrequestsおよびpandasライブラリがインストールされていることを確認します。対象プロジェクトの読み取り権限を持つJira Service Managementアカウントが必要です。Jira Cloudでは、Atlassianアカウント設定からAPIトークンを生成します。Data Centerでは、Personal Access Token（PAT）を生成します。
カスタムフィールドIDの特定：Jira Service Managementでは、カスタムフィールドに動的なIDが割り当てられます（例：Support GroupまたはSLAのcustomfield_10012）。メインの抽出を実行する前に、ブラウザまたはPostmanから特定の問題チケット（/rest/api/2/issue/[ISSUE-KEY]）をクエリし、「Support Group」、「Workaround」、「Root Cause」、SLAフィールドの実際のフィールドIDを確認します。
スクリプトの設定：提供されたPythonスクリプトを開き、CONFIG辞書を更新します。URL、ユーザーメールアドレス、APIトークンを置き換えます。手順2で確認した実際のカスタムフィールド名またはIDを使って、FIELD_MAPPING辞書を更新します。JQL_QUERYを更新し、対象プロジェクトを指定します（例：project = PM AND issuetype = Problem）。
ステータスマッピングの定義：スクリプト内のSTATUS_MAPPING辞書で、使用しているJiraワークフローのステータス（例：「Under Investigation」、「Implementing」、「Resolved」）を、ProcessMindの標準アクティビティ名（例：「Investigation Started」、「Permanent Fix Applied」）にマッピングします。
抽出の実行：ターミナルまたはIDEからスクリプトを実行します。スクリプトはexpand=changelogを指定したJira Search APIを使い、各フィールドの現在の状態と完全な変更履歴を取得します。
処理ロジック：スクリプトはすべての課題を順に処理します。まず、作成タイムスタンプから「Problem Record Created」イベントを作成します。次に変更履歴を解析し、各履歴項目について、変更されたフィールドが対象リスト（Status、Priority、Linkなど）に含まれるかを確認し、対応するイベント行を生成します。
SLAの処理：スクリプトは、SLA関連のカスタムフィールドの変更、または「Breached」と明示されたステータス遷移を確認し、SLA違反の特定を試みます。システムで特定の自動化により違反を記録している場合は、_parse_sla_breach関数のロジックを調整してください。
データ変換：スクリプトはネストされたJSON構造を表形式のPandas DataFrameに変換します。タイムスタンプはISO 8601形式に変換されます。
エクスポート：最終データセットをjira_problem_event_log.csvという名前のCSVファイルにエクスポートします。ファイルを開き、列見出しがProcessMindの要件と一致していることを確認します。
ProcessMindへのアップロード：CSVファイルをProcessMindにインポートします。ProblemKeyをCase ID、ActivityNameをActivity、EventTimestampをTimestampにマッピングします。

設定

APIエンドポイント：/rest/api/2/searchを使用します（CloudおよびほとんどのData Centerバージョンに対応）。API v3もサポートしていますが、幅広い互換性を考慮するとv2が一般的に安全です。
ページネーション：スクリプトはstartAtとmaxResultsを使ってページネーションを実装し、大規模なデータセットを効率的に処理します。デフォルトのバッチサイズは50です。
変更履歴の展開：expand=changelogパラメーターは欠かせません。これがない場合、現在の状態しか返されず、履歴とプロセスフローが失われます。
JQLによる絞り込み：クエリはissuetype = Problemで絞り込みます。初期テストでは、データ量を抑えるため日付範囲フィルター（例：created >= -180d）を追加することを強く推奨します。
認証：CloudではBasic Auth（メールアドレス＋トークン）に対応しています。Data Centerでは、ヘッダーをBearerトークン用に変更してください。
フィールドマッピング：重要な設定項目です。Jira内部の「Status」と「Priority」のフィールド名は標準ですが、「Support Group」、「Root Cause」、「SLA」はほとんどの場合、固有のID（例：customfield_12345）を持つカスタムフィールドです。

a サンプルクエリ python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        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(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

準備はできましたか？

問題管理のデータを具体的な改善案に変えましょう。ガイドをダウンロードするか、サポートチームにお問い合わせいただき、プロセスマイニングを始めてください。

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

今すぐ問題管理のフローを最適化

サイクルタイムを30％短縮し、IT環境を安定させます。

無料トライアルを開始

クレジットカードは不要です。数分でセットアップできます。

問題管理データテンプレート

問題管理データテンプレート

問題管理の属性

問題管理のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ sql

変更履歴を含むJira REST API経由のPython抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

今すぐ問題管理のフローを最適化

問題管理データテンプレート

問題管理データテンプレート

問題管理の属性

問題管理のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ sql

変更履歴を含むJira REST API経由のPython抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

今すぐ問題管理のフローを最適化

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