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

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

Jira Service Management

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

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

このテンプレートでは、サービスリクエストプロセスの分析に必要なデータを収集するための構成を示します。収集すべき重要な属性、追跡すべき主要なアクティビティ、システムから情報を抽出する方法をまとめています。このリソースを使ってデータ準備を効率化し、業務への理解を深めてください。

詳細な分析に推奨される属性
プロセスディスカバリーで追跡すべき主要なアクティビティ
Jira Service Managementからの抽出ガイダンス

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

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

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

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

5 必須 5 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	サービスリクエストのライフサイクル内で発生した、特定のイベントまたはタスクの名称です。
説明この属性は、サービスリクエストについて、ある時点で実行された具体的な操作またはステータス遷移を示します。例として、「リクエスト作成」、「リクエスト割り当て」、「解決策の実装」、「リクエストのクローズ」などがあります。これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの中心的な機能です。プロセスマップの可視化、ボトルネックの特定、標準ワークフローからの逸脱の検出が可能になり、プロセスの効率とコンプライアンスを把握できます。重要な理由プロセスの手順を定義し、プロセスマップの可視化とワークフローのパターンおよび逸脱の分析を可能にします。入手先通常は、Jira課題の「ステータス」遷移履歴から取得します。課題の変更履歴にあるステータスフィールドの各エントリが、1つのアクティビティを表します。例リクエストのトリアージ完了情報の依頼解決策の実施サービスリクエストのクローズ
	サービスリクエストID ServiceRequestId	各サービスリクエストを識別する一意の識別子であり、関連するすべてのイベントの主キーです。
説明サービスリクエストIDは、Jiraで「課題キー」と呼ばれることが多く、ユーザーまたはシステムから送信された個々のサービスリクエストを一意に識別します。初回の記録から最終的なクローズまで、後続するすべてのイベントをつなぐ中心的な識別子となり、各サービスリクエストの経路をエンドツーエンドで分析できます。プロセスマイニングでは、このIDがケースの相関付けに欠かせません。すべてのアクティビティ、ステータス変更、タイムスタンプを、それぞれが属する特定のリクエストに正しく関連付け、分析対象となる一貫したプロセスインスタンスを形成します。重要な理由このIDは、関連するすべてのアクティビティを1つのエンドツーエンドのプロセスフローにつなぐ基本的なケース識別子であり、プロセス分析を可能にします。入手先 Jira Service Managementの課題における「キー」フィールドです。例 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
	リクエストタイプ RequestType	サービスリクエストの分類です。例として、「Access Request」や「Hardware Issue」があります。
説明リクエストタイプは、サービスリクエストを内容に応じて分類します。異なるタイプのリクエストには、それぞれ異なる解決プロセス、SLA、必要なリソースがあるため、分析の基本的な軸になります。リクエストタイプ別にプロセスを分析することで、組織は特定のワークフローに合わせて改善策を調整できます。たとえば、「Password Reset」と「New Server Provisioning」では、ボトルネックになる箇所が大きく異なります。この属性は、「カテゴリ別の解決品質」のような関連性の高いダッシュボードを作成するうえでも重要です。重要な理由異なるサービスリクエストのカテゴリ間で、プロセス、作業量、パフォーマンスを比較するために欠かせません。入手先 Jiraの「issuetype」フィールド、またはJira Service Managementのカスタム「Request Type」フィールドに対応することが多い項目です。例新しいアカウントを申請ITサポートを依頼新入社員を受け入れ
	リクエストのステータス RequestStatus	ライフサイクルにおけるサービスリクエストの現在のステータスです。
説明この属性は、サービスリクエストの現在の状態を示します。例として、「Open」、「In Progress」、「Waiting for Customer」、「Resolved」があります。任意の時点で、リクエストがどの段階にあるかを確認できます。アクティビティログから過去の流れを確認できる一方、現在のステータスは未完了の作業量を分析し、滞留している項目を特定するのに役立ちます。たとえば、「Waiting for Vendor」のステータスが通常より長く続いているリクエストに焦点を当てることで、外部依存や遅延を明らかにできます。重要な理由各ケースの現在の状況を把握できるため、進行中の作業を分析し、停滞または長期化しているリクエストを特定できます。入手先 Jira課題の「status」フィールドです。例オープン対応中顧客待ち解決済み
	リクエストの優先度 RequestPriority	サービスリクエストに設定された優先度です。例として、Low、Medium、High、Criticalがあります。
説明リクエストの優先度は、サービスリクエストの緊急度とビジネスへの影響を示します。この分類によって対応順が決まり、目標解決時間やSLAが定められることもあります。プロセス分析では、優先度が重要な分析軸になります。優先度ごとにサイクルタイムやSLA遵守状況を比較し、高優先度のリクエストが実際により速く処理され、目標を達成しているかを確認できます。これにより、優先順位付けの仕組みが適切に機能しているかを検証できます。重要な理由分析を優先度別に分け、高優先度のリクエストがより迅速に処理され、より厳しいサービスレベルを満たしているかを確認できます。入手先 Jira課題の「priority」フィールドに対応します。例最高高中低
	担当者 Assignee	現在、サービスリクエストの対応を担当しているユーザーまたはエージェントです。
説明担当者は、サービスリクエストに対する次のアクションまたは解決に責任を持つ担当者です。異なるエージェントやチームに引き継がれるため、リクエストのライフサイクル中にこの属性の値が何度も変わることがあります。この属性は、作業量の分析、パフォーマンスの測定、リソース管理に欠かせません。エージェント別にプロセスをフィルタリングしたり、担当者間で解決時間を比較したり、トレーニングの必要性やボトルネックにつながる作業量の偏りを特定したりできます。重要な理由エージェントの作業量の分析、個人のパフォーマンス測定、リソース配分の把握に欠かせません。入手先 Jira課題の「assignee」フィールドに対応します。例 Alice JohnsonBob Williams未割り当て
	SLA状態 SlaState	サービスリクエストがSLAを達成したか、違反したか、または現在SLAの範囲内にあるかを示します。
説明 SLA状態は、SLA期限に対するパフォーマンスに基づいて各サービスリクエストを分類する計算済み属性です。値には「Met」、「Breached」、「In Progress」などがあります。解決時刻と「SlaDueDate」を比較して判定します。「サービスリクエストのSLAパフォーマンス」ダッシュボードの中心となる属性であり、「SLA遵守率」KPIの計算にも使われます。サービスレベルの遵守状況を一目で確認できるため、レポート、契約管理、サービス品質の維持に役立ちます。重要な理由 SLAパフォーマンスを明確かつ即座に確認できます。サービス品質と契約上のコンプライアンスを測る重要な指標です。入手先データ変換時に計算します。解決時刻が「SlaDueDate」より前であれば「Met」、それ以外は「Breached」となります。例達成違反対応中
	チャネル Channel	サービスリクエストの作成に使われた送信方法です。例として、メール、ポータル、APIがあります。
説明チャネル属性は、サービスリクエストがどのようにシステムへ登録されたかを示します。Jira Service Managementで一般的なチャネルには、カスタマーポータル、メール、エージェントによる直接作成があります。チャネル別にプロセスを分析することは、ユーザーの行動を理解し、サービス提供を改善するうえで重要です。特定のチャネルからのリクエストだけ解決に時間がかかる、または追加の確認が必要になる場合、ポータルのフォーム改善やメール解析ルールの見直しが必要だと分かります。これは「サービスリクエスト処理量の傾向」ダッシュボードにも役立ちます。重要な理由送信チャネルが解決時間、リクエストの明確さ、プロセス全体の効率に与える影響を分析できます。入手先この情報は、Jira Service Managementの「Request channel type」フィールドから取得できます。専用のAPIアクセスが必要になる場合や、カスタムフィールドに保存されている場合があります。例ポータルメールAPI
	再オープン済み IsReopened	解決済みになった後、サービスリクエストが再オープンされたかどうかを示すブール値のフラグです。
説明この計算済み属性は、リクエストのワークフローに「Request Reopened」アクティビティが含まれる場合にtrueとなるフラグです。各ケースのアクティビティの順序を分析して導出します。このフラグは、「サービスリクエスト再オープン率」KPIの計算や、「再オープンされたサービスリクエスト数」ダッシュボードに欠かせません。再オープン率が高い場合、初回解決の品質が低く、手戻りや顧客満足度の低下につながっている可能性があります。このフラグに関連するリクエストタイプや解決結果を分析することで、改善すべき領域を特定できます。重要な理由手戻りと初回解決の品質を直接測定できます。どちらもプロセスの有効性と顧客満足度を示す重要な指標です。入手先データ変換時に、ケースのアクティビティの順序に「Resolved」遷移後の「Reopened」遷移が含まれているかを確認して計算します。例 truefalse
	報告者 Reporter	サービスリクエストを最初に作成または報告したユーザーです。
説明報告者は、サービスリクエストを送信した個人です。エンドユーザーや顧客であることが多く、プロセスを開始した関係者を示します。分析では、報告者を使って、ユーザー、部門、顧客セグメントごとのリクエスト傾向を把握できます。「最も多くリクエストを送信している部門はどこか」「特定のユーザーが同じ問題に繰り返し直面していないか」といった問いに答えられます。この情報は、問題の予防的な管理やユーザートレーニングの改善に役立ちます。重要な理由リクエストの起点となったユーザーを特定し、ユーザー、部門、顧客別にリクエスト量と種類を分析できます。入手先 Jira課題の「reporter」フィールドに対応します。例 Charles DarwinMarie CurieIsaac Newton
	担当チーム AssignedTeam	サービスリクエストへの対応を担当するチームまたはグループです。
説明この属性は、リクエストを担当するチームを示します。個々の担当者よりも上位のグループ単位で分類されることが多く、チームレベルでパフォーマンスを分析するのに役立ちます。たとえば、ファーストレベルサポートチームとネットワーク運用チームを比較できます。この分析軸は、「エージェントの作業量と解決指標」のようなダッシュボードに欠かせません。チーム単位でパフォーマンス指標を集計できるため、公平な比較や、各チームがサービス提供プロセス全体にどのように貢献しているかの把握につながります。重要な理由個々のエージェントだけでなく、チームまたは部門単位でパフォーマンスを分析し、作業量のバランスを調整できます。入手先 Jiraのカスタムフィールド（例：「Team」）の場合や、担当者のユーザープロフィール属性から導出される場合があります。例 ITサポート：第1層インフラストラクチャチームアプリケーションサポート
	組織 Organization	報告者が所属する顧客組織または社内の部門です。
説明この属性は、報告者を組織または部門ごとにグループ化します。Jira Service Managementには「Organizations」機能が組み込まれており、エージェントは複数の顧客や社内チームからのリクエストを管理できます。組織別に分析すると、ビジネス上の背景を把握できます。どの顧客や部門が最も多くサポートリソースを消費しているか、特定のグループで問題が繰り返し発生していないか、異なる事業部門でSLAが一貫して守られているかを確認できます。重要な理由顧客または社内部門別にサービス需要とパフォーマンスを分析し、重要なビジネス上の示唆を得られます。入手先 Jira Service Managementのサービスリクエストに関連付けられた「Organizations」フィールドから取得されます。例 Acme Corporation財務部門Global Tech Inc.
	解決結果 Resolution	解決済みのサービスリクエストにおける最終的な結果または結論です。
説明 Resolutionフィールドは、サービスリクエストをクローズした理由を示します。一般的な値には、「Done」、「Won't Do」、「Duplicate」、「Cannot Reproduce」があります。「Resolved」や「Closed」のステータスだけでは分からない、クローズに至った詳細を確認できます。解決結果を分析すると、結果の品質や内容を把握できます。たとえば、「Duplicate」が多い場合は、リクエストの登録プロセスに問題がある可能性があります。また、どの解決結果が再オープンにつながるかを追跡することで、効果の低い解決策を特定できます。重要な理由リクエストの結果に関する背景情報を提供し、解決品質や、リクエストがクローズされる理由の傾向を分析できます。入手先 Jira課題の「resolution」フィールドに対応します。通常、課題が「done」ステータスカテゴリに遷移した際に設定されます。例完了対応しない重複修正済み

必須推奨任意

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

正確なプロセス発見と最適化を行うため、イベントログに記録すべき主要なプロセス手順とマイルストーンです。

5 推奨 8 任意

	アクティビティ	説明
	サービスリクエストのクローズ	サービスリクエストを最終的に管理上クローズすることを示します。「Resolved」状態で一定期間が経過した後に自動的に実行されることが多く、Jiraにおける課題のライフサイクルの終点です。
重要な理由プロセスの確定的な終了イベントです。「Resolved」から「Closed」までの時間を分析すると、管理上の負荷や自動クローズポリシーの影響を把握できます。入手先課題履歴から推定します。タイムスタンプは、ステータスが最後に「Closed」または同等の終了ステータスへ変更された時刻です。取得ステータスが最後に「Closed」へ変更された時刻を特定します。イベントタイプ inferred
	サービスリクエスト作成	このアクティビティは、ユーザーがポータル、メール、その他のチャネルから正式にリクエストを送信した時点で始まる、サービスリクエストのライフサイクルの開始を示します。Jiraでは、「Service Request」タイプの新しい課題が作成されたイベントとして明示的に記録され、作成時刻が保存されます。
重要な理由これはプロセスの主な開始イベントです。全体のサイクルタイムを計算し、リクエスト量と到着パターンを把握するために欠かせません。入手先課題履歴テーブルに明示的なイベントとして記録されます。アクティビティのタイムスタンプには、Jira課題の「created」フィールドを使います。取得「issues」テーブルまたは履歴から、課題の作成時刻を使います。イベントタイプ explicit
	サービスリクエスト解決	リクエストが完了し、解決策が記録された正式な時点を示します。Jiraでは、課題が初めて「Done」カテゴリーのステータスに移行した際に、「Resolution Date」フィールドが入力されます。
重要な理由これはプロセスの主な終了時点であり、解決時間とSLA遵守率の計算に欠かせません。アクティブな作業の終了を示します。入手先明示的なイベントです。タイムスタンプには、Jira課題の「Resolution Date」フィールドの値を使います。この値は、初めて「Done」カテゴリーのステータスへ移行した際に設定されます。取得 Jira課題の「resolutiondate」フィールドを使います。このフィールドは自動的に入力されます。イベントタイプ explicit
	リクエストの割り当て	サービスリクエストが、解決を担当する特定のエージェントまたはチームに割り当てられた時点で発生します。Jiraでは「Assignee」フィールドの変更を明示的に追跡するため、割り当て時刻を明確に把握できます。
重要な理由トリアージから割り当てまでの時間や、エージェントの業務量を測定するための重要な節目です。キューで待機する状態から、実際の対応へ移る時点を示します。入手先課題履歴から、「Assignee」フィールドが初めて設定された時点、または未割り当てから変更された時点を確認します。取得課題履歴で最初に「Assignee」フィールドが変更された時刻を使います。イベントタイプ explicit
	解決策の提示	多くのサービスデスクのワークフローでは、解決策をリクエスト元に提示し、承認を得る独立したステップがあります。通常は、課題のステータスが「Pending Customer Acceptance」や「Awaiting Confirmation」などに変更されたことから推定します。
重要な理由このアクティビティにより、解決策を提示した後に顧客からのフィードバックを待つ時間を切り分けられます。社内作業の時間と区別して把握できます。入手先課題履歴から推定し、解決策が顧客による確認待ちになったことを示すステータスへ変更された時刻を記録します。取得ステータスが「Pending Customer Acceptance」または同等の値に変更された時刻を特定します。イベントタイプ inferred
	ベンダー対応の終了	外部ベンダーが対応を完了し、サービスリクエストが社内チームに戻された時点を示します。課題が「Waiting for vendor」から別の状態へ移行したことから推定します。
重要な理由ベンダー対応の期間を測定すると、ベンダーのパフォーマンスを管理し、外部関係者が全体の解決時間に与える影響を把握できます。入手先課題履歴から推定します。タイムスタンプは、課題のステータスが「vendor」状態から「In Progress」に戻った時刻です。取得「status」フィールドが「vendor」状態からアクティブな状態に戻った時刻を特定します。イベントタイプ inferred
	ベンダー対応の開始	サービスリクエストが外部ベンダーまたは第三者へエスカレーションされた、またはその対応が必要になったことを示します。通常は、課題が「Waiting for vendor」や「With Third Party」などのステータスに移行したことから推定します。
重要な理由ベンダー対応を追跡することは、社内のサービスデスクが直接管理できない外部依存関係や遅延を特定するうえで重要です。入手先課題履歴から推定します。タイムスタンプは、課題のステータスが指定された「vendor」ステータスに変更された時刻です。取得「status」フィールドが「Waiting for Vendor」などの値に変更された時刻を特定します。イベントタイプ inferred
	リクエストのトリアージ完了	サービスリクエストの初期評価を示します。ここで優先度、カテゴリー、影響度を決定します。通常は、「New」から「In Progress」への移行や、専用の「Triaged」ステータスへの変更など、ステータス変更から推定します。
重要な理由トリアージまでの時間を分析すると、リクエストの初期処理の効率を評価できます。ここでの遅延は、全体の解決時間やSLA遵守率に大きく影響する場合があります。入手先課題履歴から、初期状態の「New」または「Open」から「In Progress」などのアクティブな状態へ初めてステータスが変更された時刻を特定して推定します。取得プロジェクトのワークフローに基づき、「New」または同等の初期ステータスから最初に変更された時刻を特定します。イベントタイプ inferred
	リクエストの再オープン	一度解決したサービスリクエストが、再びアクティブな状態に戻ったことを記録します。解決済みまたはクローズ済みの状態から、オープンまたは対応中の状態へステータスが変更されたことから推定します。
重要な理由再オープンされたリクエストを追跡することは、解決品質と初回解決率を測定するうえで重要です。再オープン率が高い場合、解決策が不十分である、または問題が再発している可能性があります。入手先課題履歴から、「Resolved」または「Closed」カテゴリーのステータスが「Open」または「In Progress」カテゴリーのステータスへ移行したことを特定して推定します。取得「Done」ステータスカテゴリーから「To Do」または「In Progress」ステータスカテゴリーへの変更を確認します。イベントタイプ inferred
	情報の依頼	解決を進めるために、エージェントがリクエスト元に追加情報を求めた時点を示します。通常は、課題が「Waiting for customer」や「Pending Input」などのステータスに移行したことから推定します。
重要な理由「Information Requested」のサイクルが頻繁に発生したり長引いたりする場合、最初の申請内容が不明確である、またはコミュニケーションが非効率である可能性があります。これは大きな遅延要因になります。入手先課題履歴から推定します。タイムスタンプは、課題のステータスが「Waiting for customer」または同等のステータスに変更された時刻です。取得「status」フィールドが、顧客からの回答待ちを示す値に変更された時刻を特定します。イベントタイプ inferred
	情報の提供	リクエスト元が必要な情報を返信し、エージェントが作業を再開できる状態になった時点で発生します。通常は、課題が「Waiting for customer」から別の状態へ移行したことから推定し、リクエスト元によるコメントの追加がきっかけになる場合があります。
重要な理由このアクティビティによって、顧客との依頼と回答のサイクルが完了します。情報の依頼から受領までの時間は、プロセスの待機時間を構成する重要な要素です。入手先課題履歴から推定します。タイムスタンプは、課題のステータスが「Waiting for customer」から「In Progress」に戻った時刻です。取得「status」フィールドが待機状態からアクティブな状態に戻った時刻を特定します。イベントタイプ inferred
	解決の確認	リクエスト元が提示された解決策を正式に受け入れた時点で発生します。通常は、「Resolved」ステータスへの自動移行がトリガーとなり、このステータス変更から推定します。
重要な理由この節目は解決策の有効性を確認するものであり、SLAの計測を停止するトリガーになります。顧客が修正内容を確認するまでの時間を測定できます。入手先課題履歴から推定します。タイムスタンプは、ステータスが「Pending Customer Acceptance」から「Resolved」または「Closed」に変更された時刻です。取得ステータスが「Pending Customer Acceptance」から「Resolved」または「Closed」に変更された時刻を特定します。イベントタイプ inferred
	解決策の実施	エージェントがサービスリクエストに対応するために必要な作業を実施した、または解決策を作成したことを示します。通常は、ステータスが「Pending Review」または直接「Resolved」に変更されたことから推定します。
重要な理由この節目は、解決に必要な中核作業が完了したことを示します。このアクティビティまでにかかる時間は、プロセスの中で主な価値を生み出す部分にあたることが多いです。入手先課題履歴から推定します。ステータスが「Resolved」、「Pending Acceptance」、または同様の終了前ステータスに変更された時刻に対応します。取得「status」フィールドが作業完了を示す値に変更された時刻を特定します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Jira Service Managementのインスタンスにログインし、メインメニューに移動します。
フィルターを選択し、続けて高度な課題検索を選択します。課題を検索する画面が開き、クエリを作成できます。
検索バーに、Queryセクションに記載されているJQL（Jira Query Language）クエリを入力し、分析対象のサービスリクエストを絞り込みます。必要に応じてプロジェクトキーと日付範囲を調整します。
検索ボタンをクリックしてクエリを実行します。返された課題の一覧を確認し、正しいデータセットであることを確認します。
検索結果ページの右上にあるエクスポートアイコン（外向き矢印の付いたボックスのようなアイコン）をクリックします。
ドロップダウンメニューからXMLを選択します。完全なイベントログの生成に必要な詳細な変更履歴が標準のCSVエクスポートには含まれないため、XMLを使う必要があります。
ダウンロードしたXMLファイルをローカルシステムに保存します。このファイルには、クエリに該当するすべての課題と、各課題のデータに埋め込まれた完全な変更履歴が含まれています。
エクスポートしたXMLはイベントログ形式ではないため、後処理が必要です。スクリプト（例：Python、Powershell、その他の言語）を使ってXMLファイルを解析します。
スクリプトでは、ファイル内の各課題を処理し、作成日時から「サービスリクエストの作成」イベントを作成します。次に各課題の変更履歴を解析し、必要なアクティビティに対応するstatusとassigneeのフィールド変更を特定します。特定した変更ごとに新しい行を生成します。
このデータをフラットな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プロジェクトの課題を表示およびエクスポートするための「Browse Projects」権限が必要です。
データ量：Jiraの標準UIによるエクスポートは、一度に1,000件までに制限されることがよくあります。クエリ結果がそれを超える場合は、エクスポートごとに日付範囲を狭め、データを小分けにしてエクスポートしてください。

a サンプルクエリ 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の本番データベースまたはレプリカデータベースへの直接の読み取り専用アクセスが必要です。標準のアプリケーションアクセスだけでは不十分です。また、ステータス、課題タイプ、カスタムフィールドの正確な名称を含め、対象のService Deskプロジェクトのワークフローを十分に理解している必要があります。
主要なクエリフィルター：正しいデータセットを対象にするよう、クエリを設定する必要があります。次の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データベースに対してこのクエリを直接実行すると、大きなリソースを消費し、ユーザーのアプリケーション性能に影響する可能性があります。読み取り専用レプリカデータベース、または利用の少ない時間帯に抽出を実行することを強く推奨します。

a サンプルクエリ 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アカウントにログインします。プロフィール設定で「Account settings」を選択し、「Security」タブに移動してAPIトークンを作成します。このトークンは認証に使用するため、安全にコピーして保管します。
カスタムフィールドIDを特定：「Request Type」や「SLA Due Date」など、多くのJira属性はカスタムフィールドです。「Settings」＞「Issues」＞「Custom fields」に移動してIDを確認します。目的のフィールドを検索し、三点リーダー「...」＞「View field information」をクリックします。IDはURL内に表示されます（例：customFieldId=10021）。スクリプト設定用に記録します。
Pythonスクリプトを設定：提供されたPythonスクリプトをテキストエディターで開きます。ファイル上部の設定変数に、JIRA_URL、JIRA_EMAIL、JIRA_API_TOKEN、サービスリクエストを選択するjql_query、前の手順で特定したCUSTOM_FIELD_IDSを入力します。
Jiraステータスをアクティビティにマッピング：スクリプトのSTATUS_ACTIVITY_MAP辞書を必ず確認します。Jira Service Managementの実際のワークフローに合わせてマッピングを更新してください。キーにはJiraステータスの正確な名称（例：Waiting for customer）を指定し、値にはイベントログで必要な対応アクティビティ名（例：Information Requested）を指定します。
抽出スクリプトを実行：ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動します。次のコマンドで実行します：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）：「Request Type」や「SLA Due Date」などのカスタムフィールドからデータを抽出するには、一意のシステムID（例：customfield_10021）を指定する必要があります。属性に値を入れるには、これらを正しく設定してください。
日付範囲とパフォーマンス：初回の抽出では、処理しやすい3～6か月の日付範囲をJQLで指定することを推奨します。数年分のデータを抽出すると、APIのページネーションやレート制限により時間がかかる場合があります。

a サンプルクエリ 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エクスポート

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ sql

Jira Cloud REST APIを利用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

今すぐJiraのサービスリクエスト管理を最適化

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

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

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

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

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ sql

Jira Cloud REST APIを利用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

今すぐJiraのサービスリクエスト管理を最適化

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