調達 vs 運用の所有権：誰がSaaSを決定し、いつ？

運用チームはプロジェクト管理ツールを6週間評価していました。デモを行い、Pilotを実施し、vendorを採点し、明確な優先候補を特定しました。契約の署名準備が整っていました。

法務部門がフラグを立てました。調達は同時に全社展開のために同じvendorの3社を評価していたのです。運用チームは調達が並行プロセスを進めていることを知らず、調達は運用チームが並行プロセスを進めていることを知りませんでした。そして運用チームが選んだvendorは、実際には調達が3位にランク付けしたvendorでした。

COOは政治的にどちらに転んでも難しい決定を下さなければなりませんでした。運用チームの6週間の作業を覆すか、調達の進行中の評価を覆すか。どちらの選択肢も信頼を消費し、先例を設定しました。

根本原因はどちらかのチームの悪い判断ではありませんでした。定義されていない権限構造でした。誰も答えていなかった問いがありました。運用チームはいつ決定し、調達はいつリードし、規模やスコープが閾値を超えた場合にどのように引き継ぐのか。

このガイドがその問いに答えます。

重要なポイント：SaaSの調達 vs 運用の所有権

• ミッドマーケット企業のSaaS購入の65〜75%は調達を完全に回避しています。事業部門の購入者（運用、営業、マーケティング、HR）が直接購入の意思決定を下しています（Gartner SaaS spending research, 2024）。
• 平均的なミッドマーケット企業はITが把握している以上に40〜60%多くのSaaSアプリを運用しています。シャドーITが認可されたポートフォリオを大幅に超えて実際の規模を膨らませています（Productiv State of SaaS Sprawl, 2024）。
• 重複するSaaS支出は、中央レジストリのないミッドマーケット企業でSaaS予算の10〜30%を平均しています。2つのチームが重複するツールを購入することが、防止可能な無駄の最大の単一原因です。
• 正式な調達を持つ企業での$2.5万超のツールの平均調達承認サイクル時間は6〜10週間です。それに対し、閾値以下の運用主導の意思決定は2〜5日です（Deloitte CPO Survey）。
• 150〜500名の従業員規模でSaaS所有権を正式化した企業は、従業員500名時点でのSaaS支出が、危機に迫られるまでガバナンスを先送りにした企業より従業員1人あたり約40%少なくなります（Forrester technology governance maturity research）。

意思決定者分割モデル

意思決定者分割モデルは、契約価値と機能的特殊性の2軸に基づいてSaaS購入権限を割り当てます。調達は、契約価値が重大な閾値（通常$5万以上）を超えるとき、またはツールがポートフォリオ統合がユーザー固有の適合性より重要な部門横断型インフラの場合にリードします。運用は、ツールが部門固有で閾値以下であり、ユースケースの知識が意思決定を支配する場合にリードします。共同所有権は中間帯（$1万〜$5万）に適用され、運用が要件を定義して評価を実施し、調達がRFPプロセス、契約条件、vendorデューデリジェンスを管理します。明確なタイブレーカールール付き（運用はキャパビリティで勝ち、調達は価格/条件で勝ち、セキュリティはリスクで勝ちます）。

ほとんどのミッドマーケット企業でSaaS権限が未定義である理由

ミッドマーケット企業は通常、調達問題を経験するまで正式な調達機能を構築しません。その頃には非公式な購入文化が確立されており、変えることが難しくなっています。DeloitteのGlobal Chief Procurement Officer Surveyは一貫して、ミッドマーケット段階で調達権限を正式化していない企業が、定義された所有権構造を持つ同規模企業より技術カテゴリーに20〜35%多く支出することを示しています。

進化は通常このような形になります：

• 従業員0〜50名： 創業者またはCOOがすべてを承認。非公式だが機能的。CEOはすべてのツールを知っています。
• 従業員50〜150名： マネージャーレベルでの非公式な承認と財務のスポットチェック。ほとんどの購入は可視性の閾値以下で発生します。
• 従業員150〜500名： IT、財務、運用がそれぞれ異なる購入に関わり、一貫したプロセスはありません。衝突が発生します。シャドーITは深刻です。

150〜500名の範囲でSaaS権限を正式化する必要があります。組織はすべての購入に対するCEOレベルの可視性には大きすぎますが、ガバナンスの基盤を構築するほど整備されていません。そしてSaaS支出は（通常年間$30万〜$100万以上）構造を正当化するほど大きくなっています。Forresterのテクノロジーガバナンス成熟度に関する調査は、150〜500名の従業員規模をテクノロジー支出管理における最高リスクの時期として特定しています。この成長段階で権限構造を正式化した組織は、危機が強制するまでガバナンスを先送りにした組織より500名時点でのSaaS支出が従業員1人あたり40%少なくなることを示しています。

3つの所有権モデル

モデル1：閾値ベースの権限

ミッドマーケット企業に最も一般的で実践的なモデル。権限は契約価値に基づいて割り当てられます：

メリット： 伝えやすく、適用しやすく、財務的な重要性にマッピングされます。

デメリット： 閾値の回避。チームは閾値を下回るために購入を複数の小さな契約に分割します。「遡及」ルールが必要です。同じvendorからの購入や同じ機能を提供するツールは、構成方法に関わらず閾値目的で集計されます。これはSaaSの散乱問題がどのように複合するかでもあります。個別には問題ないように見える小さな閾値以下の購入が、誰も監視していないポートフォリオに蓄積されます。

モデル2：カテゴリーベースの権限

ツールカテゴリーによって権限が割り当てられます：

メリット： カテゴリーの専門知識が意思決定を主導します。HRがHRツールを所有し、Revenue OperationsがSaaSツールを所有します。専門分野でより良い意思決定が生まれます。

デメリット： カテゴリーの境界が曖昧です。CRMは営業ツールです。しかしITツールでもあり、顧客データツールでもあります。カテゴリーの争いにはタイブレーカーが必要です。

モデル3：ハイブリッドモデル（閾値以下では運用が決定し、調達がアドバイス）

新興の調達機能を持つ企業に適した現実的な中間的アプローチ：

• $1万以下：IT登録要件を持つ運用が決定します。調達はアドバイザーとして利用可能ですが、承認権限はありません。
• $1万〜$5万：運用が評価をリードし、調達がRFPプロセス、契約レビュー、交渉のアドバイスを行います。未解決の場合はCOOへのエスカレーションを伴う共同決定。
• $5万超：調達がプロセスをリードし、運用がキャパビリティを評価・定義する主要利害関係者。共同決定。

核となる原則： 調達の付加価値はプロセスの専門知識（RFP管理、契約交渉、vendorデューデリジェンス）とポートフォリオ監視（重複防止、総支出管理）です。運用の付加価値はユースケースの知識（ツールが何をする必要があるか、ワークフローにどう適合するか）です。調達が加速ではなくボトルネックになるとき、または運用が認識される遅延を避けるために調達を回避するときに失敗します。閾値超のツールの場合、SaaS RFPの進め方は調達主導の評価を十分な速さで進めてチームが迂回しないようにするための3週間プロセステンプレートです。

適切なモデルの選択

SaaS権限マトリクステンプレート

会社向けにこのマトリクスを構築してください。ポリシーを公開する前にすべてのセルを埋めます。

購入後の所有権の割り当て

「誰が決定するか」と同様に重要な問い：契約締結後にvendor関係を誰が所有するか。

これはほとんどのガバナンスフレームワークが止まる場所です。誰が何を承認できるかを定義して、所有権を未定義のままにします。そして元のChampionが退職し、更新が近づき、誰も条件を知らず、契約がデフォルトで自動更新されます。

購入後の所有権割り当てテンプレート：

$1万以下の購入の場合、1人がすべての3つの役割を担うことがあります。$5万超の購入の場合、これらは別の人物であるべきです。

この割り当ては契約署名時に文書化し、SaaSレジストリに保存し、毎年レビューすべきです。

エスカレーション意思決定ツリー

運用と調達がSaaS購入決定に同意しない場合、エスカレーションパスを衝突が発生する前に定義する必要があります。

標準エスカレーションツリー：

これは新規購入か更新か？
├── 新規購入
│   ├── 閾値以下？ → 権限マトリクスに従い運用が決定
│   └── 閾値超？
│       ├── 運用と調達が同意？ → 経営陣への共同推奨
│       └── 運用と調達が同意しない？
│           ├── キャパビリティに関する不一致？ → 運用の勝ち（要件を定義するため）
│           ├── 価格/条件に関する不一致？ → 調達の勝ち（その専門領域のため）
│           ├── vendorリスクに関する不一致？ → IT/セキュリティの勝ち（リスクはその専門領域のため）
│           └── 戦略に関する不一致？ → COOが48時間以内に決定
└── 更新
    ├── $1万以下？ → ビジネスオーナーが決定。商業的オーナーが交渉
    └── $1万超？ → ビジネスオーナー + 商業的オーナーの共同決定。不一致の場合はCOO

「COOが48時間以内に決定する」ルールが重要です。終わりのないエスカレーションはモメンタムを失わせます。プロセスに時間制限を組み込んでください。

一般的な失敗パターン

調達が実現者ではなくゲートキーパーになる。 閾値超のすべての購入に調達のサインオフが必要で、調達が6週間サイクルを実施するとき、チームはプロセスを回避します。解決策は調達のサービスレベル基準です。$2万の購入は3週間ではなく5営業日以内に調達の対応があるべきです。

プロセスのない権限ポリシー。 誰が何を承認できるかを定義することは、承認を追跡するシステム、新しいツールを登録するためのSaaSレジストリ、今後の満了を管理するための更新カレンダーがなければ役に立ちません。

運用が無視するポリシー。 執行されないポリシーはポリシーがないより悪いです。ガバナンスの見かけを作りながら実態がありません。チームが実際に従うワークフローの周りにポリシーを構築してください。承認フォーム、Slackチャンネル、SaaSレジストリ。ポリシーは余分な手順ではなく最小限の追加手順を必要とするべきです。

契約署名時の所有権が未定義。 契約が署名された瞬間に、ビジネスオーナー、技術的オーナー、商業的オーナーが割り当てられ記録されるべきです。署名時に行われなければ、遡及的に行うことが難しくなります。これは複雑な更新条件を持つ契約では特に重要です。SaaS契約の警戒すべき点ガイドは、誰かが実際に更新カレンダーを所有している場合にのみ重要になる自動更新と通知期間の条項を説明しています。

ポリシーを定着させる

ガバナンスポリシーが失敗する最も一般的な理由は、ワークフローではなく文書として設計されていることです。文書は無視できます。ワークフローは仕事の仕方の一部です。McKinseyの調達機能における組織変革に関する調査は、既存の承認ワークフローに組み込まれた調達ポリシーが、コンテンツの品質に関わらず、単独のポリシー文書より3〜4倍高いコンプライアンス率を達成することを示しています。

ポリシーを定着させるために：

1. レジストリを構築する。 すべての承認済みツールを中央ツール（最初はスプレッドシートでも可、スケールに応じて適切なSaaS管理プラットフォームへ）にオーナー、コスト、更新日、ステータスとともに登録します。

2. 更新アラートを自動化する。 $5千超のすべての更新の90日前に、商業的オーナーに自動リマインダーが届くようにします。この一つの変更だけで更新の多くの驚きを排除できます。

3. コンプライアンスを簡単なパスにする。 $3千のツールの承認ワークフローは30分ではなく10分かかるべきです。プロセスが苦痛であれば、チームはそれを回避します。

4. 例外を公開してレビューする。 チームがプロセス外でツールを購入した場合、他のチームリーダーが見るフォーラムでそれに対処します。シャドーITは結果がない場合に持続します。

5. 四半期ごとにポートフォリオをレビューする。 簡潔なポートフォリオレビュー（総支出、追加・削除されたツール、今後の更新）は、毎回の詳細な監査なしにリーダーシップの可視性を最新に保ちます。

ガバナンスが機能しているかの測定

運用の満足度スコアは明示的に追跡する価値があります。運用が一貫して調達プロセスを低く評価する場合、ポリシーは回避策を生む摩擦を作り出しています。その摩擦は診断して解消する価値があります。

Rework Work OpsはどのようにProcurement-Operations連携をサポートするか

調達と運用が別々のシステムで作業するとガバナンスは崩壊します。調達はスプレッドシートとチケットキューに住み、運用はプロジェクトツールと共有受信ボックスに住みます。この間の引き継ぎが重複する評価、シャドーIT、更新サプライズの発生源です。

Rework Work Opsは両機能に共有サーフェスを提供します。vendorレジストリは各部門が見ることができる構造化データベースとして管理されます。すべてのツール、オーナー、更新日、支出ティア、承認ステータスが一か所に。調達は「$1万超で90日以内に更新される契約」でフィルタリングでき、運用は「現在評価中のカテゴリー内のツール」でフィルタリングできます。重複する評価は2番目のチームが6週間の並行RFPに無駄な時間を費やす前に表面化されます。

承認ワークフローテンプレートは上記の意思決定者分割モデルに直接マッピングされます。$3千のリクエストは軽量チェックリストとともに部門責任者にルーティングされます。$2.5万のリクエストには自動的に調達がアドバイザーとして追加され、RFPテンプレートが起動されます。$6万のリクエストは運用が利害関係者として参加した調達主導へとエスカレートされます。これらすべてがSlackによる追跡なしで、所有権の曖昧さなしに行われます。1ユーザー月額$6から、Work Opsは1回の重複購入を防ぐだけで価値を正当化できます。

よくある質問

参考情報

• SaaS購入意思決定ツリー：購入・構築・既存ツール拡張の判断：ガバナンス構造の中で機能する意思決定フレームワーク
• 6週間を無駄にしないSaaS RFPの進め方：閾値超の購入に対して調達主導のプロセスがどのように見えるか
• SaaSの散乱問題：そのサインと解決策：ガバナンスが長期間不在の場合に何が起きるか
• SaaS統合：ツールを削除するか維持するかの判断：優れたガバナンスが不必要にする整理作業
• 購入90日後のSaaS ROI測定：ビジネスオーナーの説明責任を90日時点の測定可能な成果に結びつける方法
• 部門向けAIガバナンスポリシー：AI SaaS購入を管理するための権限フレームワークの拡張方法