複数部署が別々にSaaS契約した結果のロックイン、契約の棚卸しと統合

社員数が100人を超えるあたりから、多くの会社で共通して起きる現象があります。営業部はSFAツールA、人事部は労務管理ツールB、経理部は経費精算ツールC、というように、各部署が自分たちの業務に最適だと判断したSaaSを、それぞれ独自の稟議で契約していく現象です。ひとり情シスがまだ全社のIT環境を目視で把握できていた30〜100人規模の頃はまだしも、部署の数が増え、各部署に予算の裁量が生まれてくる100〜300人規模になると、この「部署ごとの個別最適契約」は加速度的に増えていきます。

問題は、この状態が単なる「契約数の多さ」にとどまらないことです。部署ごとに個別契約したSaaSは、それぞれが独自のロックイン構造を持ちます。データはそのSaaS独自の形式でしか保存されておらず、契約者は当時の担当者個人のメールアドレスになっており、他の類似ツールとの連携も考慮されていない。気づいたときには、10も20もの「小さなロックイン」が社内に散らばっている状態になっています。このガイドは、ひとり情シスから複数人体制に移行しつつある情シスチームが、この状態をどう棚卸しし、どこまで、どう統合していくべきかを判断するための手順を解説します。

なお、当メディアには脱ロックインの第一歩: 自社で管理すべきアカウント一覧や使っていないSaaSの見つけ方。サブスク費用の棚卸しといったコラムがありますが、これらは主に個人の担当者が単独で行う棚卸し作業に焦点を当てています。本ガイドはそれとは異なり、複数部署にまたがる契約群を、複数人の情シスチームがどのように役割分担しながら統合の意思決定まで進めるかという、より組織的なプロセスに焦点を当てています。

なぜ100-300人規模で「部署ごとの個別契約」が増えるのか

まず、この現象がなぜ起きるのかを構造的に理解しておくことが、対処法を考える上での土台になります。

第一の理由は、稟議の決裁権限が部署長レベルまで委譲され始めることです。0-10人や10-30人の会社では、数万円程度のSaaS契約であっても経営者の目に触れることが多く、結果的に全社のツール導入状況が経営者一人の頭の中に集約されていました。しかし100-300人規模になると、月額数万円程度のSaaS契約は部署長の決裁で完結するようになり、情シスや経営層が個別の契約内容を逐一把握する仕組みがないまま、契約数だけが増えていきます。

第二の理由は、部署ごとの業務の専門性が高まることです。営業部が使うSFA、人事部が使う労務管理システム、経理部が使う会計・経費精算システムは、それぞれの業務ドメインに特化した機能を持つため、汎用的な全社共通ツールでは満足できないというニーズが実際に存在します。部署側からすれば「自分たちの業務に最適なツールを選んだ」という正当な判断であり、悪意や怠慢によるものではありません。

第三の理由は、SaaSというビジネスモデル自体が、個別部署からの直接契約を前提に設計されていることです。多くのSaaSは、クレジットカード1枚とメールアドレスがあれば、情シスを介さずにその日のうちに契約・利用開始できます。この手軽さは部署にとっての利便性である一方、情シスにとっては「知らないうちに契約されている」状態を常態化させる要因になります。

これらの理由はどれも、個々の部署や担当者を責めるべき話ではありません。むしろ、100-300人という規模の会社が組織として成長する過程で、ほぼ必然的に発生する構造的な現象だと捉えるべきです。だからこそ、事後的に「なぜ勝手に契約したのか」を問い詰めるのではなく、チームとして仕組みで対処する発想が必要になります。

さらに付け加えると、30-100人規模の「ひとり情シス」期にはこの問題がまだ本格化していないケースが多いことにも触れておく必要があります。担当者が1人しかいない段階では、そもそも部署からの相談を情シスが一手に受け止めているため、結果的に契約の窓口が一本化されていることが少なくありません。ところが情シスが複数人体制に移行し、それぞれのメンバーが特定の部署を主に担当するようになると、逆説的に「情シスの誰かは把握しているが、チーム全体としては把握できていない」という新しいタイプの分断が生まれます。これは組織が成熟する過程での成長痛のようなもので、複数人体制になったからこそ意識的に対処しなければならない課題だと理解しておいてください。

部署ごとの個別契約が生む3種類のロックイン

部署ごとに乱立したSaaS契約は、それぞれが独立してベンダーロックインの構造を抱えています。統合を検討する前に、どのようなロックインが起きているかを整理しておきます。

3つの中でも特に見落とされやすいのが、契約者個人のロックインです。部署内では「Aさんが契約してくれたツール」という認識で運用が続いていても、Aさんが異動・退職した瞬間、契約更新の通知が届かなくなったり、管理者権限を持つアカウントに誰もアクセスできなくなったりする事態が起こります。100-300人規模でチーム体制の情シスを組む際は、まずこの契約者個人のロックインから優先的に洗い出すことをお勧めします。

3つのロックインは、それぞれ単独で存在するのではなく、複合的に絡み合っていることが実務上はほとんどです。例えば、ある部署が5年前に個人契約したツールが、その後部署の中核業務フローに組み込まれ、大量の履歴データが蓄積されている場合、そのツール1つを統合しようとするだけで、契約者個人・データ形式・業務プロセスという3つのロックインすべてに同時に向き合う必要が出てきます。棚卸しの初期段階では、この複合度合いをおおまかにでも把握しておくと、後の統合の優先順位付けが格段にやりやすくなります。目安としては、「契約から3年以上経過し」「契約者が当時の担当者のまま」「かつ部署の日常業務に深く組み込まれている」ツールほど、複合的なロックインが進行している可能性が高いと考えてください。

棚卸しをチーム体制で進める意味

ひとり情シスの時代であれば、棚卸しは自分一人で完結する作業でした。しかし部署をまたぐ契約の棚卸しは、情シスが複数人になったからこそ、初めて実行可能になる作業でもあります。理由は単純で、部署の数だけヒアリング対象が存在し、各部署の業務理解を伴う対話が必要になるため、1人の担当者がすべての部署を丁寧に回るには時間的な限界があるからです。

チーム体制で進める場合、担当分担の考え方が重要になります。担当分担そのものの決め方については兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で扱っていますが、SaaS契約の棚卸しに特化した分担としては、次のような割り振り方が現実的です。

1. 部署別担当制: メンバーごとに担当部署を割り振り、各自が担当部署の契約状況をヒアリングする
2. カテゴリ別担当制: 「コミュニケーションツール系」「業務管理系」「セキュリティ系」のようにツールのカテゴリで分担し、各自が全部署を横断してカテゴリ内の契約を洗い出す
3. ハイブリッド制: 主要部署（営業・人事・経理など契約数が多い部署）は部署別に固定担当を置き、それ以外の小規模部署はカテゴリ別担当がまとめて対応する

部署数が多い会社ではハイブリッド制が現実的な落としどころになることが多いです。いずれの分担方式を選ぶ場合も、棚卸しの進捗と結果を集約する台帳フォーマットだけは統一しておく必要があります。担当者ごとにバラバラな形式で情報が集まると、後工程の統合判断がかえって困難になります。

分担を決める際にもう一つ考慮すべきなのが、進捗の可視化です。棚卸しは地味で時間のかかる作業であり、担当者によって進み方にばらつきが出やすい業務でもあります。チームのリーダー役、あるいは持ち回りの進行管理担当を1人決め、週次で「どの部署の棚卸しが完了し、どこが手つかずか」を簡単に共有する時間を設けることをお勧めします。この共有の場は、単なる進捗確認にとどまらず、「営業部で見つかったこの契約形態、他の部署にも似たものがないか」といった横断的な気づきを交換する機会にもなります。ひとりで進めていたときには得られなかった、チームならではの利点です。

棚卸しにかかる期間の目安についても触れておきます。部署数や契約数によって大きく変わりますが、10部署程度・契約数50〜100件規模の会社であれば、2〜3人のチームで週あたり数時間ずつ稼働し、1〜2ヶ月程度を見込んでおくと無理のないペースになります。他の通常業務と並行しながら進めることになるため、最初から「〇〇週間で完了させる」という固定的な期限を切るよりも、部署ごとの進捗を見ながら柔軟に調整する方が現実的です。

棚卸しシートに含めるべき項目

部署横断のSaaS棚卸しでは、単なるツール一覧以上の情報を集める必要があります。統合の可否を判断する材料として、次の項目を含めることをお勧めします。

• ツール名・提供会社: 何のサービスか
• 契約部署: どの部署が契約しているか
• 契約者名義: 法人契約か個人契約か、契約者は現職か
• 月額・年額費用: 契約金額と支払いサイクル
• 契約開始時期・契約更新タイミング: いつから使っており、次の更新はいつか
• 利用人数・利用実態: 実際に何人が、どの程度の頻度で使っているか
• 保持しているデータの種類: 顧客情報・人事情報・会計情報など、機密度の高いデータを含むか
• エクスポート機能の有無: データを標準的な形式（CSVなど）で書き出せるか
• 類似ツールの有無: 社内の他部署、あるいは全社共通ツールに同様の機能を持つものがないか

このうち「類似ツールの有無」は、統合判断の入口になる重要な項目です。棚卸しを進めていくと、部署Aと部署Bがほぼ同じ機能を持つ別々のツールを、それぞれ独立に契約しているケースが少なからず見つかります。こうした重複は、統合によってコスト削減とロックイン解消を同時に実現できる、最も分かりやすい対象になります。

棚卸しシートを埋める作業は、部署へのアンケート配布だけで完結させようとすると精度が落ちます。特に「利用人数・利用実態」や「保持しているデータの種類」といった項目は、契約担当者本人の主観だけでは正確に答えられないことが多いためです。可能であれば、アンケートの回答をそのまま鵜呑みにせず、実際にツールの管理画面にログインして利用ログを確認したり、経理の支払い記録と突合したりする一手間を、チームの誰かが担当することをお勧めします。この確認作業は地道ですが、後で「実は誰も使っていなかった」あるいは「アンケートには書かれていなかった機密データが入っていた」といった事後発覚を防ぐ上で欠かせません。

統合可否を判断する4つの基準

棚卸しによって契約の全体像が見えてきたら、次に「どのツールを統合すべきか」を判断する段階に入ります。すべてのツールを無理に一本化する必要はありません。判断基準を明確にし、統合すべきものと、部署独自のまま残すべきものを見極めます。

4つの基準すべてが統合を後押ししているツールは、優先度の高い統合候補として扱ってよいでしょう。一方、基準によって結論が分かれる場合は、拙速に統合を決めず、部署へのヒアリングを重ねて実態を見極める必要があります。特に「業務フローへの影響」は、情シス側だけでは正確に判断できないことが多いため、必ず部署側の当事者を交えて検討してください。

判断に迷うケースを効率的に処理するために、4つの基準をそれぞれ3段階（高・中・低）で採点し、単純なスコアリング表にまとめる方法も実務では有効です。厳密な統計的手法である必要はなく、あくまでチーム内で「なぜこのツールを優先したのか」を後から説明できる材料として使う程度で十分です。スコアリングの結果、複数のツールが同程度の優先度になった場合は、費用インパクトが大きいものから着手すると、統合の効果を早期に実感しやすく、チーム内・部署側双方のモチベーション維持にもつながります。

なお、この判断プロセスに経営層をどこまで巻き込むかも、事前に決めておくべき論点です。個々のSaaS契約は金額規模で見れば経営会議にかけるほどのものではないことが大半ですが、統合対象を束ねると年間数百万円規模の予算インパクトになることも珍しくありません。情シスチーム内で完結させる決裁ラインと、経営層への報告・承認が必要になる金額のしきい値を、統合作業に着手する前にあらかじめ決めておくと、後になって「なぜ相談なく進めたのか」という手戻りを防げます。

統合を進める際に踏むべきステップ

統合対象が定まったら、実際の統合作業に入ります。焦って一気に切り替えると、部署の業務を止めてしまうリスクがあるため、段階的に進めることをお勧めします。

1. 統合後のツールを確定する: 複数の類似ツールのうち、どれを残すか、あるいは新たに全社共通ツールを選定するかを決める。この際、機能面だけでなく、既存データの移行のしやすさも判断材料に含める
2. 移行対象部署への説明と合意形成: 統合によって影響を受ける部署に対し、なぜ統合するのか、いつまでに何をしてもらう必要があるのかを丁寧に説明する。一方的な通達ではなく、部署側の懸念を聞く場を設けることが望ましい
3. 並行稼働期間を設ける: 旧ツールと新ツールを一定期間並行して稼働させ、データ移行の漏れやトラブルに備える
4. 旧契約の解約手続き: 移行が完了したら、旧ツールの契約を解約する。解約前には、データのエクスポートが完了しているか、契約者名義の確認、解約の通知期限などを必ずチェックする
5. 統合後の運用ルールを明文化する: 統合したツールについて、今後は情シスを介さずに新たな類似契約を結ばないというルールを、部署側と合意した上で明文化する

このステップの中でも特に軽視されがちなのが5番目です。せっかく統合しても、統合後に別の部署が同じ課題に直面し、再び独自にツールを契約してしまえば、時間をかけて解消したはずのロックインが再発します。統合は一度きりの作業ではなく、再発防止の運用ルールとセットで初めて完結します。

並行稼働期間の長さについても、あらかじめ目安を決めておくとよいでしょう。会計・人事など月次・年次の締め処理が絡む業務系ツールの場合、少なくとも1回の締め処理サイクルを新旧両方のツールで確認できる期間を確保することをお勧めします。単純なコミュニケーションツールであれば数週間程度で十分なこともありますが、契約・請求・法定帳票が絡むツールほど、並行稼働の期間は長めに見積もっておくほうが安全です。判断に迷う場合は、部署側の締め処理の責任者に直接「何回分のサイクルを確認できれば安心か」を確認してから期間を決めることをお勧めします。

統合を見送るべきケースも存在する

すべての重複ツールを無理に統合することが、必ずしも正解とは限りません。次のようなケースでは、あえて統合を見送る判断も合理的です。

• 部署の業務が極めて専門的で、汎用ツールへの統合が業務効率を著しく損なう場合: 例えば製造部門の生産管理システムのように、業界特化の機能に強く依存しているケース
• 統合コストが、統合によって得られるメリットを明らかに上回る場合: データ移行や業務フロー再設計にかかる工数が膨大で、費用対効果が見合わないケース
• 契約更新のタイミングが近く、無理に前倒しで統合するより、更新時期に合わせて計画的に進めたほうが合理的な場合

統合を見送る場合でも、「なぜ統合しないと判断したか」を台帳に記録として残しておくことをお勧めします。数年後、担当者が変わったタイミングで同じ議論が蒸し返されることを防げますし、状況が変化した際に再検討する際の判断材料にもなります。

統合を見送ったツールについても、完全に手を離してよいわけではありません。契約者名義が個人のままになっている場合は、統合しないという判断とは切り離して、契約者名義だけは組織アカウントに変更しておくことを強くお勧めします。統合の是非と、契約者個人へのロックインを解消するかどうかは、別の問題として扱うべきだからです。機能や業務フローの統合は見送っても、緊急連絡先・管理者権限といった最低限の情報だけは情シスチームが把握できる状態にしておくことで、担当者の異動・退職時のリスクを大幅に下げられます。

部署との関係性を壊さないための進め方

SaaS統合のプロセスで最も注意すべきなのは、情シスチームと各部署との信頼関係です。情シスが一方的に「このツールは統合するので使うのをやめてください」と通達するようなやり方は、たとえ論理的に正しい判断であっても、部署側の反発を招きやすく、その後の情シスへの協力姿勢そのものを悪化させかねません。

「最初に営業部のSFAを統合しようとしたとき、いきなり『来月から新しいツールに切り替えます』と伝えたら、営業部から強い反発がありました。振り返ると、私たちは統合のメリットばかり説明していて、営業部が今のツールのどこを気に入っているのかを聞いていなかったんです。次に人事部の労務ツールを統合したときは、先にヒアリングの時間を取り、彼らが本当に困っている点と、逆に手放したくない機能を先に洗い出してから提案したところ、驚くほどスムーズに合意できました」

この教訓が示すように、統合の提案は「情シスが決めたことを伝える」のではなく、「部署の困りごとを一緒に解決する」という姿勢で進めることが、複数人体制の情シスチームだからこそ実践しやすくなります。部署別担当制を敷いていれば、担当者が日頃から該当部署と接点を持ち、信頼関係を築いた上で統合の話を持ち出せるという利点があります。

統合によるコスト削減効果を過大評価しない

部署ごとのSaaS契約を統合する動機として、ロックイン解消と並んでよく挙げられるのが「コスト削減」です。実際、複数の部署が別々に契約していたツールを1つの全社契約にまとめることで、ボリュームディスカウントが適用されたり、重複していた基本料金が1本化されたりする効果は現実に見込めます。ただし、この効果を過大に見積もることには注意が必要です。

統合を検討する際によくある誤算は、統合後のツールが元のツールと機能面で完全に同等ではないという点です。部署Aが使っていたツールの独自機能を、統合後の全社ツールが持っていない場合、その機能を代替するための追加開発やカスタマイズが必要になり、想定していたコスト削減効果が薄れることがあります。また、契約形態がユーザー数に応じた従量課金の場合、統合後の総ユーザー数によっては、想定より高い料金帯に入ってしまうケースもあります。

統合の意思決定をする際は、単純な「月額費用の合計を比較する」だけでなく、次の観点も含めて総合的に見積もることをお勧めします。

• 移行作業にかかる人件費: 情シスチームおよび部署側の担当者が移行に費やす工数を、時間単価換算でおおまかに見積もっておく
• 機能ギャップを埋めるための追加費用: カスタマイズやアドオン機能の追加が必要になる場合の費用
• 教育・定着にかかる時間: 新しいツールに部署のメンバーが慣れるまでの生産性低下を、一時的なコストとして織り込む

これらを踏まえた上でなお統合のメリットが上回るのであれば、統合を進める根拠として自信を持って部署や経営層に説明できます。逆に、精査した結果コスト面のメリットが薄いと分かった場合でも、ロックイン解消という別の観点から統合を正当化できる場合があります。コスト削減とロックイン解消は、必ずしも常に両立するとは限らない、別々の評価軸であると理解しておいてください。

統合後も台帳とセットで運用を続ける

SaaS契約の棚卸しと統合は、一度実施して終わりにできる作業ではありません。新しい部署が生まれたり、既存部署の業務内容が変化したりするたびに、新たな個別契約の芽が生まれる可能性は常に存在します。統合作業を終えたら、次のような継続的な運用に落とし込むことが重要です。

• 新規SaaS契約時の情シス確認フローを設ける: 一定金額以上のSaaS契約を結ぶ際は、情シスへの事前相談を必須とするルールを社内に周知する
• 定期的な契約棚卸しをスケジュール化する: 半年〜1年に1回、全社のSaaS契約状況を再確認するタイミングを設ける
• 台帳を常に最新化する: 統合後の契約状況を、システム管理台帳に反映し続ける。台帳の運用設計については100人を超えたら属人化台帳をどう運用に乗せるかで詳しく解説しています

新規契約の事前相談フローを設ける際は、部署側の意思決定スピードを損なわないよう配慮することも大切です。情シスへの相談が「面倒な手続き」と受け取られると、結局部署は情シスを介さずに契約してしまい、ルール自体が形骸化します。相談窓口を明確にし、返信までの目安時間を決めておくなど、部署側にとっても負担の少ない仕組みにすることが、再発防止の実効性を左右します。

よくある失敗パターンから学ぶ

最後に、部署横断のSaaS統合でチームが陥りやすい失敗パターンをいくつか紹介します。これから着手するチームが、同じ轍を踏まないための参考にしてください。

1つ目は、棚卸しの範囲を最初から広げすぎることです。全部署・全ツールを一度に洗い出そうとすると、作業量が膨らみすぎて途中で息切れし、結局中途半端な状態で放置されるケースが多く見られます。契約数の多い主要部署、あるいはロックインのリスクが高いと事前に分かっている部署から着手し、成功体験を積みながら対象を広げていくほうが、チームのモチベーションを維持しやすくなります。

2つ目は、統合の判断を情シスチームだけで完結させようとすることです。4つの判断基準に沿って情シス側で分析すること自体は重要ですが、最終的な統合の可否は、必ず部署側の実務担当者を交えて確認する場を設けてください。情シス側から見て明らかに非効率に見える契約でも、部署側には情シスが把握していない事情がある場合があります。

3つ目は、統合作業のスケジュールを契約更新のタイミングと無関係に決めてしまうことです。多くのSaaSは年間契約が基本で、契約期間の途中で解約しても、残存期間分の返金が受けられないことがあります。統合のスケジュールを組む際は、対象ツールそれぞれの契約更新月を必ず確認し、可能な限り更新のタイミングに合わせて移行を完了させることをお勧めします。

まとめ: 部署ごとのロックインは「個別対処」ではなく「仕組み」で防ぐ

部署ごとに乱立したSaaS契約は、それぞれが独立したロックインを抱えており、放置すればするほど、データ・契約者名義・業務フローの3つの側面で統合の難易度が上がっていきます。100-300人規模になり、情シスがひとりから複数人のチーム体制に移行するタイミングは、この乱立状態に本格的に向き合える最初の機会でもあります。

棚卸しは部署別担当制やカテゴリ別担当制でチームとして分担し、統合可否は機能の重複度・データの重要性・費用・業務フローへの影響という4つの基準で判断する。統合を進める際は部署との信頼関係を大切にし、統合して終わりにせず、新規契約時の確認フローや定期棚卸しといった仕組みに落とし込む。この一連の流れを、チーム体制になったからこそ実行できる仕事として捉え、着実に進めていってください。