Skip to content

認証の目的

29.1.1. 品質保証

TQS 認証の第一の目的は、ティエニピアのエコシステム内で開発、運用される技術資産の品質を公式に検証し保証することです。品質保証はコード、アーキテクチャ、テスト、セキュリティの4つの軸を中心に行われます。

29.1.1.1. コード品質検証

TQS 認証はソースコードレベルでの品質を直接検証します。これは従来のプロセス中心の認証体系とTQSを区別する核心的な差別化ポイントです。

  • フォーマッタ適用検証: Google Java Format、Prettier等の規格で指定されたフォーマッタが実際に適用されているか確認します。フォーマッタ未適用のコードはCIパイプラインでビルド失敗として処理されなければなりません。
  • ネーミング規則遵守: クラス、メソッド、変数、パッケージのネーミングがTQS規格の命名規則に従っているか検証します。
  • コード構造標準化: パッケージ構造、ディレクトリ構造、コンポーネント設計が規格に適合しているか確認します。

コード品質検証を通じて「誰が作成しても一貫した品質のコード」を保証します。これはコードレビューの効率性を高め、引き継ぎコストを削減し、長期的な保守性を確保する基盤となります。

29.1.1.2. アーキテクチャ検証

プロジェクトの技術アーキテクチャが拡張性、保守性、セキュリティの観点から適切であるか検証します。

  • レイヤー構造(Controller - Service - Repository)が正しく分離されているか確認します。
  • 依存関係の方向が単方向に維持されているか検証します。
  • 設定管理が環境別に分離されているか確認します。
  • 横断的関心事(ロギング、例外処理、認証)が適切にモジュール化されているか検証します。

29.1.1.3. テスト検証

自動化されたテストの存在有無と品質を検証します。テストのないコードは品質を保証することができないため、TQS 認証においてテストは必須項目です。

  • ラインカバレッジ80%以上、ブランチカバレッジ70%以上を充足しなければなりません。
  • テストがGiven-When-Thenパターンに従って構造的に作成されているか確認します。
  • CIパイプラインでテストが自動的に実行されるか検証します。

29.1.1.4. セキュリティ検証

セキュリティは品質の核心構成要素です。TQS 認証はセキュリティ要求事項の実際の実装有無をコードレベルで検証します。

  • データ暗号化(At-Rest、In-Transit)が適用されているか確認します。
  • 入力検証(Bean Validation、XSS防御、SQL Injection防御)が実装されているか検証します。
  • 認証および権限制御(RBAC)が正しく適用されているか確認します。
  • 依存関係セキュリティスキャン(OWASP Dependency-Check)がCIに統合されているか検証します。

29.1.2. 標準化

TQS 認証の第二の目的は、チーム間で一貫した技術スタックとコーディングコンベンションを確立することです。標準化は開発生産性を高め、チーム間の協業を円滑にし、技術負債の発生を事前に防止します。

29.1.2.1. 技術スタック標準化

TQS規格はバックエンド、フロントエンド、インフラの各領域で使用すべき技術スタックを明確に定義します。

領域標準技術目的
バックエンドランタイムJava 21最新LTSバージョンに統一
バックエンドフレームワークSpring Boot 3.xエンタープライズ級標準フレームワーク
データアクセスjOOQタイプセーフSQLビルダーに統一
フロントエンドフレームワークVue 3 (Composition API)リアクティブUIフレームワーク統一
状態管理PiniaVueエコシステム標準の状態管理
ビルドツールMaven(バックエンド)、Vite(フロントエンド)ビルド環境の統一

技術スタックが標準化されれば、開発者が別のプロジェクトに移動しても同一の技術環境で作業することができます。これは学習コストを削減し、プロジェクト間のコード再利用性を高め、社内技術サポート体制を効率化します。

29.1.2.2. コーディングコンベンション標準化

コーディングコンベンションの標準化は、個人の好みや習慣に依存しない一貫したコードスタイルを保証します。

  • フォーマッタ設定をプロジェクトに含めて自動的に適用されるようにします。
  • リンター(ESLint)設定を通じてコード品質規則を強制します。
  • コミットメッセージ形式(Conventional Commits)を統一します。
  • PRテンプレートを標準化してコードレビューの一貫性を確保します。

コーディングコンベンションが標準化されれば、コードレビューでスタイルに関する議論がなくなり、レビュアーはロジックと設計に集中することができます。これはコードレビューの質を高め、レビュー所要時間を短縮します。


29.1.3. 相互運用性

TQS 認証の第三の目的は、社内ソリューション間の技術的互換性を保証することです。ティエニピアのサービスは独立して開発されても、相互連携が円滑でなければなりません。

29.1.3.1. API互換性

TQS規格はAPI設計標準を定義して、サービス間通信の一貫性を保証します。

  • すべてのAPIはRESTful規則に従います。URLネーミング、HTTPメソッドの使用、ステータスコードの返却規則が統一されます。
  • エラーレスポンス形式が標準化されており、クライアントはどのサービスのエラーも同一の方式で処理することができます。
  • 日付/時刻形式はISO 8601を使用してタイムゾーン関連のエラーを防止します。

29.1.3.2. データ互換性

サービス間のデータ交換時に形式と規則が統一されなければなりません。

  • データベース設計規則(テーブルネーミング、カラムタイプ)が標準化されます。
  • マイグレーションツール(Flyway)を統一してスキーマ管理方式を一元化します。
  • シリアライゼーション形式(JSON)と日付/数値フォーマットを規格で定義します。

29.1.3.3. インフラ互換性

TQS-Infra規格はインフラ環境の互換性を保証します。

  • デプロイ環境(local、dev、staging、prod)の構成が標準化されます。
  • ロギング形式とモニタリング指標が統一され、運用ツールを共有することができます。
  • ネットワーク通信規格(TLSバージョン、プロトコル)が統一されます。

相互運用性が確保されれば、新しいサービスを既存インフラに統合するコストが減少し、サービス間の障害伝播を予測し防止することができます。


29.1.4. 技術負債管理

TQS 認証の第四の目的は、体系的な基準を通じて技術負債の蓄積を防止することです。技術負債は時間の経過とともに複利で増加し、放置するとシステムの安定性と開発生産性を深刻に阻害します。

29.1.4.1. 技術負債の発生防止

TQS規格は技術負債が発生する前にこれを遮断する防御線の役割を果たします。

  • コード品質基準: フォーマッタ、リンター、ネーミング規則を強制して低品質コードの流入を防止します。
  • テストカバレッジ基準: 最低カバレッジ基準を設定してテストのないコードのデプロイを遮断します。
  • 依存関係管理: セキュリティ脆弱性のある依存関係の使用を禁止し、定期的な更新を義務化します。
  • CI/CD自動化: 手動ビルド/デプロイによるヒューマンエラーを防止します。

29.1.4.2. 既存技術負債の解消

TQS 認証を準備する過程自体が既存の技術負債を解消する機会となります。

  • 自己点検チェックリストを通じて技術負債項目を体系的に識別します。
  • 認証基準に合わせるためにフォーマッタ適用、テスト作成、セキュリティ設定の補完等の作業を行います。
  • 認証更新周期ごとに技術負債の再蓄積有無を点検します。

29.1.5. ビジネス価値

TQS 認証の第五の目的は、技術品質の向上を通じて実質的なビジネス価値を創出することです。技術品質はコスト削減、顧客信頼度、組織効率性に直接的な影響を与えます。

29.1.5.1. 顧客信頼度の向上

TQSマークが付与された製品は技術品質が公式に検証されたことを意味します。これは顧客に以下のような信頼を提供します。

  • コードレベルでセキュリティが検証された製品であることを保証します。
  • 一定レベル以上のテストカバレッジと安定性を備えていることを保証します。
  • 体系的な品質管理プロセスの下で運用されていることを保証します。

29.1.5.2. 保守コストの削減

標準化されたコードとアーキテクチャは保守コストを直接的に削減します。

  • 一貫したコードスタイルはコード理解に要する時間を短縮します。
  • 高いテストカバレッジは変更時の副作用(Side Effect)を迅速に発見させます。
  • 標準化された技術スタックはバグ修正と機能追加に必要な学習コストを削減します。

29.1.5.3. 引き継ぎの効率化

TQS 認証を取得したプロジェクトは引き継ぎが容易です。

  • 標準化されたプロジェクト構造のおかげで、新しい担当者がコードを迅速に把握することができます。
  • APIドキュメント(SpringDoc/Swagger UI)が必須で含まれているため、サービスの理解度が向上します。
  • 構成管理規則(Conventional Commits、PRテンプレート)が適用されており、変更履歴の追跡が容易です。
  • 同一の技術スタックを使用するため、技術適応期間なしに業務に投入することができます。

引き継ぎコストの削減は組織の人材運用の柔軟性を高め、プロジェクトの持続性を保証します。

TIENIPIA QUALIFIED STANDARD