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

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

GitLab

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

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

このテンプレートでは、ソフトウェア開発ライフサイクルのプロセス分析に必要なデータを確認できます。収集する属性や追跡する主要なアクティビティを示し、GitLabから情報を直接抽出する方法も説明します。この資料を参考にデータを準備し、プロセスマイニングを始められます。

収集を推奨する属性
追跡する主なアクティビティ
データ抽出ガイド

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

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

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

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

3 必須 5 推奨 12 任意

	名前	説明
	アクティビティ Activity	発生したプロセスの具体的なステップまたはイベントの名前です。例：課題の作成、マージリクエストのマージ。
説明アクティビティ属性は、開発項目に対して発生した個々のイベントを記録します。GitLabでは単一のフィールドとして保存されるのではなく、課題、マージリクエスト、CI/CDパイプラインに関するさまざまな操作やタイムスタンプから導出されます。たとえば、課題の作成、コミットのプッシュ、パイプラインの失敗、マージリクエストの承認は、それぞれ別のアクティビティです。この属性は、プロセスマップの作成、ワークフローの可視化、イベントの順序や頻度の分析に欠かせません。逸脱やステップ間のボトルネック、よく見られるプロセス経路の特定に使われます。重要な理由プロセスマップ上のステップを定義し、開発ワークフロー全体の可視化と分析を可能にします。入手先 GitLabのイベントストリームに含まれるイベント種別や状態変更から導出します。または、課題やマージリクエストのcreated_at、merged_at、closed_atなどのタイムスタンプフィールドを解釈して導出します。例課題の作成開発の開始マージリクエストのマージパイプラインの失敗本番環境へのデプロイ
	開始時刻 StartTime	アクティビティまたはイベントが始まった時刻を示すタイムスタンプです。
説明 StartTimeは、特定のアクティビティが発生した正確な日時を示します。GitLabのイベントでは、さまざまなタイムスタンプフィールドから取得します。たとえば、課題の作成アクティビティのStartTimeには課題の`created_at`タイムスタンプを、マージリクエストのマージアクティビティのStartTimeにはマージリクエストの`merged_at`タイムスタンプを使います。このタイムスタンプは、プロセスマイニングにおける時間情報の基礎です。イベントを時系列に並べ、アクティビティ間の所要時間やサイクルタイムを計算し、時間の経過に伴うプロセスのパフォーマンスを分析するために使います。重要な理由イベントの時系列を示す属性です。時間に基づくすべての指標の計算や、プロセスの流れの把握に欠かせません。入手先課題のcreated_at、updated_at、closed_atや、マージリクエストのmerged_atなど、GitLabのさまざまなタイムスタンプフィールドから抽出します。例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
	開発項目 DevelopmentItem	機能追加、不具合修正、タスクなどの作業単位を一意に識別するIDで、主要なケース識別子として使われます。
説明開発項目は、ソフトウェア開発ライフサイクルを通じて進行する、追跡可能な個々の作業を表します。作成から最終的なデプロイまで、関連するすべてのアクティビティを1つのケースとして結び付けます。GitLabでは通常、プロジェクト内で一意な課題の内部ID（IID）で表されます。開発項目ごとに分析すると、エンドツーエンドのサイクルタイムの測定、ボトルネックの特定、プロセス適合性チェックが可能になります。構想から本番環境へのリリースまで、作業がどれだけ効率よく進むかを把握する基盤となります。重要な理由これは、プロセス内のすべてのイベントを結び付ける重要なケース識別子です。個々の作業項目のライフサイクル全体を追跡できます。入手先通常はGitLabの課題の内部ID（IID）です。Issues APIの応答にあるiidフィールドで確認できます。例 1024512PRJ-2345
	プロジェクト名 ProjectName	開発項目が属するGitLabプロジェクトの名前です。
説明この属性は、作業が行われているコードリポジトリまたはプロジェクトを特定します。GitLabでは、すべての課題とマージリクエストがプロジェクトに属します。プロジェクト名ごとに分析すると、製品、コンポーネント、サービス間でパフォーマンスを比較できます。SDLCプロセスの状態が良好なプロジェクトを特定したり、関心のある領域に絞ってダッシュボードを表示したりする際に役立ちます。重要な理由製品、アプリケーション、コンポーネントごとにプロセス分析を分類でき、対象を絞った改善に役立ちます。入手先 IssuesとMerge Requestsのproject_idを介して関連付けたProject APIのnameまたはpath_with_namespaceフィールドから取得します。例 platform/api-gatewayfrontend/customer-portalmobile/ios-app
	担当者 Assignee	イベント発生時に課題またはマージリクエストを担当していたユーザーです。
説明担当者は、プロセスの各時点で作業項目を担当する開発者またはユーザーです。GitLabでは、課題またはマージリクエストの`assignee`または`assignees`フィールドに記録されます。担当者別の分析は、開発者の作業負荷と配分のダッシュボードに欠かせません。リソースの利用状況を把握し、負荷が集中している個人やチームを特定し、担当者間の引き継ぎを分析できます。重要な理由作業を担当した人を追跡し、作業負荷やリソース配分の効率を分析できます。引き継ぎによる遅れの特定にも役立ちます。入手先 GitLabのIssues APIおよびMerge Requests APIの応答にあるassignee.usernameまたはassigneesフィールドから取得します。例 jdoeasmithr.williams
	終了時刻 EndTime	アクティビティまたはイベントが完了した時刻を示すタイムスタンプです。
説明 EndTimeは、アクティビティが終了した正確な日時を示します。課題の作成など、GitLabの多くの単発イベントでは、EndTimeとStartTimeは同じです。コードレビューのように所要時間があるアクティビティでは、最後の承認が行われた時刻など、完了時のタイムスタンプを表します。この属性は、個々のアクティビティの所要時間（処理時間）を正確に計算するために欠かせません。タスクに実際に取り組んだ時間と、タスク間の待ち時間を区別できるため、ボトルネックを詳しく分析できます。重要な理由アクティビティの正確な所要時間（処理時間）を計算でき、プロセス内の非効率なステップの特定に役立ちます。入手先単発イベントではStartTimeと同じです。所要時間のあるアクティビティでは、データ内の対応する完了イベントを特定して導出します。例 2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
	重大度 Severity	通常は不具合やインシデントに設定される、開発項目の重大度です。
説明重大度は、不具合や問題の影響の大きさを示し、重大から軽微までの段階があります。GitLabには標準の重大度フィールドがないため、ほとんどの場合、severity::1やseverity::2などのラベルで管理します。この属性は、重大度のエスカレーション傾向を示すダッシュボードと関連する重要業績評価指標（KPI）に欠かせません。ライフサイクルを通じた重大度の変化を分析すると、当初の見積もりが甘かった問題や、問題を悪化させるプロセスを明らかにできます。重要な理由作業の優先順位付けや、重大度の高い項目がより早く処理されているかの分析に役立ちます。変更を追跡すると、重大度のエスカレーション頻度を示す重要業績評価指標（KPI）を確認できます。入手先 GitLabの課題に付けられたlabelsから導出します。S1やS2などのラベルを重大度に対応付ける必要があります。例 1 - 重大2 - 高3 - 中4 - 低
	開発項目の種類 DevelopmentItemType	機能追加、不具合、タスク、保守など、開発項目の分類です。
説明この属性は、実施する作業の種類を分類します。GitLabでは通常、課題に付けるラベルで管理します。チームはラベルを使って、新機能の開発、不具合の修正、技術的負債への対応など、作業の種類を区別します。開発項目の種類ごとに分析すると、作業の種類によるプロセスの流れやサイクルタイムを比較できます。たとえば、不具合の修正が機能開発より早いか、技術的負債への対応で異なるレビュー手順が使われているかを分析できます。重要な理由作業の種類ごとにプロセスを分類すると、遅延、手戻り、逸脱が起きやすい作業を特定できます。入手先通常はGitLabの課題に付けられたlabelsから導出します。個々のラベルを標準化された種類に変換するためのマッピングが必要です。例機能追加不具合タスク技術的負債
	サイクルタイム CycleTime	開発項目の最初のアクティビティから最後のアクティビティまでにかかった合計時間です。
説明サイクルタイムは、ケースの所要時間を測定する計算指標です。通常、1つの開発項目について、最初のイベント（例：「課題の作成」）から最後のイベント（例：「本番環境へのデプロイ」）までの時間差として算出します。プロセス全体の効率を測る主要なKPIです。「SDLCのエンドツーエンド・サイクルタイム」などのダッシュボードで中心となる指標であり、改善状況の追跡や、システム上の問題を示す可能性がある長期化したケースの特定に使います。重要な理由開発ライフサイクル全体の効率を測定する、プロセスマイニングの主要なKPIです。入手先プロセスマイニングツールが、固有のCaseIdごとにStartTimeの最大値から最小値を差し引いて算出します。例 10日4時間23時間15分35日
	ソースシステム SourceSystem	データの取得元となるシステムを示します。
説明この属性は、プロセスデータの取得元を示します。このデータモデルでは、値は常にGitLabです。 Jiraで計画しGitLabで実行する場合のように、複数のシステムからプロセスデータを統合する環境では、この属性が重要です。データの絞り込みや分類に使えるほか、データの来歴の管理にも役立ちます。重要な理由データの取得元を明確にし、データガバナンスや複数の業務システムからのデータ統合を支援します。入手先データ変換時に追加する固定値のGitLabです。例 GitLab
	チーム名 TeamName	プロジェクトまたは担当者に関連付けられた開発チームです。
説明チーム名は、開発項目を担当するグループまたはチームを示します。通常、GitLabの標準フィールドではないため、プロジェクトの命名規則やグループ構成から導出するか、外部の参照テーブルを使って担当者を各チームに対応付けます。この属性を使うと、チーム単位でプロセスのパフォーマンスを分析できます。チーム間の効率、作業負荷、プロセス遵守状況を比較でき、チーム別にステージ固有のボトルネック分析を行うダッシュボードにも役立ちます。重要な理由チーム間のパフォーマンス分析やプロセス比較が可能になり、チーム固有のボトルネックや優れた取り組みを特定できます。入手先多くの場合、GitLab外で定義されたチーム構成にプロジェクト名や担当者を対応付けるか、GitLabのグループ階層から推定します。例フロントエンド-アルファバックエンド-サービスプラットフォーム-インフラ
	パイプラインのステータス PipelineStatus	CI/CDパイプライン実行のステータスです。「成功」「失敗」「実行中」などがあります。
説明この属性は、コミットまたはマージリクエストに関連付けられたCI/CDパイプラインの実行結果を示します。GitLabでよく使われるステータスには、「実行中」「保留中」「成功」「失敗」「キャンセル」「スキップ」があります。このデータは「手戻りと再実行の分析」ダッシュボードに欠かせません。パイプラインの頻繁な失敗は、手戻りや遅延の大きな原因になることがあります。開発効率とコード品質を高めるには、失敗の頻度や発生箇所、影響を分析することが重要です。重要な理由自動ビルドとテストの成功・失敗を追跡し、手戻りの繰り返しやコード品質、自動テストに関する問題を明らかにします。入手先 GitLab CI/CD Pipelines APIの応答にある「status」フィールドから取得します。例成功失敗実行中キャンセル
	マージリクエストのステータス MergeRequestStatus	イベントに関連付けられたマージリクエストのステータスです。「オープン」「マージ済み」「クローズ」などがあります。
説明この属性は、イベント発生時点のマージリクエスト（MR）の状態を記録します。GitLabのMRには、「オープン」「クローズ」「マージ済み」「ロック」の状態があります。開発項目全体のステータスとは別の情報です。 MRのステータスを追跡することは、SDLCのコード統合フェーズを分析するうえで重要です。「コードレビューのサイクルタイムと処理量」などのダッシュボードに利用でき、MRの作成からレビュー、承認、マージまでの遅延を特定するのに役立ちます。重要な理由コードレビューとマージの状況を可視化します。SDLCでは、この工程が重大なボトルネックになることが少なくありません。入手先 GitLab Merge Requests APIの応答にある「state」フィールドから取得します。例未着手マージ済みクローズ済みロック
	マージ先ブランチ TargetBranch	マージリクエストの変更を取り込む先のブランチ名です。
説明マージ先ブランチとは、変更をマージする対象のブランチです。たとえば、「main」「develop」や「release/1.5」のようなリリースブランチがあります。マージリクエストの基本情報の1つです。マージ先ブランチごとに分析すると、異なるブランチへのマージでプロセスにどのような違いがあるかを把握できます。たとえば、「main」へのマージは、機能ブランチへのマージより承認プロセスが厳しく、サイクルタイムも長い場合があります。また、本番環境へのデプロイと、その他のコード統合を区別するのにも役立ちます。重要な理由マージ先ブランチによってプロセスが大きく異なる場合があるため、開発やリリースのワークフローを区別するのに役立ちます。入手先 GitLab Merge Requests APIの応答にある「target_branch」フィールドから取得します。例 maindeveloprelease/v2.1.0hotfix/user-auth-bug
	マイルストーン名 MilestoneTitle	開発項目が割り当てられているマイルストーンまたはスプリントのタイトルです。
説明 GitLabのマイルストーンは、スプリントやリリースバージョンなど、特定の目標や期間に対する作業の進捗を追跡するために使います。この属性には、マイルストーンの名前またはタイトルが記録されます。特定のスプリントや計画期間におけるプロセスのパフォーマンスを分析できます。スプリントごとのサイクルタイムの変化を確認したり、プロセスビューを絞り込んで次回リリースに関係する作業だけを表示したりできます。重要な理由開発作業をスプリントやリリースなどの計画サイクルに関連付け、予定期間に対するパフォーマンスを分析できます。入手先 GitLab IssuesまたはMerge Requests APIの応答にある「milestone.title」フィールドから取得します。例 2023年第4四半期リリーススプリント23.11フェーズ1：MVP
	リリースバージョン ReleaseVersion	デプロイに関連付けられた、予定または実際のソフトウェアバージョンタグです。
説明この属性は、開発項目がどのソフトウェアリリースに含まれるかを示します。GitLabでは、マイルストーン、保護タグ、またはリリース機能のエントリを通じて関連付けることができます。この情報は「リリーススケジュールの遵守状況の追跡」ダッシュボードに欠かせません。リリースバージョンに設定した予定日と実際のデプロイ日を比較することで、組織がスケジュールを守れているかを測定し、リリース遅延の原因を調べられます。重要な理由開発項目を特定のソフトウェアリリースに関連付けます。リリースの進捗とスケジュールの遵守状況を追跡するうえで重要です。入手先 GitLab Releases、Gitタグ名、またはリリース計画に使うマイルストーンのタイトルから取得できます。例 v1.2.0v3.0.0-beta2023.4.1
	最終データ更新日時 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明この属性には、イベントデータが最後に抽出された日時、またはプロセスマイニング用データセットで更新された日時が記録されます。イベントが発生した時刻ではなく、イベントの記録が最後に同期された時刻を示します。データの鮮度を把握し、プロセス分析が適時に行われているかを確認するうえで重要な情報です。ダッシュボードや重要業績評価指標（KPI）が新しいデータに基づいていることを確認でき、ソースシステムと分析データの間に生じる遅れも把握できます。重要な理由データの鮮度を明らかにし、プロセス分析がどの程度最新の状態かを把握できるようにします。入手先データ更新時に、データ抽出ツールまたはETLプロセスによって生成、記録されるタイムスタンプです。例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	引き継ぎ待ち時間 HandoffWaitTime	担当者が異なる連続した2つのアクティビティ間に生じる、計算上の待機時間です。
説明この指標は、あるアクティビティの完了から次のアクティビティの開始までの時間を、担当者が変わる場合に算出します。たとえば、開発者の作業完了からレビュー担当者によるコードレビュー開始までの時間を測定します。「平均引き継ぎ待ち時間」KPIの中心となる指標です。チーム間や担当者間のリソース配分、コミュニケーションに潜む非効率を明らかにし、実作業が行われていない間の遅延を把握できます。重要な理由担当者やチーム間の引き継ぎで発生する待機時間を定量化し、見えにくい遅延やコミュニケーション上のボトルネックを明らかにします。入手先プロセスマイニングツールが算出します。ケース内の連続するイベントを分析し、「担当者」が異なるかを確認したうえで、時間差を計算します。例 1日2時間15分8時間
	手戻りの有無 IsRework	アクティビティが手戻りのループに含まれるかを示す真偽値です。
説明この計算属性は、テスト開始後に開発へ戻るなど、プロセスが後戻りするアクティビティを示します。通常、同じケースで「パイプライン失敗」または「QAテスト開始」の後に「開発開始」が発生するなど、特定のアクティビティの並びを検出して判定します。この属性は「手戻りと再実行の分析」ダッシュボードと「テスト後の手戻り率」KPIに直接使われます。手戻りを簡単に絞り込み、定量化できるため、頻度や原因、プロジェクトのスケジュールへの影響を把握できます。重要な理由手戻りを直接特定して定量化できるため、プロセスの非効率や品質上の問題の原因と影響を分析しやすくなります。入手先プロセスマイニングツールが、ケースごとのアクティビティの順序を分析し、手戻りを示すパターンを特定して算出します。例 truefalse
	開発項目のステータス DevelopmentItemStatus	イベント発生時点での開発項目のステータスです。未着手、進行中、クローズなどがあります。
説明この属性は、主要な作業項目（通常はGitLabの課題）の状態を示します。GitLabの課題にはopenedまたはclosedのstateがあります。より細かなステータスは、Status::TriageやStatus::In-Dev、Status::In-Reviewなどのスコープ付きラベルで管理されることがよくあります。ステータスの変更を追跡すると、ケースのライフサイクルを把握できます。各状態に費やした時間を特定でき、SDLCのエンドツーエンドのサイクルタイムなどのダッシュボードで、進行中または完了済みの作業を絞り込む際にも使えます。重要な理由ケースの状態を示し、各段階に費やした時間の分析や、進行中と完了済みの作業の絞り込みを可能にします。入手先基本のステータスは、GitLabの課題のstateフィールド（opened、closed）から取得します。より細かなステータスは、通常ラベルから導出します。例未着手クローズ済み進行中レビュー中

必須推奨任意

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

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録する主な工程とマイルストーンです。

4 推奨 8 任意

	アクティビティ	説明
	マージリクエストのマージ	コードレビューと統合プロセスが正常に完了したことを示すアクティビティです。ユーザーがマージリクエストのブランチをターゲットブランチにマージしたときに発生する明示的なイベントです。
重要な理由開発とレビューの完了を示す重要な節目です。開発サイクルタイムの測定終了点であり、デプロイまでのリードタイムの測定開始点でもあります。入手先 merge_requestsテーブルのmerged_atタイムスタンプから取得する明示的なイベントです。マージ時にはシステムノートも作成されます。記録マージリクエストのmerged_atタイムスタンプを使用します。イベントタイプ explicit
	マージリクエストの作成	初期の開発作業が完了し、コードがレビューと統合に進める状態になったことを示します。GitLabのワークフローにおける明示的な主要イベントで、開発者が新しいマージリクエスト（MR）を作成したときに記録されます。
重要な理由開発からレビューとテストへの引き継ぎを示す重要な節目です。コードレビューとCI/CDパイプラインのサイクル全体を分析する起点になります。入手先 merge_requestsテーブルのcreated_atタイムスタンプ、またはMerge Requests APIから取得する明示的なイベントです。記録マージリクエストのcreated_atタイムスタンプを使用します。イベントタイプ explicit
	本番環境へのデプロイ	コードが稼働中の本番環境に正常にデプロイされ、エンドユーザーが利用できる状態になったことを示します。GitLabのCI/CDパイプラインで、本番環境へのデプロイ専用ジョブが正常に完了したときに記録されます。
重要な理由これはプロセスの主要な終了イベントで、価値が届けられたことを示します。SDLCのエンドツーエンドのサイクルタイムとリリース頻度を測定するうえで欠かせません。入手先本番環境へのデプロイ専用CI/CDジョブが正常に完了したときのfinished_atタイムスタンプから取得します。GitLabのEnvironments機能で明示的に追跡されます。記録本番環境へのデプロイが正常に完了したCIジョブのfinished_atタイムスタンプを使用します。イベントタイプ explicit
	課題の作成	このアクティビティは開発ライフサイクルの開始を示し、機能追加、不具合、タスクなどの新しい作業項目が作成されたことを表します。GitLabでユーザーが課題を作成すると、その作成日時が記録され、明示的なイベントとして取得されます。
重要な理由これはエンドツーエンドのプロセスにおける主要な開始イベントです。課題の作成からデプロイまでの時間を分析すると、SDLCのサイクルタイム全体を把握できます。入手先これは、issuesテーブルのcreated_atタイムスタンプ、またはIssues APIから取得する明示的なイベントです。システムノートにも作成イベントが記録されます。記録課題のcreated_atタイムスタンプを使用します。イベントタイプ explicit
	コードレビューの開始	マージリクエストのピアレビューが始まったことを示します。作成者以外のユーザーによる最初のコメントやスレッド投稿など、レビューに関連する最初の操作から推定します。
重要な理由 MRの作成からレビュー開始までの時間を測定すると、待ち行列による遅れが明らかになります。この待ち時間を短縮することは、コードレビュー全体のサイクルを短くするうえで重要です。入手先 MRの作成者以外が投稿した最初のコメントまたはレビュースレッドのタイムスタンプから推定します。このデータはシステムノートまたはNotes APIから取得できます。記録 MRの作成者以外による最初のユーザーコメントのタイムスタンプを確認します。イベントタイプ inferred
	デプロイの開始	ステージング環境や本番環境など、特定の環境にコードをリリースするプロセスの開始を表します。GitLabでは、CI/CDパイプライン内のdeployジョブの開始に該当します。
重要な理由デプロイの開始を追跡すると、デプロイ段階にかかる時間を切り分けて把握できます。デプロイまでのリードタイムを測定し、短縮するうえで重要です。入手先デプロイジョブとして設定されたCI/CDジョブのstarted_atタイムスタンプから取得します。これはGitLabのEnvironments and Deployments機能の一部です。記録デプロイタスクのCIジョブログに記録されたstarted_atタイムスタンプを使用します。イベントタイプ explicit
	パイプラインの失敗	ビルドエラーやテスト失敗など、CI/CDパイプラインの実行がいずれかの段階で失敗したときに発生するアクティビティです。GitLabは各パイプラインの最終ステータスを明示的に記録するため、失敗を簡単に特定できます。
重要な理由パイプラインの失敗は、手戻りの主な原因です。発生頻度、継続時間、原因を分析すると、品質上の問題、不安定なテスト、開発者へのフィードバックループにおけるボトルネックを特定できます。入手先 ci_pipelinesテーブルのパイプラインレコードで、ステータスがfailedになっているものを特定します。finished_atタイムスタンプから失敗した時刻を確認できます。記録ステータスがfailedのパイプラインレコードに絞り込み、finished_atタイムスタンプを使用します。イベントタイプ explicit
	パイプラインの開始	ビルド、テスト、セキュリティスキャンなどを実行するCI/CDパイプラインの開始を表します。コミットやMRの作成などをきっかけにパイプラインが実行されると、GitLabは開始タイムスタンプを含むパイプラインレコードを明示的に作成します。
重要な理由パイプラインの実行状況を追跡すると、自動テストや統合プロセスの健全性と効率を監視できます。自動検証にかかる時間の把握にも役立ちます。入手先 ci_pipelinesテーブルのパイプラインレコードにあるcreated_atまたはstarted_atタイムスタンプ、またはPipelines APIから取得します。記録 MRのブランチに関連付けられたパイプライン実行レコードのタイムスタンプを使用します。イベントタイプ explicit
	承認の追加	レビュー担当者がマージリクエストのコード変更を正式に承認したことを表します。ユーザーがApproveボタンをクリックしたときに、GitLabが明示的に記録するイベントです。
重要な理由承認は品質を確保するための重要なゲートです。承認を追跡すると、必要な承認を得るまでの時間を分析し、レビュー方針へのコンプライアンスを確認できます。入手先マージリクエストの承認イベントから取得します。Approvals APIで確認できるほか、MRの履歴にも表示されます。記録マージリクエストの承認イベントログに記録されたタイムスタンプを使用します。イベントタイプ explicit
	課題のクローズ	通常は変更のデプロイと検証が完了した後に、作業項目を最終的に事務処理上クローズしたことを表します。GitLabでユーザーが課題をクローズしたときに記録される明示的なイベントです。
重要な理由課題のクローズは、関連する作業がすべて完了したことを示す場合がよくあります。クローズ時刻とデプロイ時刻を比較すると、デプロイ後の検証や事務処理に遅れがないかを確認できます。入手先 issuesテーブルのclosed_atタイムスタンプ、または対応するシステムノートから取得する明示的なイベントです。記録課題のclosed_atタイムスタンプを使用します。イベントタイプ explicit
	課題の担当者設定	課題が特定の開発者またはチームに割り当てられ、作業の担当が決まったことを表します。GitLabでは、課題の担当者フィールドに値が設定されたとき、または変更されたときに、このイベントが明示的に記録されます。
重要な理由担当者の割り当てを追跡すると、リソース配分、チームの作業負荷、引き継ぎにかかる時間を分析できます。作業の作成から着手までの遅れも特定しやすくなります。入手先課題のシステムノートから取得します。システムノートには、assigneeが追加または変更された日時が記録されます。記録課題のシステムノートからassignee changedイベントを抽出します。イベントタイプ explicit
	開発の開始	このアクティビティは、課題に関する実際のコーディング作業の開始を示します。GitLabには開発開始を明示するボタンがないため、通常は課題に関連付けられたブランチへの最初のコードコミットから推定します。
重要な理由価値を生み出す開発作業の開始時点を特定できます。計画や待ち時間と切り分けて、コーディングにかかった時間を正確に測定できます。入手先課題に関連付けられたフィーチャーブランチの最初のコミットのタイムスタンプから推定します。そのためには課題とブランチの関連付けが必要で、通常は命名規則やメタデータを使います。記録課題IDに関連付けられたブランチで、最初のコミットのタイムスタンプを確認します。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

GitLabのパーソナルアクセストークンを作成します：GitLabアカウントにログインし、「ユーザー設定」>「アクセストークン」に移動します。read_apiスコープ以上を付与した新しいトークンを作成します。このトークンでGitLabのデータにアクセスできるため、安全に保管してください。
プロジェクトのフルパスを確認します：分析対象のGitLabプロジェクトのメインページに移動します。プロジェクト名の下にフルパスが表示されます。通常はgroup/subgroup/project-nameの形式です。
GraphQLクエリの実行環境を準備します：PostmanやInsomnia、PythonやNode.jsなどのスクリプト言語のように、POSTリクエストを送信できるツールを使用します。リクエストURLには、GitLabインスタンスのGraphQLエンドポイントを指定します。GitLab.comの場合はhttps://gitlab.com/api/graphqlです。
リクエストヘッダーを設定します：リクエストに2つのヘッダーを追加します。Content-Typeにはapplication/jsonを設定します。AuthorizationにはBearer [Your Personal Access Token]を設定し、プレースホルダーを作成したトークンに置き換えます。
クエリ変数を設定します：用意されたGraphQLクエリでは、カスタマイズ用の変数を使用します。リクエスト本文にqueryとvariablesの2つのキーを持つJSONオブジェクトを作成します。用意されたスクリプトをqueryの値に貼り付けます。variablesの値では、projectPathにプロジェクトのフルパスを設定し、抽出期間の開始日を指定するcreatedAfterを定義します。
クエリを実行します：設定したPOSTリクエストを送信します。GitLab APIから、要求したプロジェクトデータを含むネストされたJSONオブジェクトが返されます。
ページネーションを処理します：開発項目が多いプロジェクトでは、クエリで1ページあたりに取得できる件数が制限されます。レスポンスには、hasNextPage（真偽値）とendCursor（文字列）を含むpageInfoオブジェクトが含まれます。次のページを取得するには、前回のレスポンスのendCursorの値をissuesAfter変数に渡して、クエリを再実行します。
JSONをフラットなイベントログに変換します：ネストされたJSONレスポンスを表形式に加工します。レスポンス内の各イシューを処理するスクリプトを作成します。各イシューからイベント（作成、担当者割り当て、クローズ）を抽出し、関連するマージリクエストのイベント（作成、承認、パイプライン、マージ、デプロイ）も抽出します。それぞれのイベントをイベントログの個別の行にします。
アクティビティと属性を対応付けます：JSONを処理しながら、データをイベントログの列に割り当てます。たとえば、issue.createdAtは「イシュー作成」アクティビティのStartTimeになります。issue.iidは、関連するすべてのイベントでケースIDとなるDevelopmentItemに使用します。
CSVにエクスポートします：変換が完了し、すべてのイベントをフラットな形式にまとめたら、CSVファイルにエクスポートします。列見出しは、DevelopmentItem、Activity、StartTime、EndTime、Assignee、DevelopmentItemType、Severity、ProjectNameなど、必要な属性名に合わせてください。
ProcessMindにアップロードします：作成したCSVファイルをProcessMindにアップロードすると、分析を開始できます。

設定

GraphQLエンドポイント：クラウド版ではhttps://gitlab.com/api/graphql、セルフホスト版ではhttps://[your-gitlab-domain]/api/graphqlにクエリを送信します。
認証：認証には、read_apiスコープを持つパーソナルアクセストークンが必要です。このトークンはBearerトークンとしてAuthorizationヘッダーに含めます。
プロジェクトパス：データ抽出対象のプロジェクトを指定するため、projectPath変数は必須です。例：'gitlab-org/gitlab'。
日付範囲：createdAfter変数を使い、抽出開始日時をYYYY-MM-DDTHH:MM:SSZ形式で指定します。APIに過度な負荷をかけず、有意義な分析を行うため、3～6か月分のデータを抽出することをおすすめします。
ページネーションの制御：issuesFirst変数で、1回のAPI呼び出しで取得するイシュー数を指定します。大規模で複雑なプロジェクトでは、10件や20件など少ない数にすると、タイムアウトのリスクを抑えられます。すべてのデータを取得するには、スクリプトにページネーションのループを実装してください。
ラベルの命名規則：DevelopmentItemTypeとSeverityの抽出結果は、プロジェクトで使用しているラベルに左右されます。クエリでは、Type::やSeverity::など、特定の接頭辞を持つラベルを検索します。チームの命名規則に合わせて、後処理スクリプト内のパターンを調整してください。

クエリの例 graphql

query getProjectDevData(
  $projectPath: ID!,
  $createdAfter: Time,
  $issuesFirst: Int = 10,
  $issuesAfter: String
) {
  project(fullPath: $projectPath) {
    name
    issues(first: $issuesFirst, after: $issuesAfter, createdAfter: $createdAfter, state: all) {
      pageInfo {
        hasNextPage
        endCursor
      }
      nodes {
        iid
        createdAt
        closedAt
        author {
          username
        }
        assignees(first: 10) {
          nodes {
            username
          }
        }
        labels(first: 20) {
          nodes {
            title
          }
        }
        timelineEvents(first: 100) {
          nodes {
            ... on LabeledEvent {
              createdAt
              user {
                username
              }
            }
            ... on UnlabeledEvent {
              createdAt
              user {
                username
              }
            }
          }
        }
        relatedMergeRequests(first: 10) {
          nodes {
            iid
            createdAt
            author {
              username
            }
            assignees(first: 10) {
              nodes {
                username
              }
            }
            mergedAt
            approvedBy(first: 50) {
              nodes {
                username
                createdAt
              }
            }
            discussions(first: 50) {
              nodes {
                notes(first: 50) {
                  nodes {
                    author {
                      username
                    }
                    createdAt
                  }
                }
              }
            }
            commits(first: 1) {
              nodes {
                authoredDate
              }
            }
            pipelines(first: 20) {
              nodes {
                createdAt
                finishedAt
                status
                jobs(first: 100) {
                  nodes {
                    name
                    startedAt
                    finishedAt
                    status
                    environment {
                      name
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

ステップ

データベースに接続します：セルフホスト版GitLabのPostgreSQLデータベースに対する読み取り専用アクセスを取得します。ホスト、ポート、データベース名、ユーザー名、パスワードが必要です。DBeaver、pgAdmin、コマンドラインツールのpsqlなど、標準的なSQLクライアントで接続します。
対象プロジェクトを確認します：分析対象となるGitLabプロジェクトのフルパスを確認します。パスはgroup/subgroup/projectの形式です。
SQLクエリを調整します：用意されたSQLクエリをSQLクライアントにコピーします。クエリの先頭にあるプレースホルダーの箇所を確認します。
分析パラメーターを設定します：クエリ内のプレースホルダーを編集します。分析期間を指定するため、start_dateとend_dateを設定します。手順2で確認した対象プロジェクトのパスをproject_paths配列に入力します。
クエリを実行します：編集したSQLクエリをGitLabデータベースに対して実行します。実行時間は、GitLabインスタンスの規模と選択した日付範囲によって異なります。
結果を確認します：クエリから、DevelopmentItem、Activity、StartTimeなどの列を含む表形式のイベントログが返されます。結果に問題がないか、簡単に確認してください。
データをCSVにエクスポートします：SQLクライアントから結果全体をCSVファイルにエクスポートします。gitlab_event_log.csvのように、内容が分かるファイル名を付けてください。
アップロード用にCSVを準備します：エクスポートしたCSVファイルが、次の条件を満たしていることを確認してください。
- ファイルの文字コードがUTF-8であること。
- 1行目に、クエリで出力された正確な列名（DevelopmentItem、Activity、StartTimeなど）が含まれていること。
- タイムスタンプが、ProcessMindで解析できるYYYY-MM-DD HH24:MI:SSなどの形式であること。
ProcessMindにアップロードします：分析を始めるには、最終版のCSVファイルをProcessMindのプロジェクトにアップロードします。

設定

プロジェクトフィルター：クエリ内のproject_paths変数で分析対象を指定します。ARRAY['group/project-a', 'group/project-b']のように、プロジェクトのフルパスを配列で指定してください。
日付範囲：start_dateとend_dateの各変数で、データの抽出期間を指定します。有意義なデータを確保しながらクエリの処理性能を保つため、まずは3～6か月分を対象にすることをおすすめします。
データベース権限：GitLabの本番データベースまたはレプリカデータベースに対する読み取り専用アクセス権を持つユーザーが必要です。具体的には、issues、projects、merge_requests、notes、ci_pipelines、ci_builds、deployments、usersなどのテーブルに対するSELECT権限が必要です。
パフォーマンスに関する考慮事項：規模が大きく稼働中のGitLabデータベースに対する直接クエリは、リソースを多く消費する場合があります。本番環境への影響を避けるため、利用の少ない時間帯に実行するか、読み取りレプリカデータベースを使うことを強くおすすめします。

クエリの例 sql

WITH vars AS (
    SELECT
        '2023-01-01'::timestamp AS start_date,
        '2024-01-01'::timestamp AS end_date,
        ARRAY['your-group/your-project'] AS project_paths
),
issue_base AS (
    SELECT i.id, i.iid, i.project_id, i.author_id, i.assignee_id, i.created_at
    FROM issues i
    JOIN projects p ON i.project_id = p.id
    JOIN namespaces n ON p.namespace_id = n.id
    WHERE p.path_with_namespace = ANY((SELECT project_paths FROM vars))
    AND i.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)
)

-- 1. Issue Created
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Created' AS "Activity",
    i.created_at AS "StartTime",
    i.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    l.name AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM issues i
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
LEFT JOIN label_links ll ON ll.target_id = i.id AND ll.target_type = 'Issue'
LEFT JOIN labels l ON l.id = ll.label_id AND l.name IN ('Feature', 'Bug', 'Task', 'Maintenance')

UNION ALL

-- 2. Issue Assigned
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Assigned' AS "Activity",
    n.created_at AS "StartTime",
    n.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM notes n
JOIN system_note_metadata snm ON n.id = snm.note_id
JOIN issues i ON n.noteable_id = i.id AND n.noteable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
WHERE snm.action = 'assignee'
AND n.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 3. Development Started (First commit on a related MR)
SELECT
    sub.DevelopmentItem,
    'Development Started' AS "Activity",
    sub.first_commit_date AS "StartTime",
    sub.first_commit_date AS "EndTime",
    sub.Assignee,
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    sub.ProjectName
FROM (
    SELECT 
        p.path_with_namespace || '!' || i.iid AS DevelopmentItem,
        c.committed_date as first_commit_date,
        u_assignee.username AS Assignee,
        p.name as ProjectName,
        ROW_NUMBER() OVER(PARTITION BY i.id ORDER BY c.committed_date ASC) as rn
    FROM merge_requests_closing_issues mrc
    JOIN merge_requests mr ON mrc.merge_request_id = mr.id
    JOIN issues i ON mrc.issue_id = i.id
    JOIN issue_base ib ON i.id = ib.id
    JOIN projects p ON i.project_id = p.id
    JOIN merge_request_diffs mrd ON mr.latest_merge_request_diff_id = mrd.id
    JOIN merge_request_diff_commits mrdc ON mrd.id = mrdc.merge_request_diff_id
    JOIN commits c ON mrdc.sha = c.sha
    LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
) sub
WHERE sub.rn = 1

UNION ALL

-- 4. Merge Request Created
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Merge Request Created' AS "Activity",
    mr.created_at AS "StartTime",
    mr.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM merge_requests_closing_issues mrc
JOIN merge_requests mr ON mrc.merge_request_id = mr.id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE mr.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 5. Pipeline Started
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Pipeline Started' AS "Activity",
    pipe.created_at AS "StartTime",
    pipe.finished_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM ci_pipelines pipe
JOIN merge_requests mr ON pipe.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE pipe.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 6. Pipeline Failed
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Pipeline Failed' AS "Activity",
    pipe.finished_at AS "StartTime",
    pipe.finished_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM ci_pipelines pipe
JOIN merge_requests mr ON pipe.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE pipe.status = 'failed'
AND pipe.finished_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 7. Code Review Started (First comment on MR by a non-author)
SELECT
    sub.DevelopmentItem,
    'Code Review Started' AS "Activity",
    sub.first_comment_time AS "StartTime",
    sub.first_comment_time AS "EndTime",
    sub.Assignee,
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    sub.ProjectName
FROM (
    SELECT 
        p.path_with_namespace || '!' || i.iid AS DevelopmentItem,
        n.created_at AS first_comment_time,
        u_assignee.username AS Assignee,
        p.name AS ProjectName,
        ROW_NUMBER() OVER(PARTITION BY mr.id ORDER BY n.created_at ASC) as rn
    FROM notes n
    JOIN merge_requests mr ON n.noteable_id = mr.id AND n.noteable_type = 'MergeRequest'
    JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
    JOIN issues i ON mrc.issue_id = i.id
    JOIN issue_base ib ON i.id = ib.id
    JOIN projects p ON mr.target_project_id = p.id
    LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
    WHERE n.author_id != mr.author_id AND n.system = false
    AND n.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)
) sub
WHERE sub.rn = 1

UNION ALL

-- 8. Approval Added
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Approval Added' AS "Activity",
    a.created_at AS "StartTime",
    a.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM approvals a
JOIN merge_requests mr ON a.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE a.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 9. Merge Request Merged
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Merge Request Merged' AS "Activity",
    mr.merged_at AS "StartTime",
    mr.merged_at AS "EndTime",
    u_merger.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM merge_requests_closing_issues mrc
JOIN merge_requests mr ON mrc.merge_request_id = mr.id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_merger ON mr.merge_user_id = u_merger.id
WHERE mr.merged_at IS NOT NULL
AND mr.merged_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 10. Deployment Started
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Deployment Started' AS "Activity",
    d.created_at AS "StartTime",
    d.finished_at AS "EndTime",
    u_deployer.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM deployments d
JOIN projects p ON d.project_id = p.id
JOIN environments e ON d.environment_id = e.id
JOIN issues i ON d.deployable_id = i.id AND d.deployable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
LEFT JOIN users u_deployer ON d.user_id = u_deployer.id
WHERE d.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 11. Deployed To Production
SELECT 
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Deployed To Production' AS "Activity",
    d.finished_at AS "StartTime",
    d.finished_at AS "EndTime",
    u_deployer.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM deployments d
JOIN projects p ON d.project_id = p.id
JOIN environments e ON d.environment_id = e.id
JOIN issues i ON d.deployable_id = i.id AND d.deployable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
LEFT JOIN users u_deployer ON d.user_id = u_deployer.id
WHERE e.name = 'production' AND d.status = 2 -- success
AND d.finished_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 12. Issue Closed
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Closed' AS "Activity",
    i.closed_at AS "StartTime",
    i.closed_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM issues i
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
WHERE i.closed_at IS NOT NULL
AND i.closed_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars);

ステップ

前提条件：システムにPython 3.6以降がインストールされていることを確認します。pipを使って、必要なpython-gitlabライブラリとpandasライブラリをインストールします。ターミナルまたはコマンドプロンプトを開き、pip install python-gitlab pandasを実行してください。
GitLabアクセストークンを作成します：GitLabインスタンスにログインし、ユーザー設定から「アクセストークン」に移動します。新しいパーソナルアクセストークン（PAT）を作成します。内容が分かる名前を付け、apiとread_apiのスコープを付与します。生成されたトークンは後から確認できないため、安全な場所にコピーしてください。
スクリプトを設定します：extract_gitlab_log.pyなどの新しいPythonファイルを作成し、用意されたスクリプトコードを貼り付けます。スクリプトの先頭にある設定部分を編集します。GitLabインスタンスのURL、プライベートアクセストークン、分析対象のプロジェクトID一覧、データ抽出の開始日を指定してください。
プロジェクトIDを確認します：プロジェクトIDを確認するには、GitLabの画面で対象プロジェクトのメインページに移動します。通常、プロジェクト名のすぐ下にプロジェクトIDが表示されています。
抽出スクリプトを実行します：ターミナルでpython extract_gitlab_log.pyを実行します。スクリプトがGitLab APIに接続し、データの取得を開始します。各プロジェクトとマージリクエストの処理状況がコンソールに表示されます。
実行状況を確認します：プロジェクト数や日付範囲によっては、API呼び出しが多くなるため、スクリプトの実行にかなりの時間がかかる場合があります。認証エラーやネットワークの問題などが発生していないか、コンソールを確認してください。
出力データを確認します：スクリプトが正常に完了すると、同じディレクトリにgitlab_event_log.csvというファイルが作成されます。このファイルには、生のイベントログが含まれています。
データの変換と書式設定：スクリプトは、タイムスタンプをISO 8601形式（YYYY-MM-DDTHH:MM:SSZ）に自動で整えます。個別のイベントでは、EndTime列にStartTimeと同じ値が設定されます。これはプロセスマイニングのイベントログで一般的な方法です。
アップロードの準備をします：作成されるCSVファイルには、DevelopmentItem、Activity、StartTimeなど、必要な列と推奨される属性が含まれます。ファイルはProcessMindにアップロードできる状態です。通常、追加の書式設定は必要ありません。

設定

GitLab URL：GitLabインスタンスのベースURLです。クラウド版の場合はhttps://gitlab.com、セルフホスト版の場合は独自のURLを指定します。
パーソナルアクセストークン：認証には、apiとread_apiのスコープを持つ有効なGitLabパーソナルアクセストークンが必要です。このトークンは、対象プロジェクトで少なくとも「レポーター」権限を持つユーザーのものを使用してください。
プロジェクトID：抽出対象に含めるプロジェクトIDを整数のリストで指定します。パフォーマンスと分析の関連性を保つため、対象プロジェクトを絞り込むことが重要です。
開始日：この日付以降に作成されたイシューとマージリクエストを抽出するため、ISO形式の日付文字列（例：'2023-01-01T00:00:00Z'）を指定します。抽出するデータ量を抑えるのに役立ちます。データ量を運用しやすい範囲に保つため、直近3～6か月など、最近の期間から始めることをおすすめします。
本番環境名：スクリプトにはPRODUCTION_JOB_NAMEというプレースホルダー変数があります。本番環境にコードをデプロイするCI/CDジョブの正確な名前を設定してください。「本番環境にデプロイ」アクティビティを正確に記録するために必要です。

クエリの例 python

import gitlab
import pandas as pd
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your GitLab instance URL, Private Access Token, and Project IDs
GITLAB_URL = os.environ.get(class="hl-string">'GITLAB_URL', class="hl-string">'[Your GitLab URL, e.g., https://gitlab.com]')
GITLAB_PRIVATE_TOKEN = os.environ.get(class="hl-string">'GITLAB_PRIVATE_TOKEN', class="hl-string">'[Your Personal Access Token]')
PROJECT_IDS = [12345, 67890]  class=class="hl-string">"hl-comment"># Replace with your target project IDs
SINCE_DATE = class="hl-string">'2023-01-01T00:00:00Z'  class=class="hl-string">"hl-comment"># Fetch data created after this date
PRODUCTION_JOB_NAME = class="hl-string">'deploy_production' class=class="hl-string">"hl-comment"># The exact name of your production deployment job

events = []

def add_event(case_id, activity, timestamp, end_timestamp=None, assignee=None, item_type=None, severity=None, project_name=None):
    class="hl-string">"""Helper function to add a new event to the list."""
    if timestamp:
        events.append({
            class="hl-string">'DevelopmentItem': case_id,
            class="hl-string">'Activity': activity,
            class="hl-string">'StartTime': pd.to_datetime(timestamp).isoformat() + class="hl-string">'Z',
            class="hl-string">'EndTime': pd.to_datetime(end_timestamp or timestamp).isoformat() + class="hl-string">'Z',
            class="hl-string">'Assignee': assignee,
            class="hl-string">'DevelopmentItemType': item_type,
            class="hl-string">'Severity': severity,
            class="hl-string">'ProjectName': project_name
        })

class=class="hl-string">"hl-comment"># Initialize GitLab API client
try:
    gl = gitlab.Gitlab(GITLAB_URL, private_token=GITLAB_PRIVATE_TOKEN)
    gl.auth()
    print(class="hl-string">"Successfully authenticated with GitLab.")
except Exception as e:
    print(fclass="hl-string">"Authentication failed: {e}")
    exit()

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
for project_id in PROJECT_IDS:
    try:
        project = gl.projects.get(project_id)
        print(fclass="hl-string">"\nProcessing project: {project.name_with_namespace}")

        class=class="hl-string">"hl-comment"># Process Issues first to establish the case ID
        issues = project.issues.list(all=True, created_after=SINCE_DATE)
        for issue in issues:
            print(fclass="hl-string">"  Processing Issue class="hl-commentclass="hl-string">">#{issue.iid}")
            case_id = fclass="hl-string">"{project.name_with_namespace}-I-{issue.iid}"
            assignee_name = issue.assignee[class="hl-string">'name'] if issue.assignee else None
            item_type = class="hl-string">'Bug' if class="hl-string">'bug' in [label.lower() for label in issue.labels] else class="hl-string">'Feature'

            class=class="hl-string">"hl-comment"># Activity: Issue Created
            add_event(case_id, class="hl-string">'Issue Created', issue.created_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activity: Issue Assigned
            try:
                state_events = issue.resourcestateevents.list(all=True)
                for event in sorted(state_events, key=lambda x: x.created_at):
                    if event.action == class="hl-string">'add' and hasattr(event, class="hl-string">'user'):
                        add_event(case_id, class="hl-string">'Issue Assigned', event.created_at, assignee=event.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        break class=class="hl-string">"hl-comment"># Capture first assignment only
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch state events for issue {issue.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Issue Closed
            if issue.closed_at:
                add_event(case_id, class="hl-string">'Issue Closed', issue.closed_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

        class=class="hl-string">"hl-comment"># Process Merge Requests and link them to issues
        mrs = project.mergerequests.list(all=True, created_after=SINCE_DATE)
        for mr in mrs:
            print(fclass="hl-string">"  Processing MR !{mr.iid}")
            class=class="hl-string">"hl-comment"># Find the closing issue to use as the case_id
            closing_issues = mr.closes_issues()
            if not closing_issues:
                continue class=class="hl-string">"hl-comment"># Skip MRs not linked to an issue

            class=class="hl-string">"hl-comment"># Assuming one MR closes one issue for simplicity
            linked_issue_iid = closing_issues[0][class="hl-string">'iid']
            case_id = fclass="hl-string">"{project.name_with_namespace}-I-{linked_issue_iid}"
            assignee_name = mr.assignee[class="hl-string">'name'] if mr.assignee else None
            item_type = class="hl-string">'Bug' if class="hl-string">'bug' in [label.lower() for label in mr.labels] else class="hl-string">'Feature'

            class=class="hl-string">"hl-comment"># Activity: Merge Request Created
            add_event(case_id, class="hl-string">'Merge Request Created', mr.created_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activity: Development Started (first commit)
            try:
                commits = mr.commits()
                if commits:
                    first_commit = commits[-1] class=class="hl-string">"hl-comment"># Commits are listed newest first
                    add_event(case_id, class="hl-string">'Development Started', first_commit.created_at, assignee=mr.author[class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch commits for MR {mr.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Code Review Started (first comment by non-author)
            try:
                notes = mr.notes.list(all=True, sort=class="hl-string">'asc')
                for note in notes:
                    if not note.system and note.author[class="hl-string">'id'] != mr.author[class="hl-string">'id']:
                        add_event(case_id, class="hl-string">'Code Review Started', note.created_at, assignee=note.author[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        break
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch notes for MR {mr.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Approval Added
            try:
                approvals = mr.approvals.get()
                for approver in approvals.approved_by:
                    add_event(case_id, class="hl-string">'Approval Added', approver[class="hl-string">'approved_at'], assignee=approver[class="hl-string">'user'][class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch approvals for MR {mr.iid}: {e}")
            
            class=class="hl-string">"hl-comment"># Activity: Merge Request Merged
            if mr.merged_at:
                add_event(case_id, class="hl-string">'Merge Request Merged', mr.merged_at, assignee=mr.merged_by[class="hl-string">'name'], item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activities from Pipelines
            try:
                pipelines = mr.pipelines()
                for p in pipelines:
                    pipeline = project.pipelines.get(p[class="hl-string">'id'])
                    add_event(case_id, class="hl-string">'Pipeline Started', pipeline.created_at, assignee=pipeline.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                    if pipeline.status == class="hl-string">'failed':
                        add_event(case_id, class="hl-string">'Pipeline Failed', pipeline.finished_at, assignee=pipeline.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                    
                    class=class="hl-string">"hl-comment"># Activities from Jobs in the pipeline
                    jobs = pipeline.jobs.list(all=True)
                    for job in jobs:
                        if class="hl-string">'deploy' in job.name.lower() and job.started_at:
                            add_event(case_id, class="hl-string">'Deployment Started', job.started_at, assignee=job.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        if job.name == PRODUCTION_JOB_NAME and job.status == class="hl-string">'success' and job.finished_at:
                            add_event(case_id, class="hl-string">'Deployed To Production', job.finished_at, assignee=job.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch pipelines/jobs for MR {mr.iid}: {e}")

    except gitlab.exceptions.GitlabError as e:
        print(fclass="hl-string">"Error processing project {project_id}: {e}")

class=class="hl-string">"hl-comment"># --- Create and Save DataFrame ---
if events:
    df = pd.DataFrame(events)
    df_sorted = df.sort_values(by=[class="hl-string">'DevelopmentItem', class="hl-string">'StartTime'], ascending=[True, True])
    df_sorted.to_csv(class="hl-string">'gitlab_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to gitlab_event_log.csv")
else:
    print(class="hl-string">"\nExtraction complete. No events found for the given projects and date range.")

ステップ

イベント受信サービスを準備します：GitLabを設定する前に、イベントを受信するサービスをデプロイします。これは、公開URLを持ち、HTTP POSTリクエストを受信して処理できるWebアプリケーションです。このサービスで、GitLabのイベントペイロードを必要なイベントログ形式に変換します。
変換処理を実装します：イベント受信サービスに、GitLabから届くJSONペイロードを解析するコードを作成します。イベントの種類（object_kind）とアクションを、指定されたアクティビティに対応付けます。たとえば、action: 'open'のissueイベントは、「イシュー作成」アクティビティに対応します。
GitLabのWebhook設定に移動します：GitLabインスタンスにログインし、監視対象のプロジェクトに移動します。左側のナビゲーションから「設定」>「Webhook」を開きます。
Webhook URLを設定します：URL欄に、手順1で準備したイベント受信サービスのエンドポイントURLを入力します。URL全体に外部からアクセスできる必要があります。
シークレットトークンを設定します：セキュリティ対策として、長くランダムな文字列をシークレットトークンに設定します。対応する欄に入力してください。送信元を確認できるよう、イベント受信サービス側で、すべてのリクエストのX-Gitlab-Tokenヘッダーに含まれるトークンを検証する必要があります。
トリガーイベントを選択します：「トリガー」セクションで、ソフトウェア開発ライフサイクル全体を記録するために必要なイベントをすべて選択します。「プッシュイベント」「イシューイベント」「機密イシューイベント」「マージリクエストイベント」「ノートイベント」「ジョブイベント」「パイプラインイベント」の各チェックボックスをオンにします。
Webhookを追加します：「SSL証明書の検証を有効にする」チェックボックスがオンになっていることを確認します。「Webhookを追加」ボタンをクリックして設定を保存します。接続を確認するため、GitLabから指定したURLにテストイベントがすぐに送信されます。
推定イベントの処理を実装します：GitLabで直接発生するイベントではなく、イベント受信サービス側で推定する必要があるアクティビティもあります。「開発開始」については、イシューに関連付けられた最初の「プッシュイベント」を検出します。「コードレビュー開始」については、作成者以外のユーザーが作成したマージリクエスト上で、最初の「ノートイベント」（コメント）を検出します。
デプロイイベントを処理します：「デプロイ開始」と「本番環境にデプロイ」のアクティビティは、「ジョブイベント」から取得します。deploy_stagingやdeploy_productionなど、特定の名前のジョブを対象にイベントを解析し、ステータス（runningまたはsuccess）を確認します。
イベントログデータを保存します：有効なWebhookを処理するたびに、データベースやCSVファイルなど、選択したデータストアに新しい行をすぐに書き込みます。各行には、少なくともDevelopmentItem（イシューまたはMRのID）、アクティビティ、StartTimeを含めます。
データを確定してエクスポートします：一定期間データを収集したら、データストアからイベントログをCSVファイルにエクスポートします。列見出しがProcessMindの要件に合っていることを確認してください。例：DevelopmentItem、Activity、StartTime。

設定

URL：Webhookペイロードを受信する、独自のイベント受信サービスのエンドポイントです。安定しており、外部からアクセスできるURLを指定してください。
シークレットトークン：受信リクエストが正当なもので、GitLabから送信されたことをイベント受信サービスが確認するためのセキュリティキーです。重要なセキュリティ対策です。
トリガーイベント：エンドポイントに送信するGitLabイベントを指定します。ライフサイクル全体を記録するには、イシュー、プッシュ、マージリクエスト、ノート、パイプライン、ジョブなど、必要なイベントを有効にします。
範囲：Webhookは、単一のリポジトリを対象にプロジェクト単位で設定する方法と、1つの設定でグループ内のすべてのプロジェクトを監視するグループ単位の方法があります。
イベント受信サービスのロジック：この方法では、独自に開発するアプリケーションのロジックが最も重要です。形式の異なるJSONペイロードを解析し、「開発開始」などのアクティビティを推定して、イベントデータを構造化されたイベントログ形式に対応付けます。
前提条件：この方法を利用するには、GitLabプロジェクトまたはグループでメンテナーまたはオーナーの権限が必要です。また、イベント受信エンドポイントとして機能するWebサービスを別途開発する必要があります。

クエリの例 json

{
  "url": "https://[your-listening-service-url.com]/webhook-endpoint",
  "secret_token": "[your-secure-secret-token]",
  "merge_requests_events": true,
  "push_events": true,
  "issues_events": true,
  "note_events": true,
  "job_events": true,
  "pipeline_events": true,
  "wiki_page_events": false,
  "releases_events": false,
  "confidential_issues_events": true,
  "confidential_note_events": true,
  "enable_ssl_verification": true
}

準備はできましたか？

このテンプレートを使ってデータを準備し、ソフトウェア開発ライフサイクルの改善を始めましょう。今日からプロセスの見直しに取り組めます。

改善ガイドに戻る

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

ソフトウェア開発ライフサイクルを改善：今すぐ最適化を開始

SDLCのボトルネックを解消し、サイクルタイムを30％短縮して、品質を高めましょう。

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

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

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

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

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

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

データ抽出ガイド

GitLab GraphQL APIによる開発ライフサイクルイベントの取得

ステップ

設定

クエリの例 graphql

GitLab PostgreSQLデータベースへの直接クエリによるイベント取得

ステップ

設定

クエリの例 sql

GitLab REST APIクライアントライブラリを使ったPythonスクリプト

ステップ

設定

クエリの例 python

GitLabシステムWebhookによるリアルタイムイベントの取得

ステップ

設定

クエリの例 json

準備はできましたか？

ソフトウェア開発ライフサイクルを改善：今すぐ最適化を開始