維持管理基準
TQS認証を取得したプロジェクトが認証状態を維持するために遵守すべき基準を定義します。本章は認証有効期間、マイナー/パッチアップデート管理、CI合格モニタリング、定期報告、認証状態変更事由を含みます。
34.1.1. 認証有効期間
TQS認証の有効期間は、認証対象プロジェクトのバージョンライフサイクルに基づいて決定されます。
| 項目 | 基準 |
|---|---|
| 基本有効期間 | 次のメジャーバージョンリリースまで（最大1年） |
| 有効期間起算日 | 認証書発行日 |
| 有効期間満了時 | 更新審査が必要 |
| 早期満了事由 | メジャーバージョンリリース、認証一時停止、認証取消 |
認証有効期間は認証書発行日から開始され、次のメジャーバージョンがリリースされるか、最大1年が経過すると満了します。メジャーバージョンリリースが1年以内に行われる場合はメジャーバージョンリリース時点で満了し、1年以上メジャーバージョンリリースがない場合は1年経過時に満了します。
有効期間が満了する前に更新審査を申請しなければなりません。更新審査は満了日から最低2週間前に申請しなければなりません。満了日までに更新審査を完了できなかった場合、認証は自動的に一時停止されます。
34.1.2. マイナー/パッチアップデート管理
マイナーバージョン（例：v1.1 → v1.2）またはパッチバージョン（例：v1.1.0 → v1.1.1）のアップデートは、認証有効期間に影響を与えません。別途の更新審査は不要であり、CIパイプラインの合格を確認することで十分です。
マイナー/パッチアップデート時に遵守すべき事項は以下の通りです。
- アップデート後にCIパイプラインが全ステージ合格するか確認しなければなりません。
- テストカバレッジが認証時点の基準（ライン80%、ブランチ70%）以上を維持しなければなりません。
- 新しい依存関係追加時にOWASP Dependency-Checkを実行し、セキュリティ脆弱性を確認しなければなりません。
- 既存のTQS規格項目に違反する変更が含まれてはなりません。
マイナー/パッチアップデートで技術スタックの重大な変更（例：主要ライブラリの入れ替え、アーキテクチャ変更）が発生する場合、変更審査を申請しなければなりません。マイナー/パッチ番号であっても実質的な変更の範囲が大きい場合、TQS委員会が変更審査を要求する場合があります。
34.1.3. CI合格モニタリング
認証を維持するためには、CIパイプラインが安定的に合格しなければなりません。CIパイプラインの継続的な失敗は、プロジェクトの品質基準遵守が疑われる状況と見なされます。
34.1.3.1. モニタリング項目
プロジェクトチームは以下の項目を継続的にモニタリングしなければなりません。
| モニタリング項目 | 基準 | 確認周期 |
|---|---|---|
| ビルド成功率 | 90%以上維持 | 週次 |
| テスト合格率 | 100%（全テスト合格） | 毎コミット |
| カバレッジ推移 | 認証基準以上を維持 | 週次 |
| セキュリティスキャン結果 | CVSS 7.0以上の脆弱性0件 | 週次 |
| フォーマット/リント合格 | 違反0件 | 毎コミット |
34.1.3.2. 警告および通知
CIパイプラインの失敗が繰り返される場合、以下の段階的措置が実行されます。
| 条件 | 措置 |
|---|---|
| 連続3回失敗 | プロジェクトチーム内部警告（自主管理） |
| 連続5回失敗 | TQS委員会に自動通知 |
| 連続10回失敗 | TQS委員会による原因分析要請 |
| 30日以上連続失敗 | 認証一時停止の検討 |
連続5回失敗時にTQS委員会に自動で通知されます。通知後、プロジェクトチームは失敗原因と解決計画をTQS委員会に報告しなければなりません。30日以上CIが連続で失敗する場合、TQS委員会は認証一時停止を検討します。
34.1.4. 定期報告
認証を維持するプロジェクトは、四半期ごとの認証維持報告書を提出することができます。定期報告書の提出は任意ですが、報告書を提出すれば更新審査時に審査範囲を縮小できる特典があります。
34.1.4.1. 報告書記載項目
定期報告書には以下の項目を含めなければなりません。
| 項目 | 内容 | データソース |
|---|---|---|
| CI合格率 | 当該四半期のビルド成功率 | CircleCIダッシュボード |
| カバレッジ推移 | ライン/ブランチカバレッジの変化推移 | JaCoCo、Vitestレポート |
| セキュリティスキャン結果 | 当該四半期の脆弱性発見/解消状況 | OWASPレポート |
| 主要変更事項 | 技術スタック変更、アーキテクチャ変更、主要機能追加 | プロジェクト変更履歴 |
| 認証基準維持状況 | 各必須項目の充足状態サマリ | 自己点検結果 |
34.1.4.2. 報告書提出および特典
- 報告書提出周期：四半期ごと1回（3ヶ月ごと）
- 提出方法：TQS委員会に書面提出
- 報告書提出時の特典：更新審査時に定期報告書で確認された項目は再検証を省略することができます。これにより更新審査期間を短縮することができます。
- 報告書未提出時のペナルティはありません。ただし、更新審査時に全項目を再検証しなければなりません。
34.1.5. 認証状態変更事由
以下の事由が発生すると、認証状態が変更される場合があります。
| 事由 | 結果 | 対応方法 |
|---|---|---|
| メジャーバージョンリリース | 更新審査が必要 | リリース前に更新審査を申請 |
| CI長期失敗（30日以上） | 認証一時停止 | 失敗原因を解決後に復元申請 |
| セキュリティ事故発生 | セキュリティ項目の再審査 | 対応措置後に再審査申請 |
| TQS規格変更 | 猶予期間内に対応 | 変更項目を適用後に再確認 |
| プロジェクトチームの自発的要請 | 認証一時停止または取消 | TQS委員会に要請書を提出 |
34.1.5.1. メジャーバージョンリリース
メジャーバージョン（例：v1.x → v2.x）リリース時に既存の認証は満了します。メジャーバージョンに対して更新審査に合格しなければ認証は維持されません。更新審査はメジャーバージョンリリース前に事前に申請することを推奨します。
34.1.5.2. CI長期失敗
CIパイプラインが30日以上連続で失敗する場合、TQS委員会は認証一時停止を決定する場合があります。一時停止の決定前にプロジェクトチームに事前通知し、14日の解消期間を付与します。解消期間内にCIが正常化すれば一時停止を免れることができます。
34.1.5.3. セキュリティ事故発生
プロジェクトでセキュリティ事故（データ漏洩、不正アクセス、脆弱性悪用など）が発生した場合、TQS委員会はセキュリティ項目に対する再審査を要求する場合があります。プロジェクトチームは事故対応措置（原因分析、再発防止対策、セキュリティ設定の強化）を完了した後に再審査を申請しなければなりません。
34.1.5.4. TQS規格変更
TQS規格が改定される場合、既存の認証プロジェクトに猶予期間が付与されます。猶予期間は規格変更の範囲と難易度に応じてTQS委員会が決定し、基本猶予期間は3ヶ月です。猶予期間内に変更された規格項目を適用しなければ、認証が一時停止される場合があります。