## テーマ: CI/CDパイプラインの改善で得た学び

### 聴衆分析
- 他チームのエンジニア（バックエンド中心）
- CI/CDの基本は理解している
- 具体的な改善手法に興味がある

### 構成（15分）
| パート | 時間 | 内容 |
|--------|------|------|
| Hook | 1分 | 「デプロイに2時間かかっていた時代の話」 |
| 問題提起 | 2分 | Before: ビルド15分、テスト30分、手動デプロイ1時間 |
| 解決策1 | 3分 | キャッシュ戦略でビルド時間を70%短縮 |
| 解決策2 | 3分 | テストの並列化で実行時間を60%短縮 |
| 解決策3 | 2分 | GitHub Actions + ArgoCD で自動デプロイ |
| 結果 | 2分 | After: 全工程15分。デプロイ頻度が月2→週3に |
| 学び | 2分 | 3つの教訓と次のチャレンジ |

### キーメッセージ
「CI/CDの改善は、小さな積み重ねが大きな成果を生む」

## スライドアウトライン（全15枚）

### スライド1: タイトル
「CI/CDパイプライン改善で、デプロイ時間を2時間→15分にした話」
チーム名、発表者名、日付

### スライド2: 自己紹介（30秒）
名前、チーム、担当領域

### スライド3: Before（問題提起）
デプロイフローの図。各ステップの時間を表示
合計: 約2時間

### スライド4: 痛みのポイント
- 金曜のデプロイは「デプロイガチャ」と呼ばれていた
- 月2回しかデプロイできない
- 手戻りが多い

### スライド5: 改善方針
3つの柱: ビルド高速化、テスト並列化、自動デプロイ

### スライド6-7: 改善1 - ビルド高速化
- Docker レイヤーキャッシュの最適化
- 依存関係のキャッシュ（npm ci --cache）
- マルチステージビルドの活用
結果: 15分 → 4分

### スライド8-9: 改善2 - テスト並列化
- テストの分類（Unit / Integration / E2E）
- マトリクスビルドで並列実行
- テスト結果の集約
結果: 30分 → 12分

### スライド10-11: 改善3 - 自動デプロイ
- GitHub Actions のワークフロー設計
- ArgoCD によるGitOps
- カナリアリリースの仕組み
結果: 手動1時間 → 自動5分

### スライド12: After
Before/After の比較図。数字の変化を強調

### スライド13: 効果
- デプロイ頻度: 月2回 → 週3回
- リードタイム: 2時間 → 15分
- 障害復旧時間: 1時間 → 10分

### スライド14: 学び
1. 計測から始める（推測せず、計測する）
2. 小さく改善する（一度に全部変えない）
3. 自動化は投資（初期コストを惜しまない）

### スライド15: Thank you + Q&A
連絡先、参考リンク

## スライド3: Before（問題提起）

[デプロイフロー図]

コミット → ビルド(15分) → テスト(30分) → 手動確認(15分) → デプロイ(60分) 合計: 約2時間

- 毎回、エンジニアが張り付いて監視
- 金曜のデプロイは「デプロイガチャ」
- 失敗すると、翌週に持ち越し

---

## スライド12: Before / After

| 指標 | Before | After | 改善率 |
|------|--------|-------|--------|
| ビルド時間 | 15分 | 4分 | -73% |
| テスト時間 | 30分 | 12分 | -60% |
| デプロイ時間 | 60分 | 5分 | -92% |
| **合計** | **2時間** | **15分** | **-87%** |
| デプロイ頻度 | 月2回 | 週3回 | +500% |

---

## スライド14: 3つの学び

### 1. 計測から始める
「遅い」という感覚ではなく、各ステップの時間を計測。
→ ボトルネックが明確になり、効果的に改善できた

### 2. 小さく改善する
一度に全部変えず、1つずつ改善して効果を確認。
→ 問題の切り分けが容易。チームの負担も分散

### 3. 自動化は投資
自動化の初期コストは2人×2週間。
→ 半年で元を取り、以降は毎月40時間の節約

## 企画書: テクニカルランチ

### 概要
- 名称: テクニカルランチ
- 頻度: 毎月第2水曜 12:00-13:00
- 場所: 会議室B / Zoom
- フォーマット: LT（5分 × 3-4名）+ フリーディスカッション

### 目的
1. チーム内の知見共有（暗黙知の形式知化）
2. プレゼンスキルの練習の場
3. チーム間の交流促進

### 運営ルール
- 発表は希望制（ネタがない時はリードが指名）
- スライド不要OK（ライブコーディング、ホワイトボード可）
- 「試してみた」「困っている」「失敗した」も歓迎
- 食事しながらカジュアルに

### 年間計画
| 月 | テーマ（ゆるく） | 初回登壇者 |
|----|----------------|-----------|
| 4月 | キックオフ（自己紹介LT） | 全員 |
| 5月 | 最近ハマった技術 | 希望制 |
| 6月 | トラブルシュート集 | 希望制 |

### 効果測定
- 参加率（目標80%以上）
- 発表者の延べ人数（四半期でチームの80%が1回以上）
- 参加者アンケート（満足度4/5以上）

## ドキュメント改善計画

### 現状分析
| ドキュメント | 状態 | 問題 |
|-------------|------|------|
| オンボーディング | 未整備 | 毎回口頭で説明 |
| ADR | 一部あり | 記録されていない判断が多い |
| Runbook | なし | 障害対応が属人化 |
| API Doc | 手動更新 | 実装と乖離 |

### 改善計画（3ヶ月）

#### 月1: オンボーディング整備
- セットアップガイドを作成
- 次の新メンバー入社時にフィードバック収集
- 担当: テクニカルリード

#### 月2: ADRの運用開始
- テンプレートとガイドラインを作成
- 過去の重要な判断を3件ADR化
- PRにADR更新チェックを追加

#### 月3: Runbook整備 + API Doc自動化
- 主要障害のRunbookを3件作成
- OpenAPI Spec導入でAPI Docを自動生成

### 成功指標
- 新メンバーのセットアップが1時間以内
- 月に2件以上のADRが作成される
- Runbookのカバー率50%以上

## タイトル
「テスト実行時間を80%短縮した3つの戦略」

## 導入
新機能をリリースする度に、CIのテスト実行を20分以上待つ日々。
PRのレビューもテストが終わるまで手が止まる。
「テストが足を引っ張っている」という声がチーム内で増えていました。

私たちのチームでは、3つの戦略でテスト実行時間を20分から4分に
短縮しました。この記事では、その具体的な方法と得られた学びを
共有します。

## 見出し構成
1. 問題: テスト実行時間がボトルネックになっていた
2. 計測: まず現状を正確に把握する
3. 戦略1: テストの分類と並列実行
4. 戦略2: 不要なテストの削除と重複排除
5. 戦略3: テスト実行環境の最適化
6. 結果: Before/After の数値比較
7. 学び: 計測→改善→計測のサイクルが大事
8. まとめ

## ターゲット読者
- CI/CDのテスト実行時間に悩んでいるエンジニア
- テスト戦略を見直したいテクニカルリード