先代のシステムを「延命するか、作り直すか」の判断基準

先代のシステムを「延命するか、作り直すか」の判断基準

結論から言う。先代のシステムを延命するか作り直すかは、「気合」でも「勘」でもなく、次の3つの問いに答えが出せるかどうかで決まる。①そのシステムが止まったとき、代わりに手を動かせる人が社内に何人いるか。②今使っている土台（OS・ソフト・言語）はあと何年、作った会社や開発元から面倒を見てもらえるか。③壊れたときに直せる人が、外部も含めて現実的に見つかるか。この3つのうち2つ以上が「危険」側に振れているなら、延命ではなく作り直しを検討すべき時期に来ている。逆に3つとも「まだ大丈夫」と言えるなら、慌てて作り直す必要はない。

この記事は、こんな状態の人に向けて書いている。先代が20年以上前に導入した販売管理システムや、経理担当のベテラン社員が作り込んだExcelとAccessの複合技が、今も会社の売上や在庫を支えている。そのシステムに詳しいのは、先代か、あるいは古参の社員一人だけ。株式の承継や登記の変更については税理士や司法書士に相談できる窓口があったのに、このシステムをどうするかだけは、誰にも相談できずに一人で抱えている——そういう二代目・三代目の経営者だ。

先代の作った仕組みは「悪」ではない、という前提から始める

まず誤解を解いておきたい。先代が作った、あるいは先代の時代に導入したシステムが「古いから悪い」という話ではない。むしろ、当時の業務量と予算と技術水準の中で、よく工夫して作られているケースが多い。Excelの請求書テンプレートに複雑な数式が組まれていたり、Accessでオリジナルの在庫管理データベースが作られていたりするのは、それだけ先代や現場の担当者が「自社の業務に合わせよう」と工夫してきた証拠でもある（Accessで作られたシステム特有の限界と移行先の選び方はAccessで動く先代の業務システムの限界と移行先の選び方を参照）。

だから承継した経営者がまずやるべきは、「こんな古いものは全部捨てて最新にしよう」と勢いで決めることではない。逆に「先代が作ったものだから」と手を触れずに神棚に上げてしまうことでもない。冷静に「このシステムは、あと何年もつのか」「もし今日壊れたら、会社の業務はどれくらい止まるのか」を数字と事実で確認する作業だ。判断は感情ではなく点検から始まる。

なぜ承継のタイミングで「システムの棚卸し」が起きにくいのか

株式の承継には税理士が、登記の変更には司法書士や行政書士がつく。融資の借り換えには銀行の担当者がつく。ところが、日々の業務を支えているシステムやExcelファイルについては、承継の場でほとんど話題にならない。中小企業庁がまとめた中小企業白書でも、事業承継時の主要な論点として経営権の移転や後継者の確保、資金調達が繰り返し取り上げられる一方、基幹システムの老朽化リスクが承継プロセスの中で明示的に点検項目として扱われることは多くない。

2023年時点の後継者不在率は54.5％。2025年までに約245万人の経営者が70歳に達する見込みとされている（中小企業庁「2024年版中小企業白書」）。

つまり、これから数年で大量の経営交代が起きる中で、その多くの現場で「先代のシステムをどうするか」という問いが後回しにされたまま進んでいる可能性が高い。承継の専門家は大勢いても、システムの承継について相談できる相手は身近にいない。この記事で扱いたいのは、まさにその空白地帯の話だ。

判断基準1：そのシステムを触れる人は社内に何人いるか

延命か作り直しかを判断する最初の基準は、費用でも見た目の古さでもない。「今、そのシステムの中身を理解して、修正やトラブル対応ができる人が何人いるか」という数字だ。

答えが「1人」、あるいは「もう退職した先代しかわからない」であれば、それはすでに経営リスクとして赤信号が灯っている状態だと考えたほうがいい。この「特定の担当者しか扱えない状態」は属人化と呼ばれる。属人化したシステムは、その人が病気で倒れる、辞める、あるいは単に休暇を取るだけで、業務が止まる可能性を抱えている。

• 経理の請求書発行が、ベテラン社員のPCに入ったExcelマクロに依存している
• 在庫管理のAccessデータベースを直せるのは、10年前に作った先代だけ
• 受発注システムの設定変更を、退職済みの元従業員に今も外部委託で頼んでいる

こうした状態は、システムそのものの新旧にかかわらず、単独で「作り直しを検討すべきサイン」になる。逆に言えば、多少古いシステムでも、複数の社員がマニュアルを見ながら保守でき、外部のベンダーとも連絡が取れている状態なら、慌てて作り直す必要はない。

判断基準2：土台のサポートはいつまで続くのか

2つ目の基準は、システムが乗っている「土台」——OS、業務ソフト、開発言語やフレームワーク——のサポート期限だ。ソフトウェアやハードウェアには、メーカーや開発元が「これ以降は修正プログラムやセキュリティパッチを提供しません」と宣言する期限がある。これをEOL（サポート終了）（End Of Life、サポート終了）と呼ぶ。

サポートが終了した土台の上で動くシステムは、次の3つの問題を抱える。

1. 新しく見つかったセキュリティの穴が塞がれないまま放置される
2. 周辺機器やソフトが新しいバージョンに対応しなくなり、連携できなくなる
3. 何かあったときに「サポート対象外なので対応できません」と業者に断られる

自社のシステムが依存しているOSやソフトのサポート期限がいつなのかを、経営者自身が把握できているかどうかは重要な分岐点だ。「詳しいことは業者に聞かないとわからない」という状態であれば、まずそこを確認するところから始めるべきだろう。サポート期限まで数年ある場合は延命の選択肢が現実的だが、すでに期限を過ぎている、あるいは1年以内に迫っている場合は、作り直しの検討を先送りする理由がなくなる。

判断基準3：壊れたときに直せる人が「外部にも」いるか

社内に詳しい人がいなくても、外部の開発会社やSIerに依頼すれば直せる、という状態であれば、まだ延命の余地はある。問題は、そのシステムを作った会社がすでに廃業していたり、使われている技術があまりに古く、対応できる技術者が市場にほとんど残っていなかったりするケースだ。こうした「これ以上古い技術に手を出せる人が見つからない」システムは、レガシーシステムと呼ばれる領域に入っている。経済産業省が主導した「レガシーシステムモダン化委員会」の2025年5月の総括レポートでも、複雑化・老朽化・ブラックボックス化した既存システムがDX推進の足かせになっている問題が改めて指摘されている。同省が2018年に公表した「DXレポート」では、2025年以降、老朽化した基幹システムが放置された場合、年間最大12兆円の経済損失が生じる可能性があるという試算も示された。

大企業だけの話ではない。中小企業の現場でも、「作った業者が倒産していて連絡が取れない」「独自にカスタマイズされすぎていて、他の業者が見ても手を出せない」という相談は珍しくない。こうした「作った会社と連絡が取れない」「触れる技術者が見つからない」状態は、システム引き継ぎ・レスキュー（運営会社ゼットリンカーの受託メニュー）が専門に扱う領域でもある。もし今、修理や改修を頼める外部の窓口を経営者自身が把握できていないなら、それ自体がすでに一つのリスクサインだ。VB6やDelphiで組まれたシステムはこの典型例で、具体的な見極め方はVB6・Delphi製の先代システムはいつまで動くか。移行タイミングの見極めに詳しい。オフコンや汎用機で動く基幹システムの場合はオフコンで動く先代の基幹システム、いつまで使い続けられるかを参照してほしい。

3つの基準をまとめると、こう整理できる

3つとも「延命でよい」側なら、今すぐ手をつける必要はない。ただし、2つ以上が「作り直し」側に振れているなら、それは先送りできる話ではなく、今期の経営課題として扱うべき水準に来ていると考えたほうがいい。

「延命」を選ぶという判断も、立派な経営判断である

ここで強調しておきたいのは、「延命」が悪い選択肢では決してないということだ。承継したばかりで資金繰りが読みにくい時期に、数百万円から数千万円規模の刷新投資に踏み切るのは、経営判断として無理筋なことも多い。3つの基準を確認した結果、社内に複数の対応者がいて、サポート期限にもまだ余裕があり、外部の相談先も確保できているのであれば、それは「まだ延命でよい」という立派な経営判断だ。

延命を選ぶ場合にやるべきことは、放置ではなくメンテナンスだ。具体的には、OSやソフトの更新プログラムを定期的に適用する体制を、特定の担当者任せにせず会社としてのルールにしておくこと。そして、今誰が何を触っているのかを一枚の表にまとめておくことだ。

この「延命=何もしない」という誤解は、承継直後の経営者が最も陥りやすい落とし穴の一つだ。延命という言葉には「今のままでとりあえず様子見」というニュアンスがあるが、本来の延命とは、限られたリソースの中で計画的にリスクを下げ続ける行為を指す。何もせず先延ばしにするだけの状態と、意図的に「今年はここまでで良い」と判断したうえでの延命は、見た目は同じでも中身がまったく違う。前者は数年後に必ずツケが回ってくるが、後者はその都度リスクの大きさを測り直しているため、状況の変化に早く気づける。

具体的なメンテナンス項目としては、次のようなものが挙げられる。

• OSやソフトウェアの更新プログラムを月次または四半期ごとに適用するスケジュールを組む
• ウイルス対策ソフトやファイアウォールの設定が最新の脅威に対応しているか、年に一度は外部の目でチェックしてもらう
• バックアップが実際に取れているか、そして復元できるかを定期的にテストする
• システムに関わる契約書・保守契約の有効期限を一覧にして、切れる前に更新可否を検討する

これらは決して大掛かりな投資を必要とするものではなく、多くは社内の運用ルールを整えるだけで実現できる。延命を選ぶという判断は、「何もしなくていい」という免罪符ではなく、「今はこの水準のメンテナンスで持ちこたえる」という具体的な計画とセットであるべきだ。

判断を先送りしたときに起きる、典型的な失敗パターン

延命でも作り直しでもなく、「決めないまま先送りする」ケースが実は一番多く、一番危険だ。典型的な失敗パターンを3つ挙げる。

• 詳しい担当者が突然退職し、誰も手が出せなくなってから慌てて業者を探す
• サポート終了後にセキュリティ事故が起き、取引先への説明対応に追われる
• 「そろそろ限界かも」と思いながら3年放置し、いざ作り直そうとしたら、もとのデータの構造すら誰も説明できず、移行作業が想定の2倍以上の期間とコストになる

これらはすべて、「判断する材料がなかった」のではなく「材料はあったのに、忙しさの中で先送りにされた」結果として起きる。承継直後の1〜2年は特に、株主総会や金融機関対応、社内の人心掌握など優先順位の高い仕事に追われがちだ。だからこそ、システムの点検は「余裕ができたらやる」ではなく、承継後できるだけ早い段階で一度着手しておくべき項目だと考えたい。

単一障害点という考え方で、リスクの所在を特定する

延命か作り直しかを考えるとき、便利な考え方がある。「もしこれが止まったら、会社のどこが最初に止まるか」を洗い出すことだ。この「そこが壊れると全体が止まってしまう一点」のことを単一障害点（SPOF）（単一障害点）と呼ぶ。

例えば、受発注のすべてが一つのExcelファイルに集約されていて、そのファイルの保存されているPCが1台しかない場合、そのPCの故障は即座に受発注業務全体の停止を意味する。逆に、複数の業務システムが分散していて、一つが止まっても他の業務は動き続けられる構造であれば、リスクは相対的に低い。

承継したばかりの経営者が最初にやるべき点検は、実は大掛かりなシステム刷新の検討よりも先に、この「単一障害点はどこか」を洗い出す作業かもしれない。棚卸しをしてみると、リスクが集中しているのはシステム全体ではなく、特定の一つのファイルや一台のPCだった、というケースは珍しくない。

先代に聞くべきこと、先代が答えられないこと

先代がまだ健在で相談できる立場にあるなら、承継のタイミングで必ず聞いておくべき質問がある。

• 「このシステムを作った会社・担当者は誰か。今も連絡が取れるか」
• 「導入した年はいつか。何か大きな改修をしたことはあるか」
• 「今、困っていることや、いつか直したいと思っていたことはあるか」

ただし、先代であっても答えられないことがある、という点は理解しておいたほうがいい。多くの先代経営者は、システムの導入を「当時の担当者や業者に任せていた」というケースが大半で、技術的な中身までは把握していないことが多い。先代に聞けば全てがわかる、と期待しすぎると、承継後に「聞いておけばよかった」と後悔することになりかねない。だからこそ、先代の記憶に頼るだけでなく、契約書や見積書、マニュアルなど「残っている記録」を一緒に探しておくことが重要になる。

「動いているから大丈夫」という感覚のズレ

承継したばかりの経営者が最初に抱きがちな感覚は、「今日も普通に動いているのだから、当分は大丈夫だろう」というものだ。この感覚は半分正しく、半分間違っている。

正しい部分は、実際に日々の業務が回っているという事実そのものは軽視すべきではないという点だ。動いているシステムを、根拠なく「古いから危険」と決めつけて不安を煽るのは適切ではない。

一方で間違っている部分は、「動いている」という状態と「壊れない」という保証はまったく別物だという点だ。老朽化したシステムは、多くの場合、壊れる前触れなく突然止まる。部品の摩耗のようにゆっくり劣化していくハードウェアと違い、ソフトウェアは「昨日まで問題なく動いていたのに、今日突然エラーで止まる」という形で不具合が表面化することが多い。特定のデータ量を超えた瞬間に処理が固まる、特定の日付をまたいだ瞬間に計算が狂う、といった形で、何の前触れもなく牙をむく。

だからこそ、「今日動いているかどうか」ではなく、「あと何年、何の保証もなく動き続けることを期待するのか」という問いに置き換えて考える必要がある。これは楽観でも悲観でもなく、単なるリスクの見積もりの話だ。

古参社員との関係が、判断を難しくすることもある

システムの延命か作り直しかという判断が難しいのは、技術の問題だけが理由ではない。長年そのシステムを使い、あるいは作り込んできた古参社員との関係が絡むからだ。

経理担当のベテラン社員が20年かけて磨き上げたExcelの仕組みを、新しい社長が「もう古いから作り直します」と一方的に宣言すれば、その社員は自分の仕事のやり方を否定されたと感じるかもしれない。逆に、その社員が定年退職を控えているのに、後任への引き継ぎもないままシステムだけが残っていく状況を放置すれば、退職と同時に会社は「誰も触れないシステム」を抱えることになる。

この場合の現実的な進め方は、「作り直すかどうか」をいきなり切り出すのではなく、「もしものときのために、今の仕組みを一緒に整理させてほしい」という頼み方から入ることだ。古参社員の工夫やノウハウを否定するのではなく、それを言語化して記録に残す作業として位置づければ、協力を得やすくなる。承継とはつまるところ、システムだけでなく、そこに込められた人の仕事のやり方を引き継ぐことでもある。「動いているから触るな」と言われるシステムに安全に手を入れる具体的な手順は、「動いているから触るな」と古参社員に言われるシステムの安全な改修手順にまとめている。

「延命」の中身は一様ではない、という注意点

延命と一口に言っても、その中身にはグラデーションがある。何もせず現状維持するだけの延命と、リスクを減らしながら使い続ける延命では、その後の安心感がまったく違う。

例えば、Excelで作られた業務フローの一部を、より構造的なデータ管理ができるツールに段階的に移行するというのも、フルスクラッチでの作り直しに至らない、中間的な延命策の一つになりうる。あるいは、複雑に組まれたマクロや数式を、担当者以外にも読めるようにコメントを付けて整理し直すだけでも、属人化のリスクは大きく下がる。「全部作り直すか、何もしないか」の二択ではなく、その間にある選択肢を検討する余地は、思っている以上に広い。

中間的な延命策には、次のようなグラデーションがある。

1. 記録だけを整える延命 — 中身は一切変えず、誰が何を触っているか、どこにリスクがあるかを文書化するだけ
2. 部分的に手を入れる延命 — もっともリスクの高い箇所だけ、担当者を増やしたり、処理を簡素化したりする
3. 土台だけ入れ替える延命 — 業務ロジックは維持したまま、動作環境(パソコンやOSなど)だけを新しくして延命期間を延ばす
4. 段階的な部分刷新 — 業務全体ではなく、特定の一機能だけを新しいシステムに置き換える

この4段階のどこまで踏み込むかは、資金力とリスクの大きさのバランスで決めればよい。重要なのは、「延命」と「作り直し」を対立する二つの選択肢としてではなく、連続したグラデーションの中のどこに自社が今いるのかを把握しておくことだ。

資金調達の場面でも「システムの状態」は見られている

延命か作り直しかという判断は、社内の業務効率だけの問題ではない。金融機関から融資を受ける場面や、将来的にM&Aや第三者承継を検討する場面でも、実はシステムの状態は思っている以上に見られている。

例えば、決算書や試算表の数字の正確性は、その裏側にある経理システムやExcelの信頼性に直結する。属人化した仕組みで数字が作られている会社は、担当者が変わった途端に数値の整合性が崩れるリスクを抱えており、金融機関の融資審査担当者や、M&Aの場面でのデューデリジェンス(買収監査)を行う専門家は、こうした「数字を作る仕組みそのものの脆さ」にも目を配っている。

将来、会社をさらに次の世代へ引き継ぐとき、あるいは第三者への譲渡を検討するときになって、「システムがブラックボックスで、誰も業務フローを説明できない」状態が発覚すれば、それは会社の評価そのものを下げる要因になりかねない。逆に言えば、システムの状態を記録し、リスクを把握し、計画的に手を打っている会社は、それ自体が「経営がきちんと管理されている会社」であることの証明にもなる。延命か作り直しかという判断は、目先の業務効率だけでなく、数年先の資金調達や会社の将来価値にも静かに影響している。

承継後、最初の1年でやっておきたいこと

ここまでの内容を踏まえ、承継後の最初の1年間で優先的に着手すべきことを整理しておく。

1. 社内にあるシステム・Excelファイルの棚卸し — 何がどこにあり、誰が管理しているかをリストアップする
2. 各システムの対応可能人数の確認 — 属人化しているものがどれかを洗い出す
3. 土台のサポート期限の確認 — 業者や社内の詳しい担当者に確認し、期限が近いものを優先順位付けする
4. 外部の連絡先が生きているかの確認 — 開発を委託した会社が今も営業しているか、契約が有効かを確認する
5. 単一障害点の特定 — 「これが止まったら会社が止まる」箇所を1つでも2つでも特定しておく
6. 先代への聞き取り — 先代が健在なうちに、導入経緯や困りごとを聞いておく

この6項目は、いずれも大きな予算を必要とするものではなく、多くは経営者自身の時間と、社内での聞き取りだけで進められる。逆に言えば、予算がないことは、この棚卸し作業を先延ばしにする理由にはならない。まず現状を把握するところから始め、そのうえで初めて「延命か、作り直しか」の判断ができる土台が整う。承継1年目にシステム面で何を優先すべきかの全体像は、ガイド会社を継いで1年目、システム面で最初にやることの優先順位も参考になる。

作り直しを選ぶ場合、最初に決めるべきこと

3つの判断基準を確認した結果、作り直しを選ぶことになった場合、次にやるべきは「いきなり全部を作り直す」計画を立てることではない。むしろ最初にやるべきは、優先順位づけだ。

会社の中には複数のシステムやExcelファイルが存在しているはずだが、すべてを同時に作り直す体力のある中小企業は多くない。単一障害点になっている箇所、サポート終了が迫っている箇所から順番に手を付けていくのが現実的だ。全体を一度に刷新しようとして計画が肥大化し、結局手つかずのまま数年が過ぎる、という失敗もよく見かけるパターンだ。

相談先がいない孤独感を、記録という形で解消する

承継した経営者の多くが感じているのは、株式や登記には専門家がいるのに、システムについては相談する相手がいない、という孤独感だ。これは決して大げさな話ではなく、システムの状態を専門的に評価し、承継のタイミングで一緒に棚卸しをしてくれる専門家の窓口は、税理士や司法書士に比べてまだ一般的とは言いがたい。

だからこそ、専門家を探す前にできることがある。それは、社内にある情報を一枚の記録としてまとめておくことだ。何のシステムがいつ導入され、誰が管理し、どの会社に依頼すれば直せるのか。こうした情報を一元管理しておけば、後から相談する外部の専門家に対しても状況を的確に説明できるようになる。逆にこの記録がまったくない状態で専門家に相談すると、状況把握だけで多くの時間と費用を消費してしまうことになりかねない。

記録として最低限まとめておきたい項目は、次の通りだ。

この表を一度作ってしまえば、毎年少しずつ更新するだけで済む。承継直後の忙しい時期にこそ、細かい聞き取りより先に、まずこの骨組みだけでも作っておく価値がある。専門家に相談する段になっても、この一枚があるだけで、初回の打ち合わせの中身が「状況把握」から「対策の検討」へと一段階進む。

判断基準を「一度きりの決断」にしない

もう一つ強調しておきたいのは、延命か作り直しかという判断は、一度決めたら終わりではないということだ。今年「延命でよい」と判断したシステムも、担当者の退職やサポート期限の到来によって、来年には状況が変わっている可能性がある。

そのため、この3つの判断基準は、一度きりのチェックリストとしてではなく、年に一度、あるいは半期に一度、定期的に見直す仕組みとして運用するのが望ましい。特に承継から数年間は、会社の体制も先代の記憶が残っている社員の状況も変化しやすい時期にあたる。定期点検の頻度を上げておくことは、決して過剰な用心ではない。

「新しい社長が全部変えたがる」という古参社員の警戒心

承継したばかりの経営者が、良かれと思ってシステムの話を切り出した瞬間、古参社員から思わぬ抵抗を受けることがある。「先代のときは何も問題なかった」「なぜ今さら変える必要があるのか」という反応だ。これは技術への無理解というより、変化そのものへの警戒心であることが多い。

新しい社長が代替わりのタイミングで組織や仕組みに手を入れようとするのは、ある意味で自然な流れだが、現場の社員からすれば「自分たちのやり方を否定された」「これまでの苦労を軽んじられた」と感じやすい局面でもある。とりわけシステムは、その社員が長年かけて使い方を覚え、工夫を積み重ねてきた「自分の持ち場」であることが多いため、心理的な抵抗は経営者が想像する以上に強く出ることがある。

この警戒心を和らげるために有効なのは、最初から「変える・変えない」を議論しないことだ。まずは「今の状態を知りたいだけ」という姿勢で、現状把握のヒアリングに徹する。そのうえで、点検の結果、本当にリスクが高い箇所が見つかったときに初めて、「このリスクをどう減らすか」を一緒に考える、という順番を踏む。いきなり結論から入らず、事実確認から入ることが、社内の協力を得るうえでの近道になる。

業種によって「延命の限界」は変わる

延命か作り直しかの判断は、業種によっても傾向が変わってくる。例えば、製造業で使われている生産管理システムや、卸売業の在庫管理システムは、取引先とのデータ連携が絡むことが多く、片方だけ古いままにしておくと、取引先のシステム更新に自社だけが追随できなくなるリスクがある。取引先からEDI(電子データ交換)の形式変更を求められたときに、自社のシステムが対応できず、結果として取引を打ち切られるといった事態も現実に起こりうる。

一方、社内で完結する経理処理や勤怠管理のようなシステムは、外部との連携が薄い分、多少古くても社内の判断だけで延命を続けやすい。ただし、その場合でも、税務や労務に関する法改正への対応が必要になるため、「法令が変わったときにアップデートできるか」という観点は忘れてはならない。

自社の業種において、システムの古さが取引先や規制対応にどう影響するかを考えることは、単純な「壊れるか壊れないか」の判断よりも、実務的には重要な視点になることが多い。

数字で見る、判断を先送りするコスト

判断を先送りすることのコストは、目に見えにくいだけに軽視されがちだ。しかし、社会全体で見ればその規模は小さくない。

経済産業省が2018年に公表した「DXレポート」は、複雑化・老朽化・ブラックボックス化した既存システムを放置した場合、2025年以降、最大で年間12兆円の経済損失が生じる可能性があると試算している。

この数字は大企業も含めた社会全体の試算であり、自社にそのままあてはまるものではない。しかし、老朽化したシステムを放置するコストが、多くの経営者が想像するよりもはるかに大きいという方向性そのものは、中小企業にも当てはまる教訓だと考えてよい。システムが止まったときの損失は、修理費用だけでなく、取引先への納期遅延、顧客からの信頼低下、社員の残業増加など、目に見えにくい形で会社全体にじわじわと広がっていく。

まとめ：判断に迷ったら、まず点検から始める

先代のシステムを延命するか作り直すかは、思想や好みの問題ではなく、事実を集めれば答えが見えてくる種類の判断だ。

1. 社内で対応できる人が何人いるか
2. 土台のサポート期限がいつまでか
3. 外部の対応可能な業者が確保できているか

この3つを確認し、2つ以上が危険信号であれば、作り直しを検討する時期に来ている。逆に3つとも問題がなければ、今は延命でよく、無理に投資する必要はない。大切なのは、この判断を先代の記憶や自分の勘に頼るのではなく、記録として残し、定期的に確認できる状態にしておくことだ。株式や登記の引き継ぎに専門家がついたのと同じように、システムの引き継ぎにも、事実に基づいた点検の習慣を持ち込んでほしい。

よくある質問

Q1. 先代に「システムのことは業者に任せてある」と言われました。それ以上何を確認すればいいですか。

「その業者は今も営業しているか」「連絡先は今の連絡先簿に載っているか」「契約は今も有効か、それとも過去に一度きりの導入契約で終わっているか」の3点を確認してほしい。中小企業のシステム導入では、開発を担当した会社や個人事業主がすでに廃業・引退しているケースは珍しくなく、「業者に任せてある」という言葉が、実際には「もう誰も対応できない」状態を指していることがある。

Q2. 古参の経理担当者が作ったExcelのマクロが複雑すぎて、誰も中身を理解していません。今すぐ作り直すべきでしょうか。

すぐに作り直すかどうかの前に、まず「その担当者が急にいなくなったら、業務は何日止まるか」を試算してみてほしい。数日で済むなら緊急度は中程度だが、「請求書が一切出せなくなる」といった致命的な影響が出るなら、それは単一障害点であり優先度は高い。作り直しの計画を立てる間にも、まずはその担当者にマクロの処理内容を書き出してもらう、簡単な引き継ぎ資料を作るなど、応急的な対応から始めるのが現実的だ。

Q3. 作り直すとなると費用も期間もかかりそうで、承継直後の資金繰りでは踏み切れません。

作り直しの検討イコール、全システムの一斉刷新ではない。単一障害点になっている箇所やサポート終了が近い箇所から優先順位をつけて、部分的に手をつける方法もある。まずは無料または低コストでできる「現状の棚卸しと記録化」から始め、投資判断はその結果を見てから段階的に行う進め方が、資金繰りへの負荷を抑えるうえで現実的だ。

Q4. 判断基準の3つのうち、1つだけが危険信号の場合はどう考えればよいですか。

1つだけであれば、直ちに作り直しに動く必要はないことが多いが、放置してよいわけではない。例えば「土台のサポートはまだ数年ある」が「社内の対応者が1人しかいない」場合、システム自体の作り直しより先に、その1人に依存している状態を解消すること（マニュアル化、複数人での運用体制づくり）を優先すべきだ。危険信号が1つでも、それがどの基準かによって取るべき対応が変わる、という点を意識してほしい。