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

変更管理のデータテンプレート

Jira Service Management

変更管理の属性(19) 変更管理のアクティビティ(13) データ抽出ガイド(3)

変更管理のデータテンプレート

このテンプレートでは、変更管理プロセスの分析に必要なデータを収集する方法をご案内します。必要な属性や記録すべき主要なアクティビティに加え、Jira Service Managementからデータを抽出する手順も説明します。この資料を参考にイベントログを作成し、変更プロセスのインサイトを得てください。

収集を推奨する属性
プロセスで記録すべき主要なアクティビティ
Jira Service Managementからのデータ抽出手順

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

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

変更管理の属性

変更管理プロセスを詳しく分析するには、イベントログに次のデータ項目を含めることをお勧めします。

5 必須 7 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	変更管理プロセスで発生した特定の業務イベントまたはタスクの名称です。
説明この属性には、変更リクエストについて、特定の時点で発生したアクティビティの名称を記録します。アクティビティは、ステータスの移行、ワークフローのステップ、Jira内の特定のログ記録から取得します。例として、「変更リクエストのレビュー提出」や「実装の開始」があります。アクティビティの順序や発生頻度の分析は、プロセスマイニングの中核です。実際のプロセスの流れを明らかにし、ステップ間のボトルネックを特定するとともに、標準手順に対するプロセスのバリアントを分析できます。重要な理由プロセスの各ステップを定義する属性です。プロセスマップの作成、バリアントの分析、ボトルネックの特定に欠かせません。入手先通常はJiraの課題履歴から取得します。具体的には、ステータスの移行や、プロセスの節目を示すカスタムフィールドの更新を参照します。例変更リクエストの承認リスク評価の実施変更の実装実装後レビューの完了
	変更リクエストID ChangeRequestId	1件の変更リクエストケースを一意に識別し、作成からクローズまでの関連アクティビティをまとめる識別子です。
説明変更リクエストIDは、Jira Service Management内の各変更の取り組みを一意に識別する主キーです。プロセスマイニングではケース識別子として機能し、すべてのイベント、ステータス変更、更新を結び付けて、プロセスの開始から終了までを一貫して把握できるようにします。分析では、このIDを使って各変更の全過程を再構成できます。リスク評価、承認、実装、レビューなど、さまざまな段階で個々の変更を追跡するために欠かせません。特定の変更に関するイベントデータを正しく集計し、関連付けるために、すべての指標、重要業績評価指標（KPI）、ダッシュボードでこの属性を使用します。重要な理由変更リクエストの全過程を追跡し、実績を分析するための基本となるケース識別子です。入手先標準のJira課題キーです。変更リクエストタイプの課題にある`key`フィールドで確認できます。例 ITSM-1024CHG-2023-001CR-5921
	開始時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示す、正確なタイムスタンプです。
説明開始時刻、つまりイベントのタイムスタンプは、変更リクエストのアクティビティが記録された正確な日時を示します。作成からクローズまで、イベントログ内の各アクティビティにタイムスタンプが付与されます。この属性は、プロセスマイニングにおける時間ベースの分析全般に欠かせません。サイクルタイム、アクティビティ間の所要時間、待ち時間の算出や、イベントの順序の特定に使います。パフォーマンスの監視、SLA遵守状況の算出、ボトルネックの特定の基礎となります。重要な理由このタイムスタンプは、パフォーマンスや所要時間の分析の基礎となり、サイクルタイムの算出や遅延の特定を可能にします。入手先 Jiraの課題履歴ログにある各記録のタイムスタンプです。作成イベントの場合は、`created`フィールドの値を使います。例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	ソースシステム SourceSystem	変更管理データの抽出元となるシステムを示します。
説明この属性は、プロセスデータの取得元となるソースシステムを示します。この場合、値は常に「Jira Service Management」です。複数のシステムからデータを統合する企業全体の分析では、データの来歴の追跡、問題の調査、システムごとのプロセスの違いの把握に欠かせないフィールドです。分析対象データの出所を明確にできます。重要な理由データの出所を明確にします。複数のシステムのデータを統合する場合や、監査を行う場合に欠かせません。入手先データ抽出時にデータセットの出所を示すために追加する固定値です。例 Jira Service Management
	最終データ更新日時 LastDataUpdate	このレコードのデータが最後に更新または抽出された日時を示すタイムスタンプです。
説明この属性には、ソースシステムからデータを最後に取得した日時を記録します。プロセスマイニングツール内のデータがどの程度新しいかを示します。この属性を確認すると、プロセスデータがどの時点の情報かを把握できます。業務用ダッシュボードやリアルタイム監視では、特に重要です。分析の前提となる情報を示すため、古いデータに基づいて意思決定することを防げます。重要な理由データの新しさを示し、最新の情報に基づく適切な分析を支援します。入手先データの取得時に、データ抽出ツールが入力するメタデータフィールドです。例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	SLAステータス SLAStatus	変更リクエストが目標完了日までに完了したかどうかを示します。
説明この計算属性は、変更リクエストの実際の解決日と「目標完了日」を比較します。結果は「達成」または「未達」などの簡潔なステータスで示されます。「変更SLAパフォーマンスモニター」ダッシュボードで、パフォーマンスをひと目で確認できます。各ケースのステータスがあらかじめ算出されるため、「変更SLA遵守率」などの重要業績評価指標（KPI）も簡単に作成できます。変更の種類、チーム、サービスのうち、どれがSLA未達と最も多く関連しているかを絞り込み、集計できます。重要な理由各ケースのSLAパフォーマンスを達成・未達で明確に示し、SLA遵守状況の報告や分析を簡単にします。入手先最後の「変更クローズ」アクティビティのタイムスタンプと「TargetCompletionDate」属性を比較して算出します。例達成未達
	リスクレベル RiskLevel	変更に伴う評価済みのリスクレベルです。低、中、高などがあります。
説明リスクレベルは、ほとんどの変更管理プロセスで必須の評価項目です。変更によって生じる可能性のある悪影響を分類します。リスク評価の段階でレベルを決定し、その結果が必要な承認ワークフローに影響することもよくあります。プロセスマイニングでは、この属性がリスクに基づく分析の要となります。「リスク評価の精度と結果」ダッシュボードでは、初期リスクと実際の結果を関連付けて確認できます。また、「リスクレベル別変更失敗率」の重要業績評価指標（KPI）を分析する際の主な切り口となり、高リスクの変更が適切に管理されているかを評価できます。重要な理由リスクの種類ごとに、プロセス上の統制や承認ワークフローが有効に機能しているかを分析し、リスクと変更の失敗率の関係を把握できます。入手先通常、Jira Service Managementのカスタムフィールドです。「リスクレベル」や「影響」などの名前がよく使われます。例低中高重大
	優先度 Priority	変更リクエストに設定された優先度で、業務上の重要性を示します。
説明優先度フィールドを使うと、変更リクエストに対応する順序をチームで決められます。影響度と緊急度を組み合わせたもので、スケジュールやリソースの割り当てを判断する際の目安になります。優先度を分析すると、優先度の高い変更と低い変更のパフォーマンスを比較できます。たとえば、優先度の高い変更のサイクルタイムが実際に短いか、ほかの変更と同じボトルネックで滞留しているかを確認できます。リソースの配分を見直し、業務上の期待に応えるうえで役立ちます。重要な理由業務上の優先度に基づいてプロセスのパフォーマンスを分析し、重大な変更が想定どおり迅速に処理されているかを確認できます。入手先 Jira課題の標準の`priority`フィールドです。例最高高中低
	変更ステータス ChangeRequestStatus	イベント発生時点における、変更リクエストの現在または過去のステータスです。
説明この属性は、変更リクエストのステータスを示します。「承認待ち」「進行中」「クローズ」などが該当します。Jiraのステータスフィールドはワークフローエンジンの基本要素であり、このフィールドの変更がプロセスの流れを左右します。ステータスを分析すると、進行中の変更の進捗を追跡し、完了した変更の結果を把握できます。たとえば、「クローズ：成功」と「クローズ：失敗」を比較できます。また、処理件数を示すダッシュボードの作成や、ステータスが以前の状態に戻る手戻りループの分析にも欠かせません。重要な理由変更リクエストの進捗と最終結果を明確に把握でき、処理件数や手戻りの分析に役立ちます。入手先 Jira課題の標準の`status`フィールドです。利用できるステータスは、プロジェクトのワークフロー設定で定義されています。例計画中承認待ち実施中クローズキャンセル
	変更タイプ ChangeRequestType	変更の分類です。標準、通常、緊急などがあります。
説明変更タイプは、その性質、緊急度、影響に基づいて変更リクエストを分類します。一般的なタイプには、事前承認済みでリスクの低い「標準」、通常の変更で正式な承認が必要な「通常」、インシデント対応のために急いで行う「緊急」があります。変更タイプによって異なるプロセス経路をたどり、SLAも異なることが多いため、この属性はプロセス分析に欠かせません。「緊急変更率」の重要業績評価指標（KPI）の算出に使えるほか、ダッシュボードを絞り込んで、タイプごとのパフォーマンスやリスクを比較できます。重要な理由プロセスを分けて分析できるため、標準変更と緊急変更など、パフォーマンスの目標やリスクが異なるワークフローを比較できます。入手先通常、Jira Service Managementプロジェクトのカスタムフィールドです。フィールド名は異なる場合がありますが、「変更タイプ」と名付けられていることがよくあります。例標準通常緊急
	担当者 Assignee	変更リクエストへの対応を現在担当しているユーザーです。
説明担当者は、変更管理ワークフローの現在のステップまたはアクティビティを担当する個人ユーザーです。変更リクエストが複数の担当者やチームの間を移る過程で、担当者が何度も変わることがあります。この属性を使うと、作業負荷の分布を分析し、特定のユーザーに関するボトルネックを特定して、リソースの割り当て状況を把握できます。「変更チームのアクティビティ別作業負荷」ダッシュボードでは、このデータを基に、どの個人またはグループが最も多くのアクティビティを処理しているかを示します。重要な理由リソースパフォーマンスと作業負荷の分布を分析し、個人またはチームのボトルネックを特定できます。入手先 Jira課題の標準の`assignee`フィールドです。例アリス・ジョンソンボブ・ウィリアムズチャーリー・ブラウン
	目標完了日 TargetCompletionDate	変更リクエストの完了予定日、またはサービスレベル合意（SLA）に基づく期限です。
説明この属性には、SLAを満たすために変更リクエストを完了すべき日付が記録されます。実際の完了時間を測る際の基準となります。この日付は、合意した期限に対するパフォーマンスを監視するうえで欠かせません。「変更SLAパフォーマンスモニター」ダッシュボードと「変更SLA遵守率」の重要業績評価指標（KPI）の基礎となります。実際の解決日と目標日を比較することで、組織はサービス提供の有効性を測定できます。重要な理由 SLAの遵守状況を算出し、期限超過のリスクがある変更を特定するための主要なデータです。入手先 Jiraの`duedate`フィールド、またはJira Service Managementで設定したSLA指標の値が使われることがよくあります。例 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	チーム Team	変更リクエストまたは特定のアクティビティを担当するチームやグループです。
説明この属性は、変更作業を割り当てられたチームを示します。Jiraには個人を指定する「担当者」フィールドがありますが、「チーム」フィールドを使って「ネットワーク運用」や「データベース管理者」などの機能別グループに作業を割り当てることもよくあります。「変更チームのアクティビティ別作業負荷」ダッシュボードでは、この属性が重要です。個人単位だけでなくチーム単位でパフォーマンスやボトルネックを分析できるため、リソースの計画や管理に役立ちます。重要な理由チームや部門単位で作業負荷とパフォーマンスを分析し、組織的なボトルネックを把握できます。入手先 Jiraには標準の「チーム」フィールドがないため、通常はカスタムフィールドです。「グループピッカー」タイプや単純な選択リストの場合があります。例インフラストラクチャチームコアサービスアプリケーションサポート
	ビジネスサービス BusinessService	変更によって影響を受けるビジネスサービスまたはアプリケーションです。
説明この属性は、変更リクエストを構成管理データベース（CMDB）で定義された特定のビジネスサービスに関連付けます。「メールサービス」や「顧客CRM」などが該当します。変更が業務に与える影響を把握するうえで重要な情報です。ビジネスサービス別に変更を分析すると、取り組みの優先順位を決め、関係者に影響を伝えやすくなります。変更が最も多いサービス、リスクが最も高いサービス、変更に関連するインシデントが集中しているサービスを把握できます。技術的な変更を業務の視点から管理するために欠かせません。重要な理由技術的な変更と業務への影響を結び付け、対象サービスの重要度に基づいて優先順位付けやリスク分析を行えます。入手先 JSMのカスタムフィールドとして設定されることが多く、Jira Assets（旧Insight）や別のCMDBに関連付けられている場合があります。例企業ウェブサイトSAP ERP社内Wiki
	報告者 Reporter	変更リクエストを最初に作成または送信したユーザーです。
説明報告者は、Jiraで変更リクエストの課題を作成したユーザーです。変更の責任者や、チームに代わって変更を開始したユーザーが該当することがよくあります。報告者を分析すると、どの部門、チーム、個人が最も多く変更を開始しているかを特定できます。変更の発生元の傾向を把握し、不完全または品質の低い変更リクエストを頻繁に送信するグループに、フィードバックやトレーニングを提供する際にも役立ちます。重要な理由変更リクエストの発生元を特定し、最初の申請の品質向上に役立てられます。入手先 Jira課題の標準の`reporter`フィールドです。例デイビッド・ミラーエヴァ・グリーンフランク・ライト
	変更理由 ChangeReason	変更を提案する根拠または業務上の理由です。
説明この属性には、「新機能の実装」「バグ修正」「インフラストラクチャのアップグレード」など、変更の根本的な理由が記録されます。要約や説明だけでは分からない背景を把握できます。分析では、変更理由をサイクルタイム、失敗率、リスクレベルなどの指標と関連付けられます。たとえば、「バグ修正に関する変更は、新機能の実装より早く承認されるか」「インフラストラクチャのアップグレードは失敗率が高いか」といった疑問に答えられます。重要な理由変更の目的とパフォーマンス、結果を関連付けて分析するための業務上の背景を把握できます。入手先通常、Jira Service Managementのカスタムフィールドで、選択リストまたはテキストフィールドとして設定されます。例セキュリティパッチソフトウェアのアップグレード新しいハードウェアの設置
	実装後の問題 PostImplementationIssue	実装後にインシデントまたは問題がこの変更に関連付けられたかどうかを示すフラグです。
説明この属性は、変更によって本番環境のインシデントなどの悪影響が生じたかどうかを示します。通常、Jiraで変更リクエストの課題を1件以上のインシデント課題に関連付けて記録します。このデータは、「実装後の問題発生率」と「変更失敗率」の重要業績評価指標（KPI）の算出に欠かせません。変更の品質と、計画、テスト、リスク評価の有効性を直接測定できます。問題につながった変更を分析すると、統制の見直しや将来の失敗防止に役立ちます。重要な理由変更がその後の運用上の問題を引き起こしたかを追跡し、変更の品質と成否を直接測定できます。入手先通常、Jiraで関連付けられた課題を確認して判定します。具体的には、インシデント課題から変更課題に「原因となった」リンクが設定されているかを確認します。例 truefalse
	手戻りの有無 IsRework	変更リクエストで手戻りが発生した場合にtrueとなるブール値フラグです。
説明この計算属性は、変更や修正のために前の段階へ差し戻された変更リクエストを特定します。たとえば、「承認待ち」から「計画中」に戻った場合が該当します。最初の申請が不完全または不正確だった、あるいは必要な基準を満たしていなかったことを示します。このフラグは、「変更手戻り率」の重要業績評価指標（KPI）と「変更の手戻りと却下の分析」ダッシュボードの基礎となります。手戻りが発生したケースに絞って、初期計画の不備、要件の不明確さ、リスク評価の不足など、根本原因を調査できます。重要な理由予定外の追加作業が必要になったケースを明示し、プロセスの非効率な部分や手戻りの根本原因を分析できます。入手先イベントログ内のアクティビティの順序を分析して算出します。後の段階のアクティビティの後に、前の段階のアクティビティが続く場合、手戻りと判定します。例 truefalse
	解決状況 Resolution	クローズした変更リクエストの最終結果で、どのように解決されたかを示します。
説明変更リクエストをクローズすると、解決状況フィールドに結果の詳細が記録されます。たとえば、「完了」は成功を示し、「実施しない」や「重複」は別のクローズ理由を示します。これにより、「クローズ」というステータスだけの場合よりも詳しい状況を把握できます。この属性は、変更の成功率と失敗率を分析するうえで欠かせません。たとえば、「実装後の問題発生率」の重要業績評価指標（KPI）は、解決状況が「失敗」または「ロールバック」の変更に絞ると、より詳しく分析できます。承認後にキャンセルまたは却下された変更と、正常に実装された変更を区別するのにも役立ちます。重要な理由変更の最終結果を詳しく把握できるため、成功率と失敗率を正確に算出できます。入手先 Jiraの標準の`resolution`フィールドです。通常、課題が「完了」ステータスカテゴリに移ると設定されます。例完了実施しない重複キャンセルロールバック

必須推奨任意

変更管理のアクティビティ

変更管理プロセスを正確に把握するため、イベントログに記録すべき主要なステップとマイルストーンです。

5 推奨 8 任意

	アクティビティ	説明
	変更のクローズ	変更リクエストが最終的にクローズされ、関連するすべてのアクティビティが完了したことを示します。Jiraの課題ステータスが「クローズ」や「完了」などの最終的な解決状態に変わった時点で取得します。
重要な理由プロセスの主な終了点です。全体のサイクルタイムの算出や、SLAの遵守状況の確認に使います。入手先 Jiraの課題履歴から、「status」フィールドが最終的なクローズ状態に変わったタイムスタンプを特定して推定します。この時点で通常、「resolution」フィールドも設定されます。記録ステータスが「クローズ」または「完了」に変わったタイムスタンプを記録します。イベントタイプ inferred
	変更の実装	変更に伴う作業が完了したことを示す重要な節目です。Jiraのワークフローでステータスが「実装済み」や「検証待ち」などに変わった時点で取得します。
重要な理由実装段階の終了を示し、実装リードタイムの算出に欠かせません。また、実装後レビューや検証を開始するきっかけにもなります。入手先 Jiraの課題履歴から、「status」フィールドが「実装済み」または「実装後レビュー待ち」に変わったタイムスタンプを特定して推定します。記録ステータスが「実装済み」などに変わったタイムスタンプを記録します。イベントタイプ inferred
	変更の承認待ち	変更リクエストが初期レビューを通過し、変更諮問委員会（CAB）または指定された承認者による正式な判断を待っている状態を示します。「承認待ち」や「CAB待ち」への移行など、ワークフローのステータス変更から取得します。
重要な理由このアクティビティは、承認待ち時間の測定や意思決定段階のボトルネックの特定に重要です。変更承認サイクルタイムの重要業績評価指標（KPI）にも直接影響します。入手先 Jiraの課題履歴から、「status」フィールドが「CAB承認待ち」や「承認待ち」などの承認状態に変わったタイムスタンプを特定して推定します。記録指定された「承認待ち」ステータスに変わったタイムスタンプを記録します。イベントタイプ inferred
	変更リクエストの作成	Jira Service Managementで変更リクエストのチケットが最初に作成されたことを示します。「変更」タイプの新しい課題が初めて保存された時点で、作成タイムスタンプが明示的に記録されます。
重要な理由すべての変更リクエストの開始点です。全体のリードタイムの測定や、時間の経過に伴う変更件数の分析に欠かせません。入手先 Jiraの課題オブジェクトにある「created」タイムスタンプから取得します。すべての課題で利用できる標準システムフィールドで、課題履歴またはAPIから取得できます。記録 Jiraの課題にある「created」フィールドのタイムスタンプを使用します。イベントタイプ explicit
	変更リクエストの承認	変更の実装が正式に承認されたことを示す重要な節目です。通常は、Jiraのワークフローでステータスが「承認済み」や「実装準備完了」などに変わった時点から推定します。
重要な理由このイベントは承認サイクルの終了と実装段階の開始を示します。承認サイクルタイムの測定や未承認の変更の追跡に欠かせません。入手先 Jiraの課題履歴から、「status」フィールドが「承認済み」状態に変わったタイムスタンプを特定して推定します。記録ステータスが「承認済み」または「実装準備完了」に変わったタイムスタンプを記録します。イベントタイプ inferred
	テストの実施	変更を検証するための実装後テストが完了したことを示します。「テスト中」などの独立したステータスで記録される場合や、「変更の実装」後に品質保証（QA）チームが追加したコメントや更新から推定する場合があります。
重要な理由テストの所要時間と結果を分析すると、実装の品質やテストプロセスの有効性を評価できます。実装後の問題発生率を算出する際の重要なデータです。入手先ステータスが「テスト中」または「テスト実施中」に変わった時点から推定できます。また、実装後の課題履歴にあるコメントや担当者の変更を分析して推定することもできます。記録ステータスが「テスト中」に変わったタイムスタンプ、またはコメントのタイムスタンプを記録します。イベントタイプ inferred
	リスク評価の実施	提案された変更のリスクと影響の分析が完了したことを示します。「リスクレベル」や「影響」など、リスク関連のカスタムフィールドが入力または更新された時点を、課題履歴から推定することがよくあります。
重要な理由このアクティビティを分析すると、リスク評価の精度を確認し、変更ポリシーへの準拠を確かめられます。「リスクレベル別の変更失敗率」など、リスクに基づく重要業績評価指標（KPI）の算出にも欠かせません。入手先 Jiraの課題履歴から、「リスクレベル」「影響」「緊急度」などのフィールドが初めて設定または変更されたタイムスタンプを取得して推定します。記録「リスクレベル」や「影響」などのフィールドに初めて値が入力されたタイムスタンプを記録します。イベントタイプ inferred
	変更のキャンセル	変更リクエストが実装または完了前に終了したことを示します。Jiraの課題ステータスが「キャンセル」や「取り下げ」などの終了状態に変わった時点で取得します。
重要な理由この別の終了点を分析すると、変更が中止された理由を把握できます。キャンセル率が高い場合、初期計画の不備や事業上の優先順位の変化が考えられます。入手先 Jiraの課題履歴から、「status」フィールドが「キャンセル」状態に変わり、対応する解決状況が設定されたタイムスタンプを特定して推定します。記録ステータスが「キャンセル」または「取り下げ」に変わったタイムスタンプを記録します。イベントタイプ inferred
	変更のスケジュール設定	承認済みの変更に具体的な実装期間が割り当てられたことを示します。Jiraの課題にある「予定開始日」や「予定終了日」フィールドへの入力または更新から推定します。
重要な理由このアクティビティにより、変更の今後の計画を把握できます。リソース管理や、承認から実装予定日までの期間の評価に役立ちます。入手先 Jiraの課題履歴から、「予定開始日」や「変更期間」などの日付フィールドが入力されたタイムスタンプを取得して推定します。記録「予定開始日」フィールドに値が入力されたタイムスタンプを記録します。イベントタイプ inferred
	変更リクエストのレビュー提出	変更リクエストに必要な初期情報がそろい、正式に評価へ提出された時点を示します。通常は、Jiraのワークフローで「下書き」から「レビュー待ち」へ移るなど、ステータスの変更から推定します。
重要な理由このアクティビティを起点に承認サイクルが始まります。この時点から承認までの時間を測定することは、承認サイクルタイムの重要業績評価指標（KPI）の算出や、初期段階のボトルネックの特定に欠かせません。入手先 Jiraの課題履歴から、「status」フィールドが「レビュー待ち」や「評価待ち」などのレビュー状態に変わったタイムスタンプを特定して推定します。記録ステータスが「レビュー待ち」「提出済み」などに変わったタイムスタンプを記録します。イベントタイプ inferred
	変更リクエストの却下	変更リクエストが正式に却下されたことを示します。通常は、追加情報を求めて申請者に差し戻すか、リクエストを取り消します。Jiraのワークフローでステータスが「却下」や「追加情報が必要」に変わった時点から取得します。
重要な理由却下を追跡することは、変更の手戻り率を分析するうえで重要です。このアクティビティが頻繁に発生する場合、変更申請の初期品質に問題がある可能性があります。入手先 Jiraの課題履歴から、「status」フィールドが「却下」などの終了状態に変わったタイムスタンプを特定して推定します。記録ステータスが「却下」または「否認」に変わったタイムスタンプを記録します。イベントタイプ inferred
	実装の開始	承認済みの変更に関する技術的な実装の開始を示します。通常は、Jiraのステータスが「承認済み」または「スケジュール済み」から「進行中」または「実装中」に変わった時点で取得します。
重要な理由このアクティビティを起点に、平均実装リードタイムを測定します。実行段階のボトルネックの特定にも役立ちます。入手先 Jiraの課題履歴から、「status」フィールドが「進行中」などの実装中の状態に変わったタイムスタンプを特定して推定します。記録ステータスが「進行中」または「実装中」に変わったタイムスタンプを記録します。イベントタイプ inferred
	実装後レビューの完了	変更の成否を評価し、得られた教訓を特定する正式なレビューが完了したことを示します。通常は、ワークフローで「実装後レビュー」から「検証済み」へ移るなど、ステータスの変更から取得します。
重要な理由このアクティビティはプロセス改善に欠かせません。レビューのサイクルタイムを測定すると、学びを速やかに記録できているかを確認できます。入手先 Jiraの課題履歴から、「status」フィールドが「実装後レビュー」状態を抜けたタイムスタンプを特定して推定します。記録「PIR」から次の状態に変わったタイムスタンプを記録します。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

Jiraの課題ナビゲーターを開く：Jira Service Managementのインスタンスにログインします。メインナビゲーションで「課題」を選択し、「課題を検索」をクリックして課題ナビゲーターを開きます。
JQL検索に切り替える：「基本」検索モードを使用している場合は、「JQL」（バージョンによっては「詳細」）をクリックして詳細モードに切り替えます。これにより、カスタムのJira Query Language（JQL）クエリを入力できます。
変更リクエストを絞り込む：この文書の「query」セクションに記載されたJQLクエリを検索バーに入力します。プロジェクトキー、変更の課題タイプ名、対象の日付範囲を表すプレースホルダーを適宜置き換えてください。
検索してデータをエクスポートする：検索を実行します。変更リクエストの課題一覧が表示されたら、通常は右上にある「エクスポート」ボタンを選択し、「Excel CSV（すべてのフィールド）」を選びます。この形式には、プロセスフローの再構築に必要な詳細な課題履歴が含まれます。
CSVを変換用に読み込む：ダウンロードしたCSVファイルを、Power Query、pandasライブラリを使ったPythonスクリプト、その他のETLツールで開きます。エクスポートしたデータは課題ごとに1行ですが、履歴データを含む列があります。
基本データを作成する：ソースファイルの各行について、最初の「変更リクエスト作成」イベントを作成します。「課題キー」をChangeRequestIdに設定し、ActivityNameを「変更リクエスト作成」とし、「作成日」列をEventTimeに設定します。
ステータス履歴を行に展開する：ステータス遷移履歴を含む列を特定します。ステータスの変更はそれぞれイベントです。各変更リクエストについて、該当するステータス遷移ごとに行を作成します（例：「下書き」から「レビュー待ち」、「承認待ち」から「承認済み」）。遷移を「変更レビュー申請」「変更承認待ち」「変更リクエスト承認」などの対応するActivityNameに割り当てます。ステータス変更のタイムスタンプをEventTimeに設定します。
フィールド更新履歴を行に展開する：ステータス変更ではなく、フィールドの更新から推定するアクティビティもあります。「リスクレベル」「計画開始日」「計画終了日」などのフィールド履歴を処理します。これらのフィールドが初めて入力または更新された時刻を使い、「リスク評価実施」や「変更予定設定」イベントの行を作成します。
属性を割り当てて補完する：作成した各イベント行に、対応するJiraフィールドを割り当てます。必要な属性にはChangeRequestStatus、ChangeRequestType、Assignee、Priorityなどがあります。値には、イベント発生時点で有効だったものを設定します。
メタデータ列を追加する：SourceSystemという列を追加し、値を「Jira Service Management」に固定します。さらにLastDataUpdate列を追加し、データを抽出した時刻を設定します。
派生指標を計算する：イベントログ全体を作成した後、ApprovalCycleTimeなど、複数のデータポイントを必要とする属性を計算します。各ChangeRequestIdについて、「変更レビュー申請」イベントから「変更リクエスト承認」イベントまでの時間差を求めます。
仕上げてアップロード用にエクスポートする：最終テーブルにChangeRequestId、ActivityName、EventTimeの各列が含まれていることを確認します。中間列やソース列を削除し、変換後のデータをUTF-8形式のCSVファイルとして保存して、プロセスマイニングツールにアップロードします。

設定

JQLフィルター：適切なデータセットを選ぶには、JQLクエリが基本となります。主なフィルターはproject、issuetype、および抽出範囲を指定するcreatedフィールドの日付範囲です。
日付範囲：代表性のあるデータを確保しつつ、パフォーマンスへの影響を抑えるため、まずは3～6か月分のデータを対象にすることをお勧めします。例：created >= "-180d"。
課題タイプ：Jiraインスタンスで変更管理に使用している課題タイプの正確な名前を指定してください。例：issuetype = "Change"またはissuetype = "Change Request"。
エクスポート形式：必ず「Excel CSV（すべてのフィールド）」を使用してください。この形式では、すべてのカスタムフィールドに加え、ステータスとフィールドの完全な変更履歴がエクスポートファイルに含まれます。フィールドを限定してエクスポートすると、イベントログの作成に必要なデータが不足します。
Jiraの権限：エクスポートを実行するユーザーには、指定したプロジェクトの「プロジェクトの閲覧」権限と、関連する課題フィールドを閲覧するために必要な権限が必要です。
カスタムフィールドの特定：データを変換する前に、「リスクレベル」「計画開始日」「変更タイプ」などのプロセス属性に対応するカスタムフィールドの正確な名前をJiraインスタンスで確認してください。

クエリの例 config

project = "[Your_Project_Key]" AND issuetype = "Change" AND created >= "[Start_Date_YYYY-MM-DD]" AND created <= "[End_Date_YYYY-MM-DD]" ORDER BY created ASC

ステップ

データベースに接続する：Jira ServerまたはData Centerの基盤データベース（PostgreSQL、MySQL、SQL Server、Oracleなど）への読み取り専用アクセス情報を取得します。DBeaver、SQL Developer、pgAdminなどの標準的なSQLクライアントでデータベースに接続します。
Jiraの設定を確認する：クエリを実行する前に、Jira Service Managementの設定で使用している名称を確認します。Jiraにログインして変更管理プロジェクトを開き、次の情報を控えてください。
- プロジェクトキー：プロジェクトを識別する短い文字列です。例：「CSM」。
- 課題タイプ名：変更リクエストに使用する正確な名前です。通常は「Change」です。
- ワークフローのステータス：「レビュー待ち」「承認待ち」「進行中」「クローズ」など、変更ワークフローで使用する各ステータス名です。
- カスタムフィールド名：「変更タイプ」「リスクレベル」「計画開始日」「計画終了日」に使用するカスタムフィールド名です。
SQLクエリをカスタマイズする：SQLクライアントで、提示されたSQLクエリを開きます。前の手順で確認した情報に合わせてプレースホルダーを置き換えてください。主な置換対象は[Your_JSM_Project_Key]、[Your Change Type Field Name]、[Your Risk Level Field Name]、[Your Planned Start Date Field Name]、[Your Planned End Date Field Name]、およびWHERE句にあるすべてのステータス名です。
日付範囲を設定する：最初の共通テーブル式（CTE）にあるAND i.created >= '[YYYY-MM-DD]'の行を探し、データ抽出の開始日を指定します。データ量を抑え、クエリのパフォーマンスを高めるために必要な設定です。
クエリを実行する：変更したSQLクエリをJiraデータベースに対して実行します。Jiraインスタンスの規模や指定した日付範囲によっては、完了まで数分かかることがあります。
結果を確認する：クエリの実行後、SQLクライアントで出力を簡単に確認します。行が返されていることと、ChangeRequestId、ActivityName、EventTimeなどの列に想定どおり値が入っていることを確かめてください。
データをCSVにエクスポートする：SQLクライアントから結果セット全体をCSVファイルにエクスポートします。列見出しを含め、区切り文字にカンマを使用し、UTF-8でエンコードするよう設定してください。
アップロードの準備をする：jira_change_management_log.csvのように、内容が分かる名前を付けます。このファイルをプロセスマイニングツールにアップロードして分析できます。

設定

データベースへのアクセス：Jira本番データベースへの読み取り専用ユーザーアカウントが必要です。データベースへの直接アクセスはJira ServerとJira Data Centerでのみ可能で、Jira Cloudでは利用できません。
Jiraプロジェクトキー：クエリにJira Service Managementプロジェクト固有のキーを設定する必要があります。p.pkey IN ('[Your_JSM_Project_Key]')句で指定します。
変更の課題タイプ：このクエリでは、変更リクエストの課題タイプ名を「Change」と想定しています。異なる名前を使用している場合は、issuetype.pname = 'Change'フィルターを更新してください。
ワークフローのステータス割り当て：イベントログの正確性は、クエリのWHERE句にあるステータス名を、プロジェクトで実際に使用しているワークフローのステータスに正しく対応付けられるかどうかに左右されます。各'Status Name'の文字列を確認し、必要に応じて更新してください。
カスタムフィールドの割り当て：このクエリでは、特定のアクティビティ（「リスク評価実施」「変更予定設定」）と属性の追跡にカスタムフィールド名を使用します。'[Your Risk Level Field Name]'などの名前がJiraの設定と一致することを確認し、必要に応じて更新してください。
日付範囲：データ量とクエリのパフォーマンスを適切に保つため、まずは3～6か月など、限定した日付範囲（i.created >= '[YYYY-MM-DD]'）を指定することを強くお勧めします。数年分のデータを抽出すると、処理にかなり時間がかかる場合があります。
パフォーマンス：課題が数百万件あるJiraインスタンスでは、このクエリの実行がデータベースのパフォーマンスに影響する可能性があります。利用の少ない時間帯に実行し、日付範囲フィルターを適用して対象を絞ってください。

クエリの例 sql

WITH ChangeRequestAttributes AS (
    SELECT
        i.id AS issueid,
        i.pkey AS ChangeRequestId,
        i.created,
        i.duedate AS TargetCompletionDate,
        istat.pname AS ChangeRequestStatus,
        u.display_name AS Assignee,
        prio.pname AS Priority,
        ct.customvalue AS ChangeRequestType,
        rl.customvalue AS RiskLevel
    FROM
        jiraissue i
    JOIN
        project p ON i.project = p.id
    LEFT JOIN
        issuestatus istat ON i.issuestatus = istat.id
    LEFT JOIN
        priority prio ON i.priority = prio.id
    LEFT JOIN
        app_user au ON i.assignee = au.user_key
    LEFT JOIN
        cwd_user u ON au.lower_user_name = u.lower_user_name
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Change Type Field Name]'
    ) ct ON i.id = ct.issue
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Risk Level Field Name]'
    ) rl ON i.id = rl.issue
    WHERE
        p.pkey IN ('[Your_JSM_Project_Key]')
        AND i.issuetype = (SELECT id FROM issuetype WHERE pname = 'Change')
        AND i.created >= '[YYYY-MM-DD]'
)
-- 1. Change Request Created
SELECT
    cra.ChangeRequestId,
    'Change Request Created' AS ActivityName,
    cra.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    ChangeRequestAttributes cra

UNION ALL

-- All subsequent events from issue history
SELECT
    cra.ChangeRequestId,
    CASE 
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Review' THEN 'Change Submitted For Review'
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Approval' THEN 'Change Awaiting Approval'
        WHEN ci.field = 'status' AND ci.newstring = 'Approved' THEN 'Change Request Approved'
        WHEN ci.field = 'status' AND ci.newstring = 'Rejected' THEN 'Change Request Rejected'
        WHEN ci.field = 'status' AND ci.newstring = 'In Progress' THEN 'Implementation Started'
        WHEN ci.field = 'status' AND ci.newstring = 'Implemented' THEN 'Change Implemented'
        WHEN ci.field = 'status' AND ci.newstring = 'In Testing' THEN 'Testing Performed'
        WHEN ci.field = 'status' AND ci.newstring = 'Verified' AND ci.oldstring = 'Post-Implementation Review' THEN 'Post-Implementation Review Done'
        WHEN ci.field = 'status' AND ci.newstring = 'Closed' THEN 'Change Closed'
        WHEN ci.field = 'status' AND ci.newstring = 'Canceled' THEN 'Change Canceled'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]') AND ci.oldvalue IS NULL THEN 'Risk Assessment Performed'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]') AND ci.oldvalue IS NULL THEN 'Change Scheduled'
    END AS ActivityName,
    cg.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    changegroup cg
JOIN
    changeitem ci ON cg.id = ci.groupid
JOIN
    ChangeRequestAttributes cra ON cg.issueid = cra.issueid
WHERE
    (
        ci.fieldtype = 'jira' AND ci.field = 'status' AND ci.newstring IN (
            'Pending Review', 'Pending Approval', 'Approved', 'Rejected', 
            'In Progress', 'Implemented', 'In Testing', 'Verified', 'Closed', 'Canceled'
        )
    )
    OR
    (
        ci.fieldtype = 'custom' AND ci.fieldid IN (
            (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]'),
            (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]')
        ) AND ci.oldvalue IS NULL
    )
ORDER BY
    ChangeRequestId, EventTime;

ステップ

Python環境を準備する：Python 3.6以降がインストールされていることを確認します。API呼び出し用のrequestsとデータ操作用のpandasを、次のコマンドでインストールします：pip install requests pandas。
Jira APIトークンを作成する：Jiraアカウントにログインします。プロフィール設定から「アカウント設定」を選択し、「セキュリティ」タブを開いて「APIトークンの作成と管理」をクリックします。新しいトークンを作成し、安全に保管してください。このトークンはAPI認証時にパスワードとして使用します。
Pythonスクリプトを設定する：提示されたPythonスクリプトをエディターで開きます。JIRA_URL、JIRA_EMAIL、JIRA_API_TOKENのプレースホルダーを、JiraインスタンスのURL、メールアドレス、作成したAPIトークンに置き換えてください。
JQLクエリをカスタマイズする：スクリプトのJQL_QUERY変数を変更し、対象のJira Service Managementプロジェクトと課題タイプを指定します。たとえば、project = "CSM"をプロジェクトキーに置き換えます。データ抽出期間を絞る日付範囲も調整し、パフォーマンスを高めてください。
カスタムフィールドとステータスを割り当てる：スクリプト内のSTATUS_TO_ACTIVITY_MAPPINGとFIELD_TO_ACTIVITY_MAPPINGの辞書を確認します。Jiraのステータス名（例：「承認待ち」）とカスタムフィールド名（例：「リスクレベル」）を、ワークフローで実際に使用している正確な名称に合わせて更新してください。customfield_10050などのフィールドIDは、Jiraのカスタムフィールド管理ページで確認できます。
スクリプトを実行する：ターミナルでpython your_script_name.pyを実行します。スクリプトがJira APIに接続し、変更リクエストの課題とその履歴を取得・処理します。
スクリプトの実行状況を確認する：取得・処理した課題数などの進捗がコンソールに表示されます。データセットが大きい場合は、完了までにかなり時間がかかることがあります。
出力を確認する：スクリプトが完了すると、同じディレクトリにjira_change_management_event_log.csvというCSVファイルが作成されます。このファイルには抽出したイベントログが含まれます。
アップロードの準備をする：CSVファイルを表計算アプリケーションで開き、ChangeRequestId、ActivityName、EventTimeなどの列が正しく構成されていることを確認します。このファイルをプロセスマイニングツールにアップロードできます。

設定

JQLクエリ：抽出対象を絞り込む主な条件はJQL_QUERY変数です。最低限、project、issuetype = 'Change'、およびcreatedフィールドの日付範囲（例：過去180日間ならcreated >= -180d）を指定してください。データ量を抑えるには、日付範囲の指定が欠かせません。
ステータスとフィールドの割り当て：スクリプトの正確性は、STATUS_TO_ACTIVITY_MAPPINGとFIELD_TO_ACTIVITY_MAPPINGの辞書の設定に左右されます。正しいアクティビティを作成できるよう、組織のJiraワークフローのステータスとカスタムフィールド名に正確に合わせてください。
API認証情報：認証には有効なJIRA_URL、JIRA_EMAIL、JIRA_API_TOKENが必要です。トークンに紐づくユーザーには、指定したプロジェクトと関連フィールドの読み取り権限が必要です。
データのページネーション：スクリプトはmaxResultsパラメーター（値は100）を使い、APIから課題をバッチ単位、つまりページごとに取得します。タイムアウトを避けながら大量の課題を確実に抽出するために必要です。
変更履歴の取得：APIリクエストのexpand=changelogパラメーターは重要です。各課題のすべてのフィールド変更履歴をJiraに含めるよう指定し、多くのアクティビティの元データを取得します。

クエリの例 python

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

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
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 = class="hl-string">"[your_jira_api_token]"

class=class="hl-string">"hl-comment"># JQL to select Change Management issues. Itclass="hl-string">'s recommended to add a date filter, e.g., 'AND created >= -180d'
JQL_QUERY = class="hl-string">'project = "CSM" AND issuetype = "Change" ORDER BY created DESC'

class=class="hl-string">"hl-comment"># --- Mappings - CRITICAL: Customize these to match your Jira workflow --- #
class=class="hl-string">"hl-comment"># Map Jira status names to standardized Activity Names
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Pending Review': class="hl-string">'Change Submitted For Review',
    class="hl-string">'Pending Approval': class="hl-string">'Change Awaiting Approval',
    class="hl-string">'Approved': class="hl-string">'Change Request Approved',
    class="hl-string">'Rejected': class="hl-string">'Change Request Rejected',
    class="hl-string">'In Progress': class="hl-string">'Implementation Started',
    class="hl-string">'Implemented': class="hl-string">'Change Implemented',
    class="hl-string">'Post-Implementation Review': class="hl-string">'Post-Implementation Review Done',
    class="hl-string">'Closed': class="hl-string">'Change Closed',
    class="hl-string">'Canceled': class="hl-string">'Change Canceled',
    class=class="hl-string">"hl-comment"># Add other custom statuses from your workflow
}

class=class="hl-string">"hl-comment"># Map Jira field updates to standardized Activity Names
class=class="hl-string">"hl-comment"># Use field names as they appear in the API changelog. Custom fields might have different names.
FIELD_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Risk Level': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Planned start date': class="hl-string">'Change Scheduled',
    class="hl-string">'Testing Status': class="hl-string">'Testing Performed', class=class="hl-string">"hl-comment"># Example for a custom class="hl-string">'Testing Status' field
}
class=class="hl-string">"hl-comment"># --- End of Configuration --- #

def get_issues(auth):
    class="hl-string">"""Paginates through JQL results to fetch all issues."""
    all_issues = []
    start_at = 0
    max_results = 100

    while True:
        api_endpoint = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'fields': class="hl-string">'*all',
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_endpoint, auth=auth, params=params, headers={class="hl-string">'Accept': class="hl-string">'application/json'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an error for bad responses (4xx or 5xx)
            data = response.json()
            issues = data.get(class="hl-string">'issues', [])
            all_issues.extend(issues)

            print(fclass="hl-string">"Fetched {len(issues)} issues, total so far: {len(all_issues)}")

            if len(issues) < max_results:
                break class=class="hl-string">"hl-comment"># Exit loop if this is the last page
            start_at += len(issues)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching issues: {e}")
            break

    return all_issues

def parse_issues_to_event_log(issues):
    class="hl-string">"""Parses issues and their changelogs into a structured event log."""
    event_log = []
    source_system = class="hl-string">"Jira Service Management"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        
        class=class="hl-string">"hl-comment"># 1. Handle class="hl-string">'Change Request Created' event
        event_log.append({
            class="hl-string">'ChangeRequestId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': fields.get(class="hl-string">'created'),
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'ChangeRequestStatus': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
            class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
            class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
            class="hl-string">'ApprovalCycleTime': None, class=class="hl-string">"hl-comment"># Requires post-processing to calculate
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># Requires post-processing to calculate
        })

        class=class="hl-string">"hl-comment"># 2. Parse changelog for all other events
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        for history in changelog:
            event_time = history[class="hl-string">'created']
            for item in history.get(class="hl-string">'items', []):
                activity_name = None
                class=class="hl-string">"hl-comment"># Map status changes
                if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status':
                    activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'toString'))
                class=class="hl-string">"hl-comment"># Map field updates
                elif item.get(class="hl-string">'field') in FIELD_TO_ACTIVITY_MAPPING:
                    activity_name = FIELD_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'field'))

                if activity_name:
                    event_log.append({
                        class="hl-string">'ChangeRequestId': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'SourceSystem': source_system,
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'ChangeRequestStatus': item.get(class="hl-string">'toString') if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status' else fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
                        class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'),
                        class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
                        class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'),
                        class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                        class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
                        class="hl-string">'ApprovalCycleTime': None,
                        class="hl-string">'SLAStatus': None
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira data extraction...")
    jira_auth = (JIRA_EMAIL, JIRA_API_TOKEN)
    
    issues_data = get_issues(jira_auth)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues into an event log...")
        event_log_data = parse_issues_to_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        df_sorted = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'jira_change_management_event_log.csv'
        df_sorted.to_csv(output_filename, index=False)
        print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

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

このデータテンプレートを使って、変更管理のプロセスマイニングを始めましょう。生のデータを分析に役立つインサイトへと変える第一歩を、今日から踏み出せます。

改善ガイドに戻る

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

変更管理を改善し、成功率95％を目指しましょう

変更の失敗を減らし、成功率95％を目指しましょう。

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

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

変更管理のデータテンプレート

変更管理のデータテンプレート

変更管理の属性

変更管理のアクティビティ

データ抽出ガイド

Jira Service Managementの標準機能で課題をCSVにエクスポート

ステップ

設定

クエリの例 config

Jira Server／Data Centerのデータベースに直接接続してSQLクエリを実行

ステップ

設定

クエリの例 sql

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

ステップ

設定

クエリの例 python

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

変更管理を改善し、成功率95％を目指しましょう