仕様書がない古いシステムを保守するには？最初に行うべき現行調査

「仕様書がない。システムを作った担当者もいない。でも、このシステムを保守しなければいけない」という状況からのご相談をいただくことがあります。

仕様書がない状態で保守を続けることは確かに難しいのですが、だからといってすぐにリプレースが必要なわけでも、どうにもならないわけでもありません。仕様書がなくても、システムの動作を読み解くための手がかりは、たいていどこかに残っています。

この記事では、仕様書も、システムを作った担当者もいない状況で、何を手がかりにするかを整理します。

「仕様書がない」状況は珍しくない

長年運用されてきた業務システムの多くは、仕様書が存在しないか、あっても現行の動作と一致していません。理由はさまざまです。

最初から仕様書を作らずに開発した
仕様書はあったが、改修のたびに更新されず実態と乖離した
担当者が退職し、仕様書の場所が分からなくなった
ベンダーが廃業し、ドキュメントを受け取れなかった

「仕様書がない = 保守できない」ではありません。仕様書の役割は「システムが何をするか」を説明することです。その情報が仕様書の形でなくても、システム自体や周辺の情報から読み解くことができます。

こうして現行システムを読み解きながら保守できる状態へ戻すアプローチの全体像は、レガシーシステム再生とは？リプレースの前に現行システムを活かす選択肢で整理しています。

仕様書の代わりに使える情報源

仕様書がない場合、代わりになる情報源を探します。どれか一つで全貌が分かるわけではありませんが、複数を組み合わせることで全体像が見えてきます。

ソースコード

最も直接的な情報源です。動いているコードは、仕様書よりも正確に「実際の動作」を示しています。

最初に把握したいのは、コード全体の構造です。

どのフレームワーク・言語で書かれているか
ディレクトリ構成から、機能の分類を読み取れるか
ファイル名・関数名から処理の目的を推測できるか

コードを読むときは「何をしているか」より「なぜこうなっているのか」が分かりにくい部分に注意が必要です。業務ルールが条件分岐の中に埋め込まれていることが多く、そこが保守の急所になります。

データベーススキーマ

テーブル構成とカラム名からシステムの業務構造を把握できます。

テーブルの一覧と、テーブル間のリレーション
主要なテーブルのカラム名と型（業務用語が使われていることが多い）
データの件数・更新頻度（実際に使われているテーブルの見当がつく）

特に、長年運用されたシステムではデータベースに業務の変遷が蓄積されています。使われなくなったカラムや、命名が一貫していない箇所などの痕跡が、システムの歴史を教えてくれます。

ログと設定ファイル

アクセスログ・エラーログ・バッチ処理のログからは、システムがどのように使われているかが分かります。

どの機能が頻繁に使われているか
どんなエラーが繰り返し発生しているか
バッチ処理が何時に何を実行しているか

設定ファイルからは、外部連携先（他システム・外部サービス）や環境構成が把握できます。

画面と帳票

実際の操作画面と、システムが出力する帳票・ファイルは、業務フローを理解するための手がかりになります。

画面の入力項目と処理の流れ
出力される帳票の項目（どんなデータをどう使っているか）
エラーメッセージ（業務上の制約が読み取れることがある）

画面を一通り操作しながら、どの処理がどのテーブルに影響しているかを確認する作業は地道ですが、全体像を把握するうえで有効です。

現場担当者の記憶

システムを毎日使っている現場のスタッフは、仕様書には書かれていない業務ルールを知っていることがあります。

「この項目には必ずこの値を入れないといけない」
「月末はこの処理が重くなる」
「この画面は使い方が特殊で、新人には必ず引き継ぐ」

こうした情報は、コードを読むだけでは分かりません。現場担当者へのヒアリングは、調査の初期段階で行うことをお勧めします。

「動いているコードが仕様書」という考え方

仕様書がない場合、「実際に動いている状態が正しい仕様」という前提で調査を進めます。

設計上の意図がどうであったかよりも、現在どう動いているかを把握することが保守の出発点です。誤った動作が長年放置されて「正しい動作」として定着しているケースもあります。その場合、設計上の「正しさ」に戻そうとすることで現場に混乱が生じることがあります。

現行の動作を記録しながら、「意図的な仕様か、バグが放置されたものか」を区別していくことが調査の核心です。

AI を使った解析（できること・できないこと）

近年、AI（大規模言語モデル）がソースコード解析の補助に使われるようになりました。

AI が得意なこと

コードの構造を要約し、処理の流れを説明する
コメントが少ないコードの意図を推測する
ドキュメントのたたき台を生成する

AI が苦手なこと・注意が必要なこと

業務文脈を踏まえた正確な解釈（業務知識がないと誤った説明になる）
大規模なコードベース全体の整合性の把握
AI の出力は必ず技術者が確認・検証する必要がある

AI は「読む作業の効率を上げるツール」です。「理解する作業の代替」にはなりません。AI が出力した解説を鵜呑みにせず、コードと照合しながら確認することが前提になります。なお、AI を使用する場合は事前にご確認・ご許可をいただきます。

調査の優先順位のつけ方

仕様書がない状態で保守を始めるとき、すべてを同時に調べようとすると行き詰まります。優先順位をつけて進めることが重要です。

最初に把握すること（優先度：高）

現在稼働しているサーバー・環境の構成
バックアップの有無と取得方法
直近で不具合が起きている箇所・頻繁に改修が入っている箇所

次に把握すること（優先度：中）

データベーススキーマと主要テーブルの役割
バッチ処理の一覧と実行タイミング
外部連携している先（API・ファイル連携など）

時間をかけて把握すること（優先度：低）

全機能の詳細な仕様
使われていない機能・レガシーコードの整理

「全部分かってから保守を始める」のではなく、「最低限必要な情報を確保しながら動かし続ける」という姿勢が、仕様書のないシステムを引き受けるときの現実的なアプローチです。この積み上げが、現行システムを段階的に保守可能な状態へ戻すレガシーシステム再生の実践につながります。

何を、どの順で、どこまで把握するかの一覧は、現行システム調査で確認すべきポイントで整理しています。

まとめ

仕様書がないシステムを引き受けたとき、最初にすべきことは「全体像の把握」ではなく「最低限の情報確保」です。ソースコード・データベース・ログ・画面・現場の記憶を組み合わせることで、仕様書の代わりになる情報は少しずつ集まります。この調査の積み重ねが「作り直す前に現行を読み解く」というレガシーシステム再生の考え方の土台になります。

「システムの寿命を決めるのは技術の新しさではなく、理解している人がいるかどうか」

「仕様書がなくて何から手をつけていいか分からない」という段階からでもご相談ください。現行システムの調査・整理・ドキュメント化を支援しています。レガシーシステム保守のページ、またはお気軽にお問い合わせください。