金曜日にデプロイできますか？ CI/CDで変わる 開発組織の意思決定
>100 Views
February 18, 26
スライド概要
https://circleci.connpass.com/event/383177/
開発の質と速度を底上げしよう！ 世界中のエンジニアが愛用する CI/CD ツール「CircleCI」の公式アカウントから日本語で最新情報をお届けします。 最新イベント・ミートアップ情報はこちら: http://circleci.connpass.com
関連スライド
各ページのテキスト
金曜日にデプロイできますか？ CI/CDで変わる 開発組織の意思決定 岡本 秀高 ( @hidetaka_dev ) Senior Field Engineer 1
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始めるDevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 2
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● https://hidetaka.dev ● http://wp-kyoto.net 3
金曜日のデプロイは 「やってはいけない」こと？ ● 週末に障害が起きるかもしれない ● 週末は対応できる人が少ない ● 今の”健全な状態 ”を維持したい ● デプロイは慎重にやるべき ● みんな「そうしろ」と言っている https://x.com/GithubProjects/status/1984174536892543217 4
「リリースは怖い・勇気のいる作業」と感じる人は多い ● デプロイして障害が起きたらどうしよう ● テストやチェックはこれで万全なのか？ ● 何か見落としている点はないか？ ● そういえばリリース作業誰がやる？ 5
「リリースは怖い・勇気のいる作業」と感じる人は多い ● デプロイして障害が起きたらどうしよう ● テストやチェックはこれで万全なのか？ ● 何か見落としている点はないか？ ● そういえばリリース作業誰がやる？ 58% リリースに不安を感じる 開発者の割合 88% リリースに不安を感じる 開発チームの割合 74% 不安からコードの更新を 回避することがあるチーム https://info.sourcegraph.com/hubfs/CTA%20assets/sourcegraph-big-code-survey-report.pdf 6
なぜリリースは「怖い作業」なのか？ ● 何が起きるかわからない → 変更の量に比例して、リリース内容の把握や理解が困難に ● 問題が起きた時、どうすればいいかわからない → ロールバックの手順が不明確 ● 慣れてないから、不安 → 頻度が少ない & リリース作業が属人化しがち 7
リリースの怖さをどう軽減するか？ 「リリースによる障害が怖い。 だからリリースの頻度や回数は減らしたほうが安心」 ● 慎重にテストやリリース作業をやれば、安心してできるはずだ ● まとめてテストやリリースをすれば、効率も良いはずだ ● リリースの頻度を減らせば、障害件数や発生率も減るはずだ 8
リリースの怖さをどう軽減するか？ 「リリースによる障害が怖い。 だからリリースの頻度や回数は減らしたほうが安心」 ● 慎重にテストやリリース作業をやれば、安心してできるはずだ ● まとめてテストやリリースをすれば、効率も良いはずだ ● リリースの頻度を減らせば、障害件数や発生率も減るはずだ 実際には、障害発生率やリリース負荷が増加する 9
低頻度の大きなリリースが一番危険 “ 1つ目は、このアプローチでは...最後のリリースから多くの変更 が溜まると、 意図しない重大な不具合が発生 し、 大幅なリリース遅延を発生 させることに繋がる点です。ˮ ● １デプロイに含まれる変更が多くなる ● 変更量が増えると、バグ混入リスクも増加する ● 「どのコミットでバグが混ざったか」の特定や、 修正のための調査が大変になる https://www.oreilly.co.jp//books/9784814400690/ 10
リリース頻度を下げると、悪循環が発生しやすい 11
苦痛を見つける最良の方法は、 めったに行われない作業を探し出すことです。 例えば、 3か月に1回しかデプロイしないということは、 そこに苦痛があることを示すサインです。 — 『入門 継続的デリバリー』 294ページ どうやってリリース頻度を増やせばいい？ https://www.oreilly.co.jp//books/9784814400690/ 12
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始めるDevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 13
開発の負荷を増やさずに、デプロイ頻度を増やす ● 「デプロイ回数を増やそう」だけでは、反発を産む → 「これ以上、開発チームに負担をかけられない」 ● CD の本質は、開発チームの負担を減らすこと → 変えるものと変えないものを整理する ○ 変えないもの : 開発する量 ○ 小さくするもの : デプロイの単位（ = バッチサイズ） ○ 結果的に増えるもの : デプロイの回数と頻度 14
Thank you. 15
バッチサイズを減らす開発方法 ● コードだけを先行してデプロイする ○ 型定義や DTO / クラス / 関数など ○ TDDで開発し、「機能するコードであること」を保証する ● 本番の動きを変える変更は、最後に行う ○ UIの変更 / API への接続など ○ ユーザー向けのリリースデプロイを できるだけ少ないコード差分で実現する 16
もう一つのデプロイ方法 デプロイと 機能リリースの分離 ● 通称: Feature Flag ● if文やDBで機能提供の オンオフを制御 ● コードをデプロイしても、 機能自体はリリースしない ● 「できたものからリリース」 できる体制を作るための仕組み 17
継続的なデリバリー（ CD ）でリスクと苦痛を軽減する デプロイは、誰もが恐れるイベントから、 日常のありふれた出来事になりました。 — 『入門 継続的デリバリー』 265ページ ● CD は「デプロイの負担」を減らすための仕組み → 負担が減った結果として 、開発速度や量が自然と増加する ● リリースの量（バッチサイズ）は小さく、頻度はより多く → 小さなリリースで、障害調査や切り戻しの負担を軽減する ● いつでもリリースできる体制を目指すことで、 小さな改善や顧客の要望を迅速にデリバリーできるようにする 18
CircleCI: 世界最大規模 の CI / CDプラットフォーム Our mission: 世界中のだれもが、思い浮かんだアイデアを すぐにソフトウェアとして配信できるように支援す る ● 複数のリポジトリサービスに対応 : GitHubやBitbucket / GitLabなどの複数サービスをサポート ● Pipeline/ Config as Code: タスクの条件や定義を YAMLで管理。URLベースの共有にも対応 ● 大規模な CI / CD活用を支援する機能群 : CircleCIを ご利用中のお客様（一部） テスト分割や並列化 / パフォーマンス分析機能 SSHデバッグ / リトライやロールバック機能 / etc… 19
テストだけでなく デプロイやロールバックも ● マーカーを設定して デプロイ状況を記録 ● ダッシュボードから 任意のバージョンにロールバック 特にインシデントのような状況では。スクリプトがどのよ うに動作しているかを事前に理解したくないですよね。 < 中略> ロールバックしたいコミットハッシュを指定するだ けで済むのは、本当に助かりました。 https://circleci.com/blog/how-perk-recovers-faster-with-centralized-rollbacks/ 20
セキュリティ要件などに応じて運用方法を決定 クラウド サーバー インスタンスのセットアップ、 セキュリティ、メンテナンスはすべてCircleCIが実施 ディベロッパー/ ユーザー データベース 顧客が管理するネットワーク内に 顧客専用のCircleCIをセットアップ ディベロッパー/ ユーザー ビルドの フリート キャッシュ & アーティファクト VCS （GitHub.com または Bitbucket Cloud） + データベース ビルドの フリート VCS キャッシュ & アーティファ クト （GitHub.com または GitHub Enterprise Server） セルフホストランナー: 実行環境だけ顧客管理のネットワーク内に配置する 21
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始める DevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 22
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始めるDevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 23
CI/CDへの投資をどう評価するか？ ● ツールの便利さではなく、アウトカムで回答が必要 ○ いくらかかるのか？ ○ ROI はどのように測るのか？ ● 予算を承認するためには「理由」が必要 ○ できるだけすでにある契約の中でやりくりしたい ○ 主観的なメリットよりも、コストや数字での判断が優先される 24
DORA Four Keysでチームの現状を可視化する * DORA DevOps Research Association ( https://dora.dev/ ) 開発現場での課題 事業側の関心事 DORA Four keys もしもの時に備える インシデント 対応力 MTTR（復旧時間） 本番環境での障害から 回復するのにかかる時間 デプロイの怖さを減ら す 品質・信頼性 変更障害率 デプロイが原因で 本番環境で障害が発生する割合 開発速度をより早く 市場投入速度 デプロイ頻度 変更リードタイム 本番環境へのリリースの頻度 commit からリリースまでの所要時間 課題を解決することで得られる outcomeを特定する https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 25
CI/CDによる改善の価値を計算する CircleCI CEOによるブログ :https://circleci.com/ja/blog/business-value-of-software-delivery/ 改善項目 ROI 計算式 計算例 ( 10人チーム / 年収550万円想定) ビルドや デプロイ時間の 短縮 (現在の時間 - 目標時間) × 実行数/日 × 開発者コスト/分 × 稼働日数 ( 10分 - 5分 ) x 10回/日 x 50円/分 x 20日 = 500,000 円 / 月 変更障害率 (現在のMTTR - 目標MTTR) × 失敗率 × 実行数/日 × 開発者コスト/分 × 稼働日数 ( 30分 - 15分 ) x 5% x 10回/日 x 50円/分 x 20日 = 150,000 円 / 月 (現在の失敗率 - 目標失敗率) × スループット/日 × ビルドコスト × 稼働日数 (20% - 5%) × 10回/日 × ¥2,500 × 20日 = ¥75,000 / 月 ビルド成功率 ビルドの高速化 ビルド成功率改善 障害発生率削減 月間725,000円 年間約870万円 のコスト削減 26
計測し、ベンチマークと比較する https://circleci.com/software-delivery-data-explorer/ 27
2つの指標で多視点から可視化する DORA Four Keys CI / CD 操作指標 視点 インシデント 対応力 MTTR（復旧時間） 指標の性質 遅行指標 プロセス指標 用途 定期的な診断 調査すべき仮説を立てるための指標 プロセスのボトルネックを特定する DevOps / CI・CD施策の効果測定 DORA Four Keys → CI / CD指標で調査 CI / CD指標を改善すると、 DORA Four Keysが動き出す https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 28
経営には数字を 現場にはストーリーを ● CI / CDで改善のサイクルを回す 効率化によるコスト最適化 → 障害による損失リスク → 手戻りや調査による非効率 ● 現場の不安や摩擦を解消する → リリースが怖くなくなる → 大小の改善を高頻度に 29
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始めるDevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 30
安心したデプロイのためにできること AIによる開発の発達と 品質やセキュリティへの懸念 ● コードの作成や提案の高速化 ● 単純作業やテスト生成の効率化 vs ● レビューコストの増加 ● 脆弱性やハルシネーションリスク https://circleci.com/ja/blog/risks-rewards-generative-ai/ 31
テストの修正や不具合が 起きた時の対応も全部、 生成AIがやってくれたらいいのに 32
Intelligent summaries によるエラーログ解析 https://qiita.com/CircleCIJapan/items/5683e63ea28fbaf3f7fe 33
Open Preview 自律型 AI エージェント Chunk ● CI / CDパイプラインを監視 ● 不安定な ( Flaky )テストを検知 テストを修正する PR を作成 ● CircleCIを使った PR の自動検証 ● アドホックな コーディングタスクにも対応 34
ChunkでCIエラーの調査と修正を一気通貫 https://qiita.com/CircleCIJapan/items/5683e63ea28fbaf3f7fe 35
Closed Preview 効率的なテスト実行計画を自動的に作成 Smarter Testing テスト実行対象を自動選択 ● ● 変更内容を分析して 必要なテストのみを実行 選択した理由なども分析可能 並列テストの実行時間最適化 ● ● 並列実行するテストの 実行時間を平均化 後続のジョブ開始時間を短縮 36
CI/ CD のROIを ROI Calculator で 計算してみよう ● 開発チームの現状を入力する ○ 人数 / ビルド回数 https://circleci.com/autonomous-validation-roi/ ○ ● 実行時間 / MTTR 10人チーム、 1ビルド/日 WF10 分、復旧 60分の場合 ○ 月94時間の短縮 ○ 人件費ベース 約400万円 / 年 37
>Agenda 今日のゴール: リリースが「怖いイベント」ではない組織になる 1. 2. 3. 4. 5. 6. 金曜デプロイにおける「怖さ」の正体 開発負荷を増やさずにデプロイ頻度を増やす方法 リリースとロールバックから始めるDevOps Demo CI/CDを「投資」として評価する 生成AI によるCI / CD 効率化 まとめ 38
リリースを 『怖いイベント』にしない ● CI / CDで改善のサイクルを回す 金曜デプロイの恐怖は、 安定したリリースができない兆候 ● 開発量は増やさない。 バッチサイズの縮小と リリース頻度の増加で不安を解消 ● ツールのコストではなく そのWFで発生するコストを見る 39
まずは現状のチェックから Step 1： Four Keysで現状を測る コミットから本番リリースまでの時 間、障害からの復旧時間を計測す Step 2： ボトルネックを特定する • MTTRが⻑い：ロールバック⼿順の不備 • 変更障害率が⾼い：テスト不⾜‧環境差分 る。まず可視化するだけで、どこに 問題があるかが⾒えてくる。 Step 3： 改善効果を数字で⾒積 「ビルド時間の短縮」「障害対応時 間の削減」を⽉額‧年額で試算し、 • リードタイムが⻑い：⼿動作業‧レビュー 投資判断の材料にする。 遅延 40
学習リソースとコミュニティ さらに学ぶための情報源 ● ● 公式ドキュメント https://www.oreilly.co.jp//books/9784814400690/ https://circleci.com/docs 実装順序の指針 レガシー環境への適用 シグナル設計の原則 etc.. ROI Calculator: 自社の状況でコスト削減効果を試算 https://circleci.com/autonomous-validation-roi/ ● 2025 State of Software Delivery Report 最新の業界データとインサイト https://circleci.com/resources/2025-state-of-softw are-delivery/ ● 入門 継続的デリバリー CircleCI の「How」だけでなく CI/CD の「Why」を学べる Twitter: CircleCIJapan 41