準備ロードマップ
TQS認証を初めて準備するプロジェクトチームのための段階別準備計画を定義します。本章は8週間標準準備計画、優先順位マトリクス、短縮準備ガイドを含みます。
33.1.1. 8週間準備計画
TQS認証の準備は、8週間単位の体系的な計画に従うことを推奨します。各週の主要活動と成果物は以下の通りです。
| 週 | 主要活動 | 成果物 |
|---|---|---|
| 1週目 | 現状分析およびGap診断 | 自己点検チェックリスト、現状分析レポート |
| 2週目 | 開発環境の標準化 | .editorconfig、.vscode/settings.json、フォーマッタ設定ファイル |
| 3週目 | コードコンベンション適用 | Spotless設定、ESLint/Prettier設定ファイル |
| 4週目 | テストインフラ構築 | JUnit 5 + JaCoCo設定、Vitest設定、カバレッジレポート |
| 5週目 | CI/CDパイプライン構成 | CircleCI設定ファイル、パイプライン実行ログ |
| 6週目 | セキュリティ点検 | Spring Security設定、OWASPスキャン結果、シークレット管理設定 |
| 7週目 | フロントエンド品質強化 | Lighthouseレポート、アクセシビリティ点検結果、バンドル分析結果 |
| 8週目 | 最終点検および審査申請 | 全体チェックリスト最終版、審査申請書 |
33.1.1.1. 1週目：現状分析およびGap診断
1週目の目標は、プロジェクトの現状を客観的に把握し、TQS規格とのGapを特定することです。
実施すべき活動は以下の通りです。
- TQS認証チェックリスト（32章）を基準に、全項目の充足状況を確認します。
- 各項目を充足、部分充足、未充足に分類します。
- 未充足項目について、補完の難易度と所要期間を推定します。
- Gap診断結果に基づき、残り7週間の詳細スケジュールを調整します。
この段階で未充足項目が全体の30%を超える場合、8週間計画では不足する可能性があるため、スケジュールの延長を検討しなければなりません。
33.1.1.2. 2週目：開発環境の標準化
開発環境の標準化は、チーム全体が同一の環境で開発できるよう設定を統一する作業です。
.editorconfigファイルをプロジェクトルートに作成し、インデント、文字エンコーディング、行末処理のルールを定義します。.vscode/settings.jsonに保存時の自動フォーマット、リント自動実行設定を追加します。- バックエンドプロジェクトにGoogle Java Formatを適用するため、
spotless-maven-pluginをpom.xmlに追加します。 - フロントエンドプロジェクトにESLint Flat ConfigとPrettierを設定します。
.gitignoreファイルを点検し、IDE設定ファイル、ビルド成果物、環境変数ファイルが適切に除外されているか確認します。
33.1.1.3. 3週目：コードコンベンション適用
既存のソースコードにTQS規格が要求するコードコンベンションを適用します。
- バックエンド：
mvn spotless:applyコマンドで全JavaソースコードにGoogle Java Formatを一括適用します。 - フロントエンド：
yarn lint --fixおよびyarn formatコマンドでESLintとPrettierのルールを一括適用します。 - ネーミング規則（クラス、変数、メソッド、パッケージ）を点検し、違反事項を修正します。
System.out.printlnの使用をロギングフレームワーク（SLF4J + Logback）に置き換えます。- TypeScriptで
any型の使用を除去し、明示的な型を定義します。 - VueコンポーネントがComposition APIを使用しているか確認し、Options API使用時は移行します。
33.1.1.4. 4週目：テストインフラ構築
テスト自動化環境を構築し、カバレッジ基準を達成します。
- バックエンド：JUnit 5ベースの単体テストを作成し、JaCoCoでカバレッジを測定します。
- フロントエンド：Vitestベースの単体テストを作成し、カバレッジレポートを生成します。
- カバレッジ目標：ラインカバレッジ80%以上、ブランチカバレッジ70%以上を達成しなければなりません。
- コアビジネスロジック、ユーティリティ関数、API呼び出しロジックを優先的にテストします。
- テストが不要なコード（設定クラス、DTOなど）はカバレッジ測定から除外するよう設定します。
33.1.1.5. 5週目：CI/CDパイプライン構成
CircleCIベースのCI/CDパイプラインを構成します。
.circleci/config.ymlファイルを作成し、パイプラインを定義します。- パイプラインステージ：リント検査 → 単体テスト → カバレッジ検証 → ビルド → セキュリティスキャンの順序で構成します。
- リント検査失敗時に後続ステージが実行されないよう設定します。
- カバレッジ閾値未達時にビルドが失敗するよう設定します。
- ビルド結果をチームに通知するアラートを設定します。
33.1.1.6. 6週目：セキュリティ点検
セキュリティ関連のTQS規格項目を点検し、補完します。
- Spring Security設定を検証します。RBAC (Role-Based Access Control) ベースのアクセス制御が適用されているか確認します。
- OWASP Dependency-Checkを実行し、依存関係のセキュリティ脆弱性をスキャンします。CVSS 7.0以上の脆弱性が0件でなければなりません。
- ソースコード内のシークレット（APIキー、パスワード、トークン）のハードコーディング有無を確認します。シークレットは環境変数またはシークレットマネージャーを通じて管理しなければなりません。
- データ暗号化設定（At-Rest、In-Transit）を確認します。
- 入力値検証ロジックが適切に実装されているか点検します。
33.1.1.7. 7週目：フロントエンド品質強化
フロントエンドのパフォーマンス、アクセシビリティ、バンドル最適化を点検します。
- Lighthouseを実行し、パフォーマンススコア90点以上、アクセシビリティスコア90点以上を達成します。
- 画像最適化（フォーマット変換、遅延読み込み）を適用します。
- バンドルサイズを分析し、コードスプリッティングを適用します。
- WCAG (Web Content Accessibility Guidelines) 2.1 AAレベルのアクセシビリティを満たしているか確認します。
- ARIA (Accessible Rich Internet Applications) 属性が適切に使用されているか点検します。
33.1.1.8. 8週目：最終点検および審査申請
全体チェックリストを最終確認し、審査を申請します。
- TQS認証チェックリスト（32章）の全項目を再確認します。
- 自動化検証ツールを全体実行し、結果を収集します。
- 成果物（設定ファイル、テストレポート、CIログ、セキュリティスキャン結果）を整理します。
- 審査申請書を作成し、TQS委員会に提出します。
- 提出前にチーム内部で最終レビューを実施し、漏れがないか確認します。
33.1.2. 優先順位マトリクス
TQS認証準備項目は、緊急性と難易度に応じて4つの領域に分類できます。このマトリクスを活用すれば、限られた時間内に効率的に準備を進めることができます。
33.1.2.1. 即時適用（緊急性 高 + 難易度 低）
直ちに実行でき、認証合格に直接的な影響を与える項目です。
| 項目 | 予想所要時間 | 備考 |
|---|---|---|
.editorconfig設定 | 30分 | プロジェクトルートに作成 |
.gitignore点検および補完 | 30分 | 漏れ項目の追加 |
| フォーマッタ適用（Spotless、Prettier） | 1〜2時間 | プラグイン設定 + 一括適用 |
System.out.println除去 | 1〜2時間 | ロギングフレームワークへの置き換え |
| 環境変数ファイル分離 | 1時間 | ハードコーディングされた設定値の分離 |
33.1.2.2. 計画的適用（緊急性 高 + 難易度 高）
認証合格に必須ですが、十分な時間と計画が必要な項目です。
| 項目 | 予想所要期間 | 備考 |
|---|---|---|
| テストカバレッジ達成（80%/70%） | 1〜2週間 | コアロジック優先で作成 |
| CI/CDパイプライン構成 | 3〜5日 | CircleCI設定 |
| セキュリティ脆弱性の解消 | 3〜5日 | OWASPスキャン後の対応 |
| Vue Options API → Composition API移行 | 1〜2週間 | コンポーネント規模により異なる |
33.1.2.3. 段階的適用（緊急性 低 + 難易度 低）
認証合格に必須ではありませんが、優秀等級以上を目指す場合に適用すべき項目です。
| 項目 | 予想所要時間 | 備考 |
|---|---|---|
| コードドキュメント化（JSDoc、JavaDoc） | 2〜3日 | 公開API優先 |
| リントルールの細分化 | 1〜2日 | プロジェクト固有ルールの追加 |
| エラーメッセージの標準化 | 1日 | 標準レスポンス形式の適用 |
| ロギングレベルの整理 | 1日 | DEBUG/INFO/WARN/ERROR基準の策定 |
33.1.2.4. 長期課題（緊急性 低 + 難易度 高）
認証取得後に長期的に改善していく項目です。
| 項目 | 予想所要期間 | 備考 |
|---|---|---|
| アーキテクチャ全体のリファクタリング | 数週間〜数ヶ月 | 構造的改善 |
| レガシーコードの全面書き換え | 数週間〜数ヶ月 | 段階的アプローチが必要 |
| 統合テスト自動化 | 2〜4週間 | E2Eテストを含む |
| パフォーマンス最適化の高度化 | 2〜4週間 | プロファイリングベースの改善 |
33.1.3. 短縮準備ガイド
すでに一部のTQS標準を適用中のプロジェクトのための4週間短縮準備計画です。本ガイドはGap診断の結果、未充足項目が全体の20%以下のプロジェクトに適用することができます。
33.1.3.1. 4週間短縮計画
| 週 | 主要活動 | 備考 |
|---|---|---|
| 1週目 | Gap診断 + 即時適用項目の一括処理 | フォーマッタ、設定ファイル、.gitignoreなど |
| 2週目 | テストカバレッジ補完 + CI/CD点検 | 未達領域の集中補完 |
| 3週目 | セキュリティ点検 + フロントエンド品質検証 | OWASPスキャン、Lighthouse実行 |
| 4週目 | 最終点検 + 審査申請 | 全体チェックリストの再確認 |
33.1.3.2. 短縮準備の資格条件
短縮準備計画を適用するには、以下の条件を満たさなければなりません。
- フォーマッタ（Spotless、ESLint、Prettier）がすでにプロジェクトに設定されていなければなりません。
- CI/CDパイプラインが基本的に稼働していなければなりません。
- テストカバレッジがライン60%以上でなければなりません（目標80%まで補完可能なレベル）。
- セキュリティ関連の重大な欠陥（シークレットのハードコーディング、CVSS 9.0以上の脆弱性）がないことが必要です。
33.1.3.3. 短縮準備時の注意事項
短縮準備計画は時間を節約できますが、以下の事項に注意しなければなりません。
- Gap診断ステップを省略または縮小してはなりません。未充足項目の正確な把握が短縮準備の前提条件です。
- テストカバレッジ補完時、単に数値を上げるための意味のないテスト作成は避けなければなりません。TQS技術審査ではテスト品質も併せて検証します。
- セキュリティ点検は短縮の対象ではありません。セキュリティ項目は必ず全体を点検しなければなりません。
- 予想より未充足項目が多い場合、直ちに8週間標準計画に切り替えることを推奨します。