認証成熟度モデル
29.4.1. 成熟度モデルの概要
TQS 成熟度モデルはCMMI (Capability Maturity Model Integration) の5段階成熟度概念に着想を得て、ティエニピアの技術環境に合わせて再設計した独自の成熟度フレームワークです。
CMMIが組織のプロセス成熟度の測定に焦点を当てているのに対し、TQS 成熟度モデルはプロジェクトの 技術実装品質成熟度 を測定します。コードコンベンション、テスト、セキュリティ、ビルド自動化等の実際の実装レベルに基づいてプロジェクトの現在位置を診断し、次の段階に進むための具体的な方向性を提示します。
TQS 成熟度モデルの5段階構造は以下の通りです。
| 段階 | 名称 | TQS 認証等級 | 核心特徴 |
|---|---|---|---|
| 第1段階 | 初期 | 未認証 | 標準未適用、個人別コーディングスタイル |
| 第2段階 | 管理 | 未認証（準備段階） | 基本コンベンション適用、フォーマッタ設定完了 |
| 第3段階 | 定義 | 基本認証 | TQS 必須項目100%充足 |
| 第4段階 | 定量 | 優秀認証 | 指標モニタリング、推奨項目80%以上 |
| 第5段階 | 最適化 | 最優秀認証 | 推奨項目100%、継続的改善プロセス |
各段階は前の段階の要件を包含します。すなわち、第3段階に該当するためには第1段階と第2段階の要件もすべて充足しなければなりません。段階を飛ばすことは許容されません。
成熟度モデルはTQS 認証と直接連携されます。第3段階以上に到達したプロジェクトのみがTQS 認証を申請することができ、第4段階と第5段階はそれぞれ優秀認証と最優秀認証に対応します。
29.4.2. 段階別定義
29.4.2.1. 第1段階：初期
第1段階は技術標準が適用されていない状態です。開発者個人の経験と好みに応じてコーディングスタイル、ツール選択、プロジェクト構造が決定されます。
| 領域 | 第1段階の状態 |
|---|---|
| コードスタイル | フォーマッタ未適用、個人別に異なるコーディングスタイル |
| プロジェクト構造 | 非標準ディレクトリ構造、一貫性のないパッケージ構成 |
| テスト | テスト未作成または非常に低いカバレッジ（30%未満） |
| 構成管理 | ブランチ戦略未定義、コミットメッセージ規則なし |
| CI/CD | パイプライン未構成または手動デプロイ |
| セキュリティ | 体系的なセキュリティ基準なし、シークレット管理不備 |
| ドキュメント化 | APIドキュメント未作成、プロジェクト説明文書の不在 |
第1段階にあるプロジェクトは技術負債が急速に蓄積され、チームメンバーの変更や要求事項の変更に脆弱です。大部分の新規プロジェクトは意図的に標準を適用しない限り第1段階から開始します。
29.4.2.2. 第2段階：管理
第2段階は基本的なコーディングコンベンションとツール設定が完了した状態です。標準化の第一歩を踏み出した段階であり、TQS 認証に向けた準備が始まります。
| 領域 | 第2段階の状態 |
|---|---|
| コードスタイル | フォーマッタ設定完了（Google Java Format、Prettier） |
| プロジェクト構造 | 基本的なレイヤー構造の適用（Controller-Service-Repository） |
| テスト | 主要機能に対するテストが存在（カバレッジ30~60%） |
| 構成管理 | ブランチ戦略の導入、基本コミット規則の適用 |
| CI/CD | 基本パイプライン構成（ビルド + テスト） |
| セキュリティ | 基本入力検証の適用、.gitignore設定 |
| ドキュメント化 | 基本プロジェクト説明文書が存在 |
第2段階はTQS 認証基準には未達ですが、標準化の基盤が整った状態です。この段階でTQS規格の必須項目を1つずつ充足していけば第3段階に移行することができます。
29.4.2.3. 第3段階：定義
第3段階はTQS規格の必須項目を100%充足した状態であり、TQS 基本認証に該当します。
| 領域 | 第3段階の状態 |
|---|---|
| コードスタイル | フォーマッタ + リンターの自動適用、CIでスタイル検証 |
| プロジェクト構造 | TQS 標準プロジェクト構造100%遵守 |
| テスト | ラインカバレッジ80%以上、ブランチカバレッジ70%以上 |
| 構成管理 | GitHub Flow、Conventional Commits、PRレビュー1名以上 |
| CI/CD | リント + テスト + ビルドパイプライン完備 |
| セキュリティ | TLS 1.2以上、BCryptハッシュ、Bean Validation、RBAC |
| ドキュメント化 | APIドキュメント自動生成（SpringDoc）、標準エラーレスポンス |
第3段階はTQS 認証の最低基準です。必須項目100%充足が要件であるため、1つの必須項目でも未充足であれば第3段階として認定されません。第3段階に到達したプロジェクトはTQS 基本認証を申請することができます。
29.4.2.4. 第4段階：定量
第4段階は必須項目の充足に加えて、推奨項目の80%以上を充足し、品質指標を定量的にモニタリングしている状態です。TQS 優秀認証に該当します。
| 領域 | 第4段階の状態 |
|---|---|
| コードスタイル | 第3段階充足 + コード複雑度/重複度のモニタリング |
| プロジェクト構造 | 第3段階充足 + 推奨設定項目80%以上適用 |
| テスト | ラインカバレッジ85%以上、統合テスト含む |
| 構成管理 | 第3段階充足 + Semantic Versioningの厳格適用 |
| CI/CD | 第3段階充足 + セキュリティスキャン段階含む |
| セキュリティ | 第3段階充足 + OWASP Dependency-Check適用 |
| ドキュメント化 | 第3段階充足 + アーキテクチャ文書、運用ガイド作成 |
| モニタリング | カバレッジ、ビルド成功率、欠陥密度の定期測定 |
第4段階の核心は 定量的管理 です。品質指標を数値で測定し、推移を分析し、目標対比達成率を管理します。感覚による判断ではなくデータに基づく品質管理が行われる段階です。
29.4.2.5. 第5段階：最適化
第5段階は必須項目と推奨項目をすべて100%充足し、継続的改善プロセスを運営している状態です。TQS 最優秀認証に該当します。
| 領域 | 第5段階の状態 |
|---|---|
| コードスタイル | 第4段階充足 + チーム独自のコンベンション改善活動 |
| プロジェクト構造 | すべての必須/推奨項目100%充足 |
| テスト | ラインカバレッジ90%以上、E2Eテスト含む |
| 構成管理 | 第4段階充足 + リリース自動化 |
| CI/CD | 第4段階充足 + 無停止デプロイ、カナリアデプロイ |
| セキュリティ | 第4段階充足 + 定期セキュリティ監査、ペネトレーションテスト |
| ドキュメント化 | 第4段階充足 + 技術決定記録（ADR） |
| 改善活動 | 定期振り返り、KPI基盤の改善目標設定および達成 |
第5段階の核心は 継続的改善 です。現在のレベルに満足せず、データに基づいて改善機会を探索し、新しい技術と方法論を積極的に導入します。第5段階のプロジェクトは社内技術優秀事例として登録され、他のプロジェクトのベンチマーク対象となります。
29.4.3. 自己診断ガイド
プロジェクトチームが現在の成熟度段階を自主的に診断できるよう、段階別の診断基準を提供します。
29.4.3.1. 診断基準テーブル
以下のテーブルの各項目に対して「充足」または「未充足」を判定します。当該段階のすべての項目を充足してはじめて当該段階として認定されます。
第1段階 -> 第2段階 移行診断
| 番号 | 診断項目 | 充足基準 |
|---|---|---|
| 1 | フォーマッタ設定ファイルがプロジェクトに含まれているか | .editorconfig またはフォーマッタ設定ファイルの存在 |
| 2 | 基本的なレイヤー構造が適用されているか | Controller-Service-Repositoryの分離 |
| 3 | テストコードが存在するか | 最低1つ以上のテストクラスの存在 |
| 4 | ブランチ戦略が定義されているか | main/featureブランチの区分使用 |
| 5 | CIパイプラインが構成されているか | ビルド自動化構成 |
| 6 | .gitignore ファイルが適切に設定されているか | ビルド成果物、IDE設定ファイルの除外 |
第2段階 -> 第3段階 移行診断
| 番号 | 診断項目 | 充足基準 |
|---|---|---|
| 1 | TQS 必須チェックリストをすべて通過しているか | 当該カテゴリの必須項目100%充足 |
| 2 | フォーマッタ/リンターがCIで自動検証されているか | CIパイプラインにリント段階を含む |
| 3 | テストカバレッジ基準を充足しているか | ライン80%、ブランチ70%以上 |
| 4 | Conventional Commitsを適用しているか | コミットメッセージ形式の遵守 |
| 5 | PRレビュープロセスが運営されているか | 最低1名レビュー後にマージ |
| 6 | セキュリティ基本項目が適用されているか | TLS、BCrypt、Bean Validation、RBAC |
| 7 | APIドキュメントが自動生成されているか | SpringDoc/Swagger UIの構成完了 |
第3段階 -> 第4段階 移行診断
| 番号 | 診断項目 | 充足基準 |
|---|---|---|
| 1 | 推奨項目充足率が80%以上であるか | 推奨チェックリスト80%以上 |
| 2 | コード品質指標を定期的に測定しているか | 月1回以上の測定 |
| 3 | テストカバレッジが85%以上であるか | ラインカバレッジ85%以上 |
| 4 | セキュリティスキャンがCIに統合されているか | OWASP Dependency-Checkまたは同等ツール |
| 5 | 品質指標の推移を追跡しているか | ダッシュボードまたはレポートの存在 |
第4段階 -> 第5段階 移行診断
| 番号 | 診断項目 | 充足基準 |
|---|---|---|
| 1 | すべての推奨項目を100%充足しているか | 推奨チェックリスト100% |
| 2 | 継続的改善プロセスが運営されているか | 定期振り返り、改善目標の策定 |
| 3 | テストカバレッジが90%以上であるか | ラインカバレッジ90%以上 |
| 4 | E2Eテストが含まれているか | E2Eテスト自動化 |
| 5 | 無停止デプロイが実装されているか | デプロイ時のサービス中断なし |
| 6 | KPI基盤の改善活動実績があるか | 最低2件以上の改善事例 |
29.4.3.2. 現在段階の判別方法
現在の成熟度段階を判別する方法は以下の通りです。
- 第1段階から開始して上位段階に順次的に診断します。
- 当該段階のすべての診断項目が「充足」であれば次の段階に移動します。
- 1つでも「未充足」の項目があれば前の段階が現在の段階です。
- 例えば、第2段階 -> 第3段階の診断で未充足項目がある場合、現在の段階は第2段階です。
自己診断はTQS 認証審査前に必ず行わなければなりません。自己診断の結果が第3段階未満のプロジェクトは認証審査を申請することができません。
29.4.4. 段階別移行ロードマップ
現在の段階から次の段階に上がるための核心活動を定義します。各移行には予想所要期間と優先度の高い活動を案内します。
29.4.4.1. 第1段階から第2段階へ
予想所要期間：2~4週
| 優先度 | 核心活動 | 詳細内容 |
|---|---|---|
| 1 | フォーマッタ設定 | Google Java Format（バックエンド）、Prettier（フロントエンド）の設定および適用 |
| 2 | プロジェクト構造整備 | 標準レイヤー構造（Controller-Service-Repository）へのパッケージ再構成 |
| 3 | CIパイプライン構成 | ビルド + テスト自動化の基本パイプライン構築 |
| 4 | ブランチ戦略導入 | GitHub Flow適用、main/featureブランチ運用開始 |
| 5 | 基本テスト作成 | コアビジネスロジックに対する単体テスト作成 |
| 6 | .gitignore 整備 | 標準 .gitignore ファイルの適用 |
第1段階から第2段階への移行は最も基本的ですが、以降のすべての段階の基盤となります。フォーマッタ設定から始めることを推奨します。フォーマッタの適用だけでもコードの一貫性が大幅に向上します。
29.4.4.2. 第2段階から第3段階へ
予想所要期間：4~8週
| 優先度 | 核心活動 | 詳細内容 |
|---|---|---|
| 1 | TQS チェックリスト自己点検 | 必須項目全体を点検し、未充足項目のリスト作成 |
| 2 | テストカバレッジ確保 | ライン80%、ブランチ70%達成のためのテスト作成 |
| 3 | CIパイプライン強化 | リント検証段階の追加、カバレッジレポートの生成 |
| 4 | セキュリティ基本項目の適用 | TLS、BCrypt、Bean Validation、Spring Security設定 |
| 5 | 構成管理規則の適用 | Conventional Commits、PRテンプレート、レビュープロセス |
| 6 | APIドキュメント自動化 | SpringDoc（Swagger UI）構成 |
| 7 | 未充足項目の補完 | 自己点検で発見された残りの必須項目の充足 |
第2段階から第3段階への移行が最も労力を要する区間です。テストカバレッジの確保に最も多くの時間を要するため、可能な限り早期に着手することを推奨します。
29.4.4.3. 第3段階から第4段階へ
予想所要期間：4~6週
| 優先度 | 核心活動 | 詳細内容 |
|---|---|---|
| 1 | 推奨項目の点検 | 推奨チェックリストを点検し、充足可能な項目を優先適用 |
| 2 | 品質指標モニタリング体系の構築 | カバレッジ、ビルド成功率、欠陥密度の自動測定環境 |
| 3 | セキュリティスキャンのCI統合 | OWASP Dependency-CheckをCIパイプラインに追加 |
| 4 | テストカバレッジの向上 | 85%以上達成、統合テストの追加 |
| 5 | 運用ドキュメントの作成 | アーキテクチャ文書、運用ガイド、障害対応マニュアル |
| 6 | 定期測定プロセスの策定 | 月別品質指標測定およびレポート体系 |
第3段階から第4段階への移行は「管理」から「測定」への転換です。品質を定量的に測定し追跡する体系を構築することが核心です。
29.4.4.4. 第4段階から第5段階へ
予想所要期間：6~12週
| 優先度 | 核心活動 | 詳細内容 |
|---|---|---|
| 1 | 残りの推奨項目の充足 | 未充足推奨項目100%達成 |
| 2 | 継続的改善プロセスの策定 | 定期振り返り、データ基盤の改善目標策定 |
| 3 | E2Eテストの構築 | 主要ユーザーシナリオに対するE2Eテスト自動化 |
| 4 | 無停止デプロイの実装 | ブルーグリーンまたはカナリアデプロイ戦略の適用 |
| 5 | セキュリティ強化 | 定期セキュリティ監査、ペネトレーションテストの実施 |
| 6 | 技術決定の記録 | ADR (Architecture Decision Records) 作成開始 |
| 7 | チーム改善活動 | 技術負債解消スプリント、コード品質改善活動の定例化 |
第4段階から第5段階への移行は最も長い時間を要する区間です。第5段階は単にチェックリストを充足することを超えて、継続的に改善する文化とプロセスを備えてはじめて達成することができます。この段階に到達したプロジェクトは組織内の技術標準の模範事例として認定されます。