VB6・Delphi製の先代システムはいつまで動くか。移行タイミングの見極め

結論から言う。VB6やDelphiで組まれた先代の業務システムは「今すぐ壊れる」ことはまずないが、「安心して使い続けられる期限」はすでに過ぎている。動いているという事実と、安全に使い続けられるという事実は別物だ。見極めるべきは「壊れるかどうか」ではなく、「壊れたときに直せる人がいるかどうか」「土台のWindowsが更新され続けているかどうか」の2点であり、この記事ではその判断基準を数字と一次情報で具体的に示す。

こんな読者を想定している。先代が20年前に個人事業主のエンジニアに発注して作らせた受発注システムが、いまだにVB6かDelphiで動いている。担当していた開発会社はとうに廃業したか連絡が取れず、パソコンの調子が悪くなるたびに古参の総務担当が「だましだまし」再起動している。誰も中身を触れないが、日々の受注・出荷・請求はそのシステムなしには回らない。そんな状態で、経営承継を機にこのシステムをどうするか考え始めた人に向けて書く。

なぜ今、この話をするのか

VB6は2008年にマイクロソフトの公式サポートが完全に終了している。すでに18年が経過した計算だ(参照: c3index「VB6移行ガイド【2026年版】」)。Delphiは製品の系譜自体は現在も続いているものの、多くの中小企業で稼働しているのは10年以上前のバージョンで書かれた資産であり、当時の開発環境も担当者もすでに手元にないケースがほとんどだ。つまり「作った人・売った会社・直せる知識」の3つが同時に失われつつある、というのが2026年時点の実情である。

先代が元気なうちは「あのシステムは大丈夫、〇〇さんに聞けば直る」で済んでいたかもしれない。しかし承継した今、その「〇〇さん」が現役を退いていたり、会社ごと畳んでいたりすることは珍しくない。相談窓口が消えた状態で老朽化したシステムだけが残る、というのが承継後によく起きる構図だ。

VB6・Delphiという2つの技術の違いを整理する

まず前提として、VB6とDelphiは似ているようで性質が異なる。ひとまとめに「古い言語だから危ない」と考えるのではなく、それぞれの特徴を押さえておきたい。

VB6とDelphiという2つのレガシー技術の違いを、対応可能技術者・移行のしやすさなどの観点で対比する比較図。

  • VB6: マイクロソフトが1998年に発売、2008年にサポート終了。実行環境(ランタイム)はWindows 10/11でも動作するが、あくまで「ベストエフォート」扱いであり、不具合が出てもマイクロソフトは修正しない。
  • Delphi: Embarcadero社(旧Borland)が開発を継続しており、最新版は今も販売されている。ただし中小企業で稼働している資産の大半は2000年代〜2010年代前半のバージョンで書かれており、当時の開発者や設計書が失われているケースが多い。
  • 共通点: どちらもWindowsのAPIやコンポーネントに強く依存した「デスクトップアプリ」の作り方をしており、クラウドやスマートフォンを前提にしていない。

つまりVB6は「言語自体がすでに終わっている」、Delphiは「言語は生きているが、あなたの会社の資産は取り残されている」という、似て非なる終わり方をしている。この違いを理解しておくと、後述する移行の緊急度判断がぶれにくくなる。

「動いている」は安全の証明にならない

先代からシステムを引き継いだ社長が最初にはまる罠が、「今日も動いているから大丈夫」という判断だ。しかしこの判断には見落としがある。

システムが「壊れていない」ことと、「これから起きるリスクに対応できる」ことはまったく別の話である。動作の継続性は過去の実績にすぎず、将来のセキュリティ脅威やハードウェア故障に対する耐性を何ら保証しない。

VB6やDelphi製のシステムが今日動いているのは、単に「まだ大きな事故が起きていないから」にすぎない。土台となるWindowsやパソコン本体の寿命、セキュリティパッチの供給状況といった外部要因が変わった瞬間に、何の前触れもなく止まる可能性がある。これは典型的なレガシーシステム(レガシーシステム)の状態であり、承継のタイミングでこそ点検すべき対象だ。

見極めの軸1:土台となるOSのサポート状況

VB6・Delphi本体のサポートがどうであれ、それを動かしているWindowsのサポート期限は動かない事実として存在する。ここが最も客観的で、社長自身にも判断しやすい基準になる。

OSサポート状況・PCの物理的寿命・対応技術者の有無という3つの軸から移行タイミングを判断する意思決定ツリー図。

Windows 10は2025年10月14日をもって公式サポートが終了した(参照: Microsoft公式「Windows 10コンシューマー向け拡張セキュリティ更新」)。業務PCでWindows 10を使い続ける場合、法人向けの延長セキュリティ更新プログラム(ESU)に有償で加入しない限り、新しいセキュリティパッチは提供されない。個人向けには無料延長の枠が用意されているが、これは家庭用の話であり、業務用パソコンにそのまま当てはめることはできない点に注意が必要だ(参照: 情シス365「Windows 10 個人向けESUが2027年10月まで1年延長」)。

さらに、すでにWindows 11に切り替えている会社であっても油断はできない。Windows 11のバージョン24H2は、Home・Proエディションで2026年10月13日(日本時間14日)に更新プログラムの提供が終了する予定であり、それ以降は25H2など新しいバージョンへの更新が必須になる(参照: Microsoft Learn「Windows 11、バージョン24H2の既知の問題と通知」)。つまり「OSを新しくしたから当面安心」というわけではなく、Windows自体が今後も数年おきにバージョンアップと期限切れを繰り返す運命にある。

VB6・Delphi製のアプリが新しいWindowsバージョンで正常に動く保証は年々薄れていく。OSがアップデートされるたびに「今回は動いた」を運任せで繰り返しているのが、多くの承継企業の実態だ。この状態は言い換えれば、システム全体がEOL(サポート終了)(サポート終了)を静かに迎え続けているということでもある。

見極めの軸2:動いているパソコンの物理的な寿命

もう一つの現実的な制約が、システムが稼働しているパソコン本体の寿命だ。業務用デスクトップPCの一般的な耐用年数は5年前後とされ、それを超えて稼働させ続けているケースは、ハードディスクやマザーボードの経年劣化による突然の故障リスクが高まる。

厄介なのは、古いVB6・Delphiアプリの中には、特定のOSバージョンや古い周辺機器のドライバに強く依存しているものがあり、「壊れたパソコンを買い替えたら、新しいパソコンでは同じソフトが動かなかった」という事態が起こりうることだ。これは単なる部品交換では済まず、システムそのものの延命限界を意味する。

  • 今のパソコンが壊れたら、同じ環境を再現できるか
  • 予備のパソコンや、同じOSバージョンのバックアップ機は用意してあるか
  • インストールに必要なライセンスキーやインストーラーは今も手元にあるか

この3つに即答できない会社は、パソコン1台の故障がそのまま業務停止に直結する。これはまさに単一障害点(SPOF)(単一障害点)の状態であり、その1台に会社の受発注や請求業務のすべてが依存している構造そのものが最大のリスクだ。

見極めの軸3:直せる人が社内・社外にいるか

技術的な期限と並んで重要なのが、「人」の観点だ。VB6・Delphiの開発経験者は年々減っており、新卒や若手のエンジニアでこれらの言語を専門的に学んでいる人はほとんどいない。結果として、既存のVB6・Delphi資産を保守できる技術者の市場価格は下がるどころか、希少性ゆえにむしろ上がっている、という逆転現象が起きている。先代の時代には「知り合いの技術者に頼めば何とかなった」システムが、承継後には「そもそも誰に頼めばいいか分からない」システムに変わっている。これは技術の問題である以上に、属人化した人間関係が承継とともに切れてしまうという、承継企業特有の脆弱性だ。

以下のチェックリストで、自社の「人のリスク」を確認してほしい。

  • [ ] 開発を担当した会社・個人と、今も連絡が取れる
  • [ ] ソースコード一式が自社の管理下にある(開発会社にしかない状態ではない)
  • [ ] 社内に、システムの中身をある程度把握している社員が最低1人いる
  • [ ] その社員が退職・異動しても引き継げるドキュメントがある
  • [ ] 過去の改修履歴や仕様変更の記録が残っている

このうち2つ以上に該当しない(チェックが付かない)場合、すでに「直せる人がいない」状態に片足を突っ込んでいると考えたほうがよい。

古参社員との関係という、もう一つの変数

承継企業においてVB6・Delphiシステムの扱いを難しくしているのが、そのシステムの操作に習熟した古参社員の存在だ。経理担当のベテラン社員が「この画面のこの順番で入力すれば動く」という独自の手順を長年守ってきており、その暗黙知がシステムの不具合や癖を事実上カバーしているケースは少なくない。

これは表面的には安定稼働に見えるが、実態は属人化が二重にかかった状態だ。システムの中身が分かる技術者がいない「技術の属人化」と、そのシステムの使い方が分かる社員が一人しかいない「運用の属人化」が同時に存在している。この社員が定年退職やケガで長期離脱した瞬間、システムは技術的には動いていても実質的に使えなくなる。先代の時代からこの社員に頼り切ってきた経緯がある場合、後継社長がシステムの話を切り出すこと自体に気を遣う場面もあるだろう。しかし「あなたの仕事を奪う話ではなく、あなたしかできない状態を減らして会社を守る話だ」という説明は、古参社員の協力を得るうえで有効だ。実際に移行プロジェクトを進める際も、古参社員への丁寧なヒアリングは要件定義の質を大きく左右する。

移行を先延ばしにした場合に何が起きるか

ここまでの3つの軸(OSサポート、ハードウェア寿命、人材)が同時に悪化していくとどうなるか、時系列でイメージしておきたい。

時期の目安起きうる事態
現在動いてはいるが、パッチも保守も新規に提供されない「凍結状態」
1〜2年後パソコンの経年劣化が進み、突発的な故障リスクが上昇
故障発生時同一環境の再現が困難になり、代替機への移行に想定外の時間がかかる
並行して対応できる技術者がさらに減り、緊急対応の外注費用が高騰
最悪のケースシステム停止により受発注・請求・出荷などの基幹業務が一時停止

経済産業省が2018年に警鐘を鳴らした「2025年の崖」は、レガシーシステムを放置した場合に発生しうる経済損失を試算したものだったが、2025年を過ぎた現在も、従業員100人以下の中小企業のDX取組率は46.9%にとどまり、老朽化したシステムを抱える企業は依然として多いことが指摘されている(参照: IPA「DX動向2025」)。「崖」は一度きりのイベントではなく、対応を先延ばしにした企業に対して静かに、しかし確実に迫り続けている坂道だと捉えたほうが実態に近い。

移行タイミングを判断する3つのシグナル

では、具体的にいつ動き出すべきか。以下の3つのシグナルのうち、いずれか1つでも当てはまったら、移行の検討を始めるタイミングだと考えてよい。

シグナル1: OSの大型サポート終了が1年以内に迫っている Windows 10のサポートはすでに終了し、Windows 11も24H2が2026年10月に期限を迎える。今使っているOSのサポート終了時期を確認し、1年を切っていれば計画を立て始める段階だ。

シグナル2: パソコンが導入から5年以上経過している 物理的な故障はある日突然やってくる。5年を超えたら「壊れたら移行する」ではなく「壊れる前に移行の準備を終えておく」意識に切り替える必要がある。

シグナル3: システムの中身が分かる人が社内外に1人もいない、または1人しかいない 最後の1人が退職・引退する前に動くべきだ。この状態で放置すると、いざというときの選択肢が「業者に丸投げでゼロから作り直す」しか残らず、時間もコストも最大化する。

「今すぐ全部作り直す」以外の選択肢もある

移行というと「全部を最新のクラウドシステムに置き換える」という大工事をイメージしがちだが、実際にはいくつかの段階的な選択肢がある。承継後の資金繰りやリソースを考えると、いきなり全面刷新に踏み切るのが正解とは限らない。

  1. 延命措置: バックアップ体制の強化、予備パソコンの確保、ソースコードの所在確認など、コストをかけずにリスクだけを下げる応急処置
  2. 部分置き換え: 最もリスクが高い機能(例えば請求書発行や在庫管理など)だけを先に新しいクラウドサービスへ移し、それ以外は当面VB6・Delphiのまま残す
  3. 並行稼働: 新旧システムを一定期間並行させ、データ突き合わせをしながら段階的に移行する
  4. 全面刷新: 業務フロー自体を見直しながら、最新技術でゼロから作り直す

どの選択肢を取るにせよ、最初にやるべきことは「今何が動いていて、誰が管理していて、いつまで持つのか」を一覧化することだ。承継企業の多くはこの一覧自体が存在しないため、移行の意思決定以前に、まず現状把握から始める必要があるケースがほとんどだ。延命か作り直しかという判断そのものの軸については、先代のシステムを「延命するか、作り直すか」の判断基準でさらに詳しく整理している。

専門家がいない孤独をどう埋めるか

株式や登記の承継であれば、税理士・司法書士・弁護士といった専門家が当然のように付いてくる。ところがシステムの承継については、相談する専門家の存在自体が知られていない。先代から「あのシステムのことは〇〇さんに任せてある」とだけ伝えられ、実際にその「〇〇さん」がどこまで信頼できる相手なのか、他の選択肢はないのか、を検証する術がないまま何年も過ぎていく社長は多い。

この孤独感は、システムの中身が「ブラックボックス」であることに起因する。何が分からないのかすら分からない状態で、業者から出てくる見積もりや説明を鵜呑みにせざるを得ない。この状態を脱する最初の一歩は、専門用語を丸暗記することではなく、「今のシステムはいつまでの寿命なのか」「壊れたら何が止まるのか」という、経営判断に直結する問いに答えを持つことだ。本記事で挙げた3つの見極め軸は、その問いに答えるための最低限のチェックポイントとして使ってほしい。

セキュリティパッチが止まっているという静かなリスク

見落とされがちだが、VB6・Delphiそのもののサポート終了に加えて、多くの場合これらのシステムはOSやミドルウェアのセキュリティパッチも長期間当てられていない。事実上、パッチの適用管理が放棄されている状態だ。

パッチが当たっていないシステムは、既知の脆弱性が公開されたまま放置されることになり、外部からの攻撃対象になりやすい。取引先とのデータのやり取りがある場合、自社のシステムが踏み台にされて取引先にまで被害が及ぶリスクもゼロではない。「うちは古いシステムを使っているだけで、狙われるような会社じゃない」という考えは、攻撃者にとっては無防備な標的を意味するにすぎない。パッチが止まっているという事実は、動作の見た目には現れないぶん、経営者が意識的に確認しにいかない限り気づけないリスクである。

承継直後だからこそ動きやすい理由

逆説的だが、承継直後というタイミングは、システム移行を切り出すには実は好都合な時期でもある。先代の時代には「今のままでいい」という空気が長年の慣性で維持されてきたかもしれないが、新社長が交代のタイミングで「会社の仕組みを一度点検する」と説明すれば、古参社員や取引先にも自然に受け入れられやすい。

また、承継のタイミングで金融機関や取引先との関係を見直す会社も多く、その延長でIT投資の相談を切り出しやすい面もある。事業承継期の設備投資・システム投資を後押しする公的支援策が用意されている年度もあるため、利用できる制度がないか商工会議所や顧問税理士に確認してみる価値はある。

VB6・Delphiシステムに潜みやすい「見えない依存」

移行タイミングを見極めるうえで、社長自身が意外と気づいていないのが、VB6・Delphi製システムが抱える「見えない依存関係」だ。デスクトップアプリとして作られたこの世代のシステムは、単体で完結しているように見えて、実際には周辺の様々な仕組みと密接に絡み合っている。

  • ローカルのデータベースファイル: Accessや古いバージョンのSQL Serverなど、システム本体とは別のデータベースソフトにデータが保存されているケースが多い。データベースソフト自体が別途サポート終了を迎えていることもあり、アプリとデータベースの両方の寿命を同時に確認する必要がある。
  • 専用の帳票・印刷ドライバ: 請求書や納品書の印刷に、特定のプリンタドライバやレイアウト定義ファイルが必要な場合がある。プリンタを買い替えた瞬間に印刷レイアウトが崩れる、という事故はこの世代のシステムで頻発する。
  • 周辺機器との連携: バーコードリーダー、ハンディターミナル、FAXモデムなど、今では入手困難な周辺機器とシリアル通信やUSB接続で連携しているケースもある。周辺機器が故障すると、後継機種との互換性がないままシステムだけが取り残される。
  • Excel・Wordとの連携マクロ: システムから出力したデータをExcelマクロで加工して初めて完成する帳票、というような「システムの外側」に隠れた処理が存在することも多い。これらは個々の担当者のパソコンにひっそりと存在し、システム本体の移行対象から漏れやすい。

これらの依存関係は、システムの仕様書には書かれていないことがほとんどだ。仕様書自体が存在しない、あるいは開発当初のバージョンのまま更新されていないケースも珍しくない。移行を検討する際は、システム本体だけでなく、その周囲に何が繋がっているかを実際の業務フローに沿って洗い出す作業が欠かせない。この洗い出しを怠ったまま新システムに切り替えると、「新しいシステムは動くが、いつも使っていた帳票が出せなくなった」という形で、移行後にトラブルが表面化する。

Accessと組み合わさっているケースは特に注意

VB6・Delphi製システムの中には、画面や処理ロジックはVB6・Delphiで書かれていても、データの保存先はマイクロソフトのAccessという組み合わせが少なくない。中小企業でAccessが好まれた背景には、Excelの延長で扱える手軽さと、当時のコストの安さがあった。

しかしAccess(データベースソフト)は、同時アクセス数が増えるとデータ破損のリスクが高まる、ファイルサイズに実務上の上限がある、といった構造的な制約を抱えている。VB6・Delphiのフロント部分の老朽化だけでなく、裏側のAccessデータベースそのものが業務量の増加に耐えられなくなっているケースもある。移行を検討する際は、「画面をどう作り替えるか」だけでなく「データの持ち方自体を見直すべきかどうか」も合わせて点検してほしい。データベース部分を含めて刷新する場合、単純な画面の作り替えよりも設計工数が増えるため、見積もりの精度にも影響してくる。Accessそのものの限界と移行先の選び方はAccessで動く先代の業務システムの限界と移行先の選び方で詳しく扱っている。

移行費用の考え方:ゼロか全部かではない

承継したばかりの社長が身構えてしまう理由の一つに、「システム移行は数百万円、数千万円かかる大工事」という漠然としたイメージがある。たしかに業務フロー全体を巻き込む全面刷新であれば、規模や機能の複雑さ次第でそれなりの投資になる。しかし、前述した「部分置き換え」や「並行稼働」といった段階的なアプローチを取れば、初期投資を抑えながらリスクの高い部分から着手することができる。

判断材料として持っておきたい視点は以下の3つだ。

  1. 止まったら被害が一番大きい機能はどれか(受注・請求・在庫など、金銭や顧客に直結する部分から優先する)
  2. 今のシステムのままでもあと何年は明確に持つのか(OSサポート期限やハードウェア年式から逆算する)
  3. 一度に全部やるのと、数年かけて段階的にやるのとで、総コストにどれだけ差が出るか(業者に概算だけでも複数パターンで出してもらう)

いきなり「全部でいくらですか」と聞くのではなく、「まずこの機能だけ移行するといくらですか」という聞き方をすることで、身の丈に合った投資判断がしやすくなる。承継直後で資金繰りに不安がある場合ほど、段階的なアプローチの検討価値は高い。

業者選びで気をつけたいこと

VB6・Delphiからの移行を依頼する業者を選ぶ際、承継社長が陥りやすい失敗が2つある。

一つは、「今のシステムに詳しい」という理由だけで、先代の代から付き合いのある同じ業者にそのまま丸投げしてしまうことだ。その業者が新しい技術に対応できるとは限らない。VB6・Delphiの保守はできても、クラウドやWebアプリケーションの開発経験が乏しい業者に刷新まで任せると、結局似たような古い作り方のシステムができあがってしまうことがある。

もう一つは、逆に「最新技術に詳しい」という理由だけで、業務内容を理解しないまま話を進めてしまう業者に依頼することだ。VB6・Delphiシステムには、長年の運用の中で蓄積された「その会社特有の業務ルール」がプログラムのあちこちに埋め込まれている。表面的な画面デザインだけを真似ても、この業務ルールを正しく引き継げなければ、移行後に現場が混乱する。

理想は、既存システムの解析経験があり、なおかつ現場へのヒアリングを丁寧に行う業者だ。相見積もりを取る際は、金額だけでなく「現行システムのどこをどう調査するのか」という調査工程の有無を確認するとよい。「動いているから触るな」と言われてきたシステムを安全に改修する具体的な手順は、「動いているから触るな」と古参社員に言われるシステムの安全な改修手順を参照してほしい。

承継後1年でやるべきことのロードマップ

ここまで挙げた見極めの軸やチェックリストを、実際にどの順番で手をつければよいか迷う社長も多いだろう。承継から1年間を目安にした大まかな流れを示す。

VB6・Delphi製システムの移行に向けた承継後1年間のロードマップを時系列で示す概要図。

時期やること
承継直後〜3ヶ月現状把握。稼働OS・パソコンの年式・対応可能な技術者の有無を一覧化する
3〜6ヶ月バックアップ体制の点検と強化。予備パソコンの確保、ソースコードの所在確認
6〜9ヶ月業者への相見積もり。段階的移行と全面刷新、両方のパターンで概算を取る
9〜12ヶ月最もリスクの高い機能から部分移行に着手、または刷新の実行計画を確定する

この流れはあくまで目安であり、OSのサポート期限が目前に迫っている場合はもっと早いペースで動く必要がある。逆に、パソコンもまだ新しく、対応できる技術者も確保できている場合は、慌てず数年かけて計画的に進める余地もある。重要なのは「何もしないまま1年が過ぎる」という状態だけは避けることだ。承継1年目にシステム面で何を優先すべきかの全体像は、ガイド製造業の承継1年目、生産管理システムの確認を後回しにしていい条件も参考になる。

経営者自身が最低限持つべき3つの問い

システムの専門知識がなくても、経営者として次の3つの問いに答えられる状態を目指してほしい。これができていれば、業者との会話でも主導権を握りやすくなる。

  • 「今のシステムが完全に止まったら、会社の何が、どれくらいの時間、止まるか」
  • 「今、このシステムの中身を説明できる人は、社内外に誰がいるか」
  • 「もし来月このシステムが動かなくなったら、今日から何をすればいいか」

この3つに即答できない状態であれば、それ自体が「まだリスクを把握できていない」というシグナルだ。逆にこの3つに答えられる状態を作ることこそが、移行の意思決定よりも先にやるべき、最初の一歩だと言える。

決算期や繁忙期を避けたスケジューリング

最後に、実務的な注意点を一つ付け加えておきたい。移行やシステム調査のプロジェクトは、決算期や年末年始の繁忙期と重なると現場の負担が一気に増す。経理担当者や現場社員へのヒアリングが必要な作業は、通常業務が落ち着いている時期を選んで着手するほうが、協力も得やすく、結果的にプロジェクトの完成度も上がる。承継直後で会社全体の年間スケジュールをまだ把握しきれていない場合は、古参社員に「一年でどの時期が一番忙しいか」を確認したうえで、逆算してシステム関連の作業時期を決めるとよい。急ぐべきリスクと、急がず段取りを整えるべき実務は分けて考える必要がある。

まとめ:先延ばしにする理由を「安心の証拠」にしない

VB6・Delphi製の先代システムが今日も動いていることは、決して安心の証拠ではない。それは単に、OSのサポート期限、パソコンの物理的寿命、対応できる技術者の存在という3つの偶然がまだ重なっていないだけの、時間限定の平穏にすぎない。

  • Windowsのサポート期限は待ってくれない
  • パソコンは経年劣化する
  • 直せる人は増えることなく減っていく

この3つが同時に悪化する前に、まず「いつまで持つのか」を可視化することから始めてほしい。全面刷新を急ぐ必要はないが、現状把握を先延ばしにする理由はどこにもない。承継したのは会社の看板と取引先との信頼だけでなく、目に見えないシステムのリスクも含まれている、という認識を持つことが、見極めの出発点になる。

先代が築いた会社を守るという点では、システムの延命も刷新も本質的には同じ目的を持っている。どちらを選ぶにせよ、選択の理由を自分の言葉で説明できる状態にしておくことが、承継社長としての責任の果たし方の一つだと言える。今日、パソコンの型番とOSのバージョンを一つ確認するところから始めてもいい。その小さな一歩の積み重ねが、数年後に会社を守ることになる。

よくある質問

Q1. VB6やDelphiのシステムは、今すぐ止めないと危険なのでしょうか。 今日明日に必ず止まるという意味ではない。ただし、動いている土台のWindowsのサポートが順次終了しており(Windows 10は2025年10月に終了、Windows 11の24H2も2026年10月に終了予定)、パッチが提供されない期間が続くほどセキュリティリスクは積み上がっていく。「今すぐ全部止めて作り直す」よりも、まず自社のOSとパソコンの状態、対応できる技術者の有無を点検し、リスクの大きさを事実で把握することが先決だ。

Q2. 開発した業者が廃業していて連絡が取れません。どうすればいいですか。 まずソースコード一式やインストーラー、ライセンス情報が自社の手元(サーバーやパソコン内、外部記憶媒体)に残っているかを確認してほしい。ソースコードさえ確保できていれば、別の技術者による解析・引き継ぎの選択肢が残る。ソースコードすら見つからない場合は、動作しているアプリの画面や帳票、業務フローから仕様を逆算する「リバースエンジニアリング」的なアプローチが必要になり、通常の新規開発より難易度も費用も上がる点は覚悟しておく必要がある。開発会社と連絡が取れず、ソースコードやドキュメントがない状態からの調査・引き継ぎを専門に受け付ける会社(システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー)に相談する選択肢もある。

Q3. 費用をかけたくないのですが、何もしなくても大丈夫でしょうか。 「何もしない」という選択自体は可能だが、それはリスクを先送りしているだけで消しているわけではない。最低限、コストをほとんどかけずにできる対策として、システムの現状(稼働OS・パソコンの年式・対応可能な技術者の有無)を一覧化する、予備のパソコンや設定情報のバックアップを取る、といった延命措置がある。全面刷新は資金計画が整ってからでも遅くないが、現状把握とバックアップだけは早めに着手することを勧める。

Q4. 古参の担当者がシステムの使い方に詳しく、本人も特に困っていないと言っています。それでも移行を検討すべきですか。 検討すべきだ。担当者が「困っていない」のは、長年の経験でシステムの癖や不具合を無意識にカバーできているからであり、その担当者が不在になった瞬間に業務が止まるリスクは消えていない。これは技術的なリスクと同時に、属人化した運用のリスクでもある。移行の話を「あなたの仕事を否定するものではなく、あなたにしかできない状態を減らして会社全体を守るための取り組みだ」という形で伝えると、協力を得やすくなる。