はじめに：なぜウォーターフォールの現場で 4keys なのか
私が所属するチームの開発プロセスは ウォーターフォール です。
アジャイルでもスクラムでもない。設計書は Excel、リリースは計画ベース、自動テストの整備もまだ道半ば。そんな現場で「DORA の 4keys を計測しよう」と言い出したら、おそらく多くの人が「うちには関係ない」と思うでしょう。
でも、私がこの仕組みを作ろうと思ったのは、まさにその 「うちには関係ない」側の現場 にいたからです。
感じていた課題
- リリース頻度が低い。大きなリリースに機能を詰め込み、一気に出すスタイル
- 小バグが多い。リリース後に細かい不具合が見つかり、修正リリースが走る
- 品質が良いとは言い切れない。しかし「なんとなく」の肌感覚でしかなく、数値で語れない
- 自動テストの整備が追いついていない。手動テストへの依存が大きい
この「なんとなく品質が悪い気がする」「リリースのたびに不安がある」という状況を、どうにか 数字で見える化 できないか。そう考えていたときに出会ったのが VSM（Value Stream Mapping） と DORA の Four Keys でした。
VSM と DORA に感銘を受けた
VSM は、開発プロセスの中で「価値が生まれている時間」と「待ち時間」を可視化する手法です。DORA の研究（『Accelerate』で有名）は、ソフトウェアデリバリーのパフォーマンスが組織パフォーマンスと強く相関することを統計的に示しています。
印象的だったのは、DORA の 4keys が 開発手法を問わない 指標だという点です。アジャイルだから高い、ウォーターフォールだから低い、ではなく、「今の自分たちがどこにいるのか」を客観的に測る物差しとして使える。ウォーターフォールであっても、デプロイ頻度やリードタイムを計測することで「改善の方向性」が見えてきます。
「まず測ろう。測れば語れる。語れれば変えられる」——そう思いました。
SaaS はあった。でも全員には届かなかった
実は、4keys を可視化できる SaaS ツールは会社として導入されていました。ただし問題が2つ。
- 利用には役職者の承認と説得が必要 で、気軽に「ちょっと試してみよう」ができない
- チーム全員がアクセスできるわけではない。見られる人が限られている
メトリクスの本当の価値は、チーム全員が日常的に目にする ことで生まれます。一部の人だけが見ているダッシュボードでは「あの人が見てるアレ」で終わってしまう。
だったら、チーム全員がアクセスできる自社ポータルに組み込んで、「こういうものだよ」とまず触れてもらおう。既存の SaaS を否定したいのではなく、チームへの浸透のための最初の一歩として自作を選びました。
全体アーキテクチャ
┌──────────────────┐
│ GitHub Actions │
│ │
│ on: push (main) │
│ + 手動実行対応 │
│ │
│ ① メトリクス収集 │
│ ② JSON生成 │
│ ③ SFTP転送 │
└────────┬─────────┘
│ SFTP
▼
┌──────────────────┐
│ 所定サーバ │
│ /data/4keys/ │
└────────┬─────────┘
│ ファイル監視
▼
┌──────────────────────────────┐
│ 開発ポータルサイト │
│ ┌──────────┐ ┌────────────┐ │
│ │ Backend │ │ Frontend │ │
│ │ (Java) │ │ (Vue.js) │ │
│ │ │ │ │ │
│ │ JSON取込 │ │ ダッシュ │ │
│ │ DB更新 │ │ ボード表示 │ │
│ └────┬─────┘ └────────────┘ │
│ │ │
│ ┌────▼──────┐ │
│ │PostgreSQL │ │
│ └───────────┘ │
└──────────────────────────────┘
設計上のポイントは、Actions とポータルを SFTP + ファイル監視で疎結合 にしていることです。Actions 側は「JSON を所定のディレクトリに置くだけ」、ポータル側は「ファイルが来たら取り込むだけ」。お互いの内部実装を知らなくてよいので、片方の変更が他方に影響しません。
ポータルサイト自体は元々チーム内で使っていた開発支援ツールで、ステージング用パイプラインの実行やテストツールなどが集約されています。ここに 4keys ダッシュボードを追加する形で実装しました。
計測対象の 3 指標
DORA の 4keys のうち、今回は GitHub のイベントから取得可能な 3 指標 を計測しています。
1. デプロイ頻度（Deployment Frequency）
main ブランチへのマージ回数を期間ごとに集計します。
main への push をトリガーに GitHub Actions が走り、1 マージ = 1 レコードが生成されるため、DB に蓄積されたレコード数を日次・週次・月次で集計するだけで算出できます。
ウォーターフォールの場合、この数字は「低い」ことが多いです。でもそれが可視化されること自体に意味があります。「月に 2 回しかマージしていない」という事実が数字で見えると、「もう少し細かく分割してマージできないか」という議論のきっかけになります。
2. 変更リードタイム（Change Lead Time）
PR の最初のコミットから main マージまでの経過時間を計測します。
GitHub API で PR に紐づくコミット一覧を取得し、最古コミットの authored_date とマージ時刻の差分を秒単位で算出します。
ウォーターフォールでは設計・実装・テストが直列に進むため、リードタイムは長くなりがちです。ただ、「PR が何日間レビュー待ちで滞留していたか」が見えるだけでも改善余地に気づけます。
3. 変更障害率（Change Failure Rate）
一定期間のデプロイのうち、障害を引き起こしたデプロイの割合です。
自動判定は hotfix/ ブランチからのマージや incident ラベル付き PR で行い、それで拾いきれないケースはポータル上の手動フラグで補完します。完全自動化より「まず計測を始める」ことを優先しました。
MTTR（平均復旧時間） は障害検知〜復旧の時間であり、GitHub のイベントだけでは完結しないため今回のスコープ外です。アラート管理ツールとの連携による将来対応を想定しています。
GitHub Actions ワークフロー
ワークフロー定義
name: 4keys Metrics Collection
on:
push:
branches: [main]
workflow_dispatch: # 手動実行にも対応
jobs:
collect-metrics:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 全履歴取得（リードタイム計算に必要）
- name: Collect merge metrics
id: metrics
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# 直近マージされたPR情報を取得
PR_NUMBER=$(gh pr list --state merged --base main --limit 1 \
--json number --jq '.[0].number')
if [ -z "$PR_NUMBER" ]; then
echo "skip=true" >> "$GITHUB_OUTPUT"
exit 0
fi
# PR詳細
PR_DATA=$(gh pr view "$PR_NUMBER" --json \
mergedAt,createdAt,commits,labels,headRefName)
MERGED_AT=$(echo "$PR_DATA" | jq -r '.mergedAt')
HEAD_BRANCH=$(echo "$PR_DATA" | jq -r '.headRefName')
# 最初のコミット日時（リードタイム計算用）
FIRST_COMMIT=$(echo "$PR_DATA" | jq -r \
'[.commits[].authoredDate] | sort | first')
# リードタイム算出（秒）
MERGED_EPOCH=$(date -d "$MERGED_AT" +%s)
FIRST_COMMIT_EPOCH=$(date -d "$FIRST_COMMIT" +%s)
LEAD_TIME_SEC=$((MERGED_EPOCH - FIRST_COMMIT_EPOCH))
# 障害デプロイの判定
IS_FAILURE="false"
if echo "$HEAD_BRANCH" | grep -qE "^hotfix/"; then
IS_FAILURE="true"
fi
if echo "$PR_DATA" | jq -e '.labels[] | select(.name == "incident")' > /dev/null 2>&1; then
IS_FAILURE="true"
fi
# JSON 生成
TIMESTAMP=$(date -u +%Y%m%d%H%M%S)
FILENAME="4keys_${TIMESTAMP}.json"
jq -n \
--arg repo "${{ github.repository }}" \
--argjson pr "$PR_NUMBER" \
--arg merged "$MERGED_AT" \
--arg first_commit "$FIRST_COMMIT" \
--argjson lead_time "$LEAD_TIME_SEC" \
--argjson is_failure "$IS_FAILURE" \
--arg branch "$HEAD_BRANCH" \
--arg collected "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
'{
repository: $repo,
pr_number: $pr,
merged_at: $merged,
first_commit_at: $first_commit,
lead_time_seconds: $lead_time,
is_failure: $is_failure,
branch: $branch,
collected_at: $collected
}' > "$FILENAME"
echo "filename=$FILENAME" >> "$GITHUB_OUTPUT"
- name: Transfer via SFTP
if: steps.metrics.outputs.skip != 'true'
env:
SFTP_HOST: ${{ secrets.SFTP_HOST }}
SFTP_USER: ${{ secrets.SFTP_USER }}
SFTP_KEY: ${{ secrets.SFTP_KEY }}
SFTP_DIR: ${{ secrets.SFTP_DIR }}
run: |
echo "$SFTP_KEY" > /tmp/sftp_key
chmod 600 /tmp/sftp_key
sftp -i /tmp/sftp_key \
-o StrictHostKeyChecking=no \
"${SFTP_USER}@${SFTP_HOST}" <<EOF
cd ${SFTP_DIR}
put ${{ steps.metrics.outputs.filename }}
bye
EOF
rm -f /tmp/sftp_key
Secrets 管理
| Secret 名 | 内容 |
|---|---|
SFTP_HOST |
転送先サーバのホスト名 |
SFTP_USER |
SFTP 接続ユーザー |
SFTP_KEY |
SSH 秘密鍵（PEM 形式） |
SFTP_DIR |
JSON 配置先ディレクトリパス |
秘密鍵を GitHub Secrets に登録する際は、改行を含む PEM 形式をそのまま貼り付けてください。Base64 エンコードは不要です。また、GHAS（GitHub Advanced Security）の Push Protection を有効にしておくと、うっかりシークレットをコードに書いてしまった際にプッシュ時点でブロックしてくれます。
ポータルサイド：ファイル監視 → DB 取り込み → 表示
ファイル監視と DB 取り込み（バックエンド）
ポータルの Java バックエンドで所定ディレクトリをポーリングし、新しい JSON を検知したら PostgreSQL に取り込みます。
@ApplicationScoped
public class FourKeysFileWatcher {
private static final Logger LOG = Logger.getLogger(FourKeysFileWatcher.class.getName());
@Inject
private FourKeysRepository repository;
private final Path watchDir;
private final Path processedDir;
@Inject
public FourKeysFileWatcher(
@ConfigProperty(name = "fourkeys.watch.dir") String dir,
@ConfigProperty(name = "fourkeys.processed.dir") String processed) {
this.watchDir = Path.of(dir);
this.processedDir = Path.of(processed);
}
// 定期ポーリング（例: 30秒間隔）
@Schedule(second = "*/30", minute = "*", hour = "*", persistent = false)
public void poll() {
try (var files = Files.list(watchDir)) {
files.filter(p -> p.toString().endsWith(".json"))
.sorted()
.forEach(this::processFile);
} catch (IOException e) {
LOG.log(Level.WARNING, "ファイル監視中にエラー", e);
}
}
private void processFile(Path file) {
try {
String content = Files.readString(file);
FourKeysRecord record = parseJson(content);
// 重複チェック（同じPR番号+リポジトリ）
if (!repository.exists(record.repository(), record.prNumber())) {
repository.insert(record);
LOG.info("取り込み完了: " + file.getFileName());
}
// 処理済みディレクトリへ移動
Files.move(file, processedDir.resolve(file.getFileName()),
StandardCopyOption.REPLACE_EXISTING);
} catch (Exception e) {
LOG.log(Level.SEVERE, "ファイル処理失敗: " + file, e);
}
}
}
処理済みファイルは別ディレクトリへ移動する方式にしています。削除ではなく移動にすることで、問題が起きたときに元データを確認できます。
テーブル設計
CREATE TABLE four_keys_metrics (
id BIGSERIAL PRIMARY KEY,
repository VARCHAR(255) NOT NULL,
pr_number INTEGER NOT NULL,
merged_at TIMESTAMPTZ NOT NULL,
first_commit TIMESTAMPTZ NOT NULL,
lead_time_sec INTEGER NOT NULL,
is_failure BOOLEAN NOT NULL DEFAULT FALSE,
branch VARCHAR(255),
collected_at TIMESTAMPTZ NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
UNIQUE (repository, pr_number)
);
-- 集計用インデックス
CREATE INDEX idx_metrics_merged_at ON four_keys_metrics (merged_at);
CREATE INDEX idx_metrics_repo ON four_keys_metrics (repository);
ダッシュボード（フロントエンド）
Vue.js のフロントエンドで API から集計データを取得し、ダッシュボードとして表示します。
┌─────────────────────────────────────────────────┐
│ 📊 4keys ダッシュボード │
├─────────────┬───────────────┬───────────────────┤
│ デプロイ頻度 │ 変更リードタイム │ 変更障害率 │
│ 3回/週 │ 4.2日 │ 8.3% │
├─────────────┴───────────────┴───────────────────┤
│ │
│ 📈 デプロイ頻度の推移（週次） │
│ ┃ │
│ ┃ ■ │
│ ┃ ■ ■ ■ ■ │
│ ┃ ■ ■ ■ ■ ■ ■ ■ ■ │
│ ┗━━━━━━━━━━━━━━━━━━━━━━ │
│ W1 W2 W3 W4 W5 W6 W7 W8 │
│ │
│ 📈 リードタイム分布 │
│ │
│ 📈 障害率の推移 │
│ │
└─────────────────────────────────────────────────┘
表示する内容はシンプルに徹しました。最初から凝ったグラフを作り込むよりも、「数字が見える」という体験をまずチームに届ける ことを優先しています。
ウォーターフォールの現場で可視化して見えてきたこと
まだ運用を始めたばかりですが、数字が見えること自体が変化を生み始めています。
「遅い」が具体的になる
「リリースが遅い気がする」から「PR のリードタイムが平均 X 日」に変わると、「じゃあ何が X 日を食っているのか」という次の問いが自然に生まれます。レビュー待ちなのか、テスト待ちなのか、承認プロセスなのか。感覚を数字に変換するだけで、議論の質が変わります。
「品質が悪い」を分解できる
「小バグが多い」という肌感覚も、変更障害率として数字になると「直近 3 ヶ月で X% のマージが hotfix を伴っている」と言い換えられます。それが許容範囲なのかどうかの判断基準を持てるようになります。
SaaS 導入への橋渡し
自作ダッシュボードで「こういうメトリクスが見えると便利ですよね」をチームが体験すると、本格的な SaaS ツールの導入提案に対する心理的ハードルが下がります。「よくわからないツールを入れる」ではなく「あのダッシュボードのもっとすごい版」として説明できるようになります。
まとめ
| やったこと | 内容 |
|---|---|
| データ収集 | GitHub Actions で main マージ時に 4keys メトリクスを JSON 出力 |
| データ転送 | SFTP で所定サーバへ転送（疎結合） |
| データ取り込み | Java バックエンドでファイル監視 → PostgreSQL へ INSERT |
| 可視化 | Vue.js ダッシュボードで週次・月次の推移を表示 |
技術的には特に難しいことはしていません。GitHub CLI でデータを集めて、JSON にして、SFTP で送って、DB に入れて、画面に出す。それだけです。
大事だったのは技術ではなく 「まず計測を始める」という判断 でした。
ウォーターフォールだから 4keys は関係ない、ということはありません。むしろ、改善の余地が大きい現場ほど、可視化のインパクトは大きいと感じています。完璧な自動テストや CI/CD パイプラインが揃ってから計測するのではなく、今の状態を測ることが第一歩 です。
自分たちが今どこにいるのかを知ること。そこからしか、改善は始まらないと思います。
本記事のコード例は実装のエッセンスを示すために一般化したサンプルです。実際の環境に合わせて調整してください。