レッスン5：SaaS 選定・契約・棚卸し

このレッスンで学ぶこと

買い手側の要件定義（機能・セキュリティ・運用）の 3 軸を組み立てられる
比較評価の 3 軸（機能適合・コスト・実装工数）で SaaS 候補を絞り込める
契約交渉のポイント（自動更新・データ返還・SLA）を語れる
シャドー IT の対処（CASB・SaaS 棚卸ツール・従業員教育）を組める
SaaS 解約プロセスの標準手順を持ち帰れる

前レッスンではデバイス管理を扱いました。本レッスンでは、情シスの「選ぶ」役割の中核である SaaS 選定・契約・棚卸しに踏み込みます。中核メッセージ 3「SaaS は買った瞬間ではなく解約時に苦しむ——契約時に出口を設計する」の実装編です。

買い手側の要件定義

SaaS 選定は、事業部から「〇〇を導入したい」と要望が上がってから始まることが多い業務です。要望を「要件」に翻訳することが、情シスの最初の仕事です。3 軸で組み立てます。

軸 1：機能要件

事業部が何を実現したいのか、業務プロセスに落とし込みます。

コア機能（絶対に必要な機能）
あると便利な機能（あれば選択理由になる）
将来必要になる可能性がある機能（拡張性）

事業部との対話で「業務で 1 日何回、その機能を使うか」「代替手段（Excel、既存 SaaS）で何が困っているか」を掘り下げます。

軸 2：セキュリティ要件

情シスとして必ずチェックする軸です。

認証：SSO（SAML／OIDC）対応、SCIM プロビジョニング対応
監査：管理者による監査ログ、外部監査認証（SOC 2、ISO 27001）
データ保護：保存時暗号化、通信暗号化（TLS）
データ所在地：日本国内リージョンの有無、越境データの扱い
業界規制：業界固有の認証（PCI DSS、HIPAA、FISC、ISMAP）

軸 3：運用要件

日常運用を支える要件です。

サポート体制：日本語サポート、営業時間、平均応答時間、SLA
障害通知：ステータスページ、メール通知、Slack 連携
アップデート情報：新機能追加・変更の事前通知
料金体系：月額／年額、ユーザー単位／使用量単位、ボリューム割引

比較評価の 3 軸

複数の SaaS 候補を並べて評価するときの 3 軸です。

軸 1：機能適合度

要件定義で定めた機能と、各 SaaS の対応度をマッピングします。以下のスコアリング例を使います。

◎（完全対応、想定以上）：5 点
○（対応）：3 点
△（部分対応、回避策で対処）：1 点
×（未対応）：0 点

コア機能に × があれば選定候補から外します。

軸 2：総所有コスト（TCO）

初期費用だけでなく、3〜5 年の総所有コストで比較します。

初期費用（セットアップ、データ移行、トレーニング）
月額または年額のライセンス費（社員数増加を織り込む）
追加機能のオプション費用
内製運用にかかる工数（IT 担当者の時間コスト）

軸 3：実装工数

導入完了までにかかる情シス側の工数を見積もります。

要件定義・仕様確定：〇時間
ベンダーとの調整：〇時間
環境構築・設定：〇時間
テスト・受け入れ：〇時間
従業員トレーニング：〇時間

工数を軽視すると「導入したが誰も使えない」状態になりがちです。

💡 ポイント SaaS 選定では「機能一覧の比較」だけで判断せず、必ず PoC（Proof of Concept）を実施します。実業務で 2〜4 週間の試験運用を行い、実際の業務フローに乗せてみて、想定通りに動くかを確認します。カタログ上は同じ機能でも、UX や現場での使いやすさは実際に触らないとわかりません。

契約交渉のポイント

SaaS 契約時に必ず確認・交渉すべき論点があります。「買った瞬間の便利さ」より「使い倒した後の縛り」を見る視点が重要です。

ポイント 1：自動更新条項

多くの SaaS 契約は「特に申し出がなければ自動更新」の条項があります。次の条件を確認・交渉します。

更新前の通知タイミング（30 日前、60 日前など）
解約通知期限（更新の 30 日前、60 日前、90 日前など）
途中解約の可否と違約金

ポイント 2：データ返還条項

解約時にデータをどう扱うかを契約時に定めます。

返還フォーマット：CSV、JSON、SQL ダンプなど、汎用形式で受け取れるか
返還費用：無料か有料か、有料の場合の料金体系
返還期限：解約後何日以内に返還されるか
削除保証：SaaS 側からの完全削除の証明書発行

ポイント 3：SLA（Service Level Agreement）

サービス稼働の保証と、未達時の対応を明確化します。

稼働率保証（99.9%、99.95% など）
未達時のクレジット還元（多くは月額料金の 10〜30% 相当）
障害の定義（計画メンテナンスは除外、部分機能停止の扱い）

ポイント 4：機密保持と個人情報保護

NDA（Non-Disclosure Agreement）の締結
個人情報の取り扱い（改正個人情報保護法遵守、越境データの扱い）
サブプロセッサー（SaaS ベンダーがさらに委託する第三者）のリスト

シャドー IT 対処

シャドー IT は、情シスの承認なしに部署・個人が導入して使う SaaS のことです。柔軟性と便利さの裏で、情報漏洩・監査違反・二重支払いのリスクがあります。

対処 1：可視化（CASB・SaaS 棚卸ツール）

CASB（Cloud Access Security Broker）：ネットワーク側でクラウドアクセスを可視化・制御
SaaS 棚卸ツール：クレジットカード決済履歴・SSO ログ・ネットワークログから使用中の SaaS を検出

可視化なしにシャドー IT は削減できません。まず「何が使われているか」を把握することが第一歩です。

対処 2：ホワイトリスト運用

情シス承認済み SaaS のリストを公開し、そこから選ぶ運用にします。承認申請フローを短くする（1 週間以内で承認可否を返す）ことで、事業部が回避策としてシャドー IT に走るのを防ぎます。

対処 3：従業員教育

承認外 SaaS の利用がなぜ問題か（情報漏洩、監査違反、二重支払い）
承認済み SaaS がある領域は、まずそちらを試す
新しい SaaS が必要な場合は情シスへ相談する経路

罰則より仕組みを整えることが有効です。

SaaS 解約プロセスの標準手順

解約は次の 5 ステップで型化します。契約時に定めた条項を実行する場面です。

ステップ 1：解約判断（3〜6 か月前）

利用状況の確認（アクティブユーザー数、機能使用状況）
代替 SaaS の選定または業務プロセスの見直し
経営陣・事業部との合意

ステップ 2：解約通知（契約条項に沿って）

契約書で定めた通知期限（多くは 30〜90 日前）に沿って書面で通知
ベンダー側と解約日を確定

ステップ 3：データ返還

契約に基づき、SaaS 側からデータを CSV／JSON 等の汎用形式で受け取る
事業部に配布、必要なら代替 SaaS へインポート

ステップ 4：アカウント無効化

IdP で SaaS 連携を解除
SaaS 側でユーザーアカウントを削除
最終的な請求書を確認

ステップ 5：データ削除確認

SaaS 側からデータ完全削除の証明書を受領
社内で解約プロセス完了を記録

講師の現場メモ——「便利で導入した SaaS を解約しようとしたらデータ返還に 60 万円請求された話」

私が独立初年度に伴走した中堅サービス業で、営業部門が独自導入した SaaS を解約する場面がありました。営業部門長は「別の SaaS に乗り換えたい」と希望していましたが、いざ解約通知を出したところ、次の 3 つが問題になりました。

第 1 に、自動更新条項が「解約通知は更新の 90 日前まで」という長期条項で、その時点で既に 60 日前まで来ていました。あと 30 日で自動的にもう 1 年契約が更新される寸前でした。

第 2 に、データ返還条項が「独自形式での返還のみ、CSV 変換は有料オプション」と定められており、CSV 変換の見積が 60 万円でした。返還を断念して独自形式のまま受け取ることも検討しましたが、社内には独自形式を読める人がいませんでした。

第 3 に、業務データが SaaS に残ったまま解約すると、削除された時点で顧客履歴が消失し、営業活動が回らなくなる懸念がありました。

契約時に「解約時どうなるか」を確認しない企業は、解約時に必ず苦しみます——この会社では 60 万円の CSV 変換を支払い、独自形式データも並行して保管し、なんとか乗り切りました。この経験を経て、私はどの会社でも SaaS 契約時に「自動更新条項」「データ返還条項」「SLA」の 3 点セットを必ず契約書で確認する運用を徹底しています。

買った瞬間の便利さより、5 年後の解約時に何が起きるかを想像する——これが SaaS 選定で最も重要な視点だと私は考えています。

中核メッセージ 6 個の再掲

本コース全体を通じて、6 個のメッセージを繰り返します。

情シスは「守る・選ぶ・運用する」の 3 役割——役割ごとに時間を配分する
アカウント運用が情シスの生命線——入社と退社の 2 点で 8 割が決まる
SaaS は買った瞬間ではなく解約時に苦しむ——契約時に出口を設計する
ヘルプデスクは「早く直す」より「二度と起こさない」——ナレッジ化が本業
インシデントは一次受付・トリアージ・エスカレーションの 3 手で対応する
IT 予算は「守り・攻め・維持」の 3 分類で経営に説明する

このレッスンで扱うのはメッセージ 3「SaaS は買った瞬間ではなく解約時に苦しむ」です。要件定義から契約交渉、シャドー IT 対処、解約プロセスまで、SaaS の全ライフサイクルを情シスが設計することが、5 年後の会社の IT 資産と業務効率を守ります。

次のレッスンで扱うこと

次のレッスン 6 では、情シスの「運用する」の中核であるヘルプデスクと ITSM/ITIL 運用に踏み込みます。チケット管理、ナレッジベースの育て方、SLA 設定、AI チャットボット活用、二度と起こさないための PostMortem まで整理します。ヘルプデスクは「早く直す」より「二度と起こさない」ナレッジ化が本業——この視点を扱います。

確認クイズ

このレッスンで学んだ内容を確認しましょう。