ストーリー
現状分析フレームワークの全体像
組織のCI/CD現状を分析するために、4つのデータ収集手法を組み合わせます。
┌─────────────────────────────────────────┐
│ CI/CD現状分析フレームワーク │
├──────────┬──────────┬──────────┬─────────┤
│ チーム │ ツール │ メトリクス│ 開発者 │
│ ヒアリング │ 監査 │ 収集 │ サーベイ │
├──────────┼──────────┼──────────┼─────────┤
│ 定性 │ 定量 │ 定量 │ 定性 │
│ 主観 │ 客観 │ 客観 │ 主観 │
└──────────┴──────────┴──────────┴─────────┘
↓ ↓ ↓ ↓
┌─────────────────────────────────────┐
│ ギャップ分析 & 成熟度マッピング │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 改善ロードマップ策定 │
└─────────────────────────────────────┘
手法1:チームヒアリング
各チームのCI/CD担当者へのインタビューを通じて、定性的な情報を収集します。
ヒアリング項目
| カテゴリ | 質問例 |
|---|---|
| ビルド | ビルドにかかる時間は?ビルドが壊れたときの対応フローは? |
| テスト | 自動テストの種類と実行タイミングは?カバレッジの目標値は? |
| デプロイ | デプロイの頻度と手順は?ロールバック手順は整備されているか? |
| セキュリティ | セキュリティスキャンは実施しているか?シークレット管理の方法は? |
| 課題 | 最大のペインポイントは何か?理想の状態との差は? |
| ツール | 使用しているCI/CDツールとその選定理由は? |
ヒアリングのコツ
- オープンクエスチョンで始め、具体例を深掘りする
- 「問題ない」という回答の裏にある前提を確認する
- 技術的な課題だけでなく、プロセスや組織的な課題も聞く
- 理想の状態を聞くことで、潜在的なニーズを発見する
手法2:ツール監査
実際のCI/CD設定ファイルとツール構成を調査し、客観的なデータを収集します。
監査項目
audit_checklist:
tools:
- name: "CI/CDツール"
check: "使用ツール、バージョン、ライセンス形態"
- name: "コンテナレジストリ"
check: "使用レジストリ、イメージスキャン設定"
- name: "シークレット管理"
check: "管理方法、ローテーションポリシー"
pipeline_config:
- name: "パイプライン定義"
check: "ステージ構成、並列度、タイムアウト設定"
- name: "テスト設定"
check: "テスト種別、実行条件、カバレッジ閾値"
- name: "セキュリティスキャン"
check: "SAST/DAST/SCA設定、失敗時の挙動"
infrastructure:
- name: "ランナー/エージェント"
check: "種類、スペック、スケーリング設定"
- name: "環境構成"
check: "dev/staging/production環境の定義"
- name: "IaC"
check: "使用ツール、状態管理方法"
自動化された監査
可能な限り、監査を自動化してスクリプトで実行します。
# GitHub Actions のワークフロー一覧を取得
gh api /orgs/{org}/repos --paginate \
--jq '.[].full_name' | while read repo; do
echo "=== $repo ==="
gh api "/repos/$repo/actions/workflows" \
--jq '.workflows[] | "\(.name) - \(.state)"'
done
# セキュリティスキャンの有無をチェック
grep -r "snyk\|trivy\|semgrep\|codeql" .github/workflows/
手法3:メトリクス収集
CI/CDシステムから定量的なデータを収集し、客観的な成熟度を評価します。
収集するメトリクス
| カテゴリ | メトリクス | 収集元 |
|---|---|---|
| DORA | デプロイ頻度 | CI/CDツールのデプロイログ |
| DORA | リードタイム | コミットからデプロイまでの時間 |
| DORA | 変更失敗率 | ロールバック/ホットフィックスの頻度 |
| DORA | 復旧時間 | 障害検知から復旧までの時間 |
| パイプライン | ビルド時間(p50/p95) | CIツールのビルドログ |
| パイプライン | テスト実行時間 | テストランナーのレポート |
| パイプライン | パイプライン成功率 | CIツールのダッシュボード |
| コスト | CI/CDインフラ費用 | クラウドの請求情報 |
| コスト | ビルド時間あたりのコスト | ランナーの単価×実行時間 |
手法4:開発者サーベイ
開発者の主観的な満足度とペインポイントを収集します。
サーベイ設計
| 質問 | 回答形式 |
|---|---|
| CI/CDパイプラインの使いやすさを10段階で評価してください | スケール(1-10) |
| ビルド・テストの待ち時間は業務に影響していますか? | リッカート尺度(5段階) |
| パイプラインの設定変更を自分で行えますか? | はい/いいえ/部分的に |
| CI/CDで最も改善してほしい点は? | 自由記述 |
| 他チームのCI/CDプラクティスを参考にしたことはありますか? | はい/いいえ |
サーベイの分析
開発者満足度ヒートマップ(仮想例):
使いやすさ 速度 信頼性 柔軟性 セキュリティ
フロントチーム ★★★★ ★★★ ★★★★ ★★★★ ★★
バックエンドチーム ★★★ ★★ ★★★ ★★★ ★★★
インフラチーム ★★★★★ ★★★★ ★★★★★ ★★★★★ ★★★★
データチーム ★★ ★ ★★ ★★ ★
モバイルチーム ★★★ ★★★ ★★★ ★★ ★★
ギャップ分析
4つの手法で収集したデータを突き合わせ、自己認識と客観データのギャップを特定します。
| チーム | 自己評価 | 客観評価 | ギャップ | 要因 |
|---|---|---|---|---|
| チームA | Level 4 | Level 3 | -1 | セキュリティスキャン未実施を認識していない |
| チームB | Level 2 | Level 3 | +1 | テスト自動化が進んでいるが自覚がない |
| チームC | Level 3 | Level 1 | -2 | 手動デプロイをCI/CDと認識している |
「ギャップが大きいチームほど、丁寧なコミュニケーションが必要だ。データを突きつけるのではなく、一緒に改善を考えるスタンスでいこう」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 4つの手法 | ヒアリング、ツール監査、メトリクス収集、開発者サーベイ |
| データの種類 | 定性×定量、主観×客観の4象限 |
| ギャップ分析 | 自己認識と客観データの差を特定する |
| 改善ロードマップ | ギャップ分析をもとに優先順位をつけて計画する |
チェックリスト
- 4つのデータ収集手法を理解した
- 各手法の具体的な実施方法を把握した
- ギャップ分析の重要性を理解した
次のステップへ
次は演習です。ここまで学んだ成熟度モデル、課題パターン、分析フレームワークを使って、実際にCI/CD現状アセスメントを行ってみましょう。
推定読了時間: 30分