部門ごとにSaaSが増え、顧客情報は営業支援ツールと会計ソフトとスプレッドシートに分かれている。月末になると、誰かが3つを突き合わせて数字を合わせている。

この状態を「ツールが多すぎる」と捉えて数を減らそうとすると、たいてい失敗します。問題はツールの数ではなく、同じデータの正本がどこにあるかが決まっていないことだからです。

本記事では、SaaSが乱立する構造、統合すべきものとそうでないものの判断基準、そして進め方を整理します。

乱立は「数」ではなく「重なり」で判定する

最初に定義を揃えます。SaaSの数が多いこと自体は問題ではありません。部門の業務に合った専用ツールを使うほうが、生産性は上がります。

問題になるのは、次の状態です。

状態具体的に起きていること乱立か
ツールは多いが、扱うデータが重ならない経理は会計ソフト、人事は勤怠システム。互いに参照しない問題なし
同じデータを複数のツールに入力している顧客情報をSFAにも請求システムにも手で入れている乱立
同じ指標の数字が部署ごとに違う受注額が営業部と経理部で一致しない乱立
誰が何を契約しているか把握できない退職者のアカウントが残っている、同種のツールが部署ごとにある乱立

判定の問いは2つで足ります。

  1. 同じ情報を、2つ以上のツールに人が入力している箇所はあるか
  2. 部署間で、同じ名前の数字が一致しないことはあるか

どちらかが「ある」なら、数に関係なく乱立しています。

なぜ乱立するのか——3つの構造

構造1：調達が部門の予算で完結する

SaaSは初期費用が小さく、月額も部門の裁量で決裁できる金額に収まることが多くあります。そのため、情報システム部門を通らずに契約できます。

この仕組み自体は悪くありません。現場が必要なツールを速く入れられるのは利点です。問題は、契約時に「このツールはどのデータを扱い、それは他のどこと重なるか」を誰も確認しないことです。

構造2：正本データの置き場が決まっていない

顧客、取引、商品、社員。これらのデータには、本来「正しい値はここにある」という正本が1つあるべきです。

正本が決まっていないと、各ツールがそれぞれ自分のデータを持ち、どれが正しいかを判断するための手作業が発生します。月末の突合、会議での数字の食い違い、転記作業は、すべてここから生まれています。

構造3：連携を後回しにして導入する

新しいツールを入れるとき、「まず使い始めて、連携は後で考える」という進め方になりがちです。そして後で考えることはほぼありません。

結果として、連携されないまま運用が固まり、人が手でつなぐ作業が業務として定着します。一度定着した手作業は「いつものやり方」になり、問題として認識されなくなります。

統合すべきもの、すべきでないもの

乱立への対処として「全社で1つのツールに統一する」は、多くの場合うまくいきません。統合の対象を分けて考えます。

対象統合すべきか理由
正本データの置き場（顧客・取引・商品・社員）すべき複数あると、どれが正しいかの判断に工数がかかり続ける
認証（ログインの入口）すべき入退社のたびに全ツールのアカウントを手で管理することになる
契約と費用の管理すべき把握できないツールは、解約もセキュリティ対策もできない
個々の業務ツール（タスク管理、チャット、デザインなど）原則しない業務に合った専用ツールの利点を失う。使い勝手が落ちると別ツールが再び増える

正本・認証・契約の3つを押さえれば、個々の業務ツールは増えても構いません。逆にこの3つが決まっていないと、ツールを減らしても乱立は再発します。

オールインワン型に寄せる場合の注意

「1つのツールで全部できる」製品に寄せる判断もあり得ます。ただし、各機能は専用ツールより弱いことが多く、現場が不足を補うために別のツールを契約し直すという形で乱立が再発します。

寄せるなら、対象は正本データを持つ中核機能に限定し、周辺業務は専用ツールを許容する設計にしてください。

進め方

全社一斉の統合プロジェクトは、1年以上かかり、その間に新しいSaaSが増えます。正本データを1種類ずつ決める形で、小さく区切って進めます。

段階やること完了の基準
1契約中のSaaSをすべて洗い出す（経費精算の明細からも拾う）契約・費用・管理者の一覧がある
2各ツールが扱っているデータの種類を書き出す顧客・取引などの重なりが見えている
3最も重なりが多いデータを1種類選び、正本の置き場を決める「顧客情報の正本は◯◯」と文書化されている
4正本以外のツールは、正本から読む形に切り替える（連携または手作業の廃止）そのデータの二重入力がなくなっている
5次のデータ種別で3〜4を繰り返す3か月ごとに1種類ずつ進んでいる

段階1では、情報システム部門の管理台帳だけでは足りません。経費精算の明細と法人カードの利用履歴から拾わないと、部門が個別に契約したツールが漏れます。台帳の作り方はSaaS管理台帳の作り方で扱っています。

進めるときにつまずく4か所

現場の反発で止まる

「使い慣れたツールを取り上げられる」という反発は必ず出ます。

対処は、個々の業務ツールは取り上げないと最初に明言することです。統合するのは正本データの置き場であり、現場が使う画面ではない、という線引きを示すと、反発の大半は消えます。

連携の開発費で予算が尽きる

ツール間をすべてAPIでつなごうとすると、開発と保守の費用が膨らみます。

対処は、連携しないという選択肢を残すことです。正本から月1回エクスポートして読み込めば足りる業務まで、リアルタイム連携にする必要はありません。連携の頻度は、そのデータが変わる頻度と、古いデータで判断したときの損失の大きさで決めます。

標準化しないままツールを入れて、二重入力が残る

統合先のツールを決めても、業務のやり方が部署ごとに違ったままだと、現場は結局スプレッドシートで補います。ツールの導入前に業務の手順を揃えておく必要があります。詳しくはSaaSを入れたのに二重入力が残る理由で扱っています。

契約を禁止した結果、見えなくなる

乱立を止めようとして新規契約を禁止すると、経費精算や個人のカードで契約され、把握できないツールが増えます。対処の考え方はシャドーITは禁止すると増えるで扱っています。

まとめ

  • 乱立は数ではなく、同じデータの重なりで判定します。二重入力と、部署間で一致しない数字があれば乱立です
  • 原因は、部門で完結する調達、正本データの置き場が決まっていないこと、連携の後回しです
  • 統合すべきは正本データ・認証・契約の3つ。個々の業務ツールまで1つにする必要はありません
  • 全社一斉ではなく、正本データを1種類ずつ決める形で3か月単位に区切ります
  • 現場のツールを取り上げない、すべてを連携しない、禁止で押さえない。この3点が止まらないための条件です

SaaSの費用面の管理はSaaSコストが増え続ける理由で扱っています。