> 継続的なプロセス改善 > サービスリクエスト管理 > Jira Service Management > データテンプレート

サービスリクエスト管理のデータテンプレート

Jira Service Management

サービスリクエスト管理の属性(17) サービスリクエスト管理のアクティビティ(13) データ抽出ガイド(3)

サービスリクエスト管理のデータテンプレート

このテンプレートでは、サービスリクエストのプロセス分析に必要なデータを収集するための手順をまとめています。収集すべき属性や追跡するアクティビティを示し、システムからデータを抽出する方法も説明します。データ準備にお役立ていただくことで、業務の状況をより詳しく把握できます。

詳細な分析に推奨される属性
プロセスの把握に必要な主なアクティビティ
Jira Service Managementからのデータ抽出ガイド

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

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

サービスリクエスト管理の属性

サービスリクエスト管理を詳しく分析するために、イベントログに含めることを推奨するデータ項目です。

5 必須 5 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	サービスリクエストのライフサイクルで発生したイベントまたはタスクの名称です。
説明この属性は、サービスリクエストに対して特定の時点で行われた操作やステータスの移行を表します。例として、「リクエスト作成」「リクエスト割り当て」「解決策の実装」「リクエストクローズ」などがあります。こうしたアクティビティの順序や頻度を分析することが、プロセスマイニングの中心です。プロセスマップの可視化、ボトルネックの特定、標準的なワークフローからの逸脱の検出に役立ち、プロセスの効率やコンプライアンスを把握できます。重要な理由プロセスの各ステップを定義し、プロセスマップの可視化やワークフローのパターン、逸脱の分析を可能にします。入手先通常は、Jiraの課題に記録された「status」の変更履歴から取得します。課題の変更履歴でstatusフィールドに記録された各項目が、1つのアクティビティに相当します。例リクエストのトリアージ情報の確認依頼解決策の実施サービスリクエストクローズ
	サービスリクエストID ServiceRequestId	各サービスリクエストを一意に識別するIDです。関連するすべてのイベントの主キーとして使用します。
説明サービスリクエストIDは、Jiraでは課題キーとも呼ばれ、ユーザーまたはシステムが送信した個々のサービスリクエストを一意に識別します。最初の記録から最終的なクローズまで、後続のすべてのイベントを結び付ける軸となり、各リクエストの経過を最初から最後まで分析できます。プロセスマイニングでは、このIDがケースを関連付けるために欠かせません。すべてのアクティビティ、ステータス変更、タイムスタンプを該当するリクエストに正しく結び付け、分析対象となる一貫したプロセスインスタンスを構成します。重要な理由関連するすべてのアクティビティを1つのエンドツーエンドのプロセスフローに結び付ける、基本となるケース識別子です。これにより、プロセスを分析できます。入手先 Jira Service Managementの課題にある「key」フィールドです。例 SR-2023-001IT-45892HELP-105
	開始時刻 EventTime	特定のアクティビティまたはイベントが発生した正確な日時です。
説明開始時刻（イベントのタイムスタンプ）は、アクティビティが発生した正確な時点を記録します。プロセス全体の時間的な流れを把握するため、プロセスマイニング分析に欠かせない要素です。このタイムスタンプを使ってイベントを時系列に並べ、アクティビティ間の所要時間やケース全体のサイクルタイムを算出し、SLAなど時間に関する目標に対するプロセスのパフォーマンスを分析します。正確なタイムスタンプがなければ、プロセスの流れや遅延の発生箇所、効率を把握できません。重要な理由イベントの順序付け、所要時間やサイクルタイムの算出、プロセスのボトルネックの特定に欠かせないタイムスタンプです。入手先 Jiraの課題の変更履歴に記録された各ステータス移行のタイムスタンプです。課題の作成時刻には「created」フィールドを使用します。例 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	ソースシステム SourceSystem	サービスリクエストのデータを抽出したシステムです。
説明この属性はデータの取得元を示します。この場合はJira Service Managementです。単一のソースから取得したデータを分析する場合は重要性が低く見えることもありますが、複数のシステムのプロセスデータを統合する際には欠かせません。分析では、データの来歴を追跡し、データ品質を確保するのに役立ちます。また、複数のソフトウェアプラットフォームにまたがる、または連携するプロセスを絞り込んで比較できます。重要な理由データの取得元を示します。データガバナンスや、複数のエンタープライズシステムのプロセスデータを統合する際に重要です。入手先通常は、データ抽出・変換の処理中に追加される固定値で、データセットの取得元を示します。例 Jira Service ManagementJiraSM
	最終データ更新 LastDataUpdate	ソースシステムからデータを最後に更新した日時を示すタイムスタンプです。
説明この属性には、Jira Service Managementからデータを最後に抽出した日時が記録されます。分析やダッシュボード、重要業績評価指標（KPI）に含まれるデータがどの程度新しいかを把握するための情報です。意思決定にあたっては、データの鮮度を把握することが欠かせません。このタイムスタンプにより、リアルタイムの情報を見ているのか、過去のある時点のスナップショットを見ているのかを確認できます。これは分析結果の有用性にも影響します。重要な理由データの鮮度を示し、最新の情報に基づいて分析できるようにします。入手先データ抽出ツールまたはスクリプトの実行終了時に生成・保存されるメタデータフィールドです。例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	SLA期限 SlaDueDate	SLAに基づき、サービスリクエストを解決する目標日時です。
説明 SLA期限は、リクエストの解決期限を示す計算済みのタイムスタンプです。Jira Service Managementで設定されたサービスレベルアグリーメント（SLA）のポリシーに基づき、リクエストの優先度や種類などから決まります。この属性は、「サービスリクエストのSLAパフォーマンス」ダッシュボードや「SLA遵守率」の重要業績評価指標（KPI）の基礎となります。実際の解決時刻と期限を比較することで、各リクエストが期限内に完了したか、遅延したか、SLA違反のおそれがあるかを判定できます。重要な理由パフォーマンス測定の基準となります。SLAの遵守状況の算出に直接役立ち、作業の優先順位付けにも役立ちます。入手先 SLA情報はJira Service Managementで管理され、APIから取得できます。動的に更新されるカスタムフィールドに保存されていることもあります。例 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	リクエストのステータス RequestStatus	ライフサイクルにおけるサービスリクエストの現在のステータスです。
説明この属性は、サービスリクエストの現在の状態を表します。「オープン」「進行中」「顧客待ち」「解決済み」などがあります。任意の時点でリクエストがどの段階にあるかを示します。アクティビティログから過去の流れを確認できる一方、現在のステータスは未完了の作業を分析し、停滞している項目を特定するのに役立ちます。たとえば、「ベンダー待ち」のステータスが通常より長く続いているリクエストを分析し、外部への依存や遅延を明らかにできます。重要な理由各ケースの現在の状況を示し、進行中の作業を分析するとともに、停滞または長期化しているリクエストを特定できます。入手先 Jiraの課題にある「status」フィールドです。例オープン進行中顧客待ち解決済み
	リクエストの優先度 RequestPriority	サービスリクエストに設定された優先度です。「低」「中」「高」「重大」などがあります。
説明リクエストの優先度は、サービスリクエストの緊急度とビジネスへの影響を示します。この分類によって対応順が決まり、目標解決時間やSLAが定められることもあります。プロセス分析では、優先度が重要な分析軸になります。優先度ごとにサイクルタイムやSLAの遵守状況を比較し、優先度の高いリクエストがより迅速に処理され、目標を達成しているかを確認できます。これにより、優先順位付けの仕組みが有効に機能しているかを検証できます。重要な理由分析を優先度別に分け、優先度の高いリクエストがより迅速に処理され、より厳しいサービスレベルを満たしているかを確認できます。入手先 Jiraの課題にある「priority」フィールドに対応します。例最高高中低
	リクエストの種類 RequestType	「アクセス権の申請」や「ハードウェアの問題」など、サービスリクエストの分類です。
説明リクエストの種類は、内容に応じてサービスリクエストを分類します。リクエストの種類によって解決プロセス、SLA、必要なリソースが異なるため、分析の基本となる軸です。リクエストの種類ごとにプロセスを分析すると、組織はワークフローに応じた改善策を検討できます。たとえば、「パスワードのリセット」と「新しいサーバーの構築」では、ボトルネックとなる箇所が大きく異なります。この属性は、「カテゴリー別の解決品質」など、目的に合ったダッシュボードの作成にも役立ちます。重要な理由サービスリクエストの種類ごとに、プロセス、作業負荷、パフォーマンスを比較するうえで欠かせない属性です。入手先 Jiraの「issuetype」フィールド、またはJira Service Managementのカスタム「リクエストの種類」フィールドに対応することが多い項目です。例新しいアカウントを申請ITサポートを依頼新入社員の受け入れ
	担当者 Assignee	サービスリクエストの対応を現在担当しているユーザーまたはエージェントです。
説明担当者は、サービスリクエストに対する次の対応または解決を担う人です。リクエストのライフサイクルを通じて、エージェントやチーム間で引き継がれるたびに、この属性の値が変わることがあります。この属性は、作業負荷の分析、パフォーマンスの測定、リソース管理に欠かせません。エージェント別にプロセスを絞り込み、担当者間で解決時間を比較できます。また、ボトルネックにつながる可能性のある研修ニーズや作業負荷の偏りも特定できます。重要な理由エージェントの作業負荷の分析、個人のパフォーマンス測定、リソース配分の把握に欠かせない属性です。入手先 Jiraの課題にある「assignee」フィールドに対応します。例アリス・ジョンソンボブ・ウィリアムズ未割り当て
	SLAの状態 SlaState	サービスリクエストがSLAを達成したか、違反したか、またはSLAの期限内にあるかを示します。
説明 SLAの状態は、SLA期限に対するパフォーマンスに基づいて各サービスリクエストを分類する計算属性です。「達成」「違反」「進行中」などの値があります。「SlaDueDate」と解決時刻を比較して判定します。「サービスリクエストのSLAパフォーマンス」ダッシュボードの中心となる属性で、「SLA遵守率」の重要業績評価指標（KPI）の算出にも使われます。サービスレベルの遵守状況をひと目で確認でき、レポート作成、契約管理、サービス品質の維持に役立ちます。重要な理由 SLAのパフォーマンスをすぐに確認できます。サービス品質や契約上のコンプライアンスを測る重要な指標です。入手先データ変換時に算出します。解決時刻が「SlaDueDate」より前であれば「達成」、それ以外は「違反」と判定します。例達成違反進行中
	チャネル Channel	サービスリクエストの作成に使われた送信方法です。メール、ポータル、APIなどがあります。
説明チャネル属性は、サービスリクエストがどの経路でシステムに登録されたかを示します。Jira Service Managementでは、顧客ポータル、メール、エージェントによる直接作成などが一般的です。チャネル別のプロセス分析は、ユーザーの行動を把握し、サービス提供を改善するうえで重要です。特定のチャネルからのリクエストは解決に時間がかかる、または確認が多く必要になるといった傾向が分かれば、ポータルのフォーム改善やメール解析ルールの見直しにつながります。「サービスリクエスト処理件数の推移」ダッシュボードにも役立ちます。重要な理由送信チャネルが解決時間、リクエストの明確さ、プロセス全体の効率に影響しているかを分析できます。入手先 Jira Service Managementでは「Request channel type」フィールドから取得できます。専用のAPIアクセスが必要な場合や、カスタムフィールドに保存されている場合があります。例ポータルメールAPI
	再オープン済み IsReopened	サービスリクエストが解決後に再オープンされたかどうかを示す真偽値です。
説明この計算属性は、リクエストのワークフローに「リクエスト再オープン」のアクティビティが含まれる場合にtrueとなる真偽値です。各ケースのアクティビティの順序を分析して算出します。このフラグは、「サービスリクエスト再オープン率」の重要業績評価指標（KPI）の算出や、「再オープンされたサービスリクエスト件数」ダッシュボードの作成に欠かせません。再オープン率が高い場合、初回解決の品質が低く、手戻りや顧客満足度の低下につながっている可能性があります。このフラグに関連するリクエストの種類や解決内容を分析すると、改善すべき領域を特定できます。重要な理由手戻りと初回解決の品質を直接測定でき、プロセスの有効性や顧客満足度を示す重要な指標になります。入手先データ変換時に、ケースのアクティビティの順序に「解決済み」への移行後の「再オープン」への移行が含まれるかを確認して算出します。例 truefalse
	報告者 Reporter	サービスリクエストを最初に作成または報告したユーザーです。
説明報告者は、サービスリクエストを送信した人です。エンドユーザーや顧客が該当することが多く、プロセスを開始した関係者を示します。分析では、報告者を使って、ユーザー、部門、顧客セグメントごとのリクエストの傾向を把握できます。「最も多くリクエストを送信している部門はどこか」「特定のユーザーが同じ問題に繰り返し直面していないか」といった問いに答えるのに役立ちます。この情報は、問題の予防的な管理やユーザー研修の改善にも役立ちます。重要な理由リクエストの送信者を特定し、ユーザー、部門、顧客ごとの件数や種類を分析できます。入手先 Jiraの課題にある「reporter」フィールドに対応します。例チャールズ・ダーウィンマリー・キュリーアイザック・ニュートン
	担当チーム AssignedTeam	サービスリクエストの対応を担うチームまたはグループです。
説明この属性は、リクエストを担当するチームを示します。個々の担当者より上位の単位でグループ化されることが多く、第一レベルサポートチームとネットワーク運用チームの比較など、チーム単位のパフォーマンス分析に役立ちます。「エージェントの作業負荷と解決指標」などのダッシュボードに欠かせない分析軸です。チーム単位でパフォーマンス指標を集計できるため、公平な比較や、各チームがサービス提供全体にどのように貢献しているかの把握に役立ちます。重要な理由個々のエージェントだけでなく、チームや部門単位でパフォーマンスを分析し、作業負荷を調整できます。入手先 Jiraのカスタムフィールド（「Team」など）を使うか、担当者のユーザープロフィール属性から取得する場合があります。例 ITサポート：ティア1インフラストラクチャチームアプリケーションサポート
	組織 Organization	報告者が所属する顧客組織または社内部門です。
説明この属性は、報告者を組織または部門ごとに分類します。Jira Service Managementには「組織」機能が組み込まれており、エージェントは複数の顧客や社内チームからのリクエストを管理できます。組織別の分析では、ビジネスの状況を踏まえて結果を把握できます。どの顧客や部門がサポートリソースを最も多く必要としているか、特定のグループで問題が繰り返し発生していないか、事業部門ごとにSLAを一貫して達成できているかを確認できます。重要な理由顧客または社内部門ごとにサービス需要やパフォーマンスを分析し、ビジネス上の重要なインサイトを得られます。入手先 Jira Service Managementでサービスリクエストに関連付けられた「Organizations」フィールドのデータです。例アクメ・コーポレーション財務部門グローバル・テック
	解決内容 Resolution	解決済みのサービスリクエストの最終的な結果または結論です。
説明解決内容フィールドは、サービスリクエストをクローズした理由を示します。「完了」「対応しない」「重複」「再現できない」などが一般的な値です。「解決済み」や「クローズ」というステータスだけでは分からない、クローズの詳細を確認できます。解決内容を分析すると、結果の品質や傾向を把握できます。たとえば、「重複」による解決が多い場合、リクエストの送信プロセスに問題がある可能性があります。また、どの解決内容が再オープンにつながるかを追跡すれば、効果の低い解決策を特定できます。重要な理由リクエストの結果に関する情報を示し、解決品質の分析やクローズ理由の傾向把握に役立ちます。入手先 Jiraの課題にある「resolution」フィールドに対応します。通常、課題が「完了」ステータスカテゴリーに移行したときに設定されます。例完了対応しない重複修正済み

必須推奨任意

サービスリクエスト管理のアクティビティ

プロセスを正確に把握し、改善するためにイベントログへ記録する主なステップと節目です。

5 推奨 8 任意

	アクティビティ	説明
	サービスリクエストクローズ	サービスリクエストの最終的な事務処理上のクローズを示します。「解決済み」の状態になってから一定期間後に自動でクローズされる場合もあります。Jiraにおける課題のライフサイクルの終点です。
重要な理由プロセスの最終的な終了イベントです。「解決済み」から「クローズ」までの時間を分析すると、事務処理にかかる時間や自動クローズのルールを把握できます。入手先課題の履歴から推定します。タイムスタンプは、ステータスが最後に「クローズ」または同等の終了ステータスに変わった時刻です。記録ステータスが最後に「クローズ」に変わった時刻を特定します。イベントタイプ inferred
	サービスリクエストの作成	ユーザーがポータルやメールなどの窓口から正式にリクエストを送信し、サービスリクエストのライフサイクルが始まるアクティビティです。Jiraでは、「サービスリクエスト」タイプの新しい課題が作成されたイベントとして明示的に記録され、作成時刻も保存されます。
重要な理由このアクティビティは、プロセスの主な開始イベントです。全体のサイクルタイムを計算し、リクエストの件数や到着パターンを把握するために欠かせません。入手先課題の履歴テーブルに明示的に記録されるイベントです。アクティビティのタイムスタンプには、Jiraの課題にある「created」フィールドを使います。記録「issues」テーブルまたは履歴から、課題の作成タイムスタンプを使用します。イベントタイプ explicit
	サービスリクエスト解決	リクエストが完了したとみなされ、解決内容が記録された正式な時点を示します。Jiraでは、課題が初めて「完了」カテゴリーのステータスになると、「解決日」フィールドに値が設定されます。
重要な理由プロセスの主要な終了マイルストーンの1つです。解決時間やSLAの遵守状況を算出するうえで重要であり、対応作業の終了を示します。入手先明示的なイベントです。タイムスタンプには、Jiraの課題が初めて「完了」カテゴリーのステータスに移行したときに設定される「解決日」フィールドの値を使用します。記録 Jiraの課題にある「resolutiondate」フィールドを使用します。このフィールドには自動的に値が設定されます。イベントタイプ explicit
	リクエストの割り当て	サービスリクエストの解決を担当する特定の担当者やチームが割り当てられたときに発生するアクティビティです。Jiraでは「担当者」フィールドの変更が明示的に記録されるため、割り当て時刻を確認できます。
重要な理由トリアージから割り当てまでの時間や、担当者ごとの業務量を測る重要な節目です。待機状態から実際の対応に移るタイミングを示します。入手先課題の履歴で、「担当者」フィールドが初めて設定された時点、または未割り当ての状態から変更された時点を確認します。記録課題の履歴にある「担当者」フィールドの最初の変更時刻を使用します。イベントタイプ explicit
	解決策の提示	多くのサービスデスクのワークフローでは、解決策をリクエストをした人に提示し、承認を得る独立した手順です。課題のステータスが「顧客の承認待ち」や「確認待ち」などに変わったことから推定します。
重要な理由このアクティビティを使うと、解決策の提示後に顧客からの回答を待つ時間を切り分け、社内作業の時間と区別できます。入手先課題の履歴から推定し、解決策の顧客確認待ちを示すステータスに変わった時刻を記録します。記録「顧客の承認待ち」または同等のステータスに変わった時刻を特定します。イベントタイプ inferred
	ベンダー対応の終了	外部ベンダーの対応が完了し、サービスリクエストが社内チームに戻った時点を示します。課題が「ベンダー待ち」ステータスから移行したことから推定します。
重要な理由ベンダー対応の所要時間を測ることで、ベンダーのパフォーマンスを管理し、解決までの時間に外部関係者が与える影響を把握できます。入手先課題の履歴から推定します。課題のステータスが「ベンダー対応」から「進行中」に戻った時刻を使用します。記録「status」フィールドが「ベンダー対応」の状態から「対応中」の状態に戻った時刻を特定します。イベントタイプ inferred
	ベンダー対応の開始	サービスリクエストが外部ベンダーや第三者にエスカレーションされた、またはその対応が必要になったことを示します。通常、課題が「ベンダー待ち」や「第三者対応中」などのステータスに移行したことから推定します。
重要な理由ベンダー対応を追跡することで、社内のサービスデスクが直接管理できない外部への依存や遅延を特定できます。入手先課題の履歴から推定します。課題のステータスが指定された「ベンダー対応」ステータスに変わった時刻を使用します。記録「status」フィールドが「ベンダー待ち」などの値に変わった時刻を特定します。イベントタイプ inferred
	リクエストのトリアージ	サービスリクエストの初期評価を表します。ここで優先度、カテゴリ、影響度を判断します。通常、「新規」から「進行中」への移行や、専用の「トリアージ済み」ステータスへの変更から推定します。
重要な理由トリアージまでの時間を分析すると、リクエストの初期対応の効率を評価できます。この段階での遅れは、解決までの時間やSLA遵守率に大きく影響する可能性があります。入手先課題の履歴から推定します。最初の「新規」または「オープン」状態から、「進行中」などの対応中の状態に変わった最初のタイムスタンプを特定します。記録プロジェクトのワークフローに基づき、「新規」または同等の初期ステータスから最初に変更された箇所を特定します。イベントタイプ inferred
	リクエストの再オープン	解決済みのサービスリクエストが対応中の状態に戻ったケースを記録するアクティビティです。解決済みまたはクローズの状態から、オープンまたは進行中の状態に変わったことから推定します。
重要な理由再オープンされたリクエストを追跡することは、解決品質や初回解決率を測るうえで重要です。再オープン率が高い場合、解決策が有効でない、または問題が再発している可能性があります。入手先課題の履歴から、「解決済み」または「クローズ」カテゴリのステータスが、「オープン」または「進行中」カテゴリのステータスに変わったことを特定します。記録「完了」カテゴリのステータスから、「未着手」または「進行中」カテゴリのステータスへの変更を確認します。イベントタイプ inferred
	情報の提供	リクエストをした人が必要な情報を回答し、担当者が作業を再開できる状態になったときに発生します。通常、リクエストをした人がコメントを追加するなどして、課題が「顧客待ち」ステータスから移行したことから推定します。
重要な理由このアクティビティで、顧客との情報確認のやり取りが完了します。情報を求めてから受け取るまでの時間は、プロセスの待ち時間を構成する重要な要素です。入手先課題の履歴から推定します。課題のステータスが「顧客待ち」から「進行中」に戻った時刻を使用します。記録「status」フィールドが「待機中」の状態から「対応中」の状態に変わった時刻を特定します。イベントタイプ inferred
	情報の確認依頼	解決を進めるために、担当者がリクエストをした人に追加情報を求める時点を示します。通常、課題が「顧客待ち」や「入力待ち」などのステータスに移行したことから推定します。
重要な理由「情報の確認依頼」が頻繁に発生したり、長引いたりする場合、最初のリクエストが不明確だったり、連絡が非効率だったりする可能性があります。これは遅延の大きな原因になります。入手先課題の履歴から推定します。課題のステータスが「顧客待ち」または同等のステータスに変わった時刻を使用します。記録「status」フィールドが、顧客からの回答待ちを示す値に変わった時刻を特定します。イベントタイプ inferred
	解決の確認	リクエストをした人が提示された解決策を正式に承認したときに発生します。多くの場合、「解決済み」ステータスへの自動移行が行われ、このステータス変更からイベントを推定します。
重要な理由この節目で解決策の有効性を確認し、SLAの計測を終了します。顧客が修正内容を確認するまでの時間を測るのにも役立ちます。入手先課題の履歴から推定します。「顧客の承認待ち」から「解決済み」または「クローズ」に変わった時刻を使用します。記録ステータスが「顧客の承認待ち」から「解決済み」または「クローズ」に変わった時刻を特定します。イベントタイプ inferred
	解決策の実施	担当者がサービスリクエストに対応するために必要な作業を行った、または解決策を作成したことを示します。多くの場合、「レビュー待ち」または「解決済み」へのステータス変更から推定します。
重要な理由この節目は、解決に向けた主要な作業の完了を示します。このアクティビティまでの時間は、プロセスの中核となる価値提供の時間にあたることが多いです。入手先課題の履歴から推定します。「解決済み」「承認待ち」など、クローズ前のステータスに変更された時刻を使用します。記録「status」フィールドが、作業の完了を示す値に変わった時刻を特定します。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

Jira Service Managementのインスタンスにログインし、メインメニューを開きます。
フィルターを選択し、続けて高度な課題検索を選びます。課題ナビゲーターが開き、クエリを作成できます。
検索バーに「クエリ」セクションのJQL（Jira Query Language）クエリを入力し、分析するサービスリクエストを絞り込みます。必要に応じてプロジェクトキーと日付範囲を調整してください。
検索ボタンをクリックしてクエリを実行します。表示された課題の一覧を確認し、対象のデータが正しく抽出されていることを確かめます。
検索結果ページの右上にあるエクスポートアイコン（外向きの矢印が付いたボックスの形をしていることが多いです）をクリックします。
ドロップダウンメニューからXMLを選択します。完全なイベントログの作成に必要な詳細な変更履歴が標準のCSVエクスポートには含まれないため、XMLを選択してください。
ダウンロードしたXMLファイルをローカルシステムに保存します。このファイルには、クエリで抽出したすべての課題と、各課題のデータに含まれる変更履歴が記録されています。
エクスポートしたXMLはイベントログ形式ではないため、後処理が必要です。スクリプト（Python、PowerShellなど）を使ってXMLファイルを解析してください。
スクリプトでファイル内の各課題を処理し、作成日時から「サービスリクエスト作成」イベントを作成します。次に、各課題の変更履歴を解析し、「ステータス」と「担当者」の変更から必要なアクティビティを特定します。変更ごとに新しい行を作成してください。
データをフラットなCSVファイルに変換し、ServiceRequestId、ActivityName、EventTimeの列と、その他の必須属性を作成します。
スクリプトの最終出力がイベントログです。CSVファイルを保存し、プロセスマイニングツールにアップロードできる状態にしてください。

設定

JQLのプロジェクトフィルター：特定のサービス管理プロジェクトを対象にするには、project = "[Your JSM Project Key]"を使います。プレースホルダーを、たとえば「JSM」や「HELPDESK」など、実際のプロジェクトキーに置き換えてください。
JQLの課題タイプフィルター：issuetype = "Service Request"を使うか、設定でサービスリクエストに使用している課題タイプ名を指定します。
日付範囲：エクスポートのデータ量を抑えるため、期間を指定して絞り込むことを強くおすすめします。created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD"のような条件を使います。最初は3～6か月の範囲が適しています。
エクスポート形式：エクスポート形式にはXMLを選択してください。CSV形式にはイベントログの作成に必要な変更履歴データが含まれません。
Jiraの権限：エクスポートを実行するユーザーには、指定したJiraプロジェクトの課題を表示・エクスポートするための「プロジェクトの閲覧」権限が必要です。
データ量：Jiraの標準UIでは、一度にエクスポートできる課題数が通常1,000件に制限されています。クエリの結果がこれを超える場合は、エクスポートごとに日付範囲を狭め、複数回に分けてください。

クエリの例 config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

ステップ

データベースへのアクセスを取得：JiraインスタンスのバックエンドSQLデータベースに接続するため、読み取り専用の認証情報と接続情報（ホスト名、ポート、データベース名）を入手します。通常はデータベース管理者またはIT部門の支援が必要です。
Jiraのスキーマを確認：DBeaver、SQuirreL SQL、SQL Server Management StudioなどのSQLクライアントでデータベースに接続します。主要なテーブルとして、jiraissue（課題の基本データ）、changegroup（変更履歴）、changeitem（各変更の詳細）、project（プロジェクトの詳細）、issuetype、priorityを確認します。
カスタムフィールドIDを特定：RequestTypeやSlaDueDateなどの属性は、カスタムフィールドであることがよくあります。customfieldテーブルに対してSELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');を実行し、IDを特定します。メインクエリで使うため、これらのIDを控えてください。
SQLクエリを設定：提示されたSQLスクリプトをSQLクライアントにコピーします。角括弧で囲まれたプレースホルダーをすべて、Jiraの設定に合った実際の値に置き換えてください。プロジェクトキー、課題タイプ名、ステータス名、カスタムフィールドIDが対象です。
日付範囲を設定：クエリの最初のissue_base部分にあるWHERE i.created >= '[YYYY-MM-DD]'句を探します。データを抽出する期間に合わせて日付を変更してください。
クエリを実行：変更したSQLスクリプトを実行します。このクエリは、PostgreSQL、SQL Server、MySQLなどの一般的なSQLデータベースで実行できます。大規模なJiraインスタンスでは、完了まで数分かかる場合があります。
結果を確認：クエリの実行後、行が返されていることと、ServiceRequestId、ActivityName、EventTimeなどの列に想定どおり値が入っていることを簡単に確認します。
データをエクスポート：SQLクライアントから結果全体をCSVファイルにエクスポートします。ファイル名はjira_servicerequest_eventlog.csvのように、内容がわかるものにしてください。
アップロードの準備：CSVファイルを開き、列見出しがServiceRequestId、ActivityName、EventTimeなどの必須属性名と完全に一致することを確認します。ProcessMindとの互換性を保つため、UTF-8エンコーディングで保存してください。

設定

前提条件：Jiraの本番データベースまたはレプリカデータベースへの直接の読み取り専用アクセスが必要です。通常のアプリケーションアクセスでは不十分です。また、対象のサービスデスクプロジェクトのワークフローについて、ステータス名、課題タイプ、カスタムフィールドの正確な名称を含め、十分に把握している必要があります。
主なクエリフィルター：正しいデータセットを対象にするよう、クエリを設定してください。次のWHERE句をよく確認します。
- p.pkey IN ('[Your Project Key]')：最も重要なフィルターです。対象を1つ以上の特定のJira Service Managementプロジェクトに限定します。
- it.pname = '[Your Service Request Issue Type]'：インシデント、問題、その他の課題タイプではなく、サービスリクエストだけを抽出します。
- i.created >= '[YYYY-MM-DD]'：抽出の開始日を指定します。最初の分析では、直近3～6か月を対象にすることをおすすめします。
ワークフローのステータスマッピング：イベントログの正確性は、クエリ内でJiraのステータス名を正しく対応付けられるかどうかに左右されます。[Status for Triage]、[Waiting for Customer Status]、[Resolved Status]などのプレースホルダーを、実際のワークフローで使われている名称に置き換えてください。
パフォーマンスに関する注意点：大規模で稼働中のJiraデータベースに対してこのクエリを直接実行すると、多くのリソースを消費し、ユーザー向けのアプリケーション性能に影響する可能性があります。読み取りレプリカに対して実行するか、利用の少ない時間帯に抽出することを強くおすすめします。

クエリの例 sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

ステップ

前提条件とセットアップ：システムにPython 3.6以降がインストールされていることを確認します。ターミナルで次のコマンドを実行し、必要なPythonライブラリをインストールします：pip install requests pandas。
Jira APIトークンを作成：Jira Cloudアカウントにログインします。プロフィール設定から「アカウント設定」を選び、「セキュリティ」タブでAPIトークンを作成します。このトークンは認証に使うため、安全にコピーして保管してください。
カスタムフィールドIDを特定：「リクエストタイプ」や「SLA期限日」など、Jiraの属性にはカスタムフィールドが使われている場合があります。IDを確認するには、「設定」＞「課題」＞「カスタムフィールド」を開きます。対象のフィールドを検索し、三点リーダー「...」＞「フィールド情報を表示」をクリックします。IDはURL内にあります（例：customFieldId=10021）。スクリプトの設定に使うため、IDを控えてください。
Pythonスクリプトを設定：提示されたPythonスクリプトをテキストエディターで開きます。ファイルの先頭にある設定変数に、JIRA_URL、JIRA_EMAIL、JIRA_API_TOKEN、サービスリクエストを選択するjql_query、前の手順で特定したCUSTOM_FIELD_IDSを入力します。
Jiraのステータスをアクティビティに対応付け：スクリプト内のSTATUS_ACTIVITY_MAP辞書を必ず確認してください。Jira Service Managementの実際のワークフローに合わせて、この対応関係を更新します。キーにはJiraのステータス名（例：「顧客からの回答待ち」）を正確に指定し、値にはイベントログで必要なアクティビティ名（例：「情報を依頼」）を指定します。
抽出スクリプトを実行：ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動して、python jira_extraction_script.pyを実行します。スクリプトがJira APIに接続して課題データを取得・処理し、進行状況をコンソールに表示します。
出力ファイルを確認：スクリプトの実行が完了すると、同じディレクトリにjira_event_log.csvというCSVファイルが作成されます。表計算アプリケーションで開き、内容を確認します。すべての列があり、想定どおり値が入力されていることを確認してください。
ProcessMindへのアップロード準備：CSVファイルの列見出しが、ServiceRequestId、ActivityName、EventTime、SourceSystem、LastDataUpdate、Assignee、RequestPriority、RequestStatus、RequestType、SlaDueDateという要件に完全に一致することを確認します。これでファイルをProcessMindにアップロードできます。

設定

Jira認証：スクリプトで安全にアクセスするには、JiraのドメインURL、Jiraアカウントに登録されているメールアドレス、個人用APIトークンが必要です。
JQLクエリ（jql_query）：抽出対象を決める中心的なフィルターです。正しい課題を選ぶため、JQLクエリを正確に指定してください。データ量を調整するには、project、issuetype、createdDateを使った日付範囲で絞り込むことをおすすめします（例：project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'）。
ステータスとアクティビティの対応付け（STATUS_ACTIVITY_MAP）：Jiraのステータス変更を意味のあるプロセスアクティビティに正しく対応付けるために必要な辞書です。組織固有のJiraワークフローに合わせて設定してください。この辞書にないステータスは無視されます。
カスタムフィールドID（CUSTOM_FIELD_IDS）：「リクエストタイプ」や「SLA期限日」などのカスタムフィールドからデータを抽出するには、一意のシステムID（例：customfield_10021）を指定する必要があります。属性に値を設定するには、IDを正しく指定してください。
日付範囲とパフォーマンス：最初の抽出では、処理しやすいデータ量にするため、JQLの日付範囲を3～6か月に設定することをおすすめします。数年分のデータを抽出すると、APIのページネーションやレート制限により時間がかかる場合があります。

クエリの例 python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{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'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

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

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

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

このテンプレートを使ってプロセスマイニングを始め、サービスリクエスト管理の改善につなげましょう。今日から業務の改善に取り組めます。

改善ガイドに戻る

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

Jiraのサービスリクエスト管理を今すぐ改善

自動化率70％を達成し、対応の遅れを解消しましょう。今すぐ効率を高めましょう。

無料トライアルを開始しましょう

クレジットカードは不要です。数分で設定できます。

サービスリクエスト管理のデータテンプレート

サービスリクエスト管理のデータテンプレート

サービスリクエスト管理の属性

サービスリクエスト管理のアクティビティ

データ抽出ガイド

Jira Service Managementの標準CSV/XMLエクスポート

ステップ

設定

クエリの例 config

Jira Server／Data Centerでのデータベース直接クエリ

ステップ

設定

クエリの例 sql

Jira Cloud REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

クエリの例 python

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

Jiraのサービスリクエスト管理を今すぐ改善