こんにちは！日々のビルド待ち、長くてうんざりしていませんか？「たかが待ち時間」と放置しているその数分が、チーム全体の生産性をじわじわと削り取っている隠れた巨大コストになっていることに、そろそろ気づく頃です。
今回は、世界中の現場で愛され続けるCI/CDの重鎮「Jenkins」をテーマに、誰も教えてくれない「ビルド待機時間の最適化」についてお話しします。
「Jenkinsって難しそう…」「監視とかPrometheusとか、なんだかハードルが高そう…」と思うかもしれませんが、安心してください。この記事を読めば、初心者の方でも手を動かしながら、データに基づいたプロフェッショナルなリソース改善手法をマスターできます。これをマスターすれば、あなたのチームの開発スピードは劇的に変わり、毎日の作業が驚くほど快適になりますよ！
—
1. そもそもJenkinsとは？なぜビルド待機時間が問題になるのか
まずは、Jenkinsの役割を優しく整理しておきましょう。
Jenkinsの役割
Jenkinsは、いわば「開発チーム専属の優秀なロボット作業員」です。私たちがコードを書くたびに、「テストして」「ビルドして」「本番サーバーにデプロイして」という退屈でミスしやすい一連の作業を、文句も言わず24時間体制で自動実行してくれます。
「ビルド待機時間」という隠れたコスト
さて、ここで問題になるのが「ビルド待機時間（Queue Time）」です。
開発者が「よし、コードをプッシュしたぞ！」とJenkinsにビルドを依頼したとします。しかし、JenkinsのCPUやメモリがいっぱいだったり、作業を手伝うロボット（ビルドノード）が足りなかったりすると、ジョブは「待ち行列（キュー）」に入れられます。
> 「ビルドが始まるまで15分待ちました…」
これが毎日、何十回も発生していたらどうでしょう？ 開発者は待ち時間に集中力を途切れさせ、開発効率はガタ落ちです。
「なんとなくサーバを大きくする」のではなく、「どのジョブが原因で、いつリソースが枯渇しているのか」をデータで正確に把握し、最適化することが、私たちDevOpsエンジニアの腕の見せ所なのです。
—
2. 基礎セットアップ：Jenkinsの起動とPrometheus連携
それでは、実際に手を動かしていきましょう。今回はDockerを使って、ローカル環境に最短でJenkinsと監視環境を構築します。
ステップ1：DockerでJenkinsを立ち上げる
まずは、Jenkinsを動かすためのコンテナを用意します。以下の `docker-compose.yml` を作成してください。
version: ‘3.8’
services:
jenkins:
image: jenkins/jenkins:lts
restart: always
ports:
- “8080:8080”
- “50000:50000”
volumes:
- jenkins_data:/var/jenkins_home
environment:
- JAVA_OPTS=”-Djenkins.install.runSetupWizard=false” # 初回ウィザードをスキップしてサクッと起動
volumes:
jenkins_data:
ターミナルで `docker compose up -d` を実行すれば、数秒で `http://localhost:8080` にJenkinsが立ち上がります。
ステップ2：Prometheusでメトリックを収集できるようにする
Jenkins内部の「いまキューにいくつジョブがあるか」「ビルダーが何台稼働しているか」というデータを外部に取り出すために、Prometheus metrics pluginをインストールします。
1. Jenkinsの管理画面にアクセス (`http://localhost:8080`)
2. 「Jenkinsの管理」 ＞ 「プラグインの管理」 を開く
3. 「利用可能」タブから `Prometheus metrics` を検索してインストール
4. インストール完了後、`http://localhost:8080/prometheus/` にアクセスしてみてください。ずらっと数字の羅列（メトリック）が表示されれば成功です！これが、監視の原データとなります。
—
3. HelloWorld的な動作確認：キューイングを可視化する
監視の仕組みが整ったところで、実際に「ビルドが待たされている状態」をあえて作り出し、データとしてどう検知されるかを見てみましょう。
1. 意図的に重たいテストジョブを作る
Jenkinsの管理画面から「新規ジョブ作成」を選び、フリースタイル・プロジェクトで `test-wait-job` を作成します。
ビルド手順（シェルスクリプトの実行など）に、以下のように少し時間を食う処理を記述します。
!/bin/bash
echo “ビルドを開始します…（わざと10秒待ちます）”
sleep 10
echo “ビルド完了！”
これを連続で何回も実行（ビルドを連打）してみてください。すると、ジョブがすぐに実行されず、「ビルド実行待ち（In the queue）」の状態が発生します。
2. PrometheusとGrafanaで可視化する
（※今回は簡略化のため、Prometheusが先ほどの `/prometheus/` エンドポイントをスクレイピングしている前提でお話しします）
Grafanaなどの可視化ツールを接続し、以下のPromQL（Prometheusのクエリ言語）を使ってグラフを描画します。
- 現在のビルドキュー数（どれだけ待たされているか）
jenkins_queue_size
- ジョブの実行時間（どこがボトルネックか）
jenkins_job_duration_seconds_sum
Grafanaのダッシュボードに「現在キューにたまっているジョブの数」がリアルタイムで波形として表示された瞬間、あなたのエンジニアとしての視界がパーッとクリアになるはずです。「あ、お昼休みの直後にみんなが一斉にプッシュするから、ここでキューが跳ね上がっているんだな」といった事実が、直感ではなく客観的なデータとして目の前に現れます。
—
4. プロの知見：データに基づいてリソースを極限まで最適化する
可視化ができたら、いよいよ本番です。得られたデータを元に、スケーラビリティを改善していきましょう。
① ピークタイムに合わせた「エージェント（Node）」の自動スケーリング
もし `jenkins_queue_size` が常に「0より大きい状態」になっているなら、それは圧倒的にビルドを処理するパワー（労働者）が足りていません。
Jenkinsの「Kubernetesプラグイン」などを導入し、負荷が高まったときだけ自動でコンテナのビルドワーカーが立ち上がり、暇になったら消える仕組み（オートスケーリング）を導入しましょう。これにより、サーバー代（コスト）を最小限に抑えつつ、待ち時間をゼロに近づけられます。
② 「重いジョブ」の切り分けと実行時間の分散
`jenkins_job_duration_seconds_sum` のデータを眺めると、「特定の結合テストだけが毎回20分かかっている」といった真のボトルネックが見えてきます。
これらは夜間バッチに回したり、並列処理（Parallel execution）を導入して処理を分割したりすることで、メインのCI/CDパイプラインを驚くほど軽量に保つことができます。
—
おわりに
いかがでしたか？
今回は、Jenkinsのビルド待機時間をPrometheusで可視化し、データに基づいてリソースを最適化する手法を解説しました。
「なんとなく遅いからサーバーを強くする」という場当たり的なアプローチから卒業し、「データに基づいてボトルネックを叩く」というエンジニアリングを行えるようになると、チームの開発スピードは劇的に向上します。何より、待ち時間が減ることで開発者のストレスが消え、プロダクトに向き合う純粋な楽しい時間が増えるはずです。
ぜひあなたの環境でも今日のステップを試して、快適でスマートなCI/CDパイプラインを手に入れてくださいね。あなたの開発ライフがより素晴らしいものになることを応援しています！