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

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

Jira Service Management

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

このテンプレートでは、変更管理プロセスを分析するために必要なデータの収集方法を詳しく説明します。必須の属性、追跡すべき主要なアクティビティ、Jira Service Managementからデータを抽出するための手順をまとめています。このリソースを使って正確なイベントログを作成し、変更プロセスを詳しく把握してください。

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

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

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

変更管理の属性

以下は、変更管理プロセスを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	変更管理プロセス内で発生した特定の業務イベントまたはタスクの名称です。
説明この属性には、変更リクエストについて特定の時点で実施されたアクティビティの名称を記録します。Jira内のステータス遷移、ワークフローのステップ、特定のログエントリから導出されます。たとえば、「Change Submitted For Review」や「Implementation Started」などです。これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの中心です。実際のプロセスフローを発見し、ステップ間のボトルネックを特定し、標準業務手順に対するプロセスバリアントを分析できます。重要な理由プロセスのステップを定義するため、プロセスマップの作成、バリアントの分析、ボトルネックの特定に欠かせません。入手先通常はJiraの課題履歴から、ステータス遷移や、プロセスの節目を示すカスタムフィールドの更新をもとに導出します。例変更リクエスト承認リスク評価の実施変更実装完了実装後レビュー完了
	変更リクエストID ChangeRequestId	単一の変更リクエストケースを識別する一意の識別子です。作成からクローズまで、関連するすべてのアクティビティをまとめます。
説明変更リクエスト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のカスタムフィールドです。「Risk Level」や「Impact」などの名前が一般的です。例低中高重大
	優先度 Priority	変更リクエストに割り当てられた優先度です。業務上の重要度を示します。
説明優先度フィールドは、変更リクエストに対応する順序をチームが決める際に役立ちます。影響度と緊急度を組み合わせた指標であり、スケジュール設定やリソース配分の基準になります。優先度を分析すると、高優先度と低優先度の変更のパフォーマンスを比較できます。たとえば、高優先度の変更で本当にサイクルタイムが短いか、他の変更と同じボトルネックで滞留していないかを確認できます。リソースの重点配分や業務上の期待への対応に役立つ分析です。重要な理由業務上の優先度に基づいてプロセスパフォーマンスを分析できます。重要な変更が想定どおり迅速に処理されているかを確認できます。入手先 Jiraの課題に標準で用意されている`priority`フィールドです。例最重要高中低
	変更ステータス ChangeRequestStatus	イベント発生時点における変更リクエストの現在または過去のステータスです。
説明この属性は、変更リクエストのステータスを示します。例として、「承認待ち」、「進行中」、「クローズ」などがあります。Jiraのステータスフィールドはワークフローエンジンの基本要素であり、このフィールドの変更がプロセスフローを動かす主な要因になります。ステータスを分析すると、進行中の変更の進捗を追跡し、完了した変更の結果を把握できます。たとえば、「クローズ：成功」と「クローズ：失敗」を区別できます。スループットダッシュボードの作成や、ステータスが以前の状態に戻る手戻りループの分析にも欠かせません。重要な理由変更リクエストの進捗と最終結果を明確に把握できるため、スループットや手戻りの分析に役立ちます。入手先 Jiraの課題に標準で用意されている`status`フィールドです。利用可能なステータスは、プロジェクトのワークフロー設定で定義されます。例計画中承認待ち実装中クローズ済みキャンセル済み
	変更タイプ ChangeRequestType	変更の分類です。標準、通常、緊急などがあります。
説明変更タイプは、変更リクエストを性質、緊急度、影響度に基づいて分類します。一般的なタイプには、事前承認済みでリスクの低い変更を示す「標準」、完全な承認が必要な通常の変更を示す「通常」、インシデント対応を目的とした緊急の変更を示す「緊急」があります。変更タイプごとに異なるプロセス経路やSLAが設定されることが多いため、プロセス分析に欠かせない属性です。「緊急変更率」KPIの計算や、タイプごとのパフォーマンスとリスクを比較するダッシュボードのフィルタリングに使われます。重要な理由標準変更と緊急変更など、異なるワークフローを分けて分析できます。それぞれの変更に固有のパフォーマンス基準とリスクを把握できます。入手先通常、Jira Service Managementプロジェクトのカスタムフィールドです。フィールド名は異なる場合がありますが、「Change Type」と名付けられていることが多いです。例標準通常緊急
	担当者 Assignee	現在、変更リクエストへの対応を担当しているユーザーです。
説明担当者は、変更管理ワークフローの現在のステップまたはアクティビティを担当する個人ユーザーです。変更リクエストが異なる担当者やチームに引き継がれる過程で、担当者はライフサイクル中に何度も変わることがあります。この属性を使うと、作業量の分布を分析し、ユーザー単位のボトルネックを特定して、リソース配分を把握できます。「変更チームのアクティビティ作業量」ダッシュボードでは、このデータを使って、最も多くのアクティビティを処理している個人やグループを示します。重要な理由リソースのパフォーマンスと作業量の分布を分析し、個人またはチームのボトルネックを特定できます。入手先 Jiraの課題に標準で用意されている`assignee`フィールドです。例 Alice JohnsonBob WilliamsCharlie Brown
	目標完了日 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には個人を指定する「Assignee」フィールドがありますが、「Team」フィールドを使って、「ネットワーク運用」や「データベース管理者」などの機能グループに作業を割り当てることもよくあります。「変更チームのアクティビティ作業量」ダッシュボードに欠かせない属性です。個人単位だけでなくチーム単位でパフォーマンスとボトルネックを分析できるため、リソース計画や管理に役立ちます。重要な理由チームまたは部門単位で作業量とパフォーマンスを分析し、組織全体に関わるボトルネックを明らかにできます。入手先 Jiraには標準の「Team」フィールドがないため、通常はカスタムフィールドです。「Group Picker」タイプや単純な選択リストの場合があります。例インフラストラクチャチームコアサービスアプリケーションサポート
	報告者 Reporter	変更リクエストを最初に作成または提出したユーザーです。
説明報告者は、Jiraで変更リクエストの課題を作成した個人です。変更の所有者や、チームに代わって変更を開始したユーザーであることがよくあります。報告者を分析すると、どの部門、チーム、個人が最も多くの変更を開始しているかを把握できます。不完全または品質の低い変更リクエストを頻繁に提出するグループを特定し、フィードバックやトレーニングにつなげることもできます。重要な理由変更リクエストの発生元を特定し、初回提出の品質向上に役立てられます。入手先 Jiraの課題に標準で用意されている`reporter`フィールドです。例 David MillerEva GreenFrank Wright
	変更理由 ChangeReason	変更を提案する根拠または業務上の理由です。
説明この属性には、変更の背景にある理由が記録されます。例として、「新機能の実装」、「バグ修正」、「インフラストラクチャのアップグレード」などがあります。概要や説明だけでは分からない重要な背景を補足します。分析では、変更理由をサイクルタイム、失敗率、リスクレベルなどの指標と関連付けられます。たとえば、「バグ修正に関する変更は、新機能の実装より早く承認されるか」、「インフラストラクチャのアップグレードは失敗率が高いか」といった問いに答えられます。重要な理由変更の目的とパフォーマンスや結果を関連付け、より深い分析を行うための業務上の背景を提供します。入手先通常、Jira Service Managementのカスタムフィールドです。選択リストまたはテキストフィールドであることが多いです。例セキュリティパッチソフトウェアアップグレード新規ハードウェアの設置
	実装後の問題 PostImplementationIssue	実装後に、この変更に関連するインシデントまたは問題が発生したかを示すフラグです。
説明この属性は、変更によって本番環境のインシデントなどの悪影響が生じたかどうかを示します。通常、Jiraで変更リクエストの課題を1件以上のインシデント課題に関連付けて記録します。「実装後の問題率」や「変更失敗率」KPIの計算に欠かせないデータです。変更の品質、計画、テスト、リスク評価の有効性を直接測定できます。問題につながった変更を分析すると、統制の改善や将来の失敗防止に役立ちます。重要な理由変更後に運用上の問題が発生したかを追跡し、変更の品質と成功度を直接測定します。入手先通常、Jiraで関連課題を確認して導出します。具体的には、Change課題に対してIncident課題から「is caused by」リンクが設定されているかを確認します。例 truefalse
	手戻りの有無 IsRework	変更リクエストが手戻りループを経た場合にtrueとなるブール型フラグです。
説明この計算属性は、変更リクエストが修正のために以前の段階へ戻されたことを示します。たとえば、「承認待ち」から「計画中」に戻った場合です。初回提出が不完全または不正確だった、あるいは必要な基準を満たしていなかった可能性を示します。このフラグは、「変更手戻り率」KPIと「変更の手戻り・却下分析」ダッシュボードの基礎になります。手戻りが発生したケースを簡単に絞り込み、初期計画の不備、要件の不明確さ、リスク評価の不足などの根本原因を調査できます。重要な理由追加の予定外作業が必要になったケースを明示し、プロセスの非効率を把握できます。手戻りの根本原因も分析できます。入手先イベントログ内のアクティビティの順序を分析して計算します。後の段階のアクティビティの後に、前の段階のアクティビティが続いた場合に手戻りと判定します。例 truefalse
	業務サービス BusinessService	変更の影響を受ける業務サービスまたはアプリケーションです。
説明この属性は、変更リクエストを構成管理データベース（CMDB）で定義された特定の業務サービスに関連付けます。例として、「メールサービス」や「顧客CRM」などがあります。変更が業務に与える影響を把握するための重要な概念です。業務サービス別に変更を分析すると、対応の優先順位を決め、関係者に影響を伝えられます。どのサービスで変更が多いか、どのサービスのリスクが高いか、変更に関連するインシデントがどこに集中しているかを確認できます。技術的な変更を業務の観点から管理するうえで欠かせません。重要な理由技術的な変更を業務への影響に結び付け、影響を受けるサービスの重要度に基づいて優先順位付けとリスク分析を行えます。入手先 JSMのカスタムフィールドであることが多く、Jira Assets（旧Insight）や別のCMDBに関連付けられている場合があります。例企業ウェブサイトSAP ERP社内Wiki
	解決結果 Resolution	クローズした変更リクエストの最終結果であり、どのように解決されたかを示します。
説明変更リクエストをクローズすると、解決結果フィールドに具体的な結果が記録されます。たとえば、「完了」は成功を示し、「実施しない」や「重複」は別のクローズ理由を示します。「クローズ」ステータスだけの場合よりも、詳しい状況を把握できます。この属性は、変更の成功率と失敗率を分析するうえで欠かせません。たとえば、「実装後の問題率」KPIを分析する際に、「失敗」または「ロールバック済み」の解決結果を持つ変更に絞り込むと、結果をより正確に把握できます。承認後に正常に実装された変更と、キャンセルまたは却下された変更を区別できます。重要な理由変更の最終結果を詳しく把握できるため、成功率と失敗率を正確に計算できます。入手先 Jiraに標準で用意されている`resolution`フィールドです。通常、課題が「完了」ステータスカテゴリに移行した際に設定されます。例完了実施しない重複キャンセル済みロールバック済み

必須推奨任意

変更管理アクティビティ

変更管理プロセスを正確にディスカバリーするため、イベントログに取得すべき主要なプロセス手順とマイルストーンです。

5 推奨 8 任意

	アクティビティ	説明
	変更クローズ	変更リクエストに関連するすべてのアクティビティが完了し、最終的にクローズされたことを示します。Jiraの課題ステータスが「Closed」や「Done」などの最終解決状態に変わった時点から取得します。
重要な理由プロセスの主な終点です。全体のサイクルタイムの算出とSLA遵守状況の判定に使います。入手先 Jiraの課題履歴から、「status」フィールドが最終クローズ状態に変わった時点のタイムスタンプを特定して推定します。この時点でresolutionフィールドも設定されるのが一般的です。取得ステータスが「Closed」または「Done」に変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	変更リクエストが承認待ち	変更リクエストが初期レビューを通過し、Change Advisory Board（CAB）または指定された承認者による正式な判断を待っている状態を示します。ワークフローで「Pending Approval」や「Awaiting CAB」などにステータスが変わった時点から取得します。
重要な理由このアクティビティは、承認待ち時間の測定と意思決定段階のボトルネック特定に重要です。Change Approval Cycle Time KPIにも直接影響します。入手先 Jiraの課題履歴から、「status」フィールドが「Pending CAB Approval」や「Awaiting Approval」などの承認状態に変わった時点のタイムスタンプを特定して推定します。取得指定された「Awaiting Approval」ステータスに変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	変更リクエスト作成	Jira Service Managementで変更リクエストチケットが最初に作成されたことを示します。新しい「Change」タイプの課題が初めて保存された時点で、作成日時を持つイベントとして明示的に記録されます。
重要な理由すべての変更リクエストの開始点です。全体のリードタイムを測定し、時間の経過に伴う受信変更の量を分析するうえで欠かせません。入手先 Jiraの課題オブジェクトにある「created」タイムスタンプから取得します。すべての課題で利用できる標準システム項目であり、課題履歴またはAPIから取得できます。取得 Jiraの課題にある「created」フィールドのタイムスタンプを使用します。イベントタイプ explicit
	変更リクエスト承認	変更が正式に実装承認された重要な節目です。通常は、Jiraワークフローで「Approved」や「Ready for Implementation」などの状態に変わった時点から推定します。
重要な理由承認サイクルの終了と実装フェーズの開始を示します。承認サイクル時間の測定や、承認されていない変更の追跡に欠かせません。入手先 Jiraの課題履歴から、「status」フィールドが「Approved」状態に変わった時点のタイムスタンプを特定して推定します。取得ステータスが「Approved」または「Ready to Implement」に変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	変更実装完了	変更に伴う作業が完了したことを示す重要な節目です。Jiraワークフローで「Implemented」または「Pending Verification」などの状態に変わった時点から取得します。
重要な理由実装フェーズの終了を示し、実装リードタイムの算出に欠かせません。実装後レビューと検証の開始トリガーにもなります。入手先 Jiraの課題履歴から、「status」フィールドが「Implemented」または「Pending Post-Implementation Review」に変わった時点のタイムスタンプを特定して推定します。取得ステータスが「Implemented」などに変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	テスト実施	変更を検証する実装後テストが完了したことを示します。「In Testing」などの独立したステータスから取得するか、「Change Implemented」後にQAチームが記録したコメントや更新から推定します。
重要な理由テストの所要時間と結果を分析すると、実装の品質とテストプロセスの有効性を評価できます。実装後問題率の算出にも使う重要なデータです。入手先ステータスが「Testing」または「Under Test」に変わった時点から推定できます。また、実装後の課題履歴にあるコメントや担当者の変更を分析して特定することもできます。取得ステータスが「In Testing」に変わった時点、またはコメントから取得したタイムスタンプを記録します。イベントタイプ inferred
	リスク評価の実施	提案された変更について、リスクと影響の分析が完了したことを示します。通常は、「Risk Level」や「Impact」など、リスク関連のカスタムフィールドが入力または更新された時点を課題履歴から推定します。
重要な理由このアクティビティを分析すると、リスク評価の精度を確認し、変更ポリシーへのコンプライアンスを確保できます。「Risk Level」別の変更失敗率など、リスクベースのKPIを算出するうえでも欠かせません。入手先 Jiraの課題履歴から、「Risk Level」、「Impact」、「Urgency」などの特定フィールドが初めて設定または変更された時点のタイムスタンプを取得して推定します。取得「Risk Level」や「Impact」などのフィールドが初めて入力された時点のタイムスタンプを記録します。イベントタイプ inferred
	変更キャンセル	実装または完了の前に変更リクエストが終了したことを示します。Jiraの課題ステータスが「Canceled」または「Withdrawn」などの終了状態に変わった時点から取得します。
重要な理由プロセスのもう一つの終点です。変更が中止された理由を分析できます。キャンセル率が高い場合、初期計画の不備や事業上の優先順位の変化が考えられます。入手先 Jiraの課題履歴から、「status」フィールドが「Canceled」状態に変わり、対応するresolutionが設定された時点のタイムスタンプを特定して推定します。取得ステータスが「Canceled」または「Withdrawn」に変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	変更のスケジュール設定	承認された変更に具体的な実装時間帯が割り当てられたことを示します。Jiraの課題で「Planned start date」と「Planned end date」フィールドが入力または更新された時点から推定します。
重要な理由このアクティビティにより、変更の今後の計画を把握できます。リソース管理や、承認から実装予定までの時間の評価にも役立ちます。入手先 Jiraの課題履歴から、「Planned start date」や「Change window」などの日付フィールドが入力された時点のタイムスタンプを取得して推定します。取得「Planned start date」フィールドが入力された時点のタイムスタンプを記録します。イベントタイプ inferred
	変更リクエストをレビューに提出	変更リクエストの初期情報が揃い、正式に評価へ提出された時点を示します。通常は、Jiraワークフローのステータス変更、たとえば「Draft」から「Pending Review」への変更から推定します。
重要な理由このアクティビティが承認サイクルを開始します。この時点から承認までの時間を測定することは、承認サイクル時間のKPIを算出し、初期段階のボトルネックを特定するうえで重要です。入手先 Jiraの課題履歴から、「status」フィールドが「Pending Review」や「Awaiting Assessment」などのレビュー状態に変わった時点のタイムスタンプを特定して推定します。取得ステータスが「Pending Review」、「Submitted」などに変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	変更リクエスト却下	変更リクエストが正式に却下され、通常は依頼者に追加情報の提出を求めるか、リクエストを取り消すことを示します。Jiraワークフローでステータスが「Rejected」または「Needs More Info」に変わった時点から取得します。
重要な理由却下を追跡することは、変更やり直し率を分析するうえで重要です。このアクティビティの頻度が高い場合、変更申請の初期品質に問題がある可能性があります。入手先 Jiraの課題履歴から、「status」フィールドが「Rejected」などの終了状態に変わった時点のタイムスタンプを特定して推定します。取得ステータスが「Rejected」または「Declined」に変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	実装後レビュー完了	変更の成功を評価し、得られた教訓を特定する正式なレビューが完了したことを示します。通常は、ワークフローで「Post-Implementation Review」から「Verified」などに移った時点から取得します。
重要な理由このアクティビティはプロセス改善に欠かせません。レビューのサイクルタイムを測定することで、得られた教訓を速やかに記録できます。入手先 Jiraの課題履歴から、「status」フィールドが「Post-Implementation Review」状態から別の状態に移った時点のタイムスタンプを特定して推定します。取得ステータスが「PIR」から後続の状態に変わった時点のタイムスタンプを記録します。イベントタイプ inferred
	実装開始	承認された変更の技術的な実装が始まったことを示します。通常は、Jiraで「Approved」または「Scheduled」から「In Progress」または「Implementing」へステータスが変わった時点から取得します。
重要な理由このアクティビティを起点に平均実装リードタイムの測定を開始し、実行フェーズのボトルネックを特定できます。入手先 Jiraの課題履歴から、「status」フィールドが「In Progress」などの実装中の状態に変わった時点のタイムスタンプを特定して推定します。取得ステータスが「In Progress」または「Implementing」に変わった時点のタイムスタンプを記録します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Jiraの課題ナビゲーターにアクセス：Jira Service Managementのインスタンスにログインします。メインナビゲーションバーで「Issues」を選択し、「Search for issues」を選択して課題ナビゲーターを開きます。
JQL検索に切り替え：「Basic」検索モードを使用している場合は、「JQL」をクリックして詳細モードに切り替えます（バージョンによっては「Advanced」と表示されます）。これにより、カスタムのJira Query Language（JQL）クエリを入力できます。
変更リクエストを絞り込み：このドキュメントの「query」セクションに記載されたJQLクエリを検索バーに入力します。プロジェクトキー、変更用の課題タイプ名、対象期間のプレースホルダーを調整します。
検索を実行してデータをエクスポート：検索を実行します。変更リクエストの一覧が表示されたら、通常は右上にある「Export」ボタンを探します。「Export Excel CSV (all fields)」を選択します。この形式には、プロセスフローの再構築に必要な詳細な課題履歴が含まれるため、必ず使用してください。
変換用にCSVを読み込み：ダウンロードしたCSVファイルを、Power Query、pandasライブラリを使ったPythonスクリプト、その他のETLツールで開きます。生のエクスポートデータは課題ごとに1行ですが、履歴データを含む列があります。
基本データを構成：ソースファイルの各行について、最初の「Change Request Created」イベントを作成します。「Issue key」をChangeRequestIdとして使用し、ActivityNameを「Change Request Created」に設定します。EventTimeには「Created」列を使用します。
ステータス履歴をアンピボット：ステータス遷移履歴を含む列を特定します。ステータスの変更はそれぞれ1つのイベントです。変更リクエストごとに、関連するステータス遷移（「Draft」から「Pending Review」、「Pending Approval」から「Approved」など）1件につき1行を作成します。これらの遷移を、「Change Submitted For Review」、「Change Awaiting Approval」、「Change Request Approved」などの対応するActivityNameにマッピングします。ステータスが変更された時刻をEventTimeに設定します。
フィールド更新履歴をアンピボット：ステータス変更ではなく、フィールド更新から推定するアクティビティもあります。「Risk Level」、「Planned start date」、「Planned end date」などのフィールド履歴を処理します。これらのフィールドが初めて入力または更新された時刻を使い、「Risk Assessment Performed」と「Change Scheduled」イベントの行を作成します。
属性をマッピングして補完：作成した各イベント行に、対応するJiraフィールドをChangeRequestStatus、ChangeRequestType、Assignee、Priorityなどの必要な属性としてマッピングします。値には、イベント発生時点で有効だったものを使用します。
メタデータ列を追加：SourceSystemという列を追加し、固定値「Jira Service Management」を設定します。LastDataUpdateという列も追加し、抽出を実行した時刻を入力します。
派生指標を計算：イベントログ全体を作成した後、複数のデータポイントを必要とするApprovalCycleTimeなどの属性を計算します。各ChangeRequestIdについて、「Change Submitted For Review」イベントと「Change Request Approved」イベントの時間差を求めます。
仕上げてアップロード用にエクスポート：最終テーブルにChangeRequestId、ActivityName、EventTimeの必要な列が含まれていることを確認します。中間列やソース列を削除します。変換後のデータをUTF-8でエンコードしたCSVファイルとして保存し、プロセスマイニングツールにアップロードします。

設定

JQLフィルター：適切なデータセットを選択するための中心的な手段です。主なフィルターには、project、issuetype、およびcreatedフィールドによる対象期間の指定があります。
対象期間：パフォーマンスに影響を与えず、代表性のあるデータセットを確保するため、まずは3～6か月の期間から始めることを推奨します。例：created >= "-180d"。
課題タイプ：Jiraインスタンスで変更管理に使用している課題タイプの正確な名前を指定する必要があります。例：issuetype = "Change"またはissuetype = "Change Request"。
エクスポート形式：必ず「Export Excel CSV (all fields)」を使用します。このオプションを使うと、すべてのカスタムフィールドに加え、ステータスとフィールドの完全な変更履歴がエクスポートファイルに含まれます。限定されたフィールドのエクスポートでは、イベントログの作成に必要なデータが不足します。
Jiraの権限：エクスポートを実行するユーザーには、指定したプロジェクトの「Browse Projects」権限と、関連するすべての課題フィールドを表示するために必要な権限が必要です。
カスタムフィールドの特定：変換前に、Jiraインスタンスで「Risk Level」、「Planned start date」、「Change Type」などのプロセス属性に対応するカスタムフィールドの正確な名前を特定する必要があります。

a サンプルクエリ 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」です。
- ワークフローのステータス：「Pending Review」、「Pending Approval」、「In Progress」、「Closed」など、変更ワークフローで使用する各ステータスの名前です。
- カスタムフィールド名：「Change Type」、「Risk Level」、「Planned start date」、「Planned end date」に使用するカスタムフィールドの名前です。
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句にあるすべてのステータス名です。
対象期間を設定：最初のCommon Table Expression（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'文字列を慎重に確認し、更新してください。
カスタムフィールドのマッピング：クエリでは、特定のアクティビティ（「Risk Assessment Performed」、「Change Scheduled」）と属性を追跡するためにカスタムフィールド名を使用します。'[Your Risk Level Field Name]'などの名前がJiraの設定と一致することを確認し、更新してください。
対象期間：データ量とクエリのパフォーマンスを管理するため、まずは3～6か月程度の限定した期間（i.created >= '[YYYY-MM-DD]'）から始めることを強く推奨します。複数年分のデータを抽出すると、処理に時間がかかる場合があります。
パフォーマンス：課題数が数百万件に及ぶJiraインスタンスでは、クエリの実行がデータベースのパフォーマンスに影響する可能性があります。利用の少ない時間帯に実行してください。対象期間のフィルターを適用し、範囲を限定することも重要です。

a サンプルクエリ 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アカウントにログインします。プロフィール設定で「Account settings」を選択し、「Security」タブに移動して「Create and manage API tokens」をクリックします。新しいトークンを作成し、安全にコピーします。このトークンは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のステータス名（例：「Pending Approval」）とカスタムフィールド名（例：「Risk Level」）を、Jiraのワークフローで使用している正確な名前に更新する必要があります。Jiraのカスタムフィールド管理ページで、customfield_10050などのフィールドIDを確認します。
スクリプトを実行：ターミナルで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に指示し、多くのアクティビティの元データを取得できます。

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

ステップ

設定

a サンプルクエリ config

Jira Server／Data Centerのデータベースに対する直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

準備はできましたか？

変更管理を強化：今すぐ成功率95％を達成

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

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

変更管理の属性

変更管理アクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

Jira Server／Data Centerのデータベースに対する直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

準備はできましたか？

変更管理を強化：今すぐ成功率95％を達成

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