「動いているから触るな」と古参社員に言われるシステムの安全な改修手順

「動いているから触るな」と古参社員に言われるシステムの安全な改修手順

結論:「触るな」は正しい。だから手順を変える

「このシステムは動いているから触るな」——先代から会社を継いだとき、経理担当の古参社員や、現場の生産管理を長年支えてきたベテランからこう釘を刺された経験はないだろうか。相手は悪意で言っているのではない。過去に誰かが軽い気持ちで改修し、締め処理が止まった、出荷データが消えた、そういう記憶があるから止めているのだ。その恐怖には、それなりの理由がある。承継直後は、こうした「見えない地雷」がどこにあるのか、経営者自身が把握できていないことも多い。まず調査すべき順番については、「触ると壊れる」と先代に言われ続けたシステムを調査する順番も参考にしてほしい。

結論から言うと、この言葉は「システムを一切変えるな」という意味ではなく、「壊れる改修の仕方をするな」という警告として受け取るべきだ。実際、経済産業省がまとめた「レガシーシステムモダン化委員会総括レポート」（2025年5月）でも、老朽化したシステムは技術面の陳腐化に加えて「肥大化・複雑化」「ブラックボックス化」の3つの側面を抱えており、影響範囲が見えないまま手を入れることこそが最大のリスクだと指摘されている※1。裏を返せば、影響範囲を可視化し、段階を踏んで進めれば、古参社員の懸念とも共存しながら改修できるということだ。

この記事では、後継経営者が「動いているから触るな」の壁を越えて、安全にシステムを改修していくための具体的な手順を、承継特有の人間関係も含めて解説する。対象読者は、先代から会社を継いだ（継ぐ予定の）非IT出身の経営者で、Excel・Access・古い販売管理ソフトなどが現場の生命線になっているが、担当者が高齢化・退職リスクを抱えている、という状態の方だ。特別なIT知識は必要ない。

なぜ「触るな」と言われるのか——古参社員の側の合理性

まず理解すべきは、古参社員の「触るな」には彼らなりの合理性があるという点だ。長年そのレガシーシステムを運用してきた担当者は、以下のような経験則を持っている。

• 過去に外部業者やIT部門が「改善提案」で手を入れた際、想定外の箇所に影響が出て業務が止まった
• マニュアルや仕様書が存在せず、動作の理由を説明できる人が自分しかいない（＝属人化）
• 改修の失敗の責任を自分が負わされるという恐れがある
• 新しいシステムへの学習コストを払いたくない、あるいは定年間際でその必要性を感じない

つまり「触るな」は保身の言葉であると同時に、過去の失敗を知っている実務者からの正当なリスク警告でもある。後継者がここを単なる「古い体質の抵抗」とだけ捉えて強引に刷新を進めると、現場の協力を失い、かえって改修が頓挫する。実際に中小企業の事業承継準備では「自社の見える化」の一環として、後継者候補の適格性だけでなく、従業員のスキルや業務の属人化の度合いを把握することが重要だとされている※2。システム改修も、この「見える化」の延長線上に位置づけるべき作業だ。

「動いているから触るな」は、システムへの警告ではなく、変更管理のプロセスが存在しないことへの警告として読み替える。

株や登記には専門家がいるのに、システム改修には誰もいない

事業承継の場面では、株式評価や名義変更は税理士が、登記変更は司法書士が、それぞれ当たり前のように相談先として存在する。契約書の確認なら弁護士に、資金繰りの相談なら銀行の担当者に頼れる。ところが、社内システムの改修となると、相談できる専門家が突然いなくなる。顧問税理士に聞いても「専門外です」と言われ、銀行担当者もシステムの中身までは踏み込んでこない。

結果として、多くの後継経営者は「先代の代からの付き合いのある業者に丸投げする」か「怖いので何もしない」のどちらかに偏りがちだ。しかしどちらも根本的な解決にはならない。丸投げは属人化を別の形で温存するだけであり、放置はリスクを先送りするだけだからだ。この記事で紹介する手順は、専門家が不在の領域を、後継経営者自身の手でカバーするためのものだと捉えてほしい。特別な技術知識は前提にしていない。

手順1:触る前に「何が動いているか」を棚卸しする

いきなり改修に着手してはいけない。最初にやるべきは、現状のシステムが何をしているかを一覧化するシステム管理台帳の作成だ。古参社員に敵対せず、むしろ「あなたの頭の中にある知識を会社の資産として残したい」というフレーミングで協力を仰ぐのがポイントになる。

棚卸しで最低限押さえるべき項目は次の通り。

この棚卸し作業自体が、実は最も価値のある改修準備になる。経産省のレポートでも、レガシーシステムのリスク評価軸として「保守コスト」「人材依存」「変更容易性」「データ連携」「セキュリティ」の5つが挙げられ、対策の優先順位は「システム棚卸し」から始まるとされている※1。棚卸しをせずに改修計画を立てるのは、地図なしで工事をするのと同じだ。

棚卸しの過程で、古参社員から「そういえば、これも同じシステムで動いている」といった新たな発見が出てくることも珍しくない。当初想定していなかった依存関係が見つかった場合は、焦らずリストに追加し、優先順位を見直せばよい。棚卸しは一度で完璧に終わらせる作業ではなく、少しずつ精度を上げていくものだと捉えておくと、気持ちの負担が軽くなる。

手順2:単一障害点を特定し、「代役」を先に作る

棚卸しが終わったら、次に見るべきは単一障害点（SPOF）がどこにあるかだ。多くの場合、それは「特定の社員のPCにしか入っていないAccessファイル」「その人しか開けないパスワード付きExcel」「担当者本人しか読めないVBAマクロ」のような形で存在する。

ここで重要なのは、改修の第一歩はシステムを変えることではなく、その人が休んでも業務が止まらない状態を作ることだという点だ。具体的には以下の順序が安全だ。

1. 現行システムの操作手順・出力結果を、まず「触らずに」文書化する
2. 同じ処理を別の担当者が代行できるかテストする（バックアップ担当の育成）
3. データのバックアップ体制を独立して確保する（本体を変更せずに済む対策から着手）
4. ここまで整った状態で初めて、本体の改修に着手する

この順序を守れば、万が一改修中にトラブルが起きても、業務そのものは止まらない。逆に言えば、代役がいない状態でいきなり本体を改修するのが、古参社員が最も恐れているシナリオそのものだ。

代役の育成には時間がかかることも多いが、焦る必要はない。まずは日常業務の中で、担当者以外の社員がシステムに触れる機会を少しずつ増やすところから始めれば十分だ。完全に同じレベルで操作できるようになる必要はなく、「最低限、業務を止めずに済む」程度の理解があれば、緊急時の備えとしては十分に機能する。半年から1年程度の時間軸で、少しずつ育成を進めていけばよい。

業種別に見る、「触るな」システムの典型例

古参社員が「触るな」と言うシステムには、業種によって共通のパターンがある。自社の業種に照らして、優先的に警戒すべき箇所の見当をつけてほしい。

製造業では、生産管理・在庫管理システムがExcelマクロと密接に連携しているケースが多い。現場の担当者が独自に組んだ集計マクロが、実は出荷判断の基礎データになっていることがあり、表面的な改修のつもりが出荷業務全体に影響することがある。

小売業・卸売業では、受発注システムと会計システムの間を、手作業やバッチ処理でつないでいるケースが目立つ。ここに触れる際は、両システムの間でデータがどう受け渡されているかを事前に必ず確認する必要がある。

士業・専門サービス業では、顧客管理や案件管理がAccessやFileMakerのような小規模データベースで組まれていることが多い。長年の運用で独自のカスタマイズが積み重なり、外部の専門家でも中身を完全に把握するのが難しい状態になっていることがある。

いずれの業種にも共通するのは、「触るな」と言われるシステムほど、実は複数の業務が絡み合った複雑な構造になっているという点だ。単純に見える改修でも、影響範囲は想像以上に広いことを前提に進めるべきだ。小売・サービス業で繁忙期をまたぐタイミングでの進め方は、小売・サービス業の承継1年目、繁忙期をまたぐ前に済ませておくことでも扱っている。

手順3:影響範囲を確認してから、小さく変更する

システムのブラックボックス化に関する解説では、長年の改修・機能追加で構造が複雑化すると、機能同士の関係が絡み合い、影響範囲の把握が難しくなり、重複した機能が存在するようになると指摘されている※3。裏を返せば、影響範囲さえ事前に確認できれば、変更のリスクは大きく下げられるということだ。

改修時に踏むべきステップは次の通り。

• 変更前に本番データのバックアップを取る（Access・Excelファイルなら単純にコピーを保存するだけでよい）
• 本番と同じ環境で試す（コピー環境がなければ、まずは休業日や締め処理の直後など、影響が出ても取り返しがつくタイミングを選ぶ）
• 一度に複数箇所を変えない（1回の改修で触る範囲を最小限にする）
• 変更後、古参社員に「いつもと同じ結果になっているか」を確認してもらう（ここで初めて古参社員は「協力者」になる）

この最後のステップが承継特有のポイントだ。古参社員を改修の「抵抗勢力」としてではなく、「結果を検証できる唯一の人物」として改修プロセスに正式に組み込む。それによって、彼らの「触るな」という警戒心は、「一緒に確認しよう」という協力関係に変わっていく。先代の代から会社を支えてきた人にとって、自分の経験が軽視されずに活かされることは、後継者への信頼にも直結する。

この段階まで来ると、当初「触るな」と強く警戒していた古参社員の態度が、目に見えて軟化することが多い。理由は単純で、改修プロセスの中に自分の役割が明確に存在するからだ。蚊帳の外に置かれて一方的に変更を押し付けられるのと、確認役として頼られるのとでは、受け止め方がまったく異なる。こうした信頼関係の変化は、システム改修だけでなく、その後の経営全般にも良い影響を及ぼすことが多い。「この後継者は現場を軽視しない」という評判が社内に広がれば、他の業務改善の提案に対しても、現場からの協力を得やすくなる。システム改修は、単なる技術的な作業ではなく、後継者としての信頼を積み上げる機会でもあると捉えておきたい。目先の効率だけでなく、長い目で見た関係づくりを意識してほしい。

手順4:改修の記録を残し、次の担当者への負債にしない

改修が完了したら終わりではない。むしろここからが重要で、何を、なぜ、どう変えたかを記録に残すことが、次の担当者（あるいは3代目）への贈り物になる。記録がなければ、また同じように「動いているから触るな」と言われるシステムが再生産されるだけだ。

記録すべき最低限の内容は以下の通り。

• 変更日・変更者・変更理由
• 変更前後の動作の違い
• テストで確認した内容と結果
• 今後同様の変更を行う際の注意点

これを特別な文書管理システムで行う必要はない。Excelの1シートやWord文書で構わないので、システム管理台帳の一部として蓄積していくことが大切だ。デジタル庁が2025年に公表したレガシーシステムモダン化に関する報告でも、ユーザー企業がモダン化を進めるための前提として、まず自社システムの現状を可視化し、記録として残すことの重要性が繰り返し述べられている※4。台帳の具体的な作り方は、属人化した先代システムを防ぐ、承継後の管理台帳の作り方や引き継ぎ書がない会社が承継後すぐに始めるシステム記録術でも詳しく解説している。

先代自身が「触るな」と言っている場合の向き合い方

古参社員だけでなく、先代自身がまだ会社に関わっており、「あのシステムには触るな」と言っているケースもある。この場合、単なる技術的な懸念に加えて、「自分が作り上げたものを否定されたくない」という感情的な側面が絡んでいることが多く、より慎重な対応が求められる。

先代との対話では、改修そのものへの賛否を最初に問うのではなく、「今のシステムがどういう経緯で今の形になったのか」を聞くところから始めるとよい。先代にとって、自分の判断の背景を聞かれることは、否定されることとは違う。むしろ、後継者が敬意を持って耳を傾けている証拠として受け取られやすい。

先代の世代では、システムを「業者に頼んで作ってもらうもの」として捉え、細部の仕組みまでは把握していないことも多い。そのため、先代への聞き取りでは技術的な詳細よりも、「なぜこの機能が必要だと考えたのか」という意思決定の背景を中心に聞くと、より実りある対話になりやすい。急がず、じっくりと話を聞く時間を作ろう。

先代が完全に引退する前のこの時期は、システムの背景を知る唯一の機会でもある。古参社員が知らない「そもそもなぜこの仕組みを選んだのか」という原点の判断は、先代にしか語れないことが多い。焦らず、しかし機会を逃さずに、対話の時間を作ることをおすすめしたい。

手順5:古参社員の知識を「個人の記憶」から「会社の資産」に変える

最終的なゴールは、システムそのものの刷新ではなく、特定の個人に依存しない状態を作ることだ。これは古参社員を排除することとは全く違う。むしろ、その人が持っている知識・経験を会社の資産として残し、その人自身も安心して引退できる状態を作ることが目的になる。

承継後の経営者がよく陥る誤解は、「システムを新しくすれば属人化が解消される」というものだ。しかし、新システムに入れ替えても、操作方法を知っているのが1人だけなら、属人化はそのまま引き継がれる。重要なのは箱を変えることではなく、知識の継承プロセスを作ることだ。

そのために有効なのが、以下のような段階的な巻き込み方だ。

古参社員に「システムを奪う人」ではなく「システムの知識を守る人」として役割を再定義してもらう。改修プロジェクトの記録係・検証係として正式に関わってもらうことで、その人の経験は「自分がいなくなったら困るブラックボックス」から「会社に残る資産」へと変わる。

この転換ができると、古参社員自身が「次はここも直したほうがいい」と改修に前向きになるケースも少なくない。「触るな」と言っていた人が、最も頼れる改修パートナーになる瞬間だ。

改修プロジェクトを小さく始める意味

システムの棚卸しから改修計画まで、ここまで紹介した手順を一気に進めようとすると、日々の経営業務との両立が難しくなる。無理に大きなプロジェクトとして立ち上げるのではなく、まずは影響範囲が最も小さく、成功体験を得やすい一箇所から着手することをおすすめしたい。

たとえば、業務全体には影響しない画面表示の軽微な修正や、エラーメッセージを分かりやすくする程度の変更から始めると、古参社員も「これくらいなら」と協力しやすくなる。小さな成功を積み重ねることで、「この後継者は無茶をしない」という信頼が社内に少しずつ広がっていく。その信頼こそが、次のより大きな改修に着手する際の土台になる。

逆に、いきなり基幹部分の全面刷新を提案すると、古参社員の警戒心が一気に高まり、その後の協力を得にくくなる。急がば回れの精神で、小さな一歩から始めることが、結果的に最も早く目的地にたどり着く道になる。

自力での改修に限界を感じたら

ここまで紹介してきた手順は、非IT出身の経営者でも実践できる範囲を想定している。それでも、以下のような状況に当たった場合は、無理に自力で進めようとせず、外部の専門家に相談する判断を検討してほしい。

• システムの構造が複雑で、棚卸しをしても全体像がまったくつかめない
• 複数のプログラム言語や技術が組み合わさっており、影響範囲の見当がつかない
• 改修による誤操作でデータ破損のリスクが高く、これ以上は自己判断で触りたくない

外部の開発会社に相談する場合でも、この記事で紹介した手順に沿って棚卸しと影響範囲の整理を先に済ませておくと、相談時の説明がスムーズになり、見積もりの精度も上がる。まったくの白紙の状態で相談するより、「ここまでは分かっているが、ここから先の判断に迷っている」という状態で相談したほうが、専門家も的確な提案をしやすい。老朽化したシステムを業務を止めずに段階的に作り変えるシステムリプレース（運営会社ゼットリンカーの受託メニュー）のように、仕様書がない状態からの調査に対応する専門会社もある。

相談先は、必ずしも先代の代からの付き合いのある業者である必要はない。しがらみのない第三者の視点で現状を評価してもらうことも、承継後のシステム対応では有効な選択肢の一つだ。複数の候補から話を聞き、比較検討する余裕を持っておくとよい。

改修後の運用体制も忘れずに設計する

改修が無事に完了しても、それで終わりではない。改修後の運用を誰が担うのか、トラブルが起きたときに誰が最初に連絡を受けるのかといった体制を、改修と同時に設計しておく必要がある。せっかく属人化を解消しても、新しい運用体制がまた1人の担当者に依存する形になっていては、同じ問題を先送りしただけになってしまう。

理想的には、システムの主担当と副担当の2人体制を作り、どちらか一方が不在でも最低限の対応ができる状態を目指したい。中小企業では人員に限りがあり、完全な2人体制が難しい場合もあるが、その場合でも「何かあったときにまず誰に連絡するか」という一次窓口だけは明確にしておくべきだ。この体制図もまた、システム管理台帳に記録しておくべき重要な情報の一つになる。定期的な見直しも忘れずに行いたい。

まとめ:安全な改修は「順番」で決まる

「動いているから触るな」という言葉を、システムへの拒否反応ではなく、変更管理プロセスの欠如への警告として受け止め直すこと。それが、承継後の経営者がシステム改修で最初に持つべき視点だ。

手順としては、①棚卸しで現状を可視化する、②単一障害点の代役を先に作る、③影響範囲を確認してから小さく変更する、④記録を残す、⑤古参社員の知識を会社の資産に変える、という順番を守ること。この順序を踏めば、古参社員の警戒心は協力に変わり、システムは壊れることなく、次の世代に引き継げる状態になっていく。

先代が築いてきた会社を、次の世代でも壊さずに強くしていくためには、目に見える資産だけでなく、こうした地味なシステムの土台も丁寧に引き継いでいく必要がある。「触るな」という言葉を恐れず、しかし軽視もせず、正しい順番で向き合ってほしい。焦らず、一つずつ進めていけば、必ず道は開ける。

改修を先送りし続けるコストも忘れない

ここまで慎重な進め方を強調してきたが、「触るな」を理由に改修を無期限に先送りすることにもリスクがある。担当者の高齢化は止まらず、システムの土台となるOSやソフトウェアのサポート期限も刻一刻と近づいている。焦って強引に進めるのも危険だが、根拠なく先送りし続けるのも同じくらい危険だ。

判断の目安として、次のいずれかに当てはまる場合は、改修の優先順位を上げて検討すべきタイミングだと考えてよい。

• システムの唯一の担当者が、定年や体調面で近い将来に業務を離れる可能性がある
• 稼働しているOSやソフトウェアのサポート終了時期が判明している、または近づいている
• 過去1年以内に、原因不明のトラブルや一時的な業務停止が発生したことがある

これらに一つでも当てはまる場合は、この記事で紹介した棚卸しから、できるだけ早く着手することをおすすめする。準備を整えてから動くのと、何も準備せずに緊急対応に追われるのとでは、コストも精神的な負担もまったく違う。古いVB6・Delphi製のシステムを使っている場合の移行タイミングの見極め方は、VB6・Delphi製の先代システムはいつまで動くか。移行タイミングの見極めで扱っている。また、決算月をまたぐタイミングでの優先度の考え方は承継1年目、決算月をまたぐ前後でシステム確認の優先度はどう変わるか、「触るな」と言われるシステムとの1年目の距離の取り方は「触るな」と言われるシステムとの、1年目の距離の取り方も参考にしてほしい。

逆に、これらのいずれにも当てはまらず、担当者も若く、システムも比較的新しい場合は、無理に急いで改修に着手する必要はない。棚卸しだけを済ませておき、状況が変化した時点で改めて優先順位を見直すという進め方でも十分だ。焦らず、着実に進めていけばよい。

#この記事で紹介した内容を実践するにあたり、よくある質問をまとめておく。

FAQ

Q1. 古参社員が改修に強く反対していて、話を聞いてもらえません。どうすればいいですか。 A. 最初から改修そのものを提案せず、「システムの棚卸しをしたい、あなたの知識を記録に残したい」という切り口から入るのが有効だ。改修の話は、棚卸しを通じて信頼関係ができてからでよい。いきなり「変える」話をすると身構えられてしまう。

Q2. Accessで作られた基幹システムが古く、担当者も高齢です。今すぐ刷新すべきでしょうか。 A. Access（データベースソフト）自体が即座に危険というわけではないが、担当者の高齢化とサポート終了が重なっている場合はリスクが高い。ただし、いきなり刷新するのではなく、まず単一障害点（その人しか触れない部分）を特定し、代役やバックアップ体制を先に作ってから、段階的に移行を検討する順序が安全だ。

Q3. 改修のたびに小さなトラブルが起きます。何が問題なのでしょうか。 A. 多くの場合、影響範囲を事前に確認せずに変更していることが原因だ。長年の改修・機能追加でシステム内部の関係が複雑化していると、一見無関係な箇所に影響が波及しやすい。変更前のバックアップ取得と、変更後の古参社員による動作確認を必須の手順として組み込むことで、トラブルの多くは防げる。

Q4. VBAマクロで動いている集計処理があり、作った本人がもう退職間近です。何から手をつければいいですか。 A. まず退職前に、マクロの中身と処理の流れを本人と一緒に文書化することを最優先にしてほしい。マクロを触るかどうかの判断はその後でよい。本人が在籍しているうちに知識を記録として残せるかどうかが、その後の改修コストを大きく左右する。

Q5. 改修プロジェクトを進める中で、古参社員と意見が対立してしまいました。どう解決すればいいですか。 A. まずは対立の原因が「改修そのものへの反対」なのか、「進め方への不満」なのかを切り分けてほしい。多くの場合、後者であることが多く、事前の説明不足や、影響範囲の確認を飛ばしたことへの不安が背景にある。改修そのものへの反対であれば、なぜその機能・仕組みが必要だと考えているのかを丁寧に聞き取り、代替案を一緒に検討する姿勢を示すことで、多くの対立は解消に向かう。

※1 経済産業省「レガシーシステムモダン化委員会総括レポート」（2025年5月28日） ※2 中小企業庁「事業承継を実施する」 ※3 システムのブラックボックス化とは？原因・リスク・解消方法をわかりやすく解説 ※4 デジタル庁ニュース「企業のDXを阻む『レガシーシステム』とは？」（2025年8月27日）