【ツール活用｜実務向け】CI/CDの「見えないボトルネック」を可視化する：パイプラインObservabilityの導入

1. 導入：なぜCI/CDの可観測性が不可欠なのか

開発チームの生産性を語る上で「DORAメトリクス」は欠かせない指標ですが、多くの現場では「リードタイムが長い」という結果は分かっても、「パイプラインのどこで、なぜ時間がかかっているのか」がブラックボックス化しています。CI/CDパイプラインに可観測性（Observability）を取り入れることで、単なる成功・失敗の判定を超えて、実行時間の推移やリソース消費を定量的かつ継続的に追跡できます。これにより、勘や経験に頼らない「データ駆動型のパイプライン改善」が可能になります。

2. 基礎知識：CI/CDの可観測性とは

CI/CDにおける可観測性とは、パイプラインという「システム」の内部状態を、出力されるデータ（メトリクスやログ）から推測・理解できるようにすることです。
Build Metrics：各ジョブの実行時間やキューイング時間。
Lead Time for Changes：コードがコミットされてから本番環境にデプロイされるまでの時間。
これらを可視化することで、「テストの並列化が不十分」「特定のビルドステップでCPUが枯渇している」といった隠れた課題を特定します。

3. 実装/解決策：メトリクスの収集と可視化

実務では、GitHub ActionsやGitLab CIなどのCIツールからメトリクスを抽出し、PrometheusやDatadog等の監視基盤へ転送するアーキテクチャが一般的です。
1. データ収集：CIの各ステップ終了時に実行時間やステータスをAPI経由で外部ストレージに送信する。
2. データ蓄積：時系列データベース（TSDB）に保存する。
3. 可視化：Grafanaなどでダッシュボード化し、異常値の検知やトレンド分析を行う。

4. サンプルプログラム：GitHub Actionsでの実行時間計測例

以下のコードは、GitHub Actionsのステップ終了時に実行時間を取得し、外部のエンドポイントへ送信する概念的な例です。

GitHub Actionsのワークフロー例
jobs:
  test:
    runs-on: ubuntu-latest
    steps:

name: Checkout

        uses: actions/checkout@v3

      # メトリクス収集の開始時間を環境変数に保持

name: Start Timer

        run: echo "START_TIME=$(date +%s)" >> $GITHUB_ENV


name: Run Tests

        run: npm test

      # 終了時間を取得し、APIへ送信（実務ではDatadogや自作エンドポイントへ）

name: Report Metrics

        if: always()
        run: |
          END_TIME=$(date +%s)
          DURATION=$((END_TIME - START_TIME))
          # ステップごとの実行時間をメトリクスサーバーへPOSTするイメージ
          curl -X POST -H "Content-Type: application/json" \
          -d "{\"job\":\"test\", \"duration\": $DURATION, \"status\": \"${{ job.status }}\"}" \
          https://your-metrics-collector.example.com/api/v1/metrics

5. 応用・注意点：現場で陥りやすい罠

「メトリクスの過剰収集」に注意
すべてのステップを詳細に計測しようとすると、計測処理自体がCI時間を圧迫する本末転倒な状況に陥ります。まずは「全体のリードタイム」と「最も重いビルドジョブ」の2点に絞って計測を始めるのが定石です。
「平均値」の落とし穴
実行時間の平均値だけを見ていると、特定のケースで発生する「外れ値（ビルドが極端に詰まる現象）」を見落とします。可視化の際は、平均値だけでなく「P95（上位95%の遅延）」や「最大値」を追跡し、ボトルネックの発生率を把握するようにしましょう。