仕様書のない業務システムは直せるのか――現状把握から始める段階的な改修の手順

「設計書がどこにも見当たらないんですよ。社内で探したんですが、紙でも電子でも残っていなくて」――引き継ぎ時のヒアリングで、繰り返し耳にするセリフです。担当者が辞め、開発会社との付き合いも切れ、手元には動いているソースコードだけ。仕様書も設計書もないまま、それでも業務は毎日回っています。

別の開発会社に相談すると、「仕様書がないから引き受けられない」「全面的に作り直すしかない」と断られる。一方で、現業を止めずに数千万円を投じる踏ん切りもつかない。多くの中小企業が、この間で立ち止まっています。

仕様書がなくても、ソースコードと動いているシステムがあれば、現状を読み解いて段階的に直す道は残っています。本記事では、その進め方を4段階に分け、自社で進める場合と外注する場合の判断軸まで、引き取り案件の現場から整理します。

「仕様書がない」とは具体的にどういう状態か

「仕様書がない」状態は、設計書紛失・実装乖離・断片化・検証手段欠如の4段階に分かれます。どの段階かで、対応の難易度も打ち手も変わるため、最初に自社のシステムがどこに当てはまるかを見極めます。

実際に弊社が引き取る案件は、これらの段階が複合的に絡んでいることがほとんどです。

段階1：設計書そのものが紛失している

紙の設計書がキャビネットを探しても見つからない、共有ドライブにも電子ファイルが残っていない――いちばん極端な状態です。導入から10年以上経った業務システムで、開発を担当した会社との関係も切れている場合に多く見られます。

この段階では、システムの「正解」を知る資料がどこにもありません。手元にあるのは、サーバー上で動いているソースコードと、日々それを使っている現場担当者の記憶だけです。

段階2：設計書はあるが、実装と乖離している

「設計書はあります」と言われて開いてみると、最終更新が10年前で、画面構成も処理の流れも今のシステムとは別物だった――これも珍しくありません。

度重なる小改修のたびに実装だけが進み、設計書は更新されないまま放置されてきた結果です。形式上の資料はあっても、信用して読めない以上、無いのとほとんど変わりません。むしろ「資料があるから大丈夫」という油断が、判断を遅らせる場合もあります。

段階3：仕様の断片だけが残っている

メールの添付ファイル、誰かの手元のExcel、退職者が残したWord――断片的な仕様メモは社内のあちこちに散らばっているが、体系立った1冊にはまとめられていない、という状態です。

断片が点在しているぶん「何かは残っている」感覚になりやすいのですが、点と点をつなぐと矛盾が出る、というのが現実です。「ここに書かれている処理は、別の人がメールで否定している」といったことが起きます。

段階4：動いてはいるが、テストもCIもない

ソースコードはサーバー上で動いている。日々の業務もこなしている。しかし、自動テストもCI（コードを変更するたびに自動で検証する仕組み）も整備されていない――この状態が、改修時のリスクを大きくします。

「直したら別の場所が壊れた」が起きたときに、それを変更前に検知する仕組みがありません。結果として、改修すること自体が経営的に怖くなり、誰も触らなくなります。

弊社が「動いてはいるが、もう誰も中身を触れない」と表現するのは、まさにこの状態です。

ドキュメントが消えていく構造的な背景については、レガシーシステムの運用管理を立て直す3つの手順で詳しく整理しています。本記事は、その先にある「具体的な改修の進め方」に踏み込みます。

なぜ仕様書はなくなるのか

仕様書は、担当者の退職・小改修の積み重ね・「動いているから触らない」文化という3つの構造的な理由で、ゆっくり失効していきます。「自社だけの不手際」ではない、という前提を共有しておきます。

担当者の退職と開発会社の廃業

業務システムの導入から10年も経つと、当時の担当者は社内にも社外にも残っていない場合がほとんどです。社内SEは転職や定年を迎え、開発を請け負った会社も廃業や事業縮小で連絡がつかなくなる。「正解を知っている人」が、組織からも市場からも消えていきます。

度重なる小改修の積み重ね

「請求書のフォーマットを少し変えてほしい」「税率改定に対応してほしい」――現場の小さな要望に応えるうち、実装だけが先行し、設計書の更新は後回しになります。10年積み重なれば、実装と設計書の距離は致命的に開きます。

「動いているから触らない」文化

過去に改修でトラブルを起こした記憶があると、関係者全員が積極的に距離を置くようになります。問いを立てること自体がタブー化し、誰も棚卸ししません。

こうした構造のもとで、保守の先送りが経営リスクにどう転じるかは、中小企業がシステム保守を後回しにできない3つの理由で整理しています。

仕様書のないシステムをどう直すか――4段階のアプローチ

いきなり改修に入らず、「トリアージ → 挙動の記録 → 部分的な仕様化 → 改修」の順で進めるのが現実的です。全画面・全機能の仕様書を作り直してから始めようとすると、ほぼ間違いなく頓挫します。

それぞれのステップで何をするか、順に見ていきます。

ステップ1：トリアージ（救うべき機能を絞る）

最初にやるのは、システムの全機能を「日次で使うもの」「月次・年次で使うもの」「実は誰も使っていないもの」に仕分ける作業です。トリアージ、つまり優先順位づけです。

現場で見ていると、長く使われてきた業務システムには、必ず「過去の名残で残っているだけで、今は誰も触らない画面」があります。経理担当が退職時に作り、後任には引き継がれず、メニューにだけ残っている処理。年に1度の集計用に作ったが、近年は別のExcelで代替されている画面。こうしたものは、改修対象から外して構いません。

仕分けは、業務担当者へのヒアリングと、可能であればアクセスログの収集で行います。「自分が普段使っている画面」を業務担当者に書き出してもらい、システムの全画面と突き合わせると、案外1割や2割は使われていないことが分かります。

ここで救う対象を絞り込めれば、後続のステップの工数は大きく下がります。

ステップ2：挙動の記録（外側から「何をしているか」を観測する）

救う対象が決まったら、その機能が「何を入力したら、何を出力するのか」を外側から記録します。中のコードを読み解く前に、まず外から見える挙動を押さえる、という順番です。

具体的にやるのは、次のような作業です。

主要画面の操作を画面録画ツールで動画として残す
テストデータを入力し、画面表示・帳票出力・データベースの変化を記録する
バッチ処理の入力ファイルと出力ファイルを保管し、対応関係を把握する
アクセスログ・SQLログを一定期間収集し、実際に呼ばれている処理を観測する

これらは、ソースコードが読めなくても進められる作業です。社内の業務担当者と、操作を見たことのある人がいれば、外側から「いま何が起きているか」をかなりの精度で記録できます。

挙動の記録には、もう一つ大事な効果があります。改修後に「前と同じ動きをしているか」を比較する基準が作れることです。テストがない前提でも、改修前の入出力データが残っていれば、改修前後の差分を突き合わせて検証できます。

ステップ3：部分的な仕様化（必要な分だけドキュメント化する）

挙動が記録できたら、改修対象とその周辺だけ、現行仕様としてドキュメントに起こします。ここでも全画面の仕様書を一度に作ろうとはしません。

弊社が「仕様書再生サービス」のような網羅型のドキュメント化を積極的に勧めないのは、過剰投資になりやすいからです。全画面の仕様書を作っても、その8割は今後も読まれません。読まれない資料に数百万円を投じるより、改修対象の周辺だけを60点の精度でドキュメント化し、改修と並行して厚みを増していくほうが、費用対効果は高くなります。

仕様書は「網羅性」より「業務との対応関係」のほうが大切です。100点の設計書を1冊揃えるより、60点でいいから業務フローに紐づいた資料を一式揃えるほうが、現場では何倍も役に立ちます。

ドキュメント化するのは、次のような最小限です。

改修対象画面の入出力項目とバリデーション
関連するデータベースのテーブル定義と、改修で影響しそうなリレーション
業務フロー上の位置づけ（前後にどの処理がつながるか）
「これは確認できなかった」という要確認リスト

要確認リストを残すことが、意外と重要です。後で別の改修が入ったときに「ここはまだ不明」だと分かっていれば、慎重に進められます。

ステップ4：影響範囲を絞った改修と検証

ここまで来てやっと、改修に着手します。原則は、改修を最小単位に分けることです。

「ついでに直したい」要望をまとめて1回でやろうとすると、影響範囲が読めなくなります。1つの改修に1つの目的、1つのリリース。地味ですが、これが仕様書のない環境で事故を起こさない最大のコツです。

改修後の検証は、ステップ2で記録した挙動と突き合わせます。改修前の入力データを再投入して、出力（画面・帳票・データベースの状態）が想定どおりに変わっているかを確認する。改修したい箇所以外は、改修前と同じ結果になっていれば、影響範囲は閉じている、と判断できます。

検証環境は、本番とは別に用意します。本番データのコピー（個人情報をマスクしたもの）で検証できる環境を、改修プロジェクトの最初に作っておくのが安全です。

やってはいけない3つのこと

経営判断としては、次の3つを避けてください。どれも善意で踏みがちな道ですが、結果的に費用も時間も大きく失います。

仕様書のないシステム改修で避けるべき3つの判断

「全部のドキュメントを作り直してから」と構える — 網羅型のドキュメント化は、終わりが見えないまま費用倒れになりがちです。改修対象の周辺だけに絞ってください。
本番環境でいきなり直す — 検証環境を用意せずに本番を触ると、戻せなくなります。改修前のデータコピーで、必ず一度試してください。
全面作り直しに即決する — 業務知識まで一緒に捨ててしまう恐れがあります。10年使ってきたシステムには、文書化されていない業務ノウハウが埋め込まれています。

3つ目の「全面作り直しの即決」を避けるべき理由は、見積もりの観点からも整理しています。詳しくは業務システムのリプレース見積もりが高すぎる時の妥当性を見極める3つの基準を参照してください。

自社で進めるか、外注するか――判断の3軸＋当時の経緯

判断は「技術的に読めるかどうか」よりも、「業務影響範囲」「使われている技術の希少さ」「期限の有無」の3軸に、「当時の経緯を知る人が残っているか」を加えて決めるのが現実的です。社内エンジニアが多少読めても、影響範囲が広く期限も近ければ、外注を組み合わせたほうが安全です。

そもそも作り直すか、段階改修で延命するかという一段上の判断については、古いシステムの作り直しは正解？3つの選択肢と判断基準で扱っています。本章は「段階改修でいく」と決めた前提での、自社／外注の切り分けです。

判断軸	自社で進めやすい	外注を組み合わせたい
業務影響範囲	限定的な1機能の改修	基幹業務全体に影響する
技術スタック	社内で現役の言語・環境	古いPHPやJava、サポート切れOSなど社内で読める人がいない
期限	業務に余裕があり、試行錯誤できる	法対応・税制改正など外部要因で期限が決まっている
当時の経緯	当時を知る社員がまだ社内にいる	開発関係者がすでに退職・廃業している

いずれか1つでも「外注側」に振れているなら、外注の検討は早めに始めたほうが安全です。

外注先を選ぶときの3つのチェック

仕様書のない前提で外注する場合、開発会社の選定で必ず確認したい点が3つあります。

仕様書がない前提で着手してくれるか — 「仕様書がないと見積もれません」と返ってくる会社は、この案件には向きません。ソースコードと稼働環境から読み解く解析力があるかを確かめてください。
全面再構築を即勧めないか — 中身を見る前から「作り直したほうが早いです」と提案してくる会社は、自社の都合を優先している可能性があります。
段階見積もりを出せるか — 「全部で数千万円」の一発見積もりではなく、「まず診断で数十万円、その後の改修は内容を見て」という分割見積もりが出せるか。これは誠実さを測る分かりやすい指標です。

開発会社の選び方の詳細は、社内SEが退職したら？システム保守を任せる開発会社の選び方で整理しています。本記事の3点は、仕様書なし前提で特に重要な観点に絞ったものです。

three dots. システムレスキューでの対応例

弊社の引き取り案件は、ほぼすべて「仕様書のない状態」から始まります。前出の4段階アプローチを、案件ごとに調整しながら適用してきました。外部公開可の2件を紹介します。

塗装業（30名）：他社に引き継ぎを断られた業務システム

担当者が退職し、他の開発会社にも引き継ぎを断られた状態のご相談でした。仕様書はなく、ソースコードと稼働しているサーバーだけが残っている、典型的な「段階1＋段階4」の状態です。

画面の操作録画と業務担当者へのヒアリングを並行し、日々使われている機能を絞り込み（ステップ1〜2）、改修対象の周辺だけ仕様を書き起こしたうえで（ステップ3）、業務影響の大きい箇所から最小単位で改修していきました（ステップ4）。結果として、全面刷新せずに業務システムをそのまま引き取り、属人化から組織で支える保守体制へ切り替えることができました。

サービス業（50名以上）：20年来の内製基幹システム

社内で内製していた基幹システムが、当時の担当者の退職とともにブラックボックス化していたケースです。設計書は形式上は残っていましたが、長年の改修で実装との乖離が大きく、信用して読めない状態でした（段階2）。

全面刷新の見積もりも取得されていましたが、金額が大きく踏み切れない、というご相談でした。弊社では刷新せず、リスクの高い箇所と業務影響の大きい箇所だけを延命する方針を立て、結果的に想定の約2割の費用で運用を継続できています。

どちらの案件も、共通するのは「全部を一度に直そうとしない」という姿勢です。仕様書がない状態では、網羅性を追い求めるほど費用は膨らみ、判断は遅れます。救う対象を絞り、外側から挙動を記録し、必要な分だけ仕様化して、最小単位で改修する――この順番を守れば、引き取り後の運用は十分に成り立ちます。

よくある質問

仕様書がないシステムでも、本当に改修だけで済みますか？

多くの場合、段階的な改修で十分に対応できます。ソースコードと稼働環境が残っていれば、外側からの挙動観測と部分的な仕様化で、改修に必要な情報は集められます。ただし業務フロー自体を作り変えたいのであれば、段階改修ではなく作り直しが妥当な選択になります。

ソースコードの解読にはどれくらい時間がかかりますか？

システムの規模と複雑さによりますが、画面数で20〜30程度の業務システムであれば、現状把握とドキュメント化の初期診断は1〜2カ月で終わるケースが多いです。全画面を網羅するのではなく、改修対象の周辺だけに絞れば、もっと短くなることもあります。

もとの開発会社ではなく、別の開発会社に保守を頼んでも契約上の問題はありませんか？

自社（システムを使っている側）が、もとの開発会社ではない別の会社に保守を委託してよいかは、当時の開発契約書で確認します。チェックすべきは、ソースコードの著作権が自社にあるか、もしくは譲渡を受けているか、そして、もとの開発会社に独占的な保守権がついていないか、の2点です。この条件を満たしていれば、別の開発会社への切り替えに法的な問題はありません。契約書が見当たらないケースでも、過去のメールや請求書から契約条件を再構成できる場合があります。

補助金は使えますか？

業務システムの改修・刷新は、IT導入補助金や省力化投資補助金など、いくつかの補助金の対象になり得ます。ただし「現行システムの単なる保守延長」は対象外となる場合が多く、業務改善や生産性向上に直結する改修であることを示せるかが鍵になります。自社の改修計画が補助金の趣旨に合うかは、申請前に専門家と確認することをお勧めします。

まとめ

仕様書も設計書もないシステムでも、ソースコードと動いている環境があれば、現状把握から段階的に直す道は残っています。要点は4つです。

救う機能を絞る（トリアージ）
外側から挙動を記録する
改修対象の周辺だけ仕様化する
影響範囲を絞って改修・検証する

避けたいのは、「全部のドキュメントを作り直してから」と構えること、本番でいきなり直すこと、そして全面作り直しに即決することです。10年動いてきたシステムには、文書化されていない業務ノウハウが詰まっています。捨てずに延命する選択肢を、まず机の上に乗せてください。

「他社に断られた」「全面作り直しの見積もりに踏み切れない」という段階からのご相談を、いつもいただいています。

システムレスキュー

動いてはいるが、もう誰も中身を触れない――そんな業務システムの現状把握と段階改修をご相談いただけます。初回相談は無料です。

/service/system-rescue/