B BROCENT

5社のベンダー、1枚の請求書:香港企業のIT統合ストーリー

香港の士業系企業を舞台にした複合シナリオ。IT予算を精査するオフィスマネージャーが、互いに連携しないウイルス対策・バックアップ・チケット管理・リモートアクセスの5枚の請求書を発見——うち2つは誰も使っていないライセンス料でした。1つの連携プラットフォームへの統合が実際に何を見つけ、何を解決するのか。

オフィスのテーブルを囲み、書類や資料を一緒に確認する同僚たち。香港の士業系企業が分散したITベンダーの請求書を精査している様子を象徴する情景
要点: 香港のある士業系企業がIT予算を精査したところ、互いに連携していない5社分の請求書が出てきました——ウイルス対策、クラウドバックアップ、チケット管理ツール、リモートアクセスツール、そして実際のヘルプデスク契約です。しかもそのうち2つは、誰も使っていないライセンスに料金を払い続けていました。1つの連携プラットフォームに統合する意味は、請求額を小さくすることではありません。バラバラのツールの寄せ集めでは構造的に見えない問題があるということです。

なぜ香港の士業系企業は5社ものITベンダーを抱えることになるのか

最初から5社体制のITスタックを組もうとする企業はありません。それは一つひとつの判断が積み重なった結果であり、どの判断も単独で見れば理にかなっています。

法律事務所、会計事務所、コンサルティング会社など、従業員50〜100人規模の企業に、5年先を見据えたアーキテクチャ計画を立てるIT部門があることはまれです。実際には、オフィスマネージャーや運営責任者が、目の前の問題を一つずつ片付けているのが実情です。ウイルス対策ソフトの契約が切れたので、誰かがウイルス対策ソフトを買う。ランサムウェアのニュースを見て不安になり、クラウドバックアップに加入する。以前はみんなが半ば無視していた共有受信箱でIT依頼を記録していたが、あるパートナーの甥が勧めたチケット管理ツールに切り替える。ハイブリッドワークが始まってリモートサポートが必要になり、誰かが画面共有ツールに登録する。そしてその過程のどこかで、システムを維持するための実際のITサポートベンダーが別途契約され、他のすべてとは別に請求される。

それぞれの購入は、単体で見れば理にかなっています。誰も座って「うちの会社は5社の互いに連携しないシステムで運用しよう」と決めたわけではありません。オフィスに家具が少しずつ溜まっていくのと同じように、自然にそうなっただけです——ここに椅子が一脚、あそこにファイルキャビネットが一台と増えていき、気がつけば何一つ揃っておらず、あの良い椅子を誰が買ったのかも誰も覚えていない、というわけです。

これは香港の士業セクターに特有のパターンです。なぜなら、こうした企業はITを、本業以外のものを買うのと同じやり方で調達するからです——場当たり的に、その時手の空いている人が、その週に電話に出たベンダーから買う。それは法律事務所を経営する上では合理的なやり方かもしれません。しかしITを管理する上では、合理的ではありません。

シナリオ:5枚の請求書、統一された真実の情報源がない

以下は、同規模・同業種の企業で繰り返し目にしてきたパターンから作成した複合的なシナリオです——特定の実在顧客ではありません。

香港の従業員70人規模の法律事務所。専任の運営担当ポストがないため、2人のパートナーが運営業務を分担しています。四半期ごとに、技術予算を精査するために座って確認します。今回、洗い出されたのは5つの独立した支出項目でした。ウイルス対策ソフトは、あるリセラーを通じて毎年更新されています。クラウドバックアップは、2社目のベンダーを通じて容量に応じて毎月請求されており、いつ同意した更新日なのか誰も覚えていません。ITリクエストを記録するチケット管理ツールは、3社目の会社に毎月わずかなSaaS料金を払っていますが、使い方は一貫しておらず、一部のスタッフは直接メールでリクエストを送っています。何かが壊れたときにITサポートベンダーが端末にリモート接続できるようにするリモートアクセスツールは、4社目のベンダーからシート単位で個別にライセンスされています。そして実際に問題を解決する人たち——修理を担当するITサポート契約——が5つ目の項目で、時間単位またはリテイナー契約で請求されます。

5枚の請求書。5つのサポート電話番号。5つのログインポータル。どれも互いにデータを共有していません。オフィスマネージャーが「実際に自社の端末に何がインストールされていて、使っていないものに料金を払っていないか」というシンプルな質問に答えようとしても、確認できる単一の場所がありません。4つの異なるベンダーコンソールにそれぞれログインし、2人分の採用サイクル前から正しく更新されていないスプレッドシートと手作業で突き合わせる必要があります。

この5つのツールは、単体で見れば選定が悪かったわけではありません。ウイルス対策ソフトは定評のある製品です。バックアップベンダーの評判もしっかりしています。問題はどの一つの製品の品質にもありません。問題は、この企業が単発の点在ソリューションの寄せ集めを買ってしまったことにあります——それぞれが一つの仕事は非常にうまくこなしますが、互いの存在をまったく認識していないのです。

連携しない5つのツールが、この規模の企業に実際にもたらすコスト

このパターンのコストは、ある日突然劇的に現れるものではありません。摩擦、無駄、死角として現れます——重要になる瞬間まで誰も気づかない類のものです。

全体像を把握している人が誰もいない。 オフィスマネージャー、パートナー、ITサポートベンダーに「今のうちの完全なIT環境はどうなっているか」と聞いても、それぞれが自分の持ち場からしか答えられません。サポートベンダーはどのチケットをクローズしたかを知っています。バックアップベンダーは何をバックアップしているかを知っていますが、それが実際にデプロイされているものと一致しているかは知りません。誰も全体地図を持っていません。そもそもその地図を保持するように設計されたシステムが一つもないからです。

何かが起きたとき、最初のステップは修理ではなく、電話をかける相手を探すことになる。 何かが壊れたとき——ノートPCが侵害された、バックアップが静かに止まっていた、退職した従業員のアクセス権が取り消されていなかった——最初のステップは診断ではありません。まず、これが5社のうちどのベンダーの問題かを突き止め、電話をかけ、それが本当に自社の問題であって他社の問題ではないことを確認してもらうのを待つことです。エンドポイントとバックアップシステムの両方に影響するセキュリティインシデントは、互いに一度も話したことがなく、何が起きたかを共有する記録もない2つの別々の会社に、それぞれ別々に電話をかけることを意味します。

ライセンスの無駄は目の前にあるのに誰も気づかない。 これは最も気づかれにくく、金額としてはしばしば最大のコストです。数ヶ月前に退職した従業員のために購入されたソフトウェアライセンス料が払われ続けている。すでに終了したプロジェクトのために確保されたシートがそのまま残っている。バックアップの容量プランは、以前のデータ量に合わせて設定されたまま、事業が拡大しても縮小しても、誰も調整していない。5社のベンダーの誰にも、これを指摘するインセンティブがありません——各社のコンソールには自社の製品しか表示されず、誰も使っていないライセンスもシステム上は「有効」のままで、毎月課金され続けます。この無駄を見つけるには、互いに連携しない5つのシステムを誰かが手作業で監査する必要がありますが、実際にはそれを行う人はいません。

カバレッジの欠落は、それが露呈する事故の瞬間まで見えてこない。 端末が交換されても、古いリモートアクセスエージェントが削除されないことがあります——それは倉庫に保管されているマシン上でまだ動作しており、依然として有効な侵入経路のままですが、「どの端末に実際に何がインストールされているか」を追跡する単一のシステムがないため、どの在庫システムもこれを捕捉できません。ある新入社員のノートPCは、初日に誰かが手動で設定を覚えていたためにバックアップが適用されています。別の新入社員のPCはそうなっていません。誰もそれを覚えていなかったからです。これはどこか一社のベンダーの仕事が悪かったからではなく、各要素をつなぐものが何もないことの必然的な結果です。

更新条件と価格がそれぞれ別々に変動していく。 5つの契約はそれぞれ異なる更新サイクルを持ち、その年たまたまそのベンダーを担当していた人が、それぞれ異なる時点で交渉したものです。つまり、この企業がITに実際いくら使っているかを統合的に把握している人は誰もおらず、まとめて交渉するための交渉力もありません。

私たちの見解:1つのプラットフォームにする理由は、請求額を小さくすることではない

企業がこの問題を私たちに持ち込むとき、彼らが本能的に期待している売り文句は「統合すればコストが下がる」というものです。実際にはそれが最も強い論拠ではなく、私たちはそれを前面に出しません。なぜなら常に成り立つとは限らないからです——単一ベンダーのバンドル価格が、それが置き換える点在ソリューションの合計とほぼ同じ水準に落ち着くこともあり、コスト削減だけを前面に押し出す統合の売り込みに懐疑的であるのは、企業として当然のことです。

本当の論拠は構造的なものです。連携したツールは、個々のツールがどれだけ優れているかとは関係なく、孤立したツールでは設計上見えないものを捉えることができる、ということです。

ウイルス対策製品は、どれほど優れていても、エンドポイント上の脅威しか知りません。バックアップ製品は、バックアップジョブのことしか知りません。どちらも、セキュリティアラートを出しているそのノートPCが、先週バックアップが静かに失敗していたのと同じ端末であることを教えてはくれません。なぜなら、それらは互いに情報を突き合わせるようには作られていない、異なる会社の、共有データモデルを持たない別々の製品だからです。これは、それぞれのツールをより良いバージョンに買い替えれば解決する問題ではありません。連携しないシステムを運用することの構造的な限界であり、どのベンダーの製品がどれだけ優れていても、この限界は消えません。

これはBrocentが自社のマネージドITプラットフォームについて主張しているのと同じ論拠です。導入時にバラバラのサードパーティ製品を寄せ集めたものではなく、Brocentが自社で構築し、エンドツーエンドで運用する単一のエンジン上で稼働しており、各モジュールはそのように設計されているためデータを共有します。これが何を生み出すかを示す具体例が2つあります。当社のセキュリティ監査モジュール内のライセンスガバナンス機能は、購入・支払い済みでありながら、どの端末でも実際には使われていないソフトウェアシートを検出できます——インストール済みソフトウェアを追跡する同じプラットフォームが、ライセンス権利も追跡しており、両者を突き合わせることができるからです。資産ライフサイクル追跡は、ハードウェアとソフトウェアの更新判断が、誰かが昔設定して忘れてしまったカレンダーのリマインダーではなく、端末の実際の経年と状態に基づいて行われることを意味します——これは、まだ問題のない機器を早期に交換してしまうことと、本来退役すべきものを誤って更新してしまうことの両方を防ぎます。

これらのどちらも、単体の点在ソリューションの内部では、どれほど作り込んでも実現できません。2つの異なる機能が、同時に同じデータを見られる必要があります。これが「単一プラットフォーム」の本当の論拠です——紙の上で安いからではなく、それぞれ別々に購入されたツールの寄せ集めには構造的にできないことを、最初からそのために作られているからこそ実行できる、という点にあります。

統合監査が実際に見つけるもの

これを抽象論ではなく具体的なものにするために、このような監査が、この規模の企業を分散したツールから単一プラットフォームへ移行させる際に典型的に発見する内容を紹介します——これも複合的な事例であり、特定顧客の実数字ではありません。

ライセンスガバナンスによって発見される未使用のソフトウェアシート。 先ほどの従業員70人規模の企業の例に戻ります。付与されたライセンスと端末の実際の稼働状況を照合すると、数ヶ月前に退職した従業員に対して、あるいはひっそりと終了したパイロットプロジェクトに対して、依然として料金が支払われ続けているシートが——企業が予想していたより多く——見つかります。誰もそれを削除しなかったのは、未使用のライセンスを削除するにはまずそれが未使用であることに誰かが気づく必要があり、気づくには、そもそも突き合わせるように設計されていない2つのシステムを相互参照する必要があるからです。連携したプラットフォームでは、新規顧客のオンボーディング時にこれを検出するのと同じライセンスガバナンスチェックが、その後も継続的に稼働し続けるため、この無駄が半年後にひっそりと再発することはありません。

廃止された端末に残ったままの古いリモートアクセスツール。 これはコストの問題であると同時に、セキュリティ上の問題でもあります。端末は通常の業務の中で交換されます——ノートPCが故障した、誰かがアップグレードした、機器が転用された、といった具合です。この過程で、ベンダーがサポートのために接続していた古いリモートアクセスソフトウェアが必ずしも削除されるわけではありません。それをアンインストールすることが誰の明確な仕事でもないからです。有効な認証情報とアクティブなリモートアクセスエージェントを備えた端末が倉庫の棚に置かれたままであれば、それは依然として侵入経路です。すべての端末とすべてのインストール済みツールを突き合わせる資産管理ビューは、まさにそのために設計されているため、この種のギャップを捕捉できます。それぞれ自分の担当範囲しか見えない5つの独立したコンソールには、構造的にこれができません。

すべてが一箇所に集約されて初めて見えてくるバックアップのカバレッジ欠落。 ツールが分散しているバージョンでは、バックアップのカバレッジは各端末を設定した人がその都度どう設定したかに完全に依存します。エンドポイントの在庫とバックアップの状態が同じプラットフォームに集約されると、これまで見えていなかったギャップ——バックアップジョブがまったく設定されていないノートPC、誰もそのベンダー独自のアラートコンソールを見ていなかったために何週間も静かに失敗し続けていたバックアップジョブ——が、リストアがうまくいかなかったときに初めて発覚する驚きではなく、一覧として可視化されます。

これらの発見に特別なツールは必要ありません。必要なのは、各比較の両側——インストール済みソフトウェアとライセンス権利、端末とバックアップジョブ、エンドポイントとリモートアクセス権限——を同一のプラットフォームが同時に保持していることだけです。それこそが、それぞれ別々に購入された点在ソリューションの寄せ集めには構造的にできないことなのです。

場当たり的な寄せ集め vs バンドル販売の販売代理店 vs 一つの連携エンジン

統合を検討する企業は、選択肢が「現状維持」か「バンドルパッケージを買う」の2つしかないと考えがちです。実際には意味のある第三の選択肢があり、2番目と3番目の違いは、請求書そのものを超えて見て初めてわかります。

3つのモデルの比較

  • 点在ソリューションの寄せ集め(「それぞれの仕事に最適なツールを、個別に管理する」) —— 個々のツールはそれぞれ確かに優れた製品かもしれません。しかし、それらをつなぐものは何もありません。ライセンスデータは一つのコンソールに、端末の在庫は別のコンソールに、バックアップの状態は三つ目のコンソールにあり、すべてを横断する単一のビューを持つ人は誰もいません。無駄とギャップは、インシデントや監査によって誰かが5つのシステムを手作業で突き合わせざるを得なくなるまで、見えないままです。
  • バンドル販売の販売代理店(請求書は一つ、バックエンドは依然として非連携) —— 一部のベンダーは、あなたの請求を一つの月次明細書にまとめる一方で、同じ別々の基盤製品をそのまま転売し続けます。それぞれが独自のバックエンドで、独自のデータモデルのまま稼働しています。これは「5つの電話番号」問題だけを解決し、それ以外は何も解決しません。ライセンスガバナンスチェックは依然としてバックアップシステムを見ることができません。一つにまとめられた請求書の裏側で、ツール同士が情報をやり取りする方法自体は実質的に何も変わっていないからです——つまり、依然として連携していないということです。
  • 一つの連携エンジン(当社が自社のマネージドITプラットフォームを構築する際に目指す姿) —— 資産在庫、ライセンス権利、バックアップの状態、チケット管理、リモートアクセス権限が、異なる会社の別々の製品ではなく、同一システム内の各モジュールとなっている単一のプラットフォームです。5つではなく1つの監査証跡。「インストール済み」と「ライセンス済み」が実際に一致しているかを本当に確認できるライセンスガバナンスチェック。両方の事実が同じ場所にあるからこそ可能になります。インシデント対応も、電話をたらい回しにするのではなく一本の電話で済みます。対応するエンジニアがすでに全体像を把握しており、他の4社のベンダーからそれぞれ情報を集める必要がないからです。

率直に言うべき留保点があります。5社体制から1つのプラットフォームへの切り替えは、スイッチを切り替えるような単純な話ではなく、実際のプロジェクトです。既存の契約は期間満了まで運用するか、正式に移行する必要があり、スタッフは新しいサポート窓口に慣れる必要があります。現在の点在ソリューションのベンダーと本当に良好な関係を築いている企業であれば、その点を上記の構造的な論拠と天秤にかけて検討する権利があります。統合の論拠が最も強くなるのは、企業がすでに上記の問題の少なくとも一つを指摘できる場合です——誰も説明できないライセンス、診断に3回の電話を要したインシデント、痛い目を見て初めて発覚したバックアップのギャップなどです。

これがマネージドITとの関係の中でどこに位置づけられるか

これは単体で購入する製品ではなく、IT関係全体の運用のあり方そのものです。マネージドITサポートの中に、別のスタック上に後付けされたアドオンモジュールとしてではなく、基盤プラットフォームとして組み込まれています。そのエンドポイント側——ライセンスガバナンスや資産追跡機能に端末レベルのデータを提供する、リモートサポートとセキュリティ監査を行うエージェント——がBCS Beamです。個別に販売されるのではなく、Brocentのマネージドプランに含まれています。企業の端末の一部しか見えないプラットフォームでは、そのどの端末についても完全な全体像を出すことはできないからです。

「完全な外部委託」と「自社内でIT体制を維持する」という両極の間に位置する企業に対しても、同じ連携プラットフォームのロジックを、既存の社内チームを置き換えるのではなく協働する形のマネージドサービスを通じて利用できます。いずれの形であっても、この構造的な優位性——ライセンス権利と実際の使用状況、端末とバックアップのカバレッジ、エンドポイントとリモートアクセス権限を突き合わせられる単一のシステム——は、プラットフォームそのものから生まれるものであり、その上に重ねられたサポートモデルから生まれるものではありません。

Brocentは2007年からアジアで事業を展開しており、2021年からシンガポールに本社を置き、2016年から香港オフィスを構えています。従業員50〜100人規模の法律事務所、会計事務所、コンサルティング会社といった士業系企業は、当社が日常的に取引しているセグメントであり、それこそが「一つずつツールを買い足していった結果、誰も全体を見渡せなくなる」というこの特定のパターンを、新規顧客ごとにゼロから発見し直すのではなく、すぐに見分けられる理由の一つです。各市場向けのプランと各ティアに含まれる内容は、料金ページに記載しています。

よくある質問

すべてを一つのベンダーにまとめると、単一障害点のリスクがかえって大きくならないか?

もっともな直感ですが、これは2つの異なるものを混同しています。ベンダーの集中とシステムの集中です。一つの連携プラットフォームに統合することは、確かにサポート関係を一社に集中させます。しかし、それが技術的な単一障害点を意味するわけではありません——5社の別々のベンダーだった場合よりもむしろリスクは低くなり得ます。連携プラットフォームは冗長性を組み込んで設計し、一つの整合したシステムとして監視できるのに対し、5つの独立した点在ソリューションはそれぞれが独自の障害リスクを抱えており、その継ぎ目を誰も監視していないからです。統合を提案するベンダーに問うべき質問は「あなたが停止したらどうなるのか」ではなく、「あなたの冗長性設計はどうなっているか、うまくいかなかった場合の当社の退出経路は何か」です——これは、現在何社のベンダーを使っているかにかかわらず、問う価値のある質問です。

移行期間中、既存のツール契約はどうなるのか?

これは各契約が現在どの契約期間にあるかによります。ほとんどの統合は段階的に進められます。新しいツールを既存のツールと並行して稼働させ、データと設定を移行し、新しいプラットフォームが正常に動作していることを確認してから、旧契約を満了させるか正式に解約します。ある週末に一気に切り替えるようなことはしません。適切なマネージドITパートナーであれば、あなたの既存契約の満了日を移行計画と事前に突き合わせ、重複するカバレッジに6ヶ月分余分に支払うようなことがないようにし、計画もないまま契約期間の途中で契約を放棄するよう求めることもありません。

このような統合には実際どのくらいの期間がかかるのか?

企業の規模や既存スタックがどれだけ複雑にもつれているかによって変わりますが、従業員50〜100人規模の企業であれば、中核となる移行——エンドポイントエージェントの展開、バックアップの移行、チケット管理とリモートアクセスの切り替え——は通常、まず現状把握と整理のフェーズを経た上で、数ヶ月ではなく数週間で完了します。未使用ライセンスやカバレッジの欠落を洗い出す監査(上記で説明したような発見事項)は通常早い段階、多くの場合オンボーディングの最初の数週間以内に行われます。今後プラットフォームを長期的に運用するのと同じツールが、その最初の監査を実行するからです。

現在5社のベンダーに支払っている合計額より高くなるのか?

高くなることもあれば、そうでないこともあります——実際には置き換える具体的なツールと、企業が現在どれだけ使われていないライセンスに無駄な支払いをしているかによります。これは監査自体が明らかにすることが多いです。私たちは「請求書の数字が小さくなる」ことを行う理由として約束することはしません。その約束が常に成り立つとは限らず、それを前面に押し出すベンダーを企業が疑うのはもっともなことだからです。より強い論拠は、5つの独立したツールでは構造的にできないことを、この連携プラットフォームが見て、実行できるという点にあります——ライセンスの無駄、カバレッジの欠落、一本の電話で済むインシデント対応です。合計額が以前支払っていた額と比べてどうであるかにかかわらず、です。

気に入っているツールを一つだけ残すことはできるか?

場合によっては可能ですが、それは統合の中核的な論拠——価値はツール同士がデータを共有することから生まれるのであり、単に発注先の会社数を減らすことから生まれるのではない、という点——に反する行為です。連携プラットフォームの外に単独で残されたツールは、その一つの部分について、統合がまさに解決しようとしていた死角をそのまま再発させます——他のすべてと同じライセンスガバナンスチェックや資産在庫ビューには表示されません。企業がそのツールを残す十分な理由を持っているなら、それは合理的なトレードオフですが、その部分が統合されたビューの外側に残ることを全員が理解している必要があります。

「単一の監査証跡」とは実務上どういう意味か?

それは、互いに参照し合わない別々のベンダーログに分散していたはずの情報が、一つの記録にまとまるという意味です。具体的には、どの端末が存在し、それぞれに何がインストールされていて、バックアップが最新かどうか、誰がリモートアクセス権を持ちどのように使われたか、どのライセンスが付与されていてどれが実際にアクティブか、をすべて示す一箇所があるということです。監査やインシデントで全体像が必要になるたびに、企業自身が手作業で突き合わせて組み立てなければならない、5つの独立したコンソールからの5つの別々の答えではありません。

もし貴社が現在、帳簿上で2〜3社を超えるITベンダーを挙げることができ、支払っているライセンスが実際に使われているかどうか確信が持てないのであれば、それは行動を起こすべきサインであることが多いです。お問い合わせいただければ、現在のツールスタックを監査した場合に何が見つかりそうか、当社と統合するかどうかにかかわらず一緒に確認します。

共有:

今すぐ行動を

インサイトをビジネスのITロードマップへ。

APACのITエキスパートと15分間の無料相談をご予約ください。現在の環境を確認し、24時間以内にカスタマイズされたITロードマップを提供します。

📋

無料チェックリスト

中国大陸へのIT展開前に確認すべき10の重要事項

PIPL準拠、ネットワーク分割、バイリンガルヘルプデスクの設定など、中国での初日に必要なすべてのIT準備。

チェックリストを申請 →

📬 アジアIT月報

中国コンプライアンス情報、サイバーセキュリティ警報、APACチーム向けITのヒントを毎月お届けします。

スパムなし。いつでも配信停止できます。