· OpenWorks · tech-tips

ステークホルダーの優先度変更がCI/CDパイプラインの検証範囲を曖昧にする──自動テスト戦略の揺らぎ

CI/CD 自動テスト アジャイル テスト戦略 パイプライン設計

優先度変更のたびに「何をテストすべきか」が定まらない

アジャイルで進めている案件では、スプリント途中のスコープ変更や優先度の入れ替わりが避けられません。その過程で、「今週中に機能Aをリリースするから、機能Bのテストは次回に回そう」という判断が何度も繰り返されます。

これ自体は悪くない判断なのですが、問題はCI/CDパイプラインの検証範囲が、その都度の優先度判断に左右されてしまうことです。

現場では、こういう流れになりやすいです：

  • 機能Aの優先度が上がったので、機能AのE2Eテストだけ走らせる設定に変更する
  • 翌週、機能Cが急浮上したので、パイプラインに機能Cのテストを追加する
  • 気づくと、機能Bのテストは「いつか走らせる予定」のまま放置されている
  • リリース直前に「機能Bは本当に動いているのか？」という不安が生じる

このパターンは特に、スプリント単位でリリースを区切っている場合に顕著です。ステークホルダーの優先度判断は正当なのに、その判断がCI/CDパイプラインの設計に反映されていないために、検証の網目に穴が開いてしまう。

パイプラインの「検証範囲の定義」と「実行スケジュール」を分けて考える

この問題の根本は、「何をテストするべきか」と「今回のスプリントで何をテストするか」を混同していることです。

前者は長期的な品質ポリシーであり、後者は短期的なビジネス優先度です。この二つを同じレイヤーで判断していると、優先度の変更に応じてパイプライン自体が揺らぎます。

現実的な対策は、こう整理することです：

1. 全体的な検証範囲を定義する（変更しない）

  • 単体テスト：全モジュール対象
  • 統合テスト：コア機能＋共通部品が対象
  • E2Eテスト：ユーザーフローの主要パターンが対象
  • パフォーマンステスト：リリース前月に実施

この定義は、プロジェクト期間中はほぼ固定です。

2. 実行スケジュールを優先度に応じて調整する

  • 機能Aが優先ならば、機能Aのテストを毎日実行
  • 機能Bは週1回に落とす
  • 機能Cは統合テストのみ、E2Eは月1回
# .github/workflows/ci.yml の例（疑似コード）
jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm test  # 全モジュール、毎コミット実行

  feature-a-e2e:
    runs-on: ubuntu-latest
    if: github.event_name == 'push'  # 毎プッシュ
    steps:
      - run: npm run test:e2e:feature-a

  feature-b-e2e:
    runs-on: ubuntu-latest
    if: github.event.schedule == '0 2 * * 0'  # 週1回（日曜2時）
    steps:
      - run: npm run test:e2e:feature-b

  feature-c-integration:
    runs-on: ubuntu-latest
    if: github.event.schedule == '0 2 1 * *'  # 月1回（1日2時）
    steps:
      - run: npm run test:integration:feature-c

重要なのは、「何をテストするか」の定義は変わらないということです。検証範囲は固定で、実行頻度や実行条件だけを調整します。

「検証範囲の曖昧さ」が招く二つの問題

1. テストの重複と漏れが同時に発生する

優先度に応じてパイプラインを都度変更していると、ある機能は3つのテストで検証されているのに、別の機能は単体テストだけ、という状況になります。これは非効率なだけでなく、本番環境での予期しない障害につながりやすいです。

現場では「前回のスプリントでは動いていたはずなのに」という言い訳が増えます。実際には、その機能のE2Eテストが外されていたのかもしれません。

2. 新しいエンジニアが「何をテストすべきか」を判断できない

チームに新しいメンバーが入ったとき、パイプラインの設定を見ても「なぜこの機能はテストされていないのか」が不明です。優先度判断なのか、技術的な理由なのか、単なる忘れなのかが区別できません。

結果として、新しいメンバーは慎重になり、「念のため全部テストしよう」と判断するか、「前回と同じ範囲でいいだろう」と判断するか、どちらかの極端に振れやすくなります。

検証範囲を明示的に文書化する

実装上の工夫として、検証範囲を明示的に管理することをお勧めします。

# テスト戦略ドキュメント

## 単体テスト
- 対象：全ての新規モジュール、変更があるモジュール
- 実行：毎コミット
- カバレッジ目標：60%以上

## 統合テスト
- 対象：決済機能、ユーザー認証、データベース連携
- 実行：毎日深夜
- 対象環境：ステージング

## E2Eテスト
- 対象：
  - ユーザー登録→ログイン→購入完了の主要フロー
  - 検索→絞り込み→詳細表示の情報取得フロー
- 実行頻度：
  - 主要フロー：毎コミット
  - その他フロー：週1回
- 対象環境：ステージング（本番同期）

## パフォーマンステスト
- 対象：決済処理（レスポンス時間 < 2秒）
- 実行：月1回、またはスケーリング変更時
- 対象環境：本番環境相当

## 優先度変更時の判断ルール
- 検証範囲の定義は変更しない
- 実行頻度（毎日 → 週1回など）は変更可
- 新機能追加時は、検証範囲ドキュメントに追記してからパイプライン設定を変更

このドキュメントをプロジェクトリポジトリに置き、スプリント計画時に参照します。優先度が変わっても「検証範囲は変わらない、実行頻度が変わるだけ」という認識が共有できます。

スプリント計画で「テスト実行スケジュール」を明示する

アジャイルのスプリント計画では、機能の優先度だけでなく「今スプリント中にどのテストを何回実行するか」も明示することをお勧めします。

スプリント28（2週間）
- 機能A：開発完了、E2Eテスト毎日実行
- 機能B：開発中、E2Eテストは来週から
- 機能C：保守モード、統合テストのみ週1回
- 機能D（前スプリント）：本番稼働中、回帰テストなし

これをスプリントボードに記載することで、ステークホルダーも開発チームも「今週は何が検証されているのか」が一目瞭然になります。

小規模チームで始めやすい実装ステップ

  1. 現在のパイプライン設定を整理する
    • 今、どのテストが走っているか、走っていないか、リストアップ
    • 「なぜこのテストは走っていないのか」を確認
  2. 検証範囲ドキュメントを作る
    • 「理想的には何をテストすべきか」を書く
    • 技術的な制約や時間的な制限は後で考える
  3. 実行スケジュールを分離する
    • 毎日実行するテスト（ユニットテスト、主要フロー）
    • 週1回実行するテスト（その他フロー、統合テスト）
    • 月1回実行するテスト（パフォーマンス、全体回帰）
  4. スプリント計画に組み込む
    • 機能の優先度と同時に「このスプリント中のテスト実行スケジュール」も決める

これだけで、優先度の変更に強いCI/CDパイプラインになります。

おわりに

ステークホルダーの優先度判断は尊重すべきものです。ただし、その判断をそのままパイプライン設定に反映させると、長期的には品質の不確実性が高まります。

「検証範囲は固定、実行スケジュールは柔軟」という設計にすることで、ビジネスの優先度変更に対応しながら、検証の網目を保つことができます。