オンプレミスの先代サーバーから、クラウド移行はどこから始めるか

社長室の隅、あるいは倉庫の一角に、先代の時代から動き続けているサーバーがある。ファンの音は少し大きくなったが、まだ止まってはいない。バックアップは誰かが手動でテープかディスクに取っているらしいが、実際に何が入っているのか、担当者以外は誰も把握していない。結論から言えば、こうした状態のオンプレミス基盤からクラウドへ移行するときの出発点は「今動いているシステムを丸ごと洗い出し、それぞれの寿命と依存関係を紙の上に並べること」であり、いきなり見積もりを取ることではない。

この記事は、次のような状態にある二代目・三代目の経営者に向けて書いている。先代が導入したサーバーやソフトウェアが本社の一室にまだ置かれていて、電源を落としたら何が起きるのか誰も正確に説明できない。取引先や社内から「クラウドにしたほうがいいのでは」と言われるが、何から手をつければいいのか分からない。長年付き合いのある地元の情報システム会社に相談すると「今のままで大丈夫です」と言われ、それ以上踏み込めない。株式の承継や登記の変更には税理士や弁護士という相談先がいるのに、サーバーの中身については誰にも本音で聞けない——そういう孤独感を抱えている社長のために、移行の順序と判断基準を整理する。

先代の時代に「そこにあった」サーバーという存在

多くの中小企業では、サーバーは経営判断の結果として「導入された」のではなく、必要に迫られて「置かれた」という経緯をたどっている。受発注が電話とFAXから脱却するタイミングで基幹システムを入れ、顧客管理は別の担当者が個人的に契約したパッケージソフトで運用し、会計はさらに別のベンダーのオンプレミス製品を使っている、というように、時期も担当者も異なるシステムが積み重なっているケースが多い。

先代がそれぞれのタイミングで「その時点でベストだった選択」を積み重ねた結果であり、誰かの判断が間違っていたわけではない。ただし、承継した二代目・三代目の視点に立つと、この積み重ねは「なぜこの構成になっているのか誰も説明できない」という状態として引き継がれる。担当者が退職していたり、導入したベンダーの担当者も代替わりしていたりすると、当初の設計意図はほぼ失われている。

この「そこにあるから動かせない」という状態そのものが、レガシーシステムの典型的な入り口になる。古いから悪いという単純な話ではなく、意図が失われたまま存在し続けているシステムをどう扱うかが、承継後の最初の情報システム課題になる。

なぜ「先代サーバー」が承継の盲点になりやすいのか

事業承継の議論では、株式の分散防止、経営権の集中、後継者教育、資金調達といったテーマが中心に語られる。株式評価や登記変更には税理士・弁護士・司法書士という明確な専門家がついてくれるが、社内のサーバーやシステムの引き継ぎについては、相談先が用意されていないことが多い。

東京商工会議所などが提供する事業承継支援でも、株価試算・税制・M&A・補助金といった経営・財務面の支援は充実している一方、システムや業務委託先との契約関係の引き継ぎは、経営者自身が個別に判断せざるを得ない領域として残っている。つまり、承継の実務上、システムの引き継ぎは制度的な支援の網からこぼれやすい。

株式や登記には専門家がいる。税務にも顧問税理士がいる。だが「このサーバー、あと何年動かせますか」と聞ける相手が社内にも社外にもいない。

この孤独感は、二代目・三代目社長からしばしば聞かれる感覚であり、システムに詳しくない経営者ほど強く感じている。だからこそ、最初に必要なのは「専門用語を理解すること」ではなく「今何があるかを可視化すること」である。

クラウド移行を始める前に、まず「今」を洗い出す

サーバーの入れ替えやクラウド移行の相談を受けると、多くの経営者はいきなり「クラウドに移行するといくらかかるか」を知りたがる。しかし見積もりの前提となる情報——何のシステムが何台のサーバーで動いているか、それぞれの保守期限はいつか、誰が契約者で誰が実際の管理者か——が社内で整理されていない状態では、どのベンダーに聞いても正確な回答は返ってこない。

最初にやるべきことは、次の3点の洗い出しである。

• 社内にある物理サーバー・NAS・複合機連携機器などのハードウェアの台数と設置場所
• それぞれの上で動いているソフトウェア（基幹・会計・顧客管理・勤怠・給与など）の名称とバージョン
• 契約先ベンダーの名前、契約更新月、保守料の年額、緊急時の連絡先

これを1枚の表にまとめる作業を、システム管理台帳の整備と呼ぶ。台帳自体は難しいものではなく、エクセル1枚で十分だが、これがないままクラウド移行の相談を進めると、後から「実はもう1台サーバーがあった」「このソフトは別会社の保守契約だった」という抜け漏れが必ず出てくる。

台帳に記載すべき項目をもう少し具体的にすると、次のようになる。ハードウェアであれば「機種名・購入年・設置場所・保証期限」、ソフトウェアであれば「製品名・バージョン・ライセンス形態・年間保守料」、契約であれば「契約先企業名・担当者名・契約更新月・解約時の通知期限」という3つの軸をそれぞれ埋めていく。最初は分かる範囲だけでよく、分からない項目は「不明・確認中」と書いておくだけでも、次に誰が見ても状況が伝わる資料になる。

この台帳作りは、社長一人で完結させる必要はない。経理担当者は契約書と請求書の在り処を知っていることが多く、現場の古参社員は実際にどの機器がどう使われているかを知っている。複数の社員から少しずつ情報を集めて1枚に統合する作業そのものが、実は社内の暗黙知を可視化する機会にもなる。

オンプレミスとは何か、あらためて確認する

ここで用語を整理しておく。オンプレミスとは、サーバーやストレージなどの情報システム基盤を自社の敷地内（社屋・工場・倉庫など）に物理的に設置し、自社または委託先が保守・運用する形態を指す。対義語がクラウドで、クラウドでは他社（クラウド事業者）が保有・運用するデータセンターの計算資源を、インターネット経由で必要な分だけ利用する。

オンプレミスの特徴は次のように整理できる。

先代の時代にオンプレミスが選ばれたのは、当時はクラウドサービスが未成熟だったか、月額課金という発想自体が一般的でなかったという時代背景がある。今の視点で「オンプレミスを選んだのは判断ミスだった」と評価するのは適切ではない。当時の技術水準と予算感の中では、自社でハードウェアを保有し目の届く範囲で管理することが、むしろ安心材料だった時期がある。

「今のままで大丈夫です」の裏にある事情

先代の代から付き合いのある情報システム会社やベンダーに「クラウド化」の相談をすると、「今のままで大丈夫です」「まだ壊れていないので急ぐ必要はありません」という回答が返ってくることがある。この回答自体を疑ってかかる必要はないが、背景にある事情は理解しておいたほうがいい。長年の保守契約が年々値上がりしているなら、先代の代から年々上がっていく保守費の契約を見直すタイミングも合わせて検討したい。

保守契約を主な収益源としているベンダーにとって、既存システムの延命は合理的な提案でもある。悪意があるわけではなく、その会社の得意分野がクラウド移行やモダンな開発ではなく、既存のオンプレミス機器の保守だからという場合が多い。長年の付き合いがあるからこそ、こちらから「クラウド化を検討したいが、御社はどこまで対応できますか」と率直に聞いてみることが、関係を壊さずに現状を把握する第一歩になる。

聞くべき質問は次のようなものだ。

1. 現在のサーバーのハードウェア保証・部品供給はいつまで継続するか
2. 現在動いているOS・ソフトウェアのメーカーサポートはいつ終了するか
3. クラウド移行を検討する場合、自社で対応可能か、他社への相談が必要か
4. データの移行（エクスポート）は技術的に可能か、どの形式で取り出せるか

この4点に明確な回答が返ってこない場合、それはベンダーの能力不足を意味するのではなく、単に「クラウド移行は自社の対応範囲外」というだけの場合が多い。角を立てず関係を維持しながら、必要な部分だけ別の専門家に相談する、という併用の発想を持つとよい。

サポート終了（EOL）という期限がある

オンプレミス機器やソフトウェアには、メーカーが定めた保守・サポートの期限がある。この期限をEOL（サポート終了）（End of Life）と呼ぶ。EOLを迎えたOSやソフトウェアは、セキュリティの脆弱性が発見されても修正パッチが提供されなくなり、サイバー攻撃を受けた際の被害が拡大しやすい状態になる。

先代の時代に導入されたサーバーのOSやデータベースソフトが、すでにメーカーの標準サポート期間を過ぎている、あるいは有償の延長サポートでかろうじて維持されている、というケースは珍しくない。延長サポートの費用が年々上がっていくのに、社内では「今まで大きな問題が起きていないから大丈夫」という空気が支配的になりやすい。

EOLは「壊れる日」ではなく「守られなくなる日」である。稼働自体は続くが、脆弱性対応という防御が失われる。この違いを理解しておくことが、クラウド移行の緊急度を判断する材料になる。

クラウド移行、最初の一歩は「全部一気に」ではない

先代サーバーからのクラウド移行というと、社内の全システムを一斉にクラウドへ切り替える、という大がかりなプロジェクトを想像しがちだが、実務としてはそのような一斉移行はリスクが高い。基幹システム、会計、顧客管理、勤怠管理など、それぞれ依存関係や重要度が異なるシステムを同時に動かすのは、失敗した場合の被害も同時に広がる。

現実的な進め方は次の順序になる。

• 台帳（システム管理台帳）を作り、稼働中の全システムを可視化する
• それぞれのEOL時期・保守契約更新月を確認し、優先度をつける
• 最もリスクが高い、または最も業務影響が小さいシステムから、試験的にクラウド移行する
• 移行の手応え（コスト・使い勝手・トラブル対応）を確認しながら、次のシステムに進む

多くの場合、最初の移行対象として選ばれるのは、勤怠管理やファイル共有など、業務が止まっても即座に会社全体が停止するわけではないシステムである。逆に、受発注に直結する基幹システムは、十分な検証期間を確保してから移行するのが安全だ。

古参社員の「今のままでいい」という声とどう向き合うか

クラウド移行の話を社内で進めようとすると、長年その業務を担ってきた古参社員から「今の使い方に慣れている」「新しいシステムは覚えるのが大変」という反発が出ることがある。これは抵抗というより、長年の運用で身につけた業務ノウハウが、システムの見た目や操作手順に染み付いていることの表れである。

古参社員の抵抗を無視して一方的に移行を進めると、現場の生産性が一時的に大きく落ちる。逆に、その社員が持っている「このシステムのこの機能は、実はこういう理由で使っている」という業務知識は、移行時の要件定義において最も価値のある情報源になる。

移行を検討する際は、古参社員に「なくなると困る機能」を先に聞き出すヒアリングの時間を設けることを勧める。表面的な操作画面が変わっても、業務上必要な機能が引き継がれていることが伝われば、反発は大きく和らぐ。

一社依存から抜け出す——マルチベンダーという考え方

先代の時代からの付き合いで、基幹システムも会計もインフラの保守も、すべて同じ1社に任せているという企業は多い。長年の信頼関係があるからこそ効率的だった面もあるが、承継後にクラウド移行を検討する段になると、この一社依存が身動きを取りにくくする要因になることがある。

契約の詳細を確認すると、データの形式が独自仕様で、他社では読み込めない、あるいはそのベンダー専用のハードウェアでしか動かない、という構成になっていることがある。この状態を業界ではベンダーロックインと呼ぶ。ロックインされている場合、クラウド移行の交渉においてベンダー側が強い立場に立ち、価格や移行条件で不利になりやすい。「うちでしか直せません」と言われた経験があるなら、先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目も参照してほしい。

ロックインされているかどうかは、次の質問をベンダーにぶつけてみると輪郭が見えてくる。「このシステムのデータを、御社以外の会社が触れる形式で書き出せますか」「このソフトウェアの利用をやめた場合、御社独自の追加費用は発生しますか」。この2問に明快な回答が得られない、あるいは高額な離脱コストが提示される場合、その関係は知らないうちに一社依存が深まっていたと考えたほうがよい。

すべてを一斉に他社へ切り替える必要はない。むしろ、基幹は既存ベンダーに残しつつ、周辺業務(勤怠・ファイル共有・簡易な顧客管理など)は別のクラウドサービスに任せる、という複数のベンダーを併用する発想を持つことが、リスクの分散になる。1社に依存しない体制を少しずつ作ることが、次の代への引き継ぎもしやすくする。1社が経営不振で保守を打ち切った場合でも、他の業務は止まらないという安心材料にもなる。

移行前に必ず確認すべき「データの持ち出せる」性質

クラウド移行、あるいはベンダーの切り替えを検討する際に最初に確認すべき技術的な論点は、現在のシステムから自社のデータを標準的な形式で取り出せるかどうかである。この「自社のデータを自社の意思で他の場所に移せる」という性質を、データの持ち出しやすさと呼んでおく。

長年使ってきたオンプレミスの基幹システムの中には、データがベンダー独自の形式で保存されており、標準的なCSVやExcel形式でのエクスポート機能自体が用意されていない、という製品が存在する。この場合、クラウド移行を進めるには、データ移行のためだけの追加費用や作業が発生する。

見積もりを取る前に、まず現行ベンダーに「データをCSVで全件エクスポートできますか」と確認することを勧める。この一問への回答の速さと明確さが、そのベンダーとの今後の付き合い方を判断する材料にもなる。すぐに「できます」と答えるベンダーは技術的な透明性が高く、逆に濁す、あるいは高額な作業費を提示するベンダーは、データを人質にした関係を築いてきた可能性がある。

データが標準形式で取り出せることが確認できれば、クラウド移行の選択肢は大きく広がる。逆に、取り出せない、あるいは取り出しに数十万円単位の特別作業費がかかると分かった場合は、その事実だけでも十分に価値のある発見である。今すぐ移行しないとしても、次の契約更新のタイミングで交渉材料として使えるし、いずれ移行するときのために予算を確保しておく判断材料にもなる。この論点はデータをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきことでも扱っているので、あわせて確認してほしい。また、ソースコードやシステムの権利関係が曖昧なまま承継しているケースもあるため、先代システムのソースコードの権利は誰にあるか、納品物から確認する方法も参考になる。

非IT出身の社長が陥りやすい3つの誤解

先代から会社を継いだ社長の多くは、営業・製造・現場のいずれかを長く経験してきており、情報システムを専門に学んだ経験を持たない場合が多い。これは決して不利なことではないが、非IT出身の社長がクラウド移行の検討時に陥りやすい誤解がいくつかある。ここで整理しておく。

1つ目は「クラウドは危険で、オンプレミスは安全」という思い込みである。自社の敷地内に物置いてあるサーバーは目に見えて安心感があるが、実際のセキュリティ水準は、誰がどう管理しているかによって決まる。老朽化したオンプレミス機器を自社の担当者が手が回らないまま放置している状態は、大手クラウド事業者が専門チームで24時間監視している環境よりも、むしろ危険度が高いことがある。

2つ目は「一度クラウドに移行したら、もう戻れない」という思い込みである。実際には、クラウドサービスの多くは契約を解除してデータを引き出すことができ、以前ほど「一度決めたら固定される」という性質は弱まっている。ただし、これは前述したデータの持ち出しやすさが確保されているサービスを選んだ場合に限られる。契約前にこの点を確認しておけば、過度に恐れる必要はない。

3つ目は「専門用語が分からないと判断できない」という思い込みである。実際には、クラウドかオンプレミスか、どのベンダーを選ぶかという判断は、技術的な詳細よりも「何が起きたら会社が困るか」という経営判断のほうが本質的である。サーバーが止まったら受注が何日止まるか、データが消えたら顧客との関係にどう影響するか、という問いに答えられるのは、現場を知っている経営者自身である。専門用語は必要な範囲だけ理解すれば十分で、細部の技術判断は専門家に委ねてよい。

先代に相談できないときの向き合い方

先代がすでに引退している、あるいは既に他界しているなど、直接相談できない状況で承継したケースも多い。この場合、「なぜこのシステムをこの構成にしたのか」という経緯を知る人が社内に誰もいない、という状況に陥りやすい。

このようなときは、まず契約書・請求書・稟議書などの紙の記録を探すことから始めるとよい。導入時期が分かれば、当時の技術水準や業界の一般的な選択肢から、おおよその経緯を推測できる。また、当時のベンダー担当者がまだその会社に在籍していれば、直接話を聞く機会を作ることも有効である。担当者が退職していても、その会社自体に導入時の資料が保管されている場合がある。

経緯が完全には分からなくても構わない。重要なのは、過去の経緯を無理に掘り起こすことよりも、「今、何が動いていて、それがいつまで安全に使えるか」という現在地を正確に把握することである。過去の判断の理由が分からないまま次に進むことは、承継においてはむしろ普通のことであり、恥じる必要はない。

クラウド移行とセキュリティ対策の関係

クラウド移行を検討する際、セキュリティ面での不安を口にする経営者は多い。「自社のデータを他社のサーバーに置くのは怖い」という感覚は自然なものだが、実際のリスクバランスを理解しておくと判断がしやすくなる。

大手クラウド事業者のデータセンターは、物理的な入退室管理、データの暗号化、複数拠点への自動バックアップといった対策が標準で組み込まれていることが多く、これらを中小企業が自社のオンプレミス環境で同水準に整えるには、相応の投資と専門人材が必要になる。一方で、クラウドを利用する側にも責任が残る。IDとパスワードの管理、アクセス権限の設定、多要素認証の有効化といった「利用者側の設定」を怠れば、クラウドであっても情報漏洩のリスクは残る。

つまり、クラウド移行はセキュリティを事業者に「丸投げ」できるわけではなく、事業者が担う部分と自社が担う部分が分かれている。この分担を理解した上で、自社が担うべき最低限の設定(パスワードの複雑化、退職者アカウントの即時削除、アクセス権限の定期確認)を運用ルールとして定めておくことが、移行後の安心材料になる。

内製化するか、外部に任せるか

クラウド移行後の運用体制を考える際、社内にIT担当者を置いて内製化するか、外部の専門会社に運用を委託するかという判断が出てくる。これは内製化とアウトソースのどちらを選ぶかという典型的な論点であり、正解は会社の規模や業種によって異なる。

従業員10〜100人規模の中小企業では、専任のIT担当者を1人置くコストと、専門会社に運用委託するコストを比較検討することになる。専任担当者を置く場合、その担当者が退職・異動した際に再び「その人しか分からない」状態に戻るリスクがある。外部委託の場合、契約内容次第で今回のような一社依存の問題が再発する可能性がある。

いずれを選ぶ場合も、契約書または業務分担表に「誰が何を担当し、どこまでの責任を負うか」を明記しておくことが、次の代への引き継ぎを楽にする。

移行プロジェクトの進め方——見積もりの前にやること

クラウド移行を外部のベンダーやシステム開発会社に相談する際、最初から複数社に見積もりを依頼するのは早すぎる。見積もりの精度は、渡す情報の精度に比例する。前述のシステム管理台帳を用意した上で相談すれば、各社からより正確で比較可能な見積もりが返ってくる。

見積もり依頼の前に整理しておくべき情報を、簡潔にまとめると次のようになる。

• 現在稼働中のシステム一覧（台帳）
• 各システムのEOL・保守契約更新時期
• 移行の優先順位（どのシステムから始めたいか）
• 移行後に譲れない業務要件（古参社員からのヒアリング結果）
• おおよその予算感（クラウド利用料は月額課金が基本という前提の理解）

この5点が整理できていれば、複数のベンダーから見積もりを取った際に、単純な金額比較ではなく、対応範囲や保守体制の違いを比較できるようになる。

「クラウド移行=コスト削減」という誤解に注意する

クラウド移行を検討する経営者の多くが期待するのは、コスト削減効果である。しかし、実際に移行してみると、月額利用料と既存の保守費用を単純比較した場合、必ずしも安くなるとは限らない。特に、既存のオンプレミス機器がすでに購入済みで残存耐用年数が長く残っている場合、その機器の追加コストがかからない期間は、クラウド移行によって新たな月額費用が発生することになる。

クラウド移行の本質的な価値は、コスト削減そのものよりも、次のような点にある。

• 災害・機器故障時の事業継続性が高まる
• ハードウェアの物理的な老朽化リスクから解放される
• 遠隔からのアクセス・複数拠点での利用がしやすくなる
• セキュリティパッチの適用が事業者側で行われ、EOLリスクが軽減される

短期的なコストだけでなく、こうした事業継続性やリスク軽減の観点を含めて経営判断することが、承継後の情報システム戦略として適切な考え方になる。

補助金という選択肢も検討に値する

クラウド移行にかかる初期費用の負担を軽減する手段として、中小企業・小規模事業者向けの補助金制度が用意されている場合がある。独立行政法人中小企業基盤整備機構が運営する「デジタル化・AI導入補助金」の事務局サイトでは、ITツールの導入やクラウドサービスの利用を対象とした支援策が案内されている。申請枠の種類や対象ツールは年度によって変わるため、実際に申請を検討する際は、事務局サイトのITツール検索や資料ダウンロードのページで最新の条件を確認することを勧める。

補助金の活用にあたっては、公募要領の締め切りや対象経費の範囲が細かく定められているため、早い段階から情報収集を始め、必要であれば商工会議所や認定支援機関に相談する体制を整えておくとよい。

クラウド移行のロードマップ——半年から1年で考える

ここまでの内容を、実際の作業順序として時系列に整理する。

1. 1ヶ月目: 社内のハードウェア・ソフトウェア・契約先ベンダーを台帳化する
2. 2ヶ月目: 各システムのEOL・保守契約更新時期を確認し、優先順位をつける
3. 3ヶ月目: 古参社員へのヒアリングを行い、「なくなると困る機能」を洗い出す
4. 4〜5ヶ月目: 最初に移行するシステム(業務影響が小さいもの)を選定し、複数社から見積もりを取る
5. 6〜8ヶ月目: 試験的な移行を実施し、運用の手応えを確認する
6. 9ヶ月目以降: 手応えを踏まえて、次のシステムの移行を計画する

この期間感は目安であり、会社の規模やシステムの複雑さによって前後する。重要なのは、全システムを一度に移行しようとせず、段階を踏んで進めることである。

移行でよくある失敗パターン

クラウド移行の相談を受ける中で、繰り返し見られる失敗パターンがいくつかある。事前に知っておくことで、同じ轍を踏む可能性を減らせる。

失敗パターン1: 移行スケジュールを決算期や繁忙期に重ねてしまう。多くの中小企業には、受注や決算処理が集中する時期がある。この時期にシステムの切り替えを行うと、トラブルが発生した際の対応リソースが確保できず、業務への影響が深刻化しやすい。移行のタイミングは、比較的落ち着いている時期を選ぶことを勧める。

失敗パターン2: 旧システムをすぐに廃止してしまう。新システムへの移行が完了したからといって、旧システムのデータやサーバーを即座に廃棄・解約するのはリスクが高い。移行後1〜3ヶ月程度は旧システムを並行して保持し、新システムのデータに誤りや欠落がないかを確認する期間を設けたほうが安全である。

失敗パターン3: 現場の意見を聞かずに導入を決めてしまう。経営者やIT担当者だけで移行先を決定し、現場に事後報告する形になると、実際の業務に必要な機能が欠けていることに移行後に気づく、という事態が起きやすい。前述した古参社員へのヒアリングを、意思決定の前段階で必ず組み込むことが重要になる。

失敗パターン4: 移行の目的を社内で共有しないまま進めてしまう。「なぜ変えるのか」を経営者が説明せずに移行を進めると、現場では「余計な変更をされた」という受け止め方になりやすい。コスト削減、事業継続性の向上、次の世代への引き継ぎのしやすさなど、移行の目的を先に共有しておくことが、社内の協力を得やすくする。

社内への説明のしかた——現場を味方にする

クラウド移行は、経営者一人の決断だけでは完結しない。実際に日々の業務でシステムを使う現場の社員が納得し、協力してくれるかどうかで、移行後の定着度は大きく変わる。

社内説明の際に有効なのは、変化を「システムの都合」ではなく「会社の将来のための投資」として伝えることである。例えば、「今のサーバーはあと数年でメーカーのサポートが切れる。何もしないと、故障したときに部品が手に入らず、業務が長期間止まるリスクがある。だから今のうちに手を打ちたい」というように、リスクと対策をセットで説明すると、変化の必要性が伝わりやすい。

また、全社員向けの一斉説明だけでなく、部署ごとに小さな説明会を開き、「あなたの部署の業務にはこういう影響がある」という具体的な情報を伝える機会を作ることも効果的である。抽象的な「クラウド化します」という説明よりも、「今使っているこの画面は、こう変わります」という具体性のある説明のほうが、現場の不安を減らす。

先代の判断を否定せず、次の代につなぐ

クラウド移行の議論を進める中で気をつけたいのは、先代が選んだシステムやベンダーを一方的に「古い」「間違っていた」と否定する態度である。先代がそのシステムを選んだ時点では、それが最善の判断だった可能性が高い。その判断を尊重しながら、時代が変わったことに応じて次の一手を打つ、という姿勢を社内・社外に示すことが、承継後の経営者としての信頼を積み上げることにつながる。

古参社員や長年のベンダーに対しても、「今までありがとうございました、これからは会社の成長に合わせて体制を見直していきます」という伝え方をすることで、関係を断ち切るのではなく、緩やかに更新していくことができる。長年の付き合いを大切にする姿勢は、地域に根ざした中小企業にとって、取引先や社員からの信頼を維持するうえでも欠かせない要素である。

まとめ——最初の一歩は「見積もり」ではなく「台帳」

オンプレミスの先代サーバーからクラウドへの移行を考えるとき、多くの経営者は「まずベンダーに見積もりを頼む」ことから始めようとする。しかし、正確な見積もりを得るためには、その前段階として、社内にどのようなシステムがあり、それぞれの寿命(EOL)と契約状況がどうなっているかを可視化する作業が欠かせない。

株式や登記の承継には税理士や司法書士という専門家がいる。システムの承継についても、最初から一社に丸ごと相談するのではなく、まず自社の現状を台帳という形で言語化し、そのうえで複数の専門家やベンダーの意見を比較する、という姿勢を持つことが、遠回りに見えて実は最短の道筋になる。承継1年目でクラウド移行の提案を受けている場合は、承継1年目、クラウド移行の提案が来たら今検討するか来年に回すかも判断材料として読んでおくとよい。

情報システムの引き継ぎに、正式な相談窓口が用意されていないことは、承継した社長にとって心細く感じられるかもしれない。しかし裏を返せば、それだけ自由度が高い領域でもある。先代の時代のやり方をそのまま踏襲する義務はなく、今の会社の規模や事業の方向性に合わせて、ゼロから組み立て直すことができる。焦って一度に全部を変えようとせず、まずは台帳を作り、現状を正確に把握するところから始めてほしい。それが、先代が築いた基盤への敬意を保ちながら、次の10年、20年を見据えた情報システムの土台を組み立てていく、最も確実な一歩になる。