LESSON 30分

ストーリー

田
田中VPoE
現状分析で課題が明確になった。ここからは解決策を設計するフェーズだ。まずはパイプライン設計の原則から始めよう
あなた
原則というと、設計パターンのようなものですか？
あ
田
田中VPoE
近い。ただし、個人やチームのパイプラインではなく、組織全体で共通の設計原則だ。20チームが同じ原則に基づいてパイプラインを構築できるようにする
あなた
チームごとにプロダクトの性質が違いますが、共通の原則を適用できるんでしょうか？
あ
田
田中VPoE
いい質問だ。共通化すべきところと、チームに裁量を与えるところの線引きが鍵になる

5つの設計原則

組織全体のパイプラインを設計する際に守るべき5つの原則を定義します。

原則1: Pipeline as Code

パイプラインの定義をコードとしてバージョン管理します。

側面説明
何をパイプラインの全ステージ、環境変数、シークレット参照、トリガー条件
なぜ変更履歴の追跡、レビューによる品質担保、再現性の確保
どこにアプリケーションリポジトリ内（.github/workflows/等）
例外シークレットの値自体はコードに含めない
# GitHub Actions: Pipeline as Code の例
name: Standard Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    uses: org/shared-workflows/.github/workflows/build.yml@v2
    with:
      language: "typescript"
      node-version: "20"

  test:
    needs: build
    uses: org/shared-workflows/.github/workflows/test.yml@v2

  security:
    needs: build
    uses: org/shared-workflows/.github/workflows/security-scan.yml@v2

原則2: 不変性（Immutability）

一度ビルドされたアーティファクトは変更せず、同じアーティファクトを全環境にデプロイします。

アンチパターン正しいアプローチ
環境ごとにビルドし直す一度ビルドして全環境で同じアーティファクトを使用
デプロイ時にコードを変更環境差分は設定（環境変数）で吸収
手動でファイルを編集すべての変更はパイプラインを通す

原則3: 高速フィードバック

パイプラインは可能な限り高速にフィードバックを返します。

理想的なフィードバック時間:

コミット → ビルド完了:          < 5分
コミット → ユニットテスト完了:   < 10分
コミット → セキュリティスキャン:  < 10分
コミット → 統合テスト完了:       < 20分
コミット → デプロイ可能:         < 30分

高速化のテクニック:

  • テストの並列実行
  • 差分ビルド（変更されたモジュールのみ）
  • レイヤーキャッシュ（Docker、依存パッケージ）
  • テスト影響分析（変更に関連するテストのみ実行）

原則4: 自己文書化

パイプラインの構成と動作が、パイプライン自体から理解できるようにします。

実践効果
ステージに明確な名前をつける何が実行されているか一目でわかる
失敗時のエラーメッセージを充実させる問題の特定と修正が速くなる
パイプラインの実行ログを構造化する後からの分析と改善が容易になる
READMEにパイプラインの説明を含める新メンバーのオンボーディングが速くなる

原則5: 漸進的な展開（Progressive Delivery）

変更は段階的にリリースし、問題があれば即座にロールバックできるようにします。

漸進的な展開のステージ:

1. ビルド & テスト（全PR）
2. ステージング環境デプロイ
3. カナリアリリース（5%のトラフィック）
4. 段階的ロールアウト（25% → 50% → 100%）
5. 自動ロールバック（エラー率閾値超過時）

共通化と自律性の線引き

組織全体のパイプライン設計で最も難しい判断が、「共通化すべきもの」と「チームに委ねるもの」の線引きです。

共通化すべきものチームに委ねるもの
セキュリティスキャンのステージテストの種類と実行方法
アーティファクトの署名と検証ビルドツールの選択
デプロイの承認プロセスデプロイのタイミング
ログとメトリクスの収集カスタムメトリクスの定義
シークレット管理の方法開発ワークフロー
コンプライアンスゲートテストカバレッジの閾値

「チームの自律性を尊重しつつ、組織として譲れない基準を守る。このバランスが取れたとき、基盤は本当に機能する」 — 田中VPoE

まとめ

ポイント内容
5つの原則Pipeline as Code、不変性、高速フィードバック、自己文書化、漸進的展開
共通化セキュリティ、コンプライアンス、監査は組織共通
自律性テスト戦略、ビルドツール、開発ワークフローはチーム裁量

チェックリスト

  • パイプライン設計の5つの原則を理解した
  • 不変性（Immutability）の重要性を理解した
  • 共通化と自律性の線引きの考え方を理解した

次のステップへ

次は「ビルド・テスト・デプロイの標準化」です。設計原則を具体的なパイプラインステージに落とし込んでいきましょう。

推定読了時間: 30分