ソフトウェア品質およびテスト

5.1 概要および目的

本章は、ProviderがCustomerの本番環境へ展開する前に、ProjectVIEW ERPの機能的正確性、性能の整合性、およびデータ信頼性をどのように保証するかを規定するソフトウェア品質およびテスト（SQT）フレームワークを定めるものです。

本書に定めるテストライフサイクルを正常に完了することなく、いかなるRelease、Update、またはUpgrade（Chapter 1, §1.4で定義される）もProductionに昇格させてはなりません。

Providerは、独自のテストフレームワーク上に構築されたカスタムAI Testing Agentsを活用し、各CustomerのProjectVIEW ERPインスタンスと直接連携する、差別化されたAI拡張テスト手法を運用しています。このアプローチにより、エンドツーエンドのデータフロー、実運用に即したユーザーインタラクションシナリオ、および包括的なデータ完全性検証を自動でシミュレーションできます。これらは、従来の手動QAやスクリプトベースQAを大きく上回る能力です。

欠陥防止に加え、SQTフレームワークには、AIエージェントの出力を分析して各Customerの導入環境内のワークフロー非効率、構成異常、データモデル改善の機会を特定する、プロアクティブなプロセス最適化アドバイザリーサービスが組み込まれています。これらの知見は、四半期サービスレビュー（§3.9）において実行可能な提案として提示されます。

5.2 範囲

SQTフレームワークは、本フレームワークの下でCustomer環境に展開されるすべてのソフトウェア成果物に適用され、以下を含みますが、これらに限定されません:

• (a) Release/Update（v11.xx） ― 3日間のアジャイルスプリントで提供される顧客固有の増分変更（§4.7）。
• (b) Upgrade（v11 → v12） ― おおむね年次で提供される製品全体のメジャーバージョン変更（§4.8）。
• (c) 構成変更 ― モジュールの有効化、ワークフローのカスタマイズ、レポートテンプレート、役割および権限の調整。
• (d) データ移行成果物 ― インポート変換、ETLスクリプト、スキーマ移行パッチ。
• (e) 連携インターフェース ― APIエンドポイント、Webhookハンドラ、サードパーティ接続アダプタ。
• (f) インフラ変更 ― データベースエンジン更新、ミドルウェアのバージョンアップグレード、TLS証明書のローテーション。

SQTフレームワークは、Customer UATの前に実施されるProvider側の内部テスト（§5.4～§5.7）と、正式な本番準備判定ゲートとなるCustomerのUniversal User Acceptance Testing（§5.8）の両方を対象とします。

5.3 AI拡張テストフレームワーク

5.3.1 アーキテクチャ概要

Providerは、3つの中核レイヤーからなる専用のAIテストプラットフォームを採用しています:

5.3.2 AI Testing Agents

各CustomerのProjectVIEW ERPインスタンスには1つ以上のカスタムAI Testing Agentが組み合わされ、Customerの以下に関するドメイン固有知識が設定されます:

• モジュール構成: 有効化されたモジュール（例: Project-Management、Contract-Management、Quality-Management）およびそれらの相互依存関係。
• 業務ルール: Customerの運用要件に固有の承認ワークフロー、エスカレーションマトリックス、通知ルール、計算式。
• データスキーマ: Customerのインスタンスで設定されたカスタムフィールド、ルックアップテーブル、コード値ドメイン、リレーショナル整合性制約。
• 役割分類: Customer組織に適用されるユーザー役割、権限セット、職務分掌ルール。
• 連携マップ: 接続されたサードパーティシステム（会計、人事、文書管理、BI）およびそれらのデータ交換契約。

AIエージェントは、ProviderのGitブランチ戦略（Master → Client → Working branches、§4.7.2）を用いてアプリケーションコードベースとともにバージョン管理され、テスト構成が検証対象ソフトウェアと歩調を合わせて進化することを保証します。

5.3.3 安全なAPI統合

安全なAPI統合レイヤーは、AI Testing AgentsとProjectVIEW ERP間の構造化された通信レイヤーを提供し、以下を可能にします:

• (a) API呼び出し: エージェントはProjectVIEWのREST/GraphQL APIを呼び出して、レコードの作成、読み取り、更新、削除を行い、UIに依存せず実ユーザーの取引をシミュレートします。
• (b) データベース検査: CustomerのDev/Sandboxデータベースへの読み取り専用アクセスにより、取引後のデータ完全性制約、参照整合性、計算フィールドを検証します。
• (c) UI自動化フック: 条件付きフィールド表示や動的フォーム検証など、業務ロジックがフロントエンドと密接に結合している場合、統合レイヤーはエージェントの指示をヘッドレスブラウザーインターフェース経由でルーティングし、ProjectVIEW UIを忠実にレンダリングします。
• (d) イベント捕捉: すべてのエージェントとERPのやり取りは、リクエストペイロード、レスポンスコード、タイミング指標、アサーション結果を含め、改変不可能な監査証跡に記録されます。

API接続は、現在のテストスイートに必要な権限のみを付与する、短寿命のスコープ付きAPIトークンで認証されます。トークンはテストセッションごとに自動でローテーションされ、本番環境に対して使用することはできません。

5.4 テスト方法論

5.4.1 テストレベル

Providerのテストライフサイクルは、進行段階の異なる5つのレベルで構成され、それぞれに明確な開始条件、終了条件、責任分担があります:

5.4.2 テスト環境

Provider側のすべてのテスト（L1～L4）は、Customer専用のDev/Sandbox環境（§2.5.1）でのみ実行されます。この環境は次の特徴を持ちます:

• 本番環境とアーキテクチャが同一 ― データベースエンジンのバージョン、ミドルウェアスタック、アプリケーションビルドが同じです。
• 匿名化された本番同等データを投入 ― 個人データを開示せずに、現実的なエッジケースを検証できる十分な量と多様性を備えます。
• 分離済み ― 本番へのネットワーク接続なし。DNS名前空間と認証レルムは別です。
• リセット可能 ― スナップショット／復元機能により、既知の正常状態を起点に再現可能なテスト実行が可能です。

本番稼働後、Dev/Sandbox環境はStaging役割（§2.5.1）へ移行し、上記の特性をすべて維持しつつ、CustomerのUAT環境としても機能します。

5.5 エンドツーエンドのデータフローシミュレーション

5.5.1 シミュレーションの目的

AIエージェントは、ProjectVIEW ERP内で業務取引のライフサイクル全体を通過する、現実的なエンドツーエンドのデータフローをシミュレーションします。目的は次のとおりです:

• (a) あるモジュールで作成されたデータが、下流のすべてのモジュールに正しく伝播、変換され、利用可能であることを検証する。
• (b) 承認経路、通知、計算を含む業務ルールが各段階で正しく作動することを確認する。
• (c) 同時実行されるユーザー操作によって、レースコンディション、デッドロック、またはデータ破損が発生しないことを検証する。
• (d) 取引レイテンシーおよびスループットを、定義されたSLOしきい値（§3.3）に照らして測定する。

5.5.2 シミュレーションシナリオ

Providerは、各シナリオを中核となるProjectVIEWの業務プロセスに対応付けた、パラメータ化されたシミュレーションシナリオのライブラリを保持しています。以下の表は代表的なシナリオを示すもので、完全なライブラリは有効化されたモジュールと構成に基づきCustomerごとに調整されます:

5.5.3 データ投入およびシナリオ実行

各シミュレーション実行前に、AIエージェントは自律的に次を行います:

• (a) 前提データの投入: テスト対象シナリオに必要なマスターレコード（プロジェクト、ベンダー、ユーザー、原価コード）を作成する。
• (b) 取引チェーンの実行: 安全なAPI統合レイヤーを介してProjectVIEW APIを呼び出し、実際のデータ値と時間間隔を伴って、業務プロセスの各ステップを正しい順序で実行する。
• (c) 各チェックポイントでアサート: 各ステップ後、エージェントはデータベースおよび／またはAPIを照会し、期待される状態変化（レコード作成／更新、ワークフロー進行、通知送信）が発生したことを確認する。
• (d) 証跡の取得: すべてのAPI呼び出し、データベースクエリ、アサーション結果、時間測定は、展開チケットに連携された改変不可能なテスト証跡リポジトリに記録される。
• (e) クリーンアップ: 完了後、エージェントはスナップショット／復元機能を用いて環境をベースラインに戻し、以降の実行にテスト成果物が残らないようにします。

5.6 ユーザーインタラクションのシミュレーション

5.6.1 目的

APIレベルのテスト（§5.5）がバックエンドロジックを検証するのに対し、ユーザーインタラクションのシミュレーションは、ProjectVIEWのユーザーインターフェースが人間ユーザーによる操作時に正しく動作することを検証します。AIエージェントは、以下を含む現実的なユーザー操作を再現します:

• 有効値、無効値、境界値を用いたフォーム入力完了。
  • 複数ステップのワークフローを通じたナビゲーション（ウィザード、承認チェーン、文書アップロードの流れ）。
  • 役割ベースのアクセス制御 ― エージェントは異なる役割／権限セットのユーザーを擬似し、UI要素が正しく表示／非表示、有効／無効になることを確認します。
  • レスポンシブ挙動 ― デスクトップおよびタブレットの表示サイズでテストし、レイアウトの整合性を確認します。
  • アクセシビリティ準拠 ― キーボード操作、ARIA属性、コントラスト比がWCAG 2.1 AA要件を満たすことを確認します。

5.6.2 इंटरラクションシナリオ

ユーザーインタラクションのシミュレーションは、ペルソナベースのテストスクリプトを中心に構成されます:

5.6.3 欠陥分類

ユーザー操作シミュレーション中に特定された欠陥は、運用インシデントと同じ重大度分類体系（§4.3）に基づいて分類されます。

5.7 データ完全性の検証

5.7.1 範囲

データ完全性は、各テスト実行後およびいかなるデプロイ推進の前にも、次の3つのレベルで検証されます。

5.7.2 完全性アサーション

AIエージェントは、各シミュレーションシナリオの終了時に、以下の完全性アサーションを実行します。

(a) 孤立レコードゼロ: すべての結合テーブルおよび子テーブルに対するSELECTクエリにより、存在しない親レコードを参照するレコードがないことを確認します。 (b) 残高検証: 財務モジュールでは、各原価センター内で総借方が総貸方と一致すること。予算の拘束額＋実績額＋残額＝予算総額であること。 (c) シーケンス整合性: 自動採番シーケンス（文書番号、取引ID）に欠番や重複がないこと。 (d) 同時実行安全性: 競合する更新を実行する並列エージェントスレッドが、適切な楽観ロック応答とともに、決定的かつ正しい結果を生成すること。 (e) 保存時暗号化: 機微情報フィールド（PII、財務データ）がデータベース内で暗号化されて保存されており、平文はアプリケーションの復号レイヤー経由でのみ利用可能であること。

5.7.3 データ完全性レポート

各テストサイクルでは、以下を含む自動化されたデータ完全性レポートが生成されます。

• 実行されたアサーション総数と合格／不合格件数。
  • テーブル、列、レコードID、期待値、実測値を含む詳細な失敗記録。
  • 直近10回のテストサイクルにおける完全性スコアを比較し、劣化傾向を特定するトレンド分析。
  • 実施した是正措置（自動修正済みか、開発へエスカレーション済みか）。

データ完全性レポートはデプロイチケットに添付され、Customerに提供されるUAT証跡パックに含められます。

5.8 包括的ユーザー受入テスト（UAT）

5.8.1 UATの前提条件

以下の前提条件が満たされるまで、ProviderはCustomerにUAT開始の案内をしてはなりません。

• (a) L1～L4のすべてのテストレベルが完了しており、未解決のP1/P2欠陥がないこと。
• (b) データ完全性レポート（§5.7.3）で、アサーションの100%合格率が示されていること。
• (c) CustomerのStaging環境が候補ビルドで更新されていること。
• (d) テストケーステンプレート、テストデータ、ユーザー認証情報が準備され、Customerが指定したUATリードに共有済みであること。

5.8.2 UATの実施

UATはCustomerが指定した担当者がStaging環境を使用して実施します。Providerは以下を行います。

• Customerの業務プロセスに整合した構造化テストケーステンプレートを提供すること。
  • 本番同等のシナリオを再現する現実的なテストデータを用意し、個人データは開示しないこと。
  • UAT期間中、欠陥の記録、トリアージ、解決のためにService Deskを利用可能にすること。
  • 共有のWhatsApp Businessグループ（§4.4）およびEmbedded Ticketing System（§4.1）を通じて、リアルタイム支援が可能な専任のProvider QA担当者をUAT窓口として割り当てること。

5.8.3 UATサインオフ

Customerの正式な代表者による書面のUATサインオフなしに、本番環境へのデプロイを進めてはなりません。 サインオフ文書には、Customerが受入基準に照らしてリリースを検証し、本番への昇格を承認したことを確認する旨を記載するものとします。

CustomerがUAT開始日から10営業日以内にサインオフまたは却下を提示しない場合、Providerは書面でのリマインダーを発行します。さらに5営業日以内に応答がない場合、リリースはCustomerにより承認されたものとみなします。

5.8.4 UAT欠陥の取扱い

UAT中に特定された欠陥は、Embedded Ticketing System（§4.1）で管理され、§5.6.3の重大度分類に従って区分されます。以下のルールが適用されます。

• P1/P2欠陥: UATサインオフを停止します。Providerは、影響を受ける機能を現在のスプリントサイクル内で是正し、再提示するものとします。
  • P3欠陥: サインオフを妨げません。Providerは次のスプリントで是正し、Customerに解決を確認します。
  • P4欠陥: バックログに登録します。是正はキャパシティとCustomerの優先度入力に基づいて計画されます。

5.9 業務最適化アドバイザリー

5.9.1 概要

ProviderのAI拡張テストフレームワークによる独自の機能は、テスト実行データの分析から得られる実行可能な業務最適化インサイトを生成できることです。このサービスにより、テストは単なる防御的な品質ゲートから、Customerにとっての積極的な価値創出活動へと変わります。

5.9.2 インサイト生成

テスト実行中、AIエージェントは以下を継続的に収集・分析します。

• (a) 取引遅延パターン: 業務フローの各ステップの処理時間が一貫して過大である箇所を特定し、業務ルールまたはデータアクセスパターンに潜在的なボトルネックがあることを示します。
• (b) 例外発生頻度: 検証失敗、業務ルールによる却下、承認拒否を記録し、ルール設定不備やユーザー案内の不明瞭さを示す業務上の摩擦点を可視化します。
• (c) データ品質異常: 不完全なレコード、デフォルト値の過剰使用、または体系的なデータ入力ミスのパターンを検出し、フォーム再設計や必須項目調整の必要性を示します。
• (d) 権限の競合: 不要な承認ボトルネック、または逆に職務分掌の欠落を生むロール／権限の組み合わせを特定します。
• (e) 未活用機能: 有効化されているが、現実的なテストシナリオでは使用されていないモジュールや機能をフラグ付けし、トレーニング不足または不要なライセンスコストの可能性を示します。

5.9.3 推奨事項の提供

業務最適化に関する推奨事項は以下のとおりです。

• 集約済み: 各主要テストサイクル（スプリントリリースまたはアップグレード）の後に、構造化されたProcess Optimisation Reportにまとめる。
  • 分類: 影響度（高/中/低）、工数（設定変更、小規模開発、大規模開発）、リスク（リスクなし、低リスク、UAT要）に基づいて分類します。
  • 提示: Service Delivery Managerが、Quarterly Service Review（§3.9）でCustomerに提示します。
  • 追跡: Continuous Service Improvement（CSI）レジスター（§4.10）に、合意済みの期限と担当者を含むアクション項目として記録します。

5.9.4 範囲上の制約

Process Optimisation Advisoryは情報提供を目的として提供されます。いかなる推奨事項の実施も、適用される変更管理およびスプリント計画プロセス（§4.6、§4.7）に従う設定変更または開発依頼に該当します。Providerは、Customerの承認、および該当する場合は正式なScope Change Request（§2.7）なしに最適化変更を実施してはなりません。

5.10 テストガバナンスおよび報告

5.10.1 テスト証跡リポジトリ

Providerは、各Customerごとに集中管理された改ざん不可のテスト証跡リポジトリを維持し、以下を含めるものとします。

• 各デプロイに対するテスト計画およびテストケース仕様。
• AIエージェントの実行ログ（API相互作用の完全なトレース、タイムスタンプ、アサーション結果）。
• データ完全性レポート（§5.7.3）。
• 業務最適化レポート（§5.9.3）。
• UAT証跡パック（テストケース結果、欠陥ログ、サインオフ文書）。
• 回帰スイートの変遷履歴（追加・変更・廃止されたテストケース）。

テスト証跡は、本Frameworkの存続期間に加えて12か月、または適用されるデータ保護規制で要求される期間（GDPR第5条1項(e)、UAE PDPL第5条）のいずれか長い方、保持されます。

5.10.2 品質指標

Providerは、Quarterly Service Review（§3.9）に含める以下の品質指標を追跡し、報告するものとします。

5.10.3 継続的改善

SQTフレームワークは、デミングサイクル（Plan-Do-Check-Act）に沿って継続的改善の対象となります。

• (a) Plan: 品質指標の傾向とCustomerからのフィードバックに基づき、各四半期の開始時にテスト戦略とAIエージェント設定を見直し、更新します。
• (b) Do: 更新済みのテストスイートとエージェント設定をCustomerのStaging環境に展開します。
• (c) Check: 品質指標（§5.10.2）を目標値と照合して評価し、未達があれば原因分析を実施します。
• (d) Act: 是正および予防措置をCSIレジスター（§4.10）に記録し、その後のスプリントサイクルで実施します。

5.11 セキュリティおよびコンプライアンス

5.11.1 テストデータ保護

SQTプロセスで使用されるすべてのテストデータは、本Frameworkのデータ保護義務（Chapter [Data Protection ― future chapter reference]）の対象となります。具体的には以下のとおりです。

• 本番データは、GDPR第89条1項およびUAE PDPL第5条に従い、非本番環境で使用する前に匿名化または仮名化しなければなりません。
• AIエージェントは、テストセッションを超えてCustomerデータを保存しません。AI Testing Agentsが処理するすべてのデータは一時的なものであり、セッション終了時に消去されます。
• APIトークンは、必要最小限の権限に限定され、期限付きであり、セッション終了時に自動的に失効します。
• テスト証跡ログは、保存時（AES-256）および転送時（TLS 1.3）に暗号化されます。

5.11.2 エージェントガバナンス

ProviderによるSQTフレームワークでのAIエージェント利用は、以下に準拠して管理されます。

• EU AI Actへの準拠: ソフトウェアテストに使用されるAIエージェントは、制御された環境内で非本番データを扱い、自然人に影響を及ぼす自律的判断を行わないため、EU AI Act（Regulation (EU) 2024/1689）において最小リスクに分類されます。
• NIST AI RMF: ProviderのAIテスト手法は、NIST AI Risk Management Framework（AI RMF 1.0）の妥当性、信頼性、説明責任の原則に整合しています。
• 人的監督: AIエージェントは人間の監督下で稼働します。すべてのテスト結果、最適化提案、デプロイ判断は、実施前に人間による確認と承認が必要です。
• 透明性: Providerは、Customerからの要請があれば、任意のテストサイクルについてAIエージェント設定、判断ロジック、相互作用ログの文書を提供します。

EU AI Act ― Regulation (EU) 2024/1689 NIST AI Risk Management Framework 1.0

5.12 プロセス登録簿

5.12.1 プロセスレジストリ

5.12.2 RACIマトリクス

R = 実行責任者 | A = 説明責任者 | C = 協議先 | I = 通知先

5.12.3 プロセスフロー ― ソフトウェア品質およびテストライフサイクル