先代の代から使う古いパッケージシステムからの乗り換え判断

先代の代から使う古いパッケージシステムからの乗り換え判断

結論：乗り換えるかどうかより先に「今どういう状態か」を知ることが先

先代から会社を継いで、経理や受発注、在庫管理に使っている古いパッケージシステムをどうするか。この問いに対する結論を先に言ってしまうと、「今すぐ乗り換えるべきか」を決める前に、「今のシステムがどういう状態にあるのか」を正確に把握することが先だ。乗り換え自体は目的ではなく、経営リスクを下げるための手段にすぎない。順番を間違えると、必要のない乗り換えに大金を払ったり、逆に本当に危険な状態を放置したまま数年を過ごしたりする。

この記事は、こんな状態の人に向けて書いている。先代が使っていたパッケージシステムが今も現役で動いていて、誰に相談すればいいのか分からず、担当していた古参社員に聞いても「昔からこれだから」という答えしか返ってこない。契約書がどこにあるかも定かでなく、年間の保守費がいくらでどこまでカバーされているのかも把握していない。ベンダーの営業担当者は先代と個人的な付き合いがあった人で、今の自分とはまだ距離がある。そして、会社の登記や株式のことなら税理士や弁護士に相談できるのに、システムのことは誰にも相談できない気がしている——そんな二代目・三代目の経営者だ。

なぜ「システムには相談先がいない」と感じるのか

事業承継の実務では、株式の移転、登記の変更、税務、労務のそれぞれに専門家が付く。税理士は決算と相続税、司法書士は登記、弁護士は契約と紛争、社会保険労務士は労務。ところが基幹システムやITベンダーとの関係には、こうした「事業承継の専門家」に相当する立場の人がほとんど存在しない。中小企業庁が公表している事業承継ガイドラインでも、支援機関の一覧が示されているが、そこに載っているのは主に金融・法務・税務の専門家であり、情報システムの引継ぎを専門に扱う窓口は想定されていない。

その結果、システムの引継ぎは「先代から現場の担当者に、担当者から後継者に」という属人的な伝達に依存しがちになる。しかも先代自身がシステムの内容を細部まで理解していたわけではなく、「昔、知り合いの会社に頼んで作ってもらった」「あの担当者が全部やってくれている」という程度の認識で数十年運用してきたケースも珍しくない。承継した社長が孤独感を覚えるのは当然で、株式や登記のように明文化された制度と専門家のネットワークが存在しないぶん、ITの引継ぎは経営者個人の判断と勘に委ねられてしまっているのが実情だ。

全国47都道府県には「事業承継・引継ぎ支援センター」が設置されており、事業承継全体の相談は無料で受けられる。しかし、この窓口が担うのは主に株式・経営権・M&Aの相談であり、基幹システムやベンダー契約の内容まで踏み込んで相談できる体制ではない。ここに「システムの承継だけ相談先がない」という構造的な空白が生まれている。

「2025年の崖」は大企業だけの話ではない

経済産業省が2018年に公表した「DXレポート」は、複雑化・老朽化・ブラックボックス化した既存システムを放置した場合、2025年以降、最大で年間12兆円の経済損失が生じる可能性があるとして「2025年の崖」という言葉を提示した。この数字は主に大企業の基幹システムを念頭に置いたものだが、背景にある構造——システムの仕様がブラックボックス化し、それを知る人材が退職・引退していくことで、変更もリプレイスも身動きが取れなくなる——は、中小企業のパッケージシステムにもまったく同じ形で当てはまる。

複雑化・老朽化・ブラックボックス化した既存システムが残存する場合、2025年以降、最大12兆円/年（現在の3倍）の経済損失が生じる可能性がある（経済産業省「DXレポート」）

IPA（情報処理推進機構）が公表している調査でも、日本企業の4割超がレガシーシステムを保有していると報告されている（米国は2割強という比較データもある）。レガシーシステムを20年以上使い続けている企業が6割を超えるという指摘もある。中小企業の場合、この「レガシーシステム」の実体は、先代の時代に導入したパッケージソフトや、それをカスタマイズした業務システムであることが多い。規模が小さいぶん統計の目立つところには出てこないが、構造としての老朽化リスクは大企業と変わらない。

この構造を知っておくと、「うちのシステムが古いのはうちだけの特殊事情ではなく、日本の中小企業全体に共通する構造問題の一部だ」という視点で捉えられる。焦って結論を急ぐ必要はないが、放置していい問題でもない。

まず確認すべき5つの現状把握ポイント

乗り換えの判断をする前に、次の5点を確認しておきたい。これができていないまま「乗り換えるべきか」を議論しても、判断の土台がない。

• 契約書の現物と契約期間：保守契約・ライセンス契約がどこにあり、いつまでの契約で、自動更新条項があるかどうか
• 年間コストの全体像：初期導入費とは別に、年間の保守費・ライセンス費・カスタマイズ費として実際にいくら払っているか
• サポート状況（EOL）：ベンダーが現行バージョンのサポートをいつまで継続する方針か、後継バージョンの提供計画があるか
• データの持ち出し可否：今のシステムに入っているデータ（顧客・取引・在庫の履歴等）を、他のシステムに移せる形式で取り出せるか
• 属人化の度合い：運用・トラブル対応が特定の社員1名、あるいはベンダー側の特定の担当者1名に依存していないか

これらは税理士や弁護士に頼んでも代わりに調べてもらえない領域だ。経営者自身か、社内の担当者が一次情報に当たるしかない。まずは契約書を引っ張り出し、担当の古参社員とベンダーの双方に、感情的な駆け引きを抜きにして事実だけを確認する場を持つことをお勧めする。データの持ち出し可否を具体的にどう確認するかは、データをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきことで手順を示している。

EOLという視点でシステムを見る

古いパッケージシステムを評価するときに便利な考え方がEOL（サポート終了）（End of Life、サポート終了）という視点だ。ベンダーが「いつまでこのバージョンをサポートするか」を明示していない、あるいは営業担当者に聞いても曖昧な返事しか来ない場合、それ自体がリスクのシグナルになる。サポートが切れたシステムは、法改正（インボイス制度や電子帳簿保存法のような制度変更）への対応が止まったり、セキュリティパッチが提供されなくなったりする。

先代の代からのベンダーとの関係が良好であればあるほど、「サポートはいつまでですか」という質問がしにくいという声もよく聞く。しかし、これは関係を壊すための質問ではなく、事業を継続するための確認事項だと位置づければ、角を立てずに聞くことができる。「先代の代から大変お世話になっているので、今後も長くお付き合いしたいと思っている。そのために、現行システムの今後のサポート方針を確認させてほしい」という切り出し方であれば、ベンダー側も敵対的に受け取りにくい。

パッケージシステム特有の「乗り換えにくさ」の正体

パッケージシステムは、スクラッチ開発のシステムと違って「そのベンダーの製品でなければ動かない」という設計になっていることが多い。データ形式が独自仕様であったり、他社製品への移行ツールが用意されていなかったりする。これは意図的な設計というよりも、パッケージ製品が普及した時代（多くは2000年代前後）の業界の標準的な作り方だったという背景がある。

この「乗り換えにくさ」を指す言葉がベンダーロックインだ。ベンダーロックインが強いシステムほど、乗り換えの初期コスト（データ移行・業務フロー再設計・社員教育）が高くなる。ただし、ロックインが強いことと、そのシステムを使い続けるべきかどうかは別の問題だ。ロックインが強いからこそ、放置すればするほど乗り換えコストがさらに膨らんでいくという性質もある。今動いているからといって先送りすると、担当者の退職やベンダーの事業縮小といったタイミングで、選択の余地なく乗り換えを迫られることになりかねない。

乗り換えを検討すべき3つのシグナル

すべての古いパッケージシステムを乗り換える必要はない。判断の軸になるシグナルを3つ挙げる。

1. ベンダーからサポート終了・新規開発停止の通知が来ている、あるいは営業担当者の世代交代で連絡が取りにくくなっている
2. 今のシステムでは対応できない業務要件（取引先からのEDI対応要求、法改正対応、複数拠点でのリアルタイム共有など）が発生し始めている
3. 運用を知っている人間が社内に1人しかおらず、その人が高齢・退職間近である

いずれか1つでも該当する場合は、乗り換えの検討を始める時期に入っていると考えてよい。逆に、これらに当てはまらず、コストも業務要件も安定しているのであれば、無理に乗り換える必要はない。「古い」という理由だけで乗り換えるのは、乗り換え先のベンダーやSaaS事業者の営業トークに乗せられているだけの可能性もある。

乗り換えない、という選択肢も正当にありえる

ここは強調しておきたい点だ。古いパッケージシステムであっても、次の条件を満たしているなら、当面は使い続けるという判断も十分に合理的だ。

• ベンダーが今後数年のサポート継続を明示している
• 年間コストが業務の重要度に対して不当に高くない
• データのバックアップと移行可能性（データポータビリティ）が最低限確保されている
• 属人化がある程度分散されている、または引継ぎの仕組みがある

乗り換えには初期コストだけでなく、社員の学習コスト、一時的な業務効率の低下、移行時のデータ不整合リスクが伴う。「今の状態で大きな問題が起きていない」のであれば、「いつサポートが切れるか」「いつデータが取り出せなくなるか」の期限だけを明確にしたうえで、当面維持するという判断も経営判断として成立する。乗り換えは常に正しいわけではなく、先代の代からの安定運用そのものにも価値がある。

古参社員との関係をどう扱うか

先代の時代からシステムを担当してきた古参社員がいる場合、乗り換えの検討はその社員の存在意義に触れる話になりがちだ。長年「あのシステムのことは彼（彼女）に聞け」という体制でやってきた会社では、乗り換えの話を持ち出すこと自体が、その社員の役割を否定するように受け取られるリスクがある。

これを避けるためには、「システムを変える・変えない」という議論の前に、「今の状態を可視化する」という作業を、その社員と一緒に行うことが有効だ。一方的に外部のコンサルタントやベンダーを呼んで調査させるのではなく、古参社員に「一番詳しいのはあなたなので、まず現状を一緒に整理させてほしい」と依頼する形を取ると、当事者として関わってもらいやすくなる。乗り換えるにしても乗り換えないにしても、この人の知識を言語化・文書化する作業自体が、会社にとって初めての「システムの一次情報の棚卸し」になる。

契約確認で見落とされがちな3点

契約書を確認する際、経営者が見落としやすいポイントを3つ挙げる。

この3点は、実際に乗り換えを決めてから初めて発覚すると、交渉の主導権をベンダー側に握られたまま進めることになる。乗り換えるかどうかを決める前の段階で、一度契約書全文に目を通しておくべき理由がここにある。「うちでしか直せません」と言われた場合の契約書チェックについては、先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目で扱っている。

実務プレイブックが示す「切り替えの怖さ」

IT保守ベンダーの乗り換え実務を扱った技術者向けの解説記事では、ベンダー切り替えは契約上の問題である以上に運用継続性の問題であり、切り替え当日にメールが止まる、月次バックアップが取れなくなるといった事故が起きると業務に深刻な影響が出ると指摘されている。同記事では、契約締結から実際の切り替えまでに3〜6ヶ月程度を要し、引継ぎ準備、並行運用、切替、旧ベンダーの撤収というフェーズを踏むのが実務上の標準的な進め方だとされている。

経営者の立場からすると、「システムを変える」という決定を下した瞬間に業務が止まるわけではなく、そこから半年前後の並行運用期間があるという時間感覚を持っておくことが重要だ。焦って一気に切り替えようとすると、この並行運用期間を圧縮してしまい、切替直後の事故リスクが高まる。乗り換えを決めたら、逆算して半年程度の移行スケジュールを組むという前提を持っておきたい。こうした現行調査から並行運用・切り替えまでの一連の移行プロセスを、業務を止めずに段階的に進める形で引き受ける会社（システムリプレース、運営会社ゼットリンカーの受託メニュー）もある。

一社に依存しない体質をどう作るか

乗り換え先を選ぶときに意識しておきたいのが「一社に依存しない体質」という考え方だ。これは必ずしも「複数のベンダーに同時に発注する」という意味ではなく、1社にすべてを依存しない体質を作るという発想だ。パッケージシステムを一社に全面依存する形から乗り換える場合、次のベンダーにも同じように全面依存してしまうと、10年後、20年後に同じ問題が再発するだけになる。

乗り換え先を選定する際は、データの持ち出しやすさ、契約の透明性、サポート体制の明文化といった点を、先代の時代には確認できなかった観点として意識的にチェックリストに入れておくとよい。これは次の代（自分の子や、将来の後継者）が同じ孤独感を抱えないようにするための備えでもある。

判断を先送りしないための最小限のアクション

ここまでの内容を踏まえ、今すぐ始められる最小限のアクションを整理する。

• 契約書の現物を探し出し、契約期間・自動更新条項・解約通知期限を確認する
• ベンダーに「今後のサポート方針」を、関係を大切にする姿勢で確認する
• 古参社員に、システムの運用実態を一緒に文書化してもらう依頼をする
• 年間コスト（保守費・ライセンス費・カスタマイズ費）の総額を一覧化する
• データが他システムに移せる形式で保存されているか確認する

これらはいずれも、外部の専門家を雇わなくても、経営者自身が数週間で着手できる範囲の作業だ。乗り換えの是非を判断する材料は、まずここから生まれる。

システムの実態を記録に残す重要性

先代からの引継ぎで最も欠けているのは、多くの場合「システムの実態を記す文書」そのものだ。何のシステムを、いつ、どのベンダーから、どういう契約で導入し、誰が運用しているのか。これを1枚の表にまとめただけでも、次に何を判断すべきかが一気に明確になる。これはいわば会社のシステム管理台帳であり、株式名簿や登記簿と同じように、承継のたびに更新されていくべき記録だ。

現状、この記録が存在しない会社は非常に多い。先代が個人の頭の中と、古参社員の経験の中にすべてを持っていたからだ。今回、乗り換えを検討する・しないにかかわらず、この記録を作ることそのものが、次の承継（あるいは次の乗り換え判断）を楽にする最大の投資になる。

台帳に含めるべき最小限の項目は、システム名・導入ベンダー・契約形態・年間コスト・契約更新月・サポート終了予定・データ形式・運用担当者の8項目程度で十分だ。最初から完璧な台帳を作ろうとすると手が止まってしまうので、まずはExcelやスプレッドシートの1シートに、わかる範囲から埋めていくところから始めるのが現実的だ。実際に乗り換えを進める場合に集めておくべき資料の一覧は、開発会社の乗り換え手順、承継を機に整理する引き継ぎ資料一覧でさらに詳しく整理している。

パッケージシステムとスクラッチ開発、乗り換え先の違いを理解する

乗り換えを検討する段になると、次の選択肢として「別のパッケージシステムに乗り換える」「クラウド型のSaaSに乗り換える」「自社の業務に合わせてスクラッチ（フルオーダー）で作り直す」という3つの方向性が見えてくる。それぞれに向き不向きがあり、先代の代のパッケージシステムを評価する軸とは異なる基準で判断する必要がある。

パッケージシステムは、業界標準の業務フローに沿っていれば導入・運用コストを抑えられる一方、自社独自の業務フロー（先代の時代に積み上げてきた、その会社ならではのやり方）に合わせようとすると、追加カスタマイズの費用がかさみやすい。逆にクラウド型のSaaSは初期費用が低く、法改正対応やセキュリティパッチが自動的に反映される利点があるが、月額課金が事業規模の拡大とともに膨らんでいくことや、自社データの持ち出し条件をあらかじめ確認しておく必要がある点は先代の代のパッケージシステムと同じ注意が必要だ。スクラッチ開発は自社の業務に完全に合わせられる代わりに、開発費・保守費ともに高くなりやすく、開発を担う会社との関係性そのものが、今回問題にしている「ベンダーロックイン」を再び生み出すリスクも抱えている。

つまり、乗り換え先を選ぶ際も、「今のパッケージシステムで困っていること」を解消できるかどうかだけでなく、「10年後、20年後にまた同じ問題（サポート終了、契約不透明、属人化）が起きないかどうか」を基準に据える必要がある。乗り換え先の選定基準に、データポータビリティと契約の透明性を明確に加えておくことが、次の代に同じ苦労をさせないための最低条件になる。

内製化という選択肢との向き合い方

乗り換え先の検討の中で、「外部のベンダーに頼らず、社内でシステムを持てないか」という内製化の検討が話題に上ることもある。内製化するか外部に任せるかという論点は、承継後の経営判断の中でも意見が分かれやすい領域だ。

内製化には、業務の変化に応じて素早く手を入れられる、ベンダーへの依存度を根本から下げられるという利点がある。一方で、社内にシステムを保守できる人材を確保・育成し続けるコストと、担当者が退職した場合に再び同じ属人化リスクを社内で抱えることになるという欠点もある。中小企業の規模では、専任のシステム担当者を複数名確保することは現実的に難しく、結局は「社内の特定の1人に依存する」という、先代の代のベンダー依存と似た構造を社内で再現してしまう危険もある。

内製化を検討する場合は、全面的な自社開発に踏み切るのではなく、まずは日常的な設定変更やデータ集計程度を社内でできるようにし、根幹となる開発・保守は外部のパートナーに任せるという中間的な体制から始めるのが現実的だ。この判断も、契約書とコストの現状把握が済んでいなければ、そもそも比較の土台がないまま議論が進んでしまう。

サーバーの置き場所という観点も忘れずに確認する

先代の代のパッケージシステムの多くは、自社の事務所やサーバー室に専用機を置いて運用する、いわゆるオンプレミス型の形態で導入されている。クラウド全盛の今の基準で見ると運用コストが高く見えることが多い。サーバーの保守・電気代・空調・老朽化した機器の買い替えといったコストが、パッケージのライセンス費や保守費とは別に発生し続けているケースがあるため、乗り換えを検討する際は、この「見えにくいハードウェアコスト」も合わせて確認しておきたい。

一方で、オンプレミス型には、インターネット環境に依存せず動作する、自社のデータを完全に自社の管理下に置けるという利点もある。特に個人情報や取引先の機密情報を多く扱う業種では、あえてオンプレミスを維持するという判断が合理的な場合もある。乗り換えを検討する際は、「クラウドの方が新しいから」という理由だけでなく、自社の業種特性やセキュリティ要件を踏まえて、オンプレミスのまま刷新するか、クラウドに移行するかを判断する必要がある。

サーバーそのものの保守を担当しているのが、先代の代からのパッケージベンダーとは別の、地域の電気店や機器商社であるケースも意外と多い。この場合、パッケージシステムの契約書だけでなく、ハードウェアの保守契約も別途確認する必要がある。両者の契約が別会社であるにもかかわらず、社内的には「システムのことは全部同じところに任せている」と誤解されていることも珍しくないため、この機会に契約主体を整理しておくとよい。

相談先がない状態を今後どう変えていくか

この記事の冒頭で触れたとおり、承継社長が抱える孤独感の根本には、株式や登記には専門家がいるのに、システムには相談先がいないという構造的な空白がある。この空白を経営者一人で完全に埋める必要はないが、少なくとも次の一手は打っておきたい。

一つは、税理士や弁護士など、既に付き合いのある専門家に「システムについても、契約書レベルでおかしな点がないか一度見てもらえないか」と相談してみることだ。IT専門ではなくても、契約書の読み方や、自動更新条項・解約条件といった契約実務そのものについては、税理士や弁護士が助言できる範囲は意外と広い。もう一つは、商工会議所や地域の中小企業支援機関が実施しているIT関連の相談窓口を、事業承継の窓口とは別に確認しておくことだ。地域によっては、ITに詳しい専門家を無料または低価格で紹介してくれる制度を持っている自治体・商工会議所もある。

先代の代から蓄積された「相談先のなさ」は、今日明日で解消するものではないが、まずは既存の専門家に「システムも見てほしい」と声をかけてみるところから、輪を広げていくことができる。

複数のパッケージシステムが並存している場合の整理

先代の代を通じて、会社の成長に応じてシステムが追加されていった結果、経理システム、受発注システム、勤怠管理システムなど、複数のパッケージシステムがそれぞれ別のベンダーから導入され、互いに連携していないという状態になっている会社も多い。それぞれのシステムでデータを別々に手入力し直しているという状態は、承継後によく発覚する典型的な問題だ。

この場合、乗り換えの判断は1システムずつ個別に検討するのではなく、まず全体の業務フローを俯瞰した上で、どのシステムをハブとして残し、どのシステムを統合・廃止するかという優先順位をつける必要がある。すべてを一度に入れ替えようとすると、移行の負荷が一気に集中し、業務が止まるリスクが高まる。優先順位をつける際の基準としては、影響範囲が大きいシステム（受発注・経理など会社の基幹となる業務）を最後に回し、影響範囲が小さく検証しやすいシステム（勤怠管理など）から段階的に手をつけるという順序が、実務上は安全性が高い。

乗り換えコストをどう見積もるか

乗り換えを検討する際、経営者が見誤りやすいのがコストの見積もり方だ。新しいシステムの導入費・月額費用だけを見て判断すると、実際にかかる総コストを大きく下回った金額感で意思決定してしまう。乗り換えコストには、次のような項目が含まれることを踏まえておきたい。

• 新システムの導入費・初期設定費
• データ移行費（旧システムからのデータ抽出・変換・投入にかかる費用）
• 並行運用期間中の二重コスト（旧システムの保守費と新システムの費用を同時に払う期間が発生する）
• 社員教育・研修にかかる時間的コスト（生産性が一時的に下がる期間を含む）
• 移行後の初期トラブル対応にかかる予備費

これらを合算せずに「新システムの月額費用が今より安い」という理由だけで判断すると、移行初年度に想定外の出費と混乱が重なることになる。乗り換えを決める際は、少なくとも移行完了までの1年間分のコストを見積もったうえで、現状維持のコストと比較する必要がある。

相見積もりを取る際に気をつけたいこと

乗り換え先を検討する段階になったら、必ず複数の会社から見積もりを取ることをお勧めする。ただし、相見積もりを取る際には、先代の代のベンダーに対する配慮も忘れないようにしたい。現行のベンダーに何も告げずに他社と交渉を進め、後から関係が発覚すると、これまで築いてきた信頼関係が一方的に損なわれてしまう。

角を立てずに進めるための現実的な手順としては、まず現行ベンダーに「事業を引き継いだので、今後の運用体制を含めて一度全体を見直したい」と伝え、現行ベンダーにも見積もりの機会を用意することだ。結果的に現行ベンダーのままで契約を見直すという結論に至ることもあれば、他社に乗り換えるという結論に至ることもある。どちらに転んでも、「隠れて動いていた」という印象を与えないことが、先代の代からの関係を大切にしながら判断を下すうえでの基本的な作法になる。

承継のタイミングだからこそ動きやすい理由

システムの見直しは、実は経営者が変わった直後というタイミングが最も動きやすい。先代が現役の間は、「今のベンダーとの関係は先代が決めたことだから」という理由で、後継者が口を出しにくい空気がある。しかし承継が完了し、経営権が明確に自分に移った後であれば、「事業を引き継いだので、一通り契約と運用を確認させてほしい」という切り出し方が、誰に対しても自然に成立する。

この「承継直後」というタイミングを逃し、数年間そのまま運用を続けてしまうと、今度は「なぜ今になって急に言い出すのか」という別の説明を用意しなければならなくなる。逆に言えば、承継してから1〜2年以内というタイミングは、契約の見直しやベンダーとの関係整理に着手する上での最も自然な口実になる期間でもある。まだ承継から時間が経っていない経営者であれば、このタイミングを活かして現状把握に着手することを強くお勧めする。

業種によって「古いパッケージシステム」の重さは違う

ここまで一般論として書いてきたが、実際には業種によって、古いパッケージシステムが抱えるリスクの重さは異なる。製造業であれば、生産管理・在庫管理のシステムが古いまま止まると、取引先への納期に直接影響が出る。建設業であれば、原価管理システムの不備が、案件ごとの採算把握を難しくし、経営判断そのものを鈍らせる。小売・流通業であれば、POSや受発注システムが取引先のシステムと連携できないことが、そのまま新規取引の機会損失につながる。士業や専門サービス業であれば、顧客管理システムの古さそのものよりも、そこに蓄積された顧客の履歴情報が引き出せなくなることの方が深刻な問題になりやすい。

自社の業種において、古いパッケージシステムが止まった場合に「どの業務が、どれくらいの時間、どの程度の損失を伴って止まるか」を一度想像してみることをお勧めする。この想像が具体的であればあるほど、乗り換えの優先順位づけや、緊急時のバックアップ体制の必要性の判断がしやすくなる。逆に、想像しても大きな損失につながらないのであれば、その部分については焦って乗り換えを検討する必要はないという判断にもつながる。

先代に直接確認できることは、聞いておく

もし先代がまだ健在で、経営から完全に退いたわけではない状況であれば、システムについて先代自身に直接確認できることは、今のうちに聞いておいた方がよい。先代がなぜそのベンダーを選んだのか、どういう経緯で今のパッケージシステムを導入したのか、契約の際にどんな条件交渉をしたのか——こうした背景情報は、契約書という紙の資料だけでは読み取れないことが多い。

先代がすでに引退している、あるいは話を聞くのが難しい状況であれば、先代と付き合いの長かった古参社員や、当時のベンダー担当者に話を聞くことが次善の策になる。いずれの場合も、「今のシステムを否定するために聞く」のではなく、「経緯を正しく理解した上で、今後の判断をしたい」という姿勢で聞くことが、相手の協力を得やすくする。先代が築いてきた関係性や判断には、当時なりの合理性があったはずだ。それを軽視せず、まず理解しようとする姿勢が、承継後の社内外の信頼関係を維持する土台になる。

まとめ：乗り換えは目的ではなく手段

先代の代から使っているパッケージシステムをどうするかという問いに、「乗り換えるべきだ」「維持すべきだ」という一律の正解はない。判断すべきは、今のシステムがどういう契約・コスト・サポート状況・属人化の状態にあるかを正確に把握し、それを踏まえてリスクとコストを比較することだ。

株式や登記の承継には専門家のネットワークがあるが、システムの承継には、今のところそれに相当する明確な相談先がない。だからこそ、経営者自身がまず現状を可視化し、古参社員やベンダーとの関係を大切にしながら、事実に基づいた判断を積み重ねていくしかない。この記事で示した確認ポイントとアクションが、その最初の一歩になれば幸いだ。

よくある質問

Q1. 古いパッケージシステムのベンダーに「サポートはいつまでか」と聞くと、関係が悪化しないか心配です。

聞き方次第で角を立てずに確認できる。「今後も長くお付き合いしたい」という前提を明示したうえで、事業継続のための確認であることを伝えれば、多くのベンダーは前向きに答えてくれる。逆に、この質問に対して曖昧な返答しか得られない場合、それ自体がサポート体制に不安があるというシグナルとして受け止めるべきだ。

Q2. 乗り換えを決めた場合、どのくらいの期間を見ておけばいいですか。

実務上は契約締結後、引継ぎ準備・並行運用・切替・旧ベンダー撤収を含めて3〜6ヶ月程度を見ておくのが標準的とされている。並行運用期間を圧縮すると切替直後の事故リスクが高まるため、逆算して半年程度のスケジュールを組んでおくことをお勧めする。

Q3. 古参社員にシステムのことを聞いても「昔からこうだから」としか答えてもらえません。どうすればいいですか。

「変える・変えない」を議論する前に、まず現状を一緒に文書化する作業として依頼してみるとよい。一方的に外部のコンサルタントを入れて調査させるのではなく、「一番詳しいのはあなたなので、一緒に整理させてほしい」という形にすると、当事者として協力してもらいやすくなる。

Q4. 乗り換えないという判断をした場合、何もしなくていいのですか。

何もしなくていいわけではない。ベンダーのサポート終了時期、データの持ち出し可否、契約の自動更新条件だけは定期的に確認し、状況が変わった時点で再度判断できる状態を保っておく必要がある。乗り換えない判断は「放置」ではなく「モニタリングを続けたうえでの現状維持」であるべきだ。