部署ごとに契約した小規模SaaSが乱立した状態を整理する方法

社員が10人を超えたあたりから、多くの会社で共通して起きる現象があります。営業部はSFA（営業支援システム）を、人事部は勤怠管理ツールを、マーケティング部はチャット型の顧客対応ツールを、経理部は請求書発行サービスを——というように、各部署がそれぞれの業務効率化のために、それぞれの判断で小規模なSaaS（クラウド型のソフトウェア）を契約し始めるのです。

この段階の会社には、まだ情シス担当が存在しないことがほとんどです。総務や経営者がIT管理を「本業の片手間」で兼任し始めたばかりで、各部署が何を契約しているかを一元的に把握する仕組みも、契約前に確認を挟む稟議のルールも整っていません。結果として、気づいたときには契約主体もカード情報も部署ごとにバラバラな、10〜20個の小規模SaaSが社内に散らばっている、という状態になります。

このガイドでは、社員10〜30人規模の会社に特有の「部署ごとに個別契約されたSaaSの乱立」という状況に焦点を当て、どういう順序で棚卸しをすれば無理なく整理できるのか、そして何を解約し、何を残すのかをどう判断すればよいのかを具体的に解説します。

なぜ10-30人規模で「部署ごとの乱立」が起きるのか

5人未満の会社であれば、契約しているSaaSの数はまだ数個程度で、社長やメンバー全員が「何を使っているか」を頭の中で把握できています。しかし社員が10人を超え、部署という単位が生まれ始めると、状況は一変します。

部署が分かれるということは、意思決定の単位も分散するということです。営業部長は営業部の業務効率化のためにSFAを契約し、人事担当は人事担当の判断で勤怠管理ツールを契約します。それぞれの契約は、その部署にとっては合理的な判断です。しかし、会社全体を俯瞰する立場の人間がいないため、「営業部と人事部で似たような機能を持つツールを別々に契約している」「同じ用途のクラウドストレージが3部署でバラバラに契約されている」といった重複が、誰にも気づかれないまま蓄積していきます。

さらに、多くのSaaSは月額数千円〜数万円程度の少額から契約でき、部署の裁量権の範囲内で稟議を通さずに契約できてしまう金額帯であることが、この乱立に拍車をかけます。1件あたりの金額が小さいため、経理も「大きな支出ではない」と見過ごしがちで、気づいたときには合計金額が無視できない規模に膨らんでいる、という展開をたどりやすいのです。

「部署ごと」であることが引き起こす3つの固有の問題

部署ごとに個別契約されたSaaSが乱立する状態は、単に「数が多い」という以上の、構造的な問題を抱えています。

• 契約主体・支払い方法が統一されていない: ある部署は法人カードで、別の部署は部署長個人のカードで、さらに別の部署は担当者個人の口座振替で支払っている、というように支払い経路がバラバラになりやすい
• 同一用途のツールが複数部署で重複契約されている: 部署間の横のつながりが薄いほど、「隣の部署が何を使っているか」を知る機会がなく、同じような課題を別々のツールで解決してしまう
• 管理者アカウントが契約した本人しか把握していない: 契約した担当者が異動・退職すると、管理者権限を持つ人間が社内に誰もいなくなるリスクを、部署の数だけ抱えることになる

この3つの問題は独立しているようで、実は根っこが同じです。「部署単位で意思決定が完結してしまい、会社全体を横断する目が入っていない」という構造そのものが、契約の分散・重複・属人化のすべてを引き起こしているのです。

シャドーITとの違い: 「隠れていた」のではなく「バラバラだった」

似たような文脈で語られる言葉にシャドーIT（情シスや管理部門が把握していない、現場が独自に導入したITツール）があります。しかし、10〜30人規模で起きる「部署ごとのSaaS乱立」は、シャドーITとは少し性質が異なる点に注意してください。

シャドーITは、多くの場合「会社が禁止している、あるいは推奨していないツールを、現場が黙って使っている」という隠蔽のニュアンスを含みます。一方、部署ごとのSaaS乱立は、各部署がむしろ正当な業務目的で、正々堂々と契約したものがほとんどです。誰かが隠していたわけではなく、単に「会社全体を見渡す役割が存在しなかったため、結果的に見えなくなっていた」というだけの話です。

この違いは、整理を進めるときの向き合い方に直結します。シャドーIT対策では「なぜ黙って導入したのか」を問い詰める必要が生じる場面もありますが、部署ごとの乱立を整理する場面では、各部署の担当者を責める必要はまったくありません。「よく使ってくれていた、ただ全社的な視点が足りなかっただけ」という前提に立ち、協力を仰ぐスタンスで進める方が、ヒアリングも解約の合意形成もスムーズに進みます。この温度感の違いを、最初に総務・経営者の間で共有しておくことをお勧めします。

棚卸しの前に: なぜ「経理の明細」から始めるべきか

部署ごとに乱立したSaaSを整理する際、多くの担当者は各部署にヒアリングをして「何を使っていますか」と聞くところから始めようとします。しかし、この進め方には落とし穴があります。部署の担当者自身が、自部署で契約しているすべてのSaaSを正確に記憶しているとは限らないからです。特に、他部署が過去に契約して現在は形骸化しているような、使われていないサービスは、ヒアリングだけでは発見できません。

そこでお勧めしたいのが、まず経理の支払い明細（クレジットカード明細・銀行口座の引き落とし履歴）から、SaaSらしき定期支払いをすべて洗い出すという進め方です。明細ベースで洗い出せば、「その部署の誰も覚えていない契約」も含めて、実際にお金が動いている契約を漏れなく拾い上げられます。

明細から洗い出す際は、次の観点で候補を絞り込んでいきます。

1. 毎月・毎年、同じ金額が引き落とされている項目を抽出する: サブスクリプション型のSaaSは、多くの場合一定の周期で同額が引き落とされます
2. 引き落とし先の名称からサービス名を特定する: クレジットカード明細の表示名がサービス名と異なる場合があるため、不明な項目はカード発行会社に問い合わせて確認します
3. どのカード・どの口座から支払われているかを記録する: この段階で「誰が契約主体になっているか」の手がかりを同時に集めておきます

この明細ベースの洗い出しと、各部署へのヒアリングを両輪で進めることで、「誰も覚えていない契約」と「部署の担当者だけが把握している契約」の両方を漏れなく拾い上げることができます。

棚卸し台帳に必要な項目

部署ごとの乱立を整理するための台帳には、通常のIT台帳に加えて、部署間の重複や責任の所在を可視化するための項目を追加します。

この台帳が完成すると、「用途カテゴリ」列で並べ替えるだけで、どの業務領域に重複契約が集中しているかが一目で分かるようになります。

棚卸しにかかる期間の目安と進め方

10〜30人規模の会社で、部署をまたいだSaaS棚卸しにどれくらいの期間を見込めばよいか、目安を示しておきます。会社の部署数や契約数によって前後しますが、おおよそ次のような工程を想定するとよいでしょう。

1. 経理明細からの候補抽出（1週間程度）: 過去半年〜1年分のカード明細・口座履歴から、定期支払いらしき項目をすべてリストアップする
2. 各部署へのヒアリング（2〜3週間程度）: 部署ごとに「このリストにあるサービス、使っていますか」「他に使っているものはありますか」を確認する。忙しい部署ほど返答が遅れがちなので、期限を区切って依頼する
3. 台帳への集約と重複の洗い出し（数日程度）: ヒアリング結果を台帳にまとめ、用途カテゴリで並べ替えて重複を確認する
4. 統合・解約の判断と実行（1〜2ヶ月程度）: 契約更新のタイミングに合わせて、順次解約・統合を進める
5. 契約主体の統一（1〜2ヶ月程度）: 4と並行、あるいは後続で、法人名義への統一を進める

全体を通すと、着手から一区切りつくまでに2〜3ヶ月程度を見込んでおくと現実的です。総務や経営者が本業と兼任しながら進める場合、無理に短期間で終わらせようとせず、ヒアリングの期限だけは明確に区切りつつ、他の工程は業務の合間に少しずつ進める形で構いません。重要なのは、いつまでも「そのうちやる」で止まらないよう、最初にゴールの月を決めておくことです。

経営層・部署責任者への説明の仕方

棚卸しの結果、重複契約や個人名義の契約が想像以上に多く見つかることは珍しくありません。この結果を経営層や各部署の責任者に説明する際、「無駄遣いを指摘する」というネガティブな伝え方をすると、各部署が防衛的になり、以降の協力が得られにくくなることがあります。

説明の際は、次のような伝え方を意識するとよいでしょう。

• 「誰が悪い」ではなく「仕組みがなかった」という前提で話す: 部署ごとの契約自体は正当な業務判断だったことを最初に確認した上で、会社全体を横断する仕組みが今までなかったことが根本原因だと説明する
• 金額のインパクトを具体的に示す: 「月額○○円の重複契約が○件見つかり、統合すれば年間○○円のコスト削減が見込める」というように、具体的な数字で示すと、経営層の理解と協力が得やすくなる
• 今後の運用ルールとセットで提案する: 過去の整理だけでなく、「今後はこうすれば同じ状態を防げる」という再発防止策をあわせて提示することで、前向きな取り組みとして受け止めてもらいやすくなる

特に経営者がIT管理を兼任している10〜30人規模の会社では、経営者自身が説明する側に回ることも多いはずです。各部署の担当者に不要な不安を与えないよう、「今使っているツールをすぐに取り上げる」のではなく「まず全体像を可視化し、その上で一緒に最適な形を考える」という進め方であることを、最初に丁寧に伝えておくことをお勧めします。

重複契約を見つけたときの判断基準

用途カテゴリで並べ替えて重複が見つかったら、どちらを残しどちらを解約するかを判断する必要があります。この判断は、単純に「安い方を残す」では済まないことが多く、次の観点を順番に確認することをお勧めします。

• 利用しているデータ量・利用者数: どちらのツールに、より多くの実績データや利用者が蓄積されているかを確認する。データ移行のコストは、後から発生する見えにくいコストであるため、先に見積もっておく
• 他システムとの連携状況: 会計ソフトや他の業務システムと連携設定が組まれている方は、切り替えると連携の再設定が必要になる
• 契約更新のタイミング: どちらか一方が更新月の直前であれば、そちらを基準に統合のスケジュールを組むと違約金や無駄な支払いを避けやすい
• 各部署の業務フローへの組み込み度合い: 現場の業務手順書やマニュアルに深く組み込まれているツールほど、切り替えの現場負担が大きい

これらを確認した上で、「機能面でどちらが優れているか」だけでなく「切り替えコストがどれくらいかかるか」を天秤にかけて判断してください。機能的に劣っていても、切り替えコストが低い方を残す方が合理的な場面は少なくありません。

解約を進める際の実務的な注意点

棚卸しと判断が終わったら、実際に解約の手続きに入ります。ここでの実務的な注意点をまとめます。

1. データのエクスポートを解約前に必ず済ませる: 過去のデータが必要になる可能性を考慮し、解約前にCSV形式などでエクスポートし、保管しておく
2. 利用中の部署に事前に周知する: 契約した本人が異動していても、その部署の他のメンバーが日常的に使っている可能性があるため、解約の1〜2週間前には必ず周知する
3. 契約更新日の直前に解約手続きを完了させる: 自動更新のタイミングを過ぎると、次の更新期間分の費用が発生してしまうサービスが多いため、解約期限を台帳に明記して管理する
4. 解約後、支払い明細から実際に引き落としが止まったことを確認する: 解約手続きをしたつもりでも、支払い情報の削除まで完了していないと引き落としが継続してしまうケースがある

なお、データのエクスポート手順や解約前の具体的なチェックポイントについては、SaaS解約前にやるべきデータエクスポート手順でより詳しく解説していますので、あわせて確認してください。

残すと決めたSaaSの「契約主体の統一」

重複契約の整理と並行して、残すと決めたSaaSについては、契約主体を法人名義・法人カードに統一する作業も進めます。部署ごとの乱立が起きている会社では、月額費用の小さいSaaSほど、担当者個人のカードで支払われたまま放置されているケースが多く見られます。

契約主体を統一する際は、次の順序で優先順位をつけると進めやすくなります。

1. 月額費用が大きいものから着手する: 経理上のインパクトが大きい契約を優先して法人名義に揃える
2. 複数部署で共有して使っているものを次に着手する: 契約者本人以外の利用者が多いツールほど、名義の属人化リスクが高い
3. 単一部署・単一担当者しか使っていない小規模なものは最後でよい: 影響範囲が限定的なため、優先度を下げても実害が小さい

この作業を進める中で、「そもそも契約者個人の名義になっていた」というケースに複数遭遇することもあるはずです。個人名義の契約が引き起こすリスクと、法人名義への切り替え手順については、個人契約のクラウドサービスを会社契約に切り替えるタイミングで詳しく扱っていますので、あわせて参照してください。

「契約した人がもういない」ケースへの対応

棚卸しを進める中で、頻繁に遭遇するのが、契約した担当者がすでに部署にいない、あるいは会社を退職しているというケースです。10〜30人規模の会社では、部署異動や退職によって、契約の経緯を知る人間が誰もいなくなっているSaaSが一定数見つかることが珍しくありません。

こうした「契約主が不在」のSaaSは、通常の重複整理とは別の手順で対応する必要があります。管理者アカウントへのアクセス権限をまず確保し、そこから利用実態を確認していくという、やや特殊な進め方が必要になるためです。この固有の課題については、「導入した人がもう部署にいない」SaaS契約の見直し方で手順を詳しく解説しています。

セキュリティ面から見た「部署ごと乱立」のリスク

契約主体やコストの問題に目が行きがちですが、部署ごとにSaaSが乱立している状態は、セキュリティの観点からも見過ごせないリスクを抱えています。

まず、各部署が個別にアカウントを作成・管理していると、パスワードの管理方法や多要素認証（MFA）（多要素認証）の設定状況が部署によってバラバラになりがちです。ある部署はきちんと多要素認証を設定している一方、別の部署は簡単なパスワードのまま放置している、というムラが生まれやすくなります。

また、退職者のアカウント削除も、部署ごとの管理では漏れが発生しやすいポイントです。全社で使っているメールやチャットツールのアカウント削除は徹底されていても、特定の部署だけが契約している小規模SaaSのアカウントは、退職手続きのチェックリストに載っていないことが多く、退職後も長期間有効なままになっているケースが少なくありません。

棚卸しの過程では、次の観点もあわせて確認しておくことをお勧めします。

• 各SaaSで多要素認証が設定可能か、設定されているかを台帳に記録する
• 現在の利用者一覧を各サービスの管理画面から出力し、退職済みの人間が含まれていないか確認する
• 管理者権限を持つアカウントが、契約した本人以外にも設定されているかを確認する（契約者が異動・退職した際の引き継ぎのため）

これらは棚卸し作業のついでに確認できる項目であるため、コスト面の整理と同時並行で進めることで、追加の工数をあまりかけずにセキュリティ面の底上げも図れます。

今後の契約でツール選定基準を揃える

棚卸しと整理が一段落したら、次に手をつけたいのが「今後、新しくSaaSを契約する際の選定基準」を部署間で揃えることです。過去の乱立を整理しても、選定の基準が部署ごとにバラバラなままでは、時間が経てばまた同じような重複が生まれてしまいます。

選定基準として、最低限次のような項目を全社共通のチェックリストにしておくことをお勧めします。

このチェックリストは、稟議のような重い承認プロセスではなく、「契約前にこれだけ確認してから決めてください」という軽いガイドラインとして共有するだけで十分です。10〜30人規模の会社に過剰な統制の仕組みを持ち込む必要はなく、あくまで「重複と個人名義化を防ぐための最低限の確認」に留めることが、無理なく定着させるコツです。

整理後に再発を防ぐための最小限のルール

一度整理しても、部署ごとの契約権限をそのままにしておけば、同じ状態がまた数年後に再現されるだけです。再発を防ぐために、10〜30人規模の会社でも無理なく運用できる最小限のルールを提案します。

• 一定額以上のSaaS契約は、契約前に総務・経営者への一報を必須にする: 稟議のような重い手続きではなく、チャットで一言共有するだけの軽い仕組みで十分です
• 新規契約は原則として法人カード・法人名義で行う: 個人カードでの立て替えを常態化させない
• 半期に1回、経理明細ベースでSaaS一覧を見直す: 棚卸しを一度きりのイベントで終わらせず、定期的な確認をカレンダーに組み込む
• 部署をまたぐ契約は、契約前に他部署に似たツールがないか確認する: 「隣の部署に聞いてみる」を契約前の当たり前の行動にする

これらのルールは、いずれも大掛かりな仕組みや専任担当者を必要とせず、既存の業務フローに軽く組み込める内容です。10〜30人規模のこの段階で、完璧な統制の仕組みを作ろうとする必要はありません。「契約前に一声かける」という文化を根付かせるだけでも、乱立の再発は大きく抑えられます。

よくある失敗パターンとその回避策

部署ごとのSaaS棚卸しに取り組んだ会社の話を聞くと、いくつか共通した失敗パターンが見えてきます。あらかじめ知っておくことで、同じつまずきを避けやすくなります。

• 一度に全部署へ一斉ヒアリングを投げて、返答が集まらないまま停滞する: 部署数が多い場合は、経理明細で支払額の大きい部署から優先的に着手し、小さい部署は後回しにする方が、全体の完了までの時間を短縮できます
• 重複が見つかった時点で即座に片方を解約してしまい、後から業務に支障が出る: 判断基準を確認する前に急いで解約すると、実は現場で日常的に使われていたことが後から発覚するケースがあります。解約前には必ず利用中の部署への事前確認を挟んでください
• 棚卸し台帳を作ったところで満足し、統合・解約の実行フェーズに進まない: 台帳の作成自体がゴールになってしまい、実際のコスト削減や契約主体の統一まで至らないまま放置される会話も多く聞きます。台帳完成後のタスクリストと担当者・期限を明確に決めてから着手することをお勧めします
• 契約更新日を確認せずに解約を進め、違約金や無駄な支払いが発生する: サービスによっては年払い契約の途中解約に違約金が発生する場合があります。解約前に契約条件を必ず確認してください

これらの失敗の多くは、「勢いで一気に進めようとする」ことが原因になっています。10〜30人規模の会社で兼任者がこの作業を進める場合、一つひとつの工程を着実に踏むことの方が、結果的に早く、かつ安全に整理を終えられます。

この整理が「情シス立ち上げ」の土台になる理由

部署ごとに乱立したSaaSの整理は、単なるコスト削減や台帳整備にとどまらず、この先会社がさらに拡大し、専任の情シス担当（いわゆる「ひとり情シス」）を置くようになったときの土台づくりでもあります。

会社の規模が30人を超え、専任の担当者が初めて置かれる段階になったとき、その担当者が最初に直面するのが「これまで誰も把握していなかった契約の全体像を、一から洗い出す」という作業です。もし10〜30人の段階でこの棚卸しと契約主体の統一が済んでいれば、専任担当者は「ゼロから発掘する」作業を省略でき、より本質的な業務改善に早くから着手できます。

逆に、この整理を先送りにしたまま会社が拡大すると、専任担当者が着任した初日から「得体の知れない契約の山」と向き合うことになり、貴重な立ち上がり期間の多くを、本来なら不要だったはずの発掘作業に費やすことになります。10〜30人という今の段階でこの整理に取り組むことは、将来の担当者への引き継ぎ資料を先回りして整えているのと同じ意味を持ちます。

まとめ: 「誰が契約したか分からない」を今のうちに解消する

部署ごとに個別契約された小規模SaaSの乱立は、10〜30人という規模だからこそ起きやすく、また今のうちであれば比較的軽いコストで整理できる問題でもあります。会社がさらに拡大し、部署の数や社員数が増えてから同じ整理を行おうとすると、対象となる契約数も関係者の数も膨れ上がり、着手のハードルは今よりずっと高くなります。

まずは経理の明細から、部署をまたいで契約されているSaaSの全体像を洗い出すところから始めてください。重複を見つけたら切り替えコストを踏まえて判断し、契約主体を法人名義に統一し、最後に再発を防ぐ軽いルールを社内に定着させる。この一連の流れを一度きちんと回しておくことが、この先の会社の拡大局面での混乱を大きく減らすことにつながります。