業務のデジタル化が進むと、営業部門ではチャットやCRM、開発部門ではプロジェクト管理、管理部門では電子契約や経費精算など、部門ごとにSaaS（Software as a Service）が増えていきます。
それぞれの導入時には必要性があっても、数年後には「社内で何種類のSaaSを使っているのか分からない」「似た機能のツールが複数ある」「誰が契約したのか分からない」といった状態になることがあります。
このとき、最初から「SaaSを減らそう」と考える必要はありません。
重要なのは、まずSaaSの利用実態を可視化し、会社として管理できる状態を作ることです。
本記事では、利用目的、利用状況、重複機能、アカウント・権限、契約、データ、システム連携を棚卸しし、SaaSを継続・統合・契約見直し・廃止へ整理する方法を解説します。
SaaSが増えること自体が問題ではない
同じ種類のSaaSが複数存在していると、一見すると無駄に見えます。
しかし、例えば同じチャット機能を持つツールでも、全社コミュニケーション、開発プロジェクト、外部パートナーとの連絡では必要な機能やユーザー、システム連携、セキュリティ要件が異なる場合があります。
そのため、「チャットツールが3種類あるから1種類へ統一する」という判断を先に置くのは適切とは限りません。
問題となるのは、なぜ複数必要なのか説明できない、管理責任者が分からない、退職者アカウントが残っている、更新日を把握していない、どのデータが保存されているのか分からない、といった管理できていない状態です。
まず社内で使われているSaaSを一覧化する
SaaS整理の第一歩は、統廃合ではなく一覧化です。
既存のSaaSを探す際には、情シスが把握しているシステム一覧だけでなく、経理・経費データ、法人カード、契約書、各部門への確認、SSO・IdP（Identity Provider：認証基盤）の登録状況、API・OAuth連携なども手掛かりになります。
最初から100%のSaaSを発見しようとすると棚卸し自体が進まないこともあります。判明したものから台帳へ追加し、継続的に精度を高める方法でも構いません。
SaaS管理台帳に入れたい項目
棚卸しでは、SaaS名だけを一覧にしても十分な判断材料にはなりません。
最低限、何のために使っているか、誰が責任を持っているか、誰が利用しているか、契約はどうなっているかを確認します。
| 項目 | 確認する内容 |
|---|---|
| SaaS名 | サービス・製品名 |
| 利用目的 | 何の業務・判断・コミュニケーションに使うか |
| 利用部門 | 主に利用する部署・ユーザー群 |
| 責任者 | 業務・管理・契約の責任者 |
| 利用者 | 割当ユーザー、実利用者、ゲスト等 |
| 費用 | 月額・年額・従量課金等 |
| 契約更新 | 更新日、自動更新、解約期限 |
| 類似SaaS | 同一・類似機能を持つ他サービス |
| 権限 | 管理者、一般ユーザー、外部ユーザー等 |
| データ | 保存する情報、外部共有、機密性 |
| 連携 | API、OAuth、Webhook、他システムとの依存 |
| 終了条件 | データ出力、削除、移行等 |
最初からすべての列を埋める必要はありません。まずは「SaaS名」「利用目的」「責任者」「利用者」「費用」「更新日」「類似SaaS」程度から始めてもよいでしょう。
特に、利用目的や責任者が空欄になるSaaSは、統廃合以前に確認が必要な対象です。
チャットツールが3種類併存している架空例
説明用の架空企業で、3種類のチャットツールが利用されているケースを考えます。
| 確認項目 | Chat A | Chat B | Chat C |
|---|---|---|---|
| 主な目的 | 全社コミュニケーション | 開発プロジェクト | 取引先との連絡 |
| 主な利用者 | 全社員 | 開発部門 | 営業部門の一部 |
| システム連携 | SSO | 開発ツールと連携 | 要確認 |
| 管理 | 情シス | 部門管理 | 契約責任者不明 |
| 外部ユーザー | 必要に応じて管理 | プロジェクト単位 | ゲストあり |
| 契約 | 把握済み | 把握済み | 自動更新 |
| 初期整理 | 継続検討 | 継続検討 | 要確認・統合候補 |
この例では、Chat AとChat Bはどちらもチャット機能を持ちますが、利用者とシステム依存関係が異なります。単純に機能が重複しているという理由だけで一方を廃止すると、業務や開発フローへ影響する可能性があります。
一方、Chat Cは利用目的、契約責任者、現在の利用者、ゲスト、保存データ、他システムとの連携を確認した上で、他ツールへ統合できるかを検討できます。
見るべきなのはSaaSの数ではなく、目的・利用者・依存関係・リスクです。
SaaSを整理する7つの確認軸
1. 利用目的と責任者
最初に、そのSaaSが何のために使われているかを確認します。また、業務上の責任者、アカウント等を管理する責任者、契約を管理する責任者を確認します。小規模企業では同一人物が兼ねても構いません。
2. 利用状況
契約しているライセンス数、割り当てているユーザー数、実際に利用しているユーザーを分けて確認します。
例えば購入ライセンスが存在しても、誰にも割り当てられていなければ契約見直しの候補になります。割り当て済みでも長期間使われていない場合には、利用理由を確認できます。
3. 機能の重複
同じカテゴリのSaaSを並べ、主要用途、利用者、外部共有、必要な連携、業務フローへの依存を比較します。
「同じチャット機能がある」だけではなく、「同じ業務目的を代替できるか」を見ることが重要です。
4. 費用と契約
月額・年額費用だけでなく、ライセンス体系、従量課金、最低契約数、更新日、自動更新、解約申請期限等を確認します。
利用状況が分かっても、契約途中でSeat数を減らせない場合があります。利用実態の確認は契約更新の十分前に行う方が、見直しへつなげやすくなります。
5. アカウントと権限
統廃合とは別に、早めに確認したいのがアクセス権です。
一般ユーザーだけでなく、管理者、ゲスト、外部ユーザー、サービスアカウントを区別します。退職や異動などに伴い不要となったアクセスは、適切に変更・停止する仕組みが必要です。
権限は業務に必要な範囲へ限定する最小権限の考え方が基本です（Joint Task Force, 2020）。SSOやMFAも、対象SaaSの重要性や利用方法に応じて確認します。
6. データとセキュリティ
そのSaaSに顧客情報、個人情報、社内機密、ファイル等の何が保存されているかを確認します。
また、外部共有、ログ、データ保持期間、エクスポート、契約終了後の削除なども整理します。セキュリティリスクはシステム単体ではなく、組織の重要業務やデータとの関係で評価します（Pascoe et al., 2024）。
7. システム連携と終了条件
利用者が少ないSaaSでも、API、OAuth、Webhook、ワークフロー自動化等を通じて他システムと接続されている場合があります。
廃止前には、どのシステムが依存しているか、データを出力できるか、連携を解除すると何が停止するかまで確認します。
利用率だけで廃止を決めない
SaaSの見直しでは、利用率は重要な判断材料です。しかし「利用頻度が低い＝不要」とは限りません。
例えば年次決算、監査、BCP、特定顧客への対応など、利用回数が少なくても業務上重要なSaaSがあります。また、サービスアカウントによるシステム連携では、人がログインする頻度だけを見ても利用実態を把握できません。
利用状況に加えて、業務上の重要性、代替可能性、契約条件、システム依存関係を確認します。
権限・退職者・管理者アカウントを優先して確認する
SaaS統廃合には部門調整やデータ移行が必要になることがあります。一方、退職者アカウントの停止や不要な管理者権限の見直しは、統廃合を待たずに着手できる場合があります。
NIST SP 800-53ではAccount ManagementとLeast Privilege（最小権限）がアクセス管理の基本的な統制として整理されています（Joint Task Force, 2020）。
特に、一般利用者だけではなく、管理者、外部ゲスト、サービスアカウントを区別し、「誰が、なぜ、この権限を持っているのか」を説明できる状態を目指します。
SSO未対応だから直ちに利用禁止とするのではなく、扱うデータ、重要性、利用者数、MFA等の代替策を含めてリスクを判断します。
残す・統合する・契約を変える・廃止するを判断する
棚卸ししたSaaSは、独自の点数を付けて機械的に順位付けする必要はありません。
実務では、例えば次の5つ程度に分類すると次の行動へつなげやすくなります。
| 状態 | 考え方 |
|---|---|
| 継続 | 目的・責任者・利用状況が明確で、継続して必要 |
| 統合候補 | 他SaaSで目的を代替できる可能性がある |
| 契約見直し | Seat数、Plan、契約条件等に見直し余地がある |
| 廃止候補 | 業務依存やデータ移行を解消すれば終了可能 |
| 要確認 | 目的、責任者、データ、契約等が不明 |
まず社内で利用しているSaaSを一部でもよいので一覧化し、「利用目的」「責任者」「利用者」「費用」「更新日」「類似SaaS」の6列を埋めてみてください。
利用目的や責任者が空欄になるSaaSがあれば、すぐ廃止するのではなく、まず事実確認の対象として整理できます。
SaaS廃止時に忘れやすいこと
「不要なSaaSが見つかったので契約を解約する」だけでは、整理は完了しません。
- 必要なデータを出力・移行したか
- 添付ファイルや履歴も必要か確認したか
- ユーザーへ利用終了を通知したか
- APIやWebhookを停止したか
- OAuth連携を解除したか
- 外部ゲストを含むアカウントを停止したか
- 自動更新を停止したか
- 契約終了手続きを完了したか
- サービス側に残るデータの削除条件を確認したか
- SaaS管理台帳を更新したか
特にデータは、解約後に取得できなくなる可能性もあるため、契約終了前に出力・保持・削除条件を確認します。
SaaS乱立を再発させないための導入ルール
一度棚卸ししても、各部門が新しいSaaSを導入すれば再び一覧は古くなります。
そこで、新規SaaSを導入するときに、利用目的、責任者、費用、扱うデータ、外部共有、類似SaaSの有無等を確認する軽量なルールを設けます。
ただし、すべてのSaaSに重い承認プロセスを要求すると、利用部門が正式な手続きを避け、管理外のIT利用を促す可能性もあります。NCSCも、ユーザー管理に不必要な摩擦を設けるとShadow ITにつながる可能性を指摘しています。
扱うデータの重要性、利用者数、外部共有、業務上の重要度などに応じて確認レベルを変える方が運用しやすいでしょう。
SaaS棚卸しチェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 一覧 | 利用中SaaSを台帳化しているか |
| 目的 | 何のためのSaaSか説明できるか |
| 責任者 | 業務・管理・契約の責任者が分かるか |
| 利用者 | 購入、割当、実利用を区別できるか |
| 重複 | 類似SaaSとの役割差を説明できるか |
| 契約 | 費用、更新日、解約期限を把握しているか |
| 一般権限 | 不要なユーザーが残っていないか |
| 高権限 | 管理者権限が必要な利用者に限定されているか |
| 外部利用者 | ゲスト・外部ユーザーを把握しているか |
| 認証 | SSO・MFA等の状況を把握しているか |
| データ | 何を保存・共有しているか分かるか |
| 連携 | API・OAuth・Webhook等を把握しているか |
| 終了 | データ出力・削除・移行条件を確認しているか |
| 定期確認 | 契約更新等に合わせて見直す仕組みがあるか |
まとめ
SaaSが増えすぎたと感じても、最初から数を減らす必要はありません。
まず、何を利用しているかを一覧化し、利用目的、責任者、利用状況、機能の重複、アカウント・権限、契約、保存データ、システム連携を確認します。
その結果をもとに、継続、統合候補、契約見直し、廃止候補、要確認へ整理します。
特に重要なのは、低利用率や製品数だけで廃止を決めないことです。業務上の重要性や他システムとの依存、外部ユーザー、データ移行条件まで見た上で判断します。
SaaS管理は一度の棚卸しで終わるものではありません。新規導入、利用者変更、契約更新、サービス終了までを含むライフサイクルとして運用することで、継続的に管理できる状態へ近づけます。
SCI総合研究所株式会社のKANAMEBAでは、SaaSを単純に削減するのではなく、利用目的、重複機能、契約、権限、セキュリティ、データ、システム連携まで整理し、継続・統合・契約見直し・廃止の判断軸を整えます。
「社内で何のSaaSを使っているか把握できていない」「部門ごとに契約が増えている」「同じ用途のSaaSが複数ある」「退職者アカウントや契約更新まで管理しきれない」といった段階から、SaaS管理とITガバナンスの進め方を整理できます。
参考文献
- Joint Task Force. 2020. Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology. NIST Special Publication 800-53 Rev. 5. DOI: 10.6028/NIST.SP.800-53r5.
- Pascoe, C. et al. 2024. The NIST Cybersecurity Framework (CSF) 2.0. National Institute of Standards and Technology. NIST CSWP 29. DOI: 10.6028/NIST.CSWP.29.