SaaS費用の棚卸し手順｜解約判断の前に利用者・契約・代替手段を揃える

請求ではなくサービス台帳を作る

カード明細だけでは、誰が使い、どの業務に必要かが分かりません。サービス名、契約主体、管理者、利用者数、料金周期、次回更新日、支払方法の参照先、利用目的、保存データ、連携先を同じ行にまとめます。カード番号やパスワードは台帳へ書きません。

年払いは月額換算だけでなく、更新日と解約・変更の期限を記録します。外貨建てや従量課金は、直近3か月の請求額を並べ、固定費と変動費を分けます。

利用状況を3種類の証拠で確認する

管理画面の最終ログイン、作成・更新された成果物、担当者への確認を組み合わせます。ログインしていなくても自動処理で使うサービスがあり、ログインが多くても成果につながっていない場合があります。

「使っている」と「止めると困る」を分けるため、停止した場合に止まる業務、データを取り出す方法、代替手段、復旧にかかる時間を記します。判断できない項目は不明のまま残し、ゼロ利用と決めつけません。

請求名と契約主体のずれを解く

カード明細の請求名から、請求書の発行元、販売店またはアプリストア、契約アカウント、サービス名までを一件ずつ対応付けます。明細の表記がサービス名と違う場合は、金額や日付だけで推測せず、請求書番号と管理画面の契約情報を照合します。確認できない請求は未確認として、会計記録と契約管理者のどちらへ照会するかを残します。

同じサービスでも、法人、部署、通貨、契約アカウントが違えば複数の請求になる場合があります。反対に、販売代理店経由の請求には複数サービスが含まれることがあります。対応付けに使った証拠の参照先と確認日を台帳へ置き、明細名だけを根拠に重複や不要と判定しません。

契約変更前に確認する依存関係

依存関係はサービス内の設定だけでなく、ウェブサイト、メール、社内手順書から検索します。変更後に気付くと復旧が難しいため、まず読み取り可能な形で一覧を保存します。

• 外部サイトやフォームからデータが入っていないか
• API、Webhook、自動化ツールが接続されていないか
• 顧客や取引先がそのURLを利用していないか
• 法令や契約で保存が必要な記録がないか
• 所有者が退任者の個人アカウントになっていないか
• 下位プランで失われる権限・履歴・書き出し機能は何か

候補ごとに安全な小さな実験を置く

利用席が余っているなら、影響のないテスト利用者を外し、権限や自動化に問題がないか確認します。上位プランから下位プランへの変更を検討する場合は、失われる機能を公式の最新比較表で確認し、テスト環境や対象を限定した運用で試します。

本番データの削除や契約操作を、調査と同じ日に勢いで行いません。対象、実行者、日時、復旧方法、確認方法を固定し、変更後は請求と業務の両方をreadbackします。

継続判断には費用以外の列を持つ

月額が安くても、毎週の手作業が増えるなら総費用は下がらないことがあります。入力時間、エラー対応、教育、連携保守、顧客への影響を簡単な尺度で記録します。

逆に、利用頻度が低くても、年に一度の重要な手続きや法定記録に必要な場合があります。頻度だけでなく、使えない時の影響と代替可能性を確認します。

四半期棚卸しチェックリスト

• 全請求元をサービス台帳へ対応付けた
• 契約主体・管理者・利用者を確認した
• 次回更新日と変更期限を記録した
• 直近3か月の利用証拠を確認した
• 保存データと外部連携を洗い出した
• 重複を業務単位で比較した
• 変更候補に復旧方法とreadback項目を付けた
• 実行結果を次回棚卸しへ残した

更新日の90日前から確認順を置く

更新日の90日前には契約主体、管理者、通貨、保存データ、外部連携を確認します。60日前には利用証拠、現在の公式プラン差分、書き出し方法を確認し、変更候補がある場合は影響を限定した試験を設計します。30日前には実行対象、担当者、復旧方法、請求と業務のreadback項目を固定し、関係者へ確認期限を伝えます。

更新まで90日ない契約は、残り日数に合わせて順番を縮めても、依存関係の確認を省きません。販売店や年払い契約には変更受付の締切が別にあるため、更新日と手続期限を分けて公式情報から記録します。外貨建ては比較に使った為替時点を残し、将来の請求額を確定値として扱いません。

期限を過ぎた場合は、急いで本番契約を操作する前に、次に変更できる日と現状の影響を確認します。調査担当と実行担当が異なる時は、対象アカウント、プラン、契約期間をreadbackできる手順を渡します。変更を実行した場合だけ、次の請求書と利用業務を確認し、予測との差を次回の棚卸しへ戻します。

重複候補は業務シナリオで比較する

「チャット機能が二つある」という機能名だけでは重複を判断できません。顧客問い合わせを受けて担当へ割り当て、履歴を検索し、退任者のアクセスを外す、といった実際の業務を一つ選び、各サービスで誰がどの操作をしているかを並べます。片方が顧客契約や自動化へ組み込まれていれば、見た目が似ていても代替には追加作業が必要です。

候補ごとに、月間利用者、重要データ、外部共有、API連携、通知先、教育資料、契約上の要件を確認します。利用回数が少なくても、年次監査や緊急対応に必要なことがあります。反対に毎日開いていても、別サービスからの通知を見るだけなら運用を変えられる場合があります。頻度と使えない時の影響を分けて記録します。

比較結果は、現状維持、設定改善、席数調整、対象を限定した移行試験など、影響の小さい次の行動へ落とします。契約変更やデータ削除を調査と同じ操作にせず、実行対象、復旧、確認方法を別の手順で固定します。商品の提供や顧客アクセスを止める判断は、単なる費用表から導きません。

変更前後を同じ指標でreadbackする

席数やプランを変える前に、現在の請求額、対象利用者、失われる機能、保存データ、連携、変更反映日、元へ戻せる期限を公式情報と管理画面で確認します。対象アカウントと契約主体を読み上げられる形にし、別部署や別通貨の契約を操作しないようにします。

まず影響のないテスト利用者または小さなグループで、ログイン、日常操作、データ閲覧、通知、自動処理を確認します。問題が出たら元の設定へ戻し、足りなかった条件を台帳へ追加します。全利用者へ広げる場合も、変更日時と問い合わせ先を知らせ、業務の観測時間を確保します。

変更後は、契約画面の席数やプラン、次回請求見込み、実際の利用者、主要業務、外部連携を確認します。請求確定後にも明細を台帳と照合し、期待との差を記録します。節約額だけでなく、手作業、エラー、問い合わせ、顧客への影響が増えていないかを同じ期間で見ます。

棚卸し結果には、確認できた事実、推測、未確認を分けて残します。「利用履歴なし」は直ちに不要を意味せず、「担当者が必要と言った」だけでも継続条件は分かりません。使用場面、使えない時の影響、代替手段、次回確認日をそろえれば、翌四半期に同じ聞き取りを繰り返さず、条件の変化から再判断できます。

請求通貨や税区分が異なる契約は単純合算せず、比較時点の換算条件を添えます。年払いは月額換算だけでなく、更新日までに戻せる選択肢と担当者を台帳へ残します。

請求書と管理画面の金額が違う場合は、税、日割り、追加利用、為替、返金を分けて照合します。差額を見込みの削減額へ混ぜず、確定した明細が届くまで未確認として次回確認日を残します。

この記事の限界

料金、解約条件、データ保持、プラン機能は変更されます。契約変更や解約の前に、対象サービスの最新規約と管理画面を確認してください。会計・税務・法務上の保存義務が関係する場合は、担当専門家の判断を優先します。