「社内のSaaSが増えすぎて、誰が何を使っているかもう追えない」という声は、情シス担当者の間で年々大きくなっています。国内企業の約3割が11種類以上のSaaSを利用しており、従業員5,001名以上の大企業では21%が51種類超を抱えているという調査結果があります。

しかし問題は種類の多さではありません。管理と統制が追いつかないまま増殖し続けていることが、コストの垂れ流し、セキュリティの穴、ガバナンスの崩壊を同時に引き起こします。

本記事では、SaaSスプロールの定義から発生原因、自社の状態を確認する兆候チェック、段階的な対策まで、情シス担当者が実践できる形で整理します。

SaaSスプロールとは何か

SaaSスプロールとは、企業内のSaaSが全社的な管理・統制のないまま各部門の判断で無秩序に増殖し、誰が何を使っているか把握できなくなった状態です。定義を正確に理解することで、シャドーITとの混同も解消できます。

SaaSスプロールの定義

スプロールはもともと都市計画の用語で、市街地が無秩序に郊外へ広がっていく現象を指します。SaaSスプロールはこの言葉をIT管理の文脈に転用したものです。

注意すべき点は、SaaSの数が多いこと自体は問題ではないということです。50種類のSaaSを使っていても完全に管理されているならスプロールではなく、10種類でも誰も把握していなければスプロール状態に該当します。管理の欠由が本質であり、契約したことさえ知らないSaaSが存在するという状態がスプロールの核心です。

シャドーITとの違い

シャドーITはIT部門が把握していない未承認の機器・ソフトウェア・クラウドサービス全般を指す広い概念で、個人デバイスの持ち込みやUSB利用なども含まれます。

SaaSスプロールはSaaSに特化した現象で、情シスが承認した上で導入したSaaSも含む点が異なります。承認済みであっても、その後の利用状況・コスト・アカウント管理が追いついていなければスプロールの問題に含まれます。両者の関係としては、シャドーITの拡大がSaaSスプロールを加速させるという相互作用があります。

シャドーITとは

SaaSスプロールが発生する4つの原因

SaaSスプロールはほぼ例外なく意図せず発生します。背景にある構造的な原因を把握することが、根本的な対策への入り口になります。

原因①　現場主導のSaaS導入

各部門の担当者がIT部門を介さずにSaaSを導入できる環境が、スプロールの最も根本的な原因です。SaaSはインターネット環境とクレジットカードがあれば即日から利用を開始できるため、営業部門が商談管理ツールを、マーケティング部門がメール配信ツールを、人事部門がHRツールを、それぞれ独自の判断で契約するケースが日常的に起きています。

業務効率化への意欲が高い現場ほどこのパターンに陥りやすいという皮肉があります。既存のツールでは不十分だと感じた担当者が試用を始め、便利だからそのまま使い続けるというごく自然な判断の積み重ねが、情シスが把握しきれない規模のスプロールを生み出します。

原因②　承認プロセスの不備

新規SaaS導入時の申請・承認フローが存在しないか、存在しても形骸化している状態が第二の原因です。フリープランで試用を始めてそのまま有料プランに移行した、チームで使い始めていつの間にか部門全体に広がったというケースでは、情シスへの届け出が行われないまま契約が確定します。

承認プロセスが厳しすぎると現場が回避行動をとり、緩すぎると何でも通ってしまいます。どちらのケースでも、情シスの関与なしにSaaSが増え続ける構造が維持されます。

原因③　組織の成長・合併・買収

組織が拡大するにつれて部門数が増え、各部門が独自のSaaSセットを持つようになります。M&Aによる組織統合は特に深刻なスプロールを引き起こします。買収先が使っていたSaaSが持ち込まれ、既存のSaaSと機能が重複するケースが多発します。

統合後の整理を先送りにしているうちに、両社のSaaSが並行稼働し続け、コストと管理負担が二重になります。組織統合のフェーズでSaaS棚卸しを計画に組み込まない場合、このリスクは特に高くなります。

原因④　退職・異動後のアカウント放置

担当者の退職や異動が発生した後も、契約や利用状況が引き継がれないまま放置されるケースが多く発生します。退職者が管理していたSaaSは担当者がいなくなった後も自動更新され続け、気づかれないまま何ヶ月も費用が発生します。このような誰も管理していないSaaSをゾンビSaaSと呼ぶことがあります。

退職者のアカウントが削除されずに残るゾンビアカウント問題も同時に発生します。コストの無駄であるだけでなく、後述するセキュリティリスクの直接的な原因になります。

SaaSスプロールが引き起こす3つのリスク

管理されないまま放置されたSaaSは、コスト・セキュリティ・ガバナンスの三方向から組織にダメージを与えます。それぞれのリスクの深刻さを確認します。

リスク①　コストの無駄（ゾンビコスト）

最も可視化しやすいリスクがコストの無駄です。未使用ライセンスへの惰性課金、同一用途のSaaSが複数部門で重複契約されているケース、担当者退職後に誰も解約しないゾンビSaaSへの支出が積み重なります。

個々の金額は少額でも、数十種類のSaaSに5名から10名分の未使用ライセンスが散在すると、年間で数百万円規模の無駄が生じます。年間契約型のSaaSは自動更新のタイミングを逃すと一年分の費用が発生するため、更新前の見直しが不可欠です。適切な管理があれば避けられたコストが、管理不在によって垂れ流され続けます。

リスク②　セキュリティの穴

退職者アカウントの放置が最大のセキュリティリスクです。SmartHRの調査では、58.0%の企業が退職者アカウントの不正利用を懸念していると回答しています。アカウントが残ったままになると、元従業員本人による不正アクセスのリスクに加え、パスワードが流出した場合に第三者が悪用する経路にもなります。

情シスが把握していないシャドーITのSaaSは、セキュリティ設定が施されていないまま業務データが流れる状態になりやすく、ISMSやGDPRなどのコンプライアンス要件を満たさないSaaSが野放しになれば監査・認証の取得にも影響が出ます。どのSaaSにどのデータが格納されているかさえ把握できなければ、インシデント発生時の影響範囲の特定も困難になります。

‍SaaSセキュリティとは

リスク③　ガバナンスとID管理の崩壊

誰がどのSaaSにどの権限でアクセスできるかを把握できない状態は、ITガバナンスが機能していないことを示します。SaaSスプロールが進むと各SaaSのアカウント管理が現場担当者に委ねられ、権限設定が属人化します。異動や組織変更があっても適切な権限変更が行われず、必要以上のアクセス権を持ったままの従業員が発生します。

監査対応では「全SaaS利用状況の一覧を提出してください」という要求に即座に答えられなくなります。SOX法対応やISMS認証の更新時に、SaaS利用状況の記録が整備されていないことが問題視されるケースも増えています。SaaSガバナンスとは

自社がSaaSスプロール状態か確認する5つの兆候

次の5つの兆候のうち3つ以上当てはまる場合、SaaSスプロールがすでに進行していると判断できます。現状確認のチェックリストとして活用してください。

兆候① 全社のSaaSをリストアップできない

自社で今いくつのSaaSを使っているかという問いに即答できない場合、可視化が不十分です。利用中のSaaSを網羅したリストが存在しないか、存在しても最新の状態に保たれていない状態はスプロールの典型的なサインです。把握できていないSaaSは管理の対象にできません。

兆候② 退職者のアカウントが残っているかわからない

直近1年間に退職・異動した従業員のSaaSアカウントが適切に削除・変更されているかを確認できない場合、アカウント管理が機能していません。削除されているはずだという認識は、確認できていないことと同義です。ゾンビアカウントはコストとセキュリティの両面でリスクになります。

兆候③ 同一用途のSaaSが複数部門に存在する

ビデオ会議ツールが営業部門ではZoom、全社ではGoogle Meet、別の部門ではMicrosoft Teamsというように、同一用途のSaaSが複数並立しているケースはスプロールの典型例です。重複契約の整理だけでも大きなコスト削減効果が見込まりますが、そのためには実態の可視化が前提になります。

兆候④ 誰が承認したかわからないSaaS契約がある

経費精算や社内請求書を確認すると、誰がいつ承認して契約したのか追えないSaaSが出てくる場合は要注意です。情シスの承認プロセスを経ずに現場が独自に契約したSaaSが含まれている可能性が高く、セキュリティ審査なしに業務データが流れている状態を意味します。

兆候⑤ SaaS費用の総額を即答できない

毎月・毎年のSaaS関連支出の合計金額をすぐに答えられない場合、コスト管理が機能していません。部門ごとの費用も統合されておらず、IT予算全体におけるSaaSの占める割合が不明な状態は、管理に大きな改善余地があることを示しています。

SaaSスプロールを防ぐ・解消する3段階の対策

SaaSスプロールへの対応は予防・現状把握・継続管理の3段階で進めます。すでにスプロールが発生している場合は現状把握から着手し、予防の仕組みを並行して整えます。

第1段階　予防（新規導入フローの整備）

スプロールを防ぐ最も確実な手段は、新規SaaSの導入に情シスが必ず関与する仕組みを作ることです。申請なしに導入を開始できる状態を放置する限り、スプロールは止まりません。

情シスへの申請を必須とする新規SaaS導入フローを策定し、どのような場合に申請が必要か、承認の基準と担当者、申請から回答までの目安期間を明文化して全社に周知します。承認フローが遅すぎると現場が回避行動をとるため、迅速な回答体制を同時に整えることが重要です。承認済みSaaSのリストを公開しておくことで、重複導入を事前に防ぐ効果もあります。試用を開始した時点でのライセンス登録を義務化すれば、フリープランから始まるSaaSも把握できます。

第2段階　現状把握（棚卸しの実施）

スプロールがすでに発生している場合、まず現状を把握することが先決です。部門ごとのヒアリング・アンケート、経費精算やクレジットカード明細からのSaaS支出の抽出、IDプロバイダーや通信ログを活用した利用サービスの検出、IT資産管理ツールによる自動スキャン、という四つの手法を組み合わせることで、シャドーITを含めた全体像に近づけます。

収集した情報はサービス名・利用部門・用途・月額または年額コスト・契約更新日・管理担当者・ライセンス数・実利用人数を必須項目として管理台帳にまとめます。棚卸し後はコスト上位のSaaSやセキュリティリスクが高いSaaSから優先的に対処します。SaaS棚卸し やり方

第3段階　継続管理（仕組みと自動化）

現状を把握した後は、継続的な管理サイクルを確立します。管理台帳はSaaSの追加・変更・解約のたびに更新し、四半期に1回の定期レビューを実施します。一度整えたら終わりではなく、SaaS環境の変化に合わせて常に最新の状態を保つことが前提です。

入退社連動のアカウント管理の仕組みを整えることが特に効果的です。入社時には必要なSaaSへのアカウント一括発行、退職・異動時には全SaaSのアカウント変更・削除を人事システムと連動して実行します。SaaSが50種類を超えるあたりから手動管理の限界が来るため、SaaS管理プラットフォームを活用して自動検出・一元可視化・アカウント管理の自動化を実現することも選択肢になります。SaaS管理プラットフォームとは

SaaSスプロール解消をジョーシスのプラットフォームで実現する

手動での棚卸しと台帳管理は出発点として有効ですが、SaaSの数が増えるにつれて限界が来ます。ジョーシスのプラットフォームはスプロール解消に必要な業務を自動化し、手動では到達できない可視化と統制を実現します。

スプロールの自動検出と可視化

ジョーシスのプラットフォームはブラウザ拡張機能やログ分析を通じて、情シスが把握していないSaaSを自動で検出します。手動のヒアリングやアンケートを経ずに、社内で使われているSaaSを網羅的に把握できます。

スプロール状態にある企業が導入した場合、これまで管理台帳に載っていなかったSaaSが次々と発見されるケースが多くあります。ダッシュボードで全SaaSの利用状況をリアルタイムに把握できるため、新たなSaaSが導入されたタイミングでの即時把握も可能になります。SaaS可視化とは

ゾンビアカウント・ゾンビSaaSの排除

ジョーシスのプラットフォームは人事システムと連携し、入社・退職・異動のタイミングに合わせて各SaaSのアカウント処理を自動で実行します。退職者のアカウントが知らないうちに残り続けるリスクを、仕組みの面から根本的に解消します。

各SaaSの利用状況データをもとに実際に使われていないライセンスを自動で検出してアラートする機能もあり、ゾンビSaaSへの惰性課金を防ぎながらコスト最適化を同時に進められます。Sales Markerでは、ジョーシスのプラットフォームの導入によりIT工数を約50%削減した実績があります。

資料ダウンロードや無料トライアルで、自社のSaaSスプロール状況の確認から始めることができます。

まとめ

SaaSスプロールとは、企業内のSaaSが全社的な管理・統制なしに各部門の判断で無秩序に増殖し、誰が何を使っているか把握できなくなった状態です。コストの垂れ流し、セキュリティの穴、ガバナンスの崩壊という三つのリスクが同時進行するため、問題を認識した時点で対策を始めることが重要です。

押さえておくべきポイントを三点に絞ります。

1. SaaSスプロールの本質は数の多さではなく、管理できていない状態にある
2. 発生原因は現場主導の導入・承認プロセスの不備・組織の成長・アカウント放置の四つ
3. 対策は予防・現状把握・継続管理の3段階で、スプロールが起きていれば棚卸しから始める

まず取り組むべきは、前述した5つの兆候で自社の現状を確認することです。三つ以上当てはまる場合は、棚卸しを実施して全体像の把握から始めてください。

• SaaS管理とは
• SaaSスプロール 対策
• SaaS棚卸し やり方
• SaaSガバナンスとは
• シャドーITとは

参考情報

• IBM「SaaSスプロールとは」
• Josys公式「SaaSスプロールとは何か、その課題を克服する方法」
• SS1LAB「SaaSスプロールによる無駄なコストとセキュリティリスクを減らすには」
• TechTarget「野良SaaS増え過ぎ問題でID管理がカオス化」
• SmartHR SaaS管理実態調査