CI/CDを導入してもリリース速度が変わらないのはなぜか？承認プロセスと手動テストのボトルネックを解消する手法

CI/CD（継続的インテグレーション／継続的デリバリー）を導入する目的は組織によって違います。テスト漏れや手作業のミスを減らしたい、リリース作業の工数を減らしたい、という動機で導入するケースも多いでしょう。一方で、事業部門から「完成したと聞いた改修が、なかなか本番に出てこない」と言われ続け、その解決策としてCI/CDに期待をかけた組織もあるはずです。本記事は後者の立場で書いています。パイプラインを整え、ビルドもデプロイも自動になった。それでも本番公開までの日数がほとんど縮まらない。このような状況に心当たりがある方に向けて、原因と手の打ち方を整理しました。
そうした場合にまず疑うべきは、パイプラインの外側にある承認の順番待ちと、手作業で行っているテストです。本記事では、承認の一部を開発チーム内のコードレビューと自動チェックに置き換え、手作業のテストを段階的に自動化する進め方を6つのステップで紹介します。あわせて、監査やセキュリティの面で押さえておくべき点にも触れます。

なぜCI/CDだけではリリースが速くならないのか

変更をコミットしてから本番環境にデプロイされるまでの時間（リードタイム）は、ビルド、テスト、承認、デプロイといった工程の合計です。そのうち最も長く時間を取っている工程がボトルネックで、全体の速さはほぼこの工程で決まります。
なお、本記事でいう「リリース速度」はリリースの回数（頻度）ではなく、このリードタイムを指します。DORA（DevOps Research and Assessment）が定義する「変更のリードタイム」と同じ考え方です。フィーチャーフラグで機能の公開を後ろにずらす場合は、デプロイから公開までの時間を別に測る必要があります（ステップ5参照）。要望を受けてから開発に着手するまでの待ち時間は、本記事では扱いません。

CI/CDが自動化するのは、コードの統合、テスト、デプロイ（本番環境への配置）といった技術的な工程です。ただし継続的デリバリーは、いつでも本番に出せる状態を保つことを指す考え方で、実際に本番へ出すタイミングを人が決める運用も含みます。テストに合格した変更をすべて自動で本番に反映する「継続的デプロイ」とは区別されます。つまり継続的デリバリーを実現していても、本番に出す判断の手前で承認を待つ構造は残り得ます。
ビルドが数分で終わるようになっても、その先で次のような待ちが発生していれば、本番に出るまでの日数はほとんど変わりません。

• 上長、品質保証部門、情報システム部門と、承認を一つずつ順番に待つ
• 月1回などの「リリース判定会議」や変更管理委員会の開催日まで待つ
• 手作業の回帰テスト（既存機能が壊れていないかの確認）に数日かかる

テストについても、パイプラインで自動実行されるのが単体テストと静的解析までにとどまっていれば、画面を操作して確認する結合テスト、既存機能をひととおり確かめる回帰テスト、業務部門が行う受入テストは手作業のまま残ります。これらが自動化されずに残る理由としては、テスト用の環境やデータを用意するのが難しい、画面の変更が多く自動テストの保守が重い、品質保証部門が独自の手順書で実施している、といった事情が挙げられます。
承認についても、押印をワークフローシステムに置き換えただけでは、段数が減らない限り待ち時間は変わりません。承認が増える背景には、過去の障害の再発防止策や、内部統制・監査への対応があります。障害のたびに確認工程を追加し、その後見直していなければ、承認の段数は増える一方です。

DORAは、変更管理委員会（CAB）や上位の管理者など、変更を提案したチームの外にいる人による重い承認プロセスが、デリバリーの性能を下げるという調査結果を公表しています。同じ資料では、変更の承認は開発過程でのピアレビュー（同僚によるコードレビュー）と、問題のある変更を早い段階で止める自動化によって行うのが良いとしています（出典：DORA「Streamlining change approval」）。

従来型のリリース管理と、自動化を前提にしたリリース管理の違い

従来のリリース管理は、リリースの前に人が確認し、問題があれば止めることで品質を守ってきました。自動化を前提にした管理では、品質チェックをパイプラインに組み込み、基準を満たした変更はそのまま先へ進めます。主な違いは次のとおりです。

承認プロセスと手動テストを見直すメリット

• リードタイムの短縮：
  承認やテストの待ちが減った分だけ、完成した変更が早く本番に届きます。
• 障害影響の縮小：
  1回のリリースに含まれる変更が少なくなるので、障害が起きたときに原因を絞り込みやすく、切り戻す範囲も小さくて済みます。
• 承認者の負担軽減：
  すべての変更に目を通す必要がなくなり、影響の大きい変更の確認に時間を使えます。
• 証跡の自動化：
  誰がいつ何を承認し、どのテストに通ったかが記録として残ります。
• 開発者体験の向上：
  作り終えた変更がリリース枠を待つ時間が短くなり、待っている間に仕様が変わって作り直す、といった手戻りも減ります。

見直しに伴うデメリットと留意点

• 初期投資が必要： 
  自動テストを書き、テスト環境を整えるには、まとまった工数がかかります。
• 合意形成に時間がかかる：
  承認ルールを変えるには、管理部門、品質保証部門、監査対応部門との調整が必要です。
• 承認者の役割が変わる：
  承認者の仕事が、変更を一つずつ見て止めることから、自動チェックの基準を決めて維持することに変わります。役割の変化について、承認者と時間をかけて話し合う必要があります。
• 自動テストの保守コスト：
  仕様が変わればテストコードも直す必要があり、放置すると失敗し続けるテストが積み上がります。
• AI活用時の留意点：
  AIの出力には誤りが混じるため、人の確認は省けません。ソースコードを外部のサービスに送ることになる場合は、社内の情報管理ルールに抵触しないかも確認が必要です。
• パイプラインが統制の要になる：
  承認の役割を自動チェックに移すと、パイプラインの設定を変えられる人が事実上の承認者になります。設定変更の管理と、変更できる人の権限管理が必要になります。
• 統制要件への説明責任：
  承認を減らしても内部統制上の要件を満たしていることを、監査の場で説明できるようにしておく必要があります。

ボトルネックを解消する6ステップ

ステップ1：待ち時間を可視化する
直近のリリースを1件選び、コミットから本番へのデプロイまでの各工程について、実際に手を動かしていた時間と、待っていた時間を書き出します（バリューストリームマッピング）。工程ごとに並べると、どこで時間を失っているかが数字で分かります。この数字は、後で関係部門に見直しを持ちかけるときの材料にもなります。

ステップ2：承認を棚卸しし、リスクで分類する 
次に、いまある承認を一つずつ取り上げ、何を防ぐために設けたのかを確認します。そのうえで、変更を「標準変更（手順が決まっていて低リスク）」「通常変更」「重大変更」に分け、どの区分にどの承認が必要かを決め直します。設けた理由を説明できない承認は、廃止や統合を検討します。
ITILでいう標準変更は、手順が定型化され、事前に承認された変更の型を指します。本記事ではこの考え方を応用し、一定の条件を満たすコード変更を標準変更として扱います。判定基準は組織ごとに決めるものですが、たとえば次のような条件を組み合わせる方法があります。

• データベースの構造変更（スキーマ変更）を含まない
• 認証・認可、決済、個人情報を扱う処理に触れない
• インフラ構成やパイプライン設定のファイルを変更しない
• 変更の規模が、あらかじめ決めた上限（変更行数など）を超えない（変更行数はリスクの粗い目安にすぎないため、ほかの条件と組み合わせて使う）
• 機能を無効にした状態で本番に配置できる（フィーチャーフラグで公開を制御できる）

変更されたファイルのパスや差分の規模など、パイプラインで機械的に判定できる条件にしておくと、判断が人によってぶれません。

ステップ3：承認を自動チェックに置き換える 
標準変更については、変更を書いた人とは別の担当者によるコードレビューの承認、自動テストの合格、静的解析で重大な指摘がないことを条件にし、これを満たせば承認会議や部門長の承認を経ずに本番へ進めるようにします。人による確認をなくすのではなく、確認する人を開発チーム内のレビュアーに移すという考え方です。承認者には判定基準を文書で示し、実際の判定結果をログで確認できるようにしておきます。通常変更や重大変更は引き続き人が承認しますが、AI搭載ツールでプルリクエストの変更内容を要約させておけば、承認者が差分を読み解く時間を短くできます。セキュリティ面の自動チェックについては、「AI時代のサイバー攻撃・情報漏洩を仕組みで防ぐ：DevSecOpsとAI搭載ツールで始める脆弱性チェックの自動化 」をご覧ください。
承認の役割をパイプラインに移す場合は、パイプラインそのものの管理が重要になります。ワークフローの定義ファイル、ブランチの保護ルール、静的解析の判定基準を書き換えられる人は、事実上、承認を省略できる立場にあるからです。これらの変更は通常変更として人が承認すること、変更できる権限を限られた担当者に絞ること、管理者がルールを迂回した場合に記録が残るようにすることを、あわせて決めておきます。
パイプラインのログを監査の証跡として使う場合は、保存期間にも注意が必要です。たとえばGitHub Actionsでは、実行ログは既定で90日後に自動で削除され、プライベートリポジトリでも設定できる上限は400日です（出典：GitHub Docs）。監査で求められる保存期間がこれより長い場合は、ログを別の保管先へ書き出す仕組みが必要です。保管先では、書き込んだ記録を後から変更・削除できない設定にするなど、改ざんを防ぐ方法もあわせて監査部門と決めておきます。また、コードレビューの承認はパイプラインの実行ログではなく、プルリクエストの履歴など、ソースコード管理サービスの側に記録されるのが一般的です。テストの結果とレビューの承認履歴は、両方を保管の対象にします。
人の承認を外した運用が内部統制や業界の基準（カード情報を扱う場合のPCI DSSなど）を満たすかどうかは、対象となる規制と監査人の判断によって変わります。どの承認を、どのレビューや自動チェックで代替するのかを一覧にし、事前に監査部門や監査人と合意しておいてください。

ステップ4：パイプラインの外に残っているテストを洗い出し、自動化の優先度をつける
結合テスト、回帰テスト、受入テストのうち、いま手作業で行っているものを一覧にします。自動化の候補は、リリースのたびに必ず実施していて、手順が毎回同じものです。いきなり全件を自動化しようとすると、作ったテストの保守に追われることになるので、効果の大きいものから少しずつ進めます。テストコードの下書きをAIに作らせると初期の工数を抑えられますが、そのまま使わず必ず人がレビューします。結果が実行のたびに変わる不安定なテストは、放置すると誰も結果を信用しなくなるため、見つけしだい修正するか、一時的にパイプラインから外します。担当者が画面を触りながら違和感を探すような探索的テストは、手作業のまま残します。

ステップ5：段階的リリースで切り戻しやすくする 
フィーチャーフラグを使えば、コードを本番に配置（デプロイ）した後も、機能を利用者に公開（リリース）するかどうかを切り替えられます。カナリアリリースでは、新しいバージョンをまず一部の利用者だけに届け、問題がないことを確かめてから範囲を広げます。いずれも、本番で問題が見つかったときに影響を一部にとどめる手段です。ただし、切り戻せるからといって事前の確認を緩めて良いわけではありません。データベースの構造変更や、すでに書き込まれたデータはフラグを切り替えても元に戻らず、利用者にいったん出た影響も取り消せないからです。段階的リリースは、事前の確認をすり抜けた問題に早く気づくための備えと位置づけます。承認を減らせるのは、ステップ2とステップ3で、人が見なくても同じ水準の確認ができると言える変更に限られます。
なお、フィーチャーフラグは使い終わったら削除します。不要なフラグが残り続けるとコードの分岐が増え、それ自体が障害の原因になります。また、フラグの切り替えも本番環境の変更にあたるため、誰がいつ切り替えたかを記録しておきます。

ステップ6：DORAの指標で効果を測り、改善を続ける 
DORAの指標を、月に一度など決まった間隔で計測します。DORAは現在、変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間、変更失敗率、デプロイの手戻り率の5つを挙げ、前の3つを「スループット（速さ）」、後の2つを「不安定性」の指標に分類しています（以前は「4つのキー」と呼ばれる4指標が広く使われていました。指標の変遷はDORA「A history of DORA’s software delivery metrics」で説明されています。本記事の目的から言えば、まず追いかけるべきは変更のリードタイムです。あわせて変更失敗率とデプロイの手戻り率を見て、速くした代わりに本番での失敗や緊急の修正が増えていないかを確かめます。リードタイムが縮み、変更失敗率が以前と変わっていなければ、見直しが妥当だったことを関係部門に数字で説明できます。なお、指標はアプリケーションやサービスごとに測ります。DORAも、性質の大きく異なるアプリケーション同士を比べると誤解を招くと注意しており、チーム間の競争に使うことは避けます。
パイプラインの設計やGitの運用ルールづくりを社内だけで進めるのが難しい場合は、DevOps・Git導入支援のような外部のサービスを使う手もあります。テスト自動化を特定の担当者任せにせず、チームの誰もが書けるようにしたい場合は、研修を利用する方法もあります。

事例：国内の小売業のECサイト（Web）開発における例

以下は特定企業の実績でなく、国内の企業で一般的に見られる課題をもとに想定したものです。

【状況】

• CI/CDを導入し、ビルド・単体テスト・デプロイは自動化済み
• 決済は外部の決済代行サービスに委託しており、自社のシステムではカード情報を保持していない
• しかし本番リリースは月1回の定例枠のみで、部門をまたぐ複数段階の承認と、画面操作を伴う手作業の回帰テストが毎回必要だった
• セールやキャンペーンに合わせた改修がリリース枠に間に合わず、施策の開始が後ろ倒しになることがあった

【実施した見直し】

• 変更を「標準変更」と「通常変更」に分類し、標準変更は別の担当者によるコードレビューと自動テストの合格を条件に、承認会議を経ずに本番へ反映できるようにした
• 決済画面にかかわる変更は、標準変更の対象外とした
• どの承認をどのレビューや自動チェックで代替するかを一覧にし、事前に内部監査部門と合意した
• パイプライン設定とブランチ保護ルールの変更は通常変更として扱い、変更できる担当者を限定した
• 手作業の回帰テストのうち、操作手順が固定的な項目から自動化に着手した
• フィーチャーフラグを導入し、デプロイ（本番への配置）とリリース（利用者への公開）を切り分けた
• キャンペーン用の画面や機能をフィーチャーフラグで事前に配置し、開始日時に公開を切り替える運用にした

【得られた変化（想定）】

• 標準変更は、承認会議の開催を待たずに本番へ反映できるようになった
• 手作業のテストが減るにつれて変更のリードタイムが短くなり、変更失敗率は見直し前と同程度に保たれた
• テストの結果とレビューの承認履歴を外部の保管先に書き出すようにし、監査の準備にかかる工数が減った
• キャンペーンの開始日に合わせた機能公開を、リリース枠に縛られずに行えるようになった

まとめ

CI/CDを入れたのにリリースが速くならないときは、ツールや技術力よりも先に、承認の流れや手作業のテストといった運用の側を確認する価値があります。パイプラインをいくら速くしても、その前後で待たされていては、本番に出るまでの日数は縮まりません。承認を減らす際は、人による確認をなくすのではなく確認の場をコードレビューと自動チェックに移すこと、そしてパイプラインと証跡の管理を同時に整えることが前提になります。

よくある質問

Q1. 内部統制や監査要件との両立は可能ですか？ 
A. 両立を図ることは可能です。ただし、どの承認をどのレビューや自動チェックで代替するかは、事前に監査部門や監査人と合意しておく必要があります。テストの結果はパイプラインの実行ログに、コードレビューの承認はプルリクエストの履歴に自動で記録されるため、両方をあわせて証跡として使えます（記録される場所はツールによって異なります）。保存期間と改ざん防止については、ステップ3を参照してください。

Q2. テスト自動化の費用対効果はどう考えれば良いですか？ 
A. 「実施回数×1回あたりの手作業の工数」で削減できる工数を見積もり、そこから自動テストの作成工数と、仕様変更に合わせた保守の工数を差し引いて考えます。差し引いた効果が大きいものから着手します。

Q3. 承認者が見直しに反対する場合はどうすれば良いですか？ 
A. まず、その承認で何を防ぎたいのかを承認者に聞きます。そのうえで、承認者が見ていた観点を自動チェックでも確認できることを、実際のテスト結果やログで示します。切り戻しの仕組みは、あくまで万一の備えとして説明します。

Q4. AI搭載ツールは承認やテストの見直しに役立ちますか？ 
A. 変更内容の要約や、テストコードの下書きづくりには使えます。ただ、出力に誤りが含まれることもあるため、判断そのものを任せることはできません。

Q5. 継続的デプロイに移行すれば、承認待ちはなくなりますか？ 
A. 継続的デプロイでは、テストに合格した変更が自動で本番に反映されるため、本番に出すかどうかを判断するための承認はなくなります（マージ前のコードレビューは残るのが一般的です）。その分、自動テストと監視の水準を高める必要があり、規制や監査の要件によっては採用が難しい場合もあります。まずは継続的デリバリーのまま、標準変更の承認を減らすところから始めるのが現実的です。

関連用語

• CI/CD：
  コードの統合・テスト・配置を自動化し、継続的にリリース可能な状態を保つ手法
• 継続的デプロイ：
  テストに合格した変更を、人の判断を挟まずに自動で本番へ反映する手法
• リードタイム： 
  変更をコミットしてから本番環境にデプロイされるまでの所要時間（本記事での定義。DORAの「変更のリードタイム」と同じ）
• DORA指標： 
  変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間、変更失敗率、デプロイの手戻り率の5つで、ソフトウェアを本番に届ける速さと安定性を測る指標。以前は「4つのキー」と呼ばれる4指標が広く使われていた
• 変更管理委員会（CAB）： 
  本番環境への変更を審査・承認する会議体（英語ではChange Advisory Board）
• バリューストリームマッピング： 
  工程ごとの作業時間と待ち時間を図示し、ボトルネックを見つける手法
• 標準変更：
  手順が定型化され、リスクが低いと事前に認められた変更。本記事では、一定の条件を満たすコード変更にもこの考え方を応用している
• 回帰テスト：
  変更によって既存機能が壊れていないかを確認するテスト
• フィーチャーフラグ：
  コードを配置したまま、機能の公開・非公開を切り替える仕組み
• カナリアリリース：
  一部のユーザーにのみ先行して公開し、問題がなければ段階的に拡大する方法
• 探索的テスト：
  手順を固定せず、担当者の経験や観察に基づいて不具合を探す手動テスト