"分からない"から"楽しい"へ - CI/CD導入で変わった開発現場の景色

## 現場主導のCI/CD導入体験記

## はじめに
CI/CD環境の構築は、確かに導入時の負担は存在します。
しかし、開発効率の向上や品質の安定化など、得られる効果は非常に大きいと実感しています。
開発現場でどのような課題があるのか、CI/CDでどう解決できるのかをまとめてみました。

:::note info
CI/CDは単なる自動化ツールではありません。
チームの生産性と品質を大きく向上させる文化変革のきっかけとなります。
:::

まず最も基本的な用語から説明します。

```mermaid
graph LR
    Dev[開発者] --> Git[GitLab<br>コード管理]
    Git --> CI[CI<br>自動テスト]
    CI --> CD[CD<br>自動デプロイ]
    CD --> Prod[本番環境]
    
    style Dev fill:#f9f,stroke:#333,stroke-width:2px
    style Git fill:#bef,stroke:#333,stroke-width:2px
    style CI fill:#dfd,stroke:#333,stroke-width:2px
    style CD fill:#dfd,stroke:#333,stroke-width:2px
    style Prod fill:#fdb,stroke:#333,stroke-width:2px

```


### CI/CDとの出会い
私がCI/CDの必要性を強く感じたのは、チームでWeb系サービスの開発・運用を担当していた時のことです。定期的なリリース作業の中で、以下のような課題を抱えていました。

```mermaid
graph LR
    subgraph Before[Before: 手動での課題]
        direction TB
        B1[コード作成] --> B2[手動テスト]
        B2 --> B3[レビュー待ち]
        B3 --> B4[手動デプロイ]
    end
    
    subgraph After[After: 自動化による改善]
        direction TB
        A1[コード作成] --> A2[自動テスト]
        A2 --> A3[自動レビュー]
        A3 --> A4[自動デプロイ]
    end
    
    style Before fill:#ffebee,stroke:#333,stroke-width:2px
    style After fill:#e8f5e9,stroke:#333,stroke-width:2px
    
    %% Before nodes styling
    style B2 fill:#fff,stroke:#d32f2f,stroke-width:2px
    style B3 fill:#fff,stroke:#d32f2f,stroke-width:2px
    style B4 fill:#fff,stroke:#d32f2f,stroke-width:2px
    
    %% After nodes styling
    style A2 fill:#fff,stroke:#388e3c,stroke-width:2px
    style A3 fill:#fff,stroke:#388e3c,stroke-width:2px
    style A4 fill:#fff,stroke:#388e3c,stroke-width:2px

    %% Adding annotations
    classDef annotation fill:none,stroke:none
    
    B2_note[❌ ミス発生]:::annotation
    B3_note[❌ 時間がかかる]:::annotation
    B4_note[❌ 深夜作業]:::annotation
    
    A2_note[✅ 品質安定]:::annotation
    A3_note[✅ 即時フィードバック]:::annotation
    A4_note[✅ 作業効率化]:::annotation
    
    B2 --> B2_note
    B3 --> B3_note
    B4 --> B4_note
    
    A2 --> A2_note
    A3 --> A3_note
    A4 --> A4_note

```

- 複数人での手作業による長時間のデプロイ作業
- 環境差異による予期せぬ動作の違い
- テスト漏れによるバグの混入
- インシデント発生時の対応遅延
:::note warn
特に痛感したのはβテスト前の本番想定のリリース作業でした。
チーム全員が疲れている状態での手作業は、些細なミスを引き起こしやすく、
結果として翌日まで作業が長引くことも。
:::

### CI/CD導入で解決できること
現場で実際に経験した課題とその解決方法を共有します。

✅ **作業品質の向上**
- Before: 手順書ベースの手作業
- After: 自動化されたパイプライン
- 効果：ヒューマンエラーの大幅な削減

✅ **リリースの効率化**
- Before: 複数人での確認作業
- After: 自動テストと承認フロー
- 効果：リリースサイクルの短縮

✅ **障害対応の改善**
- Before: 切り戻し作業に時間を要する
- After: ワンクリックでのロールバック
- 効果：障害時の対応時間短縮

📌 **想定外の効果**: チームの心理的安全性が向上しました。自動化された環境では、個人の判断や操作ミスへの不安が軽減され、メンバーがより積極的に改善提案を行うようになりました。

### なぜGKEとGitLabなのか？
複数のツールやサービスを検討・検証した結果、以下の理由でGKEとGitLabを選択しました。

✅ **GitLabのメリット**
- オンプレミス運用可能（セキュリティ要件対応）
- CI/CD機能の充実度
- コミュニティの活発さと情報量

筆者の所感：CI/CDツールの選定では、チームの技術スタックや運用体制との相性を重視しました。GitLabは学習曲線が緩やかで、チーム全体での習得がスムーズでした。

✅ **GKEのメリット**
- マネージドサービスによる運用負荷軽減
- スケーラビリティの確保
- コスト効率の柔軟な調整

筆者の所感：Kubernetes運用の経験から、プラットフォーム管理の負荷は想像以上に大きいことがわかりました。マネージドサービスの活用は、開発チームの本来の役割に集中するために重要な選択でした。

### 導入による変化

```mermaid
graph LR
    subgraph Before[導入前]
        direction TB
        B1[作業手順の確認] --> B2[環境構築の相談]
    end
    
    Before --> After
    
    subgraph After[導入後]
        direction TB
        A1[機能改善の提案] --> A2[価値創造の議論]
    end
    
    style Before fill:#ffebee,stroke:#333,stroke-width:2px
    style After fill:#e8f5e9,stroke:#333,stroke-width:2px
    
    classDef beforeNode fill:#fff,stroke:#d32f2f,stroke-width:2px
    classDef afterNode fill:#fff,stroke:#388e3c,stroke-width:2px
    
    class B1,B2 beforeNode
    class A1,A2 afterNode

    %% Adding annotations
    B_note["❌ 作業レベルの会話"]:::annotation
    A_note["✅ プロダクトの本質的な議論"]:::annotation
    
    classDef annotation fill:none,stroke:none
    
    Before --> B_note
    After --> A_note
    
```

📌 **印象的な変化**: チームの会話の質が変わりました。「デプロイ手順の確認」といった作業レベルの会話から、「この機能をどう改善するか」というプロダクトの本質的な議論に時間を使えるようになりました。

### よくある懸念と実際

1. **技術的なハードルへの不安**
   - ✅ 段階的な学習が可能
   - ✅ 基本操作は1-2ヶ月で習得可能
   - ✅ チーム全体でのナレッジ共有が重要

2. **コストへの懸念**
   - ✅ スモールスタートが可能
   - ✅ 段階的な規模拡大
   - ✅ 運用工数削減による効果

3. **既存システムとの統合**
   - ✅ 新規開発から段階的に導入可能
   - ✅ 部分的な適用から開始
   - ✅ 徐々に範囲を拡大


### これから始める方へのアドバイス
現場で苦労した経験から、具体的なアドバイスを共有させていただきます。

```mermaid
graph TD
    Plan[計画<br>小さな目標設定] --> Do[実行<br>自動化の実装]
    Do --> Check[確認<br>チーム振り返り]
    Check --> Act[改善<br>フィードバック反映]
    Act --> Plan
    
    style Plan fill:#cdf,stroke:#333,stroke-width:2px
    style Do fill:#dcf,stroke:#333,stroke-width:2px
    style Check fill:#fcd,stroke:#333,stroke-width:2px
    style Act fill:#dfc,stroke:#333,stroke-width:2px

```

1. **スモールスタートの重要性**
   - 📌 私たちの場合、最初は単体テストの自動実行だけから始めました。「Hello, World!」レベルの簡単なものでしたが、これが自信につながりました
   - その後、静的解析、ステージング環境へのデプロイと、できることを少しずつ増やしていきました
:::note alert
途中、複雑な処理を一度に自動化しようとして躓いた経験から、
「小さく始めて育てる」の重要性を学びました
:::
2. **チームビルディング**
   - 最初は「面倒くさい」という声も多かったのですが、小さな成功体験を共有することで、徐々に前向きな雰囲気に変わっていきました
   - 📌 週1回の「CI/CD相談会」を設けて、困っている人がすぐに質問できる場を作りました。これが普及の鍵となりました

3. **継続的な改善**
   - 完璧主義は禁物です。最初の半年は、パイプラインが不安定で何度も失敗しました。でも、それを1つずつ改善していく過程で、チームの技術力が大きく向上しました
   - 特に印象的だったのは、障害対応時の変化です。以前は「誰が原因を作ったか」という話になりがちでしたが、「どうやって防ぐか」という建設的な議論ができるようになりました
   - 📌 現在でも月1回の振り返りを行い、パイプラインの改善点を洗い出しています。この継続的な改善サイクルが、チームの財産となっています

### まとめ
CI/CDは単なる技術導入ではありません。これは「より良いものを、より安全に、より早く届ける」ための文化づくりです。技術的な課題は必ず解決できますが、大切なのはチーム全体でその価値を理解し、共に成長していく姿勢だと実感しています。

✅ **成功のための3つのキーポイント**
- スモールスタートで確実に進める
- チーム全体で価値を共有する
- 継続的な改善を怠らない


皆さんの開発現場でのCI/CD導入の参考になれば幸いです。