拠点・部署ごとに異なるベンダーを使っている状態を整理する統合判断

複数の拠点や部署を持つ100-300人規模の会社を情シスチームとして見渡すと、しばしば奇妙な光景に出くわします。本社のWebサイトはA社、支店の業務システムはB社、営業所のネットワーク機器はC社、工場の生産管理システムはD社――拠点や部署ごとに、まったく異なる開発会社・ベンダーが個別に契約されている状態です。一見すると、これはマルチベンダー体制のメリット・デメリットで語られるような、意図的なリスク分散策に見えるかもしれません。しかし実態は多くの場合、まったく異なります。拠点ごとに独立した経緯でシステムが導入され、それぞれの拠点の担当者が個別に業者を選んだ結果、たまたま複数のベンダーが混在している状態にすぎないことがほとんどです。

この状態は、マルチベンダーという言葉が示す「戦略的な分散」とは似て非なるものです。当メディアのマルチベンダー体制のメリット・デメリットは、1社への依存から脱却するために意図的に複数ベンダーを使い分けるかどうかを検討する担当者向けの記事でした。本ガイドが扱うのは、その逆の起点です。すなわち、既に自然発生的にマルチベンダー化してしまっている拠点・部署の契約群を、複数人の情シスチームがどう棚卸しし、どこまでを統合し、どこを維持すべきかを判断していくプロセスです。「意図せず生まれた分散」を、まず正確に実態把握した上で、「維持すべき分散」と「統合すべき重複」に仕分けていく作業だと考えてください。

「自然発生的な分散」と「戦略的な分散」の違いを見極める

統合の議論に入る前に、まず自社の状態が、自然発生的な分散なのか、それとも既に戦略的な分散なのかを見極める必要があります。両者は表面的には似ていますが、対処の方向性がまったく異なります。

多くの100-300人規模の会社は、表の左側「自然発生的な分散」の状態にあります。この状態自体が悪いというわけではありませんが、放置すると、契約管理コストの増大、セキュリティポリシーの不統一、緊急時の対応窓口の分散といった問題を引き起こします。本ガイドの目的は、この自然発生的な分散状態を、少なくとも「情シスチームが全体像を把握し、意図を持って維持または統合を判断できる状態」まで引き上げることにあります。

見極めの際に注意したいのは、「戦略的な分散」を装った「自然発生的な分散」も存在するという点です。過去に誰かが「リスク分散のため」という理由を後付けで説明していても、実際には単に個別の経緯で異なるベンダーが選ばれていただけ、というケースは少なくありません。この見分け方としては、「その分散の意図を、いつ、誰が、どのような基準で決めたのか」を説明できる記録が残っているかどうかを確認するとよいでしょう。記録が残っておらず、口頭の説明も曖昧なままであれば、それは戦略的な分散ではなく、事後的に理由づけされた自然発生的な分散である可能性が高いと判断してください。

もう一つの見分け方として、「その分散状態を、情シスチームが定期的に評価・見直ししているかどうか」も参考になります。戦略的な分散であれば、当然、その効果を定期的に検証し、必要に応じて分散の範囲を調整するはずです。一方、自然発生的な分散は、多くの場合、一度生まれたきり誰も見直すことなく放置され続けています。この「見直しの有無」という視点は、単なる分散の実態把握だけでなく、今後どのような運用体制を築くべきかのヒントにもなります。

拠点・部署ごとのベンダー分散が生まれる典型的な経緯

なぜこのような分散状態が生まれるのか、典型的な経緯を整理しておきます。原因を理解することは、今後同じパターンの分散を防ぐ上でも役立ちます。

第一に、拠点開設のタイミングと、本社の情シス体制が整うタイミングにズレがあることです。会社が拡大する過程で、新しい拠点や部署が先に立ち上がり、その後になって本社の情シス体制が追いついてくるというケースは珍しくありません。拠点が先に立ち上がっている間は、拠点の責任者が地元の業者や、知り合い経由の紹介で開発会社を選定することになり、本社が把握しないまま契約が進みます。

第二に、部署ごとの業務要件の専門性です。生産管理システムに強いベンダー、Webサイト制作に強いベンダー、ネットワークインフラに強いベンダーは、それぞれ異なる専門領域を持っていることが多く、部署が個別に「この業務ならこの会社が良い」と判断した結果、自然と複数のベンダーが並立することになります。

第三に、M&Aや事業統合の経緯です。会社が買収や統合を経て拡大してきた場合、統合前の各組織がそれぞれ独自のベンダーと取引していた関係が、統合後もそのまま引き継がれることがあります。この場合、単なる契約の重複にとどまらず、システムそのものの重複や、データ形式の違いといった、より根深い課題を抱えていることも少なくありません。

第四に、拠点責任者の裁量権の大きさです。100-300人規模の会社では、拠点や支店の責任者に一定の予算執行権限が委譲されていることが多く、その権限の範囲内であれば、本社の情シスに相談せずにベンダーを選定・契約できてしまいます。この権限自体は、拠点の機動力を保つ上で必要なものですが、情シスチームとの情報共有の仕組みが伴っていないと、本社が把握しないままベンダーが増え続ける結果を招きます。

これらの経緯を振り返ると、拠点・部署ごとのベンダー分散は、会社が成長する過程でほぼ避けられない副産物であることが分かります。だからこそ、分散が生まれたこと自体を問題視するのではなく、分散した状態をいかに正確に把握し、必要な範囲で整理していくかという、事後的なマネジメントの視点が重要になります。

棚卸しの第一歩: ベンダー台帳を作る

拠点・部署ごとのベンダー分散を整理する第一歩は、どの拠点・部署が、どのベンダーと、何の契約をしているかを一覧化するベンダー台帳を作ることです。システムそのものの棚卸しとは別に、「ベンダー」を主語にした台帳を作ることがポイントです。

• ベンダー名: 契約している開発会社・業者の名称
• 対応拠点・部署: そのベンダーがどの拠点・部署のシステムを担当しているか
• 契約内容: 保守契約か、都度発注の請負契約か、契約形態を明記する
• 契約金額・支払いサイクル: 年間の取引金額と支払いの頻度
• 窓口担当者: 社内側の窓口担当者と、ベンダー側の担当者
• 契約開始時期: いつからの取引か
• 対応可能な技術領域: そのベンダーが技術的にどこまで対応できるか

このベンダー台帳を作る過程で、これまで気づかなかった事実が明らかになることがあります。例えば、A拠点とB拠点が、実は同じベンダーと個別に契約を結んでいたが、本社側ではそれぞれ別のベンダーだと認識していた、といったケースです。ベンダーを主語に整理し直すことで、システム単位の台帳だけでは見えなかった重複や関連性が浮かび上がってきます。

台帳を作成する際、「対応可能な技術領域」の欄は特に丁寧に埋めることをお勧めします。この項目は、ベンダー自身の営業資料やWebサイトの情報を鵜呑みにするのではなく、実際にこれまで発注してきた案件の内容から逆算して記入する方が、実態に即した情報になります。表向きには幅広い技術に対応できると謳っているベンダーでも、実際に得意としている領域は限られていることが少なくありません。この見極めは、後の統合可否の判断や、統合パターンを選ぶ際の重要な材料になります。

また、台帳作成の過程では、各ベンダーとの契約書そのものも合わせて確認しておくことをお勧めします。特に、契約の自動更新条項や、解約通知の期限、最低契約期間といった条件は、統合を進める際のスケジュールに直接影響します。台帳の項目として「解約通知期限」を追加しておくと、後の統合作業を計画する際に非常に役立ちます。拠点によっては契約書そのものが現地に保管されたままで、本社側に控えが存在しないこともあるため、この機会に契約書の写しを本社側でも一元管理できるよう整備しておくと、今後の同様の棚卸し作業の負担を大きく軽減できます。

チームでの分担調査: 拠点担当制の活用

ベンダー台帳の作成は、複数拠点・部署にまたがるヒアリングを伴うため、情シスチームでの分担が欠かせません。効果的な分担方法として、拠点・部署ごとに担当者を割り振る「拠点担当制」があります。

1. 担当拠点・部署を割り振る: チームメンバーごとに、担当する拠点・部署を決める
2. 現地の窓口担当者にヒアリングする: 各拠点・部署の実務担当者に、利用しているベンダーと契約状況を確認する
3. 経理の支払い記録と突合する: ヒアリングだけでは漏れる契約がないか、実際の支払い明細と照合する
4. 台帳フォーマットに落とし込む: 統一されたフォーマットで、集めた情報を台帳に反映する

この分担方式は、100-300人規模で複数拠点にシステムが散らばる問題の整理手順で扱っているシステムの拠点別棚卸しと、進め方が似ています。実際、システムの棚卸しとベンダーの棚卸しは同時並行で進めると効率的です。1回のヒアリングで、「どんなシステムを、どのベンダーから、どんな契約で使っているか」をまとめて確認できれば、拠点側の負担も軽減できます。

拠点担当制でヒアリングを進める際、担当者が最初に確認すべきなのは、システムやベンダーの情報そのものよりも先に、「その拠点における実質的な決裁者は誰か」という点です。拠点責任者が実務を把握しているとは限らず、実際には現場の特定の社員がベンダーとのやり取りを一手に担っているケースも多くあります。決裁者と実務担当者が異なる場合、両方にヒアリングすることで、より正確な情報が得られます。この決裁者と実務担当者の関係性は、後に統合の合意形成を進める際、誰にどのタイミングで話を通すべきかという段取りを組む上でも重要な手がかりになります。

ヒアリングの過程で、拠点側から「なぜ今さらこんなことを聞かれるのか」という戸惑いの反応が返ってくることもあります。この戸惑いを解消するためには、ヒアリングの目的が「拠点の裁量を制限すること」ではなく、「本社として拠点を適切にサポートできる体制を作ること」であるという説明を、最初の段階で丁寧に行うことが効果的です。特に、緊急時のベンダー対応が滞った際に本社が助けに入れないという課題感を共有すると、拠点側の協力も得やすくなります。

統合可否を判断する基準

ベンダー台帳が整ったら、次に「どのベンダーを統合すべきか」を判断する段階に入ります。判断基準は、次の4つの観点で整理すると分かりやすくなります。

拠点・部署ごとのベンダー統合は、単なるSaaS契約の統合よりも複雑な側面があります。ベンダーが変わるということは、そのベンダーが担ってきたシステムの保守・改修体制そのものが変わることを意味するためです。統合を検討する際は、コストや効率性だけでなく、統合後の保守体制がきちんと機能するかどうかを慎重に見極める必要があります。

4つの基準に加えて、統合を検討する際には「地理的な現地対応の必要性」も重要な判断材料になります。ネットワーク機器の設置や、複合機・POSレジといった物理的な機器の保守を伴うベンダーの場合、統合先のベンダーが実際に拠点まで駆けつけられる体制を持っているかどうかが、統合可否を大きく左右します。遠方の拠点にあるベンダーを、現地対応網を持たない全国区のベンダーに統合してしまうと、かえって障害対応のスピードが低下するリスクがあるため注意が必要です。この観点は、次に説明する統合パターンの選択にも直接関わってきます。逆に、クラウドサービスやリモート対応で完結する領域であれば、現地対応の制約は小さく、統合の自由度が高いと判断できます。

統合パターンの分類: 何を、どこまで統合するか

統合を検討する際、「全社で1社に統一する」という極端な選択肢だけでなく、いくつかの中間的なパターンも存在します。自社の状況に応じて、最適なパターンを選んでください。

• 完全統合型: 全拠点・全部署のベンダーを、単一のベンダーに統一する。管理はシンプルになるが、拠点固有の要件への対応力は下がりやすい
• 技術領域別統合型: Webシステム系、インフラ系、業務パッケージ系など、技術領域ごとに1社ずつに集約する。拠点をまたいだ技術領域の一貫性を保ちつつ、専門性は維持できる
• 地域ブロック統合型: 全国に拠点が散らばっている場合、地域ブロックごとにベンダーを集約する。現地対応が必要な業務（機器の設置・保守など）で有効
• 重要度別統合型: 事業継続への影響が大きいシステムのベンダーだけを優先的に統合し、影響の小さいシステムは各拠点の裁量に任せる

100-300人規模の会社では、いきなり完全統合型を目指すのではなく、技術領域別統合型や重要度別統合型から着手し、実績を積みながら統合の範囲を広げていくアプローチが現実的です。特に、拠点数が多い会社では、地域ブロック統合型を組み合わせることで、現地対応の実効性を保ちながら、契約数自体は削減できるバランスの取れた統合を実現しやすくなります。

どのパターンを選ぶにせよ、統合方針を決める際はチームで次のような問いを立てて検討することをお勧めします。「このベンダーが今後も存続し続ける可能性はどの程度か」「このベンダーへの依存度が今後さらに高まっていく見込みはあるか」「統合先として想定しているベンダーは、拡大する事業規模に対応できるキャパシティを持っているか」。これらの問いに対する答えが曖昧なまま統合を進めてしまうと、数年後に再び同じ課題に直面することになりかねません。統合は一度きりの作業ではなく、将来の事業拡大も見据えた中長期的な意思決定であるという認識を持つことが大切です。

統合を進める際のチーム内合意形成

統合パターンの方向性が定まったら、実際に統合を進める前に、チーム内での合意形成を丁寧に行う必要があります。拠点担当制でヒアリングを進めてきた場合、各担当者は自分が担当した拠点への思い入れや理解を持っていることが多く、統合によって「自分が担当してきた拠点のベンダーが変わってしまう」ことに、心理的な抵抗を感じる場合もあります。

「営業所のネットワーク機器を長年見てくれていたベンダーを、全社統合の対象にする話が出たとき、正直、担当していた自分としては抵抗がありました。ただ、チームで話し合う中で、単に契約を切り替えるのではなく、その営業所の特性や、これまでのベンダーとのやり取りで得た知見を、統合後の新しいベンダーにきちんと引き継ぐプロセスを設計することで、抵抗感がだいぶ和らぎました。統合そのものより、知見が失われることへの不安が大きかったのだと、後から気づきました」

この教訓が示すように、統合への抵抗感の背景には、単なる変化への不安だけでなく、「これまで積み上げてきた拠点固有の知見が失われるのではないか」という懸念が隠れていることが多くあります。統合を進める際は、契約の切り替えだけでなく、拠点固有の知見をどう引き継ぐかというプロセスをセットで設計することで、チーム内・拠点側双方の納得感を高められます。

知見の引き継ぎを具体的に設計する際は、次のような手順が有効です。まず、統合対象となるベンダーとの過去のやり取りの中で、特に重要だった判断や、拠点固有の事情に基づくカスタマイズの経緯を、拠点担当者が文書化します。次に、その文書を統合先の新しいベンダーに事前共有し、移行時の打ち合わせで内容をすり合わせます。最後に、一定期間は旧ベンダーと新ベンダーの両方に問い合わせできる並行期間を設け、知見の抜け漏れが実際の運用で発覚した場合に補完できる体制を整えます。この一連の手順を踏むことで、単なる契約の切り替えにとどまらない、実質的な引き継ぎが実現できます。

統合を見送るべきケース

すべての拠点・部署のベンダーを統合することが、必ずしも最適とは限りません。次のようなケースでは、あえて分散状態を維持する判断も合理的です。

• 拠点の業務が地理的・法的な特殊性を持つ場合: 海外拠点や、特定業界の規制が強い拠点など、現地事情に精通したベンダーでなければ対応が難しいケース
• 統合による切り替えコストが著しく大きい場合: 老朽化したシステムが拠点の基幹業務に深く組み込まれており、ベンダーの切り替えがシステムの入れ替えを伴うほど大掛かりになるケース
• 既に十分に管理された状態にある場合: 契約条件・対応品質ともに問題がなく、単にベンダーが複数存在するというだけで、実害が生じていないケース

統合を見送る場合でも、前述のベンダー台帳による一元管理だけは維持してください。統合しないという判断は、「把握しなくてよい」という意味ではありません。契約状況を常に情シスチームが把握できる状態を保った上で、あえて分散を維持するという、意図を持った選択にしておくことが重要です。

統合を見送ったベンダーについても、最低限の情報だけは統一基準で管理しておくことをお勧めします。具体的には、緊急連絡先、契約の更新タイミング、社内側の窓口担当者の3点です。統合は見送っても、そのベンダーとの取引が完全にブラックボックス化してしまうことは避けなければなりません。分散を維持する判断と、情報を把握し続ける努力は、切り離して考えるべき別の課題です。この3点さえ台帳に記録されていれば、担当者が急に不在になった場合でも、チームの他のメンバーが最低限の初動対応を取れる状態を保てます。

統合後の運用: 拠点との継続的な連携を保つ

統合を実施した後も、拠点や部署との関係が途切れないよう、継続的な連携体制を維持することが欠かせません。統合によってベンダーの窓口が本社に一本化されると、拠点側からすれば「今までは近くの業者にすぐ相談できたのに、本社を経由しないといけなくなった」という不便さを感じる場合があります。

実際、統合直後の数ヶ月は、拠点側から「前のベンダーの方が対応が早かった」といった声が上がることも珍しくありません。この反応をもって統合が失敗だったと即断するのではなく、新しい体制が定着するまでの一時的な摩擦として捉え、丁寧にフォローする姿勢が求められます。

この不便さを軽減するために、次のような運用を組み込むことをお勧めします。

1. 拠点向けの一次窓口を明確にする: 統合後も、拠点からの相談を最初に受け付ける窓口（本社の情シスチームの担当者）を明確にし、拠点側の心理的なハードルを下げる
2. 対応品質を定期的に確認する: 統合後、拠点からの評判や対応スピードに問題が生じていないか、定期的にヒアリングする
3. ベンダー台帳を更新し続ける: 統合後の契約状況を台帳に反映し、新たな個別契約が発生していないかを継続的にチェックする

拠点担当制を敷いているチームであれば、統合後も拠点ごとの窓口担当を維持し、その担当者が拠点からの声を吸い上げる役割を継続することで、統合によるコミュニケーションの断絶を防ぎやすくなります。

新規拠点・新規部署でベンダー分散を再発させないために

統合作業が一段落した後も、会社が拡大を続ける限り、新しい拠点や部署が生まれるたびに、同じ経緯で新たなベンダー分散が再発するリスクは常に存在します。この再発を防ぐためには、新規拠点・新規部署を立ち上げる際のルールを、あらかじめ整備しておくことが有効です。

• 新規拠点立ち上げ時の情シス関与を必須化する: 拠点の開設が決まった段階で、情シスチームが早期に関与し、既存の統合済みベンダーをまず検討する流れを作る
• 拠点責任者への周知: 拠点責任者が独自にベンダーを選定する前に、本社の情シスへ相談するルールを、拠点責任者向けのオンボーディング資料に明記する
• 定期的な新規契約の確認: 半年に1回程度、新たに発生したベンダー契約がないかをベンダー台帳と照合し、抜け漏れを確認する
• 拠点責任者向けの簡易チェックリストを用意する: ベンダー選定前に確認すべき最低限のポイントを、拠点責任者が自分で参照できる形で共有しておく

新規拠点の立ち上げは、多くの場合、事業のスピード感が優先される局面でもあります。情シスの関与が「スピードを遅らせる障害」と受け止められないよう、迅速に相談・判断できる窓口とプロセスを用意しておくことが、ルールの実効性を左右します。目安として、新規拠点からの相談には1〜2営業日以内に一次回答を返すといった具体的な対応目標をチーム内で定めておくと、拠点側の安心感にもつながり、ルールの形骸化を防ぎやすくなります。

まとめ: マルチベンダー化は「把握」してから「判断」する

拠点・部署ごとに異なるベンダーを使っている状態は、それ自体が問題なのではなく、その状態を情シスチームが把握できているかどうかが問題の本質です。自然発生的に生まれた分散状態を放置すれば、契約管理コストの増大やセキュリティポリシーの不統一といったリスクが積み重なっていきますが、だからといってすべてを機械的に統合すればよいわけでもありません。

拠点担当制を活用してベンダー台帳を整備し、技術領域の重複・契約コスト・対応品質・統合の実現可能性という4つの基準で統合可否を判断する。統合パターンは完全統合型だけでなく、技術領域別・地域ブロック別・重要度別といった中間的な選択肢も検討する。そして統合を進める際も見送る際も、拠点固有の知見や関係性を大切にしながら、チームとしての合意形成を丁寧に積み重ねていく。この一連のプロセスを通じて、マルチベンダー状態を「意図せず生まれた混乱」から「チームが把握し、選び取った体制」へと転換していってください。

ひとり情シスの時代には、こうした拠点横断のベンダー整理は、着手すること自体が現実的ではありませんでした。1人の担当者が本社の業務をこなしながら、全拠点のヒアリングと調整を行うには、時間的にも物理的にも限界があったためです。複数人体制へと移行した今だからこそ、拠点担当制という形でチームの力を分散させながら、これまで手つかずだったマルチベンダー状態に本格的に向き合うことができます。この機会を活かし、拠点・部署ごとに散らばったベンダーとの関係を、行き当たりばったりの状態から、チームとして意図を持って設計された状態へと、着実に整えていってください。