技術審査
技術審査はTQS認証手続きの第3段階であり、TQS委員会が提出された成果物とプロジェクトソースコードに基づいてTQS規格の充足状況を検証する中核プロセスです。本章では、審査方法、項目別検証方法、判定基準、補完依頼手続き、結果通知について定義します。
31.4.1. 審査方法
TQS技術審査は、自動検証と手動レビューを併用して実施します。2つの方法を組み合わせることで、ツールで定量化可能な項目と人間の判断が必要な項目の両方を検証することができます。
31.4.1.1. 自動検証
自動検証は、CI/CDパイプラインの実行結果と自動化ツールの検証結果を確認する方式です。自動検証は全体審査の**60%**の比重を占めます。
自動検証の対象とツールは以下のとおりです。
| 検証項目 | ツール | 基準 | 検証方法 |
|---|---|---|---|
| バックエンドコードフォーマッティング | Spotless（Google Java Format） | 違反0件 | mvn spotless:check実行結果確認 |
| フロントエンドリント | ESLint（Flat Config） | エラー0件 | npx eslint .実行結果確認 |
| フロントエンドフォーマッティング | Prettier | 違反0件 | npx prettier --check .実行結果確認 |
| バックエンドテストカバレッジ | JaCoCo | ライン80%、ブランチ70% | JaCoCo HTMLレポート数値確認 |
| フロントエンドテストカバレッジ | Vitest coverage | ライン80%、ブランチ70% | カバレッジレポート数値確認 |
| フロントエンド性能 | Lighthouse | 性能90点以上 | Lighthouseレポートスコア確認 |
| 依存関係セキュリティ脆弱性 | OWASP Dependency-Check | CVSS 7以上0件 | スキャンレポート結果確認 |
| CI/CDパイプライン | CircleCI | 直近5回成功 | ビルド履歴確認 |
自動検証は、TQS委員会が直接ツールを実行するか、プロジェクトチームが提出した結果物をレビューする方式で実施します。CI/CDパイプラインが正常に稼働しているプロジェクトの場合、TQS委員会がパイプラインを直接トリガーして結果を確認することができます。
31.4.1.2. 手動レビュー
手動レビューは、TQS委員会の審査委員がソースコードとプロジェクト構造を直接確認する方式です。手動レビューは全体審査の**40%**の比重を占めます。
手動レビューの対象は以下のとおりです。
- コードコンベンション： 命名規則の遵守状況、コードの可読性、コメントの適正性
- アーキテクチャパターン： 機能別パッケージ構造の適用、レイヤー分離、依存性の方向
- セキュリティ実装： Spring Security設定、認証/認可ロジック、SQLパラメータバインディング、入力検証
- テスト品質： Given-When-Thenパターンの適用、テストケースの意味性、境界値テストの含有状況
- プロジェクト構造： ディレクトリ構造の標準遵守、設定ファイル管理、環境別プロファイル分離
- フロントエンド設計： コンポーネント設計原則、Composition APIの活用、状態管理パターン
手動レビューは最低2名の審査委員が独立して実施します。各審査委員は担当領域についてレビュー結果を作成し、最終判定は審査委員間の合意を通じて決定します。
31.4.1.3. 審査比率
自動検証と手動レビューの比率は、審査タイプによって異なります。
| 審査タイプ | 自動検証 | 手動レビュー | 備考 |
|---|---|---|---|
| 初回審査 | 60% | 40% | 全項目対象 |
| 更新審査 | 70% | 30% | 変更事項 + 重要項目 |
| 変更審査 | 変動 | 変動 | 変更範囲に応じて決定 |
自動検証の比率が高い理由は、TQS規格の相当部分がツールを通じて定量的に検証可能であるためです。ただし、手動レビューを通じて、ツールでは捕捉できない設計品質、コードの意図、セキュリティロジックの適正性を併せて検証します。
31.4.2. 審査項目別検証方法
TQS技術審査の詳細領域別の自動検証ツールと手動レビュー項目を定義します。
31.4.2.1. 検証マトリクス
| 審査領域 | 自動検証ツール | 手動レビュー項目 |
|---|---|---|
| コードコンベンション | Spotless、ESLint、Prettier | 命名規則遵守、コード可読性、コメント適正性 |
| テスト | JaCoCo、Vitest coverage | テスト品質、Given-When-Thenパターン、境界値テスト |
| セキュリティ | OWASP Dependency-Check | Spring Security設定、SQLパラメータバインディング、入力検証、シークレット管理 |
| 性能 | Lighthouse | バンドルサイズ最適化、画像最適化、コードスプリッティング |
| プロジェクト構造 | — | パッケージ構造、ディレクトリ構造、設定ファイル管理 |
| CI/CD | CircleCIビルドログ | パイプライン段階構成、環境分離、ビルド安定性 |
| 構成管理 | — | ブランチ戦略、コミットメッセージ形式、PRプロセス |
| API設計 | SpringDoc（Swagger UI） | RESTful規則、エラーレスポンス形式、日付形式 |
31.4.2.2. 領域別詳細検証基準
コードコンベンション領域
コードコンベンション領域は、ソースコードの一貫性と可読性を検証します。自動検証でフォーマッティング規則の遵守を確認し、手動レビューで命名規則とコード品質を確認します。
| 検証項目 | 検証方法 | 合格基準 |
|---|---|---|
| Google Java Format適用 | mvn spotless:check | 違反0件 |
| ESLint規則適用 | npx eslint . | エラー0件、警告最小化 |
| Prettier適用 | npx prettier --check . | 違反0件 |
| Java命名規則 | 手動レビュー | クラス（PascalCase）、メソッド（camelCase）、定数（UPPER_SNAKE_CASE） |
| Vueコンポーネント命名 | 手動レビュー | PascalCaseファイル名、複数単語コンポーネント名 |
| TypeScript strictモード | tsconfig.json確認 | strict: true設定 |
テスト領域
テスト領域は、テストの充実度と品質を検証します。カバレッジ数値とともに、テストコードの作成パターンと意味性を併せて評価します。
| 検証項目 | 検証方法 | 合格基準 |
|---|---|---|
| バックエンドラインカバレッジ | JaCoCoレポート | 80%以上 |
| バックエンドブランチカバレッジ | JaCoCoレポート | 70%以上 |
| フロントエンドラインカバレッジ | Vitest coverage | 80%以上 |
| フロントエンドブランチカバレッジ | Vitest coverage | 70%以上 |
| Given-When-Thenパターン | 手動レビュー | JUnit 5テスト全体適用 |
| コンポーネントテスト | 手動レビュー | 主要コンポーネントテスト作成 |
| コンポーザブルテスト | 手動レビュー | ビジネスロジック含有コンポーザブルテスト作成 |
セキュリティ領域
セキュリティ領域は、プロジェクトのセキュリティ実装レベルを検証します。セキュリティ項目は他の領域より厳格な基準を適用し、Critical項目の未充足は即時不合格事由に該当します。
| 検証項目 | 検証方法 | 合格基準 | 重要度 |
|---|---|---|---|
| TLS 1.2以上の適用 | 設定ファイル確認 | 適用完了 | Critical |
| パスワードBCryptハッシュ | 手動レビュー | 適用完了 | Critical |
| Spring Security適用 | 手動レビュー | 認証/認可設定完了 | Critical |
| SQLパラメータバインディング | 手動レビュー | jOOQバインディング使用、文字列連結未使用 | Critical |
| ソースコード内シークレット | 手動レビュー | ハードコーディング0件 | Critical |
| Bean Validation適用 | 手動レビュー | リクエストDTOに検証アノテーション適用 | High |
v-html未使用 | 手動レビュー | 未使用またはDOMPurify適用 | High |
| OWASPスキャン | レポート確認 | CVSS 7以上0件 | High |
31.4.3. 審査判定基準
技術審査の判定は、合格、条件付き合格、不合格の3種類に区分されます。判定基準は、必須項目の充足率とセキュリティCritical項目の充足状況に応じて決定されます。
31.4.3.1. 判定基準表
| 判定 | 必須項目充足率 | セキュリティCritical | 条件 |
|---|---|---|---|
| 合格 | 100% | 全項目充足 | 必須項目をすべて充足した場合 |
| 条件付き合格 | 90%以上100%未満 | 全項目充足 | 未充足項目を2週間以内に補完する条件 |
| 不合格 | 90%未満 | — | 必須項目充足率90%未満 |
| 不合格 | — | 1件以上未充足 | セキュリティCritical項目の未充足 |
31.4.3.2. 合格
合格は、すべての必須項目を充足した場合に付与される判定です。合格判定を受けたプロジェクトは、直ちに認証発行段階（第4段階）に進行します。
合格判定時に認証等級が同時に決定されます。等級は推奨項目の充足率に応じて基本、優秀、最優秀に区分されます。
| 等級 | 必須項目 | 推奨項目充足率 |
|---|---|---|
| 基本 | 100%充足 | 80%未満 |
| 優秀 | 100%充足 | 80%以上100%未満 |
| 最優秀 | 100%充足 | 100% |
31.4.3.3. 条件付き合格
条件付き合格は、必須項目充足率が90%以上であるが100%に達しない場合に付与される判定です。セキュリティCritical項目は必ず全項目充足の状態でなければなりません。
条件付き合格判定時に以下の条件が付与されます。
- 未充足項目に対する補完依頼書が発行されます。
- 補完期限は判定日から**2週間（10営業日）**です。
- 補完期限内に未充足項目をすべて解消しなければなりません。
- 補完完了後に再確認審査を受けなければなりません。
補完期限内に補完を完了できなかった場合、条件付き合格は不合格に転換されます。補完期限は延長できません。
31.4.3.4. 不合格
不合格は、必須項目充足率が90%未満であるか、セキュリティCritical項目が未充足の場合に付与される判定です。
不合格判定を受けたプロジェクトは、以下の手続きに従います。
- 審査レポートを通じて未充足項目の詳細内容を確認します。
- 未充足項目に対する補完作業を実施します。
- 補完作業完了後、第1段階（事前検討）からやり直します。
- 再審査申請時に、前回審査で指摘された項目の補完内容を明記しなければなりません。
不合格後の再審査までの最低待機期間はありません。プロジェクトチームは補完作業完了後、直ちに再審査を申請することができます。
31.4.4. 補完依頼手続き
条件付き合格判定時に補完依頼手続きが開始されます。補完依頼は、未充足項目を明確に伝達し、補完完了の有無を確認する体系的なプロセスです。
31.4.4.1. 補完手続きフロー
各段階の詳細内容は以下のとおりです。
| 段階 | 実施主体 | 活動 | 所要期間 |
|---|---|---|---|
| 補完依頼書発行 | TQS委員会 | 未充足項目、補完基準、期限の明記 | 判定後即時 |
| 補完作業実施 | プロジェクトチーム | 未充足項目の解消、コード修正、設定変更 | 最大2週間 |
| 補完完了報告 | プロジェクトチーム | 補完内容および根拠資料の提出 | — |
| 再確認審査 | TQS委員会 | 補完項目に限定した再検証 | 3営業日 |
| 最終判定 | TQS委員会 | 合格または不合格の判定 | 即時 |
31.4.4.2. 補完依頼書の内容
補完依頼書には以下の情報が含まれます。
| 項目 | 内容 |
|---|---|
| 審査番号 | 当該審査の固有識別番号 |
| プロジェクト名およびバージョン | 審査対象プロジェクト情報 |
| 判定結果 | 条件付き合格 |
| 未充足項目リスト | 項目番号、項目名、未充足理由、補完基準 |
| 補完期限 | 判定日から2週間（10営業日） |
| 補完完了報告方法 | 提出様式および提出先 |
| 担当審査委員 | 再確認審査を実施する委員 |
31.4.4.3. 再確認審査
再確認審査は、補完依頼された項目に限定して実施されます。既存の審査で充足と判定された項目は再確認の対象に含まれません。
再確認審査の結果は合格または不合格のみです。再確認審査では条件付き合格は付与されません。補完項目をすべて充足すれば合格、1つでも未充足であれば不合格と判定されます。
31.4.5. 審査結果の通知
審査完了後、TQS委員会はプロジェクトチームに審査結果を公式に通知します。
31.4.5.1. 通知期限
審査完了日から3営業日以内に結果を通知しなければなりません。通知はプロジェクトリードに公式文書（審査レポート）とともに伝達されます。
31.4.5.2. 審査レポート
審査レポートは、審査プロセスと結果を総合的に記録した公式文書です。審査レポートには以下の情報が含まれます。
| レポート項目 | 内容 |
|---|---|
| 審査基本情報 | 審査番号、プロジェクト名、バージョン、審査タイプ、審査期間 |
| 審査委員情報 | 審査に参加した委員一覧 |
| 領域別審査結果 | コードコンベンション、テスト、セキュリティ、性能、構造、CI/CD領域別結果 |
| 項目別充足状況 | 全項目の充足/未充足の詳細状況 |
| 自動検証結果要約 | 各ツール別実行結果要約 |
| 手動レビュー所見 | 審査委員のコードレビュー意見および改善勧告事項 |
| 最終判定 | 合格/条件付き合格/不合格および理由 |
| 認証等級（合格時） | 基本/優秀/最優秀および算定根拠 |
31.4.5.3. 審査結果に対する異議申立て
プロジェクトチームは、審査結果に対して異議を申し立てることができます。異議申立ては、結果通知日から5営業日以内に書面で提出しなければなりません。
異議申立て時に以下の事項を明記しなければなりません。
- 異議対象項目（審査レポートの項目番号）
- 異議理由（具体的な根拠を含む）
- プロジェクトチームの主張を裏付ける証拠資料
TQS委員会は異議申立てを受理した後、5営業日以内に検討結果を通知します。異議が受理された場合は審査結果が変更され、棄却された場合は既存の判定が維持されます。異議申立ては1回に限り可能です。