事前検討
事前検討はTQS認証手続きの第1段階であり、プロジェクトチームが正式審査を申請する前に、自主的に規格適合性を診断するプロセスです。本章では、事前検討の目的、実施方法、Gap分析、補完計画、事前コンサルティング手続きを定義します。
31.2.1. 事前検討の目的
事前検討の核心的な目的は、正式技術審査における不合格リスクを最小化することです。正式審査で不合格判定を受けると、補完作業後に第1段階からやり直さなければならないため、最低3〜4週間の追加期間が必要となります。事前検討を通じて未充足項目を事前に識別し補完することで、認証取得までの全体所要期間を短縮することができます。
事前検討を実施すると、以下の効果が期待できます。
- 正式審査前にプロジェクトの規格充足状況を客観的に把握することができます。
- 未充足項目に対する補完優先順位を明確に設定することができます。
- チーム内のTQS規格に対する理解度を高め、規格遵守の文化を定着させることができます。
- 不必要な再審査を防止し、TQS委員会とプロジェクトチーム双方のリソースを節約することができます。
事前検討はプロジェクトチームの責任の下で実施されます。プロジェクトリードが事前検討の総括責任を負い、開発チームが実際の点検作業を遂行します。事前検討の所要期間は、プロジェクトの規模と規格充足レベルに応じて1〜2週間です。
31.2.2. 自主点検の実施
自主点検は、TQS認証チェックリスト（第32章）を基準に、プロジェクトの各項目別の充足状況を確認する作業です。自主点検は、自動化ツールを活用した定量的検証と手動確認を併用して実施します。
31.2.2.1. チェックリストに基づく点検
プロジェクトチームは、TQS認証チェックリスト（第32章）のすべての項目について充足状況を確認しなければなりません。各項目について以下の情報を記録します。
| 記録項目 | 説明 |
|---|---|
| 項目番号 | チェックリスト項目の固有番号 |
| 充足状況 | 充足 / 部分充足 / 未充足 |
| 根拠資料 | 充足を証明するスクリーンショット、設定ファイルパス、リンク |
| 備考 | 部分充足または未充足の場合の理由および補完計画 |
チェックリスト点検時に、項目の必須/推奨区分を明確に認識しなければなりません。必須項目は100%充足しなければ認証を取得することができず、推奨項目の充足率は認証等級（基本/優秀/最優秀）に影響を与えます。
31.2.2.2. 自動化ツールの実行
自主点検の定量的項目は、自動化ツールを実行して検証します。以下のツールの実行結果を収集し記録しなければなりません。
| ツール | 検証対象 | 実行コマンド | 基準 |
|---|---|---|---|
| Spotless | バックエンドコードフォーマッティング | mvn spotless:check | 違反0件 |
| ESLint | フロントエンドリント | npx eslint . | エラー0件 |
| Prettier | フロントエンドフォーマッティング | npx prettier --check . | 違反0件 |
| JaCoCo | バックエンドテストカバレッジ | mvn test jacoco:report | ライン80%、ブランチ70% |
| Vitest | フロントエンドテストカバレッジ | npx vitest run --coverage | ライン80%、ブランチ70% |
| Lighthouse | フロントエンド性能/アクセシビリティ | Chrome DevToolsまたはCLI | 性能90点以上 |
| OWASP Dependency-Check | 依存関係セキュリティ脆弱性 | mvn dependency-check:check | CVSS 7以上0件 |
自動化ツールの実行結果は、正式審査時に提出する成果物の基礎資料となります。そのため、実行結果をファイルとして保存し、実行日時と環境情報を併せて記録することを推奨します。
31.2.2.3. 未充足項目の識別
自主点検の結果、未充足または部分充足に分類された項目を別途リスト化します。未充足項目リストには以下の情報を含めなければなりません。
- 項目番号および項目名
- 必須/推奨区分
- 現在の状態（部分充足の場合は充足率または現況を記述）
- 未充足理由
- 想定補完難易度（高/中/低）
未充足項目リストは、Gap分析と補完計画策定のインプットとして活用されます。
31.2.3. Gap分析
Gap分析は、プロジェクトの現状とTQS要求事項との差異を体系的に分析するプロセスです。自主点検で識別された未充足項目に基づいて、Gapの規模、原因、影響度を分析します。
31.2.3.1. 比較マトリクスの作成
Gap分析の第一段階は、現状とTQS要求事項の比較マトリクスを作成することです。比較マトリクスは各チェックリスト領域別に作成し、項目別の充足状態を視覚的に把握できるよう構成します。
充足状態は以下の3種類に分類します。
| 充足状態 | 定義 | 対応 |
|---|---|---|
| 充足 | TQS要求事項を完全に満たしている状態 | 追加対応不要 |
| 部分充足 | TQS要求事項の一部のみ満たしている状態 | 未充足部分の補完が必要 |
| 未充足 | TQS要求事項をまったく満たしていない状態 | 全面的な補完または新規実装が必要 |
31.2.3.2. Gap分析結果の例示
以下はGap分析結果テーブルの作成例です。プロジェクトチームはこの形式を参考にして、実際のプロジェクトのGap分析結果を作成します。
| 領域 | 項目 | TQS要求事項 | 現在の状態 | 充足状態 | Gapの説明 |
|---|---|---|---|---|---|
| コードコンベンション | Spotless適用 | ビルド時にフォーマット検証を自動化 | spotless-maven-plugin設定完了 | 充足 | — |
| テスト | ラインカバレッジ | 80%以上 | 72% | 部分充足 | 8%p不足、サービス層テスト強化が必要 |
| セキュリティ | OWASPスキャン | CVSS 7以上の脆弱性0件 | 未適用 | 未充足 | プラグイン設定および初回スキャンが必要 |
| CI/CD | セキュリティスキャン段階 | パイプラインにセキュリティスキャンを含む | リント/テスト/ビルドのみ構成 | 未充足 | CircleCI設定にセキュリティスキャン段階の追加が必要 |
| フロントエンド | Lighthouseスコア | 性能90点以上 | 85点 | 部分充足 | 画像最適化、コードスプリッティング強化が必要 |
Gap分析の結果で、必須項目の未充足件数が全必須項目の10%を超える場合、補完作業にかなりの時間が必要となる可能性があるため、審査スケジュールを慎重に策定しなければなりません。
31.2.4. 補完計画の策定
Gap分析の結果に基づいて、未充足項目に対する具体的な補完計画を策定します。補完計画はプロジェクトリードが総括し、開発チームと協議して実現可能なスケジュールで策定しなければなりません。
31.2.4.1. 優先順位の決定
未充足項目の補完優先順位は、以下の基準に従って決定します。
| 優先順位 | 基準 | 例 |
|---|---|---|
| 1位 | 必須項目のうちセキュリティ関連 | Spring Security設定、SQLパラメータバインディング、シークレット管理 |
| 2位 | 必須項目のうちコード品質関連 | フォーマッター適用、命名規則、パッケージ構造 |
| 3位 | 必須項目のうちテスト/CI関連 | テストカバレッジ、CI/CDパイプライン構成 |
| 4位 | 推奨項目（優秀/最優秀等級を目標とする場合） | OWASPスキャン、Lighthouse最適化、キーボードナビゲーション |
必須項目は必ず補完しなければならず、推奨項目は目標認証等級に応じて補完の要否を決定します。基本認証のみを目標とする場合、推奨項目の補完は任意です。
31.2.4.2. 補完作業スケジュールの策定
補完計画には、各未充足項目に対して以下の情報を含めなければなりません。
- 補完作業内容（具体的な作業範囲を記述）
- 担当者（作業を遂行する開発者またはチーム）
- 開始日および完了予定日
- 依存関係（他の補完作業との前後関係）
- 検証方法（補完完了をどのように確認するか）
補完作業スケジュールは、プロジェクトの既存開発スケジュールと並行可能なレベルで策定しなければなりません。認証準備のためにリリーススケジュールが遅延する状況は最小限に抑えなければなりません。
31.2.4.3. 想定所要期間の算定
補完作業の想定所要期間は、未充足項目の規模と難易度に応じて異なります。以下は、主要な補完作業タイプ別の想定所要期間です。
| 補完作業タイプ | 想定所要期間 | 備考 |
|---|---|---|
| フォーマッター/リンター設定適用 | 1〜2日 | ツール設定後に一括適用可能 |
| 命名規則リファクタリング | 2〜5日 | プロジェクト規模に比例 |
| テストカバレッジ強化 | 3〜7日 | 不足分に比例 |
| CI/CDパイプライン構成 | 1〜3日 | 既存パイプラインの有無により異なる |
| セキュリティ設定適用 | 2〜5日 | 項目数と複雑度により異なる |
| プロジェクト構造リファクタリング | 3〜10日 | プロジェクト規模と現状に比例 |
31.2.5. 事前コンサルティング
プロジェクトチームは、事前検討の過程でTQS委員会に非公式の事前コンサルティングを依頼することができます。事前コンサルティングは、規格の解釈が不明確な場合や、適用方法に関するアドバイスが必要な場合に活用します。
31.2.5.1. コンサルティングの依頼方法
事前コンサルティングは、TQS委員会にメールまたは社内コミュニケーションツールを通じて非公式に依頼します。依頼時には以下の情報を含めなければなりません。
- プロジェクト名および担当者
- 質問項目（チェックリスト番号または規格条項）
- 具体的な質問内容
- 現在の適用状態（可能な場合はコードまたは設定例を含む）
事前コンサルティングの依頼は審査申請とは独立して行われ、事前コンサルティングを受けなくても審査申請には影響しません。
31.2.5.2. コンサルティングの範囲
事前コンサルティングで取り扱う範囲は以下のとおりです。
- TQS規格の特定条項に対する解釈に関する質問
- 特定の技術スタックにおける規格適用方法のアドバイス
- チェックリスト項目の充足基準の確認
- 自主点検結果に対する事前意見の提供
事前コンサルティングで取り扱わない範囲は以下のとおりです。
- 具体的なコード作成の代行
- 事前審査判定（合格/不合格の予測）
- 正式審査における判定結果の保証
31.2.5.3. コンサルティング結果の効力
事前コンサルティングで提供された意見は参考事項であり、正式審査の結果に直接的な影響を及ぼしません。事前コンサルティングで「問題ない」という意見を受けた場合でも、正式審査で当該項目が未充足と判定される場合があります。これは、事前コンサルティングが非公式な性格を持ち、正式審査ではより厳格な基準が適用される可能性があるためです。
ただし、事前コンサルティングで提供されたアドバイスを誠実に履行した場合、正式審査での合格可能性を高めることができます。プロジェクトチームは事前コンサルティングの内容を記録し、当該アドバイスに基づく措置結果を成果物に含めることを推奨します。