自己点検ツール
TQS認証審査を申請する前に、プロジェクトチームが自主的に規格適合性を検証できるツールと活用方法を定義します。本章は自動化検証ツール総括、ツール別設定ガイド、CI連携点検、総合レポート作成方法を含みます。
33.2.1. 自動化検証ツール総括
TQS認証で要求される主要検証項目は、自動化ツールを通じて定量的に測定することができます。以下の表はTQS自己点検に使用するコアツールと合格基準を整理したものです。
| ツール | 検証領域 | 実行コマンド | 合格基準 |
|---|---|---|---|
| Spotless | Javaコードフォーマット | mvn spotless:check | フォーマット違反0件 |
| ESLint | JS/TSコード品質 | yarn lint | エラー0件 |
| Prettier | コードフォーマット | yarn format:check | フォーマット違反0件 |
| JaCoCo | バックエンドテストカバレッジ | mvn test jacoco:report | ライン80%、ブランチ70% |
| Vitest | フロントエンドテスト | yarn test:coverage | ライン80%、ブランチ70% |
| Lighthouse | Webパフォーマンス/アクセシビリティ | npx lighthouse <URL> | パフォーマンス90点、アクセシビリティ90点 |
| OWASP Dependency-Check | 依存関係セキュリティ | mvn dependency-check:check | CVSS 7.0以上の脆弱性0件 |
すべてのツールはCLI環境で実行できなければならず、CI/CDパイプラインで自動的に実行されるよう構成しなければなりません。
33.2.2. ツール別設定ガイド
各ツールのインストールおよび基本設定方法を説明します。
33.2.2.1. Spotless（バックエンドコードフォーマット）
Spotlessはspotless-maven-pluginを通じてMavenプロジェクトに統合します。pom.xmlの<build> > <plugins>セクションにプラグインを追加しなければなりません。
主要設定項目は以下の通りです。
| 設定項目 | 値 | 説明 |
|---|---|---|
| フォーマッタ | Google Java Format | TQS必須フォーマッタ |
| 適用対象 | src/**/*.java | 全Javaソース |
| 除外対象 | 自動生成コード | jOOQ生成コードなど |
- フォーマット検査：
mvn spotless:check（違反時ビルド失敗） - フォーマット適用：
mvn spotless:apply（自動修正）
33.2.2.2. ESLint（フロントエンドコード品質）
ESLintはFlat Config形式で設定しなければなりません。プロジェクトルートにeslint.config.jsファイルを作成します。
主要設定項目は以下の通りです。
| 設定項目 | 値 | 説明 |
|---|---|---|
| 設定形式 | Flat Config | TQS必須形式 |
| パーサー | @typescript-eslint/parser | TypeScriptサポート |
| Vueプラグイン | eslint-plugin-vue | Vue 3 SFCリント |
| TypeScriptプラグイン | @typescript-eslint/eslint-plugin | 型安全性ルール |
any型の使用禁止ルール（@typescript-eslint/no-explicit-any）をerrorに設定しなければなりません。- Vue Composition API強制ルールを有効化することを推奨します。
33.2.2.3. Prettier（コードフォーマット）
Prettierはプロジェクトルートの.prettierrcファイルで設定します。
TQSで推奨する基本設定値は以下の通りです。
| 設定項目 | 推奨値 | 説明 |
|---|---|---|
printWidth | 100 | 1行の最大長 |
tabWidth | 2 | インデントサイズ |
useTabs | false | スペース使用 |
semi | true | セミコロン使用 |
singleQuote | true | シングルクォート使用 |
trailingComma | all | 末尾カンマ使用 |
- フォーマット検査：
yarn format:checkまたはnpx prettier --check . - フォーマット適用：
yarn formatまたはnpx prettier --write .
33.2.2.4. JaCoCo（バックエンドテストカバレッジ）
JaCoCoはjacoco-maven-pluginを通じてMavenプロジェクトに統合します。pom.xmlにプラグインを追加し、カバレッジ閾値を設定しなければなりません。
TQS必須カバレッジ基準は以下の通りです。
| カバレッジ種別 | 最低基準 | 備考 |
|---|---|---|
| ラインカバレッジ | 80% | 必須 |
| ブランチカバレッジ | 70% | 必須 |
カバレッジ測定から除外できる対象は以下の通りです。
- jOOQ自動生成コード
- 設定クラス（
@Configuration） - DTOおよびRecordクラス
- mainメソッドを含むアプリケーションエントリポイント
33.2.2.5. Vitest（フロントエンドテスト）
Vitestはvite.config.tsでテスト設定を管理します。別途のvitest.config.tsファイルを使用することもできます。
主要設定項目は以下の通りです。
| 設定項目 | 値 | 説明 |
|---|---|---|
| テスト環境 | jsdomまたはhappy-dom | DOMシミュレーション |
| カバレッジプロバイダー | v8またはistanbul | カバレッジ測定エンジン |
| カバレッジレポーター | text、html、lcov | レポート出力形式 |
- テスト実行：
yarn test - カバレッジ測定：
yarn test:coverage - カバレッジ基準はバックエンドと同様にライン80%、ブランチ70%を満たさなければなりません。
33.2.2.6. Lighthouse（Webパフォーマンス/アクセシビリティ）
LighthouseはChrome DevToolsまたはCLIを通じて実行することができます。CI環境ではCLI方式を使用します。
TQS必須スコア基準は以下の通りです。
| カテゴリ | 最低スコア | 備考 |
|---|---|---|
| パフォーマンス (Performance) | 90点 | 必須 |
| アクセシビリティ (Accessibility) | 90点 | 必須 |
| ベストプラクティス (Best Practices) | 80点 | 推奨 |
| SEO | 80点 | 推奨 |
- CLIインストール：
npm install -g lighthouse - 実行：
npx lighthouse <URL> --output=json --output-path=./lighthouse-report.json
33.2.2.7. OWASP Dependency-Check（依存関係セキュリティ）
OWASP Dependency-Checkはdependency-check-mavenプラグインを通じてMavenプロジェクトに統合します。
主要設定項目は以下の通りです。
| 設定項目 | 値 | 説明 |
|---|---|---|
| 失敗閾値 | CVSS 7.0 | このスコア以上の脆弱性発見時にビルド失敗 |
| レポート形式 | HTML、JSON | 結果レポート出力形式 |
| 自動更新 | 有効化 | NVDデータベース自動更新 |
- スキャン実行：
mvn dependency-check:check - CVSS 7.0以上の脆弱性が1件でも発見されるとビルドが失敗します。
- フロントエンドの依存関係は
yarn auditまたはnpm auditで別途点検します。
33.2.3. CI連携点検
すべての自動化検証ツールはCircleCIパイプラインに統合し、毎コミットごとに自動で実行されるよう構成しなければなりません。
33.2.3.1. パイプライン構成順序
CIパイプラインは以下の順序で検証ステージを実行しなければなりません。
| 順序 | ステージ | 実行ツール | 失敗時の動作 |
|---|---|---|---|
| 1 | コードフォーマット検査 | Spotless、Prettier | パイプライン中断 |
| 2 | リント検査 | ESLint | パイプライン中断 |
| 3 | 単体テスト | JUnit 5、Vitest | パイプライン中断 |
| 4 | カバレッジ検証 | JaCoCo、Vitest Coverage | パイプライン中断 |
| 5 | ビルド | Maven、Vite | パイプライン中断 |
| 6 | セキュリティスキャン | OWASP Dependency-Check | パイプライン中断 |
各ステージは前のステージが成功した場合にのみ実行されます。ステージが失敗した場合、後続ステージを実行せず直ちにパイプラインを中断します。
33.2.3.2. CI点検チェックリスト
CI連携が正しく構成されているか、以下の項目を確認しなければなりません。
- すべての検証ツールがCI環境で正常に実行されるか確認します。
- 検証失敗時にパイプラインが中断されるか確認します。
- カバレッジレポートがCIアーティファクトとして保存されるか確認します。
- セキュリティスキャン結果がレポートとして出力されるか確認します。
- ビルド成功/失敗の通知がチームに送達されるか確認します。
33.2.4. 総合レポート作成
各ツールの実行結果を総合して、TQS自己点検レポートを作成しなければなりません。このレポートは審査申請時の参考資料として活用されます。
33.2.4.1. レポート記載項目
総合レポートには以下の項目を含めなければなりません。
| 項目 | 内容 | 出典 |
|---|---|---|
| プロジェクト情報 | プロジェクト名、バージョン、技術スタック | 手動作成 |
| コードフォーマット結果 | Spotless、Prettier実行結果 | ツール実行ログ |
| リント結果 | ESLint実行結果、警告/エラー件数 | ESLintレポート |
| バックエンドカバレッジ | ライン/ブランチカバレッジ数値 | JaCoCoレポート |
| フロントエンドカバレッジ | ライン/ブランチカバレッジ数値 | Vitestレポート |
| パフォーマンス/アクセシビリティスコア | Lighthouse各カテゴリスコア | Lighthouseレポート |
| セキュリティスキャン結果 | 脆弱性件数、最高CVSSスコア | OWASPレポート |
| CIパイプライン状態 | 直近のビルド成功率、連続成功回数 | CircleCIダッシュボード |
33.2.4.2. レポート作成基準
- すべての数値はツールの実行結果から直接抽出しなければなりません。手動で数値を調整してはなりません。
- レポート作成時点の日付と実行環境（OS、ツールバージョン）を明記しなければなりません。
- 未充足項目がある場合、当該項目に対する補完計画と予想完了日を記載しなければなりません。
- レポートは審査申請書とともに提出します。レポートなしで審査を申請することも可能ですが、レポートを添付すれば審査期間を短縮することができます。