ベンダーロックインとは？先代の代から陥りがちな典型パターン

先代が30年前に契約したシステム会社から、今も毎月同じ金額の保守料が引かれている。何をしてもらっているのか正直よくわからないが、止めたら何が起きるかもわからないので、そのまま契約を更新し続けている。そんな会社を継いだ経営者は、実は少なくない。

株式の承継には税理士がいる。登記の変更には司法書士がいる。しかし、先代の代から使っているシステムやソフトウェアの契約については、相談できる専門家が身近にいないことが多い。契約書を読んでも技術的な条件がわからず、担当者に聞いても「今のままで問題ないですよ」と言われて終わる。この記事では、その「今のままで問題ないですよ」の裏にあるベンダーロックインという状態を、承継後の経営者が実務でどう見極め、どう向き合えばいいかを整理する。

結論を先に言うと、ベンダーロックインそのものは「悪」ではない。しかし、承継のタイミングでその状態に気づかずに放置すると、選択肢のないまま高いコストを払い続ける構造が固定化される。まずは自社がどの程度ロックインされているかを把握し、そのうえで「このまま付き合う」「条件を見直す」「乗り換える」のどれを選ぶかを、自分の意思で決められる状態に持っていくことが第一歩になる。

この記事はこんな状態の人向けに書いている

• 先代の代から同じシステム会社・ソフトウェア会社と契約しているが、契約内容や仕組みを自分では説明できない
• 「うちのデータ、他社に移せるんですか」と聞いたら、はっきりした返事がもらえなかった
• 保守料や利用料が毎年少しずつ上がっているが、見直す機会がないまま今に至っている
• 古参の社員が「昔からこの会社にお願いしている」ことを理由に、ベンダー変更に消極的
• 株や登記の承継は専門家に相談できたのに、システムの承継については誰に聞けばいいかわからなかった

一つでも当てはまるなら、この記事は読む価値がある。

ベンダーロックインとは何か

ベンダーロックインとは、特定のベンダー（システム会社・ソフトウェア会社）が提供する製品やサービスに業務が深く依存してしまい、他社への切り替えが技術的・経済的・心理的に困難になっている状態を指す。英語の "vendor lock-in" をそのまま訳したもので、IT業界では古くから使われている概念だ。

技術的な観点で言えば、データ形式が独自仕様である、システムが他のソフトウェアと連携できない構造になっている、仕様書やソースコードが手元にないためベンダー以外の誰も保守できない、といった状態が典型だ。経済的な観点では、乗り換えにかかる初期費用・データ移行費用・従業員の再教育コストが、現状維持のコストを上回ってしまい、結果として「わかっていても動けない」状況に陥る。

重要なのは、ベンダーロックインは意図的な「悪徳ベンダー」だけが作り出すものではないという点だ。むしろ多くの場合、長年の信頼関係の中で自然に積み重なっていく。担当者と顔なじみになり、細かい要望を電話一本で聞いてもらえる関係は、承継以前の経営においては合理的な選択だったはずだ。問題は、その関係性の裏側で「他に選べる相手がいない」状態が静かに固定化していたことに、承継の代になって初めて気づくというタイムラグにある。

公正取引委員会が2022年に公表した「官公庁における情報システム調達に関する実態調査報告書」では、発注者側が長期にわたり特定のベンダーに依存し、自力では抜け出せない状態にある実態が指摘されている。同報告書は、情報システムの疎結合化やオープンな仕様設計、組織・人員体制の整備が、ロックインを防ぐ観点から重要だとしている。

これは官公庁を対象にした調査だが、指摘されている構造は中小企業にもそのまま当てはまる。「発注側にも原因がある」という視点は、承継した経営者が自社の状況を振り返るうえでも参考になる。

なぜ先代の代からロックインが生まれやすいのか

承継企業でベンダーロックインが起きやすい背景には、いくつかの構造的な理由がある。順に見ていく。

理由1：システム導入の目的が「業務を止めないこと」だった

先代がシステムを導入した当時の最優先事項は、多くの場合「今の業務を止めずに回すこと」だった。将来の乗り換えやすさ、データの標準化といった観点は、二の次、あるいはまったく検討されていなかった可能性が高い。当時は「乗り換えやすさ」を評価軸にする発想自体が一般的ではなかった時代でもある。

理由2：契約更新が「自動で続く」設計になっている

多くの保守契約・利用契約は、自動更新条項がついている。担当者が変わらない限り、誰も内容を見直さないまま契約は更新され続ける。承継後の経営者が契約書を初めて読んでみて、更新条項や解約条件の存在に気づくケースは非常に多い。

理由3：属人化した「先代とベンダー担当者の関係」

先代とベンダー側の担当者が長年の付き合いで、業務外のことまで含めて信頼関係を築いていることがある。この関係性自体は資産だが、契約内容やシステムの技術的な実態が「口約束」や「暗黙の了解」の中に隠れてしまい、承継後の経営者には見えなくなっているケースが少なくない。

理由4：古参社員がベンダーとの関係を「変えたくない」と感じている

現場の古参社員にとって、慣れたシステムと慣れた担当者は仕事のしやすさそのものだ。後継者が「ベンダーを見直したい」と言うと、システムの話のはずが「先代を否定するのか」という感情的な反応に変わることがある。これは技術の問題ではなく、社内の心理的な力学の問題であり、承継後の経営者が最も扱いに慎重さを求められる場面の一つだ。

理由5：技術的な実態を確認する手段がなかった

株式や登記であれば、専門家に頼めば内容を正確に把握できる。しかしシステムの技術的な実態——データがどの形式で保存されているか、どのソフトウェアに依存しているか、ソースコードや仕様書が存在するか——を確認できる専門家に、承継の場面で相談する機会がほとんど用意されていない。これが「株や登記には専門家がいるが、システムには相談先がいない」という孤独感の正体だ。

ロックインの典型パターンを3つに分けて見る

承継企業で実際に見られるロックインのパターンは、おおむね3つに分類できる。

これらは重なって発生することが多い。たとえば「保守独占型」と「関係依存型」が同時に起きている会社では、契約書上は普通の業務委託契約に見えても、実質的には「その担当者がいなければ何も動かせない」状態になっている。

データ閉じ込め型の見分け方

自社の基幹システムやSaaSから、データをCSVやExcelなど汎用形式でエクスポートできるかどうかを確認してみるとよい。エクスポート機能自体がない、あるいは一部の項目しか出力できない場合は、データ閉じ込め型の可能性が高い。この観点はデータポータビリティ（データポータビリティ）という概念で整理されることが多く、乗り換えの可否を判断する最初の分岐点になる。具体的な確認手順はデータをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきことで解説している。

保守独占型の見分け方

「このシステムの仕様書はありますか」「ソースコードは弊社に開示されますか」と一度聞いてみるとよい。即答で「もちろんあります」と返ってくる会社もあれば、話をそらされる、あるいは「弊社の資産なので開示できません」と言われる会社もある。後者であれば、保守独占型のリスクを抱えていると考えて間違いない。

関係依存型の見分け方

「その担当者が急に辞めたら、うちの業務はどうなるか」を社内で一度シミュレーションしてみる。答えが誰からも出てこない、あるいは「〇〇さんに聞いてみないとわからない」という返事しか出てこないなら、関係依存型が強く効いている状態だ。

経済産業省が示す「レガシーシステム」問題との関係

ベンダーロックインは、経済産業省が2018年に公表した「DXレポート」で提起した「2025年の崖」問題とも深く関係している。同レポートは、老朽化・複雑化・ブラックボックス化した既存システム（レガシーシステム）が企業の経営やDX推進の足かせになっていると指摘し、対応が進まなければ2025年以降、年間で最大12兆円の経済損失が生じる可能性があると警告した。

さらに2025年5月にIPA（情報処理推進機構）が公表した「レガシーシステムモダン化委員会総括レポート」では、2025年の崖として警告された時期に入りながらも、多くの企業でDXやレガシーシステムの脱却に向けた動きが十分な機運を持って進んでいない実態が確認されている。既存のレガシーシステムが、生成AIなど最新のデジタル技術の統合・活用を妨げる要因になっているという指摘もある。

つまり、ベンダーロックインは一部の会社だけの特殊な問題ではなく、日本の中小企業全体が抱える構造的な課題の一部だということだ。承継した経営者が「うちだけの問題ではないか」と気にしすぎる必要はない一方で、「全体の問題だから仕方ない」と放置してよい理由にもならない。この重なりを理解しておくと、社内で説明するときの説得力が増す。

レガシーシステムという言葉自体は「古いシステム」を指す中立的な用語だが、ロックインと組み合わさると厄介さが増す。古くなったシステムを変えたくても、データや仕様がそのベンダーの独自仕様でしか動かないために、身動きが取れないという状態が生まれるからだ。

「今すぐ乗り換えろ」ではない、というのが本当のところ

ここまで読んで「今すぐベンダーを変えるべきだ」と結論づけるのは早計だ。ベンダーロックインへの向き合い方は、実際には3段階に分けて考えるべきものだ。

1. まず現状を正確に把握する（乗り換える・変えないに関わらず必須）
2. その状態のリスクとコストを見積もる
3. そのうえで「維持する」「条件を見直す」「乗り換える」を選ぶ

いきなり3の「乗り換える」に飛びつくと、移行コストや業務停止リスクを見誤ることがある。逆に、現状把握を怠ってそのまま何もしないと、いつの間にか値上げや障害対応の遅さといった形でコストが表面化する。承継後の最初の1〜2年でやるべきは、あくまで1と2であることが多い。

現状把握のための実務チェックリスト

以下は、承継後に自社のロックイン状況を確認するための実務チェックリストだ。専門知識がなくても、担当者やベンダーへの質問として使える形にしてある。

• 契約書に自動更新条項があるか、解約するには何ヶ月前の通知が必要か
• データをCSV・Excelなど汎用形式でエクスポートできるか（できない項目はあるか）
• システムの仕様書・設計書が自社で保管されているか、ベンダーの手元にしかないか
• ソースコードの著作権・利用権が自社にあるか、ベンダーに帰属しているか
• 保守料・利用料の過去5年の変動履歴を把握しているか
• 障害対応や問い合わせに対するベンダーの対応スピードに、社内から不満の声が出ていないか
• 担当者が退職・異動した場合の引き継ぎ体制がベンダー側に整っているか
• 同種のシステムを提供できる他のベンダーが、現実的に存在するか

これらの答えを一つずつ埋めていくだけで、自社がどのパターンのロックインに近いかが見えてくる。この作業は、単発の点検で終わらせず、契約名・ベンダー名・保守料・データ形式・仕様書の有無などを一覧の台帳にまとめておくと、承継後の定期的な棚卸しの土台になる。台帳という形にしておくメリットは、次の後継者や、経営者本人が忘れた頃にもう一度見直すときに、ゼロから調べ直す手間を省けることだ。口頭で聞いた内容や担当者の記憶に依存させず、書面として残しておくことが、次の承継の孤独感を減らすことにもつながる。この台帳づくりの具体的な進め方は、脱ロックインの第一歩、承継後に自社で管理すべきアカウント一覧で詳しく紹介している。

古参社員・先代への配慮をどう組み込むか

ロックインの見直しを進める際、最も気を使うべきは技術面ではなく人間関係の面だ。特に次の2点は避けたい。

先代を否定する言い方をしない。 「今のベンダーはダメだ」という言い方は、先代の判断そのものを否定するメッセージとして受け取られやすい。伝え方としては「当時は最適な選択だったが、状況が変わった」という時間軸を明示する言い方の方が、社内の反発を招きにくい。

古参社員を置き去りにした議論をしない。 ベンダーとの関係を最も肌感覚で理解しているのは、多くの場合、経営者本人よりも現場の古参社員だ。彼らを蚊帳の外にして経営判断だけで進めると、後になって「なぜ自分たちに相談がなかったのか」という不満が出やすい。現状把握のチェックリストを一緒に埋めてもらうところから始めると、心理的な抵抗が和らぐことが多い。

「先代の代から使っているシステムを見直す」という話を切り出すと、まず出てくる反応は技術的な指摘ではなく、「なぜ今のままでいけないのか」という感情的な問いであることが多い。技術の話をする前に、この問いに答える準備をしておくことが実務上は近道になる。

契約を見直すときに確認すべき3つの視点

現状把握が終わり、「維持する」「条件を見直す」「乗り換える」のいずれかを選ぶ段階に来たら、契約面では次の3つの視点を持つとよい。

視点1：解約・移行にかかる実費用を数字で出す

「なんとなく大変そう」という感覚ではなく、データ移行費用、新システムの導入費用、従業員の再教育にかかる時間、二重運用期間のコストを、概算でよいので数字に落とす。数字にすると、思っていたより小さいコストで済むケースと、想定以上に大きいコストがかかるケースの両方が見えてくる。

視点2：契約解除の条件と通知期間を確認する

自動更新条項がある契約では、「解約する場合は契約満了の何ヶ月前までに書面で通知」といった条件が定められていることが多い。この期間を過ぎると、望まなくてももう1年契約が続くことになる。承継後、最初にやるべき実務の一つは、このタイミングを逃さないようにカレンダーに登録することだ。

視点3：単一ベンダーに依存しない選択肢があるかを確認する

すべてを一社に任せる体制から、複数のベンダー・ツールを組み合わせる体制に移すことで、リスクを分散できる場合がある。この考え方はマルチベンダー（マルチベンダー）という概念で説明されることが多い。ただし、ベンダーを増やすこと自体が目的化すると、管理の手間が増えて逆に非効率になることもあるため、自社の規模と体制に合った範囲で検討することが大切だ。

たとえば、基幹の会計システムや生産管理システムは既存ベンダーに残しつつ、新しく必要になった領域（会社サイトのリニューアル、予約システムの導入、在庫管理の一部の効率化など）だけを別の会社に依頼する、という進め方がある。これは一気に全部を切り替えるよりもリスクが小さく、既存ベンダーとの関係を急に断ち切らずに済む現実的な移行方法になる。新しい領域での対応スピード・費用感・説明の分かりやすさを比較する材料にしてから、数年かけて本体の契約を見直すかどうかを判断する、という段階的な進め方が現場では機能しやすい。

古いシステムほど保守を頼める会社が減っていく構造

ベンダーロックインが強まっていく背景には、システムそのものの老朽化という構造的な要因もある。長年にわたり個別のカスタマイズを繰り返してきたシステムほど、内部構造が複雑になり、保守を担当できる技術者や会社が限られてくる。その結果、対応できる会社・担当者がその一社に固定化され、価格や条件についての交渉力そのものが弱まっていく。

• システムが古くなるほど、対応できる技術者・会社が減る
• 対応できる会社が減るほど、価格・条件の交渉力はベンダー側に偏る
• 交渉力が偏った状態が、そのまま何年も固定される
• 気づいたときには、他に頼める会社が見当たらない状態になっている

これは意図的な「なんとかホールドアップしよう」という悪意があって起きるわけではなく、システムが古くなるにつれて自然に生まれていく力関係の変化だ。実際に「今のベンダーとしか話ができない」「仕様書もソースコードも手元にない」という状態まで進んでしまっている場合は、そうした状態そのものを専門に引き受ける会社（システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー）に現状調査を相談する選択肢もある。リプレイス費用の内訳がなぜ高くなりがちなのかは、先代の代からの基幹システムのリプレイス費用はなぜ高い？内訳の読み方で解説している。この構造を理解しておくと、「なぜ今の会社にしか頼めないのか」という疑問への納得感が生まれる。同時に、この状態こそが最も早く手を打つべき対象でもある。放置すればするほど、選択肢は狭まっていく。

使用中のシステムやソフトウェアが、開発元によるサポートの終了時期を迎えていないか、あるいは近づいていないかを確認しておくことも重要だ。サポートが終了したシステムを使い続けている場合、ロックインの是非を議論する前に、そもそもセキュリティや動作保証の観点で継続利用そのものが難しくなっている可能性がある。この場合、検討すべきは条件の見直しではなく、移行計画そのものになる。サポート終了は「まだ動いているから大丈夫」という感覚では判断できない。動いていることと、安全に使い続けられることは別の問題であり、この見極めを怠ると、ロックインの解消どころか、より大きなトラブルを後から抱え込むことになる。

「乗り換えない」という選択も正当な経営判断

ここまでロックインのリスクを説明してきたが、現状把握と検討を経た結果、「今のベンダーのまま続ける」という結論に至ることも、まったく問題のない経営判断だ。

乗り換えない方が合理的なケースは、たとえば次のような場合だ。

• 移行コストが、現状維持コストを大きく上回ると数字で確認できた
• 現在のベンダーが、価格や対応スピードについて誠実に交渉に応じてくれている
• 業務への影響が小さく、システムの規模自体がそこまで大きくない
• 社内の体制上、当面は乗り換えに割けるリソースがない

重要なのは、「調べずに続けている」状態と、「調べたうえで続けると決めた」状態は、外から見れば同じでも意味がまったく違うという点だ。前者はロックインに気づかず放置している状態であり、後者は経営者が主体的に選んだ状態だ。この記事の目的は、後者に立てるようになることにある。割高に感じるSaaS契約をどう縮小・乗り換えるかの選択肢は、高くなった先代契約のSaaSを乗り換え・縮小する選択肢で整理している。

承継後1年で何をすべきか、優先順位で示す

最後に、承継直後の経営者が実際に何から手をつければいいかを、優先順位の形で示す。

1. すべての契約書を集める。 システム関連の契約は、経理や総務の引き出しに埋もれていることが多い。まず存在を確認するところから始める。
2. 上記チェックリストで現状を確認する。 難しい技術用語がわからなくても、担当者やベンダーに質問する形で進められる。
3. 契約更新・解約通知のタイミングをカレンダーに登録する。 ここを逃すと、望まない自動更新が発生する。
4. 古参社員に、ベンダーとの関係の歴史を聞く。 感情的な配慮の土台になる情報を、契約書からは読み取れない部分まで含めて把握する。
5. 必要であれば、外部の第三者（税理士・中小企業診断士・IT専門の相談窓口など）に契約書の技術的な条件を確認してもらう。 株や登記に専門家を頼ったのと同じ発想で、システムにも第三者の目を入れる。

この5つを、承継後1年以内に一通り終えることを目標にするとよい。すべてを一気に変える必要はない。まずは「知っている状態」を作ることが、孤独感を減らす最初の一歩になる。実際に刷新へ動き出す段階になったら、何から着手すべきかの優先順位のつけ方は最初の刷新、何から手をつけるか決めるための優先順位のつけ方も参考になる。

ロックインの見極めは、承継のたびに繰り返す作業になる

もう一つ知っておきたいのは、ベンダーロックインの見極めは一度やれば終わりという作業ではないということだ。今回、先代から現経営者への承継のタイミングでこの棚卸しを行ったとしても、次に経営者自身が誰かに事業を譲るとき、あるいは事業拡大で新しいシステムを導入するとき、また同じ確認が必要になる。

だからこそ、今回の棚卸しの結果は、口頭の記憶ではなく書面や表の形で残しておくことに意味がある。今の経営者が「知っている状態」を作ったとしても、それを次の世代に引き継がなければ、また同じ孤独感がそのまま繰り返されてしまう。株式や登記の記録が代々きちんと引き継がれていくのと同じように、システムの契約状況や技術的な実態についても、承継のたびに更新される記録として残していく発想を持つとよい。

システムの技術は数年単位で移り変わっていく。今は最新に見えるシステムも、10年後には別の形の「古いシステム」になる。ロックインの見極めは一過性のイベントではなく、経営を続ける限り繰り返される定期的な健康診断のようなものだと捉えておくと、次に同じ問題に直面したときの心理的なハードルも下がるはずだ。

よくある誤解を先に解いておく

ベンダーロックインという言葉を初めて知ったとき、いくつかの誤解が生まれやすい。実務に入る前に、ここで一度整理しておく。

誤解1：ロックインされているのは自社の管理が悪いからだ

先代の代の判断を、承継後の視点だけで「管理が悪かった」と評価するのは公平ではない。当時の状況、当時の選択肢、当時の常識の中で行われた判断であり、後から振り返って初めて見えてくる問題は珍しくない。責めるべき相手を探すのではなく、今の状態をどう扱うかに集中した方が実務は前に進む。

誤解2：クラウドサービスに移行すればロックインはなくなる

オンプレミスの古いシステムから、クラウド型のSaaSに移行すれば安心だと考えがちだが、実際には新しいロックインの形が生まれることもある。SaaSであっても、データのエクスポート機能が限定的だったり、独自のAPIにしか対応していなかったりすれば、乗り換えづらさという意味では同じ問題を抱える。移行先を選ぶときも、この記事で示したチェックリストの観点は変わらず有効だ。

誤解3：大手ベンダーと契約していれば安心だ

規模の大きいベンダーであっても、契約内容が不透明であったり、データの持ち出しに制限があったりすれば、ロックインのリスクは変わらず存在する。ベンダーの規模や知名度は、ロックインの有無とは別の軸で判断すべき要素だ。

誤解4：一度ロックインに気づいたら、必ず乗り換えなければならない

先述の通り、現状を把握したうえで「維持する」という判断を下すことも、正当な経営判断の一つだ。ロックインの存在に気づくこと自体が目的であり、その先にどう動くかは会社ごとの事情によって変わってくる。

承継の初日にできる、最も小さな一歩

大がかりな契約見直しやベンダー交渉に取り組む前に、承継直後の経営者が一日でできる、最も小さな一歩を紹介しておく。

まず、社内で使っているシステム・ソフトウェア・SaaSの名前を、思いつく限り書き出してみる。会計、受発注、勤怠管理、顧客管理、メール、Webサイト、生産管理など、部署ごとに違うシステムを使っていることも多い。この時点では、契約内容や金額まで詳しく調べる必要はない。「どんな名前のシステムが、社内のどこで動いているか」を紙一枚に書き出すだけでよい。

次に、それぞれのシステムについて、契約担当者（先代が直接契約していたのか、総務が管理しているのか）が誰かを確認する。多くの場合、この段階で初めて「このシステムの契約書がどこにあるのかわからない」という事実に気づく。この気づき自体が、すでに大きな一歩だ。

• 社内のシステム・SaaSの名前を全て書き出す
• 各システムの契約担当者・管理者を確認する
• 契約書の保管場所を確認する（見つからない場合は、それ自体が要注意サイン）
• 一覧が完成したら、次に「現状把握のための実務チェックリスト」に進む

この作業に必要な時間は、慣れていれば半日程度だ。承継直後の忙しい時期であっても、優先度を上げて取り組む価値のある作業だと言える。システムの契約は、株式や登記のように公的な記録として残っているわけではないため、経営者自身が意識して掘り起こさなければ、存在すら忘れられてしまうことがある。

先代に直接聞けるなら、聞いておきたいこと

先代がまだ健在で、経営の一線から退いたばかりという状況であれば、システムやベンダーとの関係について直接話を聞ける貴重な機会がある。この機会は時間が経つほど失われていくため、承継の早い段階で活用しておきたい。

聞いておきたい質問の例を挙げる。

• このベンダーと契約したきっかけは何だったか
• 契約時に他社と比較検討したかどうか
• 過去にトラブルや値上げの交渉があったかどうか、あればどう対応したか
• 担当者について、信頼している理由や気になっている点があるか
• 「もし今のシステムを一から選び直せるなら、同じ会社を選ぶか」

最後の質問は特に有効だ。先代自身が「今ならもしかしたら違う選択をするかもしれない」と答えることもあれば、「いや、この会社で間違いなかった」と明確に答えることもある。どちらの答えであっても、後継者にとっては、自分の判断の材料になる貴重な情報だ。

先代がこうした話を後継者に自発的にすることは少ない。多くの場合、経営の話は業績や取引先の話が中心になり、システムやベンダーとの関係性は話題に上がりにくい。だからこそ、後継者側から意識して聞く機会を作る必要がある。

まとめ：ロックインは把握した上で選ぶもの

先代の代から続くベンダーとの関係は、多くの場合、悪意によって作られたものではない。時代背景の中で合理的だった選択が、時間の経過とともに「他に選べない」状態へと固定化してしまったものだ。ベンダーロックインという言葉を知ることの意味は、ベンダーを悪者にすることではなく、自社が今どういう状態にあるのかを正確に言葉にして把握することにある。

承継した経営者にとって、株式や登記の手続きには専門家がついているのに、システムについては相談先が見つからないという孤独感は実際に存在する。しかし、この記事で示したチェックリストや優先順位は、専門的な技術知識がなくても、担当者やベンダーへの質問という形で一つずつ進められるように作ってある。

まずは現状を知ること。そのうえで、維持するのか、条件を見直すのか、乗り換えるのかを、自分の意思で選べる状態を作ること。それが、先代から引き継いだシステムと、これからの会社の成長を両立させるための、最初の一歩になる。

よくある質問

Q. ベンダーロックインに気づいたら、すぐにベンダーに指摘した方がいいですか。

A. すぐに指摘する前に、まず自社の現状把握を終えることを勧める。データのエクスポート可否や契約の解約条件など、事実を確認したうえで話をする方が、感情的な対立を避けやすく、交渉の材料としても強くなる。何もわからないまま「ロックインされているのでは」と切り出すと、話が噛み合わずに終わることが多い。

Q. 先代の代からの付き合いで、ベンダーの担当者に気まずくて聞きにくいのですが、どう切り出せばいいですか。

A. 「見直したい」ではなく「引き継いだので現状を確認しておきたい」という言い方から始めるとよい。承継直後の経営者が契約内容やデータの取り扱いを確認するのは自然な行為であり、ベンダー側にとっても不自然な依頼ではない。誠実に対応してくれるかどうかは、それ自体がベンダーの姿勢を見極める材料になる。

Q. 乗り換えるかどうかを決める前に、社内で誰に相談するのが適切ですか。

A. 現場でシステムを実際に使っている社員と、契約や経理を把握している担当者の両方に話を聞くのが基本になる。加えて、技術的な条件の確認については、顧問の税理士や中小企業診断士、商工会議所の相談窓口など、社外の第三者に一度見てもらうことも検討に値する。株や登記の専門家に相談したのと同じ発想で、システムにも第三者の視点を入れることができる。

Q. うちは規模が小さく、システムも簡素なので、そこまで深刻なロックインは起きていないと思います。それでも確認すべきですか。

A. 規模が小さいほど、担当者一人・ベンダー一社に依存する構造になりやすく、関係依存型のロックインが強く出る傾向がある。システムの規模とロックインの深刻さは必ずしも比例しない。特に「その担当者が辞めたら業務が止まるかどうか」だけは、規模に関わらず一度確認しておく価値がある。