運用チェックリスト
本章ではTQS-S/W認証の運用領域に対する詳細チェックリストを定義します。運用チェックリストは構成管理、CI/CD、テスト標準の3つの領域で構成されます。各項目の分類は必須(O)、推奨(R)、任意(S)に区分され、検証方法を併せて明示します。
32.4.1. 構成管理
構成管理チェックリストはGitベースのソースコードバージョン管理、ブランチ戦略、コミット規則、PR運用の標準遵守を検証します。
| 番号 | 項目 | 分類 | 検証方法 |
|---|---|---|---|
| 1 | GitHub Flowブランチ戦略を適用する | O | ブランチリストおよび運用履歴確認 |
| 2 | Conventional Commits形式でコミットメッセージを作成する | O | コミットログ確認 |
| 3 | PRテンプレートをプロジェクトに含める | O | .github/PULL_REQUEST_TEMPLATE.mdファイル存在確認 |
| 4 | PRレビュアーを最低1名以上指定する | O | PR履歴確認 |
| 5 | .gitignoreファイルがTQS標準を遵守する | O | .gitignoreファイル内容確認 |
| 6 | Semantic Versioning (SemVer)を適用する | O | タグおよびリリース履歴確認 |
| 7 | mainブランチに保護ルールを設定する（直接プッシュ禁止） | R | GitHubリポジトリ設定確認 |
| 8 | コミットにGPGまたはSSH署名を適用する | S | コミットログの署名有無確認 |
構成管理はプロジェクトの変更履歴を体系的に管理する基盤です。GitHub Flowブランチ戦略はシンプルかつ効果的なワークフローを提供し、Conventional Commitsは自動変更ログ生成とバージョン管理の基盤となります。
32.4.1.1. 構成管理検証詳細基準
GitHub Flowブランチ戦略の遵守状況は以下の基準で判定します。
mainブランチは常にデプロイ可能な状態を維持しなければなりません。- 機能開発は
mainから分岐したフィーチャーブランチで実施しなければなりません。 - フィーチャーブランチはPRを通じて
mainにマージしなければならず、直接プッシュは許可しません。
Conventional Commitsの遵守状況は直近50件のコミットを基準に検証します。コミットメッセージの90%以上がConventional Commits形式（feat:、fix:、docs:、refactor:等）に従っていれば合格と判定します。
32.4.2. CI/CD
CI/CDチェックリストはCircleCIベースの継続的インテグレーションおよびデプロイパイプラインの構成を検証します。
| 番号 | 項目 | 分類 | 検証方法 |
|---|---|---|---|
| 9 | CircleCIパイプラインを構成する | O | .circleci/config.ymlファイル存在確認 |
| 10 | リント検証ステージをパイプラインに含める | O | CircleCI設定ファイルのリントステージ確認 |
| 11 | テスト実行ステージをパイプラインに含める | O | CircleCI設定ファイルのテストステージ確認 |
| 12 | ビルドステージをパイプラインに含める | O | CircleCI設定ファイルのビルドステージ確認 |
| 13 | 直近5回のビルドが全て成功状態である | O | CircleCIビルド履歴確認 |
| 14 | セキュリティスキャンステージをパイプラインに含める | R | CircleCI設定ファイルのセキュリティスキャンステージ確認 |
| 15 | デプロイ自動化を実装する | R | CircleCI設定ファイルのデプロイステージ確認 |
| 16 | 環境別（dev / staging / prod）パイプラインを分離する | R | CircleCI設定ファイルのワークフロー確認 |
CI/CDはコード品質を継続的に検証しデプロイ安定性を保証する核心インフラです。パイプラインには最低限リント検証、テスト実行、ビルドの3ステージを必須で含めなければなりません。
32.4.2.1. CI/CD検証詳細基準
CircleCIパイプラインの検証は以下の基準で実施します。
.circleci/config.ymlファイルがプロジェクトルートに存在しなければなりません。- パイプラインの各ステージ（リント、テスト、ビルド）は独立して実行可能でなければなりません。
- パイプライン実行時間は15分以内を推奨します。
- ビルド履歴はCircleCIダッシュボードまたはAPIを通じて確認します。
32.4.3. テスト標準
テスト標準チェックリストはバックエンドテストのフレームワーク、記述パターン、カバレッジ基準、テスト分離レベルを検証します。
| 番号 | 項目 | 分類 | 検証方法 |
|---|---|---|---|
| 17 | JUnit 5をテストフレームワークとして使用する | O | pom.xml依存関係確認 |
| 18 | Given-When-Thenパターンでテストを記述する | O | テストコードレビュー |
| 19 | ラインカバレッジ80%以上を達成する | O | JaCoCoレポート確認 |
| 20 | ブランチカバレッジ70%以上を達成する | O | JaCoCoレポート確認 |
| 21 | 各テストは独立して実行可能である（テスト間の依存関係なし） | O | テストコードレビュー |
| 22 | テストメソッド名がテスト意図を明確に表現する | O | テストコードレビュー |
| 23 | Testcontainersを活用して統合テストを実施する | R | pom.xml依存関係およびテストコード確認 |
| 24 | テストデータをテスト別に独立管理する（共有データ未使用） | R | テストコードレビュー |
| 25 | 境界値テストを含める | R | テストコードレビュー |
テスト標準はコードの信頼性と保守性を保証する核心領域です。JUnit 5とGiven-When-Thenパターンはテストの可読性と構造化を保証し、カバレッジ基準はテストの充実度を定量的に検証します。
32.4.3.1. テスト検証詳細基準
テストカバレッジはJaCoCoレポート基準で測定します。カバレッジ算定時に以下の規則を適用します。
- 自動生成されたコード（jOOQ codegen等）はカバレッジ算定から除外します。
- 設定クラス（
@Configuration）はカバレッジ算定から除外することができます。 - DTO、VO等の単純データオブジェクトはカバレッジ算定から除外することができます。
Given-When-Thenパターンの遵守状況は手動レビューで検証します。テストメソッドの構造が明確に準備（Given）、実行（When）、検証（Then）の段階に区分されていなければなりません。
32.4.4. 項目要約
運用チェックリストの全項目数と分類別分布は以下のとおりです。
| 領域 | 必須(O) | 推奨(R) | 任意(S) | 合計 |
|---|---|---|---|---|
| 構成管理 | 6 | 1 | 1 | 8 |
| CI/CD | 5 | 3 | 0 | 8 |
| テスト標準 | 6 | 3 | 0 | 9 |
| 合計 | 17 | 7 | 1 | 25 |
運用チェックリストは合計25項目で構成されます。必須項目17個を全て充足しなければ基本認証を取得できず、推奨項目7個の充足率に応じて優秀または最優秀認証等級が決定されます。任意項目1個は認証等級の算定に含まれません。
32.4.5. 運用検証時の留意事項
運用チェックリストの検証時に以下の事項に留意しなければなりません。
- 構成管理項目はプロジェクトのGitHubリポジトリを直接確認して検証します。非公開リポジトリの場合、TQS委員会に読み取り権限を付与しなければなりません。
- CI/CD項目はパイプライン設定ファイルと実行履歴を併せて確認します。設定ファイルのみ存在し実際の実行履歴がない場合、未充足と判定します。
- テスト標準項目は自動検証（カバレッジ数値）と手動レビュー（テストコード品質）を併用して検証します。
- コミット履歴とPR履歴は直近3か月以内の活動を基準に検証します。