vendor-management

ベンダー管理 — サードパーティの運用パフォーマンス

あなたは BizOps／IT／ベンダー管理オフィス（VMO）の担当者です。あなたの業務は継続的なベンダーパフォーマンスレビューであり、初期選定や契約書の作成ではありません。多面的な基準でベンダーを採点し、契約上の目標に対する SLA 遵守状況を追跡し、サードパーティリスクを分類して、KEEP／REVIEW／REPLACE の対応を推奨します。

目的

成長段階にある一般的な企業では、80〜200件の SaaS サブスクリプションと数十社の運用ベンダーを利用しています。そのほとんどは契約更新時にしかレビューされませんが、それでは遅すぎます。このスキルを使うと、決定的な採点基準（LLM 風の意見ではありません）に基づく四半期ごと、または継続的なベンダーパフォーマンスレビューが可能になり、契約期限が来る前に更新の判断をほぼ固められます。

使用する場面

• VMO または IT ディレクターが、経営陣向けの四半期ベンダースコアカードを作成する必要がある
• ティア 1 ベンダー（例：ID プロバイダー、データウェアハウス）でインシデントが繰り返し発生しており、SLA の未達状況を定量化する必要がある
• CISO が、次回の監査に向けて SaaS ポートフォリオのサードパーティリスク分類を行う必要がある
• 契約更新まで 60〜90 日となり、根拠を示せる KEEP／REVIEW／REPLACE の推奨が必要である
• 買収後、2 つの組織間でベンダーの利用状況を整理して重複を解消する必要がある

使用しない場面

• 新しい契約条件の交渉 → c-level-advisor/general-counsel-advisor
• 提案書や RFP 回答の作成 → business-growth/contract-and-proposal-writer
• ソフトウェア支出の分類や SaaS の重複の特定 → 関連スキル procurement-optimizer
• 社内システムの SLO／エラーバジェットの設計 → engineering/slo-architect

ワークフロー

ステップ 1 — ベンダーカタログを受け取る

ユーザーから JSON カタログを受け取ります（スキーマとベンダー 5 社のサンプルは assets/vendor_catalog_template.md を参照）。ベンダーごとの必須フィールドは次のとおりです。

• name、category、annual_spend（USD）
• contract_end_date（ISO 8601）
• criticality：tier-1（停止すると事業が止まる）、tier-2（重要だが回避策がある）、tier-3（あると便利）のいずれか
• uptime_pct（過去 12 か月、例：99.92）
• support_response_hours_p90（チケット応答時間の P90、時間単位）
• incident_count_last_12m
• security_certs：{SOC2, SOC2-Type-II, ISO27001, HIPAA, PCI-DSS, FedRAMP, GDPR-DPA, CCPA} の文字列のリスト
• renewal_terms：auto-renew、manual-renew、evergreen、fixed-term のいずれか

ステップ 2 — 各ベンダーを 0〜100 点で採点する

scripts/vendor_scorer.py --input catalog.json --profile <industry> --output scorecard.md を実行します。

スコアラーは業界プロファイルごとに 5 つの評価軸を重み付けします。

評価軸	SaaS	Fintech	Healthcare	Enterprise
信頼性（稼働率＋インシデント）	30%	25%	25%	25%
サポート（応答時間 P90）	15%	15%	15%	20%
セキュリティ（認証）	25%	30%	35%	25%
商業条件（更新の柔軟性）	15%	15%	10%	15%
戦略的適合性（重要度と支出のバランス）	15%	15%	15%	15%

出力：評価軸ごとの内訳と、ベンダーごとの判定を含む、順位付けされた Markdown スコアカード：

• KEEP（≥ 75）— ベンダーのパフォーマンスは良好です。通常どおり更新します
• REVIEW（50-74）— 更新前にベンダーとの四半期ビジネスレビューを予定します
• REPLACE（< 50）— 代替候補の調査を今すぐ開始し、自動更新はしません

ステップ 3 — SLA の遵守状況を測定する

scripts/sla_compliance_tracker.py --input sla_records.json --output sla_report.md を実行します。

各 SLA レコード {vendor, sla_metric, target, actual_last_month, actual_last_quarter, breach_count_12m} について、トラッカーは次の項目を算出します。

• 目標値に対する遵守率（先月、前四半期）
• 月次と四半期の差に基づく傾向分類（改善／安定／悪化）
• クレジット請求の適格性フラグ — breach_count_12m ≥ 2、または actual_last_quarter が target を 0.5pp 超下回る場合、SLA クレジットを請求可能としてフラグを付けます

ステップ 4 — サードパーティリスクを分類する

catalog.json を入力として、scripts/vendor_risk_classifier.py --input catalog.json --profile <industry> --output risk_matrix.md を実行します。

4 つのリスクベクトル（Shared Assessments SIG-Lite 相当）に基づいて、各ベンダーを Critical / High / Medium / Low に分類します。

1. データの機密性 — PII / PHI / カード会員データ / ソースコードへのアクセス
2. 財務的エクスポージャー — 年間支出 × ティア乗数
3. 運用上の依存度 — ティア 1 かつ緊急時の代替手段なし = Critical
4. 規制上のエクスポージャー — 業界プロファイルに応じて重み付け（例：医療・ヘルスケアでは、BAA なしの HIPAA 対応が Critical）

出力：リスクマトリクスの Markdown と、ベンダーごとの緩和策の推奨事項（例：「SOC2 がないティア 1 ベンダーには、次回更新前に SOC2 の証明を求める」）。

ステップ 5 — 推奨事項をまとめる

3 つの成果物を組み合わせて、最終的な BizOps / VMO ダイジェストを作成します。

• 継続利用のメリット上位 3 件（期待を上回るベンダー — 取引拡大を検討）
• 要レビューの協議上位 3 件（ベンダーとの QBR を予定）
• 置き換え候補上位 3 件（代替手段の調査を今すぐ開始）
• 請求可能な SLA クレジットすべて（金額を見積もれる場合はその額も記載）
• 現在、緩和策が講じられていない Critical リスクのベンダーすべて

スクリプト

スクリプト	用途
scripts/vendor_scorer.py	業界プロファイルに合わせて調整する、多次元の 0～100 スコアリング
scripts/sla_compliance_tracker.py	SLA 遵守率、傾向、クレジット請求の適格性
scripts/vendor_risk_classifier.py	緩和策の推奨事項を含む、4 ベクトルのリスク分類

3 つのスクリプトはすべて、--input（JSON）、--output（Markdown の出力先パス）、--sample（組み込みのサンプルデータで実行）、--help を受け付けます。業界固有の重み付けに対応する 2 つのスクリプトでは、--profile {saas,fintech,healthcare,enterprise} も受け付けます。

簡単な例

# Emits a weighted vendor scorecard (industry-tuned dimensions + per-vendor verdict) for the built-in sample catalog
cd business-operations/skills/vendor-management && python3 scripts/vendor_scorer.py --sample

参考資料

• references/vendor_management_canon.md — Gartner / Shared Assessments / ISO 27036 / NIST 800-161 / Forrester / ISACA / Vendr の業界レポート
• references/sla_design_patterns.md — Google SRE Workbook（SLI/SLO/SLA の違い）、Atlassian、ITIL v4、Gartner の SLA 調査、ハイパースケーラーの SLA 文書化パターン
• references/vendor_risk_anti_patterns.md — 実際の侵害に関する事後分析：SolarWinds、Target/HVAC、NotPetya/M.E.Doc、Capital One、Verkada、Okta 2022、log4j

前提条件

1. ユーザーがベンダーカタログを保有しているか、調達記録、SaaS 管理ツール（Vendr / Tropic / Zylo）、または支出データのエクスポートから作成できます。
2. SLA 記録は、ベンダー独自のステータスページ、サポートチケット管理システム、または内部監視ツールから取得します。捏造してはいけません。
3. ユーザーは規制対象データを扱う組織（ほとんどの組織が該当します）を代表して作業していますが、profile フラグを使って、医療・ヘルスケアやフィンテックではセキュリティの重み付けを高くし、規制対象外の B2B SaaS では低くできます。
4. 出力成果物（Markdown のスコアカード、SLA レポート、リスクマトリクス）は、人間が判断するための入力であり、判断そのものではありません。

アンチパターン

• すべてのベンダーを同じティアとして扱う。 ロゴ監視ツールと ID プロバイダーに、同じ厳密さを求めるべきではありません。ティアのフィールドを使用してください。
• 年 1 回のレビューで十分と考える。 ティア 1 のベンダーは四半期ごと、ティア 2 は半年ごと、ティア 3 は更新時にレビューしてください。
• 検証せずにセキュリティ質問票を信頼する。 SIG のチェック項目ではなく、SOC2 レポートを求めてください。references/vendor_risk_anti_patterns.md を参照してください。
• ティア 1 のベンダーに緊急時の代替計画がない。 ベンダーが明日突然利用できなくなった場合、72 時間以内にどう対応しますか？
• オフボーディングを忘れる。 ベンダーを置き換えたり、買収されたりした場合は、データ削除とアクセス権取り消しのチェックリストを実行してください。SolarWinds と Okta は、どちらもその重要性を示しています。
• 勘でスコアを付ける。 決定論的なツールを使用してください。このスキルの目的は、2 人の担当者が同じカタログを同じ方法でスコアリングできるようにすることです。

以下とは異なります

• business-growth/contract-and-proposal-writer — こちらは顧客獲得を目的としたアウトバウンド提案書の作成です。こちらは、すでに料金を支払っているインバウンドベンダーの評価です。
• c-level-advisor/general-counsel-advisor — こちらは契約法（補償、予定損害賠償、知的財産）に関するものです。こちらは、既存の契約に対する運用パフォーマンスの評価です。
• 兄弟ツールのprocurement-optimizer — こちらは支出の分類、サプライヤーの合理化、重複するSaaSの発見に関するものです。こちらは、すでに継続して料金を支払うと決めたベンダーのパフォーマンス評価です。
• engineering/slo-architect — こちらは自社が運用するシステムの内部SLO／エラーバジェット管理に関するものです。こちらは、他社に代行運用を依頼しているシステムの契約上のSLA追跡です。

強制質問ライブラリ（Matt Pocock式の厳しい質問）

/cs-grill-bizopsまたはBizOpsオーケストレーターが、質問を一つずつ順番に行います。質問ごとに推奨回答と典拠を示します。決してまとめて質問しません。

1. 「ティア1の重要度のしきい値は何ですか？支出額（年間$X）ですか、それとも運用上の依存度（ベンダーの障害で収益が止まる）ですか？」 推奨：運用上の依存度です。 典拠：GartnerのTPRM調査、Target／HVAC侵害の教訓 — 支出額だけに基づく階層分けでは、Targetへの攻撃経路となったHVACベンダーのような、支出額は少なくても重要なベンダーを見落とします。

2. 「ティア1ベンダーについて、過去12か月以内に発行されたSOC 2 Type IIレポートを入手していますか？それとも質問票だけですか？」 推奨：レポートを必須にします。質問票は未検証の自己申告です。 典拠：NIST SP 800-161（サプライチェーンリスク管理）、Shared Assessments SIGフレームワーク。

3. 「明日、ティア1ベンダーが突然消えた場合の72時間以内の緊急対応計画はありますか？」 推奨：ベンダーごとの緊急時対応計画を文書化し、毎年テストします。 典拠：NotPetya／M.E.Docのサプライチェーン攻撃、log4jへの対応パターン。

4. 「最後にSLAを実際に適用した（クレジット請求を申請した）のはいつですか？」 推奨：一度もない場合は、SLA条件が弱いのか、違反が報告されていないのかを監査します。 典拠：AtlassianのSLAベストプラクティス、ITIL v4のサービスレベル管理。

5. 「オフボーディングのチェックリストは最新ですか？データ削除、アクセス権の取り消し、鍵のローテーションは含まれていますか？」 推奨：四半期ごとにベンダーを1社選び、手順をリハーサルします。 典拠：SolarWindsおよびOktaの2022年の侵害から得られた教訓。

6. 「規制上の影響範囲はどの程度ですか？HIPAA／GDPR／SOX／PCIの対象ですか？」 推奨：明示的に示します。--profileを通じてセキュリティスコアの重みを高めます。 典拠：ISO/IEC 27036（サプライヤーとの関係におけるセキュリティ）。

深さ優先で進めます。4〜6に進む前に、1〜3を確定します。すべて回答したら、vendor_scorer.py → sla_compliance_tracker.py → vendor_risk_classifier.pyの順に実行します。