GitLabが持つ、強力な分析機能一式
1. はじめに
ソフトウェア開発において、「何を測定するか」は「何を改善できるか」に直結します。GitLabは単なるバージョン管理システムではなく、開発プロセス全体を可視化し、データに基づいた意思決定を可能にする包括的なアナリティクス機能を提供しています。
本記事では、GitLabが提供する各種アナリティクス機能について、技術的な観点から詳しく解説します。これらの機能を活用することで、チームのパフォーマンスを定量的に把握し、継続的な改善につなげることができます。
2. アナリティクス機能の全体像
GitLabのアナリティクス機能は、以下のような階層構造で提供されています。
3. Value Streams Dashboard：組織全体のパフォーマンスを俯瞰する
3.1 概要と対象ティア
- 対象ティア: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Value Streams Dashboardは、組織のDevOpsパフォーマンスを包括的に可視化するカスタマイズ可能なダッシュボードです。すべてのステークホルダーが同じメトリクスセットにアクセスできる単一の情報源（SSOT）として機能します。
3.2 主要な表示内容
Value Streams Dashboardは以下のメトリクスを可視化します。
3.2.1 DORAメトリクス
開発速度と安定性を測定する4つの指標を提供します。
3.2.2 Value Stream Analytics（VSA）フローメトリクス
- Lead time: Issueが作成されてからクローズされるまでの中央値
- Cycle time: 最初のコミットからIssueクローズまでの中央値
- Issues created/closed: 新規作成数とクローズ数
- Merge request throughput: マージされたMRの数
- Median time to merge: MR作成からマージまでの中央値
3.2.3 脆弱性メトリクス
- Critical/High脆弱性の経時変化
3.2.4 GitLab Duo使用状況
- Duoを使用した貢献者数
- Code Suggestions使用率
- Code Suggestions受け入れ率
3.3 ダッシュボードのパネル構成
3.3.1 Overview Panel
トップレベルのネームスペースアクティビティの全体像を提供します。データは月次でバッチ処理により集計されます。
3.3.2 DevSecOps Metrics Comparison
過去6ヶ月間のグループまたはプロジェクトのメトリクスを表示します。以下の3つの比較パネルが含まれます。
- Lifecycle metrics: 基本的な開発メトリクス
- DORA metrics (Ultimate): 4つのDORA指標
- Security metrics (Ultimate、Developer以上): セキュリティ関連指標
各パネルでは以下が可能です。
- グループ、プロジェクト、チーム間のパフォーマンス比較
- 価値貢献度の高いチーム・プロジェクトの特定
- メトリクスの詳細分析へのドリルダウン
Change %カラムは、6ヶ月前と比較した前月からの増減率を示します。Trendカラムのスパークラインは、青（ネガティブ）から緑（ポジティブ）の色で傾向を表示します。
3.3.3 DORA Performers Score（Ultimate）
組織のDevOpsパフォーマンスレベルを、プロジェクトごとにHigh、Medium、Lowの3段階で可視化します。
各DORAメトリクスのスコア基準：
| メトリクス | High | Medium | Low | 説明 |
|---|---|---|---|---|
| Deployment Frequency | ≥30 | 1-29 | <1 | 1日あたりの本番デプロイ数 |
| Lead Time for Changes | ≤7 | 8-29 | ≥30 | コミットから本番稼働までの日数 |
| Time to Restore Service | ≤1 | 2-6 | ≥7 | サービス復旧までの日数 |
| Change Failure Rate | ≤15% | 16%-44% | ≥45% | 本番障害を引き起こした変更の割合 |
3.4 カスタムダッシュボードの作成
Value Streams Dashboardは、YAMLファイルでカスタマイズできます。
3.4.1 設定手順
- グループのSettings > Analyticsで、ダッシュボード設定ファイルを保存するプロジェクトを選択
- プロジェクトのデフォルトブランチに
.gitlab/analytics/dashboards/value_streams/value_streams.yamlを作成 - 設定ファイルに以下の内容を記述
3.4.2 設定例
# version - アナリティクスダッシュボードスキーマの最新バージョン
version: '2'
# title - Value Streams Dashboardのタイトルを変更
title: 'カスタムダッシュボードタイトル'
# description - Value Streams Dashboardの説明を変更（オプション）
description: 'カスタム説明'
# panels - パネル設定のリスト
panels:
- title: 'グループ使用状況概要'
visualization: usage_overview
queryOverrides:
namespace: group
filters:
include:
- groups
- projects
gridAttributes:
yPos: 1
xPos: 1
height: 1
width: 12
- title: 'グループDORAとIssueメトリクス'
visualization: ai_impact_table
queryOverrides:
namespace: group
filters:
includeMetrics:
- deployment_frequency
- deploys
gridAttributes:
yPos: 2
xPos: 1
height: 12
width: 12
- title: 'DORAパフォーマンススコア'
visualization: dora_performers_score
queryOverrides:
namespace: group/my-project
filters:
projectTopics:
- ruby
- javascript
gridAttributes:
yPos: 26
xPos: 1
height: 12
width: 12
3.4.3 設定パラメータ
| フィールド | 説明 |
|---|---|
| title | パネルのカスタム名 |
| queryOverrides | 各可視化に固有のデータクエリパラメータ |
| namespace | パネルに使用するグループまたはプロジェクトのパス |
| filters | サポートされている可視化タイプごとのクエリフィルタ |
| visualization | レンダリングする可視化のタイプ |
| gridAttributes | パネルのサイズと位置 |
3.5 レポートのスケジュール実行
CI/CDコンポーネント「Value Streams Dashboard Scheduled Reports」ツールを使用して、定期的なレポート生成を自動化できます。
このツールは以下を実行します。
- GitLab GraphQL APIを通じてプロジェクトまたはグループからメトリクスを収集
- GitLab Flavored Markdownでレポートを作成
- 指定プロジェクトにIssueを作成し、比較メトリクステーブルを含める
これにより、意思決定者がタイムリーで関連性の高い情報を確実に受け取ることができます。
4. Value Stream Analytics：開発フローの各ステージを詳細分析
4.1 概要と対象ティア
- 対象ティア: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Value Stream Analyticsは、ソフトウェア開発プロセスの各ステージの所要時間を計算します。アイデアから本番環境までの時間を、MRまたはIssueイベントを追跡することで測定します。
4.2 構造的理解
4.2.1 Value Stream（バリューストリーム）
顧客に価値を提供する全体的な作業プロセスです。グループごとに複数のValue Streamを持つことができ、DevOpsライフサイクルの異なる側面に焦点を当てられます。
4.2.2 Value Stream Stage（ステージ）
開始イベントと終了イベントのペアと追加のメタデータ（ステージ名など）を表します。デフォルトステージを使用することも、カスタムステージを作成することもできます。
4.2.3 Value Stream Stage Events（イベント）
ステージの開始と終了を定義する構成要素です。GitLabは以下の計算式でステージ期間を算出します。
ステージ期間 = 終了イベント時刻 - 開始イベント時刻
4.3 サポートされるイベント
GitLabは以下のイベントをサポートしています。
Issueイベント:
- Issue closed
- Issue created
- Issue first added to a board
- Issue first added to iteration
- Issue first assigned
- Issue first associated with a milestone
- Issue first mentioned in a commit
- Issue label added
- Issue label removed
Merge Requestイベント:
- Merge request closed
- Merge request created
- Merge request first assigned
- Merge request first committed
- Merge request first deployed to production
- Merge request label added
- Merge request label removed
- Merge request last approved
- Merge request last build finished
- Merge request last build started
- Merge request merged
- Merge request reviewer first assigned
4.4 データ集約とパフォーマンス
Value Stream Analyticsは、バックエンドプロセスを使用してステージレベルのデータを収集・集約します。これにより、大規模グループでもスケール可能です。
データ処理には通常10分程度かかりますが、以下の場合はさらに時間がかかる可能性があります。
- 初めてValue Stream Analyticsを表示する場合
- グループ階層が再編成された場合
- IssueやMRの一括更新が行われた場合
最終更新時刻は、ページ右上の「Last updated」バッジで確認できます。
4.5 デフォルトステージの測定方法
| ステージ | 測定方法 |
|---|---|
| Issue | Issue作成から最初のアクション（ラベル追加またはマイルストーン追加）までの中央値 |
| Plan | 前ステージのアクションからブランチへの最初のコミットまでの中央値 |
| Code | 最初のコミットからMR作成までの中央値 |
| Test | パイプライン全体の実行時間の中央値 |
| Review | MR作成からマージまでの中央値（closing issue patternを含むもの） |
| Staging | MRマージから本番環境への最初のデプロイまでの中央値 |
4.6 ワークフロー例
1日で7つのステージすべてを通過する例を見てみましょう。
各ステージの記録時間：
- Issue: 09:00 - 11:00 = 2時間
- Plan: 11:00 - 12:00 = 1時間
- Code: 12:00 - 14:00 = 2時間
- Test: 5分
- Review: 14:00 - 19:00 = 5時間
- Staging: 19:00 - 19:30 = 30分
4.7 カスタムValue Streamの作成
4.7.1 デフォルトステージを使用する場合
- Analyze > Value Stream analyticsに移動
- 「New Value Stream」を選択
- Value Stream名を入力
- 「Create from default template」を選択
- ステージをカスタマイズ
- 順序変更：上下矢印を使用
- 非表示：Hide（👁）を選択
- カスタムステージ追加：「Add a stage」を選択
- 「New value stream」を選択
4.7.2 カスタムステージを使用する場合
- Analyze > Value Stream analyticsに移動
- 「New value stream」を選択
- 各ステージについて：
- ステージ名を入力
- Start eventとStop eventを選択
- 別のステージを追加する場合は「Add a stage」を選択
- ステージを並び替えるには上下矢印を使用
- 「New value stream」を選択
4.8 ラベルベースステージの活用
複雑なワークフローを測定するために、スコープ付きラベルを使用できます。
例：ステージング環境から本番環境へのデプロイ時間を測定する場合
このように設定することで、環境間の移行時間を正確に追跡できます。
4.9 累積ラベルイベント期間
GitLab 16.10以降、ラベルベースステージでは繰り返しイベントの期間を累積的に測定します。
例：
- 9:00: ラベル追加
- 10:00: ラベル削除
- 12:00: ラベル再追加
- 14:00: ラベル削除
従来の計算：5時間（9:00から14:00）
累積計算：3時間（9:00-10:00 + 12:00-14:00）
この機能により、実際の作業時間をより正確に把握できます。
4.10 GraphQL APIでのメトリクス取得
Value Stream AnalyticsはGraphQL APIを通じてもアクセスできます。
4.10.1 Value Stream一覧の取得
group(fullPath: "your-group-path") {
valueStreams {
nodes {
id
name
}
}
}
4.10.2 ステージメトリクスの取得
group(fullPath: "your-group-path") {
valueStreams(id: "your-value-stream-id") {
nodes {
stages(id: "your-stage-id") {
id
name
metrics(
labelNames: ["backend"],
milestoneTitle: "17.0",
timeframe: { start: "2024-03-01", end: "2024-03-31" }
) {
average {
value
unit
}
median {
value
unit
}
count {
value
unit
}
}
}
}
}
}
4.11 ベストプラクティス
- タイムリーなデータ取得: 期間の終わりに近いタイミングでメトリクスを取得
- 定期レポート: スケジュールパイプライン機能を使用してスクリプトを作成
- データの変動追跡: 過去の期間のメトリクスを再取得し、以前のデータと比較
- データスキューの発見: プロジェクトの移動や削除がメトリクスに与える影響を把握
5. DORAメトリクス：業界標準でパフォーマンスを測定
5.1 概要と対象ティア
- 対象ティア: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
DORAメトリクスは、DevOpsパフォーマンスに関するエビデンスベースのインサイトを提供します。4つの主要な測定値により、チームがどれだけ速く変更を提供し、それらの変更が本番環境でどの程度機能するかを示します。
5.2 DORAメトリクスの2つの側面
5.3 Deployment Frequency（デプロイ頻度）
5.3.1 定義
指定された期間における本番環境への成功したデプロイの頻度です。
5.3.2 ビジネス上の意義
デプロイ頻度が高いということは、より早くフィードバックを得られ、より速く反復して改善や機能を提供できることを意味します。これにより、顧客の要求や新しい市場機会に迅速に対応できます。
5.3.3 計算方法
GitLabでは、デプロイ頻度は以下のように計算されます。
デプロイ頻度 = 1日あたりの平均デプロイ数
計算条件：
- デプロイの終了時刻（
finished_atプロパティ）を基準 - 成功したデプロイのみカウント（
Deployment.statuses = success） - production環境ティアまたはproduction/prod という名前の環境が対象
5.3.4 改善方法
- グループとプロジェクト間でコードリリースの頻度をベンチマーク
- 以下を検討：
- 自動テストの追加
- 自動コード検証の追加
- 変更を小さなイテレーションに分割
5.4 Lead Time for Changes（変更のリードタイム）
5.4.1 定義
コード変更が本番環境に到達するまでにかかる時間です。
注意：Value Stream AnalyticsのLead timeとは異なります。VSAのLead timeは、Issueが要求されてから（Issue created）、完了・提供されるまで（Issue closed）の時間を測定します。
5.4.2 ビジネス上の意義
Lead time for changesは、CI/CDパイプラインの効率性を反映し、作業が顧客にどれだけ迅速に提供されるかを可視化します。低いLead time for changesは、より効率的なCI/CDパイプラインを意味します。
5.4.3 計算方法
Lead Time for Changes = デプロイ完了時刻 - MRマージ時刻
計算の詳細：
- MRのマージボタンがクリックされた時点から測定開始
- コードが本番環境で正常に実行されるまでを測定
- コーディング時間は計算に含まれない
- データはデプロイ完了直後に集約（わずかな遅延あり）
5.4.4 特殊ケース：マージ前のデプロイ完了
まれに、関連するMRがマージされる前にデプロイが完了する場合があります。この場合、GitLabは以下の式を使用します。
Lead Time = GREATEST(0, deployment_finished_at - merge_request_merged_at)
GREATEST関数により、リードタイム値が負にならないようにしています。
5.4.5 改善方法
- CI/CDパイプラインの効率性をグループとプロジェクト間でベンチマーク
- 以下を検討：
- Value Stream Analyticsを使用してプロセスのボトルネックを特定
- 変更を小さなイテレーションに分割
- 自動化の追加
- パイプラインのパフォーマンス改善
5.5 Time to Restore Service（サービス復旧時間）
5.5.1 定義
組織が本番環境の障害から復旧するのにかかる時間です。
5.5.2 ビジネス上の意義
Time to restore serviceは、組織が本番環境の障害からどれだけ早く復旧できるかを反映します。低いTime to restore serviceは、組織が新しい革新的な機能でリスクを取り、競争上の優位性を推進し、ビジネス成果を向上させることができることを意味します。
5.5.3 計算方法
GitLabでは、Time to restore serviceは以下のように測定されます。
Time to Restore Service = インシデントがオープンだった時間の中央値（本番環境）
前提条件：
- GitLabインシデントが追跡されている
- すべてのインシデントが本番環境に関連している
- インシデントとデプロイは厳密に1対1の関係
5.5.4 改善方法
- サービス中断や停止からのチーム対応と復旧を、グループとプロジェクト間でベンチマーク
- 以下を検討：
- 本番環境への可観測性の向上
- 対応ワークフローの改善
- Deployment frequencyとLead time for changesの改善により、修正をより効率的に本番環境に投入
5.6 Change Failure Rate（変更失敗率）
5.6.1 定義
変更が本番環境で障害を引き起こす頻度です。
5.6.2 ビジネス上の意義
Change failure rateは、出荷されるコードの品質に関するインサイトを提供します。高いChange failure rateは、非効率なデプロイプロセスまたは不十分な自動テストカバレッジを示している可能性があります。
5.6.3 計算方法
Change Failure Rate = (インシデント数 / デプロイ数) × 100
前提条件：
- GitLabインシデントが追跡されている
- すべてのインシデントが本番インシデント（環境に関係なく）
特記事項：
- 特定の日において、すべてのインシデントとデプロイが結合された日次レートに集約される
- 重複インシデントは別エントリとして計算される
5.6.4 計算例
10日間（1日1デプロイ）で、初日に2件のインシデント、最終日に1件のインシデントがあった場合：
Change Failure Rate = 3 / 10 = 0.3 = 30%
5.6.5 改善方法
- グループとプロジェクト間で品質と安定性をベンチマーク
- 以下を検討：
- 安定性とスループット（Deployment frequencyとLead time for changes）の適切なバランスを見つける
- 速度のために品質を犠牲にしない
- コードレビュープロセスの効率性向上
- 自動テストの追加
5.7 DORAカスタム計算ルール（実験的機能）
5.7.1 Multi-branch rule for lead time for changes
デフォルトのLead time for changes計算とは異なり、このルールでは複数ブランチ操作を単一のデプロイジョブで測定できます。
例：
設定方法（Railsコンソールで実行）：
my_project = Project.find_by_full_path('group/subgroup/project')
Dora::Configuration.create!(
project: my_project,
branches_for_lead_time_for_changes: ['master', 'main']
)
既存設定の更新：
my_project = Project.find_by_full_path('group/subgroup/project')
record = Dora::Configuration.where(project: my_project).first
record.branches_for_lead_time_for_changes = ['development', 'staging', 'master', 'main']
record.save!
5.8 DORAメトリクスの測定：様々なケース
5.8.1 GitLab CI/CDパイプラインを使用しない場合
Deployment frequencyは通常のpush型デプロイ用に作成されたデプロイレコードに基づいて計算されます。pull型デプロイ（例：エージェント経由のコンテナイメージ接続）では、デプロイレコードが作成されません。
このような場合、Deployments APIを使用してデプロイレコードを作成できます。
curl --request POST \
--header "PRIVATE-TOKEN: <your_access_token>" \
--form "environment=production" \
--form "sha=<commit_sha>" \
--form "ref=main" \
--form "status=success" \
"https://gitlab.example.com/api/v4/projects/:id/deployments"
5.8.2 Jiraとの統合
- Deployment frequencyとLead time for changesはGitLab CI/CDとMRに基づいて計算され、Jiraデータは不要
- Time to restore serviceとChange failure rateはGitLabインシデントが必要
5.8.3 外部インシデント管理ツールとの統合
PagerDutyなどの外部ツールの場合：
- Webhookを設定してPagerDutyインシデントごとにGitLabインシデントを自動作成
- HTTP統合を設定して以下を自動化：
- アラートトリガー時のインシデント作成
- 復旧アラート経由でのインシデントクローズ
5.9 プロジェクトとグループでの利用可能性
| メトリクス | レベル | 備考 |
|---|---|---|
| deployment_frequency | Project | 単位：デプロイ数 |
| deployment_frequency | Group | 単位：デプロイ数、集約方法：平均 |
| lead_time_for_changes | Project | 単位：秒、集約方法：中央値 |
| lead_time_for_changes | Group | 単位：秒、集約方法：中央値 |
| time_to_restore_service | Project/Group | 単位：日、集約方法：中央値 |
| change_failure_rate | Project/Group | デプロイの割合 |
5.10 データ集約の詳細
| メトリクス名 | 測定値 | Value Streams Dashboard | CI/CDアナリティクスチャート | カスタムインサイトレポート |
|---|---|---|---|---|
| Deployment frequency | 成功したデプロイ数 | 月ごとの日次平均 | 日次平均 | day（デフォルト）またはmonth |
| Lead time for changes | 本番環境へのコミット成功までの秒数 | 月ごとの日次中央値 | 中央値 | day（デフォルト）またはmonth |
| Time to restore service | インシデントがオープンだった秒数 | 月ごとの日次中央値 | 日次中央値 | day（デフォルト）またはmonth |
| Change failure rate | 本番インシデントを引き起こしたデプロイの割合 | 月ごとの日次中央値 | 失敗したデプロイの割合 | day（デフォルト）またはmonth |
6. GitLab Duo & SDLC Trends：AIの影響を可視化する
6.1 概要と対象ティア
- 対象ティア: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
- ステータス: GitLab Self-ManagedではBeta
GitLab Duo & SDLC Trendsは、GitLab DuoがSDLCパフォーマンスに与える影響を測定します。このダッシュボードは、プロジェクトまたはグループのAI採用状況における主要なSDLCメトリクスの可視性を提供します。
6.2 主要な用途
6.3 キーメトリクス
6.3.1 Assigned Duo Seat Engagement（割り当て済みDuoシートエンゲージメント）
エンゲージメント率 = (過去30日間にAI機能を使用したユーザー数 / 割り当て済みDuoシート総数) × 100
GitLab Duoシートが割り当てられ、過去30日間に少なくとも1つのAI機能を使用したユーザーの割合です。
6.3.2 Code Suggestions Usage（Code Suggestions使用率）
使用率 = (Code Suggestionsを使用したユーザー数 / コード貢献者数) × 100
過去30日間にCode Suggestionsを使用した、Duoシートが割り当てられたユーザーの割合です。コードエディタ拡張機能からのデータのみを収集します。
6.3.3 Code Suggestions Acceptance Rate（受け入れ率）
受け入れ率 = (受け入れられたCode Suggestions数 / 生成されたCode Suggestions総数) × 100
過去30日間にコード貢献者が受け入れたGitLab Duo提供のCode Suggestionsの割合です。
6.3.4 Duo Chat Usage（Duo Chat使用率）
Chat使用率 = (月間ユニークDuo Chatユーザー数 / Duo割り当てユーザー総数) × 100
毎月GitLab Duo Chatを使用するユーザーの割合です。
6.4 表示されるメトリクス
6.4.1 GitLab Duo使用状況メトリクス
Code Suggestions Usage
- AIコード提案に対する月間ユーザーエンゲージメント
- GitLab.comでは5分ごとにデータ更新
- 当月にコードをプッシュしたユーザーのみカウント
Duo RCA Usage
- GitLab Duo Root Cause Analysisに対する月間ユーザーエンゲージメント
- MRから失敗したCI/CDジョブのトラブルシューティングに使用
Duo Features Usage
- GitLab Duo機能を使用した貢献者数
Duo Code Review Requests
- MRに対するGitLab Duo Code Reviewリクエスト数
- MR作成者と非作成者の両方からのリクエストを含む
Duo Code Review Comments
- GitLab Duo Code ReviewがMR差分に投稿したコメント数
Duo Agent Platform Chats/Flows
- GitLab Duo Agent Platformを通じて開始されたチャットセッション数および実行されたエージェントフロー数
6.4.2 開発メトリクス
- Lead time
- Median time to merge
- Deployment frequency
- Merge request throughput
- Critical vulnerabilities over time
- Contributor count
6.4.3 パイプラインメトリクス
| メトリクス | 説明 |
|---|---|
| Total pipeline runs | プロジェクトでのパイプライン実行数 |
| Median duration | パイプライン実行の中央値（分） |
| Success rate | 正常に完了したパイプライン実行の割合 |
| Failure rate | 失敗したパイプライン実行の割合 |
6.5 GitLab Duo Code Suggestions：詳細分析
6.5.1 プログラミング言語別の受け入れ
過去30日間のプログラミング言語別のCode Suggestions受け入れ数を表示します。
各言語について以下を表示：
- Suggestions accepted: ユーザーが受け入れた提案数
- Suggestions shown: ユーザーに表示された提案数
- Acceptance rate: 受け入れられた提案の割合
6.5.2 IDE別の受け入れ
過去30日間のIDE別のCode Suggestions受け入れ数を表示します。
各IDEについて以下を表示：
- Suggestions accepted: ユーザーが受け入れた提案数
- Suggestions shown: ユーザーに表示された提案数
- Acceptance rate: 受け入れられた提案の割合
6.5.3 コード生成ボリューム傾向
過去180日間、月別集計でのCode Suggestionsを通じて生成されたコードのボリュームを表示します。
- Lines of code accepted: 受け入れられたCode Suggestionsのコード行数
- Lines of code shown: Code Suggestionsに表示されたコード行数
6.5.4 GitLab Duo Code Review：役割別リクエスト
過去180日間、月別集計でのGitLab Duo Code Reviewリクエスト数を表示します。
- Review requests by authors: MR作成者によるリクエスト数（プロジェクト設定による自動リクエストと作成者による手動リクエストを含む）
- Review requests by non-authors: MR作成者以外によるリクエスト数（例：レビュアーがDuoにMR変更のレビューを依頼）
作成者の採用率が高いほど、チームが自動レビューワークフローを受け入れていることを示します。
6.6 ユーザー別メトリクス
過去30日間の個別ユーザーによる各GitLab Duo機能の使用状況を表示します。
GitLab Duo Code Suggestions usage by user
- 受け入れられたCode Suggestions数
- Code Suggestions受け入れ率
GitLab Duo Code Review usage by user
- MR作成者としてGitLab Duoからリクエストしたコードレビュー数
- コードレビューコメントへのリアクション数（👍および👎）
GitLab Duo Root Cause Analysis usage by user
- GitLab Duoからのトラブルシューティングリクエスト数
GitLab Duo usage by user
- ユーザーによるDuoイベント数
6.7 メトリクスデータの利用可能性
以下の表は、GitLab Duoメトリクスの使用データ計算が開始されたGitLabバージョンを示しています。
| GitLab Duoメトリクス | データ計算開始 |
|---|---|
| Code Suggestions usage rate | GitLab 16.11 |
| Root Cause Analysis usage | GitLab 18.0 |
| Code Review requests and comments | GitLab 18.3 |
| Agent Platform chats and flows | GitLab 18.7 |
6.8 閲覧方法
前提条件：
- Code Suggestionsが有効化されている
- GitLab Self-Managedの場合、貢献分析用のClickHouseが設定されている
閲覧手順：
- プロジェクトまたはグループに移動
- Analyze > Analytics Dashboardsを選択
- GitLab Duo and SDLC trendsを選択
GraphQL APIを使用してメトリクスを取得することも可能です（AiMetrics、AiUserMetrics、AiUsageData API）。
7. プロジェクト/グループレベルアナリティクス
GitLabは、より詳細な分析のために、プロジェクトとグループレベルで多様なアナリティクス機能を提供します。
7.1 Issue Analytics（Premium/Ultimate）
7.1.1 概要
Issue Analyticsは、グループまたはプロジェクトで毎月作成されるIssueに関するインサイトを提供します。
7.1.2 表示内容
- 毎月オープン・クローズされたIssue数の棒グラフ
- 以下の詳細を含む上位100Issueのテーブル：
- 名前
- 経過時間
- ステータス
- マイルストーン
- イテレーション
- 重み
- 期限
- 担当者
- 作成者
7.1.3 フィルタリング
以下の条件でフィルタリング可能：
- Author（作成者）
- Assignee（担当者）
- Milestone（マイルストーン）
- Label（ラベル）
- My reaction（自分のリアクション）
- Weight（重み）
7.1.4 拡張機能（Ultimate）
Ultimateティアでは、「Issues closed」メトリクスが追加され、選択期間内に解決されたIssue総数を表示します。
7.2 Merge Request Analytics（Premium/Ultimate）
7.2.1 概要
Merge Request Analyticsは、チームのコードレビューとマージワークフローに関する貴重なインサイトを提供します。
7.2.2 主要メトリクス
月間マージ数
- 組織が月ごとにマージしたMR数
平均マージ時間
- MR作成からマージイベントまでの平均時間
個別MR情報
- マイルストーン
- コミット
- 行変更
- 担当者
7.2.3 ビジネス上の活用
以下を特定できます：
- 生産性が低い/高い月
- MRとコードレビュープロセスの効率性と生産性
これらのインサイトにより、以下のデータ駆動型の意思決定が可能になります：
- リソース配分: 低生産性期間に対処するためのリソース再配分またはタイムライン調整
- パフォーマンスベンチマーキング: 高パフォーマンスチームの特定とベストプラクティスの共有
- マイルストーン計画: 過去のマージ傾向に基づいたタイムライン調整
- プロセス最適化: コードレビューとマージワークフローのボトルネック特定と解決
7.2.4 Throughputチャート
Throughputチャートは、一定期間にクローズされたIssueまたはマージされた（クローズされたのではなく）MRを表示します。テーブルには1ページあたり最大20件のMRが表示され、以下の情報が含まれます：
- MR名
- マージ日
- マージまでの時間
- マイルストーン
- コミット
- パイプライン
- 行変更
- 担当者
7.2.5 Mean Time to Merge
「Mean time to merge」の数値は、MRが作成されてからマージされるまでの平均時間を示します。クローズされた、またはまだマージされていないMRは含まれません。
7.3 Productivity Analytics（Premium/Ultimate）
7.3.1 概要
Productivity Analyticsは、グループのMRに関する情報を表示します。
7.3.2 活用方法
以下を特定できます：
- MRのマージにかかる時間に基づく開発速度
- マージに時間がかかるMRの潜在的な原因
- マージに最も時間がかかる、または最も多くの変更を含む作成者、ラベル、マイルストーン
7.3.3 表示チャート
棒グラフ
- マージまでの日数別MR数
- コミット、コメント、マージ日間の時間
- コミット数、コード行数、変更ファイル数
散布図
- 1日あたりのMRメトリクス（MRあたりのコミット数など）
テーブル
- MRタイトル
- マージまでの時間
- コミット、コメント、マージ日間の期間
7.3.4 フィルタリング
- 特定プロジェクトのアナリティクスを表示
- 作成者、マイルストーン、ラベルでフィルタリング
- 日付範囲の調整
7.4 Code Review Analytics（Premium/Ultimate）
7.4.1 概要
Code Review Analyticsは、少なくとも1つの非作成者コメントがあるオープンなMRのテーブルを表示します。レビュー時間は、MRへの非作成者による最初のコメントからの経過時間です。
7.4.2 活用方法
MRごとのレビューメトリクスを表示し、コードレビュープロセスを改善できます。
多数のコメントやコミットは以下を示す可能性があります：
- コードが複雑すぎる
- 作成者がさらなるトレーニングを必要としている
長いレビュー時間は以下を示す可能性があります：
- 他のタイプよりも遅く進む作業タイプ
- 開発サイクルを加速する機会
少ないコメントと承認者は以下を示す可能性があります：
- 利用可能なチームメンバーの不足
7.4.3 表示内容
1ページあたり最大20件のレビュー中MRを表示し、以下の情報を含みます：
- MRタイトル
- レビュー時間
- 作成者
- 承認者
- コメント
- コミット
- 行変更
7.5 Contribution Analytics（Premium/Ultimate）
7.5.1 概要
Contribution Analyticsは、グループメンバーが過去1週間、1ヶ月、または3ヶ月に行った貢献イベントの概要を提供します。インタラクティブな棒グラフと詳細なテーブルが、グループメンバーごとの貢献イベント（pushイベント、Issue、MR）を表示します。
7.5.2 トラッキング
Contribution Analyticsは、ユニークコミットではなくpushイベントに基づいています。これにより、より信頼性の高い貢献ビューが提供されます。
例：
- ユーザーがブランチAに3つのコミットを1回のpushで行う
- 後で、ユーザーがブランチAからブランチBにそのコミットのうち2つをpush
- GitLabは5つのコミットを記録（実際のユニークコミットは3つ）
7.5.3 活用シーン
- ワークロードバランシング: 一定期間のグループの貢献を分析し、高パフォーマーまたは追加サポートが必要なメンバーを特定
- チームコラボレーション: コードpush対レビューや承認など、貢献のバランスを評価し、協調的な開発プラクティスを確保
- トレーニング機会: チームメンバーがメンタリングやトレーニングから恩恵を受ける可能性がある領域を特定（MR承認率やIssue解決率が低い場合など）
- 振り返り評価: Contribution Analyticsを振り返りに組み込み、チームが目標をどれだけ効果的に達成したか、どこで調整が必要かを評価
7.5.4 ClickHouseとの連携
GitLab.comでは、Contribution AnalyticsはClickHouse Cloudクラスター経由で実行されます。GitLab Self-Managedでは、ClickHouse統合を設定すると、ClickHouseイベントテーブルがPostgreSQLイベントテーブルから自動的に入力されます。
7.6 CI/CD Analytics（Free/Premium/Ultimate）
7.6.1 概要
CI/CD Analyticsは、パイプラインのパフォーマンスと成功率に関するインサイトを提供します。重要なCI/CDパイプラインメトリクスの可視化をGitLab UI内で直接提供します。
7.6.2 パイプラインメトリクス
すべての利用可能なパイプラインを収集してパイプライン統計を集計します（ステータスに関係なく）。各日のデータは、パイプラインが作成された時点に基づきます。
主要メトリクス：
| メトリクス | 説明 |
|---|---|
| Total pipeline runs | 選択期間に実行されたパイプライン総数 |
| Median duration | パイプライン完了までの中央値 |
| Failure rate | 失敗したパイプラインの割合 |
| Success rate | 正常に完了したパイプラインの割合 |
7.6.3 フィルタリング
特定の領域に焦点を当てるためにアナリティクスデータをフィルタリングできます：
- Source: パイプライントリガーソースでフィルタ
- Branch: パイプラインが実行されたブランチでフィルタ
- Date range: 分析する期間を選択（例：先週）
7.6.4 パイプライン期間チャート
パイプライン実行時間が時間とともにどのように変化したかを表示します。
- Median（50パーセンタイル）: 典型的なパイプライン期間
- 95パーセンタイル: 95%のパイプラインがこの時間以内に完了（5%のみがより長くかかる）
この可視化により、パイプライン期間の傾向を特定し、CI/CDプロセスの効率性を時間経過とともに判断できます。
7.6.5 パイプラインステータスチャート
時間経過に伴うパイプラインステータスの分布を表示します：
- Successful: エラーなく完了したパイプライン
- Failed: エラーにより正常に完了しなかったパイプライン
- Other: その他のステータス（キャンセル、スキップ）
この可視化により、パイプラインの安定性を追跡し、失敗率が高い期間を特定できます。
7.7 Contributor Analytics（Free/Premium/Ultimate）
7.7.1 概要
Contributor Analyticsは、プロジェクトメンバーが時間経過とともにプロジェクトに行ったコミットの概要を提供します。
7.7.2 表示内容
- 選択したプロジェクトブランチへの時間経過に伴うコミット数の折れ線グラフ
- 各プロジェクトメンバーによるコミット数の折れ線グラフ
7.7.3 プロジェクトコミット履歴の表示
- Analyze > Contributor analyticsに移動
- 「History」を選択
- Branches (main)ドロップダウンリストから、表示したいコミットのブランチを選択
フィルタリングオプション：
- Author: 特定ユーザーのコミットを表示
- Commit message: コミットメッセージで検索
7.7.4 RSSフィードとして取得
プロジェクトへのコミットリストをAtom形式のRSSフィードとして表示できます。
- Analyze > Contributor analyticsに移動
- 「History」を選択
- 右上のフィードシンボル（📡）を選択
7.8 Repository Analytics
7.8.1 プロジェクト用（Free/Premium/Ultimate）
Repository Analyticsは、プロジェクトのGitリポジトリに関する情報を表示します。
表示内容：
- リポジトリのデフォルトブランチで使用されているプログラミング言語
- 過去3ヶ月のコードカバレッジ統計
- 過去1ヶ月のコミット統計
- 月の日別、曜日別、時間別のコミット数
チャートデータ処理：
- データはキューに入れられる
- バックグラウンドワーカーがデフォルトブランチへの各コミット後10分でチャートを更新
- GitLabインストールのサイズやバックグラウンドジョブキューによっては、データ更新に時間がかかる場合あり
7.8.2 グループ用（Premium/Ultimate）
Repository Analytics for Groupsは、グループ内のすべてのプロジェクトのテストカバレッジデータを提供します。
活用方法：
- グループ内のすべてのプロジェクトのコードカバレッジ傾向を監視
- カバレッジレポートを生成するプロジェクトとジョブの総数を追跡
- 分析用の過去のカバレッジデータをダウンロード
カバレッジメトリクス：
現在のグループコードカバレッジ：
- カバレッジレポートを持つプロジェクト数
- すべてのプロジェクトの平均カバレッジ率
- カバレッジレポートを生成するパイプラインジョブの総数
平均テストカバレッジ：
- 過去30日間のグループ内のすべてのプロジェクトの平均テストカバレッジを示すグラフ
最新のテストカバレッジ結果：
- グループ内の各プロジェクトの最新のカバレッジデータのリスト
カバレッジデータのダウンロード：
CSVファイルには以下が含まれます：
- 最大1000レコード
- 各プロジェクトのデフォルトブランチからのデータ
- カバレッジが報告された1日1行
- 複数のカバレッジレポートが生成された場合、その日の最後の値を使用
CSVの各カバレッジレポートの情報：
- カバレッジジョブが実行された日付
- レポートを生成したジョブ名
- プロジェクト名
- カバレッジ率
8. Analytics Dashboards：カスタマイズ可能な分析環境
8.1 概要と対象ティア
- 対象ティア: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Analytics Dashboardsは、収集されたデータをビルトインダッシュボードで可視化するのに役立ちます。
8.2 データソース
データソースは、ダッシュボードフィルタと可視化がクエリと結果取得に使用できる、データベースまたはデータコレクションへの接続です。
8.3 ビルトインダッシュボード
GitLabは、事前定義された可視化を持つビルトインダッシュボードを提供しています。これらのダッシュボードには「By GitLab」とラベルが付けられています。ビルトインダッシュボードは編集できませんが、類似のスタイルでカスタムダッシュボードを作成できます。
利用可能なビルトインダッシュボード：
- Value Streams Dashboard: DevOpsパフォーマンス、セキュリティ露出、ワークストリーム最適化に関連するメトリクスを表示
- GitLab Duo and SDLC trends: プロジェクトまたはグループのSDLCメトリクスに対するAIツールの影響を表示
- DORA Metrics Dashboard: 時間経過に伴う各DORAメトリクスの進化を表示
- Merge request analytics: MRスループットと平均マージ時間のメトリクスを表示
8.4 カスタムダッシュボード
関連性の高いメトリクスを可視化するカスタムダッシュボードを作成できます。
特徴：
- 各プロジェクトは無制限のダッシュボードを持つことができる（制限はリポジトリサイズ制限のみ）
- 各ダッシュボードは1つ以上の可視化を参照できる
- 可視化はダッシュボード間で共有可能
- プロジェクトメンテナーは、コードオーナーや承認ルールなどの機能を使用してダッシュボード変更の承認ルールを適用可能
- ダッシュボードファイルはプロジェクトの他のコードと一緒にソース管理でバージョン管理される
8.5 ダッシュボードの作成
8.5.1 ディレクトリ構造
.gitlab/analytics/dashboards
├── conversion_funnels
│ └── conversion_funnels.yaml
├── demographic_breakdown
│ └── demographic_breakdown.yaml
├── north_star_metrics
│ └── north_star_metrics.yaml
├── visualizations
│ └── example_line_chart.yaml
8.5.2 設定ファイルの作成
-
.gitlab/analytics/dashboards/に、ダッシュボード名と同じディレクトリを作成 - 新しいディレクトリに、ディレクトリと同じ名前の
.yamlファイルを作成 - ファイルは
ee/app/validators/json_schemas/analytics_dashboard.jsonで定義されたJSONスキーマに準拠する必要がある
8.6 ダッシュボードフィルタ
以下のフィルタをサポート：
Date range（日付範囲）
- データを日付でフィルタリングする日付セレクタ
Anonymous users（匿名ユーザー）
- データセットから匿名ユーザーを含める/除外するトグル
有効化方法：
title: My dashboard
# ...
filters:
excludeAnonymousUsers:
enabled: true
dateRange:
enabled: true
8.7 インラインチャート可視化の定義
以下のチャートタイプと可視化オプションを定義できます：
- Line chart: EChartsのオプション
- Column chart: EChartsのオプション
- Data table: テーブル形式の表示
-
Single stat:
decimalPlacesオプションのみ設定可能（数値、デフォルト値は0）
8.7.1 必須フィールド
- version
- type
- data
- options
8.8 チャート可視化テンプレートの定義
複数のダッシュボードで使用される可視化は、別のテンプレートファイルとして保存できます。
注意点：
- テンプレートは控えめに使用することを推奨
- ダッシュボードエディタUIで可視化選択リストが長くなる可能性あり
- 一般的には、複数のダッシュボードで同一に使用される可視化に限定すべき
8.8.1 テンプレートファイルの作成
-
.gitlab/analytics/dashboards/visualizations/ディレクトリに.yamlファイルを作成 - ファイル名は、定義する可視化を説明的なものにする
-
ee/app/validators/json_schemas/analytics_visualization.jsonのスキーマに従って可視化設定を定義
8.8.2 例：折れ線グラフテンプレート
version: 1
type: line_chart
data:
# データソース設定
options:
# チャートオプション
必須フィールド：
- version
- type
- data
- options
8.9 ダッシュボードの場所変更
プロジェクトまたはグループのカスタムダッシュボードの場所を変更できます。
8.9.1 グループダッシュボード
- ダッシュボードファイルを保存するプロジェクトを見つける（グループに属している必要あり）
- グループのSettings > Analyticsに移動
- Analytics Dashboardsセクションで、ダッシュボードファイルプロジェクトを選択
- 「Save changes」を選択
8.9.2 プロジェクトダッシュボード
デフォルトでは、カスタムダッシュボードは現在のプロジェクトに保存されます。ただし、ダッシュボード用の別プロジェクトを持つこともできます。
このセットアップは以下の場合に推奨されます：
- ダッシュボード定義に特定のアクセスルールを適用したい
- 複数のプロジェクト間でダッシュボードを共有したい
注意: ダッシュボードは同じグループ内のプロジェクト間でのみ共有可能
9. DevOps Adoption：組織全体の機能採用状況を追跡
9.1 概要
DevOps Adoptionは、組織内のグループがGitLab機能をどのように採用・使用しているかを表示します。この情報は、グループとインスタンスの両方で利用可能です。
9.2 グループレベルのDevOps Adoption（Ultimate）
9.2.1 機能採用
DevOps Adoptionは、開発、セキュリティ、運用の機能採用を表示します。
| カテゴリ | 機能 |
|---|---|
| Development | Approvals Code owners Issues Merge requests |
| Security | DAST Dependency scanning Fuzz testing SAST |
| Operations | Deployments Pipelines Runners |
機能は、グループまたはサブグループが過去1ヶ月間（完全な暦月）にプロジェクトでその機能を使用した場合、採用されたと表示されます。
9.2.2 表示内容
Overviewタブ：
- 採用された機能の総数
- 各カテゴリで採用された機能
- Adoption over timeバーチャート：月ごとの各カテゴリで採用された機能数
- Adoption by subgroupテーブル：サブグループごとの各カテゴリで採用された機能数
Dev、Sec、Opsタブ：
- サブグループごとの開発、セキュリティ、運用で採用された機能
除外される項目：
- 休眠プロジェクト：機能を使用するプロジェクトの数は考慮されない
- 新しいGitLab機能：採用は採用された機能の総数であり、機能の割合ではない
9.2.3 データ処理
週次タスクがDevOps Adoptionのデータを処理します。このタスクは、グループのDevOps Adoptionに初めてアクセスするまで無効になっています。
データ処理タスクは、毎月1日にデータを更新します。月次更新が失敗した場合、タスクは成功するまで毎日試行します。
DevOps Adoptionデータは、GitLabがグループのデータを処理する間、表示されるまで最大1分かかる場合があります。
9.3 インスタンスレベルのDevOps Adoption（Free/Premium/Ultimate）
9.3.1 DevOps Score
DevOps Scoreを表示するには、GitLabインスタンスのService Pingをアクティブ化する必要があります。DevOps Scoreは比較ツールであるため、スコアデータは最初にGitLab Inc.によって中央処理される必要があります。
DevOps Scoreを使用して、DevOpsステータスを他の組織と比較できます。
表示内容：
- 過去30日間のGitLabインスタンス上の主要機能の使用状況（その期間の請求可能ユーザー数で平均化）
- スコア：機能スコアの平均
- 使用状況：過去30日間の請求可能ユーザーあたりの機能の平均使用状況
- Leader usage：GitLabが収集したService Pingデータに基づくトップパフォーマンスインスタンスから計算
注意事項：
- Service Pingデータは、分析のためにGitLabサーバーで集約される
- 使用情報は他のGitLabインスタンスには送信されない
- GitLabを使い始めたばかりの場合、この機能が利用可能になる前にデータが収集されるまで数週間かかる場合あり
10. その他の分析機能
10.1 Insights（Ultimate）
Insightsは、項目数（例：作成されたバグ）を月ごとに表示するインタラクティブな棒グラフです。
10.1.1 活用方法
プロジェクトやグループのカスタムレポートを設定し、以下のようなデータを探索できます：
- 指定期間に作成・クローズされたIssue
- MRがマージされるまでの平均時間
- トリアージの衛生状態
10.1.2 設定
Insightsは.gitlab/insights.ymlファイルで設定します。
設定例：
bugsCharts:
title: "バグのチャート"
charts:
- title: "月間作成バグ数"
description: "月ごとに作成されたオープンなバグ"
type: bar
query:
data_source: issuables
params:
issuable_type: issue
issuable_state: opened
filter_labels:
- bug
group_by: month
period_limit: 24
10.1.3 サポートされるチャートタイプ
- bar: 棒グラフ
- line: 折れ線グラフ
- stacked-bar: 積み上げ棒グラフ
10.1.4 クエリパラメータ
data_source:
-
issuables: MRまたはIssueデータを公開 -
dora: DORAメトリクスを公開
params（issuables用）:
-
issuable_type: issue または merge_request -
issuable_state: opened、closed、locked、merged、all -
filter_labels: ラベルでフィルタ -
collection_labels: ラベルでグループ化 -
group_by: day、week、month -
period_limit: 過去何期間分を表示するか -
period_field: created_at、closed_at、merged_at
params（DORA用）:
-
metric: deployment_frequency、lead_time_for_changes、time_to_restore_service、change_failure_rate -
group_by: day、month -
period_limit: 期間制限（最大180日または6ヶ月） -
environment_tiers: production、staging、testing、development、other
10.2 Usage Trends（Free/Premium/Ultimate、Self-Managed/Dedicated）
Usage Trendsは、インスタンスに含まれるデータ量と、このボリュームが時間とともにどのように変化しているかの概要を提供します。
10.2.1 表示内容
総数の概要：
- Projects
- Groups
- Users
- Issues
- Merge requests
- Pipelines
1年間の月次値の折れ線グラフ：
- ProjectsとGroups
- Pipelines
- IssuesとMerge requests
Usage Trendsデータは毎日更新されます。
11. まとめ：GitLabアナリティクスの実践的活用
GitLabのアナリティクス機能は、単なるメトリクスの可視化ツールではなく、開発プロセス全体をデータに基づいて継続的に改善するための包括的なエコシステムです。
11.1 段階的な導入アプローチ
組織の成熟度に応じて、以下のような段階的な導入が効果的です。
11.2 各ティアでの推奨活用法
Freeティア:
- CI/CD Analyticsでパイプラインの健全性を監視
- Contributor Analyticsでチーム活動を把握
- Value Stream Analyticsの基本機能で開発フローを理解
Premiumティア:
- Value Streams Dashboardで組織全体のメトリクスを集約
- Code Review Analyticsでレビュープロセスを最適化
- Productivity Analyticsでボトルネックを特定
Ultimateティア:
- DORAメトリクスで業界標準と比較
- GitLab Duo & SDLC TrendsでAI投資のROIを測定
- DevOps AdoptionでGitLab機能の採用状況を追跡
- カスタムダッシュボードで組織固有のKPIを可視化
11.3 データ駆動型文化の構築
アナリティクス機能を最大限活用するためには、技術的な設定だけでなく、組織文化の醸成も重要です。
- 定期的なメトリクスレビュー: 週次または月次でチームメトリクスをレビュー
- 改善目標の設定: データに基づいた具体的な改善目標を設定
- 透明性の確保: ダッシュボードを全員がアクセス可能にし、情報の民主化を推進
- 実験と学習: A/Bテストや段階的ロールアウトで新しいプラクティスを試験
- 振り返りへの統合: スプリント振り返りやポストモーテムでメトリクスを活用
11.4 技術的ベストプラクティス
データ品質の確保:
- 適切な環境ティア設定（production環境の明確化）
- Issueとコミットの適切なリンク（
#issue_numberの記載） - インシデント管理の統合（PagerDutyなど外部ツールとの連携）
パフォーマンスの最適化:
- ClickHouse統合の活用（Self-Managed環境）
- 適切なデータ集約期間の設定
- GraphQL APIを使用した効率的なデータ取得
セキュリティとアクセス制御:
- ダッシュボード設定ファイルへの適切なアクセス制御
- コードオーナーの設定による変更管理
- ロールベースのメトリクスアクセス権限設定
GitLabのアナリティクス機能は、継続的に進化しています。定期的にドキュメントを確認し、新機能を試すことで、チームのパフォーマンス向上につなげることができます。データに基づいた意思決定により、より速く、より確実に価値を提供できる開発組織を構築しましょう。