誰も触れない先代由来のバッチ処理の正体を突き止める方法

誰も触れない先代由来のバッチ処理の正体を突き止める方法

結論:バッチ処理の正体は「止めて確認」ではなく「観察してから確認」で突き止める

毎晩深夜2時、誰も触っていないのに黒い画面が一瞬だけ立ち上がって消える。朝出社すると、なぜかExcelファイルが1つ更新されている。誰に聞いても「先代の時代からずっとそうだから」としか答えが返ってこない——そんな不思議な現象に、心当たりはないだろうか。

先代から会社を継いだ二代目・三代目経営者の多くが、こうした「正体不明のバッチ処理」を社内に1つや2つ抱えています。触ると何かが壊れそうで怖いから、誰も手を出さない。かといって放置し続けると、いつか必ず限界が来ます。担当者の退職、Windowsのアップデート、サーバーの入れ替え——きっかけは何でもよく、ある日突然「動かなくなった」という形で牙をむいてきます。

厄介なのは、こうした処理が「壊れるまでは何の問題も起こさない」という点です。普段は静かに、しかし確実に業務を支え続けているからこそ、経営者の目には「特に困っていない」領域として映り、優先順位が上がりません。しかし、それは時限爆弾の導火線が見えていないだけで、いつか必ず火がつくということでもあります。

株や登記の手続きには専門家が伴走してくれますが、こうした社内の仕組みには誰も付き添ってくれません。結論から言うと、先代由来のバッチ処理の正体は、いきなり止めて確認するのではなく、動いている状態のまま「どこにあるか」「何に依存しているか」「何を出力しているか」の3点を無停止で観察してから、初めて安全に手を加えられます。本記事では、非IT出身の経営者でも実行できる、具体的な調査手順を順を追って解説します。専門知識がなくても、正しい順番さえ守れば一人で進められる作業です。

こんな状態に心当たりがある方に向けて書いています。

• 経理担当者から「あのバッチ、たまに止まるんです」と報告を受けたが、誰に相談すればいいか分からない
• 先代を支えていたベテラン社員が高齢で、もし体調を崩したらバッチ処理の中身が完全にブラックボックス化すると不安に感じている
• パソコンを入れ替えたい、サーバーを更新したいと思っているが、正体不明のバッチ処理が動いているせいで踏み切れない

なぜ「先代由来のバッチ処理」は誰も触れなくなるのか

先代由来のバッチ処理が「触れない存在」になる背景には、明確な構造があります。多くの場合、当時は経理担当者や情報システム担当が1人しかおらず、その人が業務の合間に自分の裁量で作ったものです。当時の担当者にとっては「ちょっとした効率化」だったものが、10年、20年と積み重なるうちに、誰もその全体像を把握できない「装置」になっていきます。

経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」でも、この構造そのものが指摘されています。レポートでは、システム関連業務が属人化しており、すべての経緯を把握するエンジニアが離職していると、今後の改修に必要な技術情報が継承されていない事態が起こりうると明記されています（経済産業省 商務情報政策局「DXの現在地とレガシーシステム脱却に向けて」2025年5月28日）。

システム関連の業務が属人化しており、すべての経緯を把握するエンジニアが離職していると、今後の改修に必要な技術情報が継承されていない事態も想定される。

これは大企業だけの話ではありません。むしろ情報システム専任者を置けない中小企業ほど、この構造がそのまま経営リスクに直結します。先代が元気なうちは「聞けば分かる」で済んでいたことが、承継のタイミングで一気に「誰も分からない」に変わってしまうのです。属人化は、承継期の中小企業が最も高い確率でつまずく壁の一つだと言えます。会社の規模が大きくなるほど、こうした見えない依存関係の数も増えていく傾向があります。

さらに厄介なのは、こうしたバッチ処理の多くが会社の基幹業務——請求書の発行、在庫データの連携、給与計算前のデータ集計——に静かに組み込まれていることです。表面上は何の問題もなく動いているように見えるため、「動いているなら触らないほうがいい」という判断が積み重なり、結果として誰も手を出せないレガシーシステムとして固定化されていきます。

株や登記には専門家がいるのに、バッチ処理には誰もいない

事業承継の場面では、株式の評価や名義変更は税理士が、登記の変更は司法書士が、それぞれ当たり前のように相談先として存在します。ところが、社内で動いているバッチ処理のような「見えにくいシステム資産」については、相談できる専門家が最初から用意されていません。顧問税理士に聞いても「それはうちの専門外です」と言われ、取引銀行の担当者もシステムの中身までは踏み込んできません。

この構造的な穴のせいで、多くの承継社長は「とりあえず様子を見る」という選択をしがちです。しかし、様子を見ている間にも、担当者の高齢化やパソコンの経年劣化は静かに進みます。専門家がいないからこそ、経営者自身が最低限の調査手順を知っておくことに価値があります。この記事で紹介する手順は、まさにその「相談先がいない領域」を自分の手でカバーするためのものです。

ステップ1: まず「止めずに」在り処を特定する

バッチ処理の正体を突き止める第一歩は、止めることでも中身を読むことでもなく、どこにあるかを特定することです。これは非IT出身の経営者でも、パソコンの基本操作ができれば十分に実行できます。

Windows環境であれば、以下の手順で登録済みのバッチ処理を一覧確認できます。

1. キーボードで「Windowsキー」+「R」を押し、「ファイル名を指定して実行」画面を開く
2. taskschd.msc と入力してEnterキーを押す(タスクスケジューラが起動する)
3. 左側のツリーから「タスクスケジューラライブラリ」を選択し、登録されているタスクの一覧を表示する
4. 見慣れないタスク名を見つけたら、それを選択して下部の「操作」タブを開く。実行されるファイルの保存場所(パス)が表示される

このパスさえ分かれば、正体不明だったバッチ処理が「どのフォルダの、どのファイルなのか」という物理的な所在に変わります。ここまでは実行中のプログラムを一切止めずに確認できるので、業務への影響はありません。

サーバー側でLinux系のシステムが使われている場合は、cron(クローン)と呼ばれる同種の仕組みが使われていることが一般的です。この場合は社内のIT担当者や委託先のエンジニアに「crontabの一覧を見せてほしい」と依頼するのが確実です。自社に分かる人がいない場合は、この時点で外部の技術者に調査を依頼する判断も選択肢に入ります。

ステップ2: バッチファイルの中身を「読む」のではなく「拾う」

在り処が分かったら、次はファイルの中身を確認します。ここで身構える経営者の方が多いのですが、プログラミングの知識がなくても、拾えるヒントは想像以上にたくさんあります。

バッチファイル(拡張子が .bat のファイル)は、実はメモ帳やテキストエディタで開くだけで中身を見ることができます。難しいプログラム言語ではなく、コマンドの羅列であることがほとんどです。全部を理解する必要はありません。以下のポイントだけ拾えれば十分です。

このステップで特に重要なのが、拡張子から推測できる「連携先」です。中小企業のバッチ処理は、Access（データベースソフト）や共有フォルダ上のExcelファイルを経由してデータをやり取りしているケースが非常に多く見られます。バッチ処理そのものより、その先につながっているデータベースやファイルのほうが、実は業務上の本体であることも珍しくありません。

ここまで来ると、「得体の知れない黒い画面」が、「請求書データを経理システム用のフォーマットに変換して、共有フォルダにコピーしている処理」というように、輪郭のある存在に変わってきます。

ステップ3: 業務側から逆算する「聞き取り」を組み合わせる

技術的な調査と同時に必ず行ってほしいのが、業務側からの聞き取りです。バッチ処理の担当者がすでに退職している場合、コードを読むだけでは「なぜこの処理が必要なのか」という背景までは分かりません。ここは現場の人にしか分からない領域です。

具体的には、以下のような質問を経理担当者や現場の責任者に投げかけてみてください。

• 「毎朝(あるいは毎月末)、決まった時間に届くファイルやメールはありますか?」
• 「このExcelファイル、誰が更新しているか知っていますか? 自動で更新されている感覚はありますか?」
• 「もしこの処理が急に止まったら、一番先に気づく業務は何ですか?」

先代の時代を知っている古参社員がいる場合は、この聞き取りが特に有効です。「あれは確か、取引先のA社にデータを送るために先代が作らせたものだ」といった記憶が、コードには残っていない背景情報を補ってくれます。承継後の会社では、こうした古参社員との対話そのものが、システムの正体を突き止めるための貴重な一次情報になります。技術的な調査と人への聞き取りを両輪で進めることで、初めてバッチ処理の全体像——「何を」「誰のために」「なぜ」動かしているのか——が見えてきます。

ステップ4: 依存関係を図にして「止めたら何が起きるか」を可視化する

在り処と中身、背景がある程度分かったら、次は「このバッチ処理が止まったら、どこに影響が及ぶか」を紙一枚、あるいはExcel一枚でいいので図にしてください。難しいツールは不要です。

「バッチ処理A」→「共有フォルダの在庫ファイルを更新」→「営業担当がそのファイルを見て受注可否を判断」→「もし止まれば、営業が古い在庫数のまま受注してしまう」

このように、処理の流れと、その先に誰の業務がつながっているかを言葉で書き出すだけで十分です。この作業を通じて、多くの経営者が気づくのは「このバッチ処理、実は特定の1台のパソコンでしか動かない設定になっていた」という事実です。担当者の私物に近いパソコンや、退職予定の社員のアカウントに紐づいたまま放置されているケースは珍しくなく、これはまさに単一障害点（SPOF）そのものです。そのパソコンが壊れる、そのアカウントが無効化される、その瞬間に会社の業務が止まるリスクを抱えたまま気づかずに経営していた、という状態です。

依存関係が見えてきたら、次のような表に整理しておくと、後々の判断がしやすくなります。

この一枚があるだけで、「触れない謎のバッチ処理」は「管理された業務プロセスの一部」に変わります。

ステップ5: 一時停止のテストは「閑散期」に「本人以外の立会い」で行う

ここまでの調査で影響範囲が見えてきたら、最後に実際の一時停止テストに進みます。ただし、これは繁忙期を避け、なるべく業務への影響が小さい時期(月末月初を避けた閑散期など)に、必ず複数人の立会いのもとで実施してください。

一時停止テストで確認すべきことは以下の3点です。

1. 停止した直後に、想定していた通りの業務(在庫確認、請求書発行など)にエラーや遅延が出るか
2. 停止して1日、あるいは1週間経過した時点で、想定していなかった別の業務に影響が出ていないか
3. 停止を解除して再開したとき、正常に元の状態へ戻るか

特に2番目が重要です。バッチ処理は、想像以上に離れた部署の業務にまで影響していることがあります。経理のためだと思っていた処理が、実は月末の給与計算の下準備も兼ねていた、というようなケースは、実際に現場でよく見られる話です。なお、バッチ処理以外の「触ると壊れる」と言われるシステム全般の改修手順は、「動いているから触るな」と古参社員に言われるシステムの安全な改修手順でも詳しく解説している。

調査を古参社員との関係構築の機会に変える

バッチ処理の調査は、単なる技術調査にとどまりません。先代の時代から会社を支えてきた古参社員にとって、後継社長から「あなたの知っていることを教えてほしい」と頼られる経験は、信頼関係を築く貴重な機会にもなります。

聞き取りの際に気をつけたいのは、「なぜこんな分かりにくい仕組みにしたのか」と原因を追及する姿勢を見せないことです。当時の担当者は、限られたリソースの中で最善を尽くしてその仕組みを作った可能性が高く、結果を否定するような聞き方をすると、以降の協力が得られにくくなります。「今の状態を正確に把握して、会社を止めないようにしたい」という目的を明確に伝え、あくまで敬意を持って聞き取りを進めることが、結果的に最も効率的に情報を引き出す方法です。急かさず、相手のペースに合わせて話を聞く姿勢も大切にしてください。

こうした調査を通じて、古参社員が「自分の知識が会社の役に立っている」と感じられれば、その後のシステム刷新や業務改善についても、協力的な姿勢を得やすくなります。バッチ処理の調査は、技術的な作業であると同時に、承継後の社内関係を築き直す第一歩でもあるのです。

先代自身がまだ会社に関わっている場合は、先代にも同じように聞き取りをしてみてください。古参社員でさえ知らなかった「そもそもなぜこの処理を作ったのか」という原点の経緯を、先代だけが知っていることがあります。先代が完全に引退する前のこのタイミングは、聞ける機会が限られている分、貴重な調査のチャンスでもあります。忙しい合間を縫って、短い時間でも構わないので声をかけてみましょう。

正体が分かったら「システム管理台帳」に必ず残す

苦労してバッチ処理の正体を突き止めても、それを記録に残さなければ、また同じ苦労を数年後に繰り返すことになります。担当者が変わるたびに、また一から「これは何をしているんだ」という調査をやり直すのは、時間的にも精神的にも大きな負担です。

ここで有効なのが、社内のIT資産を一覧化するシステム管理台帳です。大掛かりなシステムを導入する必要はなく、Excel1枚で構いません。今回突き止めたバッチ処理の情報(実行場所、実行時刻、入出力先、影響範囲、分かる人)を、先ほどの表の形式でそのまま台帳に転記しておくだけで十分です。

台帳を作る際は、次の点を意識してください。

• 「分かる人」の欄は複数人書けるようにする。1人しか書けない状態こそが属人化の温床です
• 最終更新日と確認日を分けて記録する。「いつ作られたか」と「いつ最後に確認したか」は別の情報です
• 年に1回、決算期など決まったタイミングで台帳を見直す。作りっぱなしでは意味がありません

中小企業庁も事業承継の実施にあたっては、経営権や資産の承継だけでなく、事業運営に必要な情報やノウハウの引き継ぎが重要だと位置づけています(参考:中小企業庁「事業承継を実施する」)。バッチ処理のような目に見えにくい業務資産も、この「引き継ぐべき経営資源」の一部だと捉えることが、承継を無事に終えるための一つの視点になります。台帳の作り方や承継後すぐに始めるべき記録の残し方については、引き継ぎ書がない会社が承継後すぐに始めるシステム記録術や属人化した先代システムを防ぐ、承継後の管理台帳の作り方も参考にしてほしい。

業種別に見る、バッチ処理が潜みやすい業務領域

バッチ処理の中身は業種によって傾向が異なります。自社の業種に照らして、優先的に疑うべき箇所の見当をつけてください。

製造業・卸売業では、在庫データの夜間更新や、複数の拠点間でのデータ同期にバッチ処理が使われていることが多く見られます。工場の生産ラインの稼働データと事務所の受発注システムを橋渡しする役割を、名もなきバッチファイルが担っているケースも珍しくありません。

小売業・サービス業では、POSレジの売上データを集計して翌朝の帳票にまとめる処理が典型的です。店舗が複数ある場合、各店舗のデータを本部のサーバーに集約する処理もバッチ化されていることがあります。

建設業・工事関連では、案件ごとの原価データを集計し、月次の実行予算と突き合わせる処理が使われることがあります。案件数が多い会社ほど、こうした集計処理が複雑化しやすく、担当者以外には全容が見えなくなりがちです。

いずれの業種でも共通するのは、バッチ処理そのものが目立たない存在であるがゆえに、承継のタイミングまで存在にすら気づかれないことです。棚卸しの際は、こうした業種特有の集計・連携処理がないかを意識して探してみてください。

調査でよくある3つの失敗パターン

ここまでの手順どおりに進めれば大きな失敗は避けられるが、実際に調査を始めた経営者からは、いくつか共通する失敗談が聞かれる。事前に知っておくことで、同じつまずきを避けやすくなる。

失敗パターン1: 繁忙期にいきなり一時停止テストをしてしまう

在り処と依存関係の調査までは順調に進んだのに、早く白黒つけたい気持ちが先行して、月末月初などの繁忙期にテストを実施してしまうケースがある。想定外の業務に影響が出た場合、繁忙期であるほど現場の負担と混乱が大きくなる。テストは必ず閑散期を選び、影響が出てもすぐに元へ戻せる体制で行うべきだ。

失敗パターン2: 聞き取りを経理担当者1人だけで済ませてしまう

バッチ処理は複数の部署をまたいで影響することが多いにもかかわらず、最初に見つけた1人の担当者への聞き取りだけで「分かった」と判断してしまうケースがある。本文のステップ4で紹介した依存関係の可視化を怠ると、経理担当者の知らないところで営業や製造の業務にも影響していた、という事実を見落とすことになる。聞き取りは1人で終わらせず、影響が及びそうな部署の担当者にも横断的に確認したい。

失敗パターン3: 調査した情報を台帳に残さず、記憶だけに頼ってしまう

苦労して正体を突き止めたのに、その情報を誰にも共有せず、経営者の頭の中だけに留めてしまうケースも少なくない。これでは結局、経営者自身が退任・交代するタイミングで、また同じ「属人化」が再現されてしまう。調査した情報は、必ず本文で紹介したシステム管理台帳に文字として残しておくことが、調査そのものと同じくらい重要な工程になる。

これら3つの失敗に共通するのは、いずれも「焦り」か「一人で抱え込むこと」に起因している。閑散期を選ぶこと、複数人に聞くこと、記録に残すこと——この3点さえ意識しておけば、調査の質は大きく安定する。

まとめ:正体不明のまま先送りするコストのほうが大きい

先代由来のバッチ処理を突き止める作業は、地味で、すぐに売上につながるものでもありません。だからこそ、多忙な経営者ほど後回しにしがちです。しかし、担当者の退職やパソコンの故障、WindowsのEOL（サポート終了）(サポート終了)といったきっかけは、経営者の都合とは無関係にやってきます。何の準備もないままその日を迎えれば、業務が突然止まり、原因究明だけで数日を費やす、という事態になりかねません。

今回紹介した5つのステップ——所在の特定、中身の確認、聞き取り、依存関係の可視化、慎重な停止テスト——は、いずれも専門的なプログラミング知識がなくても、経営者自身か、社内の担当者だけで実行できる内容です。まずは「触らない」から「観察する」へ、最初の一歩を踏み出してみてください。正体が分かれば、それはもう「怖いブラックボックス」ではなく、経営判断の材料にできる「管理対象」に変わります。ぜひ今日から、ゆっくりでよいので取り組んでみてください。

先代が築いた会社を次の世代へつなぐ作業には、株式や不動産のような目に見える資産だけでなく、深夜に静かに動くバッチ処理のような、目に見えにくい仕組みも含まれます。今日から少しずつ、その正体を明らかにしていくことが、将来のトラブルを防ぐ最も確実な備えになります。焦らず、一つずつ確かめていきましょう。

自分たちでは手に負えないとき、外部委託の費用感はどのくらいか

ここまで紹介した手順は経営者自身か社内の担当者で実行できる内容だが、バッチ処理が業種特有の複雑な連携をしている、あるいは調査する時間そのものが確保できない、という場合は、外部の開発会社に現状調査を依頼するという選択肢もある。

外部に依頼する場合、まず気になるのは費用感だろう。システム開発会社への依頼相場では、既存システムの現状調査(アセスメント)だけであれば数十万円から数百万円程度が目安とされ、この段階で得られた情報がその後の見積もり精度を大きく左右するとされている。バッチ処理1〜2本程度のピンポイントな調査であれば、この目安のうち低い側の金額に収まることが多いが、依存関係が複雑で複数のシステムにまたがる場合は、調査範囲が広がる分だけ費用も上がる。

依頼する際は、次の点を事前に伝えておくと、見積もりの精度が上がりやすい。

• 調査してほしいバッチ処理の数(分かっている範囲でよい)
• 本文のステップ1〜2で自社にて特定できた「在り処」の情報(伝えられる場合は事前に共有する)
• 調査の目的(単に現状を把握したいのか、将来的な刷新の判断材料にしたいのか)

自社である程度「在り処」と「聞き取り」まで済ませてから依頼すると、開発会社側の調査工数が減り、結果的に費用を抑えられる傾向がある。逆に、何も調べていない状態から丸ごと依頼すると、その分の初期調査費用が上乗せされることになる。

調査後、次にやるべきこと

正体を突き止め、台帳に記録できたら、次のステップとして「このバッチ処理を今後どうするか」の方針を決める段階に進みます。ここで焦って刷新や廃止を決める必要はありません。多くの場合、次の3つの選択肢のいずれかに落ち着きます。

• そのまま維持する：業務に不可欠で、大きな問題も起きていない場合、無理に手を入れずに維持する。ただし台帳での定期確認は継続する
• バックアップ体制だけ整える：処理自体は変えず、実行環境（パソコンやアカウント）が単一障害点にならないよう、代替の実行環境を用意しておく
• 将来的な刷新の候補にする：担当者の高齢化やOSのサポート終了が近い場合、次のシステム刷新の検討リストに載せておく

どの選択肢を取るにせよ、「調査して終わり」にせず、次に誰が、いつ、この情報を見直すのかを決めておくことが重要です。承継直後のこの一手間が、数年後の大きなトラブルを防ぐことにつながります。決めた方針は口頭で終わらせず、台帳の備考欄に一行でも書き残しておくことをおすすめします。この不具合対応を自分で引き取るか外部に相談するかの判断基準は、承継1年目、システムの不具合は自分で直すか開発会社に投げるかでも整理している。

それでは、ここまでの内容を踏まえてよくある質問に答えていきます。

よくある質問

Q. バッチ処理の中身を調べるとき、いきなり止めてみて確認してもいいですか?

おすすめしません。先代由来のバッチ処理は、請求書発行や在庫連携、給与計算のデータ受け渡しなど、業務の根幹に組み込まれているケースが多く、止めた瞬間に翌朝の出力が欠落して発覚する、というリスクがあります。まずは本文で紹介した手順で「何に依存し、何を出力しているか」を無停止で洗い出し、影響範囲が明確になってから、閑散期に本人以外の立会いのもとで一時停止のテストを行うのが安全です。

Q. バッチ処理を作った担当者がすでに退職していて聞けない場合はどうすればいいですか?

本人がいなくても正体は追えます。タスクスケジューラやcronの登録内容、バッチファイル自体の中身、更新日時、参照しているフォルダやファイルの拡張子は、担当者不在でも社内のPCとサーバーから直接確認できる一次情報です。加えて、経理や現場の担当者に「毎朝何時にどんなファイルが出てくるか」を聞き取ると、コードが読めなくても業務側から逆算して機能を特定できます。

Q. 調べた結果、誰も使っていない不要なバッチ処理だったらどうすればいいですか?

すぐに削除するのではなく、まず無効化して一定期間(1〜3ヶ月程度)様子を見ることをおすすめします。年次処理や決算期にだけ使われる休眠バッチの可能性があるためです。無効化した日付と担当者、確認した影響範囲を記録に残しておけば、万一問題が出ても即座に復旧でき、最終的に不要と確定した時点で正式に廃止という判断ができます。

Q. こうした調査を社内でやる時間がない場合、外部に依頼することはできますか?

可能です。ただし依頼する場合も、今回紹介した「所在の特定」「聞き取り」だけは社内で先に済ませておくことをおすすめします。外部の技術者はコードを読むことはできても、「なぜこの処理が必要になったのか」という社内の背景事情までは分かりません。社内で分かる範囲の情報を整理してから依頼したほうが、調査の精度もスピードも上がります。

Q. 調査の結果、複数のバッチ処理が互いに依存し合っていることが分かりました。どう扱えばいいですか?

処理同士の依存関係が複雑な場合は、無理に個別に整理しようとせず、まず全体の関連図を一枚にまとめることを優先してください。「処理Aの出力が処理Bの入力になっている」といった連鎖が見えてくると、どこか一箇所を変更した際の影響範囲が把握しやすくなります。こうした複雑な依存関係が見つかった場合は、それ自体が将来的なシステム刷新を検討すべき重要なサインでもあります。台帳に「要注意：処理間の依存関係あり」と明記し、次に手を入れる際の申し送り事項として残しておくとよいでしょう。焦って一度に全部を解きほぐそうとせず、一つずつ丁寧に確認していく姿勢が結果的に近道になります。