Copyright SHIFT INC, All Rights Reserved. 2025 / DevOpsDays Tokyo 2025 日本のマジョリティへの CI/CD導入戦略 15 04 14:00- 14:40 株式会社SHIFT アジャイル推進部 部長 秋葉 啓充 あきば ひろみつ 株式会社SHIFT アジャイル推進部 DevOps推進1G グループ長 松吉 研二 まつよし けんじ 

マスター テキスト 「品質保証」の強みを軸に を 展開する企業です IT総合サービス 

3 Copyright SHIFT INC, All Rights Reserved. DXの総合サービスを提供し、累計顧客数は約3,200社へ(2024年5月末時点) 事業の変遷 はじまりは「ソフトウェアテスト」 2009年 市場をブルーオーシャンとして捉え成長 出所：SHIFT. 統合報告書 2022. 2023年4月20日, 20p. コンサルティング 開発 セキュリティ 性能 デジマ ERP Agile AI 人事コンサル PMO ソフトウェア開発産業の市場規模は 約16.5兆円 ※ソフトウェアテスト業務は全開発工程の33.8％と想定 （ソフトウェア開発データ白書2018‒2019） ※経済産業省 2021年情報通信業基本調査（2020年度実績） （ソフトウェア開発に関連する業界の売上高合計より算定） ※検証工程を専業とする国内企業の売上高規模による推定 

4 Copyright SHIFT INC, All Rights Reserved. 自己紹介 経歴 大阪府出身。2007年に 外資系SIerの子会社でエンジニアとしてキャリ アスタート。 ベンチャーを経て2020年にSHIFT入社。 コンサル、スクラムマスター、インフラアーキテクト、自動化PM、 エンジニアリングマネージャーなどを担当し、2025年3月より現職。 登壇歴 2025年：DevOpsDays Tokyo、SHIFT Agile FESほか 2024年：openSUSE.Asia Summit、SHIFT EVOLVEほか 2023年：SHIFT 89祭ほか 2022年：JaSST‘22 Kansaiほか ＃心理的安全性 ＃GitHub Trends＃クラウド海峡横断部 ＃RPA ＃ローコード #AI ＃自動化 #CI/CD ＃哲学 ＃ポストモダン ＃2男児の父 ＃人間は9タイプ #フットサル #IoT 秋葉 啓充（あきば ひろみつ） アジャイル推進部 部長 入社：2020年4月 

5 Copyright SHIFT INC, All Rights Reserved. 自己紹介 経歴 大学卒業後、11年間システム開発会社で携帯サイトやECサイトの開 発を実施案件ではPL、会社ではチームリーダー（課長職）に従事。 その後、3年間GISクラウドシステムの企画〜運用・保守まで実施。 SHIFTに参画してから • テスト自動化でリアルタイム現新比較の仕組みをスクラッチ開発 • 標準化された自動化技術の適用、運用支援など様々な業界のお客様 への営業技術支援(プリセールス) • フレームワーク／サービス開発 • 組織マネジメント ＃テスト自動化 ＃CI/CD ＃DevOps ＃マネージャー賞受賞 ＃お茶目なジェントルマンで賞 ＃2児の父 松吉 研二（まつよし けんじ） アジャイル推進部 DevOps推進1G グループ長 入社：2017年4月 

6 Copyright SHIFT INC, All Rights Reserved. 明るく 楽しく 前向きに あ た ま 「あたま」はほかにも使える 集める 確かめる 前に進める あ た ま 「あたま」を活用する 私たちが大事にしていること： 

7 Copyright SHIFT INC, All Rights Reserved. これまで取り組んでいたことがDevOpsと呼ばれるものだった 出典：https://qiita.com/official-columns/interview/202202-shift/ 技術に覚えがある人もおり、早くからテストを自動化していた 「SHIFTといえばテスト」でテストの仕事が多くあった CIムーブメントが起き、やがてそれがDevOpsと呼ばれるようになった 

8 Copyright SHIFT INC, All Rights Reserved. テスト自動化→DevOpsと発展してきたが われわれSHIFTへのお仕事の依頼はあいかわらずテスト自動化、CI/CD構築といった依頼が多い 技術の発展は目まぐるしいが、今世の中はDevOpsに対してどのような状態なのか？ 

9 Copyright SHIFT INC, All Rights Reserved. 日本においてDevOpsやCI/CDは市民権を得てきたように思えるが、まだ幻滅期にあるとのこと。 いまのところアーリーマジョリティの普及期と考えられるので、まだまだこれから導入や定着が待っている。 「やってみたが定着化していない勢」がわれわれに相談してきているということか。 世の中の “いま” を見てみる 出典：Gartner: 日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年 

10 Copyright SHIFT INC, All Rights Reserved. 部分的なテスト自動化やCI導入などをしてきたが、 顧客の文化を変えるまでにはいたっていなかった。 DevOps文化を当たり前にしたいが、どれだけ当事者意識を もってしても、第三者である私たちでは限界があるのか？ 私たちはDevOps文化を当たり前にしていきたい その常識、変えてみせる。 いや、限界などないはずだ！ 

No content

12 Copyright SHIFT INC, All Rights Reserved. 文化を変えるためのアプローチ 出典：https://speakerdeck.com/twada/building-automated-test-culture-2024-winter-edition 技術「が」文化「に」影響を与える 何もしてないから壊れる 自然と壊れが発生する現代において、継続的な活動を定着させていく要素は文化、プロセス、ツール（技術）。 文化を作るには時間がかかるので、プロセスとツールから変化を加えれば、 文化として定着させていけるのでは？が出発点。 

13 Copyright SHIFT INC, All Rights Reserved. よく聞くブランチ戦略だけでも複数種類あり、それぞれによさそうな事例や考え方がある。 CI、バージョニング、CD、IaC…と様々な要素があり、それぞれに考え方やツール、サービスがある。 顧客文化を変えていくのにフィットするプロセス・ツールは何がある？ 聞きたいことはみんな一緒 うちはどれをどう使えばいい？どれがフィットする？ 

Copyright SHIFT INC, All Rights Reserved. 14 正解があるならこっちが知りたい…と言いたい 

15 Copyright SHIFT INC, All Rights Reserved. どんな状況に対しても100点が取れるものは存在しないが、 マジョリティがはじめるときのプロセスとツールの標準をつくれば 及第点が取れるレベルのものはつくれるかもしれない そうもいかないので… まずはブランチ戦略をつく作り、 それを支える仕組みやプロセスを考えてみることに 1. それぞれの状況、ステージによって考える 2. 似たところがあったりなかったり 3. 複数の支援を続けるなかで気づく 

16 Copyright SHIFT INC, All Rights Reserved. CI/CDを行ううえで、プロセスやツールの使い方を周知するためのドキュメントをつくっちゃったりしませんか？ 生成AIでどんなドキュメントをつくるのか聞いてみると…たくさん出てきました。 例えば、ルールを守りやすくするため、開発ガイドを用意 z 1.CI/CD利用アカウントの作成手順 1. CI/CDツール（例：Jenkins, GitLab CI, GitHub Actions）のアカウント 作成手順 2. アクセス権限の設定方法 3. セキュリティベストプラクティス 2.ブランチ戦略 1. ブランチの命名規則 2. ブランチの種類（例：main, develop, feature, release, hotfix） 3. ブランチのマージポリシー 4. ブランチの保護ルール 3.パイプラインの構築方法 1. パイプラインの基本構成 2. 各ステージ（ビルド、テスト、デプロイ）の詳細 3. パイプラインのトリガー条件 4. パイプラインのエラーハンドリング 4.コードレビューとマージの手順 1. プルリクエスト（PR）の作成手順 2. コードレビューのガイドライン 3. マージの承認プロセス 5.テスト戦略 1. ユニットテスト、統合テスト、エンドツーエンドテストの実施方法 2. テストカバレッジの基準 3. テスト結果のレポート方法 z 6.デプロイメント戦略 1. デプロイメントの種類（例：ローリングデプロイ、ブルーグリーン デプロイ、カナリアリリース） 2. デプロイメントの手順 3. ロールバック手順 7.モニタリングとアラート設定 1. モニタリングツールの設定方法（例：Prometheus, Grafana） 2. アラートの設定基準と通知方法 3. ログ管理の方法 8.セキュリティガイドライン 1. セキュリティスキャンの実施方法（例：SAST, DAST） 2. セキュリティベストプラクティス 3. 秘密情報の管理方法（例：シークレット管理） 9.インフラストラクチャの設定 1. インフラストラクチャのコード化（IaC）ツールの使用方法（例： Terraform, Ansible） 2. 環境のセットアップ手順（例：開発、ステージング、本番） 10.ドキュメント管理とナレッジシェア 1. ドキュメントの保存場所とアクセス方法 2. ナレッジシェアの方法（例：Wiki, Confluence） 3. ドキュメントの更新手順 

あるあるなので、 そこを踏まえて導入戦略のコンセプトを考えた こんなにドキュメントをつくっても、 読まれずにドキュメントが腐ってしまったこと、 ありませんか？ 

理解の促進と導入後も改善がしやすいようにガイドは用意するが、ガイドには甘えない 成熟度が高くない段階でも自然とブランチ戦略や安全なデプロイができるようにする 導入戦略のコンセプト ドキュメントを読まなくても、1時間の説明会を聞けば使える 

Copyright SHIFT INC, All Rights Reserved. 19 次に、ブランチ戦略をどう考えたか？ 世の中の有名なブランチ戦略は、日本のマジョリティには（まだ）向かない Git flow GitHub flow GitLab flow ほかにもいろいろ 

20 Copyright SHIFT INC, All Rights Reserved. 日本のマジョリティによくあるGitビギナーが使うにはブランチの種類とルールが多い。 mainとdevelopの両方を維持する意義がわからなくなる。 Git flow 

21 Copyright SHIFT INC, All Rights Reserved. 日本のマジョリティによくある中長期・大規模開発では、mainへPRがマージされたものが すぐに本番リリースできるものではないことが多い。 これを使いこなすためにはFeature Flagや高度な自動テストが整備され、featureを小さく分割し、 それぞれを本番リリース可能な形で開発できる程度に成熟したチームが必要。 GitHub flow 本番リリース？ 

22 Copyright SHIFT INC, All Rights Reserved. 日本のマジョリティによくある並行開発では、同じ環境ブランチを共有すると機能が混ざったり、 本番障害のHotfixをしようとしたら次の開発機能が混ざり込んだりしてしまう。 その分、環境ブランチを並行開発分用意する必要があるが、それぞれの同期（マージ）が超絶複雑 になり、環境差分の原因となる。 GitLab flow feature-2をリリースする前に hotfixが入った場合、 そのままhotfixをリリースすると feature-2が一緒に入り込む 

日本のマジョリティによくあるケースに 適用しやすいブランチ戦略とは？ 

24 Copyright SHIFT INC, All Rights Reserved. 日本のマジョリティによくある中長期・大規模開発向けにプロジェクト単位でブランチを切り、 その下で開発・テスト・不具合修正を行うシンプルなフロー ブランチ戦略 - 正常系 main project/プロジェクト名称 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR issue/不具合名称 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

25 Copyright SHIFT INC, All Rights Reserved. mainブランチの最新コミットが本番と同じソースコードであるため、開発プロジェクト中のHotfix は、mainブランチからhotfixブランチを切り、その下で開発・テストを行うシンプルなフロー ブランチ戦略 - Hotfix main project/プロジェクト名称 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR PR PR issue/不具合名称 issue/不具合名称 merge issue/不具合名称 hotfix/緊急リリース名称 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

26 Copyright SHIFT INC, All Rights Reserved. mainブランチの最新コミットが本番と同じソースコードであるため、開発プロジェクト中のHotfix は、mainブランチからhotfixブランチを切り、その下で開発・テストを行うシンプルなフロー ブランチ戦略 - Hotfix main project/プロジェクト名称 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR PR PR issue/不具合名称 issue/不具合名称 merge issue/不具合名称 hotfix/緊急リリース名称 直接projectにマージ(PR)しようとすると、コンフリクト している場合は、main,hotfix,projectどれもプロテクト ブランチのため、コンフリクトを解消する方法がない。 （厳密にはないわけではないが）コンフリクト発生有無 により場合分けをすると、手順やルールが煩雑になり、 慣れていないチームでは混乱を招くため、issueブラン チ経由のような方法に統一することを推奨。 必要に応じてコンフリクトの解消や 開発中のプロジェクトに合わせた修正を行う。 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

日本のマジョリティ層が 陥りやすい罠 

PRのターゲットブランチを間違えて作成し、そのままマージしてしまう Gitを理解している人がおらず、わからないなかで泣きながら復旧に取り組み、 多くの時間を溶かすことに… 

開発中のアーティファクトにバージョンがない、 もしくは1.0.0-SNAPSHOTのようにバージョンがすべて同じ デプロイやテストの資材を取り違えによる本番障害が発生 QA・品証を通ったバージョンがわからない 

mainやreleaseブランチにマージしてから本番用ビルド・リリースしたり、 リポジトリ内のファイルのバージョン番号を上げてコミットしてから 本番用ビルド・リリース まれにビルドが壊れていたり、テストを通したビルドと微妙に変わっていたりして、 アーティファクト同一性を担保できずに本番障害 

罠に陥らないための工夫 誰でも使えるようにする仕組み 

32 Copyright SHIFT INC, All Rights Reserved. ガードレール（フールプルーフ）により壊れにくくする →PRパイプラインのブランチ条件やジョブで、ブランチ戦略のルールに則っているかチェックする ブランチ戦略の半分は優しさでできている main project/プロジェクト名称 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR PR PR merge issue/不具合名称 hotfix/緊急リリース名称 issue/不具合名称 issue/不具合名称 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

33 Copyright SHIFT INC, All Rights Reserved. ガードレール（フールプルーフ）により壊れにくくする →PRパイプラインのブランチ条件やジョブで、ブランチ戦略のルールに則っているかチェックする ブランチ戦略の半分は優しさでできている main project/プロジェクト名称 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR PR PR merge issue/不具合名称 hotfix/緊急リリース名称 issue/不具合名称 issue/不具合名称 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ ガードレール例 mainへのマージが可能なのはproject,hotfixのみとし、間違った ブランチからPRが作成されていないか検査してあげる。 ガードレール例 project,hotfixへのマージが可能なのはwork,issueのみとし、間違った ブランチからPRが作成されていないか検査してあげる。 

PRのターゲットブランチを間違えて作成し、 そのままマージしてしまう Gitを理解している人がおらず、 わからない中で泣きながら復旧に取り組み、 多くの時間を溶かすことに… 間違ったブランチにマージしようとしたら パイプラインがエラーになる仕組みにより、 間違ったマージを防ぐことができ、無駄な 時間を削減。壊れないという安心感 Before After 

35 Copyright SHIFT INC, All Rights Reserved. オートバージョニングとトレーサビリティ • ビルド番号相当をバージョン番号に含める（下図ではパッチバージョンをビルド番号として扱っている） • CIパイプラインにおいてgitコマンドを駆使して自動的にビルド番号をカウントアップしてタグ付けする • リポジトリ内のファイルにはバージョン番号はもたない、もしくは固定値とし、手作業でのバージョンアップやコミットをしない ブランチ戦略の半分は優しさでできている main project/1.1 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR v1.0.5 PR PR issue/不具合名称 issue/不具合名称 merge issue/不具合名称 hotfix/緊急リリース名称 v1.1.0 v1.1.1 v1.1.2 v1.1.3 v1.0.6 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

開発中のアーティファクトにバージョンがない、 もしくは1.0.0-SNAPSHOTのようにバージョンが すべて同じ デプロイやテストの資材を取り違えによる 本番障害が発生 QA・品証を通ったバージョンが分からない リリース対象がバージョンにより判別でき るようになり、リリースモジュールの取り 違えがなくなった。 また、トレーサビリティーを確保している ため、問題が発生したバージョンの特定が 容易になった。 Before After 

37 Copyright SHIFT INC, All Rights Reserved. アーティファクト同一性 • コミット : ビルドアーティファクト : バージョン : デプロイ環境 = 1 : 1 : 1 : N • 1つのコミットに対して、ビルドアーティファクトもバージョン番号も1つ、それを複数の環境にデプロイ可能にする • テスト・QAがすべて完了した同じアーティファクトを本番にもリリースする ブランチ戦略の半分は優しさでできている dev stg IT〜 単体テスト 本番稼働 dev stg prod IT〜 単体テスト dev 単体テスト dev stg IT〜 単体テスト main project/1.1 PR PR 前回PJ完了 PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR PR v1.0.5 PR PR issue/不具合名称 issue/不具合名称 merge issue/不具合名称 hotfix/緊急リリース名称 本番稼働 dev stg prod IT〜 単体テスト v1.1.0 v1.1.1 v1.1.2 v1.1.3 v1.0.6 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ 

mainやreleaseブランチにマージしてから 本番用ビルド・リリースしたり、 リポジトリ内のファイルのバージョンを上げて コミットしてから本番用ビルド・リリース まれにビルドが壊れていたり、テストを通 したビルドと微妙に変わっていたりして、 アーティファクト同一性を担保できずに 本番障害 テスト実施したアーティファクトを 確実にリリースでき、 意図しないビルド差分をなくす ことができた。 Before After 

39 Copyright SHIFT INC, All Rights Reserved. Gitだけであれば、mainブランチへのマージだけはFast Forwardマージすることで、マージコミットをつくらず に本番リリースしたコミットを指すようにできる。 少し脱線 通常コミット マージコミット PRパイプラインを実行(静的解析/UT) CIパイプラインを実行(静的解析/UT/オートバージョニング/パッケージング/デリバリー) マージコミットに対してCIパイプラインを実行 プロテクトブランチ main project/プロジェクト名称 PR 前回PJ完了 PR PR merge /rebase work/作業名称 work/作業名称 開発&テスト PR issue/不具合名称 PJ完了 mainブランチをFFマージ 

40 Copyright SHIFT INC, All Rights Reserved. 多くのGitのホスティングサービスだと、「mainブランチへのマージだけはFast Forwardマージする」ができない。 →泣く泣くマージコミットにしている。 ちょっと古いけど、2022年当時の調査した社内Teamsスレッド 少し脱線 

41 Copyright SHIFT INC, All Rights Reserved. パイプラインだけではなく、クラウドインフラも型として作成した • バックエンド、フロントエンドそれぞれに対応し、ビルドツールやプログラミング言語のパターンを複数作成 • プロジェクト管理ツールや静的解析の組み込みをすることもある その他の工夫ポイント CI/CDサービス ベンダー Azure GitHub プロジェクト管理 Azure Boards VCS Azure Repos GitHub パイプライン Azure Pipelines GitHub Actions パッケージレジストリ Azure Artifacts GitHub Packages アプリケーション 言語 Java Python フレームワーク Spring Boot Django/Flask パッケージマネージャー Maven Pipenv/Poetry ビルドツール ユニットテスト JUnit5 django.test/pytest SAST/SCA SonarQube/Trivy コンテナレジストリ Azure Container Registry GitHub Packages Black/isort/Flake8/Ruff 開発プロセス 開発プロセス 小規模(内製)ウォーターフォール アジャイル デプロイ方式 デプロイ方式 TypeScript React/Vue.js/Nuxt npm Jest/Vitest ESLint/Prettier/Biome 物理/仮想マシン + In-Placeデプロイ … Azure Static Web Apps Vite SAST/SCA Azure App Service GitHub Advanced Security GitHub Projects Checkstyle/SpotBugs 

42 Copyright SHIFT INC, All Rights Reserved. お客様の声 ブランチ戦略が分かりやすくて、メンバーからもすごく好評です。 優しいブランチ戦略のおかげで、すぐにCI/CDの恩恵を受けることができました。 おかげで、チーム全体が継続的に改善する文化に変わりました。 結果としてパフォーマンスもぐんと上がったんです。 前は“壊したらどうしよう…”ってビクビクしてたんですけど、今は安心して作業 できるようになりました。おかげで、いろんなことにチャレンジしやすくなりま したね。 ツールやプロセスのベースを提供してもらうことでCI/CDをお手軽に導入するこ とができました。 CI/CDに慣れていくことで、すぐに直そうという意識が芽生えて、綺麗に保ちた い気持ちが強くなりました。 CI/CDを簡単に導入できたおかげで、ブランチの健康状態がリアルタイムで把握 できるようになり、現場と管理者との信頼関係が改善され、スムーズなプロジェ クト運営が可能となりました。 

43 Copyright SHIFT INC, All Rights Reserved. 着実にお客様から感謝の声はいただけている。 しかし、 まだまだDevOpsを当たり前にしている企業は多くはない。 わたしたちはDevOps文化を当たり前にしていきたい もっとDevOpsを 普及していくために 最後に提言を言わせて いただきます 

はじめの一歩を踏み出したい組織はまだまだある。 た ま 大事なのは「あたま」を活用することです あ あせらず たすけあい まずはかたちからはじめてもいいじゃない 

ブースにもぜひ お立ち寄りください！ 資料の公開やイベント告知は X で配信中！ カジュアル面談も受け付け中！ https://x.com/shiftevolve_jp 今日の話に興味をもってくださった方へ 

46 Copyright SHIFT INC, All Rights Reserved. Agile Japanサテライト : SHIFT Agile FES 開催!! 生成AI時代における人間の情熱とプロダクト Tably株式会社 代表取締役 及川 卓也 トップエンジニアが語るDX最前線 イオン株式会社 CTO 兼 イオンスマートテクノロジー株式会社 CTO 山﨑 賢 株式会社クレディセゾン 取締役 兼 専務執行役員 CTO 兼 CDO 小野 和俊 Kent Beckの思想と学びの道筋 株式会社SHIFT ソリューション事業部 アジャイル推進部 部長 秋葉 啓充 株式会社アトラクタ Founder兼CTO アジャイルコーチ 吉羽 龍太郎 2025.5.17 SAT 09:50-18:30 ONLINE+ONSITE 

47 Copyright SHIFT INC, All Rights Reserved. アンケートへのご協力をお願いします。 本セッションの感想をお聞かせください。 回答完了画面のご提示で、SHIFTブースにてノベルティをプレゼント！ 

Copyright SHIFT INC, All Rights Reserved. ご清聴ありがとうございました