• 機能の可用性
• 価値ストリーム分析の仕組み
  • 価値の流れのステージ
  • 値のストリーム
  • バリューストリームのステージイベント
  • バリューストリーム・アナリティクスによるデータの集約方法
  • 価値ストリーム分析によるステージの測定方法
    • ワークフロー例
  • 価値ストリーム分析による生産環境の特定方法
• 価値のストリーム分析の表示
  • データフィルター
• バリューストリーム分析メトリクス
  • ライフサイクルのメトリクス
  • DORAメトリクス
• ライフサイクルとDORAメトリクスの表示
• 各開発ステージのメトリクスを表示します。
• タスクをタイプ別に表示
• 値のストリームの作成
  • GitLabのデフォルトステージを使ってバリューストリームを作成します。
  • カスタムステージでバリューストリームを作成
    • カスタム・バリュー・ストリーム用のラベル・ベースのステージ
    • カスタム価値ストリーム設定の例
• 値のストリームの編集
• バリューストリームの削除
• サイクル完了までの日数の表示
• 価値のストリーム分析のアクセス権限
• トラブルシューティング
  • Sidekiqによる100%のCPU使用率cronjob:analytics_cycle_analytics

価値ストリーム分析

バリューストリーム分析では、アイデアから生産までにかかる時間を測定します。

価値の流れとは、顧客に価値を提供する作業プロセス全体のことです。例えば、DevOpsライフサイクルは、「管理」ステージから始まり「保護」ステージで終わる価値の流れです。

バリューストリーム分析を使用して、以下を特定します：

• アイデアから生産までにかかる時間。
• プロジェクトの速度。
• 開発プロセスのボトルネック。
• 長期化しているイシューやマージリクエスト。
• ソフトウェア開発ライフサイクルを遅らせる要因。

バリューストリームアナリティクスはビジネスを支援します：

• エンドツーエンドのDevSecOpsワークストリームを可視化します。
• 非効率の特定と解決
• ワークストリームを最適化し、より早く、より多くの価値を提供します。

バリューストリーム・アナリティクスは、プロジェクトとグループで利用できます。

機能の可用性

バリューストリームアナリティクスは、FOSS版とライセンス版で、プロジェクトとグループレベルで異なる機能を提供します。

• GitLab Freeでは、バリューストリーム分析はデータを集約しません。データベースに直接クエリし、イシューやマージリクエストの作成日に日付範囲フィルタが適用されます。事前に定義されたデフォルトステージでバリューストリーム分析を表示することができます。
• GitLab Premiumでは、バリューストリーム分析はデータを集約し、終了イベントに日付範囲フィルタを適用します。バリューストリームを作成、編集、削除することもできます。

価値ストリーム分析の仕組み

バリューストリーム分析では、ソフトウェア開発プロセスの各ステージの期間を計算します。

バリューストリームアナリティクスは、3つのCoreオブジェクトで構成されています：

• バリューストリームには、バリューストリームのステージリストが含まれます。
• 各値のストリームのステージ・リストには、1 つ以上のステージが含まれます。
• 各ステージには、開始と停止の 2 つのイベントがあります。

価値の流れのステージ

ステージは、イベントペア（開始イベントと終了イベント）をステージ名などの追加メタデータとともに表します。ステージは、バックエンドで定義されたペアリング・ルールで設定できます。

値のストリーム

バリューストリームは、ステージのコンテナオブジェクトです。グループごとに複数のバリューストリームを持つことができ、DevOpsライフサイクルのさまざまな側面に焦点を当てることができます。

バリューストリームのステージイベント

イベントは、バリューストリーム分析機能の最小構成要素です。ステージは開始イベントと終了イベントで構成されます。

以下のステージイベントがあります：

• イシュー終了
• イシューの作成
• イシューが最初にボードに追加された日
• 最初に割り当てられたイシュー
• マイルストーンに最初に関連付けられたイシュー
• 最初に言及されたイシュー
• イシューラベル追加
• イシューラベル削除
• MRクローズ
• MRマージ
• MR作成
• MR ファーストコミット時間
• MRの最初の割り当て
• MRの最初のデプロイ
• MRラベル追加
• MRラベル削除
• MR 最終パイプライン期間

これらのイベントは、継続時間の計算において重要なロールを果たします。継続時間＝イベント終了時間-イベント開始時間という式で計算されます。

どのような開始イベントと終了イベントがペアになるかは、開始イベントと終了イベントの検証を参照してください。

バリューストリーム・アナリティクスによるデータの集約方法

• GitLab 14.5 で導入されました。
• GitLab 14.9で追加された停止日によるフィルタリングのトグル。
• GitLab 14.9 でデータ更新バッジが追加されました。
• GitLab 14.9で停止日によるフィルタリングのトグルが削除されました。
• GitLab15.0で停止日によるフィルタリングを有効にしました。

バリューストリーム分析では、ステージレベルのデータを収集・集計するためにバックエンドプロセスを使用します。これにより、イシューやマージリクエストの数が多い大規模なグループでも拡張できるようになっています。このプロセスのため、アクション（イシューのクローズなど）が発生してからバリューストリーム分析ページにデータが表示されるまでに若干の遅延が発生する場合があります。

データの処理と結果の表示に最大10分かかる場合があります。以下の場合、データ収集に10分以上かかることがあります：

• 初めてバリューストリーム分析を表示し、まだバリューストリームを作成していない場合。
• グループ階層が再配置されている場合。
• イシューやマージリクエストの一括更新があった場合。

最新の更新日時を表示するには、右隅の編集の横にある最終更新日時バッジにカーソルを合わせてください。

価値ストリーム分析によるステージの測定方法

バリューストリームアナリティクスでは、各ステージの開始イベントから終了イベントまでを測定します。

例えば、ステージはユーザーがイシューにラベルを追加したときに開始し、別のラベルを追加したときに終了します。アイテムが終了イベントに達していない場合は、ステージ時間の計算に含まれません。

バリューストリーム分析では、事前に定義したイベントに基づいてステージをカスタマイズできます。設定を簡単にするために、GitLabはテンプレートとして使えるステージの定義済みリストを提供します。

バリューストリームアナリティクスの定義済みの各ステージは、以下の表で詳しく説明します。

バリューストリーム解析による各ステージの計算方法については、バリューストリーム解析開発ガイドを参照してください。

ワークフロー例

この例では、1日で7つのステージをすべて完了するワークフローを示しています。

ステージに開始時刻と停止時刻が含まれていない場合、そのデータは中央値に含まれません。この例では、マイルストーンが作成され、テスト環境と設定環境のCI/CDが設定されています。

• 09:00: イシューを作成。イシュー・ステージ開始。
• 11:00: マイルストーンにイシューを追加し、イシューの作業を開始し、ローカルにブランチを作成します。イシューステージが停止し、プランステージが開始。
• 12:00:最初のコミットを行います。
• 12:30: イシュー番号のブランチに 2 番目のコミット。計画ステージが停止し、コードステージが開始します。
• 14:00: ブランチをプッシュし、イシューのクローズパターンを含むマージリクエストを作成。コードステージが停止し、テストステージとレビュアーステージが開始します。
• GitLab CI/CD は.gitlab-ci.ymlで定義されたスクリプトを実行するのに5分かかります。
• 19:00: マージリクエストをマージします。レビューステージが停止し、ステージングステージが開始します。
• 19:30:production 環境へのデプロイが終了。ステージング停止。

バリューストリームアナリティクスでは、各ステージで以下の時間が記録されます：

• イシュー：09:00～11:00：2時間
• プラン11:00から12:00まで：1時間
• コード12:00から14:00まで：2時間
• テスト：5分
• レビュー14:00～19:00：5時間
• ステージ：19:00～19:30：30分

この例に関連する以下の観察に留意してください：

• この例では、最初のコミットでイシュー番号に触れなくても問題ないことを示しています。
• テストステージは、サイクル全体の時間の計算に使用されます。すべての MR をテストする必要があるため、レビュープロセスに含まれます。
• この例では、7つのステージのうち1つのサイクルのみを示しています。バリューストリーム分析ダッシュボードには、複数のサイクルの中央値が表示されます。

価値ストリーム分析による生産環境の特定方法

バリューストリームアナリティクスは、これらのパターンのいずれかに一致する名前を持つプロジェクト環境を探すことで、生産環境を特定します：

• prod またはprod/*
• production またはproduction/*

これらのパターンは大文字と小文字を区別しません。

GitLab CI/CD設定でプロジェクト環境の名前を変更することができます。

価値のストリーム分析の表示

• GitLab 13.3で導入されたフィルタリング
• 13.0で導入された水平ステージパスと13.12で削除された機能フラグ

前提条件：

• 少なくともレポーターロールを持っている必要があります。
• カスタム・バリュー・ストリームを作成する必要があります。バリュー・ストリーム分析では、グループまたはプロジェクト用に作成されたカスタム・バリュー・ストリームのみが表示されます。

グループまたはプロジェクトのバリューストリーム分析を表示するには、以下の手順に従います：

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value stream analyticsを選択します。
3. 特定のステージのメトリクスを表示するには、[Filter results]テキストボックスの下にあるステージを選択します。
4. オプション。結果をフィルタリングします：
   1. フィルタ結果]テキストボックスを選択します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 日付範囲を調整するには
      • 開始日］フィールドで開始日を選択します。
      • To］フィールドで、終了日を選択します。チャートとリストには、日付範囲内に作成されたワークフロー項目が表示されます。
5. オプション結果を昇順または降順でソートします：
   • 最も新しいまたは最も古いワークフロー項目でソートするには、Last eventheaderを選択します。
   • 各ステージに費やされた時間の多い順、少ない順に並べ替えるには、Durationヘッダを選択します。

ワークフロー項目テーブルのヘッダーの横にあるバッジは、選択したステージで完了したワークフロー項目の数を示します。

テーブルには、選択したステージに関連するワークフロー項目のリストが表示さ れます。選択したステージに応じて、以下のようになります：

• イシュー
• マージリクエスト

データフィルター

バリューストリーム分析をフィルタリングして、特定の条件に一致するデータを表示できます。以下のフィルタがサポートされています：

• 日付範囲
• プロジェクト
• Assignee
• Author
• Milestone
• レーベル

バリューストリーム分析メトリクス

• GitLab 13.0から導入されました。
• GitLab 13.12で機能フラグを削除。

価値のストリーム分析の概要ページには、プロジェクトとグループのDevSecOpsライフサイクルパフォーマンスの主要メトリクスが表示されます。

ライフサイクルのメトリクス

バリューストリーム分析には、以下のライフサイクル・メトリクスが含まれます：

• リードタイム：リードタイム：イシューが作成されてからクローズされるまでの時間の中央値。
• サイクルタイム：最初のコミットからイシューがクローズされるまでの時間の中央値。GitLabは、リンクされたイシューのマージリクエストの一番最初のコミットから、そのイシューがクローズされるまでのサイクルタイムを測定します。マージリクエストの作成は常にコミット時間よりも遅くなるため、サイクルタイムのアプローチはリードタイムを過小評価します。
• 新しいイシュー：新しく作成されたイシューの数。
• デプロイ数：本番環境へのデプロイの総数。

DORAメトリクス

• GitLab 14.5で変更のリードタイムDORAメトリクスを導入しました。
• GitLab 14.3で、グループのバリューストリーム分析のためのDORA APIベースのデプロイメトリクスがGitLab UltimateからGitLab Premiumに移動しました。
• GitLab 15.0でサービスタイルの復元時間を導入しました。
• GitLab 15.0で変更失敗率タイルを導入。

バリューストリーム分析には以下のDORAメトリクスが含まれます：

• デプロイ頻度
• 変更リードタイム
• サービス復旧の時期
• 変更失敗率

DORAメトリクスは、DORA APIからのデータに基づいて計算されます。

GitLab PremiumまたはUltimateサブスクリプションをお持ちの場合：

• 成功したデプロイ回数はDORAデータで計算されます。
• データは環境と環境階層に基づいてフィルタリングされます。

ライフサイクルとDORAメトリクスの表示

前提条件

• デプロイ メトリクスを表示するには、本番環境が設定されている必要があります。

ライフサイクル・メトリクスを表示するには

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value Stream Analyticsを選択します。Filter results]テキストボックスの下にライフサイクル・メトリクスが表示されます。
3. オプション。結果をフィルタリングします：
   1. フィルタ結果] テキスト ボックスを選択します。選択したフィルタに基づいて、ダッシュボードはライフサイクル・メトリクスを自動的に集計し、価値のストリームのステータスを表示します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 日付範囲を調整するには
      • 開始日］フィールドで開始日を選択します。
      • Toフィールドで、終了日を選択します。

バリュー・ストリーム・ダッシュボードと DORAメトリクスを表示します：

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value stream analyticsを選択します。
3. Filter results]テキストボックスの下の[Lifecycle metrics]行で、[Value Streams Dashboard / DORA]を選択します。
4. オプション。新しいページを開くには、このパス/analytics/dashboards/value_streams_dashboard をグループ URL に追加します（例：https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard）。

各開発ステージのメトリクスを表示します。

• GitLab 13.0から導入されました。
• GitLab 13.12で機能フラグを削除。

バリューストリーム分析では、各開発ステージでイシューやマージリクエストに費やされた時間の中央値が表示されます。

グループ別に各ステージに費やされた時間の中央値を表示します：

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value stream analyticsを選択します。
3. オプション。結果をフィルタリングします：
   1. フィルタ結果]テキストボックスを選択します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 日付範囲を調整するには
      • 開始日］フィールドで開始日を選択します。
      • Toフィールドで、終了日を選択します。
4. 各ステージのメトリクスを表示するには、[Filter results（結果の絞り込み）] テキスト・ボックスの上にあるステージにカーソルを合わせます。

タスクをタイプ別に表示

タイプ別タスクチャートは、グループの1日あたりのイシューとマージリクエストの累積数を表示します。

Chartはグローバルページフィルタを使用して、選択したグループと時間枠に基づいてデータを表示します。

タスクをタイプ別に表示するには

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. Analyze > Value stream analyticsを選択します。
3. Filter results]テキストボックスの下にある[Overview]を選択します。合計時間] チャートの下に [タイプ別タスク] チャートが表示されます。
4. タスクタイプを切り替えるには、設定（{settings}）ドロップダウンリストを選択し、イシューまたはマージリクエストを選択します。
5. ラベルを追加または削除するには、設定({settings})ドロップダウンリストを選択し、ラベルを選択または検索します。デフォルトでは、一番上のグループレベルのラベル（最大10）が選択されています。ラベルは最大15個まで選択できます。

値のストリームの作成

GitLabのデフォルトステージを使ってバリューストリームを作成します。

GitLab 13.3で導入されました。

バリューストリームを作成する際、GitLabのデフォルトステージを使用し、ステージを非表示にしたり並べ替えたりすることができます。また、デフォルトテンプレートで提供されているステージに加えて、カスタムステージを作成することもできます。

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value Stream analyticsを選択します。
3. Create new Value Stream を選択します。
4. バリューストリームの名前を入力します。
5. デフォルトのテンプレートから作成］を選択します。
6. デフォルトステージをカスタマイズします：
   • ステージを並べ替えるには、上下の矢印を選択します。
   • ステージを非表示にするには、Hide({eye-slash})を選択します。
7. カスタムステージを追加するには、Add another stageを選択します。
   • ステージの名前を入力します。
   • 開始イベントと 停止イベントを選択します。
8. 値のストリームを作成] を選択します。

カスタムステージでバリューストリームを作成

• GitLab 13.7 で導入されました。
• GitLab 13.10ではデフォルトで有効。
• GitLab 13.11で機能フラグを削除。

バリューストリームを作成する際に、独自の開発ワークフローに沿ったカスタムステージを作成・追加することができます。

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value Stream analyticsを選択します。
3. 値のストリームを作成] を選択します。
4. 各ステージで
   • ステージの名前を入力します。
   • 開始イベントと 停止イベントを選択します。
5. 別のステージを追加するには、Add another stageを選択します。
6. ステージを並べ替えるには、上下の矢印を選択します。
7. 値のストリームを作成] を選択します。

カスタム・バリュー・ストリーム用のラベル・ベースのステージ

複雑なワークフローを測定するには、スコープ付きラベルを使用できます。例えば、ステージング環境から本番環境へのデプロイ時間を測定するには、以下のラベルを使用できます：

• コードがステージングにデプロイされると、workflow::staging ラベルがマージリクエストに追加されます。
• コードが本番環境にデプロイされると、workflow::production のラベルがマージリクエストに追加されます。

カスタム価値ストリーム設定の例

上記の例では、Test Group（最上位の名前空間）で異なる開発ワークフローを使用している 2 つのチームに対して、2 つの独立した価値の流れが設定されています。

最初の値ストリームでは、ステージの定義に標準的なタイムスタンプ・ベースのイベントを使用します。2 番目の値ストリームでは、ラベル・イベントを使用します。

値のストリームの編集

GitLab 13.10で導入されました。

バリューストリームを作成した後は、目的に合わせてカスタマイズすることができます。バリューストリームを編集するには

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value Stream analyticsを選択します。
3. 右上のドロップダウンリストを選択し、バリューストリームを選択します。
4. バリュー・ストリームのドロップダウン・リストの横で、[Edit] を選択します。
5. オプション
   • 値のストリームの名前を変更します。
   • デフォルトステージの非表示または順序の変更。
   • 既存のカスタムステージの削除。
   • 新しいステージを追加するには、Add another stageを選択します。
   • ステージの開始イベントと終了イベントを選択します。
6. オプション。変更した内容を元に戻すには、［値のストリームをデフォルトに戻す］を選択します。
7. 値ストリームを保存］を選択します。

バリューストリームの削除

GitLab 13.4 で導入されました。

カスタム値ストリームを削除するには

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. 右上隅でドロップダウンリストを選択し、削除するバリューストリームを選択します。
3. 削除（バリュー・ストリームの名前）］を選択します。
4. 確認するには、Delete を選択します。

サイクル完了までの日数の表示

• GitLab 13.4でChartの中央線が削除されました。
• GitLab 13.12で合計を平均に置き換えました。

合計時間チャートは、開発サイクルが完了するまでの平均日数を示しています。Chartは直近500件のワークフロー項目のデータを表示しています。

1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
2. Analyze > Value stream analyticsを選択します。
3. Filter results］ボックスの上で、ステージを選択します：
   • 全ステージのサイクルタイムの概要を表示するには、Overview（概要）を選択します。
   • 特定のステージのサイクルタイムを表示するには、ステージを選択します。
4. オプション。結果をフィルタリングします：
   1. フィルタ結果]テキストボックスを選択します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 日付範囲を調整するには
      • 開始日］フィールドで開始日を選択します。
      • Toフィールドで、終了日を選択します。

価値のストリーム分析のアクセス権限

バリューストリームアナリティクスのアクセス権限は、プロジェクトタイプによって異なります。

トラブルシューティング

Sidekiqによる100%のCPU使用率cronjob:analytics_cycle_analytics

バリューストリーム分析のバックグラウンドジョブがCPUリソースを独占することで、パフォーマンスに強い影響を与える可能性があります。

この状況から回復するには

1. Railsコンソールですべてのプロジェクトの機能を無効にし、既存のジョブを削除します：

   Project.find_each do |p|
     p.analytics_access_level='disabled';
     p.save!
   end
      
   Analytics::CycleAnalytics::GroupStage.delete_all
   Analytics::CycleAnalytics::Aggregation.delete_all
   

2. Sidekiqルーティングを、例えば単一のfeature_category=value_stream_management 、複数のfeature_category!=value_stream_management エントリで設定します。Enterprise Editionのリストで他の関連キューメタデータを検索します。
3. バリューストリーム分析をプロジェクトごとに有効化します。パフォーマンス要件に応じて、Sidekiqルーティングをさらに微調整する必要があるかもしれません。