試験項目チェックリスト（Cシート）の目的は「疎通」ではなく「証明」
ネットワークの構築が完了すると、試験フェーズに入ります。多くの現場で行われる試験は、単なる「疎通確認」または「設定値の確認」に留まりがちです。
Pingが通ることや、ルーターのコンフィグが正しいことは、設計の「最低条件」でしかありません。真に価値のある試験とは、Aシートで定めた「可用性」「性能」「セキュリティ」といった非機能要件を設計通りに満たしているかを証明することです。
Cシート（試験項目チェックリスト）の役割は、試験の目的を「動くこと」から「設計が破綻しないこと」へと強制的に切り替えることにあります。
Cシートの核：「壊れること」と「復旧時間」をA-Noで定義する
Cシートの設計思想は、「壊れないこと」を祈るのではなく、「設計通りに壊れ、かつAシートで定めた許容時間内に復旧すること」を強制的に検証することです。
1. 試験の「合格基準」にA-Noを強制的に紐づける
従来の試験表が「接続OK/NG」の二択だったのに対し、Cシートでは、合格基準にAシートで定義した時間軸や具体的な結果を入れ込み、それに紐づくA-Noを明記します。
| 試験項目 | 試験目的 | 合格基準 | 根拠A-No |
|---|---|---|---|
| コアSW切替試験 | 冗長構成が機能するか | 30秒以内に通信が再開すること | A-11 |
| DMZアクセス制御 | セキュリティポリシー違反がないか | 内部NWからDMZセグメントへの直接アクセスがすべて拒否されること | A-15 |
| ユーザー認証試験 | 認証システム連携 | 認証失敗から5秒以内に再認証プロンプトが表示されること | A-12 |
試験担当者は、単に疎通が戻るかを見るのではなく、「A-11で定義された許容停止時間（例：30秒）を超過しなかったか」を計測する論理的義務が発生します。
2. Cシートが実現する「設計の品質保証」
Aシート（Why）とBシート（数字）の論理がCシートに流れ込むことで、設計の品質は以下の点で保証されます。
- 設計目標の検証: 試験が「A-11 可用性」や「A-14 拡張性」といった、設計の根幹を成す要件の達成度を直接検証します。
- 非機能要件の可視化: 性能や冗長性など、目に見えない非機能要件が、Cシート上で具体的な計測可能な項目に変換されます。
- レビュー耐性の最終担保: レビュー担当者は、「この試験で本当にA-11の要件が満たせるのか？」という、設計思想レベルの検証に集中できるようになります。
【連載まとめ】設計者の「思考OS」としての3点セットの価値
本連載で解説したA（要件）→ B（数字）→ C（試験）のトレーサビリティ構造は、単なるドキュメント作成の効率化ではありません。
これは、設計者が「なぜ」を常に意識し、すべての判断に論理的な根拠を付与し、その根拠がサービスイン後も維持されることを証明するための、「設計者の思考OS」そのものです。
レビューで問われたときに即座に根拠を答えられること。そして、引き継ぎ後も設計思想がブレないこと。これが、この実務テンプレートが設計者の皆様に提供する最大の価値です。
このテンプレートは、「何となくOKだった試験」や「何となく選んだ/24」を二度と許さないためのものです。
【DL専用エリア】
設計判断の根拠（A-No）をドキュメント間でトレース可能にする実務テンプレート