SaaS統合：ツールを廃止すべきか維持すべきか
ITリードはCOOのためにスタック概要を準備するよう依頼されました。数時間で完了すると思っていた作業に3日かかりました。会社には81のアクティブなSaaSサブスクリプションがありました。そのうち14は機能が重複していました。6つは過去90日間のアクティブユーザーが3人未満でした。4つは退社から6ヶ月以上経過した従業員向けにプロビジョニングされていました。
年間総支出は$340,000。ITリードの見積もりでは、$80,000〜$120,000が統合と廃止によって回収可能でした。
誰も不注意ではありませんでした。スタックは4年間の通常の事業運営の中で成長していました。チームは必要なツールを見つけ、承認を得て、プロジェクトに使い、そして次に移っていました。契約は自動更新され、使用状況が変化していきました。全体像を把握しているオーナーが誰もいなかったのです。
重要データ：SaaS統合の数字
- 中堅企業の平均SaaSアプリケーション数は130以上で、2020年の80から増加しています（BetterCloud、2024 SaaSOpsの現状）。
- Gartnerによれば、組織は未使用または重複ライセンスでSaaS支出の25%を無駄にしており、SaaS支出$75Mの企業では年間約$18Mに相当します。
- Productivの2024年ベンチマークによれば、SaaSアプリの44%が機能的に重複または重複しており、複数のツールが同じカテゴリの問題を解決しています。
- 体系的な統合プログラムを実施した企業は、12ヶ月以内に年間SaaS支出の20〜35%を回収しています（BetterCloud、Zyloベンチマーク）。
- 正式なSaaS管理を行っていない組織では、シャドーITが総SaaS支出の30〜40%を占めています（Gartner）。
統合ROIの優先順位
統合がすべて同じ効果をもたらすわけではありません。節約額の大きい順に：支出統合（同じカテゴリの重複ライセンスの削減）は通常、総節約額の40〜50%を回収し、管理統合（より少ないツール全体でのプロビジョニング、SSO、ベンダー管理のITオーバーヘッド削減）は25〜35%を回収し、統合コスト削減（重複システム間のミドルウェア、カスタムコネクタ、データ同期コストの排除）が残りの15〜25%を回収します。節約額が即時かつ測定可能なため、まず支出統合を優先してください。管理と統合の利益は6〜12ヶ月にわたって複利的に積み上がります。
このガイドは、ITリードの3日間の発見作業を繰り返し可能な四半期ごとの演習に変える統合プロセスです。廃止案が提示されたときに最も大きな声を上げる人に依存せず、維持または廃止の判断を下すフレームワークを運用リーダーに提供します。新しいツールが構造化されたレビューなしに承認され続けるという根本的な問題があれば、SaaS購買デシジョンツリーが時間をかけて統合要件を減らすための上流フレームワークです。
統合が期待以上の回収をもたらす理由
ほとんどの企業が統合によって回収できる額を過小評価するのは、支出が数十の明細に分散されており、どのツールも単独では問題に見えないからです。BetterCloudのSaaSOps現状レポートは、中堅企業の平均がSaaS予算の25〜40%を未使用または重複ツールに無駄遣いしており、これは意図的な棚卸しが表面化するまで検出されないことが多いと指摘しています。しかし計算は複利的になります。
- 年間$5,000のツールにアクティブユーザーが2人なら、アクティブユーザー1人あたりのコストは年間$2,500です。
- 維持予定の年間$30,000のプラットフォームに既にある機能と重複する年間$20,000のツールは、負の価値のために$20,000を支払っています（機能ではなく複雑性を追加しています）。
- 統合棚卸し中に自動更新されたツールは、すでに廃止を決定したものに対して1年分の費用を支払わせました。
目標は積極的に削減することではありません。正確に削減することです。合理的な使用状況で真の価値を提供しているツールは維持すべきです。この基準を満たさないツールは、個々のチームがどれほど気に入っていても、コスト、複雑性、IT管理時間を消費しています。
ステージ1：スタック全体の棚卸し
見えないものは削減できません。棚卸しステージは、判断を下す前に現在のSaaSスタックの完全で正確な全体像を構築することです。
スタック全体の発見
多くのITリードはスタックを把握していると思っています。実際には15〜30%を見落としています。シャドーIT（チームや個人のクレジットカードで購入されたツール、ITが関与せずに有料に転換した無料試用、買収によって取得したツール）が実際のSaaS支出の相当部分を占めることがよくあります。GartnerのSaaS管理とシャドーITに関する調査によれば、正式なSaaS管理プログラムのない組織では、シャドーITが総技術支出の30〜40%を占めると推定されています。
SaaS発見ソース：
| ソース | 発見できるもの |
|---|---|
| 財務・買掛金記録 | 買掛金を通じて請求されたすべてのもの |
| 法人カード明細 | 従業員による直接請求 |
| AWS/Azure/GCPマーケットプレイス | クラウドプラットフォーム経由で購入されたSaaS |
| SSO/IdPログ | Okta、Azure AD、Google Workspaceに接続されたツール |
| ブラウザ拡張機能の棚卸し | ブラウザ拡張経由でインストールされたSaaSツール |
| メールドメイン分析 | 会社のメールアドレスを使ったSaaS試用サインアップ |
| 従業員アンケート | 直接質問：「承認済みリストにないツールを何か使っていますか？」 |
単一のソースで完全な全体像は得られません。少なくとも最初の4つを並行して実施してください。
棚卸しスプレッドシートの作成
発見された各ツールについて、以下を記録します。
| フィールド | 重要な理由 |
|---|---|
| ツール名とカテゴリ | 重複マッピングを可能にする |
| 年間コスト | 深く棚卸しする価値があるものを優先する |
| シート数（契約数・プロビジョニング数・アクティブ数） | 過剰プロビジョニングを表面化する |
| 契約更新日 | 棚卸し中の不意の自動更新を防ぐ |
| 契約期間と通知要件 | 退出タイムラインを決定する |
| オーナー（維持・廃止決定の責任者） | 説明責任を割り当てる |
| 最後のアクティブ使用（日付） | 放棄されたツールの素早いシグナル |
| 主な使用ケース | 重複マッピングを可能にする |
| 使用中の統合 | 廃止計画において重要 |
SaaSスタック棚卸しテンプレート：
| ツール | カテゴリ | 年間コスト | シート数：契約/アクティブ | 更新日 | 通知要件 | オーナー | 最終使用 | 主な使用ケース | 統合 |
|------|----------|-------------|------------------------|---------|---------|-------|---------|----------------|------|
このスプレッドシートは以降のすべての作業の作業文書です。常に最新の状態に保ってください。新しいツールが承認されるかツールが廃止されるたびに更新します。
ステージ2：重複マッピング
スタック全体を把握したら、重複する機能を提供しているツールをマッピングします。ここで統合の機会が見えてきます。
カテゴリグループ分け
ベンダーカテゴリではなく機能でツールをグループ化します。
- コミュニケーション： メッセージング、メール、ビデオ会議
- プロジェクトとタスク管理： プロジェクト追跡、ToDoリスト、ワーク管理
- ドキュメントと知識管理： Wiki、ドキュメント、ファイルストレージ
- CRMと営業： 連絡先管理、Pipeline追跡、セールスエンゲージメント
- HRと人材管理： HRIS、パフォーマンス、採用、Onboarding
- 分析とBI： Dashboard、レポーティング、データ視覚化
- カスタマーサポート： チケット管理、ライブチャット、ヘルプデスク
- 財務と会計： 経費管理、請求書発行、調達
各カテゴリで、会社が支払っているすべてのツールにフラグを立てます。3つのツールを持つカテゴリにはほぼ常に統合の可能性があります。
重複ヒートマップ
各カテゴリのシンプルなヒートマップを作成します。
| カテゴリ：プロジェクト管理 | ツールA | ツールB | ツールC |
|---|---|---|---|
| タスク追跡 | X | X | X |
| プロジェクトタイムライン | X | X | |
| リソース配分 | X | ||
| 時間追跡 | X | X | |
| クライアント向けプロジェクト | X | ||
| レポーティング | X | X |
ツールAとツールBの機能重複が70%以上なら、それは統合候補です。ツールBにはなくツールAにある機能があれば、それは計画が必要な移行依存関係です。
ステージ3：使用率スコアリング
重複は統合が可能な場所を示します。使用率スコアリングはどのツールを維持するかを示します。
5基準使用率マトリックス
重複セット内の各ツールを5つの基準で1〜5でスコアリングします。
| 基準 | 定義 |
|---|---|
| アクティブユーザー率 | 過去30日間にログインしたプロビジョニング済みユーザーの割合 |
| ワークフロー重要度 | ツールが突然消えた場合のチームアウトプットへの影響 |
| 統合の深さ | 現在使用中の統合の数と重要性 |
| 置き換えの難しさ | 機能を別のツールに移行するのはどれほど難しいか |
| コスト効率 | 年間コスト1ドルあたりの提供価値 |
スコアリングガイド：
| スコア | アクティブユーザー率 | ワークフロー重要度 | 統合の深さ | 置き換えの難しさ | コスト効率 |
|---|---|---|---|---|---|
| 5 | 80%超 | 事業にとって重要 | 5以上の統合 | 移行90日超 | 高価値、合理的なコスト |
| 4 | 60〜80% | 重要 | 3〜5の統合 | 移行30〜90日 | 良好な価値 |
| 3 | 40〜60% | 有用 | 1〜2の統合 | 移行2〜4週間 | 適度な価値 |
| 2 | 20〜40% | 時々使用 | APIアクセスのみ | 移行2週間未満 | 低い価値 |
| 1 | 20%未満 | ほとんど使用されない | 統合なし | 離脱が容易 | 非常に低い価値 |
合計スコアによって処置が決まります。
- 18〜25： 維持。このツールは真の価値を提供しており、置き換えるにはコストがかかるほど統合されています。
- 11〜17： 評価。このツールは一定の価値を提供していますが、検討する価値のある統合の道筋があるかもしれません。
- 5〜10： 廃止候補。使用率が低く、統合も少なく、ワークフロー上の重要性も低い。維持コストが置き換えの労力を上回っています。
スコアリングのよくある間違い
使用率ではなく機能でスコアリングする。 誰も使っていない印象的な機能を持つツールは、機能のない誰も使っていないツールと同じスコアになります。アクティブ使用率が最初のフィルタです。
最大の支持者がスコアを決めるのを許す。 ツールの購入を推進した人は維持のために戦います。オーナーの自己評価に依存するのではなく、ツール自体からのデータ（ログイン数、アクティブユーザー、機能使用ログ）を使って使用率データを取得します。維持するツールの真のコストを評価する際は、SaaSのTCOモデリングが、単純なライセンス比較では見落とされる維持を決定したツールの真のコストをモデル化するための5カテゴリフレームワークを提供します。
統合数にない非公式なワークフロー依存関係を無視する。 ツールにAPI統合はないかもしれませんが、そこから別のプロセスを動かすスプレッドシートに人々が手動でエクスポートするためにワークフローに深く組み込まれている場合があります。公式な依存関係だけでなく、非公式な依存関係も確認してください。
ステージ4：移行計画を伴う廃止シーケンシング
スコアリングが完了すると、廃止候補のリストができます。シーケンシングは決定と同様に重要です。誤った順序で削減するか、移行計画なしで削減すると、プロジェクトを完遂するための政治的意志を失わせる混乱が生じます。
廃止シーケンシングの原則
まずゼロインパクトのツールから始める。 5〜7スコア（使用率が非常に低く、統合なし、アクティブユーザーなし）のツールは、予算を回収し勢いを生み出す速い成果です。まずこれらを廃止します。
重複ペアをまとめて移行する。 2つのツールが重複していて1つに統合する場合、移行を一緒に計画します。ユーザーにはギャップではなく、明確な移行経路が必要です。
契約更新日を尊重する。 契約が2ヶ月後に自動更新されるのに、3ヶ月後に廃止を計画しても意味がありません。更新日と廃止計画を照合します。更新通知の締め切りをカレンダーに登録します。窓が閉まる前、自分の準備が整ったときではなく、通知を提出する必要があります。SaaS契約の危険信号ガイドでは、自動更新通知期間の長さと通知要件が契約ごとにどのように異なるかを説明しています。
重要なツールは並行稼働する。 高使用率のツールを廃止する際は、移行の最後の2〜4週間、旧ツールと新ツールの両方を並行稼働します。ユーザーが移行する前に完全に切り替えないでください。
20ステップ廃止チェックリスト
廃止前（第1〜2週）：
- 決定が下されツールオーナーに伝達済み
- 契約更新日を確認してカレンダーに登録済み
- 必要に応じて非更新の通知を送付済み
- ツールのすべてのユーザーを特定済み
- ツールに依存するアクティブなワークフローを文書化済み
- ツールに依存する統合を特定済み
- データエクスポート要件の範囲を確定済み（形式、量、タイムライン）
- 移行先を確認済み（この使用ケースの代替ツールは何か？）
移行（第3〜6週）：
- 移行タイムラインをユーザーに伝達済み
- 必要な形式でデータをエクスポート済み
- 代替ツールにデータをインポート済み（または代替がない場合はアーカイブ済み）
- 廃止ツールの統合を再構築または無効化済み
- 代替ツールでユーザーをプロビジョニング済み
- 代替ツールについてユーザーのトレーニングを完了済み
- 並行稼働期間を設定済み（旧ツールはまだアクセス可能、新ツールはアクティブ）
廃止（最終週）：
- 残りのデータをエクスポートしてアーカイブ済み
- すべてのユーザーの移行を確認済み
- 確認受領とともにキャンセルを提出済み
- ITアクセス・SSO接続を無効化済み
- 請求からコストを確認・除外済み
- スタック棚卸しスプレッドシートを更新済み
統合の測定
統合後6ヶ月および12ヶ月でこれらを追跡します。
| 指標 | 目標 |
|---|---|
| SaaS支出削減 | 統合前支出の20〜35% |
| ツール数削減 | 開始数によるが、25〜40%削減を目標 |
| IT管理時間 | ツール関連サポートチケットの減少 |
| エンドユーザー生産性への影響 | 自己申告満足度調査と実際のアウトプット指標 |
| シャドーITインシデント | 未承認ツールの発見件数の減少 |
注意深く見るべき指標が一つあります。統合後60日間のエンドユーザー生産性です。McKinseyの組織変革管理に関する調査によれば、構造化されたユーザーコミュニケーションと移行サポートを含む技術統合プロジェクトは、統合を純粋にコスト削減と捉えるプロジェクトよりも40〜50%速く完全な生産性回復を達成することが分かっています。人々が真に使っていたツールを削除し、十分な移行サポートを提供しなかった場合、財務ケースを損なう生産性への影響が見られます。統合による節約は予算に現れるべきで、生産性コストはチームに現れるべきではありません。
ReworkはSaaS統合の統合先としてどう機能するか
ほとんどの中堅統合では、最終的に同じ4カテゴリを対象とします。CRM、ワーク・プロジェクト管理、チームチャット、タスク追跡です。これらのツールは高支出、高重複で、日常ワークフローに深く組み込まれています。典型的なスタック問題：SalesforceかHubSpotのCRM（$50〜150/ユーザー）、AsanaかMondayのプロジェクト追跡（$20〜30/ユーザー）、Slackのチャット（$12〜18/ユーザー）、別のタスクツールかセールスエンゲージメントプラットフォーム（$15〜40/ユーザー）。50人チームの場合、4社、4つの請求サイクル、4つのSSO設定、維持すべき4セットの統合にかかる費用は簡単に年間$80K〜$180Kになります。
Reworkは4つをワンプラットフォームで置き換えます。CRMとSales Opsは$12/ユーザー/月〜、Work Ops（プロジェクト追跡 + チャット + タスク）は$6/ユーザー/月〜。同じ50人チームで年間総支出は$10,800〜$14,400となり、同等品の単体ツールと比較して75〜85%の削減となります。統合の節約も複利的です。1つのSSO接続、1つの管理コンソール、Sales Pipelineからプロジェクト納品までをカバーする1つのデータモデル。Reworkに統合したチームは通常4〜8週間でフル移行を完了します。単体ベストオブブリードベンダーに統合してその周りに3つのツールを統合するよりも速いです。
よくある質問
関連ガイド
- SaaS乱立問題：その兆候と解決策：18ヶ月以内に再び統合が必要にならないためのガバナンス変更
- SaaSのTCOモデリング：表示価格を超えて：維持を決定したツールの真のコストのモデリング方法
- SaaS購買デシジョンツリー：購入・内製・既存ツール活用の選び方：将来の統合要件を減らすための事前デシジョンフレームワーク
- SaaSベンダーの切り替え：移行の隠れたコスト：廃止シーケンシングに影響する移行コストモデル
- 調達部門と運用部門の所有権：統合プロセスを誰が所有し、チームをまたいでどのように実行するか
- データ移行計画：高リスクツールの廃止のための移行コンポーネントの計画方法
