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

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

Jira Service Management

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

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

このテンプレートは、Jira Service ManagementにおけるITサービス管理のワークフローを分析するための指針です。必要なデータ項目とプロセス上の節目を特定し、チームが根本的な問題の調査や原因分析をどのように進めているかを把握するために必要な属性とアクティビティを整理します。これらの指針に沿ってデータを収集することで、プロセスマイニングに必要なデータを整え、具体的な改善案につなげられます。

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

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

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

問題管理の属性

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

5 必須 5 推奨 10 任意

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

必須推奨任意

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

解決ワークフローを正確に把握するため、イベントログに記録する主要なプロセスの手順と節目です。

8 推奨 6 任意

	アクティビティ	説明
	インシデントを問題に関連付け	関連するインシデントチケットを問題レコードにリンクしたことを示します。課題リンクテーブルまたは履歴に記録されます。
重要な理由問題の影響と範囲を把握できます。「インシデントから問題へのリンクの深さ」KPIの算出や、ビジネスへの影響に基づく優先順位付けに欠かせません。入手先 Jira課題リンク：「原因である」または「関連する」タイプのリンクを作成記録課題リンクの作成時に記録イベントタイプ explicit
	サポートグループに割り当て	問題レコードを特定の技術チームまたはサポートグループに割り当てたことを示します。「サポートグループ」のカスタム項目、またはグループを使用していない場合は「担当者」項目の変更で追跡します。
重要な理由チーム間の引き継ぎやボトルネックの分析に欠かせません。転送率が高い場合、振り分けに非効率な点がある可能性があります。入手先 Jira課題履歴：「サポートグループ」または「担当者」項目の変更記録割り当て項目の変更時に記録イベントタイプ explicit
	問題レコードをクローズ	問題のライフサイクルの最終終了を示します。ステータスが「クローズ」に変更された時点で明示的に記録されます。
重要な理由プロセスインスタンスの確定した終了点です。合計サイクルタイムやクローズ率の算出に必要です。入手先 Jira課題履歴：ステータスが「クローズ」に変更記録ステータスが「クローズ」に移行した時点で記録イベントタイプ explicit
	問題レコードを作成	問題チケットがシステムに作成された時点を示す最初のイベントです。課題履歴には作成日時として明示的に記録されます。
重要な理由問題管理のライフサイクルの開始を示し、件数の分析に利用できます。処理量や受付率の算出に欠かせません。入手先 Jira課題テーブル：作成日時のタイムスタンプ、または履歴タブ：課題作成イベント記録課題の作成処理が確定した時点で記録イベントタイプ explicit
	回避策を更新	「回避策」テキスト項目への入力または更新を示します。一時的な修正が文書化されたことを表すイベントです。
重要な理由ビジネスへの影響を軽減するまでの速さを測定します。「回避策の提供リードタイム」KPIの算出に欠かせません。入手先 Jira課題履歴：「回避策」項目が変更（空欄ではない）記録回避策項目の変更時に記録イベントタイプ explicit
	根本原因を特定	根本原因が正式に記録された時点です。ステータスが「根本原因を特定」に変更された場合、または「根本原因」項目に値が入力された場合に判定します。
重要な理由調査段階を終える重要な節目です。「根本原因の特定までの平均時間」の算出に欠かせません。入手先 Jira課題履歴：ステータスが「根本原因を特定」に変更、または「根本原因」項目に値を入力記録ステータス項目を比較するか、項目への入力を確認イベントタイプ inferred
	解決を検証	修正によって問題が解決したことを確認した状態です。ステータスが「解決済み」または「検証済み」に移行した場合に判定します。
重要な理由修正が機能することを確認する品質ゲートです。ここでの遅れは、テストやユーザー受け入れにボトルネックがあることを示します。入手先 Jira課題履歴：ステータスが「解決済み」または「検証済み」に変更記録ステータス項目の更新を比較イベントタイプ inferred
	調査を開始	問題のステータスが調査中などのアクティブな調査状態に移行したことを示します。アクティブな作業段階の開始点です。
重要な理由調査のサイクルタイムの計測を開始します。滞留中の待ち時間と実際の分析時間を区別できます。入手先 Jira課題履歴：ステータスが「調査中」または「進行中」に変更記録ステータス項目の更新を比較イベントタイプ inferred
	SLA違反	問題の解決にかかった時間が、定められたサービスレベル契約を超えたことを示すイベントです。SLAの目標日と解決日を比較して算出します。
重要な理由コンプライアンスレポートに欠かせません。目標未達が多い優先度やカテゴリを特定できます。入手先 Jira Service ManagementのSLAログ：「解決までの時間」が目標を超過、または算出値記録 SLA項目のデータから判定するか、期限と解決日を比較イベントタイプ calculated
	問題の優先度を変更	問題レコードの優先度項目が更新されたことを示します。履歴タブで「優先度」項目の変更を確認します。
重要な理由問題のエスカレーションまたは優先度の引き下げを示します。分析すると、初期トリアージの精度や優先度の高い滞留案件の長期化を把握できます。入手先 Jira課題履歴：「優先度」項目が旧値から新しい値に変更記録優先度項目の更新時に記録イベントタイプ explicit
	問題を再オープン	問題のステータスが「解決済み」または「クローズ」からアクティブな状態に戻ったことを示します。修正の失敗、または解決の却下を表します。
重要な理由主要な品質指標です。再オープン率が高い場合、根本原因分析やテストが不十分である可能性があります。入手先 Jira課題履歴：ステータスが「クローズ」または「解決済み」から「オープン」または「進行中」に変更記録ステータス項目の順序を比較イベントタイプ inferred
	変更リクエストをリンク	変更リクエスト（RFC）を問題レコードにリンクしたことを示します。恒久的な修正プロセスの開始を表します。
重要な理由原因の特定から修正の開始までの遅れを測定します。「変更管理への移行遅延」KPIの分析に役立ちます。入手先 Jira課題リンク：「修正される」タイプのリンク、または「変更」課題タイプへのリンクを作成記録「変更」課題タイプへのリンク作成時に記録イベントタイプ explicit
	実装後レビュー	修正の適用後にレビューを実施したことを示します。ステータスの「レビュー中」への変更、または実装後レビュー（PIR）専用項目の更新で記録します。
重要な理由教訓を記録するためのコンプライアンス活動です。「実装後レビューのコンプライアンス」分析に役立ちます。入手先 Jira課題履歴：ステータスが「レビュー中」に変更、または「PIRメモ」項目を更新記録ステータス項目またはPIR項目の更新を比較イベントタイプ inferred
	恒久的な修正を適用	解決策が実装されたことを示すステータス遷移です。通常、「実装中」または「修正済み」への変更から判定します。
重要な理由技術的な修正作業の終了を示します。実装のサイクルタイムの測定に使用します。入手先 Jira課題履歴：ステータスが「実装済み」「検証待ち」または「修正済み」に変更記録ステータス項目の更新を比較イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

問題管理プロジェクトの「Browse Projects」権限を持つアカウントで、ブラウザーからJira Service Managementにログインします。
上部メニューから「Filters」を選択し、「Advanced Issue Search」をクリックして課題ナビゲーターを開きます。
検索モードが「Basic」になっている場合は、「JQL（Jira Query Language）」に切り替えます。
下記のクエリセクションにあるJQLクエリ文字列を入力し、問題レコードを絞り込みます（例：project = 'Problem Management'）。システムのエクスポート上限に合わせて期間を設定してください。
「Search」をクリックし、想定した問題レコードが一覧に表示されることを確認します。
課題ナビゲーター画面の右上にある「Export」を選択します。
ドロップダウンメニューから「Export XML」を選択します。CSVは選択しないでください。標準のCSVエクスポートには現在の状態しか含まれず、プロセスマイニングに必要な変更履歴が記録されません。
生成されたXMLファイル（例：jira_export.xml）を、処理環境からアクセスできるローカルディレクトリに保存します。
必要なライブラリpandasがまだインストールされていない場合は、Python環境にインストールします。
クエリセクションに記載された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環境のフィールド名と一致していることを確認してください。

クエリの例 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の場合は、個人用アクセストークン（PAT）を作成します。
カスタムフィールドIDの確認：Jira Service Managementでは、カスタムフィールドに動的なID（例：サポートグループや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の標準アクティビティ名（例：「調査開始」、「恒久修正の適用」）に対応付けます。
データの抽出：ターミナルまたはIDEからスクリプトを実行します。スクリプトはexpand=changelogを指定してJira Search APIを呼び出し、現在の状態と各フィールドの全変更履歴を取得します。
処理ロジック：スクリプトは各課題を順に処理します。まず、作成日時から「問題レコード作成」イベントを生成します。次に変更履歴を解析し、各履歴項目の変更フィールドが対象リスト（ステータス、優先度、リンクなど）に含まれるかを確認して、対応するイベント行を作成します。
SLAの処理：スクリプトは、SLA関連のカスタムフィールドの変更、または「Breached」と明示されたステータス遷移を調べて、SLA違反を特定します。システムで違反を示すために特定の自動化を使っている場合は、_parse_sla_breach関数のロジックを調整してください。
データ変換：スクリプトは、入れ子になったJSON構造を表形式のPandas DataFrameに変換します。タイムスタンプはISO 8601形式に変換されます。
エクスポート：最終データセットはjira_problem_event_log.csvという名前のCSVファイルに出力されます。ファイルを開き、列名がProcessMindの要件に合っていることを確認してください。
ProcessMindへのアップロード：CSVファイルをProcessMindにインポートします。ProblemKeyをケースID、ActivityNameをアクティビティ、EventTimestampをタイムスタンプにマッピングします。

設定

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

クエリの例 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の課題ナビゲーターからのエクスポート

ステップ

設定

クエリの例 sql

Jira REST APIと変更履歴を使ったPython抽出

ステップ

設定

クエリの例 python

始める準備はできましたか？

問題管理の流れを今すぐ最適化