「触ると壊れる」と先代に言われ続けたシステムを調査する順番

「触ると壊れる」と先代に言われ続けたシステムを調査する順番

先代が引退する数ヶ月前、あるいは引退してしまった後になって、こんな言葉が頭の中で何度も再生されていないでしょうか。「あのパソコンだけは絶対に触るな」「あのシステムは古いけど、触ると壊れるから触らないでくれ」。承継したばかりの社長の多くが、社内のどこかにこの「聖域」を抱えています。見積もりも、受発注も、在庫管理も、下手をすれば給与計算までもが、その「触ってはいけない」システムの中で動いている。

この記事は、そんな状態にある方——先代からシステムの詳細を教わらないまま経営を引き継ぎ、しかし社内の誰に聞いても「昔からこうだから」としか返ってこず、かといって外部のIT業者に何を相談すればいいのかもわからない、という方に向けて書いています。株式や登記の引き継ぎには税理士や司法書士という明確な相談先がありますが、システムの引き継ぎには相談先がありません。この孤独感こそが、多くの後継社長が最初にぶつかる壁です。

結論から言います。「触ると壊れる」システムは、いきなり触ってはいけませんが、いきなり放置してもいけません。やるべきことは、壊さずに「何がそこにあるのか」を調べる棚卸しです。そして棚卸しには、闇雲に手を付けるのではなく、リスクが高い場所から低い場所へと向かう合理的な順番があります（仕様書が一切ない場合の逆算調査は仕様書がない先代システムの仕様を、動きから逆算して復元する方法で扱っています）。この記事では、その順番と、承継特有の事情をふまえた調べ方を具体的に解説します。

なぜ「触ると壊れる」と言われたシステムほど後回しにできないのか

多くの後継社長は「動いているなら、とりあえず触らずに様子を見よう」と考えます。気持ちはよくわかりますが、これは順序として危険です。なぜなら「触ると壊れる」という言葉は、たいてい次の2つのどちらか、あるいは両方を意味しているからです。

1. そのシステムを深く理解している人間が先代しかおらず、他の誰も構造を説明できない（属人化）
2. ソフトウェアやOSがすでに古く、メーカーのサポートが切れている、あるいは切れかけている(いわゆるEOLの状態)

どちらのケースも、時間が経てば経つほど状況は悪化します。属人化は、唯一の理解者である先代の記憶が薄れたり、体調を崩したりすれば取り返しがつかなくなります。サポート終了は先送りにするほど代替システムへの移行が難しくなり、セキュリティ上の欠陥が放置されたまま業務が回り続けることになります。IPA(情報処理推進機構)の「中小企業の情報セキュリティ対策ガイドライン」でも、まず自社にどのような情報資産があるかを台帳で把握することが対策の出発点として位置づけられています。触らずに様子見を続けることは、実は最もリスクの高い選択なのです。

「うちは特別法律に触れるような使い方はしていないから大丈夫」という認識は危険です。サポートが切れたシステムは、法令違反の有無とは関係なく、脆弱性が修正されないまま外部と繋がり続けるという別のリスクを抱えています。

先代からすれば、「触ると壊れる」は悪意のある警告ではなく、長年の経験に基づいた率直な忠告だったはずです。ただしその忠告は「だから触るな」ではなく「だから雑には触るな、調べてから触れ」と読み替える必要があります。

そもそもなぜ先代は「触るな」としか言い残さなかったのか

引き継ぎの場で、先代が詳細な仕様書やマニュアルを渡してくれなかったことに、不満や不安を感じている方もいるかもしれません。ですが、これは先代が怠慢だったからとは限りません。多くの中小企業では、システムは「導入プロジェクト」としてではなく、「日々の業務をなんとか回すための応急処置の積み重ね」として育ってきました。

• 忙しい繁忙期に、とりあえず動く仕組みを誰かが作った
• その後、担当者が変わるたびに少しずつ改造が加えられた
• 「なぜこうなっているか」の理由は、その都度の担当者の頭の中にしかない
• 文書化する余裕もなく、次の繁忙期がやってくる

この積み重ねの果てにできあがるのが、外部から見ると意味不明な挙動をする、しかし社内では誰も疑問に思わない「いつものシステム」です。先代にとっては、その来歴を一から説明すること自体が大仕事であり、かつ「説明してもどうせ伝わらないだろう」という諦めもあったはずです。「触ると壊れる」は、複雑な経緯を省略した、いわば先代なりの最短の警告文だったと捉えると、聞き取りの際の態度も変わってきます。相手を責める材料にするのではなく、「経緯を一緒に掘り起こす」という姿勢で臨むことが、結果的に一番早く情報を引き出す近道になります。

承継直後にやってはいけない3つの行動

具体的な調査手順に入る前に、承継したばかりの社長が陥りやすい失敗を先に共有します。焦って動くと、かえって古参社員との関係や、先代との信頼関係を損なうことがあるためです。

• いきなり業者を呼んで刷新の相見積もりを取る: 現状把握より先に「入れ替え」の話を進めると、古参社員が「今のやり方を全否定された」と感じ、非協力的になります
• 先代に「なぜこんな古いシステムのままにしたのか」と詰める: 先代にも当時の事情(コスト、当時のベンダーの倒産、人手不足など)があります。詰問は情報を引き出す機会を自ら潰す行為です
• 経理・受発注などの本番データに直接触れて動作確認する: 壊れた場合の被害が実害に直結します。調査段階では「見る」と「動かす」を明確に分けてください

これらを避けたうえで、次に紹介する調査の順番に沿って進めます。

調査の順番の全体像

「触ると壊れる」システムの調査は、次の5段階の順番で進めるのが安全です。ポイントは、システムの中身をいきなり見に行くのではなく、まず「壊れたら困る度合い」を外側から見積もることから始める点にあります。

この順番の根底にあるのは「影響が大きいものほど早く、かつ最も慎重に扱う」という考え方です。以下、それぞれを詳しく見ていきます。

順番1: 業務への影響範囲を洗い出す(壊す前に「何が止まるか」を知る)

最初にやるべきは、システムそのものを調べることではなく、「そのシステムが止まったら、どの業務が止まるか」を紙に書き出すことです。たとえば以下のような整理です。

• 受発注システムが止まる → 出荷ができない → 顧客への納期遅延が即日発生する
• 給与計算のExcelファイルが壊れる → 今月の給与支払いが計算できない
• 顧客台帳のAccessデータベースが開けなくなる → 誰が何を買った顧客か分からなくなる

これは技術調査ではなく、経営者としての優先順位付けです。ITに詳しくなくても、社長であればこの整理は誰よりも正確にできるはずです。ここで「止まったら即詰む」システムが判明したら、それが単一障害点（SPOF）です。単一障害点は、バックアップも代替手段もなく、それが止まった瞬間に業務全体が止まってしまう箇所を指します。単一障害点だと分かった時点で、その調査の優先順位を最も高く設定してください。

逆に「止まっても半日〜1日は他の方法(手書き、電話)で代替できる」ものは、優先順位を落として構いません。この最初の仕分けをせずに手当たり次第調べ始めると、重要度の低いところに時間を使いすぎて、本当に危ないシステムの調査が後回しになりがちです。

順番2: 誰が何を知っているかを聞き取る(属人化の所在を可視化する)

次にやるのは、社内の人間関係の棚卸しです。「このシステム、詳しいのは誰ですか」を、経理担当、営業事務、現場責任者など、部署ごとに一人ひとりに聞いて回ります。ここで大事なのは、次の3種類を区別して記録することです。

1. 操作できる人: 日常的にキーボードを叩いて使っている人
2. 設定を変更できる人: マクロやAccessのクエリ、サーバーの設定などを触れる人
3. なぜそうなっているか経緯を知っている人: たいてい先代、または先代の代からいる古参社員

この3つは別人であることが多いのが中小企業システムの特徴です。日常操作は若い事務員ができても、VBAマクロの中身をいじれるのは退職した元社員だけ、という状況は珍しくありません。VBAマクロで組まれた請求書作成の仕組みなどは、作った本人以外誰も中身を理解していないケースが典型例です。

聞き取りの際は、古参社員に対して「先代のやり方が古い」というニュアンスを出さないよう注意してください。長年その仕組みを守ってきた自負がある社員も多く、聞き方次第では「今さら何を疑っているのか」と態度を硬化させてしまいます。

聞き取りの切り口の例:「これから会社を長く続けていくために、今のやり方を正確に記録として残しておきたい。教えてもらえますか」

先代自身への聞き取りも同様です。すでに引退している場合でも、月に一度顔を出してもらう、電話で30分だけ時間をもらうなど、可能な範囲で経緯を聞く機会を作ってください。先代がまだ現役で会社に残っている場合は、「壊すつもりはなく、記録に残したいだけ」だと明確に伝えることが、警戒心を解く最初の一歩になります。

順番3: 現物を「見るだけ」で記録する(壊さずに実態をつかむ)

聞き取りで大まかな見取り図ができたら、ようやく現物の調査に入ります。ここでの鉄則は「操作しない、設定を変えない、まず見るだけ」です。具体的には以下を記録していきます。

• パソコンの機種名、購入時期(わかれば)、OSのバージョン
• インストールされているソフトウェア名とバージョン
• そのパソコンやサーバーがどこに置かれ、誰の机の下にあるのか
• ネットワークにどう繋がっているか(単体で動いているのか、他のPCと共有しているのか)
• 起動時に立ち上がる業務ソフト、デスクトップに置かれたショートカットやファイル

レガシーシステムと呼ばれる古いシステムほど、この段階での注意が必要です。長年設定を変えずに動いてきたレガシーシステムは、ちょっとした操作ミスや、意図せぬWindows Updateの適用だけで突然起動しなくなることがあります。調査段階では次のルールを徹底してください。

• 電源を落とす場合は必ず先に「今は使われていない時間帯か」を確認する
• 何かキーを押す前に画面をスマートフォンで撮影しておく(操作前の状態を残す)
• インストール済みソフト一覧は、右クリックでアンインストールボタンを押すのではなく、一覧表示だけで済ませる
• どうしても不安な画面は、その場でIT業者や詳しい知人に電話で相談してから進める

この段階で無理に自己解決しようとせず、少しでも「これは危ないかもしれない」と感じたら手を止める判断力が、結果的に一番早く安全に調査を終えるコツです。Access（データベースソフト）で組まれた顧客管理システムなどは、ファイルを開いただけでも自動的にデータの一部が更新されてしまう設定になっている場合があるため、特に慎重な扱いが必要です。

順番4: サポート状況・契約状況を確認する(EOLと契約切れを洗い出す)

現物の記録ができたら、それぞれのソフトウェア・機器について「いつまでメーカーに面倒を見てもらえるのか」を調べます。具体的には以下を確認します。

• OS(Windows等)のサポート終了日は過ぎていないか
• 業務ソフトのバージョンは、開発元のサポート対象内か
• そのシステムを納入した業者は今も営業しているか、担当者は連絡が取れるか
• 保守契約は今も生きているか、更新料は誰にいくら払っているのか
• ライセンス契約の名義は誰になっているか(先代の個人名義になっていないか)

このうち最後の「名義」の確認は、承継特有の重要な論点です。中小企業では、ソフトウェアのライセンスやドメイン、クラウドサービスの契約者名が、法人ではなく先代個人のメールアドレス・クレジットカードで登録されたままになっているケースが少なくありません。先代が完全に会社と縁が切れてしまうと、パスワードの再発行すらできなくなるおそれがあります。名義変更の要否は、システムの技術的な調査と同じくらい優先度の高い確認事項です。

サポートが切れている、または切れかけているソフトウェアが見つかった場合、それはIT業界でEOL（サポート終了）と呼ばれる状態です。EOLを迎えた製品は、新たな脆弱性が見つかっても修正プログラムが提供されなくなるため、外部からの攻撃に対して無防備な状態が続きます。加えて、パッチマネジメント、つまり日々のセキュリティ更新プログラムの適用自体が止まっている可能性が高く、放置期間が長いほど後から一括対応する際の作業量と緊張感が増します。

調査にかける時間の目安と、社長自身が動くべき理由

「調査」と聞くと大掛かりな作業に思えるかもしれませんが、目安としては、従業員10〜30人規模の会社であれば、聞き取りと現物記録だけなら2〜4週間程度、契約状況の確認まで含めても1〜2ヶ月程度で一巡できることが多いです（会社を継いで1年目にシステム面で何を優先すべきかは会社を継いで1年目、システム面で最初にやることの優先順位も参照してください）。もちろんシステムの数や複雑さによって前後しますが、「いつまでに終わらせるか」を最初に決めておかないと、日々の経営業務に追われてずるずると先送りになりがちです。カレンダーに「棚卸し期間」として明示的に時間を確保することをお勧めします。

この調査は、総務担当者や外部業者に丸投げするのではなく、社長自身がある程度は先頭に立って動くべき作業です。理由は2つあります。

1つ目は、業務への影響範囲の判断(順番1)が、経営全体を見渡せる立場でなければ正確にできないためです。どの業務が止まると経営上致命的か、どの業務なら一時的に代替できるかは、現場の一担当者よりも経営者の方が正しく判断できます。

2つ目は、先代や古参社員への聞き取り(順番2)において、社長自らが動くこと自体が「本気で会社の将来を考えている」というメッセージになるためです。総務担当者からの事務的な質問と、社長自身からの質問とでは、相手の協力度合いがまったく変わってきます。もちろん現物調査(順番3)やサポート状況の確認(順番4)といった技術的・事務的な作業は、信頼できる社員や外部の詳しい人に分担してもらって構いません。社長は「なぜこの調査が必要か」を全社に説明し、旗を振る役割に徹するのが効率的です。

調査中に見つかりやすい「想定外」のパターン

実際に調査を始めると、想定していなかった事実が見つかることが少なくありません。あらかじめ心づもりをしておくと、動揺せずに対応できます。

担当者しか知らないパスワードで守られている 特定の社員の頭の中、あるいはその社員の机の引き出しの中のメモにしかパスワードが存在せず、本人が休むと誰も中身を確認できない、という状態はよくあります。これも属人化の一形態であり、見つかった時点で優先的に共有・記録すべき対象です（退職者が持っていたパスワードやアカウントの棚卸しは、先代の退職者PCとアカウント、承継前にやる棚卸しの手順が参考になります）。

廃業した業者が作ったシステムがまだ現役で動いている 納入した業者自体がすでに廃業しており、問い合わせ先が存在しないケースです。この場合、トラブルが起きても誰も直せない状態が続いていることになります。次にトラブルが起きたときに詰むことがほぼ確定しているため、優先的に代替手段を検討する対象になります。

同じ業務のために複数のシステムが並行して使われている 古いシステムを完全に廃止できず、新しいシステムと二重運用になっているケースです。担当者ごとに使うシステムが違う、部署ごとにやり方が違う、といった状態は、データの整合性が取れなくなるリスクを抱えています。

個人のパソコンやスマートフォンに業務データが入っている 特に営業担当者や、経理を一人で担っていた社員の私物端末に、顧客データや経理データが保存されているケースです。退職や機種変更のタイミングでデータが失われるリスクがあるため、早期に会社の管理下にあるシステムへ移す必要があります。

これらはいずれも、「触ると壊れる」という警告の裏に隠れていた、より根深い課題であることが多いです。調査を進める中でこうした事実に出会っても、それは調査が失敗しているのではなく、むしろ正しく機能している証拠だと捉えてください。

聞き取りが難航したときの対処法

古参社員や先代からの聞き取りがうまくいかないケースもよくあります。以下のようなパターン別に対処法を整理します。

先代が「大丈夫、心配するな」としか言わない場合 心配していないわけではなく、うまく言語化できていない、あるいは「経営から退いた自分が口を出すべきではない」と遠慮している場合が多いです。抽象的な質問ではなく「このパソコンの電源はいつ入れて、いつ切っていますか」「バックアップは誰かが取っていますか」など、Yes/Noで答えられる具体的な質問に切り替えると、口が開きやすくなります。

古参社員が「自分にしかわからないから」と抱え込む場合 悪意ではなく、その業務が自分の存在価値になっているケースが多く見られます。「あなたを外すためではなく、あなたが急に休んでも会社が困らないようにするための記録」という説明を丁寧に繰り返すことが有効です。

担当者がすでに退職していて誰も分からない場合 最後の手段として、システムを納入した業者(パッケージソフトのシール、請求書の宛先などから特定できることが多い)に直接問い合わせます。廃業している場合は、同種のソフトを扱う別の業者に「このソフトの仕様、分かりますか」と相談すると、業界の知見で類推してもらえることがあります。

調べた結果は台帳に一本化する

ここまでの調査結果は、頭の中やメモ帳に散らばらせず、一つの台帳にまとめます（台帳の作り方の詳細は属人化した先代システムを防ぐ、承継後の管理台帳の作り方にまとめています）。これは形式にこだわる必要はなく、Excelでもスプレッドシートでも構いません。重要なのは「これを見れば全部わかる」状態を作ることです。この台帳はシステム管理台帳と呼ばれ、IPAの「中小企業の情報セキュリティ対策ガイドライン」の付録にもサンプル様式(ハードウェア台帳・ソフトウェア台帳・情報資産管理台帳など)が公開されています。ゼロから項目を考える必要はなく、まずはこうした公的な様式をひな形として使うのが近道です。

台帳に最低限含めたい項目は次の通りです。

• 機器・ソフトウェア名、設置場所、管理者(実際に触れる人)
• 導入時期(わかる範囲で)、サポート終了予定日
• 契約先業者名、連絡先、保守契約の有無と更新時期
• ライセンス名義(法人名義か個人名義か)
• そのシステムが止まった場合に影響する業務、代替手段の有無
• 経緯を知っている人の名前とメモ(先代からの伝聞含む)

台帳は一度作って終わりではなく、年に1回程度見直すことを前提にしてください。この台帳があるだけで、次に自分がこの会社を誰かに引き継ぐとき、あるいは新しい担当者を採用したときに、今回味わった苦労を二度と繰り返させずに済みます。

よくある質問

Q. 先代がまだ会社に来ていて、システムの話をすると機嫌が悪くなります。どう切り出せばいいですか。

A. 「変えたい」ではなく「記録として残したい」という目的から入るのが有効です。多くの場合、先代の懸念は「せっかく築いた仕組みを否定される」ことへの抵抗感にあります。「お父さん(先代)が作った仕組みのおかげでここまで回ってきたので、それを正しく次に引き継げるように、まず記録させてほしい」という伝え方であれば、抵抗感は和らぎやすくなります。実際に触って変更するのは記録が終わった後の話だと明確に分けて伝えることも重要です。

Q. 古参社員が「自分がいなくなったら会社は回らなくなる」と匂わせてきて、聞き取りに協力的ではありません。

A. まず、その社員の存在自体を否定する意図はないと明確に伝えてください。台帳作成の目的は特定の個人を代替可能にすることではなく、その社員が病気や急な事情で休んだときにも会社が止まらないようにする、いわば「保険」であるという説明が響きやすいです。また、聞き取りをその社員だけに任せず、社長自身が同席してヒアリングする形にすると、「詰められている」という印象を和らげられます。

Q. システムの契約が先代個人の名義になっていることが分かりました。名義変更は急ぐべきですか。

A. 急ぐべき部類に入ります。特にドメイン、クラウドサービス、一部の業務ソフトのライセンスなどは、契約者本人しかパスワードの再発行や解約手続きができない設計になっていることが多く、先代と連絡が取れなくなってから気づくと解決までに長い時間がかかります。契約書やクレジットカードの明細、請求書の宛名から名義を洗い出し、法人名義またはあなた自身の名義に変更できるものから順に進めてください。

Q. 調査した結果、明らかに危険な(サポートが切れている)システムが複数見つかりました。全部同時に入れ替えるべきですか。

A. 一度に全部を入れ替える必要はありません。まず順番1で洗い出した「業務への影響範囲」に立ち返り、止まると即座に事業継続が難しくなるもの(単一障害点)から優先順位をつけて対応してください。予算にも限りがあるはずなので、リスクの高さと入れ替えの緊急度を突き合わせて、年単位の計画に落とし込むのが現実的です。焦って一斉に手を付けると、かえって現場が混乱し、古参社員の反発を招きやすくなります。

調査の結果を、外部の専門家にどう伝えればよいか

台帳がある程度形になってきたら、次のステップとしてIT業者やシステム会社に相談する場面が出てくるはずです。ここで注意したいのは、初回の相談でいきなり「刷新してほしい」と伝えてしまうと、業者側もどこから手をつけていいか分からず、結果的に割高な提案や、的外れな提案を受け取ってしまうことがある点です。

相談の際は、次の3点を最低限まとめて持っていくと、話がスムーズに進みます。

1. 現状の一覧: 順番3・4で作成した台帳(機器・ソフトウェア・サポート状況)
2. 困りごとの優先順位: 順番1で洗い出した「止まると困る業務」の一覧
3. 予算感と時期の制約: いつまでに、どれくらいの予算で対応したいか(概算で構いません)

これらがあるだけで、業者側は「まず何を優先すべきか」を的確に判断できるようになります。逆にこれらがない状態で相談すると、業者側も手探りで全体を調べ直すところから始めることになり、その分の調査費用や時間が余計にかかってしまうことがあります。棚卸しをあなたの手である程度終えておくこと自体が、外部に依頼する際のコストを下げる準備になるのです。

また、複数の業者に相談する場合は、同じ台帳・同じ優先順位のリストを渡すことで、見積もりの前提条件を揃えることができます。前提条件がバラバラのまま各社に相談すると、金額の比較そのものが意味をなさなくなってしまうため注意してください。

承継後の人間関係を壊さずに進めるための心構え

ここまで紹介してきた調査は、技術的な作業である以上に、社内の人間関係を扱う作業でもあります。特に事業承継の直後は、古参社員が新しい社長のやり方をまだ品定めしている時期でもあり、システムへの向き合い方一つで、その後の信頼関係が大きく変わることがあります。

意識しておきたいのは、この調査の目的が「先代のやり方を否定すること」ではなく「先代が守ってきたものを、次の世代に正しく引き継ぐこと」だという点を、言葉にして繰り返し伝えることです。特に古参社員に対しては、次のような姿勢が伝わると協力を得やすくなります。

• 変更や刷新の決定は、調査が終わってから改めて相談する、と明言する
• 聞き取りの場では、否定的な相槌(「それは非効率ですね」等)を避ける
• 調査の結果、その社員の仕事のやり方自体を評価するようなコメントは慎む
• 台帳ができた後は、その社員にも共有し、「あなたの知識が会社の資産として残った」と伝える

先代に対しても同様です。特に、先代がまだ会長や相談役として会社に関わり続けている場合、システムの話題は「経営から退いたはずなのに口を出さざるを得ない」という複雑な感情を伴うことがあります。調査の進捗を定期的に、押し付けがましくない形で共有する(「先日教えてもらった件、台帳にまとめました」など)ことが、先代の安心材料になります。

システムの調査は、突き詰めれば「会社の中の見えない部分を、皆が見える形にする」作業です。それは同時に、先代の代から積み重なってきた工夫や苦労に光を当て、正しく評価し直す機会でもあります。技術的な正しさだけでなく、こうした人間関係への配慮を伴わせることで、調査そのものが承継をスムーズに進める助けにもなっていきます。

おわりに

「触ると壊れる」というひと言は、先代なりの精一杯の申し送りだったのかもしれません。しかしそのひと言だけを頼りに、システムに触れずにいる状態は、経営者としてはむしろ危険を先送りしているに過ぎません。今日から必要なのは、いきなり刷新することでも、先代を責めることでもなく、まず「何がそこにあるのか」を壊さずに調べ、記録することです。

この調査は、一人で全部を背負い込む必要はありません。業務への影響範囲の洗い出しは経営者にしかできない仕事ですが、現物調査や台帳化の部分は、外部の専門家の手を借りることもできます。まずは今回紹介した順番で、自社の中に眠っている「聖域」を一つずつ明るみに出していくところから始めてみてください。それは、先代が築いてきたものを壊す行為ではなく、正しく次へつなぐための最初の一歩です。

調査を進める中でシステム自体の延命が難しいと分かった場合は、先代のレガシーシステム、壊れる前にデータだけ救出する方法を先に確認しておくと、最悪のタイミングでの喪失を避けられる。