1 適合表の概要
適合表とは、製品、規格、仕様、手順、計画などの「対象」が、所定の条件や要求事項に対して適合しているかを、対比可能な形で整理した表（マトリクス）である。要求側の情報と、評価・証明側の情報を並置することで、確認作業の見落としを減らし、説明責任を果たしやすくする。
適合表は、品質保証やコンプライアンス領域で用いられることが多い。特に、複数部門の成果物や多数の要求事項が存在する場合、口頭確認や個別資料だけでは整合性を追跡しにくいため、表形式による可視化が効果を持つ。
1.1 適合表の目的
主な目的は、適合状況を体系的に示し、確認・監査・レビューの効率を高めることである。要求事項に対して、対象が満たす内容の有無、判定結果、根拠資料を紐づけることで、判断の依拠が明確になる。
また、変更に伴う影響を追跡しやすくする点も重要である。要求側の改訂や、設計・実装・手順の変更が発生したときに、適合表上の差分を起点に影響範囲を特定できるため、再評価の見落としを抑えられる。
1.2 適合表の基本構成
適合表は、要求事項と対象の対応関係を成立させるための最小単位として、各種の欄で構成される。実務では表題、版情報、対象の特定情報を含め、要求事項ごとに判定結果と根拠を紐づける設計が一般的である。
最下段や末尾に注記、例外条件、未達時の扱い、作成者・承認者の情報を置くことも多い。これにより、運用段階で必要となる判断材料や責任範囲が明確になる。
1.2.1 要求事項欄
要求事項欄には、基準となる文書や仕様から抽出した要求を、行単位で記載する。要求番号、要求文、適用条件（対象範囲、前提、除外条件）などを含めると、後工程での参照が容易になる。
要求文は、後で改訂が入る可能性を考慮し、「原文に近い形」または「原文の意味を損なわない形」で統一することが望ましい。粒度が粗すぎると判定の曖昧さが残り、細かすぎると表が肥大化し運用負荷が増える。
1.2.2 適合判定欄
適合判定欄には、当該要求に対する達成状況を示す。判定は、単純な適合／不適合にとどめる場合もあるが、実務では条件付き適合、部分適合、評価中などの状態を設けることがある。
判定結果は、読む側が再現可能な形で解釈できる必要がある。そのため、判定の意味（例：条件付き適合の要件、評価中の定義、是正の進め方）を別欄または注記で明確化する。
1.2.3 根拠・参照資料欄
根拠・参照資料欄には、判定の根拠となる資料への参照情報を記載する。たとえば試験成績書、検証レポート、設計図面、仕様書の該当箇所、計算書、レビュー記録、認証証明書などが該当する。
参照の粒度は、根拠をたどるために必要十分であることが重要である。資料の名称だけでなく、版番号、章・節、ページ、発行日などを組み合わせると、後日の追跡性が向上する。
1.3 適合表が対象とする範囲
適合表がカバーする範囲は、対象の境界を定義することで決まる。対象が「製品の全仕様」なのか、「特定モジュール」なのか、「運用手順のみ」なのかを明確にしないと、要求に対する判定がブレやすい。
また、外部委託品、例外として扱う要件、適用しない要求の扱いも範囲に含める。適合しないこと自体が誤りではなく、除外の妥当性が示されて初めて整理が成立するためである。
2 適合表の作成方法
適合表の作成は、要求の抽出と整理、対象情報の収集、判定基準の確立、記入の品質確保という流れで進めると体系的になる。特に初期設計が弱いと、後で参照や差分追跡が困難になりやすい。
実務では、作成の担当者だけでなく、レビュー側や監査側が参照することを前提に設計する。読みやすさと追跡性を同時に満たすことが、作成後の労力を左右する。
2.1 要求事項の整理
要求事項の整理は、適合表の骨格を決める工程である。要求をどの単位で切り出し、どのように優先度や区分を付すかは、表の運用性に直結する。
この段階では、要求文の意味が変わらない範囲で整形し、判定できないあいまいさを排除することが目標となる。必要に応じて要求の解釈確認を行い、後工程の手戻りを減らす。
2.1.1 要求の粒度設計
要求の粒度は、判定の再現性と管理のしやすさを両立させる観点で決める。粒度が大きい場合、複数の技術要素をまとめて扱うことになり、どこが根拠なのかが曖昧になりやすい。
逆に粒度を細かくしすぎると、表の行数が増えて更新負荷が上がる。さらに、関連する要求が散在すると、変更時に影響範囲を特定しにくくなる。したがって、評価や試験が成立する単位、または設計要素との対応が取りやすい単位を基準に調整する。
2.1.2 優先度・区分の付与
優先度や区分の付与は、未達時の対応やレビューの優先順位に関係する。たとえば安全性に直結する要件、性能や互換性に関わる要件、情報開示や文書化に関わる要件など、観点ごとに整理する。
区分があると、監査時に見るべき箇所が明確になる。加えて、試験計画やレビュー計画を組む際に、重点領域を先に処理できるようになり、手戻りのコストを下げられる。
2.2 対象情報の収集
対象情報の収集は、要求に対する根拠を実際に提示できる状態にする工程である。適合表は「主張」だけでは成立せず、検証や設計根拠の実体が必要になる。
収集範囲は、評価データ、図面・仕様書、証明書、レビュー記録などに広がる。これらを適切に整合させることで、判定の信頼性が確保される。
2.2.1 試験・評価データ
試験・評価データは、定量的な達成状況を示す根拠として用いられる。測定値、試験条件、サンプル数、合否基準、評価手順などを含めることで、外部からも判断可能な形になる。
データ収集では、試験の実施日や適用バージョンを揃える点が重要である。仕様変更や設計更新が入った場合、データが別世代の対象に紐づいていると、誤判定の原因になる。
2.2.2 図面・仕様書・証明書
図面、仕様書、証明書は、設計意図や規格適合の根拠として参照される。図面では版番号、適用図、注記番号などの参照が必要となることが多い。仕様書では条項番号や表番号を明示すると追跡性が上がる。
証明書は、発行主体、対象範囲、適用条件、期限などの要素を押さえる。これらが不明確なまま参照すると、表の信頼性が損なわれるため、記載ルールを事前に定めることが望ましい。
2.3 適合判定の基準
適合判定の基準は、判定が人によって変わらないようにするための枠組みである。基準が曖昧だと、同じ状況でも結果が分岐し、レビューや監査で論点になりやすい。
ここでは、判定に必要な測定や評価の条件、合否の閾値、例外の扱いなどを明文化する。
2.3.1 判定基準の明文化
判定基準は、要求文から導出される合否条件を明確に記す。たとえば「数値範囲」「許容誤差」「試験条件」「適用対象」「評価方法」などが含まれる。
また、根拠資料が複数ある場合の優先順位も決めるとよい。最新の版を優先する、特定の試験結果を優先する、といったルールを定めることで、判定の一貫性が保たれる。
2.3.2 例外・条件付き適合の扱い
例外や条件付き適合は、適合表の要点になりやすい。完全に不適合とするのではなく、条件が満たされる限り適合とみなせる状況、または限定的に適合とみなす状況を明確に記載する。
条件付きの場合は、その条件（運用制約、追加手順、将来の改修、監視頻度など）を具体化し、条件を破った場合の扱いも示す。これにより、適合状態が“見かけ上の合格”に留まらず、運用上の管理に繋がる。
2.4 記入ルールと品質チェック
記入ルールと品質チェックは、適合表の信頼性を支える。表の見た目だけ整っていても、参照の不整合や表記の揺れがあると、運用上のトラブルが生じる。
品質チェックでは、内容の正確性だけでなく、読み手が迷わない構造になっているかを確認する。
2.4.1 表記ゆれの統一
表記ゆれの統一は、追跡性と検索性に影響する。要求番号の形式、資料名の表記、単位系、略語の展開ルールなどを統一することで、同一内容の重複や参照漏れを減らせる。
特に単位や記号の表現は、誤読につながりやすい。統一した記法に基づき記載し、必要に応じて略語集や注記欄で補足する。
2.4.2 根拠リンクの整合性確認
根拠リンクの整合性確認では、参照先が存在すること、版が一致すること、内容が当該要求の判定根拠になっていることを確認する。資料の改訂により章やページが変わる場合、参照の更新漏れが起きやすい。
また、根拠資料の適用対象が適合表の対象と一致しているかも重要である。評価対象の個体、構成、構成要素の範囲がズレていると、内容は正しくても根拠としては不適切になる。
3 適合表の運用と管理
適合表は作成して終わりではなく、変更や運用を通じて価値が維持される。運用段階では版管理、差分追跡、レビューや監査への活用が中心となる。
適合状況は時間とともに変わるため、更新の手順と責任分界を明確にすることが重要である。
3.1 版管理と改訂履歴
版管理では、適合表の改訂番号、改訂日、改訂者、変更理由を管理する。これにより、どの版の情報が当時の判断に使われたのかが追跡できる。
改訂履歴には、変更した欄の概要を簡潔に記すことが多い。詳細は差分資料やリンク先に委ね、改訂の意図を短く伝える設計が有効である。
3.2 変更管理（差分追跡）
変更管理（差分追跡）では、要求側または対象側の変更が適合表に与える影響を特定する。設計変更、手順の修正、試験条件の変更、根拠資料の更新などが該当する。
差分追跡では、更新すべき行、影響範囲、再評価の要否を明確にする。全件再判定はコストが大きいため、変更された要求や関連する対象要素に絞って確認することで効率を高められる。
3.3 監査・レビューへの活用
適合表は、レビューや監査の際に論点を整理するための基盤となる。要求事項ごとの判定と根拠が揃っていると、確認作業が場当たりにならず、短時間で整合性の確認が進む。
活用方法は組織によって異なるが、内部レビューと対外提出・説明では求められる粒度が変わる。
3.3.1 社内レビュー
社内レビューでは、判定の妥当性、根拠の適切さ、参照の整合性を中心に点検する。技術部門と品質部門、場合によっては法務や調達が関与し、解釈の齟齬がない状態にする。
レビュー観点をチェックリスト化すると、毎回の確認漏れを抑えられる。加えて、未達や条件付き適合がある場合は、是正計画の妥当性や期限の妥当性まで議論対象に含めるとよい。
3.3.2 対外提出・説明
対外提出・説明では、受け手が求める説明の粒度に合わせて整備する。要求事項と根拠資料が明確であることに加え、表の読み方が分かる注記があると説明コストが下がる。
また、情報の機密性に配慮して公開範囲を調整する場合もある。根拠資料を全文添付できないときは、参照の形式や要約の書き方を事前に取り決めることで、説明の一貫性を保てる。
4 よくある形式と応用例
適合表には複数の形式があり、目的や対象の性質に応じて選択される。一覧型、段階判定型、ツール連携型などが代表例である。
ここでは形式ごとの特徴と、業種ごとの適用イメージを示す。特定の業界に限らず、手順や仕様の管理が重要な領域で共通して使いやすい。
4.1 一般的な一覧型（マトリクス型）
一覧型（マトリクス型）は、要求事項を行に、必要情報（判定、根拠、備考など）を列に配置する形式である。構造が単純で、要求ごとの状態を一覧で把握しやすい。
大量の要求がある場合でも、並び順の設計やフィルタの運用により可読性を確保できる。判定が二値中心でも、条件付きや評価中の状態を列挙することで実務に対応する。
4.2 段階判定型（達成度の段階化）
段階判定型は、達成度を段階で表す形式である。たとえば「完全適合」「ほぼ適合」「一部未達」「要再評価」のように、検証の成熟度や残課題の程度を示す。
この形式は、開発初期や試験未完了の状況で特に有用である。進捗を可視化できるため、マイルストーン管理と相性がよく、残作業の優先付けにも役立つ。
4.3 要件管理ツール連携型
要件管理ツール連携型では、適合表の行（要求）と、チケット、要件、テストケース、変更要求などの情報を連結する。これにより、更新時の追跡性が高まり、手作業による転記負荷を抑えられる。
連携では、識別子の設計が重要になる。要求番号や内部IDを統一し、リンク切れが起きない運用ルールを決めることで、表の価値が安定する。
4.4 業種別の応用
業種によって要求の性質や根拠の種類が異なるため、適合表もそれに合わせて調整される。特に、評価データの有無、証明書の取り扱い、変更頻度の違いが形式選定に影響する。
以下では代表的な3領域に分けて、適合表の使い方の違いを概観する。
4.4.1 ソフトウェア・システム
ソフトウェア・システムでは、要求事項に対して設計仕様、実装、テスト結果が根拠として紐づくことが多い。適合判定では、ユースケースや機能要件、非機能要件（性能、安全性、可用性など）を対象にする場合がある。
テストケースとの連携を強めると、判定の根拠がより具体化する。さらに、ログや解析結果を参照可能にしておくと、障害や再現性の確認に役立つ。
4.4.2 製品・部品
製品・部品では、図面、仕様書、材料証明、試験成績書、工程条件などが根拠になりやすい。適合判定は、規格値や許容範囲に基づいて行われることが多く、測定条件の記載が重要となる。
また、ロットや製造条件、検査方法の違いが適合性に影響する場合があるため、根拠資料側の適用範囲を明記する運用が望ましい。これにより、同じ仕様でも製造条件が異なるケースでの誤認を防げる。
4.4.3 手順・運用ルール
手順・運用ルールに対する適合表では、文書化された手順が要求に対して整合しているかを中心に整理する。根拠としては手順書、教育記録、運用ログ、チェックリスト、内部監査の記録などが参照されることがある。
運用の適合性は、文書が存在するだけでなく実際に運用されているかで判断される。適合表には、実施頻度や記録の取得方法、例外処理の条件なども反映させると、監査時に説明しやすい。