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

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

Jira Software

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

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

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

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

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

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

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

ソフトウェア開発ライフサイクルを詳しく分析するには、これらのデータ項目をイベントログに含めることをおすすめします。

5 必須 6 推奨 10 任意

	名前	説明
	アクティビティ Activity	開発ライフサイクルで発生した特定のイベント、またはステータス変更の名前です。
説明この属性は、ソフトウェア開発プロセスにおける個別のステップやマイルストーンを表します。Jiraの課題のステータス変更や、コードのコミット、レビューなどの重要なイベントからアクティビティを特定します。プロセスマイニングでは、アクティビティの順序からプロセスマップが作成されます。アクティビティを分析すると、プロセスの流れを把握し、各段階にかかる時間を測定できます。また、手戻りや品質チェックの省略など、標準的なワークフローからの逸脱も検出できます。重要な理由アクティビティはプロセスの各ステップを示します。その順序を把握することで、プロセスの流れを可視化し、ボトルネックを特定し、プロセスのバリアントを分析できます。入手先通常は、Jiraの課題履歴または変更履歴に記録された「ステータス」フィールドの遷移から取得します。連携した開発ツールのデータを追加することもできます。例開発開始コードレビュー実施QAテスト完了本番環境にデプロイ済み
	イベント時刻 EventTime	特定の開発アクティビティやイベントが発生した正確な日時です。
説明イベント時刻は、アクティビティが発生した日時を記録するタイムスタンプです。各ケースのイベントを時系列に並べるための基礎となり、プロセスマイニング分析全体を支えます。サイクルタイム、処理時間、アクティビティ間の待ち時間など、時間に関する指標の算出に欠かせません。プロセスのパフォーマンスを時系列で分析できるため、開発ライフサイクルのどの時点で、どこに遅延が発生しているかを特定できます。重要な理由イベントを正しい順序に並べ、所要時間に関する指標を算出するための基本情報です。プロセスの効率を把握し、遅延を特定するうえで重要です。入手先課題の変更履歴または履歴に記録された各エントリーの「作成日時」に相当します。例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	開発項目 DevelopmentItem	Jira Software内で、ストーリー、バグ、タスクなどの作業単位を一意に識別するIDです。
説明開発項目は、機能開発、バグ修正、タスクなど、個別の作業単位を表す主要なケース識別子です。その項目の構想や計画から、開発、テスト、デプロイまでのすべてのアクティビティを関連付けます。Jiraでは通常、課題キーに対応します。例：「PROJ-123」。この属性を分析すると、各作業項目のライフサイクル全体を追跡できます。プロセスマップの作成、サイクルタイムの算出、開発プロセスにおける項目ごとの流れの違いの特定にも使います。重要な理由関連する開発アクティビティをすべて結び付けるための基本キーです。これにより、1つの作業項目の開始から完了までを追跡できます。入手先 Jira SoftwareのIssue APIオブジェクトで、課題に使用される標準の「キー」フィールドです。例 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ではカスタムフィールドとして設定されることが多く、プロジェクトや特定のコンポーネントなどの情報から特定することもできます。この属性は、チーム単位のパフォーマンス分析に欠かせません。ダッシュボードをチームごとに絞り込み、サイクルタイム、手戻り率、スループットなどの指標を表示できます。「フェーズ間の引き継ぎ効率」や「開発者の作業負荷と項目の進捗」ダッシュボードでも重要な属性です。重要な理由開発チーム間のパフォーマンスを測定、比較できます。成果を上げているチームを特定し、優れた取り組みを共有するのに役立ちます。入手先 Jiraのカスタムフィールドであることが多いため、Jira管理者に「Team」「Squad」などの具体的なフィールド名をご確認ください。例チーム・フェニックスコアサービスUI/UXアベンジャーズ
	プロジェクト名 ProjectName	開発項目が属するJiraプロジェクトの名前です。
説明 Jiraでは、すべての作業項目がプロジェクトごとに整理されています。プロジェクト名は、特定の製品、チーム、取り組みなどを示す大まかな情報です。この属性は、フィルターや比較に使う分析軸です。プロジェクトや製品ごとにSDLCプロセスを分析し、ベンチマークできます。プロジェクトごとの効率や手戻りの違い、チームによるプロセスのバリアントの違いを把握できます。重要な理由プロジェクト、製品、チームごとにプロセス分析を分けられます。パフォーマンスを比較し、優れた取り組みを特定するのに役立ちます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「project」フィールドです。例モバイルアプリ開発コアプラットフォームデータサイエンス
	担当者 Assignee	開発項目を現在担当しているユーザーです。
説明担当者は、現在の段階で作業項目を受け持つ人です。Jiraの標準フィールドで、項目が担当者やチーム間を移ると値が変わります。担当者を分析すると、リソースの割り当て、作業負荷の分布、引き継ぎのタイミングを把握できます。特定の段階にどの開発者やチームが関わっているか、誰がボトルネックになっているか、組織内で作業がどのように分担されているかを確認できます。重要な理由アクティビティを担当するユーザーやリソースを特定できます。作業負荷の分析やリソース管理、担当者間の引き継ぎ状況の把握に役立ちます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「assignee」フィールドです。例アリス・スミスボブ・ジョンソン未割り当て
	項目タイプ ItemType	バグ、ストーリー、Task、エピックなど、開発項目の分類です。
説明項目タイプは、実施する作業の種類を分類します。Jiraでは標準の「issuetype」フィールドで作業項目を区別します。種類によってワークフローが異なる場合があります。この属性は比較分析に欠かせません。特定の作業タイプに絞ってプロセスを分析し、たとえば「バグ」と「ストーリー」のライフサイクルを比較できます。作業タイプによって遅延や手戻りが起きやすいか、標準プロセスから逸脱しやすいかを特定するのに役立ちます。重要な理由バグと新機能など、作業タイプごとにプロセス分析を分けて比較できます。それぞれの作業がどのように処理され、どこに違いがあるかを把握できます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「issuetype」フィールドです。例ストーリーバグTaskエピック
	項目のステータス ItemStatus	ワークフローにおける開発項目の現在のステータスです。
説明この属性は、「進行中」「レビュー中」「完了」など、特定の時点における開発項目の段階を示します。ステータスの変化を時系列で並べることで、プロセスマイニングのアクティビティが生成されます。「アクティビティ」属性がステータスの変更イベントを表すのに対し、「項目のステータス」は項目の状態を示します。フィルターや分析の軸として使うと、特定の状態にある項目数や、長期間同じステータスにとどまっている項目の特徴を確認できます。重要な理由項目のライフサイクル上の現在地を示します。ステータス別の分析や、進行中の作業の状況を把握するために必要です。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「status」フィールドです。例未着手進行中レビュー中完了
	項目の優先度 ItemPriority	開発項目に設定された優先度で、対応の緊急性を示します。
説明項目の優先度は、作業項目の相対的な重要度や緊急性を示します。Jiraの標準「priority」フィールドでは、「最高」「高」「中」「低」などのレベルを設定できます。優先度を分析すると、適合性を確認し、重要な項目のボトルネックを特定できます。たとえば、「優先度の高い項目の適合性チェック」ダッシュボードでは、この属性を使って、優先度の高い項目が想定どおり優先的に処理されているか、優先度の低い項目と同じ待ち行列で滞留していないかを確認します。重要な理由優先度の高い項目が低い項目より速く処理されているか、より効率的な経路をたどっているかを分析できます。SLAの達成状況の確認にも役立ちます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「priority」フィールドです。例最高高中低
	イベント終了時刻 EventEndTime	アクティビティまたはステータスが完了した時刻です。
説明この属性は、アクティビティの完了時刻を示します。特定のケースでは、次のアクティビティのタイムスタンプにあたります。「イベント時刻」（開始時刻）がアクティビティの開始を示すのに対し、イベント終了時刻は終了を示します。この2つのタイムスタンプの差が、そのアクティビティの処理時間です。「平均ステージ処理時間」KPIの算出や、アクティビティの所要時間を分析するダッシュボードの作成に欠かせません。重要な理由アクティビティの終了時点を示し、プロセスの各ステップにかかる時間を算出できます。ボトルネック分析に必要な情報です。入手先派生属性です。イベントの終了時刻は、同じケースで次に発生するイベントの開始時刻です。例 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	コンポーネント Component	項目が属するプロジェクト内の小区分または機能領域です。
説明 Jiraでは、コンポーネントを使ってプロジェクト内の課題を、より小さく扱いやすい単位に分類します。「ユーザー認証」などの機能領域、「バックエンドAPI」などの技術レイヤー、「レポート」などのモジュールを表します。コンポーネント別に分析すると、開発プロセスをより細かく把握できます。アプリケーションのどの部分でバグが多いか、開発サイクルが長いか、手戻りが多いかを特定し、技術的負債や複雑さがある領域を見つけるのに役立ちます。重要な理由製品の機能領域や技術領域ごとにプロセスを分けて分析できます。遅延や品質上の問題が発生しているコンポーネントを特定するのに役立ちます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の標準「components」フィールドです。例ユーザーインターフェースデータベースAPIゲートウェイ認証
	スプリント名 SprintName	開発項目が割り当てられているアジャイルスプリントの名前です。
説明スクラムを採用するチームでは、スプリントは一定期間内に一連の作業を完了するための期間です。この属性には、項目が属するスプリントの名前または識別子が記録されます。スプリント単位の分析は、アジャイルに焦点を当てたプロセスマイニングの基本です。各スプリントのパフォーマンスや、次のスプリントに持ち越された作業を把握し、スプリント目標に対する進捗を追跡できます。一般的な日付範囲よりも具体的な時間軸の情報を得られます。重要な理由アジャイルチームの状況を把握するための重要な情報です。スプリントごとにプロセスの効率とスループットを分析できます。入手先通常、この情報はJira Software（Agile）が管理する「Sprint」カスタムフィールドに保存され、Issue APIから取得できます。例 PROJスプリント12023年第4四半期スプリント311月PIスプリント2
	修正バージョン FixVersion	開発項目が実際に解決され、リリースされたソフトウェアバージョンです。
説明 Jiraの「修正バージョン」は、項目の完了した作業を含むリリースを示します。開発作業の具体的な成果を表します。この属性から実際のリリース情報を確認し、「計画リリースバージョン」と比較して納品状況を分析できます。また、特定のリリースに含まれるすべての項目をまとめ、達成した内容を一覧できます。重要な理由作業がどのリリースに含まれたかを確認できます。リリース分析の基準となり、納品した機能の追跡にも役立ちます。入手先 Jira Issue APIのレスポンスにある「fixVersions」フィールドにあたります。例 v2.1.1緊急修正v3.0.0メジャーリリースv2.2.0
	報告者 Reporter	開発項目を最初に作成、または報告したユーザーです。
説明報告者は、Jiraで課題を作成した人です。開発者、QAテスター、プロダクトマネージャーのほか、サービスデスク連携を通じた顧客の場合もあります。報告者を分析すると、作業がどこから発生したかを把握できます。たとえば、QAチームが報告したバグと顧客が報告したバグで、ライフサイクルに違いがあるかを分析できます。また、プロセスの開始時点におけるコミュニケーションの傾向や情報の流れを理解するのにも役立ちます。重要な理由作業項目の発生元を特定できます。誰がタスクを作成したか、誰がバグを報告したかに基づく傾向の分析に役立ちます。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「reporter」フィールドです。例チャールズ・ダーウィンマリー・キュリーアイザック・ニュートン
	引き継ぎ待ち時間 HandoffWaitTime	連続する2つのアクティビティの間に生じる待ち時間です。
説明あるアクティビティの完了から次のアクティビティの開始までの待ち時間、つまりキュー時間を測定します。作業が担当者に引き取られるまで、手つかずの状態で待機している時間を表します。「平均引き継ぎ待ち時間」KPIと「フェーズ間の引き継ぎ効率」ダッシュボードで重要な指標です。引き継ぎ時間が長い場合、開発チームとQAチームの間などで、調整上の問題、リソース不足、チーム間のコミュニケーションの非効率が生じている可能性があります。この待ち時間を最小限に抑えることは、全体のサイクルタイム短縮につながります。重要な理由プロセス内の待ち時間やキュー時間を明らかにし、チームや担当者間の引き継ぎにおける非効率や調整上の問題を把握できます。入手先計算指標です。同じケースにおけるアクティビティの開始時刻から、直前のアクティビティの終了時刻を差し引きます。例 017280043200
	手戻りの有無 IsRework	アクティビティが手戻りループに含まれるかどうかを示すフラグです。
説明このブール属性は、アクティビティがプロセスの前段階に戻るステップを表す場合にtrueになります。たとえば、QAテストに失敗し、「開発開始」に戻る場合です。ケース内のアクティビティの順序を分析して判定します。手戻りの特定は、プロセスの効率と品質を高めるうえで欠かせません。この属性は、「手戻りアクティビティ率」KPIと「手戻りループの頻度と経路」ダッシュボードに直接利用されます。無駄になった作業量を定量化し、手戻りにつながる品質問題の根本原因を特定できます。重要な理由非効率な手戻りループに含まれるアクティビティを明示することで、プロセスの無駄や品質問題を正確に測定・分析できます。入手先計算属性です。想定するプロセスフローを定義し、前の段階に戻ることでフローから逸脱したアクティビティにフラグを設定します。例 truefalse
	総サイクルタイム CycleTime	開発項目の開始から完了までにかかる総時間です。
説明サイクルタイムは、開発項目の作成から本番環境へのデプロイなど、最終的な解決に至るまでの経過時間を測定します。ケース単位で、最初のイベントと最後のイベントのタイムスタンプの差として算出します。プロセス全体の速度と効率を測る主要なKPIです。「平均エンドツーエンドサイクルタイム」KPIと「SDLC全体のサイクルタイム分析」ダッシュボードは、この計算に基づいています。プロセス改善の取り組みでは、サイクルタイムの短縮が重要な目標となることがよくあります。重要な理由開発プロセスの開始から完了までの速度を測定し、全体的な効率と納品速度を把握するための主要なパフォーマンス指標となります。入手先ケース単位で算出する属性です。特定の「DevelopmentItem」について、最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを差し引きます。例 12096002592000604800
	計画リリース PlannedReleaseVersion	項目のデプロイ先として計画されているソフトウェアバージョンまたはリリースです。
説明この属性は、Jiraの「影響するバージョン」フィールドにあたることが多く、機能や修正の対象となるリリースを示します。作業の完了期限または目標として機能します。「予定どおりのリリース納品率」KPIの算出に欠かせない属性です。このバージョンに関連付けられた計画リリース日と実際のデプロイ日を比較することで、スケジュールの遵守状況やリリースプロセスの予測可能性を測定できます。重要な理由目標の納品日またはリリースを定義します。予定どおりの納品率の算出や、スケジュールの遵守状況の分析に役立ちます。入手先 Jira Issue APIの「versions」または「fixVersions」フィールドにあたります。計画に使用するフィールドは環境によって異なる場合があります。例バージョン2.12024年第1四半期リリースプロジェクト・フェニックスのローンチ
	項目の解決状況 ItemResolution	開発項目をクローズした最終結果、またはその理由です。
説明解決状況は、項目がクローズ状態になった理由を示します。ステータスが「クローズ」でも、解決状況は「完了」「対応しない」「重複」「再現不可」などの場合があります。作業の結果を理解するための重要な情報です。解決状況を分析すると、正常に完了した作業と、キャンセルまたは却下された項目を区別できます。品質分析や、価値ある作業の実際のスループットと、最終的に破棄された項目に費やした労力を把握するうえで役立ちます。重要な理由正常に完了した項目と、別の理由でクローズされた項目を区別できます。生産性や品質を正確に分析するために重要です。入手先 Jira Issue APIのレスポンスにある「fields」オブジェクト内の「resolution」フィールドです。通常、課題がクローズされた場合にのみ値が設定されます。例完了対応しない重複再現不可

必須推奨任意

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

ソフトウェア開発ライフサイクルを正確に把握するには、これらの主要なプロセスステップとマイルストーンをイベントログに記録してください。

6 推奨 8 任意

	アクティビティ	説明
	QAテスト完了	開発項目がすべての品質保証チェックに合格し、ユーザー受け入れテストやリリースなど次の段階に進める状態を示します。通常は、主要なテスト中のステータスから別の状態に変わった時点から推定します。
重要な理由この時点で重要な品質ゲートが完了します。QAフェーズの所要時間を分析すると、テストプロセスやリソース配分の改善に役立ちます。入手先 Jira課題の変更履歴から推定します。「status」フィールドが「QA中」から「UAT準備完了」や「リリース準備完了」などの次の状態に変わった時刻です。記録ステータスが「QA中」から「UAT準備完了」に変わった時刻。イベントタイプ inferred
	QAテスト開始	開発項目の正式な品質保証テストが始まった時点を示します。Jiraのステータスが「QA中」「テスト中」「テスト準備完了」などに変わった時点から推定します。
重要な理由これは品質検証サイクルの開始を示す重要な節目です。「開発完了」からこの時点までの時間を測ると、開発チームとQAチームの間で発生する引き継ぎの遅れが分かります。入手先 Jira課題の変更履歴から推定します。「status」フィールドが「QA中」など、指定されたQAテストの状態に変わった時刻です。記録ステータスが「QA中」または「テスト中」に変わった時刻。イベントタイプ inferred
	UAT承認	ユーザー受け入れテストが正常に完了し、関係者がリリースを承認したことを示します。「UAT中」から「リリース準備完了」や「完了」などにステータスが変わった時点から推定します。
重要な理由このマイルストーンは、業務側の承認を確認し、本番環境へのリリースを可能にします。納品物がユーザーの期待に沿っていることを確かめる重要な関門です。入手先 Jiraの課題変更履歴から推定します。ワークフローでステータスが「UAT中」から次の状態に変わった時刻で、承認を示します。記録ステータスが「UAT中」から「リリース準備完了」に変わった時刻です。イベントタイプ inferred
	本番環境にデプロイ済み	このイベントは、開発項目に関連するコード変更が本番環境で稼働した時点を示します。最終ステータスが「完了」または「リリース済み」に変わったことから推定するか、連携したCI/CDツールから明示的なイベントを取得できます。
重要な理由これはプロセスの主な成功到達点です。エンドツーエンドの総サイクルタイムの算出や、デプロイ頻度とスループットの測定に欠かせません。入手先 Jiraの課題変更履歴でステータスが「リリース済み」または「完了」に変わったことから推定できます。より正確に把握するには、JenkinsやBambooなどのCI/CDツールから送信されるデプロイイベント、またはJiraのデプロイ機能で取得できます。記録ステータスが「完了」または「リリース済み」に変わった時刻です。イベントタイプ inferred
	開発開始	開発者が開発項目の作業を実際に始めた時点を示します。ほとんどの場合、Jiraのワークフローでステータスが変わった時刻から推定します。たとえば、課題のステータスが「進行中」に変わった時点です。
重要な理由これは、実際の開発時間を測定するうえで重要な節目です。待ち時間と付加価値を生む作業を区別でき、ボトルネックの特定に役立ちます。入手先 Jira課題の変更履歴から推定します。「status」フィールドが初めて「進行中」「開発中」などの作業中の状態に変わった時刻です。記録ステータスが「進行中」に変わった時刻。イベントタイプ inferred
	開発項目の作成	ストーリー、バグ、タスクなどの新しい開発項目がJiraに正式に登録され、ライフサイクルが始まる時点です。すべての課題について、作成時刻がイベントとしてシステムに記録されます。
重要な理由このアクティビティはプロセスの明確な開始点となります。エンドツーエンドのサイクルタイムの計算や、流入する作業の総量の追跡に欠かせません。入手先すべてのJira課題に共通する基本的なイベントです。作成時刻は課題レコードの「created」フィールドに保存され、Jira APIから取得できます。記録 Jiraの課題オブジェクトにある「created」タイムスタンプフィールド。イベントタイプ explicit
	QAテスト不合格	QAチームが不具合を見つけ、開発項目が修正のために開発者へ戻されたことを示します。「QA中」から「進行中」や「未着手」に戻るなど、ステータスが前の段階に戻った時点から推定します。
重要な理由このアクティビティは、手戻りの繰り返しを特定するうえで重要です。発生頻度を追跡すると、品質不足によるコストを数値化し、開発や要件の改善が必要な箇所を把握できます。入手先 Jira課題の変更履歴から推定します。「status」フィールドがテスト中の状態（例：「QA中」）から、前の開発段階の状態（例：「進行中」）に変わった時点を記録します。記録ステータスがテスト中から開発中に変わった時刻。イベントタイプ inferred
	UAT開始	業務部門の関係者やエンドユーザーが新機能を検証する、ユーザー受け入れテストの開始を示します。Jiraのステータスが「UAT中」や「ユーザー受け入れテスト」などに変わった時点から推定します。
重要な理由このアクティビティは、リリース前の最終検証フェーズの開始を記録します。所要時間を分析すると、関係者の対応可能な時間やフィードバックのサイクルによる遅延を把握し、短縮するうえで役立ちます。入手先 Jira課題の変更履歴から推定します。「status」フィールドが「UAT中」または同様に指定されたステータスに更新された時刻です。記録ステータスが「UAT中」に変わった時刻。イベントタイプ inferred
	コードレビュー実施	同僚やリーダーが、品質、標準、機能の観点からコードをレビューしたことを示します。「レビュー中」から「QA準備完了」へのステータス変更から推定できるほか、開発ツールとの連携によって明示的に記録することもできます。
重要な理由このアクティビティは重要な品質ゲートです。所要時間や手戻りなどの結果を分析することで、コードの品質向上や後工程で見つかる不具合の削減に役立ちます。入手先通常は、Jira課題の変更履歴でステータスが「コードレビュー」状態から変わった時点から推定します。BitbucketやGitHubなどのコードリポジトリツールと連携している場合は、イベントとして明示的に記録することもできます。記録ステータスが「レビュー中」から次の状態に変わった時刻。イベントタイプ inferred
	リリース準備完了	開発項目がすべてのチェックを通過し、特定のソフトウェアリリースバージョンにまとめられて、デプロイを待っていることを示します。多くの場合、課題のステータスが「リリース準備完了」に変わったとき、または「修正バージョン」フィールドに値が入力されたときに推定します。
重要な理由このアクティビティを追跡すると、リリースの準備状況や、開発とテストが完了してからデプロイの機会を待つ時間を把握できます。入手先通常は、Jiraの課題変更履歴でステータスが「リリース準備完了」に変わったことから推定します。または、「修正バージョン」フィールドに値が設定された時刻から推定できます。記録ステータスが「リリース準備完了」に変わった時刻、または「修正バージョン」に値が入力された時刻です。イベントタイプ inferred
	開発完了	開発者がコーディングを終え、コードレビューやテストなど次の段階に進める状態を示します。Jiraのステータスが「進行中」から「レビュー中」や「QA準備完了」などに変わった時点から推定します。
重要な理由この時点で開発の主要フェーズが終了します。コーディングにかかった時間や、品質保証チームへの引き継ぎの効率を分析できます。入手先 Jira課題の変更履歴から、「status」フィールドが開発中の状態から「レビュー中」や「QA準備完了」などの次の状態に変わった時刻を取得して推定します。記録ステータスが「進行中」から「レビュー中」または「QA準備完了」に変わった時刻。イベントタイプ inferred
	開発開始の準備完了	開発項目の仕様確認、レビュー、優先順位付けが完了し、開発者が作業を始められる状態を示します。通常は、ワークフローで「バックログ」から「未着手」や「開発準備完了」へ移るなど、ステータスの変更から推定します。
重要な理由この時点を追跡すると、バックログの準備状況や、開発開始前に項目が待機する時間を測定できます。計画や要件の整理にかかる時間と、実際の開発時間を分けて把握できます。入手先 Jira課題の変更履歴から推定します。「status」フィールドが「開発準備完了」「未着手」「開発対象に選定」などに変わった時刻を確認します。記録開発開始前の準備完了状態にステータスが変わった時刻。イベントタイプ inferred
	開発項目のキャンセル	開発項目が完了前に終了したことを示します。「キャンセル」「却下」「対応しない」などの終了状態にステータスが変わったことから推定し、特定の解決状況が設定されることもあります。
重要な理由このアクティビティでは、プロセスが成功に至らなかった結果を追跡します。項目がキャンセルされた理由を分析すると、計画、優先順位付け、要件定義に関する問題が見つかることがあります。入手先 Jiraの課題変更履歴から推定します。課題の「ステータス」が「キャンセル」または「対応しない」に変わり、対応する解決状況が設定された時刻です。記録ステータスが「キャンセル」「却下」または「対応しない」に変わった時刻です。イベントタイプ inferred
	開発項目のクローズ	これは最後の管理上の処理であり、その項目に追加作業が発生しないことを確認します。多くの場合、ステータスが「クローズ」に変わり、「解決状況」フィールドに値が設定されたことから推定します。
重要な理由項目の一連の流れが完全に終了した時点を示します。「本番環境にデプロイ済み」と比較すると、管理上の遅れやデプロイ後の監視期間が明らかになることがあります。入手先 Jiraの課題変更履歴から推定します。「ステータス」フィールドが「クローズ」に変わり、解決状況が設定された時刻です。記録ステータスが「クローズ」に変わった時刻です。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

Jira Softwareのインスタンスにログインします。
メインナビゲーションバーで課題を選択し、課題を検索をクリックします。課題ナビゲーターが開きます。
検索ページで、既定の基本検索から詳細検索に切り替え、Jira Query Language（JQL）を使えるようにします。
JQLクエリ欄に、提示されたJQLクエリを入力します。プロジェクトキーと日付範囲のプレースホルダーを、要件に合わせて置き換えてください。
検索アイコンをクリックするかEnterキーを押してクエリを実行します。条件に一致するすべての開発項目が一覧表示されます。
検索結果ページの右上にあるエクスポートアイコン（共有アイコンのような形の場合や、ラベルが明記されている場合があります）をクリックし、XMLを選択します。イベントログの作成に必要な変更履歴全体が構造化されて含まれるため、CSVは使用しないでください。
ダウンロードしたXMLファイルをローカルマシンに保存します。このファイルにはJiraの課題ごとに1件のレコードが含まれ、過去の変更履歴はその中にネストされています。
重要な変換手順：エクスポートしたXMLファイルは、フラットなイベントログではありません。外部スクリプトまたはETLツールを使って解析する必要があります。スクリプトでXML内の各<item>タグ（Jiraの課題を表します）を順に処理します。
各課題について、まずcreatedフィールドのタイムスタンプを使い、「開発項目の作成」アクティビティの行を作成します。
次に、各課題内の<changelog>データを解析します。ステータス遷移を表す各<changeitem>について、出力ファイルに新しい行を作成します。Jiraのステータス遷移（例：「進行中」から「レビュー中」）を対応する業務アクティビティ（例：「開発完了」）にマッピングし、遷移のタイムスタンプをEventTimeに設定します。
各行に必須属性と推奨属性を設定し、XML構造から課題キー、課題タイプ、担当者、プロジェクトなどのデータを抽出します。
すべての課題と履歴を処理したら、指定された属性に一致するヘッダーを付けて変換後のデータを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プロジェクトの「プロジェクトの閲覧」権限が必要です。

クエリの例 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プロジェクトのワークフロー設定（プロジェクト設定 > ワークフロー）を開き、追跡する各アクティビティに対応するステータスの正確な名称を確認します。例：「バックログ」「進行中」「レビュー中」「完了」などです。
SQLクエリを調整：提示されたSQLクエリをクライアントにコピーします。プレースホルダーの値を必ず置き換えてください。各UNION ALLブロックのWHERE句にあるステータス名は、プロジェクトのワークフローと正確に一致させてください。
クエリパラメーターを設定：日付範囲のフィルター（WHERE ji.created >= '2023-01-01'）を変更し、分析期間を指定します。また、プロジェクトキーのフィルター（--AND p.pkey IN ('PROJ1', 'PROJ2')）のコメントを解除して値を設定し、1つ以上のプロジェクトに絞り込むことを強くおすすめします。
カスタムフィールドを設定：Jiraインスタンスで「チーム名」のカスタムフィールドIDを確認します。Jiraのカスタムフィールド管理ページで確認できます。クエリ内のプレースホルダー'customfield_10100'を実際のIDに置き換えてください。
クエリを実行：変更したSQLクエリをJiraデータベースに対して実行します。
出力を確認：返されたデータを簡単に確認し、さまざまなアクティビティの行が含まれ、各列に想定どおり値が設定されていることを確かめます。
イベントログをエクスポート：SQLクライアントから結果全体をCSVファイルにエクスポートします。文字コードはUTF-8にしてください。
アップロードの準備：エクスポートしたCSVファイルの列ヘッダーが、必須属性名DevelopmentItem、アクティビティ、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName、TeamNameと一致することを確認します。

設定

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

クエリの例 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インスタンスにログインします。ユーザープロフィール設定を開き、「セキュリティ」に移動して「APIトークンを作成・管理」を選択します。新しいトークンを作成し、安全な場所にコピーします。このトークンは、スクリプトの認証時にパスワードの代わりに使用します。
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を使用する権限も必要です。

クエリの例 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イベントIDを含めます。ProcessMindがステータス履歴からアクティビティを推測することを前提にしないでください。
Webhook受信側または取り込みレイヤーで、明示的なアクティビティマッピングを作成します。条件に該当する各Webhookをイベントログの1行に変換します。課題の作成はDevelopment Item Created、開発準備の遷移はItem Ready for Development、進行中への遷移は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ワークフローとイベント設定に基づいてマッピングを適用します。たとえば、「バックログ」「未着手」「開発準備完了」「進行中」「レビュー中」「QA準備完了」「QA中」「テスト中」「UAT中」「リリース準備完了」「完了」「リリース済み」「クローズ」「キャンセル」「却下」「対応しない」などのローカルステータスは、意図された業務上の意味と一致する場合にのみマッピングしてください。ペイロードが複数の該当イベントを明示的に表している場合を除き、1つのWebhookから複数の行を作成しないでください。
すべてのイベントを必須スキーマに正規化します。DevelopmentItemにはJiraの課題キー、Activityには必須の14種類のアクティビティ名のいずれか1つ、EventTimeにはイベント発生時刻、SourceSystemにはJira Software、LastDataUpdateには取り込み時刻を設定します。担当者、課題タイプ、優先度、ステータス、プロジェクト名、チーム名など、存在する場合は推奨属性も設定します。
JiraイベントID、課題キー、イベントのタイムスタンプ、遷移ID、アクティビティマッピングを使ってWebhookの重複配信を排除します。Webhookは再送される場合があるため、受信側は冪等に処理する必要があります。元のイベントタイムスタンプを保持し、取り込み時刻で置き換えないでください。
スキーマ、タイムスタンプ、ケース識別子、アクティビティ名、重複処理、設定した日付範囲の網羅性を確認し、生成されたイベントログを検証します。14種類すべてのアクティビティが行として記録される可能性があり、後からProcessMindがアクティビティを推測する必要がないことを確認してください。
正規化したイベントログをCSVまたはProcessMindがサポートする別のイベントログ形式でエクスポートします。明示的なイベントごとに1行を作成し、DevelopmentItem、Activity、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName、TeamNameの列を含めます。ProcessMindの取り込み設定に従って、ファイルをアップロードするか、受信エンドポイントの出力に接続します。

設定

方式とクエリ言語：Jira AutomationのルールとHTTPSのWebhook受信エンドポイントを設定します。抽出はJiraデータベースへのクエリではなく、ルール設定とイベントの正規化によって行うため、クエリ値はconfigです。
ケース識別子：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のローカルステータスと遷移に対応する、プロジェクト固有のマッピング表または設定を維持します。「進行中」「QA中」「完了」「クローズ」などのステータス名は、承認済みワークフローで定義された意味に沿って解釈してください。
日付範囲：初回の検証では、3～6か月分のイベントを収集します。継続的にストリーミングする場合は、対象期間の開始前に受信エンドポイントを稼働させ、停止中に発生したイベントを再取得または補完する方法を用意します。
フィルター：対象とするJiraプロジェクト、課題タイプ、ワークフローの範囲、イベントの日付範囲で絞り込みます。Company CodeとDocument TypeはJira Softwareの標準的な概念ではないため、代わりにプロジェクト、課題タイプ、その他設定済みのJiraフィールドを使用します。
ペイロードのフィールド：課題キー、課題タイプ、担当者、優先度、ステータス、プロジェクト、利用可能な場合はチームフィールド、イベントのタイムスタンプ、遷移の詳細、解決状況、Fix Version、イベントIDを含めます。
タイムスタンプの処理：可能な場合はタイムゾーン情報を含めてタイムスタンプを保存します。EventTimeには元のイベント時刻を、LastDataUpdateには受信側での更新時刻を使用します。
配信とセキュリティ：HTTPS、受信側がサポートする認証、リクエストの検証、再試行処理、冪等な処理を使用します。認証情報をイベントログの行に含めないでください。
パフォーマンス：大量のデータを扱う場合は、非同期の取り込み、対応していれば受信後のバッチ処理、インデックス付きの重複排除キー、イベント日付によるパーティション分割を使用します。運用中の受信エンドポイントでWebhookペイロードを無制限に保持しないでください。
前提条件：Jira Automationの権限、プロジェクトルールの設定権限、関連する課題とフィールドの閲覧権限、アクセス可能なHTTPSエンドポイント、および送信Webhookやデプロイイベントに必要なJiraプランまたは連携機能が必要です。
データ品質：削除された課題、名称が変更されたステータス、担当者やチームフィールドの欠損、タイムゾーン変換、重複配信、順序どおりに届かないイベントへの対応を定義します。

クエリの例 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％短縮しましょう。

無料トライアルを開始

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

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

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

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

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

データ抽出ガイド

Jira JQLクエリと標準のCSVまたはXMLエクスポート

ステップ

設定

クエリの例 config

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

ステップ

設定

クエリの例 sql

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

ステップ

設定

クエリの例 python

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

ステップ

設定

クエリの例 config

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

Jira SoftwareのSDLCを今すぐ最適化