Cron jobs引継ぎ漏れで月次売上が消える
買収から最初の月末。買い手側の経理が月次の売上を確認すると、サブスクリプションの請求が一件も発行されていなかった。サービスは正常に動いている。ユーザーはログインでき、機能も使える。しかし「毎月1日の午前3時に全契約者へ請求を発行するバッチ」が、サーバー移行のときに引き継がれていなかった。誰もそのcronの存在を知らなかったからだ。その月の定期売上は、丸ごと宙に消えた。
これは、スマホアプリの署名鍵やCloudflareの設定と並ぶ、M&Aにおける「見えない事業の心臓」の問題だ。多くの事業は、人間が手を動かさなくても回る定期処理 ── 請求発行、サブスク更新、決済リトライ（督促）、レポート生成、データ同期、ライセンス更新、クリーンアップ ── によって、収益と運用が静かに支えられている。これらのバッチ処理は財務諸表に現れず、システム構成図にも書かれず、多くの場合ドキュメントすら存在しない。
本稿では、事業の収益と運用を支える定期処理（cron jobs / スケジュールバッチ）が、なぜM&Aで引き継ぎ漏れを起こすのか、どこに隠れているのか、棚卸しと引き継ぎの実務手順、そして定期処理の品質をバリュエーションにどう織り込むかを、現場目線で整理する。
1. なぜ定期処理は引き継ぎ漏れを起こすのか
1-1. 「動いているから誰も触らない」が招く知識の消滅
定期処理の多くは、一度設定されると人間の介在なしに動き続ける。動いている限り誰も触らず、設定した本人が退職すれば、その存在と意図はチームの記憶から消える。残るのは「なぜか毎月ちゃんと請求が出ている」という結果だけだ。事業が回っているという事実が、逆にバッチの存在を不可視にする。
M&Aでサーバーを移行したり、インフラを再構築したりするとき、可視化されているアプリケーションコードは移される。しかしcrontabの一行、スケジューラの設定、外部の自動化ツールに仕込まれたジョブは、棚卸しされなければ移されない。「動いているから安全」ではなく、「動いている理由を誰も説明できないから危険」なのだ。
1-2. 失敗が静かである ── 検知の遅れが損失を拡大する
定期処理の引き継ぎ漏れが厄介なのは、失敗が静かなことだ。リアルタイムのAPIが落ちれば即座にエラーが噴出し、すぐ気づく。しかしバッチが動かなかった場合、エラーは出ず、ただ「起きるべきことが起きない」だけだ。請求が発行されない、メールが送られない、データが同期されない ── これらは月末の照合や顧客からの問い合わせで初めて発覚する。
発覚が遅れるほど損失は拡大する。請求が一ヶ月止まれば一ヶ月分の売上が消え、督促バッチが止まれば失敗した決済が回収されず解約に至り、データ同期が止まれば不整合が蓄積して後から手作業で修復することになる。静かな失敗は、気づいたときには取り返しがつかない規模になっている。
2. 定期処理はどこに隠れているか ── 棚卸しの捜索範囲
2-1. OSレベル ── crontab・systemd timer
最も古典的なのが、サーバーのOSレベルに仕込まれた定期処理だ。Linuxのcrontab（ユーザーごと・システム全体）、/etc/cron.d、systemd timer、atジョブなど、複数の場所に分散している可能性がある。特定のユーザーのcrontabにしか登録されていないジョブは、そのユーザーでログインしないと見えない。
棚卸しでは、全ユーザーのcrontab、/etc/crontab、/etc/cron.d、/etc/cron.daily等、systemctl list-timersの出力をすべて取得する。「アプリは動いているサーバーを移せば終わり」という発想は、OSレベルのスケジューラを見落とす。サーバーをそのまま移行しない（再構築する）場合は特に危険だ。
2-2. アプリケーションレベル ── ジョブスケジューラ
近年は、OSのcronではなくアプリケーションフレームワーク側のスケジューラを使うことが多い。Sidekiq/Sidekiq-cron、Celery beat、node-cron、Laravel Scheduler、Quartzなど、フレームワークごとに仕組みが異なる。これらはコードベースの中に定義されているため一見追いやすいが、設定がコードと環境変数とDB設定に分散していることがある。
さらに、ジョブの実行にはワーカープロセスの常駐が必要で、ワーカーが起動していなければジョブはキューに溜まるだけで実行されない。移行時にワーカーの起動を忘れる、あるいは並列度の設定を誤ると、ジョブが滞留する。棚卸しでは、定義されているジョブ一覧と、それを実行するワーカーの稼働状況の両方を確認する。
2-3. プラットフォーム・外部ツール ── マネージドcronとSaaS自動化
クラウドネイティブな事業では、定期処理がプラットフォーム側に置かれている。Vercel Cron、Cloudflare Cron Triggers、クラウドのスケジューラ、GitHub Actionsのschedule、各種マネージドジョブなどだ。さらに、ZapierやMake等のノーコード自動化ツールに、業務上重要なフロー（決済通知、CRM同期、レポート配信）が仕込まれていることもある。
これらは旧オーナーのアカウントに紐づいているため、アカウント移管が済まなければ動き続けるか、あるいは止まる。外部の自動化ツールに仕込まれた業務フローは、システム構成図にもコードにも現れない最も発見しにくい定期処理だ。棚卸しでは、利用中の全SaaSのアカウントと、そこに設定された自動化を洗い出す。
3. 棚卸しの実務 ── 全ジョブの台帳化
3-1. ジョブ台帳に記載すべき項目
発見した定期処理は、一件ずつ台帳化する。記載すべきは、①ジョブ名と目的、②実行スケジュール（頻度・時刻・タイムゾーン）、③実行場所（どのサーバー/プラットフォーム/アカウント）、④依存する環境変数・シークレット・APIキー、⑤このジョブが止まると何が起きるか（業務影響）、⑥冪等性の有無（再実行・二重実行の安全性）、⑦監視・アラートの有無、⑧オーナー（責任者）。
この台帳は、移行時の引き継ぎチェックリストになると同時に、買い手にとっては事業がどれだけ自動処理に支えられているかを可視化する資料になる。ジョブ台帳が存在する事業は、それ自体が「運用が可視化された事業」として技術DDで高く評価される。
3-2. タイムゾーンと多重実行という落とし穴
移行時に頻発する事故が、タイムゾーンのずれと多重実行だ。旧環境がJSTで動いていたバッチを、UTC設定の新環境にそのまま移すと、実行時刻が9時間ずれる。月初の請求が想定と違う日時に走り、締め処理と矛盾を起こす。タイムゾーンはジョブ台帳に必ず明記し、移行後に実行時刻を検証する。
多重実行は、移行期間中に旧環境と新環境の両方でバッチが動いてしまうケースだ。冪等でないバッチ（請求発行・メール送信など）が二重に走ると、顧客に二重請求・二重メールが届く。移行時は「旧環境のジョブを確実に停止してから新環境を有効化する」という切り替え順序を、ジョブ単位で設計する必要がある。
4. 定期売上との接続 ── 収益を支えるバッチの特定
4-1. 収益クリティカルなジョブの分類
全ジョブの中でも、収益に直結するものは別格の扱いが必要だ。サブスクリプションの更新処理、請求・インボイス発行、決済の自動実行、決済失敗時のリトライ（dunning/督促）、ライセンスや利用上限の更新 ── これらが止まると、収益が直接的に消失する。台帳の中でこれらを「収益クリティカル」として分類し、移行時の優先度と監視レベルを最高に設定する。
特に督促（dunning）処理は見落とされやすい。決済が失敗した顧客に自動で再試行・再通知を行うバッチが止まると、本来回収できた売上が回収されず、そのまま解約に流れる。督促バッチの停止は、解約率の悪化という形で遅れて事業価値を蝕む。
4-2. バッチ停止の収益感応度をDDで試算する
買い手の技術DDでは、収益クリティカルなジョブが一定期間停止した場合の収益影響を試算する。月次請求バッチが1サイクル止まれば月商の何割が消えるか、督促バッチが止まれば解約率がどれだけ悪化するかを、過去の決済成功率・回収率データから推定する。
この試算は、定期処理の引き継ぎを「技術的な作業」から「収益リスクの定量評価」へと引き上げる。収益クリティカルなバッチの引き継ぎ完了を、クロージング条件あるいは移行完了の検証項目として契約に組み込むべきだ。バッチ一つの引き継ぎ漏れが、買収後の最初の月の損益計算書を狂わせる。
5. バリュエーションとチェックリスト
5-1. 定期処理の成熟度をバリュエーションに反映する
定期処理の成熟度は、運用リスクの指標として評価できる。ジョブが台帳化され、冪等に設計され、失敗時にアラートが飛び、再実行手順が文書化されている事業は、移行リスクが小さく減点幅も小さい。逆に、誰も全容を把握しておらず、単一サーバーのcrontabに散在し、監視もない事業は、移行失敗による収益消失リスクを抱えており、相応の割引が必要だ。
この観点は、事業の「運用の引き継ぎやすさ」を測る代理指標でもある。自動処理が可視化・監視されている事業は、人が抜けても回る事業であり、それ自体がバリュエーションの加点要素になる。
5-2. 買い手・売り手のチェックリスト
買い手は、①全定期処理の台帳の開示要求、②収益クリティカルなジョブの特定とバッチ停止の収益感応度試算、③冪等性・監視・再実行手順の有無、④外部SaaS自動化の棚卸し、⑤移行時の切り替え順序とタイムゾーン検証計画、を確認する。
売り手は、買収交渉前に全定期処理を棚卸しして台帳化し、収益クリティカルなジョブに監視を入れ、移行手順を文書化しておく。「人が手を動かさなくても回る仕組み」を可視化して提示できる売り手は、買い手の最大の不安 ── 移行後に何が静かに止まるか分からないという不安 ── を解消できる。定期処理の棚卸しは、見えない心臓を可視化する作業であり、技術的DDの要諦の一つだ。
結論：事業は「動いているコード」ではなく「動き続ける仕組み」で価値を持つ
リアルタイムに動くアプリケーションは目に見え、検証もしやすい。しかし事業の収益と運用を静かに支えているのは、月に一度、夜中に誰にも気づかれず走る定期処理だ。これらは財務諸表にもシステム構成図にも現れないが、止まった瞬間に月次売上を消し、解約率を悪化させ、データ整合性を崩す。
M&Aにおける定期処理の棚卸しは、「動いている理由」を可視化し、買い手が確実に引き継げる状態に翻訳する作業だ。売り手にとっては自動処理の成熟度が事業価値を守り、買い手にとってはバッチ停止の収益感応度が買収リスクの実像を映す。技術的DDの本質は、こうした「見えないが事業を回している仕組み」を数字と手順に翻訳することにある。Cron jobsは、その最も地味で、最も致命的な論点の一つだ。
