業務システムが止まったのに頼める会社がない――トラブル発生後の動き方

月末の請求処理を回そうとしたら、いつもの画面でエラーが出て先に進まない。何度かやり直しても同じところで止まる。前にこのシステムを作ってもらった会社に電話したら、番号が使われていない。メールも戻ってくる。社内を見回しても、中身が分かる人はいない――。

業務システムのトラブルで困るのは、不具合そのものよりも、その後に「では誰に頼むのか」で詰まる瞬間です。動いている間は意識しなかった保守の頼み先が、止まって初めて空白だったと分かる。保守契約を結んでいなかった、作った会社がもう連絡不能、社内に対応できる人がいない。このどれかに当てはまると、不具合の大小に関わらず初動が取れなくなります。

結論から書くと、こういう状態でも頼める会社はあります。保守契約がなくても、前の開発会社と連絡が取れなくても、仕様書や設計書が揃っていなくても、挙動から引き取って対応できるケースは現実にあります。ただし、頼む前にやっておくと結果が変わる初動がいくつかあり、ここを飛ばすと復旧も調査も遠回りになります。トラブルが起きてしまった後、頼り先のない中小企業が何から動けばいいのかを、現場の温度感のまま順に整理します。

なお、株式会社ニーズウェルが従業員1,000人以下の企業の決裁権限保持者1,005人に行った「システム運用の課題」に関する調査（2022年8月）では、システムトラブル時に管理者が社内にいる企業は60.6%で、約4割（39.4%）は社内に管理者がいないという結果が出ています。頼み先がない状態は、あなたの会社だけの特殊事情ではありません。

システムが止まったら、まず何をすればいいか

トラブルが起きた直後にいちばんやってはいけないのは、原因が分からないまま手当たり次第に触ることです。焦って動くほど、後で頼む会社が原因を追えなくなり、復旧が遠のきます。最初の数十分は、直そうとするより「被害を広げない」「今の状態を残す」ことに使ってください。

避けたい動きは、はっきりしています。

むやみな再起動を繰り返す: サーバやサービスの再起動で直る不具合もありますが、原因不明のまま何度も再起動すると、エラーの痕跡（ログ）が上書きされたり、中途半端な状態でデータが書き込まれたりすることがあります。再起動は一度試して様子を見る程度にとどめます。
データを上書きする操作: 「とりあえず入れ直せば直るかも」とデータを再投入したり、バックアップを上書きで取り直したりするのは危険です。元の状態が消えると、原因究明も復元も難しくなります。
自己流の修正: 設定ファイルやデータベースを直接書き換える、心当たりのある箇所を勘で直す、といった操作は、症状を別の形に変えてしまうことがあります。直ったように見えて、別の処理が静かに壊れているケースもあります。

代わりにやっておきたいのは、現状を記録することです。エラーメッセージは画面のスクリーンショットを撮り、文言をそのまま控えます。「いつから」「どの操作で」「どの画面で」「誰が操作したとき」起きるのかを、思い出せる範囲でメモにします。再現する操作が分かっているなら、その手順も書き留めておきます。この記録は、後で会社に頼むときの調査材料になり、ヒアリングの時間を大幅に短くします。

そのうえで、業務を止めないための手作業の止血を考えます。請求処理が止まったなら、その月だけ表計算ソフトで集計して請求書を出す。受注がシステムに入らないなら、いったん紙やメモで受け、復旧後にまとめて入力する。きれいなやり方ではありませんが、業務を完全に止めないことが、その後の判断の余裕を生みます。システムの復旧は急ぎたくなりますが、急ぐほど壊しやすいのが原因不明のトラブルです。止血と原因究明は分けて考えてください。

どこまで自社対応で、どこから会社に頼む範囲か

すべてを外部に丸投げする必要はありません。社内で切り分けられることを先にやっておくと、頼んだ後の動きが速くなり、調査の費用も抑えやすくなります。線引きの目安を整理します。

社内でできるのは、主に「症状の特定」と「影響範囲の把握」です。

どの業務・どの機能が止まっているのか、逆にどこは正常に動いているのか
いつから起きているか。直前に何か変わったこと（OS更新、ネットワーク工事、サーバ移転、担当者の操作）がなかったか
全員に起きるのか、特定の人・特定の端末だけか
インターネットや社内ネットワークの問題か、システム本体の問題か（他のサービスは見られるか、で大まかに切り分く）

ここまでは専門知識がなくても、観察と聞き取りで進められます。これが揃っているだけで、頼む側の説明が「なんか動かないんです」から「月末バッチが特定の条件でエラーになる」に変わり、相手も初動を組みやすくなります。

一方で、外部に頼る範囲は「原因の究明」と「修正」です。ログを読んでエラーの発生源を特定する、データの不整合を直す、コードやサーバ設定を修正する――こうした作業は、システムの中身に触れる必要があり、勘で進めると先ほどの「やってはいけない」に直結します。社内に対応できる人がいないなら、ここは無理に踏み込まず、会社に渡す方が安全です。

頼む前に揃えておきたい情報も整理しておきます。先ほど記録したエラー内容と再現手順に加えて、システムのおおよその構成（どの会社がいつ作ったか、どんな言語・環境か、サーバはどこにあるか）、ログイン情報やサーバの管理者権限が手元にあるか、ソースコードや仕様書が残っているか。これらが分かる範囲で揃っていると、初回の相談で「まず何を見るか」まで話が進みます。揃っていなくても頼めますが、揃っているほど調査は速くなります。

システムトラブルに対応してくれる会社には、どんな種類があるか

「システム障害に対応してくれる会社」と一口に言っても、得意な領域はかなり違います。自社の状況に合わない種類に頼むと、たらい回しになったり、断られたりします。大きく分けて押さえておくと、相談先を絞りやすくなります。

ひとつは、元の開発会社です。作った当人なので中身を最も分かっているはずで、連絡がつくなら第一候補になります。ただし、保守契約の有無、担当者が在籍しているか、そもそも会社が存続しているかで、頼めるかどうかが変わります。連絡がつかない・廃業した、というのが今回の前提なら、この選択肢は消えています。

次に、保守・運用を専門にする会社や**情シス代行（社内の情報システム部門を外部が代わりに担う形）**があります。日常的な運用監視や定型的な保守を引き受けるところで、契約ベースで安定して見てもらえるのが強みです。一方で、他社が作った素性の分からないシステムや、古い言語で書かれたものは「対象外」とされることがあります。

そして、他社が作ったレガシーシステムを引き取ることを専門にする会社があります。前の会社がいない、仕様書がない、古い環境で動いている――こうした「引き受け手が見つかりにくいシステム」を、挙動から調べて引き取ることを前提にしているタイプです。今回のような頼み先のないトラブルでは、この種類が現実的な受け皿になりやすいです。

ひとつ注意したいのは、データ復旧とは別だということです。「システム障害復旧」で検索すると、壊れたハードディスクやサーバから物理的にデータを取り出すデータ復旧の会社が多く出てきます。これは円盤が物理破損した、ファイルが消えた、といった場面の専門で、業務システムのエラーや動作不良を直す仕事とは別の領域です。物理的にディスクが壊れたのでなければ、頼むべきはデータ復旧ではなく、システムの中身を見られる会社です。ここを取り違えると、見当違いの相手に時間を使ってしまいます。

固有の社名は挙げませんが、自社の状況が「契約のある定型保守」なのか「素性の分からないシステムの緊急の引き取り」なのかで、向く相手は変わります。今止まっていて、前の会社もいない、という状況なら、引き取りを前提にした会社を軸に探すのが近道です。

保守契約がない・前の開発会社と連絡が取れなくても頼めるのか

ここがいちばん不安に感じられるところだと思います。結論を先に書くと、保守契約がなくても、前の開発会社と連絡が取れなくても、頼めます。トラブルで初めて「契約していなかった」と気づいた、というのはよくある相談で、それ自体は対応を断る理由になりません。

頼み方として現実的なのは、いきなり保守契約を結ぶのではなく、単発で調査だけ依頼する形です。「まず一度、何が起きているか見てほしい」という単発の調査・診断から入れる会社なら、契約に縛られずに第一歩を踏めます。月額の保守契約は、原因や状態が見えてから検討すれば十分です。最初の相談で長期契約を前提にされると、止まっている最中の判断としては重すぎます。契約に縛られずに動きたい場合は、使った分だけ払う業務システム保守も合わせて読んでみてください。単発で調査だけ頼む頼み方を扱っています。

ソースコードや仕様書が揃っていなくても、挙動から引き取れる場合があります。システムが今も動いている（または動いていた）のであれば、その動き方そのものが手がかりになります。画面の挙動、データの中身、エラーの出方を外側から観測して、構造を少しずつ読み解いていく進め方です。前の会社がいない、資料がない、というのは確かに難易度を上げますが、「だから無理」と即断する話ではありません。

前の開発会社が廃業・連絡不能でも対応できるのは、まさにこの「挙動から読む」前提に立っているかどうかで決まります。元の作り手に聞けることを前提にした会社だと、連絡がつかない時点で手が止まります。一方、他社のシステムを資料なしで引き取ることを織り込んでいる会社なら、連絡不能はスタート地点の一条件にすぎません。

私たち three dots. のシステムレスキューも、この前提で動いています。保守契約がない状態からの単発の調査、前の会社が廃業・連絡不能のケース、ソースコードや仕様書が揃わないシステムの引き取りを、挙動から調べて対応します。料金は月額固定ではなく、実際に動いた分だけの実働ベース（従量課金）なので、「まず調査だけ」という小さな入り方ができます。頼み先がないまま止まっている状態こそ、こうした入り方が合います。

「直してくれる会社」を選ぶとき何で見極めるか

止まっている最中は、声をかけてくれる会社に飛びつきたくなります。ただ、ここで相手を見る目を一段持っておくと、後の負担がかなり変わります。トラブル対応を頼む会社を選ぶときに効く見極めの観点を挙げます。

いきなり作り直しを勧めてこないか: 状況も見ないうちから「全部作り直しましょう」と言ってくる相手は、目の前のトラブルではなく新規開発を売りたいだけの場合があります。まずは止まっている原因を切り分け、最小限で復旧させる発想を持っているかを見ます。今のトラブルと全面刷新は、分けて考えるべき別の話です。
調査だけ小さく頼めるか: 最初から長期契約や大きな見積もりを前提にせず、「まず調査・診断だけ」という小さな単位で受けてくれるか。止まっている最中に大きな決断を迫られるのは、判断材料がない中では危険です。
料金の出方が分かりやすいか: 月額固定なのか、動いた分だけの実働ベースなのか。トラブル対応のように作業量が読みにくい場面では、使った分だけの実働ベースの方が、最初の一歩を踏みやすいことが多いです。固定と実働ベースの向き不向きは月額固定と実働ベースはどっちが得かで整理しています。
経緯や資料がなくても引き取る姿勢があるか: 「ソースコードはありますか」「仕様書をください」「前の会社の連絡先は」と、揃っていない前提で詰まってしまう相手か、それとも資料がない状態を出発点として受け止める相手か。今回のような状況では、ここが決定的に効きます。

この4つは、いずれも「目の前のトラブルを最小限で収めてくれるか」を別の角度から見たものです。逆に、状況を見る前から大きな話を持ち出してくる、契約ありきでしか動かない、資料がないと門前払い、という反応が出るなら、急いでいても一度立ち止まる材料になります。止まっている弱みにつけ込まれないために、この目線だけは持っておいてください。

頼んだあと、同じトラブルを繰り返さないために

無事に復旧したとして、そこで終わりにすると、同じ場所でまた止まります。トラブル対応には、その場をしのぐ「止血」と、原因を断つ「恒久対応」の2段階があり、混同すると再発します。

止血は、業務を回すために症状を一時的に抑える対応です。エラーを回避する設定を入れる、問題のあるデータを手で直す、止まった処理を手作業で代替する――いずれも「今日を乗り切る」ための応急処置で、原因そのものは残っています。一方の恒久対応は、なぜそのエラーが起きたのか、根本の原因を特定して直すことです。止血で業務を戻したら、落ち着いたタイミングで恒久対応に進む、という順番が現実的です。止血だけで「直った」と片づけると、同じ条件が揃ったときに再発します。

恒久対応は、必ずしも一度に大改修する必要はありません。原因を特定したうえで、影響の大きい箇所から段階的に直していくやり方があります。仕様書がない状態からどう段階的に直すかは仕様書のない業務システムは直せるのかで4段階に分けて整理しています。

そして、今回のいちばんの教訓は「頼み先がなかった」ことだったはずです。再発防止と同じくらい大事なのが、次に止まったときに同じ状況に陥らない備えです。具体的には、ソースコードと管理者権限が手元にあるかの確認、いざというときに相談できる第二の保守先を関係として持っておくこと、システムの構成や経緯を簡単にでも記録しておくこと。これらをやっておくと、次のトラブルでは初動の選択肢が段違いに広がります。連絡が取れなくなる前に打てる備えは業務システムを頼んだ会社と連絡が取りづらいにまとめてあるので、復旧後の落ち着いた段階で目を通しておくと、同じ思いをせずに済みます。

よくある質問（FAQ）

システムが止まったのに頼める会社がない時、どうすればいい？

まず触らず、現状を記録することから始めます。原因不明のまま再起動やデータの上書きを繰り返すと、後で頼む会社が原因を追えなくなります。エラー内容と再現手順を控え、業務は手作業で止血しつつ、他社のシステムでも単発の調査から受けてくれる会社を探すのが現実的な順番です。

保守契約を結んでいなくても、見てもらえる？

見てもらえます。保守契約がないことは、対応を断る理由にはなりません。いきなり月額契約を結ぶのではなく、「まず一度調べてほしい」という単発の調査・診断から入れる会社を選べば、契約に縛られずに第一歩を踏めます。長期契約は状態が見えてから検討すれば十分です。

前の開発会社が廃業・連絡不能でも対応してもらえる？

対応できる会社があります。鍵は、元の作り手に確認できることを前提にしているかどうかです。他社のシステムを資料なしで引き取ることを織り込んでいる会社なら、連絡不能はスタート地点の一条件にすぎません。逆に、前の会社への確認ありきで動く相手だと、連絡がつかない時点で手が止まります。

ソースコードや仕様書が残っていなくても頼める？

頼める場合があります。システムが今も動いている（動いていた）なら、その挙動そのものが手がかりになります。画面の動き、データの中身、エラーの出方を外側から観測して構造を読み解く進め方です。資料がないと難易度は上がりますが、それだけで「無理」と即断する話ではありません。

緊急ですぐに直りますか？

正直なところ、原因によります。設定や軽微なデータの問題ならその日のうちに目処が立つこともありますが、原因が深い場合は調査に時間がかかります。即日復旧や「必ず直る」を約束する相手より、まず何が起きているかを切り分け、止血と恒久対応を分けて現実的な見通しを示してくれる相手の方が、結果として早く落ち着きます。焦って大改修に飛びつくより、被害を広げない初動を踏むことが、最短の近道になることも多いです。

止まった時こそ、小さく頼める相手を

業務システムが止まり、頼める会社もない――この状況は、初動さえ間違えなければ、思っているより手が打てます。むやみに触らず現状を記録する、社内で症状を切り分ける、データ復旧ではなく中身を見られる会社を探す、いきなり作り直しを勧めない相手を選ぶ、止血と恒久対応を分ける。この順番を踏めば、頼み先がない中でも前に進めます。

そして、保守契約がない・前の会社が廃業・連絡不能・資料が揃わない、という条件は、対応できる会社にとっては珍しいものではありません。私たち three dots. のシステムレスキューは、こうした引き取りにくいシステムを挙動から調べて引き取り、実働ベース（使った分だけ）でお引き受けしています。「まず一度、調査だけでも」という入り方ができるので、止まっている最中の重い決断を先送りにしたまま、状況把握から始められます。

システムレスキュー

開発会社が廃業した、連絡が取れない、仕様書が残っていない。そんな業務システムのトラブルを、挙動から調べて引き取ります。保守契約がない状態からの単発の調査・診断にも、実働ベースで対応しています。

/service/system-rescue/

復旧後の備えや、契約に縛られない頼み方は、次の記事も参考になります。

使った分だけ払う業務システム保守――「スポット保守」と実働ベース料金の現実解

月額契約を結ばずに、調査だけ・必要なときだけ実働分を払う頼み方を整理しています。トラブル発生後の小さな第一歩に使えます。

/blog/business-system-spot-maintenance/