> 継続的なプロセス改善 > ソフトウェア開発ライフサイクル > Jira Software > データテンプレート

ソフトウェア開発ライフサイクルのデータテンプレート

Jira Software

ソフトウェア開発ライフサイクルの属性 (21) ソフトウェア開発ライフサイクルのアクティビティ (14) 抽出ガイド (4)

ソフトウェア開発ライフサイクルのデータテンプレート

このテンプレートでは、ソフトウェア開発ライフサイクルを分析するために必要なデータを収集する手順を示します。収集すべき基本的なデータ項目、追跡すべき重要なプロセスステップ、Jira Softwareから情報を抽出する方法を説明しています。このガイドを使ってイベントログを準備し、効果的なプロセスマイニングにつなげてください。

収集を推奨する属性
追跡すべき主要なアクティビティ
Jira Softwareからデータを抽出する方法

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

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

ソフトウェア開発ライフサイクルの属性

ソフトウェア開発ライフサイクルを詳細に分析するために、イベントログに含めることを推奨するデータ項目です。

5 必須 6 推奨 10 任意

	名前	説明
	アクティビティ Activity	項目の開発ライフサイクルで発生した特定のイベントまたはステータス変更の名称です。
説明この属性は、ソフトウェア開発プロセスにおける個別のステップまたはマイルストーンを表します。これらのアクティビティは、Jira課題のstatusフィールドの変更や、コードコミット、レビューなどの重要なイベントから生成されます。プロセスマイニングでは、これらのアクティビティの順序がプロセスマップを形成します。アクティビティを分析すると、プロセスの流れを把握し、各段階の所要時間を測定できます。また、手戻りループや品質ゲートのスキップなど、標準ワークフローからの逸脱も検出できます。重要な理由アクティビティはプロセスのステップを定義します。その順序は、プロセスの流れを可視化し、ボトルネックを特定し、プロセスのばらつきを分析するうえで欠かせません。入手先通常は、Jira課題の履歴または変更履歴における「status」フィールドの遷移から生成します。接続された開発ツールのデータで補完することもできます。例開発の開始コードレビューの実施QAテスト完了本番環境へデプロイ済み
	イベント時刻 EventTime	特定の開発アクティビティまたはイベントが発生した正確な日時です。
説明イベント時刻は、アクティビティが発生した時点を記録するタイムスタンプです。各ケースのイベントを時系列に並べるための、すべてのプロセスマイニング分析の時間的な基盤となります。この属性は、サイクルタイム、処理時間、アクティビティ間の待機時間など、時間に基づくすべての指標を計算するうえで欠かせません。時間の経過に伴うプロセスパフォーマンスを分析し、開発ライフサイクルのどの時点で、どこに遅延が発生しているかを特定できます。重要な理由イベントを正しい順序に並べ、期間に基づくすべての指標を計算するための基礎となるタイムスタンプです。プロセスの効率を把握し、遅延を特定するうえで重要です。入手先課題の変更履歴または履歴にある各エントリの「created」タイムスタンプに対応します。例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	開発項目 DevelopmentItem	Jira Software内で、ストーリー、バグ、タスクなど、1つの作業単位を識別する一意の識別子です。
説明開発項目は、機能、バグ修正、タスクなど、特定の作業単位を表す主要なケース識別子です。その項目に関する初期構想と計画から、開発、テスト、デプロイまでのすべてのアクティビティを関連付けます。Jiraでは通常、課題キーに対応し、例として「PROJ-123」があります。この属性を分析すると、各作業項目のエンドツーエンドのライフサイクルを追跡できます。プロセスマップの作成、サイクルタイムの計算、開発プロセスにおける項目ごとの流れの違いの特定に役立ちます。重要な理由関連する開発アクティビティをすべて結び付けるための基本となるキーです。1つの作業項目が開始から完了までどのように進んだかを追跡できます。入手先 Jira Software Issue APIオブジェクトにおける、課題の標準的な「key」フィールドです。例 PROJ-101CORE-5432API-789
	ソースシステム SourceSystem	開発ライフサイクルのデータを抽出したシステムです。
説明この属性はデータの出所を識別します。このプロセスでは常に「Jira Software」になりますが、複数のソースシステムを組み合わせて分析する場合に、データを区別するために役立ちます。より広いIT環境では、ソースシステムを指定するとデータの来歴が明確になり、異なるプラットフォーム間でのデータ品質管理と統合作業を進めやすくなります。重要な理由データの出所を明確にします。複数システムのデータを統合する場合や、データガバナンスおよび監査を行う場合に重要です。入手先データの抽出および変換処理の際に追加する静的な値です。例 Jira Software
	最終データ更新 LastDataUpdate	このプロセスのデータがソースシステムから最後に更新された時刻を示すタイムスタンプです。
説明 Jira Softwareからデータが最後に抽出された日時を記録する属性です。分析対象データの鮮度を把握するための情報を提供します。最終更新時刻を把握すると、プロセス分析結果がどの時点の情報に基づいているかを確認できます。分析担当者や業務ユーザーは最新データを見ていることを確認でき、分析に含まれるイベントの締め時点も把握できます。重要な理由データの鮮度を示します。分析結果やダッシュボードにプロセスの最新状態を反映するために欠かせません。入手先データの抽出、変換、ロード（ETL）処理の終了時に生成され、記録されるタイムスタンプです。例 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	チーム名 TeamName	作業項目を担当する開発チームです。
説明開発項目を担当する特定のアジャイルチームまたは機能チームを表します。Jiraではカスタムフィールドとして実装されることが多く、プロジェクトや特定のコンポーネントなど、別の情報から導出することもできます。この属性は、チーム単位のパフォーマンス分析に欠かせません。ダッシュボードをチーム別に絞り込み、サイクルタイム、手戻り率、スループットなどの指標を表示できます。「Inter-Phase Handoff Efficiency」や「Developer Workload & Item Progress」ダッシュボードでも重要な属性です。重要な理由異なる開発チーム間でパフォーマンスを測定、比較し、高い成果を上げているチームを特定して優れた取り組みを共有できます。入手先 Jiraのカスタムフィールドであることが多い項目です。具体的なフィールド名については、Jira管理者にご確認ください。「Team」、「Squad」などの名称が考えられます。例 Team PhoenixコアサービスUI/UX Avengers
	プロジェクト名 ProjectName	開発項目が属するJiraプロジェクトの名称です。
説明 Jiraでは、すべての作業項目をプロジェクト単位で整理します。プロジェクト名は、特定の製品、チーム、取り組みに対応することが多く、全体像を把握するための情報になります。この属性は、フィルターや比較に使える有効な分析軸です。異なるプロジェクトや製品間でSDLCプロセスを分析し、ベンチマークできます。どのプロジェクトの効率が高いか、どのプロジェクトで手戻りが多いか、チームごとに異なるプロセスバリエーションを採用しているかを明らかにできます。重要な理由プロジェクト、製品、チーム単位でプロセス分析を分け、パフォーマンスを比較し、優れた取り組みを特定できます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「project」フィールドです。例モバイルアプリ開発コアプラットフォームデータサイエンス
	担当者 Assignee	現在、開発項目の処理を担当しているユーザーです。
説明担当者は、現在の段階で作業項目に責任を持つ個人です。Jiraの標準フィールドであり、項目が異なる担当者やチームへ移ると変更されます。担当者を分析すると、リソース配分、作業負荷の分布、引き継ぎの発生箇所を把握できます。特定の段階に関わる開発者やチーム、ボトルネックになっている担当者、組織内での作業分担について確認できます。重要な理由アクティビティの責任者または担当リソースを特定し、作業負荷の分析、リソース管理、担当者間の引き継ぎの把握に役立ちます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「assignee」フィールドです。例 Alice SmithBob Johnson未割り当て
	項目ステータス ItemStatus	ワークフロー内における開発項目の現在のステータスです。
説明この属性は、ある時点における開発項目の具体的な段階を示します。「In Progress」、「In Review」、「Done」などがあります。時間の経過に伴うステータス変更の順序から、プロセスマイニングのアクティビティが生成されます。「Activity」属性が変更イベントを表すのに対し、「ItemStatus」は項目の状態を示します。フィルターや分析の軸として利用でき、特定の状態にある項目数や、一定のステータスに長時間とどまっている項目の特徴を確認できます。重要な理由項目がライフサイクルのどの位置にあるかを示すスナップショットです。ステータスに基づく分析や、進行中の作業の現在状態を把握するうえで欠かせません。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「status」フィールドです。例 To Do進行中レビュー中完了
	項目タイプ ItemType	開発項目の分類です。Bug、Story、Task、Epicなどがあります。
説明項目タイプは、実施する作業の種類を分類します。Jiraでは標準の「issuetype」フィールドを使って異なる作業項目を区別し、それぞれに固有のワークフローが設定されている場合があります。この属性は比較分析に欠かせません。特定の作業タイプに絞ってプロセスを分析でき、例えば「Bug」と「Story」のライフサイクルを比較できます。これにより、特定の作業タイプで遅延、手戻り、標準プロセスからの逸脱が発生しやすいかを確認できます。重要な理由バグと新機能など、異なる作業タイプの処理方法やプロセスの違いを比較できるよう、プロセス分析を分割できます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「issuetype」フィールドです。例ストーリーバグTaskエピック
	項目の優先度 ItemPriority	開発項目に設定された優先度で、緊急度を示します。
説明項目の優先度は、作業項目の相対的な重要度または緊急度を定義します。Jiraには「Highest」、「High」、「Medium」、「Low」など、設定可能なレベルを持つ標準の「priority」フィールドがあります。優先度を分析すると、重要な項目の適合状況を確認し、ボトルネックを特定できます。例えば、「Priority Item Conformance Check」ダッシュボードでは、この属性を使って高優先度の項目が想定どおり優先処理されているか、低優先度の項目と同じキューで滞留していないかを確認します。重要な理由高優先度の項目が低優先度の項目より速く処理されているか、より効率的な経路をたどっているかを分析し、SLAの達成状況を確認できます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「priority」フィールドです。例最高高中低
	イベント終了時刻 EventEndTime	アクティビティまたはステータスが完了した時刻を示すタイムスタンプです。
説明この属性は、アクティビティの完了時刻を示します。特定のケースでは、次のアクティビティのタイムスタンプにあたります。「EventTime」（StartTime）がアクティビティの開始を示すのに対し、「EventEndTime」は終了を示します。この2つのタイムスタンプの差が、そのアクティビティの処理時間です。「Average Stage Processing Time」KPIの計算や、アクティビティの所要時間を分析するダッシュボードの作成に欠かせません。重要な理由アクティビティの終了点を定義し、プロセスの各ステップの所要時間を計算できます。ボトルネック分析に欠かせない情報です。入手先導出される属性です。特定のイベントでは、同じケースにおける次のイベントの開始時刻が終了時刻になります。例 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	コンポーネント Component	項目が属するプロジェクト内のサブセクションまたは機能領域です。
説明 Jiraでは、コンポーネントを使ってプロジェクト内の課題を、より小さく管理しやすい単位に分類します。「User Authentication」のような機能領域、「Backend API」のような技術レイヤー、「Reporting」のようなモジュールを表します。コンポーネント単位で分析すると、開発プロセスをより細かく把握できます。アプリケーションの特定部分でバグが多いか、開発サイクルが長いか、手戻りが多いかを特定し、技術的負債や複雑性のある領域を明らかにできます。重要な理由製品の機能領域または技術領域ごとにプロセスを分け、遅延や品質問題の原因となっているコンポーネントを特定できます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある標準の「components」フィールドです。例ユーザーインターフェースデータベースAPIゲートウェイ認証
	スプリント名 SprintName	開発項目が割り当てられているアジャイルスプリントの名称です。
説明スクラムを採用するチームでは、スプリントは一定の作業を完了させる期間を区切った単位です。この属性には、項目が属するスプリントの名称または識別子を記録します。スプリント単位の分析は、アジャイルに重点を置いたプロセスマイニングの基礎です。個々のスプリントのパフォーマンス、持ち越し作業、スプリント目標に対する進捗を評価できます。一般的な日付範囲よりも具体的な時間軸を提供します。重要な理由アジャイルチームに重要な背景情報を提供し、スプリントごとにプロセスの効率とスループットを分析できます。入手先通常は、Jira Software（Agile）が管理する「Sprint」カスタムフィールドに保存されます。データはIssue APIから取得できます。例 PROJスプリント12023年第4四半期スプリント311月PIスプリント2
	修正バージョン FixVersion	開発項目が実際に解決され、リリースされたソフトウェアバージョンです。
説明 Jiraの「Fix Version」は、項目の完了した作業を含むリリースを示します。開発作業の具体的な成果を記録します。この属性は実際のリリース情報を提供し、「PlannedReleaseVersion」と比較して納品パフォーマンスを分析できます。また、特定のリリースで提供されたすべての項目をまとめ、完了した内容を一覧で確認するためにも使います。重要な理由作業がどのリリースに含まれたかを確認し、リリース分析と提供機能の追跡における基準となる情報を提供します。入手先 Jira Issue APIレスポンスの「fixVersions」フィールドに対応します。例 v2.1.1ホットフィックスv3.0.0メジャーリリースv2.2.0
	報告者 Reporter	開発項目を最初に作成または報告したユーザーです。
説明報告者は、Jiraで課題を作成した個人です。開発者、QAテスター、プロダクトマネージャー、またはサービスデスク統合を通じた顧客の場合もあります。報告者を分析すると、作業の発生源を把握できます。例えば、QAチームが報告したバグと顧客が報告したバグで、ライフサイクルに違いがあるかを分析できます。また、プロセスの開始時点におけるコミュニケーションのパターンや情報の流れを理解するのにも役立ちます。重要な理由作業項目の発生源を特定し、誰がタスクを作成したか、誰がバグを報告したかに基づいてパターンを分析できます。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「reporter」フィールドです。例 Charles DarwinMarie CurieIsaac Newton
	引き継ぎ待ち時間 HandoffWaitTime	2つの連続するアクティビティ間のアイドル時間です。
説明このメトリクスは、1つのアクティビティが完了してから次のアクティビティが開始されるまでの待機時間、つまりキュー時間を計算します。作業が担当者に引き取られるまで、アイドル状態で待機している時間を表します。これは、「平均引き継ぎ待ち時間」KPIと「フェーズ間引き継ぎ効率」ダッシュボードにおける重要なメトリクスです。引き継ぎ時間が長い場合、開発チームとQAチームの間など、チーム間の調整上の問題、リソース不足、コミュニケーションの非効率が示唆されます。このアイドル時間を最小限に抑えることは、全体のサイクルタイムを短縮するための重要な施策です。重要な理由プロセス内のアイドル時間やキュー時間を明らかにし、チーム間または担当者間の引き継ぎにおける非効率や、調整上の問題を把握できます。入手先これは計算メトリクスです。同じケースにおけるアクティビティの開始時刻から、直前のアクティビティの終了時刻を差し引いて算出します。例 017280043200
	手戻りかどうか IsRework	アクティビティが手戻りループの一部かどうかを示すフラグです。
説明このブール型属性は、アクティビティがプロセスの後戻りを表す場合にtrueになります。例えば、QAテストに失敗した後、「Development Started」へ戻るケースです。ケース内のアクティビティの順序を分析して判定します。手戻りを特定することは、プロセスの効率と品質を改善するうえで基本となります。この属性は、「Rework Activity Rate」KPIと「Rework Loop Frequency and Paths」ダッシュボードを直接支援します。無駄になった作業量を定量化し、手戻りにつながる品質問題の根本原因を特定できます。重要な理由非効率な手戻りループの一部であるアクティビティを明示的に示し、プロセスの無駄と品質問題を正確に測定、分析できます。入手先計算される属性です。想定するプロセスの流れを定義し、以前の段階へ戻ることでその流れから逸脱したアクティビティにフラグを付ける必要があります。例 truefalse
	総サイクルタイム CycleTime	開発項目にかかるエンドツーエンドの総所要時間です。
説明サイクルタイムは、開発項目が作成されてから、本番環境へのデプロイなど最終的に解決されるまでの経過時間を測定します。ケース単位で、最初のイベントのタイムスタンプと最後のイベントのタイムスタンプの差として計算します。プロセス全体の速度と効率を測定する主要KPIです。「Average End-to-End Cycle Time」KPIと「Overall SDLC Cycle Time Analysis」ダッシュボードは、この計算に直接基づいています。サイクルタイムの短縮は、プロセス改善の取り組みにおける主要な目標になることが多い項目です。重要な理由開発プロセスのエンドツーエンドの速度を測定し、全体の効率と納品速度を示す主要なパフォーマンス指標を提供します。入手先ケース単位で計算される属性です。特定の「DevelopmentItem」について、最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを引いた値です。例 12096002592000604800
	計画リリース PlannedReleaseVersion	項目のデプロイが計画されている対象ソフトウェアバージョンまたはリリースです。
説明この属性は、Jiraの「Affects Version/s」フィールドに該当することが多く、機能や修正の対象リリースを示します。作業完了に向けた期限または目標として機能します。「On-Time Release Delivery Rate」KPIに欠かせない属性です。このバージョンに関連付けられた計画リリース日と実際のデプロイ日を比較すると、スケジュール遵守状況とリリースプロセスの予測可能性を測定できます。重要な理由目標とする納期またはリリースを定義し、納期遵守率の計算とスケジュール遵守状況の分析を可能にします。入手先 Jira Issue APIの「versions」または「fixVersions」フィールドに対応します。計画に使用する具体的なフィールドは異なる場合があります。例バージョン2.12024年第1四半期リリースProject Phoenixのローンチ
	項目の解決結果 ItemResolution	開発項目をクローズした最終的な結果または理由です。
説明 Resolutionは、項目がクローズ状態へ移行した理由を示します。ステータスが「Closed」であっても、解決結果は「Done」、「Won't Do」、「Duplicate」、「Cannot Reproduce」などになります。作業結果を理解するための重要な情報です。解決結果を分析すると、正常に完了した作業と、キャンセルまたは却下された項目を区別できます。価値ある作業の実際のスループットと、最終的に破棄された項目に費やした労力を把握するうえで重要です。重要な理由正常に完了した項目と、別の理由でクローズされた項目を区別できます。生産性と品質を正確に分析するために欠かせません。入手先 Jira Issue APIレスポンスの「fields」オブジェクト内にある「resolution」フィールドです。通常は課題がクローズされた場合にのみ入力されます。例完了対応しない重複再現不可

必須推奨任意

ソフトウェア開発ライフサイクルのアクティビティ

ソフトウェア開発ライフサイクルのプロセスを正確に発見するために、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 8 任意

	アクティビティ	説明
	QAテスト完了	開発項目がすべての品質保証チェックに合格し、ユーザー受け入れテストやリリースなど、次の段階へ進める状態になったことを示します。主なテスト状態から別の状態へステータスが変更されたことから推測します。
重要な理由重要な品質ゲートの完了を示します。QAフェーズの所要時間を分析すると、テストプロセスとリソース配分を最適化できます。入手先 Jira課題の変更履歴から推測します。「status」フィールドが「In QA」から「Ready for UAT」や「Ready for Release」などの次の状態へ移行した時刻です。取得「In QA」から「Ready for UAT」へステータスが変更された時刻です。イベントタイプ inferred
	QAテスト開始	このイベントは、開発項目に対する正式な品質保証テストフェーズの開始を示します。課題が「In QA」、「In Testing」、「Ready for Testing」などのステータスに移行した際のJiraステータス変更から推測します。
重要な理由品質検証サイクルを開始する重要なマイルストーンです。「Development Completed」からこの時点までの時間を測定すると、開発チームとQAチームの間で発生する引き継ぎの遅延を把握できます。入手先 Jira課題の変更履歴から推測します。「status」フィールドが「In QA」など、指定されたQAテスト状態に変更された時刻です。取得「In QA」または「In Testing」へステータスが変更された時刻です。イベントタイプ inferred
	UAT承認	ユーザー受け入れテストが正常に完了し、関係者がリリースを承認したことを示します。「In UAT」から「Ready for Release」や「Done」などへステータスが変更されたことから推測します。
重要な理由業務上の受け入れを確認し、本番環境へのデプロイを承認するマイルストーンです。提供した成果物がユーザーの期待を満たしていることを確認する重要なゲートです。入手先 Jira課題の変更履歴から推測します。承認を示す、「In UAT」からワークフロー内の次の状態へステータスが変更された時刻です。取得「In UAT」から「Ready for Release」へステータスが変更された時刻です。イベントタイプ inferred
	本番環境へデプロイ済み	開発項目に関連するコード変更が本番環境で稼働した時点を示します。最終ステータスが「Done」または「Released」に変更されたことから推測できます。また、統合されたCI/CDツールから明示的なイベントとして取得することもできます。
重要な理由プロセスにおける主要な成功到達点です。エンドツーエンドの総サイクルタイムを計算し、デプロイ頻度とスループットを測定するために欠かせません。入手先ステータスが「Released」または「Done」に変更された際のJira課題の変更履歴から推測できます。より正確に把握するには、JenkinsやBambooなどのCI/CDツールから送信されるデプロイイベント、またはJiraのDeployments機能から取得できます。取得「Done」または「Released」へステータスが変更された時刻です。イベントタイプ inferred
	開発アイテムの作成	これはライフサイクルの開始を示すイベントです。ストーリー、バグ、タスクなどの新しい開発アイテムがJiraに正式に登録された時点を指します。すべての課題について、作成タイムスタンプがシステムに明示的に記録されます。
重要な理由このアクティビティはプロセスの確定した開始点となるため、エンドツーエンドのサイクルタイムの計算や、受け付けた作業量の把握に欠かせません。入手先 Jiraのすべての課題に共通する基本的なイベントです。作成タイムスタンプは課題レコードの`created`フィールドに保存され、Jira APIから取得できます。取得 Jira Issueオブジェクトの`created`タイムスタンプフィールド。イベントタイプ explicit
	開発の開始	開発者が開発アイテムに対して実際の作業を開始した時点を示します。通常は、Jiraのワークフローで課題のステータスが「In Progress」などに変わったことから推定します。
重要な理由アクティブな開発時間を測定するための重要なマイルストーンです。待機時間と付加価値を生む作業時間を区別できるため、ボトルネックの特定に役立ちます。入手先 Jiraの課題変更履歴から推定します。`status`フィールドが初めて「In Progress」、「In Development」などのアクティブな状態に変わった時点のタイムスタンプです。取得「In Progress」へステータスが変わった時点のタイムスタンプ。イベントタイプ inferred
	QAテスト失敗	QAチームが欠陥を発見し、開発項目が手戻りのため開発者へ差し戻されたことを示します。「In QA」から「In Progress」または「To Do」へ戻る場合など、ステータスが後戻りしたことから推測します。
重要な理由手戻りループを特定するうえで欠かせないアクティビティです。発生頻度を追跡すると、品質不良によるコストを定量化し、開発や要件定義における改善領域を明らかにできます。入手先 Jira課題の変更履歴から推測します。「status」フィールドがテスト状態（例：「In QA」）から、以前の開発状態（例：「In Progress」）へ移行した時点で取得します。取得テスト状態から開発状態へステータスが変更された時刻です。イベントタイプ inferred
	UAT開始	ユーザー受け入れテストの開始を示します。ここでは、業務部門の関係者またはエンドユーザーが新機能を検証します。「In UAT」や「User Acceptance Testing」などの状態へJiraステータスが変更されたことから推測します。
重要な理由リリース前の最終検証フェーズの開始を追跡するアクティビティです。所要時間を分析すると、関係者の対応可能な時間やフィードバックサイクルによる遅延を把握し、削減できます。入手先 Jira課題の変更履歴から推測します。「status」フィールドが「In UAT」または同様に指定されたステータスへ更新された時刻です。取得「In UAT」へステータスが変更された時刻です。イベントタイプ inferred
	コードレビューの実施	同僚またはリードが、品質、標準、機能性の観点からコードをレビューしたことを示します。「In Review」から「Ready for QA」への移行など、ステータスの変更から推測できます。また、統合された開発ツールから明示的に取得することもできます。
重要な理由このアクティビティは、品質を確認する重要なゲートです。所要時間や、手戻りなどの結果を分析すると、コード品質の向上と、後工程で見つかるバグの削減につながります。入手先通常は、ステータスが「Code Review」から別の状態に移行した際のJira課題の変更履歴から推測します。BitbucketやGitHubなどのコードリポジトリツールを統合している場合は、明示的なイベントとして取得することもできます。取得「In Review」から次の状態へステータスが変更された時刻です。イベントタイプ inferred
	リリース準備完了	開発項目がすべてのチェックに合格し、特定のソフトウェアリリースバージョンにまとめられ、デプロイを待っていることを示します。課題のステータスが「Ready for Release」に変更された場合や、「Fix Version」フィールドが入力された場合に推測することが多い項目です。
重要な理由リリース準備の状況と、開発およびテスト作業が完了してからデプロイの機会を待っている時間を追跡できます。入手先通常は、Jira課題の変更履歴でステータスが「Ready for Release」に変更されたことから推測します。または、「Fix Version/s」フィールドが設定された時刻から推測することもできます。取得「Ready for Release」へステータスが変更された時刻、または「Fix Version」が入力された時刻です。イベントタイプ inferred
	開発の完了	開発者がコーディングを終え、コードレビューやテストなど次の段階へ進める状態になったことを示します。通常は、Jiraのステータスが「In Progress」から「In Review」または「Ready for QA」へ変わったことから推定します。
重要な理由開発の中核フェーズの終了を示すため、コーディングにかかった時間や、品質保証チームへの引き継ぎの効率を分析できます。入手先 Jiraの課題変更履歴から、`status`フィールドがアクティブな開発状態から「In Review」や「Ready for QA」などの次の状態へ変わった時点のタイムスタンプを取得して推定します。取得「In Progress」から「In Review」または「Ready for QA」へステータスが変わった時点のタイムスタンプ。イベントタイプ inferred
	開発可能な状態になったアイテム	開発アイテムの仕様化、レビュー、優先順位付けが完了し、開発者が作業を開始できる状態になったことを示します。通常は、ワークフローで「Backlog」から「To Do」または「Ready for Dev」へ移動するなど、ステータス変更から推定します。
重要な理由これを追跡することで、バックログの準備状況や、開発開始前にアイテムが待機している時間を測定できます。計画・詳細化にかかる時間と、実際の開発時間を分けて把握できます。入手先 Jiraの課題変更履歴から推定します。`status`フィールドが「Ready for Dev」、「To Do」、「Selected for Development」などに変わった時点のタイムスタンプを確認します。取得開発前の準備完了状態へステータスが変わった時点のタイムスタンプ。イベントタイプ inferred
	開発項目キャンセル	開発項目が完了前に終了したことを示します。「Canceled」、「Rejected」、「Won't Do」などの終了状態へステータスが変更されたことから推測し、特定の解決結果を伴うことが多い項目です。
重要な理由成功に至らなかったプロセスの結果を追跡するアクティビティです。項目がキャンセルされた理由を分析すると、計画、優先順位付け、要件定義における問題を明らかにできます。入手先 Jira課題の変更履歴から推測します。課題の「status」が「Canceled」または「Won't Do」に変更され、対応する解決結果が設定された時刻です。取得「Canceled」、「Rejected」、または「Won't Do」へステータスが変更された時刻です。イベントタイプ inferred
	開発項目クローズ	追加作業が予定されていないことを確認する、最後の管理上のアクションです。ステータスが「Closed」に変更され、「Resolution」フィールドに値が設定されたことから推測することが多い項目です。
重要な理由開発項目のライフサイクルが完全に終了したことを示します。「Deployed to Production」と比較すると、管理上の遅延やデプロイ後の監視期間を明らかにできます。入手先 Jira課題の変更履歴から推測します。「status」フィールドが「Closed」に変更され、解決結果が設定された時刻です。取得「Closed」へステータスが変更された時刻です。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Jira Softwareインスタンスにログインします。
メインナビゲーションバーでIssuesを選択し、Search for issuesをクリックします。Issue Navigatorが開きます。
検索ページで、既定のBasic検索から詳細設定検索に切り替え、Jira Query Language（JQL）を使用できるようにします。
JQLクエリバーに、提供されたJQLクエリを入力します。プロジェクトキーと日付範囲のプレースホルダーを、要件に合わせて置き換えます。
検索アイコンをクリックするかEnterキーを押してクエリを実行します。条件に一致するすべての開発項目が一覧表示されます。
検索結果ページの右上にあるExportアイコン（共有アイコンのように表示される場合や、明示的にラベルが付いている場合があります）をクリックし、XMLオプションを選択します。イベントログの作成に必要な完全な構造化変更履歴が含まれるため、CSVは使用しないでください。
ダウンロードしたXMLファイルをローカルマシンに保存します。このファイルにはJira Issueごとに1つのレコードが含まれますが、すべての過去の変更がその中にネストされています。
重要な変換手順：エクスポートしたXMLファイルは、フラットなイベントログではありません。外部スクリプトまたはETLツールを使って、このファイルを解析する必要があります。スクリプトでは、XML内の各<item>タグ（Jira Issueを表します）を順に処理します。
各Issueについて、まずcreatedフィールドのタイムスタンプを使い、Development Item Createdアクティビティの行を作成します。
次に、各Issue内の<changelog>データを解析します。ステータス遷移を表す各<changeitem>について、出力ファイルに新しい行を作成します。Jiraのステータス遷移（例：In ProgressからIn Review）を対応する業務アクティビティ（例：Development Completed）に対応付け、遷移のタイムスタンプをEventTimeに設定します。
各行について、XML構造からIssueキー、Issueの種類、担当者、プロジェクトなどを抽出し、必要な属性と推奨属性をすべて設定します。
すべてのIssueと履歴の処理が完了したら、指定された属性と一致する見出しを持つCSVファイルとして変換済みデータを保存し、プロセスマイニングツールにアップロードできる状態にします。

設定

JQLクエリのフィルター：JQLクエリはデータを選択するための主要な手段です。主なフィルターには、特定の開発プロジェクトを対象にするproject、Story、Bug、Taskなどの関連項目だけを含めるissuetype、分析期間を定義するcreatedがあります。
日付範囲：初回の分析では、3～6か月分のデータを抽出することを推奨します。意味のあるパターンを把握するのに十分なデータ量を確保しながら、エクスポートファイルのサイズを抑えられます。JQLではcreated >= 'YYYY-MM-DD'およびcreated <= 'YYYY-MM-DD'を使って範囲を指定します。
課題タイプ：issuetypeの値は具体的に指定してください。通常はStory、Bug、Task、Spikeを含め、主要なケースを表さないEpicなどのコンテナ課題や、粒度の細かいSub-taskは除外します。
エクスポート形式：エクスポート形式にはXMLを選択してください。標準のCSVエクスポートには、アクティビティの順序を再構成するために必要な構造化された変更履歴が確実に含まれるとは限りません。
ユーザー権限：エクスポートを実行するユーザーには、JQLクエリで指定したJiraプロジェクトに対する「Browse Projects」権限が必要です。

a サンプルクエリ config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

ステップ

データベース接続の確立：読み取り専用の認証情報と、JiraインスタンスのバックエンドSQLデータベースへのネットワーク接続を用意します。この方法は、セルフホスト型Jiraのインストール環境でのみ使用できます。
SQLクライアントでの接続：DBeaver、SQL Server Management Studio、pgAdminなどのデータベースクライアントツールを使用し、提供された認証情報でJiraデータベースに接続します。
ワークフローステータスの確認：クエリを実行する前に、Jiraプロジェクトのワークフロー設定（Project settings > Workflows）を開きます。追跡する各アクティビティに対応するステータスの正確な名前を確認します。例として、「Backlog」、「In Progress」、「In Review」、「Done」などがあります。
SQLクエリのカスタマイズ：提供されたSQLクエリをクライアントにコピーします。プレースホルダーの値を変更する必要があります。各UNION ALLブロックのWHERE句にあるステータス名が、プロジェクトのワークフローと正確に一致していることを確認します。
クエリパラメーターの設定：日付範囲フィルター（WHERE ji.created >= '2023-01-01'）を変更し、分析対象期間を指定します。また、プロジェクトキーのフィルター（--AND p.pkey IN ('PROJ1', 'PROJ2')）のコメントを解除して設定し、1つ以上の特定のプロジェクトに絞り込むことを強く推奨します。
カスタムフィールドの設定：Jiraインスタンスで「Team Name」に割り当てられているカスタムフィールドIDを確認します。JiraのCustom Fields管理ページで確認できます。クエリ内のプレースホルダー'customfield_10100'を実際のIDに置き換えます。
クエリの実行：変更したSQLクエリをJiraデータベースに対して実行します。
出力の確認：返されたデータにさまざまなアクティビティの行が含まれ、列に想定どおり値が入力されていることを簡単に確認します。
イベントログのエクスポート：SQLクライアントから結果セット全体をCSVファイルにエクスポートします。ファイルのエンコードがUTF-8であることを確認します。
アップロードの準備：エクスポートしたCSVファイルの列見出しが、必須属性名であるDevelopmentItem、アクティビティ、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName、TeamNameと一致していることを確認します。

設定

データベース認証情報：誤ってデータを変更しないよう、Jiraデータベースの読み取り専用ユーザーアカウントが必要です。
ワークフローステータス名：クエリの中心となるのは、ステータス名（例：「In Progress」、「Done」）によるフィルタリングです。これらはJiraのワークフローやプロジェクトごとに異なります。クエリ内のプレースホルダー値を、設定で使用している正確な名称に置き換えてください。
日付範囲：クエリには処理するデータ量を制限するWHERE ji.created >= '[YYYY-MM-DD]'句が含まれています。初回の分析では、データ量を管理しやすく、クエリを速く実行できる3～6か月の範囲を推奨します。
プロジェクトフィルター：分析対象を絞るため、p.pkey IN ('[YourProjectKey]')条件で特定のプロジェクトキーを指定することを強く推奨します。大規模なJiraインスタンスですべてのプロジェクトをクエリすると、処理に時間がかかる場合があります。
チームのカスタムフィールド：「Team Name」はカスタムフィールドであることを前提としています。提供されたクエリではプレースホルダーID（customfield_10100）を使用しているため、Jiraインスタンスの設定にある正しいIDへ更新する必要があります。
パフォーマンス：データベースへの直接クエリは、リソースを大量に消費する場合があります。ユーザー向けのJiraのパフォーマンスに影響しないよう、利用の少ない時間帯、または可能であれば本番データベースの読み取りレプリカに対して抽出を実行してください。

a サンプルクエリ sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

ステップ

前提条件：システムにPython 3がインストールされていることを確認します。API呼び出しに使うrequestsと、データ操作に使うpandasを、次のコマンドでインストールします：pip install requests pandas。
Jira APIトークンを生成：Jiraインスタンスにログインします。ユーザープロファイル設定を開き、Securityに移動して「Create and manage API tokens」を選択します。新しいトークンを作成し、安全にコピーします。このトークンは、スクリプト認証時にパスワードの代わりに使用します。
Pythonスクリプトを設定：提供されたPythonスクリプトを、たとえばextract_jira_log.pyというファイルにコピーします。ファイルを開き、先頭の設定セクションにJiraサイトのURL、メールアドレス、生成したAPIトークンを入力します。
JQLクエリを定義：スクリプト内のJQL_QUERY変数を変更します。このクエリで抽出対象の課題を指定します。まずは、プロジェクト、課題タイプ、特定の日付範囲で絞り込む方法がおすすめです。例：project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d。
ステータスマッピングをカスタマイズ：スクリプト内のSTATUS_MAPPING辞書を確認します。このマッピングは、組織固有のJiraワークフローステータスを、プロセスマイニング用の標準アクティビティへ変換するために欠かせません。キーであるJiraステータス名を、ワークフローの正確な名称に更新してください。
スクリプトを実行：ターミナルで次のコマンドを使ってスクリプトを実行します：python extract_jira_log.py。スクリプトがJira APIに接続し、課題データを取得して変更履歴を処理します。
APIのページネーションを処理：スクリプトは、50件単位で課題を取得することでページネーションを自動処理します。JQLクエリに一致するすべての課題を取得するまで、リクエストを継続します。
課題の変更履歴を処理：各課題について、スクリプトは履歴全体を取得します。作成イベントを特定した後、すべてのステータス変更を順に処理し、STATUS_MAPPINGに基づいて関連する遷移ごとにイベントログへ新しい行を作成します。
イベントログファイルを生成：すべての課題の処理が完了すると、スクリプトはイベントをpandas DataFrameにまとめ、SourceSystemやLastDataUpdateなどの必要なメタデータ列を追加し、最終的なイベントログをjira_event_log.csvというCSVファイルとして同じディレクトリに保存します。

設定

JIRA_URL：JiraインスタンスのベースURLです。例：https://your-company.atlassian.net。
JIRA_EMAIL：認証に使用するユーザーアカウントのメールアドレスです。
JIRA_API_TOKEN：スクリプト認証のために、Jiraユーザーのセキュリティ設定で生成したAPIトークンです。
JQL_QUERY：抽出する課題を絞り込むJira Query Languageの文字列です。データ量を管理するため、過去6～12か月などの日付範囲で絞り込むことを強く推奨します。また、正しいプロセスを分析できるよう、プロジェクトと関連する課題タイプ（例：Story、Bug、Task）でも絞り込んでください。
STATUS_MAPPING：Jiraワークフローのステータス名を、必要な汎用アクティビティ名に対応付けるPython辞書です。プロセスモデルの正確性を確保するうえで最も重要な設定です。プロジェクトのワークフローに合わせてカスタマイズしてください。
前提条件：スクリプトを実行するには、抽出対象のプロジェクトと課題への読み取りアクセス権を持つJiraユーザーアカウントが必要です。REST APIを使用する権限も必要です。

a サンプルクエリ python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].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 query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

ステップ

JiraプロジェクトでJira Automation、送信Webhook、HTTPS受信エンドポイントを利用できることを確認します。受信エンドポイントはPOSTリクエストを受け付け、イベントメタデータや課題フィールドを含む完全なJSONペイロードを保持できる必要があります。
ルールを作成する前にイベント契約を定義します。ケース識別子にはDevelopment Item、アクティビティ名にはActivity、イベントタイムスタンプにはEventTime、ソースシステムにはJira Software、取り込みまたは更新のタイムスタンプにはLastDataUpdateを使用します。受信エンドポイントでは、Jira課題キーをDevelopmentItemとして保持するよう設定します。
課題イベントトリガーを使ってJira Automationルールを作成します。課題の作成、ワークフローステータスの遷移、解決状況の変更、該当する場合はFix Versionの変更、Jira設定で利用できるデプロイやレビューの連携イベントに対するルールを設定します。Jiraに共通のワークフローはないため、ローカルのステータス名と遷移条件を必要なアクティビティに対応付けます。
各ルールから[Your webhook endpoint]へWebhookを送信するよう設定します。POSTとJSON形式を使用します。課題キー、課題タイプ、担当者、優先度、ステータス、プロジェクト、利用可能な場合はチームフィールド、イベントタイムスタンプ、遷移情報、解決状況、Fix Versionの値、Jiraイベント識別子を含めます。ProcessMindがステータス履歴からアクティビティを推測することを前提にしないでください。
Webhook受信エンドポイントまたは取り込みレイヤーで、明示的なアクティビティマッピングを作成します。条件を満たす各Webhookをイベントログの1行に変換します。課題の作成はDevelopment Item Created、準備完了への遷移はItem Ready for Development、In Progressへの遷移はDevelopment Started、レビューまたは開発完了への遷移はDevelopment Completed、レビュー遷移または連携されたレビューイベントはCode Review Performed、テストへの遷移はQA Testing Started、QAへの後戻りはQA Testing Failed、テスト成功時の遷移はQA Testing Completed、UATへの遷移はUAT StartedおよびUAT Approved、リリース準備はPrepared For Release、本番デプロイまたは設定されたリリース完了はDeployed To Production、終了はDevelopment Item Closed、キャンセルまたは却下はDevelopment Item Canceledに対応付けます。
プロセスオーナーが承認したJiraワークフローとイベント設定に基づいてマッピングを適用します。たとえば、Backlog、To Do、Ready for Dev、In Progress、In Review、Ready for QA、In QA、In Testing、In UAT、Ready for Release、Done、Released、Closed、Canceled、Rejected、Won't Doなどのローカルステータスは、意図した業務上の意味を持つ場合にのみ対応付けます。ペイロードが複数の条件該当イベントを明示的に表していない限り、1つのWebhookから複数の行を作成しないでください。
すべてのイベントを必要なスキーマに正規化します。DevelopmentItemにはJira課題キー、Activityには14個の必須アクティビティ名のいずれか1つ、EventTimeにはイベント発生時刻、SourceSystemにはJira Software、LastDataUpdateには取り込み更新時刻を設定します。存在する場合は、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName、TeamNameなどの推奨属性も設定します。
Jiraイベント識別子、課題キー、イベントタイムスタンプ、遷移識別子、アクティビティマッピングを使ってWebhook配信を重複排除します。Webhookは再送される可能性があるため、受信エンドポイントは冪等性を備える必要があります。取り込み時刻で置き換えず、元のイベントタイムスタンプを保持します。
スキーマ、タイムスタンプ、ケース識別子、アクティビティ名、重複処理、設定した日付範囲全体の網羅性を確認し、生成されたイベントログを検証します。14個すべてのアクティビティ値が行として発生し得ること、また後からProcessMindがアクティビティを推測する必要がないことを確認します。
正規化したイベントログをCSVまたはProcessMindがサポートする別のイベントログ形式でエクスポートします。1つの明示的なイベントにつき1行を作成し、DevelopmentItem、Activity、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName、TeamNameの列を含めます。ProcessMindの取り込み設定に従って、ファイルをアップロードするか、受信エンドポイントの出力を接続します。

設定

方式とクエリ言語：Jira AutomationルールとHTTPS Webhook受信エンドポイントを設定します。抽出はJiraデータベースへのクエリではなく、ルール設定とイベントの正規化によって行うため、クエリ値は設定値です。
ケース識別子：Jira課題キーをDevelopmentItemとして使用します。複数の課題を1つのケースにまとめないでください。
必須アクティビティ：Development Item Created、Item Ready for Development、Development Started、Development Completed、Code Review Performed、QA Testing Started、QA Testing Failed、QA Testing Completed、UAT Started、UAT Approved、Prepared For Release、Deployed To Production、Development Item Closed、Development Item Canceledを明示的にマッピングします。
イベントトリガー：課題の作成、ワークフロー遷移、解決状況、Fix Version、レビュー連携、デプロイ連携のトリガーは、Jira設定でサポートされ、意味のある場合にのみ有効にします。
ステータスマッピング：Jiraのローカルステータスと遷移について、プロジェクト固有のマッピングテーブルまたは設定を管理します。In Progress、In QA、Done、Closedなどのステータス名は、承認済みワークフローの意味に基づいて解釈する必要があります。
日付範囲：初回の検証では、3～6か月分のイベントを収集します。継続的なストリーミングでは、対象期間の開始前に受信エンドポイントを稼働させ、停止中に生成されたイベントに備えて再生またはバックフィルの方法を用意します。
フィルター：対象とするJiraプロジェクト、課題タイプ、ワークフローの範囲、イベントの日付範囲で絞り込みます。Company CodeとDocument TypeはJira Softwareの標準概念ではないため、代わりにプロジェクト、課題タイプ、その他の設定済みJiraフィールドを使用します。
ペイロードのフィールド：課題キー、課題タイプ、担当者、優先度、ステータス、プロジェクト、利用可能な場合はチームフィールド、イベントタイムスタンプ、遷移の詳細、解決状況、Fix Version、イベント識別子を含めます。
タイムスタンプの処理：可能な場合はタイムゾーン情報付きでタイムスタンプを保存します。EventTimeにはソースイベントのタイムスタンプ、LastDataUpdateには受信エンドポイントの更新時刻を使用します。
配信とセキュリティ：HTTPS、受信エンドポイントがサポートする認証、リクエスト検証、再試行処理、冪等処理を使用します。認証情報をイベントログの行に直接保存しないでください。
パフォーマンス：大規模なデータ量では、非同期取り込み、サポートされている場合は受信後のバッチ処理、インデックス付きの重複排除キー、イベント日付によるパーティション分割を使用します。運用中の受信エンドポイントでWebhookペイロードを無制限に保持しないでください。
前提条件：Jira Automationの権限、プロジェクトルールを設定する権限、対象の課題とフィールドを表示する権限、外部からアクセス可能なHTTPSエンドポイント、送信Webhookとデプロイイベントに必要なJiraプランまたは連携機能が必要です。
データ品質：削除された課題、名称変更されたステータス、担当者が未設定の場合、チームフィールドが未設定の場合、タイムゾーン変換、重複配信、順序どおりでないイベント受信への対応を定義します。

a サンプルクエリ config

{
  "method": "Real-time Event Streaming via Automation Webhooks",
  "approach": "Jira Automation rules send issue event JSON payloads to a configured HTTPS endpoint. The receiver normalizes each qualifying payload into one explicit event-log row.",
  "queryLanguage": "config",
  "confidence": "verified",
  "caseIdentifier": "DevelopmentItem",
  "sourceSystem": "Jira Software",
  "endpoint": "[Your webhook endpoint]",
  "dateFrom": "[Start date and time]",
  "dateTo": "[End date and time]",
  "filters": {
    "projects": "[Configure based on your Jira projects]",
    "issueTypes": "[Configure based on your Jira issue types]"
  },
  "outputColumns": [
    "DevelopmentItem",
    "Activity",
    "EventTime",
    "SourceSystem",
    "LastDataUpdate",
    "Assignee",
    "ItemType",
    "ItemPriority",
    "ItemStatus",
    "ProjectName",
    "TeamName"
  ],
  "activityMappings": [
    {
      "activity": "Development Item Created",
      "trigger": "Issue created",
      "condition": "The Jira issue creation event is received within the configured scope"
    },
    {
      "activity": "Item Ready for Development",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from a configured backlog or specification status to a configured ready-for-development status"
    },
    {
      "activity": "Development Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to the configured active development status, commonly In Progress"
    },
    {
      "activity": "Development Completed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from active development to a configured development-complete, review, or QA-ready status"
    },
    {
      "activity": "Code Review Performed",
      "trigger": "Workflow transition or configured review integration event",
      "condition": "A qualifying code review completion event is received, such as a transition from review to QA-ready"
    },
    {
      "activity": "QA Testing Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured QA or testing status"
    },
    {
      "activity": "QA Testing Failed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions backward from a configured QA or testing status to a development or rework status"
    },
    {
      "activity": "QA Testing Completed",
      "trigger": "Workflow transition",
      "condition": "The issue leaves the configured primary QA or testing status through a successful testing transition"
    },
    {
      "activity": "UAT Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured UAT or user acceptance testing status"
    },
    {
      "activity": "UAT Approved",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from UAT to a configured approval, release-ready, or completed status"
    },
    {
      "activity": "Prepared For Release",
      "trigger": "Workflow transition or Fix Version field change",
      "condition": "The issue reaches a configured release-ready status or receives a qualifying Fix Version value"
    },
    {
      "activity": "Deployed To Production",
      "trigger": "Configured deployment event or workflow transition",
      "condition": "A production deployment event is received, or the configured final release transition represents production deployment"
    },
    {
      "activity": "Development Item Closed",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches the configured Closed status and, where required, has a qualifying Resolution value"
    },
    {
      "activity": "Development Item Canceled",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches a configured canceled, rejected, or won't-do terminal state and, where required, has a qualifying Resolution value"
    }
  ],
  "normalization": {
    "oneRowPerEvent": true,
    "developmentItem": "payload.issue.key",
    "eventTime": "payload.event.timestamp or the source timestamp supplied by the Jira event",
    "sourceSystem": "Jira Software",
    "lastDataUpdate": "receiver ingestion timestamp",
    "assignee": "payload.issue.fields.assignee.displayName or account identifier when available",
    "itemType": "payload.issue.fields.issuetype.name",
    "itemPriority": "payload.issue.fields.priority.name",
    "itemStatus": "payload.issue.fields.status.name",
    "projectName": "payload.issue.fields.project.name",
    "teamName": "payload.issue.fields.team or the configured team field when available"
  },
  "deduplication": {
    "key": "payload.event.id, payload.issue.key, payload.event.timestamp, payload.transition.id, mapped activity",
    "behavior": "Ignore repeated deliveries with the same deduplication key while retaining the first valid event row"
  },
  "requiredConfiguration": [
    "Configure one or more Jira Automation rules for each qualifying event type",
    "Configure the webhook receiver at [Your webhook endpoint]",
    "Configure local Jira status and transition mappings",
    "Configure project and issue-type filters at [Configure based on your Jira projects] and [Configure based on your Jira issue types]",
    "Configure authentication and request validation according to the receiver implementation"
  ]
}

準備はできましたか？

このテンプレートでデータを準備し、今すぐソフトウェア開発ライフサイクルの最適化を始めてください。分析結果をもとに、提供スピードと品質を高められます。

改善ガイドに戻るテンプレートをダウンロード

Jira SoftwareのSDLCを最適化：今日から始めましょう

非効率を特定し、SDLCのサイクルタイムを30％短縮できます。

無料トライアルを開始

クレジットカードは不要です。数分で最適化を始められます。

ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルの属性

ソフトウェア開発ライフサイクルのアクティビティ

抽出ガイド

組み込みのCSVまたはXMLエクスポートを使ったJira JQLクエリ

ステップ

設定

a サンプルクエリ config

SQLによるJiraデータベースへの直接クエリ（セルフホスト型）

ステップ

設定

a サンプルクエリ sql

公式Jira REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

Automation Webhookによるリアルタイムイベントストリーミング

ステップ

設定

a サンプルクエリ config

準備はできましたか？

Jira SoftwareのSDLCを最適化：今日から始めましょう

ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルの属性

ソフトウェア開発ライフサイクルのアクティビティ

抽出ガイド

組み込みのCSVまたはXMLエクスポートを使ったJira JQLクエリ

ステップ

設定

a サンプルクエリ config

SQLによるJiraデータベースへの直接クエリ（セルフホスト型）

ステップ

設定

a サンプルクエリ sql

公式Jira REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

Automation Webhookによるリアルタイムイベントストリーミング

ステップ

設定

a サンプルクエリ config

準備はできましたか？

Jira SoftwareのSDLCを最適化：今日から始めましょう

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