審査申請および受付
審査申請および受付はTQS認証手続きの第2段階であり、プロジェクトチームが事前検討を完了した後、正式審査を申請するプロセスです。本章では、提出すべき成果物、成果物作成ガイド、受付手続き、審査費用、スケジュール調整について定義します。
31.3.1. 提出成果物
プロジェクトチームは、審査申請時に以下の成果物を提出しなければなりません。成果物は必須と推奨に区分され、必須成果物が欠落している場合は受付が差し戻されます。
| 番号 | 成果物 | 説明 | 必須有無 |
|---|---|---|---|
| 1 | 自主点検チェックリスト | 項目別充足状況および根拠（スクリーンショット/リンク含む） | 必須 |
| 2 | プロジェクトリポジトリのアクセス権限 | ソースコードレビューのための読み取り権限（GitHub） | 必須 |
| 3 | CI/CDパイプライン結果 | 直近5回のビルド/テスト通過履歴（CircleCI） | 必須 |
| 4 | テストカバレッジレポート | JaCoCo（バックエンド）+ Vitest coverage（フロントエンド） | 必須 |
| 5 | 依存関係セキュリティスキャンレポート | OWASP Dependency-Check結果 | 推奨 |
| 6 | Lighthouseレポート | 性能/アクセシビリティスコア（フロントエンド含むプロジェクト） | 推奨 |
| 7 | プロジェクトアーキテクチャ文書 | システム構成図、技術スタック説明、主要設計決定事項 | 推奨 |
必須成果物は、TQS委員会が審査を遂行するための最低限の資料です。推奨成果物は、審査の効率性を高め、プロジェクトに対する審査委員の理解度を向上させる補助資料です。推奨成果物を提出しなくても審査は進行しますが、該当領域の審査により多くの時間がかかる場合があります。
優秀または最優秀等級を目標とするプロジェクトは、推奨成果物をすべて提出することを推奨します。推奨項目の充足状況を証明する根拠資料として活用されるためです。
31.3.2. 成果物作成ガイド
各成果物の具体的な作成方法と形式を案内します。成果物は定められた形式に合わせて作成しなければならず、形式が適合しない場合は補完依頼を受ける場合があります。
31.3.2.1. 自主点検チェックリスト
自主点検チェックリストは、TQS認証チェックリスト（第32章）のすべての項目について充足状況を記録した文書です。
| 記載項目 | 記載方法 |
|---|---|
| 項目番号 | チェックリスト原本の項目番号をそのまま使用 |
| 充足状況 | 充足(O)、部分充足(△)、未充足(X)で表記 |
| 根拠資料 | 充足の場合：設定ファイルパス、スクリーンショット、CIログリンク |
| 部分充足の場合：現在の数値と目標数値を明記 | |
| 未充足の場合：未充足理由を記載 | |
| 備考 | 当該項目に対する追加説明または特記事項 |
自主点検チェックリストは審査の出発点となります。正確かつ誠実に作成しなければならず、実際の状態と異なる記載をした場合、審査過程で信頼性の問題が発生する場合があります。
31.3.2.2. プロジェクトリポジトリのアクセス権限
TQS委員会がソースコードを直接確認できるよう、GitHubリポジトリの読み取り権限を付与しなければなりません。
- リポジトリがprivateの場合、TQS委員会のGitHub組織アカウントまたは審査委員個人アカウントにCollaborator権限（Read）を付与します。
- リポジトリがorganization所属の場合、当該organizationのteamにTQS委員会アカウントを追加します。
- アクセス権限は審査期間中維持しなければならず、審査完了後に解除することができます。
- リポジトリのデフォルトブランチ（mainまたはmaster）が審査対象バージョンの最新状態を反映していなければなりません。
31.3.2.3. CI/CDパイプライン結果
CI/CDパイプライン結果は、プロジェクトのビルド、テスト、リント検証が継続的に通過していることを証明する資料です。
| 提出項目 | 詳細要件 |
|---|---|
| 直近5回のビルド履歴 | CircleCIダッシュボードのスクリーンショットまたはビルドURL |
| 各ビルドの段階別結果 | リント、テスト、ビルド各段階の成功/失敗状態 |
| 失敗履歴の含有有無 | 直近5回のうち失敗がある場合は失敗理由と解決内容を含む |
| パイプライン設定ファイル | .circleci/config.ymlファイルパスが確認可能な状態 |
直近5回のビルドがすべて成功状態でなければなりません。5回のうち失敗が含まれている場合、当該失敗の原因と解決過程を明記しなければなりません。繰り返しのビルド失敗履歴は、審査時にマイナス要因として作用する場合があります。
31.3.2.4. テストカバレッジレポート
テストカバレッジレポートは、プロジェクトのテスト充実度を定量的に証明する資料です。
バックエンド（JaCoCo）：
mvn test jacoco:report実行後に生成されるHTMLレポートを提出します。- レポートパス：
target/site/jacoco/index.html - ラインカバレッジ80%以上、ブランチカバレッジ70%以上を充足しなければなりません。
- プロジェクト全体レベルのカバレッジとパッケージ別カバレッジの両方を確認できなければなりません。
フロントエンド（Vitest）：
npx vitest run --coverage実行後に生成されるカバレッジレポートを提出します。- ラインカバレッジ80%以上、ブランチカバレッジ70%以上を充足しなければなりません。
- コンポーネントテスト、コンポーザブルテスト、ストアテストのカバレッジをすべて含めなければなりません。
31.3.2.5. 依存関係セキュリティスキャンレポート
OWASP Dependency-Checkを実行して生成されたセキュリティスキャンレポートを提出します。この成果物は推奨事項ですが、優秀または最優秀等級を目標とする場合は提出しなければなりません。
mvn dependency-check:check実行後に生成されるHTMLレポートを提出します。- CVSS（Common Vulnerability Scoring System）7以上の脆弱性がないことが求められます。
- 脆弱性が存在する場合、対応計画（バージョンアップグレードスケジュール等）を併せて提出します。
31.3.2.6. Lighthouseレポート
フロントエンドを含むプロジェクトは、Lighthouseレポートを提出することを推奨します。
- Chrome DevToolsのLighthouseタブまたはLighthouse CLIを使用してレポートを生成します。
- 主要ページ（ログイン、ダッシュボード、主要機能ページ）のそれぞれについてレポートを提出します。
- 性能スコア90点以上を充足しなければなりません。
- アクセシビリティ、ベストプラクティス、SEOスコアも参考資料として含めます。
31.3.2.7. プロジェクトアーキテクチャ文書
プロジェクトの全体的な技術構造を説明する文書です。審査委員がプロジェクトを迅速に理解するのに役立ちます。
- システム構成図（バックエンド、フロントエンド、データベース、外部連携構成）
- 技術スタック一覧および選定理由
- 主要設計パターンおよびアーキテクチャ決定事項
- ディレクトリ構造の説明
31.3.3. 受付手続き
審査申請の受付手続きは、以下の4段階で進行します。
31.3.3.1. 手続きフロー
各段階の詳細内容は以下のとおりです。
| 段階 | 実施主体 | 活動 | 所要期間 |
|---|---|---|---|
| 提出 | プロジェクトチーム | 成果物一式をTQS委員会に提出 | — |
| 書類確認 | TQS委員会 | 必須成果物の有無、形式の適合性確認 | 1営業日 |
| 受付通知 | TQS委員会 | 受付完了または補完依頼の通知 | 1営業日 |
| 審査スケジュール確定 | TQS委員会 | 審査開始日、審査委員配置の通知 | 2営業日 |
31.3.3.2. 書類確認基準
TQS委員会は、提出された成果物に対して以下の事項を確認します。
- 必須成果物4種がすべて含まれているか確認します。
- 各成果物の形式が本章で定義した基準に適合しているか確認します。
- プロジェクトリポジトリに対するアクセス権限が正常に付与されているか確認します。
- 自主点検チェックリストが全項目を含んでいるか確認します。
書類確認の結果、不備事項がある場合、TQS委員会はプロジェクトチームに補完依頼を通知します。補完依頼には不備事項の具体的な内容と補完期限が含まれます。補完期限は通知日から3営業日以内です。
31.3.3.3. 受付差戻し理由
以下に該当する場合、審査申請が差し戻されます。
- 必須成果物が欠落している場合
- 自主点検チェックリストで必須項目の未充足が明白な場合（未充足必須項目が5件以上）
- プロジェクトリポジトリへのアクセスが不可能な場合
- 補完依頼に対して期限内に補完が行われなかった場合
受付が差し戻された場合、プロジェクトチームは差戻し理由を解消した後、再度審査を申請することができます。再申請の回数制限はありません。
31.3.4. 審査費用
TQS認証はティエニピア社内認証制度です。そのため、別途の審査費用は発生しません。
TQS委員会の審査遂行は、委員会業務の一環として処理されます。プロジェクトチームは審査申請時に別途の費用を負担せず、審査結果に伴う追加費用も発生しません。
ただし、補完作業に必要な開発リソースはプロジェクトチームの負担です。事前検討段階で十分な準備を行い、補完作業を最小化することが効率的です。
外部アドバイザーが必要な場合、当該費用はTQS委員会の運営予算から支出されます。プロジェクトチームに別途費用が請求されることはありません。
31.3.5. スケジュール調整
審査スケジュールは、TQS委員会とプロジェクトチームが協議して確定します。プロジェクトのリリーススケジュールと審査スケジュールが衝突しないよう、事前に調整しなければなりません。
31.3.5.1. 審査開始期限
審査申請受付日から5営業日以内に審査を開始しなければなりません。TQS委員会は受付通知時に審査開始予定日を併せて案内します。
5営業日以内の審査開始が困難な場合（委員会のスケジュール、同時審査件数の超過等）、TQS委員会はプロジェクトチームに遅延理由と変更後の審査開始予定日を通知しなければなりません。
31.3.5.2. リリーススケジュールの考慮
プロジェクトチームは、審査申請時に次回リリーススケジュールを併せて提出することを推奨します。TQS委員会はプロジェクトのリリーススケジュールを考慮して審査を進行します。
- リリース予定日が迫っている場合、優先審査を依頼することができます。
- 優先審査はTQS委員会の判断に基づき、受諾の可否が決定されます。
- 優先審査が受諾された場合でも、審査基準は同一に適用されます。
31.3.5.3. 審査スケジュールの変更
受付確定後に審査スケジュールの変更が必要な場合、審査開始予定日の2営業日前までに変更を依頼しなければなりません。審査開始日以降のスケジュール変更は原則として認められません。
審査進行中にプロジェクト側の理由で審査が中断された場合、当該審査は取消処理され、今後新たな審査申請を通じて再度進行しなければなりません。