LESSON 30分

ストーリー

田中VPoE
成熟度モデルと課題パターンを理解したところで、実際に組織を分析するフレームワークを紹介しよう
あなた
ヒアリングシートのようなものですか?
田中VPoE
それだけじゃない。ヒアリング、ツール監査、メトリクス収集、開発者サーベイ — 複数のデータソースを組み合わせて立体的に分析するんだ。片方からだけ見ても真実は見えない
あなた
たとえば、チームが「うちのCI/CDは問題ない」と言っていても、メトリクスを見ると実はリードタイムが長い、みたいなことですか?
田中VPoE
まさにそれだ。自己認識と客観データのギャップこそ、最も価値のある発見になる

現状分析フレームワークの全体像

組織の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つの手法で収集したデータを突き合わせ、自己認識と客観データのギャップを特定します。

チーム自己評価客観評価ギャップ要因
チームALevel 4Level 3-1セキュリティスキャン未実施を認識していない
チームBLevel 2Level 3+1テスト自動化が進んでいるが自覚がない
チームCLevel 3Level 1-2手動デプロイをCI/CDと認識している

「ギャップが大きいチームほど、丁寧なコミュニケーションが必要だ。データを突きつけるのではなく、一緒に改善を考えるスタンスでいこう」 — 田中VPoE


まとめ

ポイント内容
4つの手法ヒアリング、ツール監査、メトリクス収集、開発者サーベイ
データの種類定性×定量、主観×客観の4象限
ギャップ分析自己認識と客観データの差を特定する
改善ロードマップギャップ分析をもとに優先順位をつけて計画する

チェックリスト

  • 4つのデータ収集手法を理解した
  • 各手法の具体的な実施方法を把握した
  • ギャップ分析の重要性を理解した

次のステップへ

次は演習です。ここまで学んだ成熟度モデル、課題パターン、分析フレームワークを使って、実際にCI/CD現状アセスメントを行ってみましょう。


推定読了時間: 30分