部門横断の責任分界（設計・QA・情シス・経営）の決め方
（OEM調査依頼で止まらない運用設計）
OEM調査依頼や監査対応で一番止まりやすいのは、技術判断そのものではなく、「誰が何を決めるか」が曖昧なことです。
- 設計は「技術確認はするが、対外回答は品質でしょ」と考える
- QAは「根拠を作るのは開発でしょ」と考える
- 情シスは「製品ではなく社内IT担当なので対象外」と考える
- 経営は「最後に承認だけ」と思っているが、判断材料が上がってこない
この状態だと、期限（SLA）だけが近づき、結論も証跡もまとまりません。
FIRSTのPSIRT Services Frameworkでも、PSIRTは製品開発から切り離された独立組織ではなく、開発・テスト/品質保証・サポート・法務/広報など複数の内部関係者と連携する前提で整理されています。また、内部関係者とその役割を理解し、必要なコミュニケーション方法を整えること、さらにインシデント対応時には PSIRT、開発、サポート、サプライヤーなどを集めて状況把握することが推奨されています。
CISAの脆弱性開示 handling procedures でも、報告の追跡、内部調整、影響評価と優先順位付け、外部とのコミュニケーション、そして目標時間（timelines）を定めて追跡することが求められています。つまり、責任分界とは「組織図の問題」ではなく、内部調整と期限運用を成立させるための設計です。
先に結論：4部門は「4役」に変換すると決めやすい
部門名のままだと、責任が重なって揉めます。
最初は 設計・QA・情シス・経営 を、そのまま部門で切るのではなく、次の 4役 に変換して考えると整理しやすいです。
技術評価
対象版数、構成、到達性、影響有無を確認する
→ 主に設計/開発が担当
対外回答
OEM向け回答文、提出物、証跡の整理を行う
→ 主にQAが担当
運用・証跡管理
チケット、期限、保存場所、ログ、権限、社内連絡を整える
→ 情シスまたはPSIRT窓口機能が担当
承認・経営判断
期限交渉、リスク受容、外部発信の承認を行う
→ 経営層または部門長が担当
この4役に置き換えると、誰が“作る側”で、誰が“決める側”かが見えやすくなります。
部門別に見ると、何を持つべきか
設計/開発
設計は「技術評価の責任者」です。持つべき責任は次の通りです。
- 対象製品・対象版数の確認
- 構成やSBOM、設定、IFの確認
- 影響あり/なし/調査中の技術根拠の提示
- 暫定対策/恒久対策の案出し
- 修正版の対象版数、更新方式の提示
逆に、OEMへの最終文面を設計だけで確定させる必要はありません。
QA（品質保証）
QAは「対外回答の責任者」です。持つべき責任は次の通りです。
- OEM/顧客との窓口
- 受領確認、一次回答、最終回答の期限管理
- 回答書の組み立て（結論→根拠→対応方針→証跡）
- 提出履歴の管理
- 監査証跡の整理
QAが“技術判断そのもの”をする必要はありませんが、技術判断を対外説明に変換する責任を持ちます。
情シス/PSIRT窓口
情シスは、自社ITだけでなく、PSIRT窓口機能を兼ねるなら「運用設計」の責任を持ちます。
- チケット/案件IDの管理
- 証跡の保管場所、アクセス権、命名ルール
- 期限管理表の更新
- 社内エスカレーションの運用
- 監査時に再現できるログの保持
ここは“技術評価”と混同しやすいですが、主役は運用を回すことです。
経営/部門長
経営は最後に判子を押すだけではありません。持つべき責任は次の通りです。
- 期限交渉やリスク受容の承認
- 重大案件での優先順位付け
- 追加工数や予算の判断
- 対外的に重い回答の承認
- 例外運用の承認
経営が入るべき場面を決めておかないと、全部の案件で承認待ちになって詰まります。
手順：責任分界を決める（5ステップ）
まず“決めること”を洗い出す
部門ではなく、決める対象を列挙します。たとえば次のようなものです。
- ・対象版数を確定する
- ・影響あり/なしを決める
- ・一次回答を出す
- ・最終回答を承認する
- ・証跡を保存する
- ・期限交渉をする
- ・修正版の出荷を決める
RACIで4列だけ作る
最初は細かくしすぎず、4列だけで十分です。
案件の重さで“承認線”を分ける
すべての案件で経営承認が必要だと止まります。たとえば次のように切ると現実的です。
- 軽微： QA承認
- 通常： QA ＋ 設計責任者
- 重大： QA ＋ 設計責任者 ＋ 部門長
証跡の責任者を別で置く
多くの現場で抜けるのがここです。技術評価があっても、証跡を残す人がいないと監査で弱くなります。最低限、証跡管理のOwner を1人決めてください。
例外時のルールを先に決める
上流回答待ち、設計不在、承認者不在など、例外は必ず起きます。その時の代替ルール（エスカレーション先）を、最初に決めておくと事故が減ります。
そのまま使える：責任分界（RACI）テンプレ
以下のような表を1枚持つだけで、かなり安定します。（※ これは雛形です。実際には組織構成に応じて入れ替えてください。）
| 決めること | 設計 | QA | 情シス/PSIRT | 経営/部門長 |
|---|---|---|---|---|
| 対象版数の確定 | R | C | I | I |
| 影響有無の技術判断 | R | C | I | I |
| OEM一次回答の作成 | C | R | C | I |
| 最終回答の承認 | C | R | I | A |
| 証跡の保存/管理 | C | C | R | I |
| 期限交渉 | C | R | I | A |
| 修正版の出荷判断 | R | C | I | A |
OEM調査依頼・監査対応の進め方を、自社の組織に合わせて整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（体制が回らなくなる原因）
- 設計が“全部やる”ことになっている
技術も対外回答も証跡も全部抱え込み、止まりやすくなります。 - QAが“取りまとめるだけ”で責任が無い
文面調整しかできず、期限交渉や証跡管理が宙に浮きます。 - 情シスが関与せず、ログと証跡が散らばる
後から監査で辿れなくなります。 - 経営承認が全部に必要
軽微案件まで承認待ちになり、SLAを落とします。
FAQ：責任分界・RACIの決め方
最初は役割で切る方が整理しやすいです。部門名だけで決めると、責任が重なったり抜けたりしやすくなります。
必要です。むしろ兼務ほど「どの帽子で判断しているのか」を明確にする必要があります。
重大案件、期限交渉、リスク受容、対外回答の承認など、“重い判断”だけに絞ると運用が崩れにくいです。
エスカレーションと承認をシステム化しませんか？
Auto PSIRT Cloudなら、OEM調査依頼をチケット化し、あらかじめ決めた担当者や承認者へワークフローとして自動で通知します。誰がボールを持っているか、システム上で一目で分かります。