PSIRTと品質保証（QA）を衝突させない役割分担
（兼務でも破綻しない決め方）
PSIRTを立ち上げると、かなりの確率で最初に揉めるのが 品質保証（QA）との役割分担 です。
現場でよく起きるのは、次のようなすれ違いです。
- PSIRT側は「外部への回答をまとめたい」
- QA側は「品質保証の承認なしに外へ出せない」
- 設計側は「技術判断はするが、窓口業務は持ちたくない」
- 経営側は「最後に承認するが、どこまで介入すべきか分からない」
結果として、案件は止まり、OEM回答期限だけが迫ります。
FIRST の PSIRT Services Framework では、PSIRTは開発・テスト・品質保証・リリース・サポートなどの内部関係者と継続的に連携する前提で整理されており、さらに remediation（対策）の signoff は 責任ある QA engineer / team が行い、標準の testing / QA practice に統合されるべきだとされています。つまり、QAは“後からハンコを押すだけ”の存在ではなく、PSIRTの中核的な協働相手です。
先に結論：PSIRTとQAは「何を決めるか」で分ける
役割分担がぶつかる原因は、部門名で責任を切ろうとすることです。
実務では、部門ではなく“判断対象”で分ける とかなり整理しやすくなります。
おすすめは次の切り分けです。
PSIRT（窓口機能）
受付、全体調整、外部コミュニケーション、期限管理
QA（品質保証）
対外回答の品質、証跡の整合性、リリース観点での妥当性確認
設計/開発
対象版数の確定、成立条件、技術根拠、対策案
承認者（部門長/経営）
外部送付の承認、例外判断、期限交渉の最終判断
この分け方は、FIRST が示す internal stakeholder management と remedy signoff by QA の考え方を、サプライヤー実務向けに落としたものです。
なぜPSIRTとQAは衝突しやすいのか
衝突の原因は、どちらも「品質を守る」立場に見えるからです。
ただし、守っている対象は少し違います。
PSIRT が守るもの
- 受付漏れがないこと
- OEM/顧客への回答が期限内に返ること
- 脆弱性の状態（影響あり/なし/調査中）が整理されていること
QA が守るもの
- 外部へ出す内容に矛盾がないこと
- 対策版や証跡が品質として成立していること
- リリース判断や提出物の整合性が取れていること
どちらも必要ですが、ここを言語化せずに始めると、
PSIRTは「早く返したい」 ／ QAは「曖昧なまま出したくない」
という典型的な対立になります。
兼務でも破綻しない：役割分担の最小形
最初は大きな組織図は要りません。最低限、次の4役を決めれば十分です。
-
1. 窓口（PSIRT役）
OEM/顧客/外部報告の受付、案件ID付与、期限（SLA）設定、一次回答の送付
-
2. 技術評価（設計/開発）
対象版数の特定、構成確認、影響有無の根拠作成、暫定対策/恒久対策の案出し
-
3. 品質確認（QA）
回答書の整合性確認、証跡の参照性チェック、リリース/提出物との一貫性確認、対策版の signoff
-
4. 承認（部門長/経営）
外部送付の承認、期限交渉の判断、重大案件の優先順位判断
手順：役割分担を決める（5ステップ）
まず「決めること」を洗い出す
最初にやるのは、部門名を並べることではなく、案件の中で“誰かが決める必要があること” を列挙することです。
・対象版数を確定する
・影響あり/なし/調査中を決める
・外部回答文を作る
・証跡を保存する
・修正版を承認する
・期限交渉をする
RACIで1枚にする
部門をそのまま書くより、RACIで表にすると衝突が減ります。
QAの役割を“遅延要因”ではなく“品質保証”として定義する
QAが毎回すべてを最初からレビューすると、SLAが落ちます。だからQAは、技術判断そのものをやり直す役割ではなく、対外回答の品質と証跡の妥当性を確認する役割 と定義します。
承認が必要な案件レベルを決める
すべてを部門長承認にすると止まります。たとえば次のように切ると現実的です。
- 軽微： QA確認で送付可
- 通常： QA ＋ 設計責任者
- 重大： QA ＋ 設計責任者 ＋ 部門長
例外ルールを先に作る
設計不在、QA不在、緊急回答、上流回答待ちなどの例外時にどうするかを決めます。これが無いと、結局「その時の力関係」で決まって再炎上します。
そのまま使える：役割分担（RACI）テンプレ
以下の表をそのまま使えます。（※これは最小形です。組織に応じて調整してください）
| 決めること | PSIRT窓口 | 設計/開発 | QA | 承認者 |
|---|---|---|---|---|
| 受領確認 | R | I | I | I |
| 対象版数の確定 | I | R / A | C | I |
| 影響有無の判断 | I | R | C | I |
| 回答書作成 | R | C | C | I |
| 回答書レビュー | I | C | R / A | I |
| 外部送付承認 | I | I | C | A |
| 証跡保存 | R | C | C | I |
| 修正版signoff | I | R | A | I |
実務でのコツ
- 1. 「QAは遅い」ではなく、入る位置を決める QAを早い段階から毎回巻き込むのではなく、回答書レビューと提出前確認に重点を置くと機能しやすいです。
- 2. 設計は“根拠を1〜3行で返す” 長い技術説明ではなく、対象版数と成立条件を短く返せるようにすると、QAやPSIRT窓口が動きやすくなります。
- 3. PSIRT窓口は期限と更新日を死守する 技術結論が未確定でも、受領確認と次回更新日は返せます。ここがPSIRT窓口の最重要責任です。
自社でのPSIRT立ち上げや、部門間の運用設計を整理したい方はご相談ください。
【無料】オンライン相談を予約するFAQ：役割分担の決め方
技術判断の最終責任と、対外送付の最終責任を分けるのが現実的です。多くの場合、技術判断は設計/開発、対外送付はQAまたは承認者が持つと安定します。
必要です。むしろ兼務ほど、「いまどの帽子で判断しているか」を切り分けないと、責任が曖昧になります。
その通りです。だからQAは“技術判断のやり直し”ではなく、“外部回答と証跡の品質確認”に役割を絞るのがコツです。
部門間の連携を、システムでスムーズにしませんか？
Auto PSIRT Cloudなら、案件のチケット化から影響判定、承認フローまでがシステム上で一元管理されます。誰がボールを持っているか一目で分かり、期限切れを防ぎます。