認証対象および範囲
28.2.1. 適用対象
TQS 認証はティエニピア内部で開発、運用、デプロイされるすべての技術資産を適用対象とします。プロジェクトの類型と規模に応じて適用される認証カテゴリと検証項目が異なります。
28.2.1.1. プロジェクト類型別適用対象
TQS 認証の適用対象は以下のように分類されます。
| プロジェクト類型 | 説明 | 適用カテゴリ | 例 |
|---|---|---|---|
| 企業向けアプリケーション | 社内または顧客に提供するアプリケーション | TQS-S/W | Flowinグループウェア、プロジェクト管理ツール |
| バックエンドサービス | REST API、マイクロサービス、バッチ処理サービス | TQS-S/W | 認証サービス、通知サービス、精算サービス |
| 内部ライブラリ | 社内共通モジュール、ユーティリティライブラリ | TQS-S/W | セキュリティ文書生成モジュール、共通ロギングライブラリ |
| APIサービス | 外部連携API、公開API | TQS-S/W | パートナー連携API、データ照会API |
| 社内ツール | 開発生産性ツール、管理者ツール | TQS-S/W | デプロイ自動化ツール、モニタリングダッシュボード |
| サーバーおよびネットワーク機器 | 社内ネットワークに接続される物理/仮想サーバー | TQS-H/W | 社内サーバー、ネットワークスイッチ、ファイアウォール機器 |
| インフラ環境 | IDC、クラウド、ストリーミングアーキテクチャ | TQS-Infra | プロダクションクラスタ、CDN構成、ストレージ環境 |
28.2.1.2. 適用基準
すべてのプロジェクトが同一レベルの認証を要求されるわけではありません。適用基準はプロジェクトの重要度と影響範囲に応じて決定されます。
- 必須適用対象: プロダクション環境にデプロイされるすべてのプロジェクトはTQS 認証を取得しなければなりません。
- 推奨適用対象: ステージング環境までデプロイされる内部ツールはTQS 認証を取得することを推奨します。
- 選択適用対象: ローカル開発環境でのみ使用されるユーティリティスクリプトはTQS 認証を選択的に適用することができます。
プロダクションにデプロイされるプロジェクトがTQS 認証なしに運用されることは許容されません。新規プロジェクトは初回プロダクションデプロイ前に認証を取得しなければならず、既存プロジェクトは猶予期間内に認証を完了しなければなりません。
28.2.2. 認証単位
TQS 認証は プロジェクト名 + バージョン 単位で発行されます。同一プロジェクトであってもバージョンが異なれば別の認証として管理します。これにより特定バージョンの品質状態を正確に追跡することができます。
28.2.2.1. 認証識別体系
認証書には以下の情報が明示されます。
| 項目 | 説明 | 例 |
|---|---|---|
| プロジェクト名 | 公式プロジェクト名称 | Flowin Groupware |
| バージョン | Semantic Versioning基準のバージョン | v2.1.0 |
| カテゴリ | TQS 認証カテゴリ | TQS-S/W |
| 等級 | 認証等級 | 優秀認証 |
| 発行日 | 認証発行日 | 2026-03-01 |
| 有効期間 | 次のメジャーバージョンリリース時まで | v3.0.0リリース時に満了 |
| 認証番号 | 固有認証識別番号 | TQS-SW-2026-001 |
28.2.2.2. バージョン基準
認証の有効範囲はSemantic Versioning体系に従います。
- メジャーバージョン変更 (v1.x.x -> v2.x.x): 全体再審査が必要です。既存の認証は満了します。
- マイナーバージョン変更 (v2.1.x -> v2.2.x): 再審査なしで既存の認証が維持されます。ただし、CI/CDパイプラインの通過を確認しなければなりません。
- パッチバージョン変更 (v2.1.1 -> v2.1.2): 再審査なしで既存の認証が維持されます。CIの通過のみ確認します。
28.2.2.3. マルチモジュールプロジェクト
1つのプロジェクトが複数のモジュールで構成されている場合、認証単位の処理方式は以下の通りです。
- 単一リポジトリ（Monorepo）: プロジェクト全体を1つの認証単位として処理します。すべてのモジュールがTQS基準を充足しなければなりません。
- 複数リポジトリ（Polyrepo）: 各リポジトリを個別の認証単位として処理します。リポジトリごとに独立して認証を申請します。
- 共有ライブラリ: 複数のプロジェクトで使用される共有ライブラリは独立した認証単位として管理します。共有ライブラリが認証を取得すれば、当該ライブラリを使用するプロジェクトの審査時に関連項目を免除することができます。
マルチモジュールプロジェクトで一部のモジュールのみ変更された場合でも、認証単位がプロジェクト全体である場合は全体基準で審査を行います。ただし、変更されていないモジュールは以前の審査結果を参照して簡素化審査を適用することができます。
28.2.3. 部分認証と全体認証
TQS 認証は単一カテゴリ認証（部分認証）と複数カテゴリ認証（全体認証）の両方を支援します。プロジェクトの性格に応じて適切な認証範囲を選択することができます。
28.2.3.1. 部分認証
部分認証はTQS-S/W、TQS-H/W、TQS-Infraのうち1つのカテゴリのみを単独で認証を受ける方式です。
- ソフトウェアのみを開発するプロジェクトはTQS-S/W単独認証を申請することができます。
- インフラ構築のみを担当するプロジェクトはTQS-Infra単独認証を申請することができます。
- 部分認証を取得したプロジェクトは当該カテゴリのTQSマークのみ使用することができます。
部分認証はプロジェクトの技術的範囲が特定カテゴリに限定される場合に適しています。大部分のプロジェクトはTQS-S/W部分認証から開始します。
28.2.3.2. 全体認証
全体認証はTQS-S/W、TQS-H/W、TQS-Infraの3つのカテゴリすべての認証を受ける方式です。
- ソフトウェア、ハードウェア、インフラをすべて含む総合プロジェクトに適用します。
- 全体認証を取得すると
TQS Full Certifiedマークを使用することができます。 - 全体認証は各カテゴリの審査を順次的または並列的に行うことができます。
全体認証時、各カテゴリの必須項目をすべて100%充足しなければなりません。1つのカテゴリでも基準未達の場合、全体認証は発行されず、充足したカテゴリに対してのみ部分認証を発行します。
28.2.3.3. 認証拡張
部分認証を保有するプロジェクトが他のカテゴリの認証を追加で取得して全体認証に拡張することができます。
- 既存の部分認証は有効期間内になければなりません。
- 追加カテゴリに対する審査のみを別途行います。
- すべてのカテゴリの認証が完了すれば全体認証として統合発行します。
28.2.4. 認証除外対象
以下に該当するプロジェクトまたは成果物はTQS 認証対象から除外されます。ただし、除外対象であっても TQS規格を参考にして品質を管理することを推奨します。
28.2.4.1. 除外対象一覧
| 除外対象 | 理由 | 備考 |
|---|---|---|
| PoC (Proof of Concept) | 技術検証目的の一時的プロジェクト | 正式プロジェクト転換時に認証必要 |
| プロトタイプ | 初期コンセプト検証用の成果物 | プロダクション転換時に認証必要 |
| 外部ベンダー提供ソリューション | ティエニピア自社開発物ではない場合 | カスタマイズ部分は認証対象 |
| レガシーシステム | 既存稼働中の旧システム | マイグレーション時に認証必要 |
| 一回性スクリプト | データマイグレーション等の一回性作業 | 反復使用時は認証対象に転換 |
| 教育/学習用プロジェクト | 社内教育目的のサンプルプロジェクト | プロダクションデプロイ不可 |
28.2.4.2. 除外対象の転換
除外対象として分類されたプロジェクトが以下の条件に該当する場合、認証対象に転換されます。
- PoC/プロトタイプ: 正式プロジェクトに昇格されてプロダクションデプロイが決定された場合、デプロイ前にTQS 認証を取得しなければなりません。
- 外部ベンダーソリューション: 内部でカスタマイズコードを追加した場合、カスタマイズ部分に対してTQS-S/W認証を適用しなければなりません。
- レガシーシステム: マイグレーションを実施する場合、マイグレーション結果物はTQS 認証対象です。マイグレーション完了後6ヶ月以内に認証を取得しなければなりません。
- 一回性スクリプト: 同一スクリプトを3回以上反復使用する場合、または他のプロジェクトで再利用する場合は認証対象に転換されます。
28.2.4.3. 除外対象管理
認証除外対象プロジェクトも社内プロジェクト管理システムに登録し、除外理由を明示しなければなりません。TQS 委員会は四半期ごとに除外対象一覧を検討して、認証対象に転換すべきプロジェクトがあるか点検します。除外理由が消滅したプロジェクトは直ちに認証対象として再分類します。