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

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

Jira Service Management

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

このテンプレートは、変更管理プロセスを分析するために必要なデータを収集するための包括的なガイドを提供します。重要な属性、追跡すべき主要なアクティビティ、およびJira Service Managementからデータを抽出するための実用的なガイダンスを概説しています。このリソースを使用して、正確なイベントログを構築し、変更プロセスに関する深いインサイトを得てください。

収集を推奨する項目
`プロセス`で追跡すべき主要な活動
`Jira Service Management`からのデータ抽出ガイド

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

変更管理属性

これらは、変更管理プロセスの包括的な分析のためにイベントログに含めることを推奨するデータフィールドです。

5 必須 8 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	変更管理プロセス内で発生した特定のビジネスイベントまたはタスクの名前。
説明この属性は、変更リクエストに対して特定の時点で発生したアクティビティの名前を記録します。これらのアクティビティは、ステータス遷移、ワークフローステップ、またはJira内の特定のログエントリ（例：「レビューのために変更提出済み」や「実装開始」）から派生します。これらのアクティビティのシーケンスと頻度を分析することがプロセスマイニングの核となります。これにより、実際のプロセスフローの発見、ステップ間のボトルネックの特定、および標準運用手順に対するプロセスバリアントの分析が可能になります。その重要性プロセスのステップを定義し、プロセス全体の把握、バリアントの分析、ボトルネックの特定に不可欠です。取得元通常、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
	Assignee Assignee	現在、変更リクエストに対して行動する責任があるユーザー。
説明アサインeeは、変更管理ワークフローにおける現在のステップまたはアクティビティを担当する個々のユーザーです。アサインeeは、変更リクエストが異なる担当者やチーム間を移動するにつれて、ライフサイクルを通じて複数回変更される可能性があります。この属性は、ワークロードの分散を分析し、ユーザー固有のボトルネックを特定し、リソース割り当てを理解するために使用されます。「変更チームアクティビティワークロード」ダッシュボードは、どの個人またはグループが最も多くのアクティビティを処理しているかを示すためにこのデータに依存しています。その重要性これは、リソースのパフォーマンスとワークロードの分散を分析し、個人またはチームのボトルネックを特定するのに役立ちます。取得元これはJira課題の標準`assignee`フィールドです。例 Alice JohnsonBob WilliamsCharlie Brown
	SLAステータス SLAStatus	変更リクエストが目標完了日までに完了したかどうかを示します。
説明この計算属性は、変更リクエストの実際の解決日を「目標完了日」と比較するものです。結果は「達成」または「違反」などの単純なステータスで表示されます。これは、「変更SLAパフォーマンスモニター」ダッシュボードのパフォーマンスを明確に一目で示す指標を提供します。各ケースのステータスを事前に計算することで、「変更SLA遵守率」のようなKPIの作成を簡素化します。これにより、SLA違反に最も頻繁に関連する変更の種類、チーム、またはサービスを簡単にフィルタリングして集計することができます。その重要性各ケースのSLAパフォーマンスについて明確な二元的な結果を提供し、SLA遵守の報告と分析を簡素化します。取得元最終的な「Change Closed」アクティビティのタイムスタンプを「TargetCompletionDate」属性と比較して計算されます。例達成違反
	リスクレベル RiskLevel	変更に関連する評価されたリスクレベル（例：低、中、高）。
説明リスクレベルは、ほとんどの変更管理プロセスにおける必須の評価であり、変更の潜在的な負の影響を分類します。このレベルはリスク評価フェーズ中に決定され、多くの場合、必要な承認ワークフローに影響を与えます。プロセスマイニングでは、この属性はリスクベース分析にとって重要です。「リスク評価の正確性と結果」ダッシュボードをサポートし、初期リスクと実際の結果を相関させます。また、「リスクレベル別変更失敗率」KPIの主要なディメンションでもあり、高リスク変更が効果的に管理されているかを評価するのに役立ちます。その重要性プロセスの制御と承認ワークフローが異なるリスクプロファイルに対して効果的であるかどうかを分析でき、リスクと変更失敗率の相関関係を特定するのに役立ちます。取得元これは通常、Jira Service Managementのカスタムフィールドです。一般的な名前には「リスクレベル」や「影響」があります。例低中高クリティカル
	優先度 Priority	変更リクエストに割り当てられた優先度レベルで、ビジネス上の重要性を示します。
説明優先度フィールドは、チームが変更リクエストに対処する順序を決定するのに役立ちます。これは影響と緊急性の組み合わせを反映し、スケジューリングとリソース割り当てをガイドします。優先度を分析することで、高優先度と低優先度の変更間のパフォーマンス比較が可能になります。例えば、高優先度の変更が実際に短いサイクルタイムを持つのか、あるいは他の変更と同じボトルネックに陥っているのかを確認できます。これは、リソースの焦点を最適化し、ビジネスの期待に応える上で貴重です。その重要性ビジネス優先度に基づいたプロセスパフォーマンスの分析を可能にし、重要な変更が期待通りに迅速に進められていることを保証します。取得元これはJira課題の標準`priority`フィールドです。例最高高中低
	変更ステータス ChangeRequestStatus	イベント発生時の変更リクエストの現在または履歴上のステータス。
説明この属性は、「承認待ち」、「進行中」、または「クローズ済み」など、変更リクエストのステータスを示します。Jiraのステータスフィールドはそのワークフローエンジンの基本であり、このフィールドの変更はプロセスフローの主要な駆動要因となります。ステータスを分析することで、進行中の変更の進捗を追跡し、完了した変更の結果（例えば、「クローズ済み - 成功」対「クローズ済み - 失敗」）を理解することができます。これはスループットダッシュボードを構築し、ステータスが以前の状態に戻る手戻りループを分析するための鍵となります。その重要性変更リクエストの進捗と最終結果を明確に把握でき、スループットと手戻り分析にとって不可欠です。取得元これはJira課題の標準`status`フィールドです。利用可能なステータスは、プロジェクトのワークフロー構成で定義されます。例計画承認待ち実装中クローズキャンセル済み
	変更タイプ ChangeRequestType	変更の分類（例：標準、通常、緊急）。
説明変更タイプは、その性質、緊急性、影響に基づいて変更リクエストを分類します。一般的なタイプには、事前承認済みの低リスク変更に対する「標準」、完全な承認を必要とするルーチン変更に対する「通常」、インシデントを修正するための緊急変更に対する「緊急」などがあります。この属性は、異なる変更タイプが異なるプロセスパスをたどり、異なるSLAを持つため、プロセス分析に不可欠です。これは「緊急変更率」KPIを計算したり、ダッシュボードをフィルタリングして各タイプのパフォーマンスとリスクを比較したりするために使用されます。その重要性標準変更と緊急変更のような異なるワークフローを分析するためにプロセスをセグメント化することを可能にし、それぞれに固有のパフォーマンス期待値とリスクがあります。取得元これは通常、Jira Service Managementプロジェクトのカスタムフィールドです。フィールド名は異なる場合がありますが、多くの場合「変更タイプ」と名付けられています。例標準通常緊急
	承認サイクルタイム ApprovalCycleTime	変更がレビューのために提出されてから正式に承認されるまでの期間。
説明これは、「レビューのために変更提出済み」アクティビティと「変更リクエスト承認済み」アクティビティの間の経過時間を測定する計算メトリクスです。集中的な分析のために、変更ライフサイクルの承認フェーズを分離します。このメトリクスは、「変更承認サイクルタイム」ダッシュボードおよび対応するKPIを直接サポートします。特定の承認グループ、変更タイプ、またはリスクレベルが原因であるかどうかにかかわらず、承認プロセスにおけるボトルネックを特定するために使用されます。この時間を短縮することは、変更全体のデリバリープロセスを大幅に加速させることができます。その重要性承認段階の効率を直接測定し、変更承認における遅延を特定し対処するのに役立ちます。取得元特定の変更リクエストIDについて、「Change Request Approved」のタイムスタンプから「Change Submitted For Review」のタイムスタンプを差し引いて計算されます。例 2日4時間8 hours 30 minutes5 days
	目標完了日 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には個人の「アサインee」フィールドがありますが、「チーム」フィールドは「ネットワーク運用」や「データベース管理者」などの機能グループに作業を割り当てるためによく使用されます。これは「変更チームアクティビティワークロード」ダッシュボードにとって不可欠です。これにより、個人レベルだけでなく、チームレベルでのパフォーマンスとボトルネックの分析が可能になり、リソース計画と管理にとってより有用であることがよくあります。その重要性チームまたは部門レベルでの作業負荷とパフォーマンス分析を容易にし、システム全体のボトルネックを浮き彫りにします。取得元 Jiraには標準の「チーム」フィールドがないため、これは通常カスタムフィールドです。「グループピッカー」タイプまたはシンプルな選択リストである可能性があります。例インフラストラクチャチームコアサービスアプリケーションサポート
	報告者 Reporter	変更リクエストを最初に作成または提出したユーザー。
説明レポーターは、Jiraで変更リクエスト課題を作成した個人です。これはしばしば変更のオーナーであるか、チームを代表して変更を開始する人物です。レポーターを分析することで、どの部署、チーム、または個人が最も多くの変更を開始しているかを特定できます。変更源のトレンドを見つけたり、不完全または低品質な変更リクエストを頻繁に提出するグループにフィードバックやトレーニングを提供したりするために使用できます。その重要性変更リクエストの発生源を特定するのに役立ち、初期申請の品質向上を分析できます。取得元これはJira課題の標準`reporter`フィールドです。例 David MillerEva GreenFrank Wright
	変更理由 ChangeReason	変更を提案する正当な理由またはビジネス上の理由。
説明この属性は、「新機能実装」、「バグ修正」、または「インフラストラクチャアップグレード」など、変更の根本的な理由を捉えます。要約や説明を超えた重要なコンテキストを提供します。分析において、変更の理由はサイクルタイム、失敗率、リスクレベルなどの他のメトリクスと相関させることができます。これにより、「バグ修正に関連する変更は新機能実装よりも早く承認されるか？」や「インフラストラクチャアップグレードはより高い失敗率を持つか？」といった疑問に答えるのに役立ちます。その重要性変更の目的とそのパフォーマンス、結果を関連付けることで、より深い分析を可能にするビジネスコンテキストを提供します。取得元これは通常、Jira Service Managementのカスタムフィールドであり、多くの場合、選択リストまたはテキストフィールドです。例セキュリティパッチソフトウェアアップグレード新規ハードウェアインストール
	実装後の課題 PostImplementationIssue	実装後にインシデントまたは問題がこの変更にリンクされたかどうかを示すフラグです。
説明この属性は、変更が本番環境でのインシデントなどの負の結果につながったかどうかを示します。これはしばしば、変更リクエスト課題をJiraの1つ以上のインシデント課題にリンクすることを伴います。このデータは、「実装後課題発生率」および「変更失敗率」KPIを計算するために不可欠です。変更の品質、および計画、テスト、リスク評価プロセスの有効性を直接的に測定するものです。どの変更が問題につながるかを分析することは、コントロールを洗練し、将来の失敗を防ぐのに役立ちます。その重要性変更がその後の運用上の問題を引き起こしたかどうかを追跡することで、変更の品質と成功を直接測定します。取得元これは通常、Jiraでリンクされた課題をチェックすることで導き出されます。特に、変更課題がインシデント課題からの「～によって引き起こされる」リンクを持っているかどうかを確認します。例 truefalse
	手戻り IsRework	変更リクエストが手戻り（リワーク）ループを経験したかどうかを示すブール値フラグです。
説明この計算属性は、「承認待ち」から「計画中」に戻るなど、前のステージに差し戻されて修正が必要となった変更リクエストを特定します。これは、最初の提出が不完全、不正確、または必要な基準を満たしていなかったことを示唆しています。このフラグは、「変更手戻り率」KPIおよび「変更手戻りおよび却下分析」ダッシュボードの基礎となります。手戻りケースにフラグを立てることで、アナリストはそれらを容易にフィルタリングし、初期計画の不備、要件の不明確さ、不十分なリスク評価などの根本原因を調査できます。その重要性追加の計画外作業が必要であったケースを明示的にフラグ付けすることでプロセス非効率性を浮き彫りにし、手戻りの根本原因分析を可能にします。取得元イベントログ内の活動の順序を分析して計算されます。後期の活動の後に前期の活動が続く場合、手戻りが検出されます。例 truefalse
	業務サービス BusinessService	変更によって影響を受けるビジネスサービスまたはアプリケーション。
説明この属性は、変更リクエストを構成管理データベース（CMDB）で定義された特定のビジネスサービス（例：「メールサービス」や「顧客CRM」）にリンクします。これは、変更のビジネス影響を理解するための重要な概念です。ビジネスサービス別に変更を分析することは、取り組みの優先順位付けとステークホルダーへの影響の伝達に役立ちます。どのサービスが最も多くの変更を受けているか、どのサービスが最もリスクにさらされているか、および変更関連のインシデントがどこに集中しているかを把握することができます。これは、ビジネス中心の視点から技術的な変更を管理するために不可欠です。その重要性技術的な変更をビジネスへの影響と結びつけ、影響を受けるサービスの重要度に基づいて優先順位付けとリスク分析を可能にします。取得元これはJSMにおけるカスタムフィールドであることが多く、Jira Assets（旧Insight）または別のCMDBに頻繁にリンクされます。例企業ウェブサイトSAP ERP社内Wiki
	解決 Resolution	クローズされた変更リクエストの最終結果で、どのように解決されたかを示します。
説明変更リクエストがクローズされた際、「解決」フィールドは結果に関する特定の情報を提供します。例えば、「完了」は成功を示し、「実行しない」や「重複」はその他のクローズ理由を提供します。「クローズ済み」ステータス単独よりも多くのコンテキストを提供します。この属性は、変更の成功率と失敗率を分析するために不可欠です。例えば、「実装後課題発生率」KPIは、「失敗」または「ロールバック」の解決策を持つ変更でフィルタリングすることでよりよく理解できます。これは、成功裏に実装された変更と、承認後にキャンセルまたは却下された変更を区別するのに役立ちます。その重要性変更の最終結果に関する詳細なコンテキストを提供します。これは、成功率と失敗率を正確に計算するために不可欠です。取得元これはJiraの標準`resolution`フィールドであり、通常、課題が「完了」ステータスカテゴリに移行したときに設定されます。例完了実行しない重複キャンセル済みロールバック済み

必須推奨任意

変更管理活動

これらは、正確な変更管理プロセスディスカバリのためにイベントログで取得すべき主要なプロセスステップとマイルストーンです。

5 推奨 8 任意

	アクティビティ	説明
	変更クローズ済み	変更リクエストの最終的なクローズを示し、関連するすべてのアクティビティが完了したことを意味します。これは、Jira課題のステータスが「クローズ済み」または「完了」といった最終的な解決済みの状態に変更されたときに把握されます。
その重要性これはプロセスの主要な終点です。全体的なサイクルタイムを計算し、SLAへの遵守を決定するために使用されます。取得元 Jira課題履歴から、「status」フィールドが最終的なクローズ状態に変更された際のタイムスタンプを特定して推測されます。通常、この時点で解決策フィールドも設定されます。取得「クローズ済み」または「完了」へのステータス変更時のタイムスタンプを追跡します。イベントタイプ inferred
	変更リクエスト作成済み	Jira Service Managementでの変更リクエストチケットの初回作成を示します。「変更」タイプの新規課題が初めて保存された際に、作成タイムスタンプと共に明示的に記録されるイベントです。
その重要性これはすべての変更リクエストの出発点であり、全体のリードタイムを測定し、時間の経過に伴う受信変更のボリュームを分析するために重要です。取得元 Jira課題オブジェクトの「created」タイムスタンプから取得されます。これはすべての課題で利用可能な標準システムフィールドであり、課題履歴またはAPIを介して取得できます。取得 Jira課題の'created'フィールドのタイムスタンプを使用します。イベントタイプ explicit
	変更リクエスト承認済み	変更が正式に実装承認された重要なマイルストーンです。これはJiraワークフローで「Approved」や「Ready for Implementation」のようなステータスへの変更を推測することで、ほぼ常に捕捉されます。
その重要性このイベントは、承認サイクルの終了と実装フェーズの開始を示します。承認サイクルタイムの測定と不正な変更の追跡に不可欠です。取得元 Jira課題履歴から、「status」フィールドが「Approved」状態に遷移した際のタイムスタンプを特定して推測されます。取得「承認済み」または「実装準備完了」へのステータス変更時のタイムスタンプを追跡します。イベントタイプ inferred
	変更実装済み	変更に関連する作業が完了したことを示す主要なマイルストーンです。これはJiraワークフローで「Implemented」や「Pending Verification」のようなステータスへの変更を通じて捕捉されます。
その重要性これは実装フェーズの終了を示し、実装リードタイムの計算に不可欠です。また、実装後レビューおよび検証活動のトリガーでもあります。取得元 Jira課題履歴から、「status」フィールドが「Implemented」または「Pending Post-Implementation Review」に変更された際のタイムスタンプを特定して推測されます。取得「実装済み」またはそれに類するステータスへの変更時のタイムスタンプを追跡します。イベントタイプ inferred
	変更承認待ち	変更リクエストが初期レビューを通過し、現在、変更諮問委員会（CAB）または指定された承認者からの正式な決定を待っていることを示します。これは、「Pending Approval」または「Awaiting CAB」への移行など、ワークフローにおけるステータス変更から捕捉されます。
その重要性このアクティビティは、承認待機時間の測定と意思決定フェーズにおけるボトルネックの特定に重要であり、変更承認サイクルタイムKPIに直接影響します。取得元 Jira課題履歴から、「status」フィールドが「Pending CAB Approval」や「Awaiting Approval」のような承認状態に変更された際のタイムスタンプを特定して推測されます。取得指定された「承認待ち」ステータスへの変更時のタイムスタンプを追跡します。イベントタイプ inferred
	テスト実施済み	変更を検証するための実装後テストの完了を示します。これは「テスト中」のような明確なステータスである場合もあれば、「変更実装済み」イベント後のQAチームによるコメントや更新から推測される場合もあります。
その重要性テストの期間と結果を分析することは、実装の品質とテストプロセスの有効性を評価するのに役立ちます。これは、実装後の問題発生率を計算するための主要な入力となります。取得元これは、「テスト中」または「テスト対象」へのステータス変更から、あるいは実装後の課題履歴におけるコメントや担当者変更を分析することから推測できます。取得「テスト中」へのステータス変更時、またはコメントからのタイムスタンプを追跡します。イベントタイプ inferred
	リスク評価実施済み	提案された変更のリスクと影響分析の完了を示します。このイベントは、通常、「リスクレベル」や「影響」といったリスク関連のカスタムフィールドが入力または更新された際に、課題履歴から推測されます。
その重要性この活動を分析することで、リスク評価の正確性を評価し、変更ポリシーへの準拠を確保できます。これは、リスクレベル別変更失敗率のようなリスクベースのKPIを計算するために不可欠です。取得元 Jira課題履歴から、「Risk Level」、「Impact」、「Urgency」などの特定のフィールドが初めて設定または変更された際のタイムスタンプを捕捉して推測されます。取得「リスクレベル」や「影響」などのフィールドの初回入力時のタイムスタンプを追跡します。イベントタイプ inferred
	変更キャンセル	実装または完了前の変更リクエストの終了を示します。これは、Jira課題のステータスが「キャンセル済み」または「取り下げ済み」といった終了状態に変わったときに把握されます。
その重要性この代替終了点は、変更がなぜ破棄されたのかを分析するのに役立ちます。高いキャンセル率は、初期計画の不備やビジネス優先順位の変化を示している可能性があります。取得元 Jira課題履歴から、「status」フィールドが「Canceled」状態に変更され、対応する解決策が設定された際のタイムスタンプを特定して推測されます。取得「キャンセル済み」または「取り下げ済み」へのステータス変更時のタイムスタンプを追跡します。イベントタイプ inferred
	変更スケジュール済み	承認された変更に特定の実装期間が割り当てられたことを示します。これは、Jira課題内の「Planned start date」および「Planned end date」フィールドが入力または更新されたことから推測されます。
その重要性このアクティビティは、変更の先行計画を可視化します。リソース管理や、承認からスケジュールされた実装までの時間を評価するのに役立ちます。取得元 Jira課題履歴から、「Planned start date」や「Change window」などの日付フィールドが入力された際のタイムスタンプを捕捉して推測されます。取得「計画開始日」フィールドの入力時のタイムスタンプを追跡します。イベントタイプ inferred
	変更リクエスト却下済み	変更リクエストの正式な却下を示します。これは通常、より詳細な情報を得るためにリクエスタに差し戻されるか、キャンセルされることを意味します。Jiraワークフローのステータスが「却下済み」または「追加情報が必要」に変わることで把握されます。
その重要性却下を追跡することは、変更手戻り率を分析するために不可欠です。このアクティビティの頻度が高い場合、初期変更提出の品質に問題があることを示しています。取得元 Jira課題履歴から、「status」フィールドが「Rejected」または類似の最終状態に変更された際のタイムスタンプを特定して推測されます。取得「却下済み」または「辞退済み」へのステータス変更時のタイムスタンプを追跡します。イベントタイプ inferred
	変更レビュー提出済み	変更リクエストの初期情報が完了し、正式に評価のために提出された時点を示します。これは通常、Jiraワークフローでのステータス変更（例：「ドラフト」から「レビュー保留中」）から推測されます。
その重要性このアクティビティは承認サイクルを開始します。この時点から承認までの時間を測定することは、承認サイクルタイムKPIの計算と初期段階のボトルネック特定に不可欠です。取得元 Jira課題履歴から、「status」フィールドが「Pending Review」や「Awaiting Assessment」のようなレビュー状態に変更された際のタイムスタンプを特定して推測されます。取得「レビュー保留中」、「提出済み」またはそれに類するステータスへの変更時のタイムスタンプを追跡します。イベントタイプ inferred
	実装後レビュー完了	変更の成功を評価し、教訓を特定する正式なレビューの完了を示します。これは通常、「Post-Implementation Review」から「Verified」への移行など、ワークフローにおけるステータス変更を通じて捕捉されます。
その重要性このアクティビティはプロセス改善に不可欠です。このレビューのサイクルタイムを測定することは、学びが迅速に捉えられることを保証するのに役立ちます。取得元 Jira課題履歴から、「status」フィールドが「Post-Implementation Review」状態から移動した際のタイムスタンプを特定して推測されます。取得「PIR」から後続のステータスへの変更時のタイムスタンプを追跡します。イベントタイプ inferred
	実装開始	承認された変更の技術的な実装開始を示します。これは通常、Jiraのステータスが「承認済み」または「スケジュール済み」から「進行中」または「実装中」に変わることで把握されます。
その重要性このアクティビティは平均実装リードタイムの測定を開始し、実行フェーズ中のボトルネックを特定するのに役立ちます。取得元 Jira課題履歴から、「status」フィールドが「In Progress」のようなアクティブな実装状態に変更された際のタイムスタンプを特定して推測されます。取得「進行中」または「実装中」へのステータス変更時のタイムスタンプを追跡します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Access Jira's Issue Navigator: Jira Service Managementインスタンスにログインします。メインナビゲーションバーで「課題」を選択し、次に「課題を検索」を選んで課題ナビゲーターを開きます。
Switch to JQL Search: 「基本」検索モードの場合は、「JQL」（またはバージョンによっては「高度な検索」）をクリックして、詳細モードに切り替えます。これにより、カスタムのJira Query Language（JQL）クエリを入力できるようになります。
Filter for Change Requests: このドキュメントの「query」セクションで提供されているJQLクエリを検索バーに入力します。プロジェクトキー、変更用の課題タイプ名、および希望する日付範囲のプレースホルダーを調整してください。
Execute the Search and Export Data: 検索を実行します。変更リクエスト課題のリストが表示されたら、通常は右上の「エクスポート」ボタンを見つけます。「Export Excel CSV (all fields)」オプションを選択してください。この形式は、プロセスフローを再構築するために必要な詳細な課題履歴が含まれるため、非常に重要です。
Load the CSV for Transformation: ダウンロードしたCSVファイルを、Power Query、pandasライブラリを使用したPythonスクリプト、またはその他のETLツールなどのデータ準備ツールを使用して開きます。生データのエクスポートでは、課題ごとに1行ですが、履歴データを含む列があります。
Structure the Base Data: ソースファイルの各行について、最初の「Change Request Created」イベントを作成します。「Issue key」をChangeRequestIdとして使用し、ActivityNameを「Change Request Created」に設定し、「Created」列をEventTimeとして使用します。
Unpivot Status History: ステータス遷移履歴を含む列を見つけます。各ステータス変更はイベントです。各変更リクエストについて、関連するすべてのステータス遷移（例：「Draft」から「Pending Review」、「Pending Approval」から「Approved」）に対して新しい行を作成します。これらの遷移を「Change Submitted For Review」、「Change Awaiting Approval」、「Change Request Approved」などの対応するActivityNameにマッピングします。ステータス変更のタイムスタンプがEventTimeとなります。
Unpivot Field Update History: 特定のアクティビティはステータス変更ではなく、フィールド更新から推測されます。「Risk Level」、「Planned start date」、「Planned end date」などのフィールドの履歴を処理します。これらのフィールドが最初に設定または更新されたタイムスタンプを使用して、「Risk Assessment Performed」および「Change Scheduled」イベントの新しい行を作成します。
Map and Augment Attributes: 作成した各イベント行について、対応するJiraフィールドをChangeRequestStatus、ChangeRequestType、Assignee、Priorityなどの必要な属性にマッピングします。値はイベント発生時に有効だったものである必要があります。
Add Metadata Columns: 静的な値「Jira Service Management」を持つSourceSystemという名前の列を追加します。また、LastDataUpdateという名前の別の列を追加し、抽出が実行されたタイムスタンプを設定します。
Calculate Derived Metrics: 完全なイベントログを作成した後、ApprovalCycleTimeのように複数のデータポイントを必要とする属性を計算します。これには、各ChangeRequestIdについて「Change Submitted For Review」と「Change Request Approved」イベント間の時間差を求める作業が含まれます。
Finalize and Export for Upload: 最終テーブルにChangeRequestId、ActivityName、EventTimeの必須列があることを確認します。中間列やソース列は削除します。最終的な変換済みデータをCSVファイルとして保存し、UTF-8でエンコードされていることを確認し、プロセスマイニングツールにアップロードします。

設定

JQL Filter: JQLクエリは、適切なデータセットを選択するための主要なツールです。抽出範囲を定めるための主要なフィルターには、project、issuetype、およびcreatedフィールドに対する日付範囲フィルターが含まれます。
Date Range: パフォーマンスの問題を引き起こさずに代表的なデータセットを確保するため、3〜6か月間のデータ範囲から始めることをお勧めします。例：created >= "-180d"。
Issue Type: Jiraインスタンスで変更管理に使用されている課題タイプの正確な名前を指定する必要があります。例：issuetype = "Change"またはissuetype = "Change Request"。
Export Format: 常に「Export Excel CSV (all fields)」を使用してください。このオプションにより、すべてのカスタムフィールド、そして最も重要なステータスとフィールドの完全な変更ログ履歴がエクスポートファイルに含まれることが保証されます。限られたフィールドのエクスポートでは、イベントログを構築するために必要なデータは含まれません。
Jira Permissions: エクスポートを実行するユーザーは、指定されたプロジェクトに対する「Browse Projects」権限、および関連するすべての課題フィールドを表示するための必要な権限を持っている必要があります。
Custom Field Identification: 変換を行う前に、「Risk Level」、「Planned start date」、「Change Type」などのプロセス属性に対応するJiraインスタンス内のカスタムフィールドの正確な名前を特定する必要があります。

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

ステップ

Establish Database Connection: Jira ServerまたはData Centerの基盤となるデータベース（PostgreSQL、MySQL、SQL Server、Oracleなど）への読み取り専用アクセス認証情報を取得します。DBeaver、SQL Developer、pgAdminなどの標準SQLクライアントを使用してデータベースに接続します。
Identify Jira Configuration: クエリを実行する前に、Jira Service Managementの設定で使用されている特定の名前を特定する必要があります。Jiraにログインし、変更管理プロジェクトに移動します。以下の情報をメモしてください。
- プロジェクトキー: プロジェクトの短い識別子（例：'CSM'）。
- 課題タイプ名: 変更リクエストの正確な名前（通常は'Change'）。
- ワークフローステータス: 変更ワークフロー内の各ステータスの名前（例：'Pending Review'、'Pending Approval'、'In Progress'、'Closed'など）。
- カスタムフィールド名: 「Change Type」、「Risk Level」、「Planned start date」、「Planned end date」に使用されるカスタムフィールドの名前。
Customize the SQL Query: 提供された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句内のすべてのステータス名です。
Set the Date Range: 最初の共通テーブル式（CTE）内のAND i.created >= '[YYYY-MM-DD]'という行を見つけます。日付を変更して、データ抽出の開始点を定義します。これはデータ量を制限し、クエリパフォーマンスを向上させるために重要です。
Execute the Query: 変更したSQLクエリをJiraデータベースに対して実行します。Jiraインスタンスの規模と選択した日付範囲によっては、完了までに数分かかる場合があります。
Review the Results: クエリが完了したら、SQLクライアントで出力を簡単に検査し、行が返され、ChangeRequestId、ActivityName、EventTimeなどの列が期待どおりに設定されていることを確認します。
Export Data to CSV: SQLクライアントから結果セット全体をCSVファイルにエクスポートします。エクスポート設定に列ヘッダーが含まれていること、区切り文字としてコンマを使用していること、およびUTF-8エンコーディングを使用していることを確認してください。
Prepare for Upload: ファイルをjira_change_management_log.csvのように分かりやすい名前にします。このファイルは、プロセス・マイニング・ツールにアップロードして分析する準備が整いました。

設定

Database Access: Jiraプロダクションデータベースへの読み取り専用ユーザーアカウントが必要です。Jira ServerおよびJira Data Centerインスタンスのみが直接データベースにアクセスでき、Jira Cloudはできません。
Jira Project Key: クエリは、Jira Service Managementプロジェクトの特定のキーで設定する必要があります。これはp.pkey IN ('[Your_JSM_Project_Key]')句で確認できます。
Issue Type for Changes: クエリは変更リクエストの課題タイプが「Change」という名前であると仮定しています。設定で別の名前を使用している場合は、issuetype.pname = 'Change'フィルターを更新する必要があります。
Workflow Status Mapping: イベントログの正確性は、クエリのWHERE句にあるステータス名とプロジェクトの実際のワークフローステータスが正しくマッピングされているかに完全に依存します。各「Status Name」文字列を慎重に確認し、更新してください。
Custom Field Mapping: このクエリは、「Risk Assessment Performed」や「Change Scheduled」などの特定のアクティビティと属性を追跡するためにカスタムフィールド名に依存しています。'[Your Risk Level Field Name]'のような名前をJiraの設定に合わせて確認し、更新する必要があります。
Date Range: 管理可能なデータ量とクエリパフォーマンスを確保するために、3〜6か月のような限定された日付範囲（i.created >= '[YYYY-MM-DD]'）から始めることを強くお勧めします。複数年分のデータを抽出すると、非常に遅くなる可能性があります。
Performance: 数百万の課題を抱える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;

ステップ

Set Up Python Environment: Python 3.6以降がインストールされていることを確認してください。API呼び出し用のrequestsとデータ操作用のpandasの必要なライブラリを、pip install requests pandasコマンドを実行してインストールします。
Generate Jira API Token: Jiraアカウントにログインします。プロファイル設定に移動し、「アカウント設定」を選択し、次に「セキュリティ」タブに移動して「APIトークンの作成と管理」をクリックします。新しいトークンを作成し、安全にコピーしてください。このトークンはAPI認証のパスワードとして使用されます。
Configure the Python Script: 提供されているPythonスクリプトをエディタで開きます。JIRA_URL、JIRA_EMAIL、JIRA_API_TOKENのプレースホルダー値を、ご自身のJiraインスタンスURL、メールアドレス、および生成したAPIトークンに置き換えます。
Customize JQL Query: スクリプト内のJQL_QUERY変数を変更して、正しいJira Service Managementプロジェクトと課題タイプをターゲットにします。例えば、project = "CSM"をご自身のプロジェクトキーに変更します。データの抽出期間を制限し、パフォーマンスを向上させるために、クエリ内の日付範囲を調整します。
Map Custom Fields and Statuses: スクリプト内のSTATUS_TO_ACTIVITY_MAPPINGとFIELD_TO_ACTIVITY_MAPPING辞書を確認します。Jiraワークフローで使用されている正確な名前に一致するように、Jiraステータス名（例：「Pending Approval」）とカスタムフィールド名（例：「Risk Level」）を更新する必要があります。customfield_10050のようなフィールドの正しいIDを見つけるには、Jiraのカスタムフィールド管理ページを使用してください。
Execute the Script: コマンドpython your_script_name.pyを使用して、ターミナルからスクリプトを実行します。スクリプトはJira APIに接続し、変更リクエスト課題を取得し、その履歴を処理します。
Monitor Script Execution: スクリプトは、取得および処理された課題の数を示す進行状況メッセージをコンソールに出力します。大規模なデータセットの場合、これにはかなりの時間がかかることがあります。
Review the Output: スクリプトが完了すると、同じディレクトリにjira_change_management_event_log.csvという名前のCSVファイルが生成されます。このファイルには抽出されたイベントログが含まれます。
Prepare for Upload: スプレッドシートアプリケーションでCSVファイルを開き、ChangeRequestId、ActivityName、EventTimeなどの列が正しく構造化されていることを確認します。このファイルは、プロセス・マイニング・ツールにアップロードする準備が整いました。

設定

JQL Query: JQL_QUERY変数は抽出のための主要なフィルターです。最低限、project、issuetype = 'Change'、およびcreatedフィールドの日付範囲（例：過去180日間の場合はcreated >= -180d）を指定する必要があります。特定の期間でフィルタリングすることは、データ量を管理するために不可欠です。
Status and Field Mappings: スクリプトの正確性は、STATUS_TO_ACTIVITY_MAPPINGとFIELD_TO_ACTIVITY_MAPPING辞書に完全に依存します。これらは、適切なアクティビティを生成するために、組織のJiraワークフローステータスとカスタムフィールド名に正確に一致するように設定する必要があります。
API Credentials: スクリプトには、認証のために有効なJIRA_URL、JIRA_EMAIL、およびJIRA_API_TOKENが必要です。トークンに関連付けられたユーザーは、指定されたプロジェクトおよびすべての関連フィールドに対する読み取り権限を持っている必要があります。
Data Pagination: スクリプトは、APIから課題をバッチ（ページ）で取得するためにmaxResultsパラメーター（100に設定）を使用します。これは、タイムアウトなしで大量の課題を確実に抽出するために不可欠です。
Changelog Expansion: 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.")

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

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

変更管理属性

変更管理活動

抽出ガイド

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%の成功率を達成