仕様書がないシステムの改修は、何から始めるか｜現状調査の5ステップと、着手前に確認すること

なぜ、仕様書は失われるのか

最初に申し上げておくと、これは管理が悪かったという話ではありません。 10年動いているシステムで、当初の仕様書が今の実態と一致しているほうが、むしろ稀です。 失われ方には、だいたい3つのパターンがあります。

1. 最初から作られていない

短納期の案件、小規模なシステム、個人の開発者への依頼。 「動けばいい」で始まったものが、気づけば基幹業務を支えている——という経緯は珍しくありません。 作った時点では、作った本人が全部分かっているので、誰も困りません。

2. 作られたが、更新されていない

納品時の仕様書はある。しかしその後5年分の改修が反映されていない。 この場合、残っている仕様書はかえって危険です。 書かれているとおりに動くと思って改修すると、想定外の箇所が壊れます。 古い仕様書は、無いより悪いことがあります。

3. 人の頭の中にしかない

長く担当してきた社員や、付き合いの長い開発会社の特定の技術者。 その人に聞けば何でも分かる状態は、うまく回っているうちは効率的です。 ただ、退職・異動・取引終了のどれか一つで、すべてが止まります。

3つに共通するのは、作った時点では誰も困らないことです。 困るのは数年後、別の人が触ろうとしたときです。 そしてそのときには、たいてい、もう時間がありません。

仕様書がないまま改修に入ると、何が起きるか

「とりあえず直してください」で着手した場合に、実際に起きることです。

見積りが出せない。出ても、大きく外れる

改修の工数は、変更する箇所の量ではなく、影響が及ぶ範囲で決まります。 影響範囲が読めない状態で出した見積りは、推測です。 着手後に「想定より広かった」が判明し、追加費用の相談になる——という進み方になりがちです。

直した箇所と関係ないところが壊れる

共通処理に手を入れたら、まったく別の画面でエラーが出る。 ひとつの関数が、10年のあいだに想定外の使われ方をしているケースはよくあります。 どこから呼ばれているかが分からないまま触るのは、配線図のない壁の中に釘を打つのと同じです。

テストの範囲が決まらない

影響範囲が読めなければ、どこを確認すればよいかも決まりません。 結果として「念のため全部確認する」ことになり、改修そのものより検証に時間がかかります。

いちばん困るのは、やめる判断ができないこと

費用が膨らんできても、どこまで進んだのか、あといくらで終わるのかが分からない。 だから引き返す判断ができず、投じた分がもったいないという理由だけで続けることになります。

これらはすべて、改修の前に現状把握をしなかったことから生まれます。 だから最初にやるのは、改修ではなく調査です。

現状調査の5ステップ

実際に当社が進める順序です。どれも稼働中のシステムを止めずに行えます。

ステップ1：現物を集める

設計書ではなく、今まさに動いているものを集めます。確認する対象は次のとおりです。

• ソースコード一式（どこにあるか、最新かどうかを含む）
• データベースの構造と、実際に入っているデータ
• サーバーの構成（台数、OS、ミドルウェア、バージョン）
• 稼働中の画面そのもの
• 定期実行されているバッチ処理（夜間処理は見落とされがちです）
• 外部システムとの連携（決済、会計、メール配信、API連携など）
• ドメイン、SSL証明書、各種アカウントの管理先

この段階で「どこにあるか分からない」ものが出てきます。 それを洗い出すこと自体が、最初の成果です。 所在不明のまま改修を始めると、切り替えの当日に止まります。

ステップ2：外から見える範囲を棚卸しする

内部を読む前に、使う側から見た全体像を作ります。画面一覧、帳票一覧、ユーザー種別と権限の対応です。

ここで併せて確認したいのが、実際に使われている機能と、使われていない機能の仕分けです。 アクセスログを見ると、何年も誰も開いていない画面が出てくることがあります。 使われていない機能を改修対象から外せれば、その分だけ費用も期間も下がります。 全部を直す必要がある、という前提をまず疑います。

ステップ3：ソースコードを解析し、内部構造を可視化する

画面と処理の対応、共通処理がどこから呼ばれているか、使用しているライブラリとそのバージョン。 ここを押さえると、改修の影響範囲が見えるようになります。

当社ではこの工程でAIによるコード解析を使っています。 従来は人が数週間かけて読んでいた範囲を短時間で把握できるため、 その分を実装と検証に回せます。

ステップ4：データの流れを押さえる

テーブルの定義、どのテーブルが何に使われているか、どこで作られてどこで更新されるか。 使われていないテーブルや、同じ情報が複数箇所に重複して持たれている箇所も、ここで見つかります。

プログラムは書き直せますが、データは作り直せません。 改修でも移行でも、最後に問題になるのはたいていデータの側です。ここは時間をかけて確認します。

ステップ5：触ってよい範囲と、触ってはいけない範囲を決める

ここまでで、影響範囲の地図ができます。 「この変更は、この3画面とこのバッチに影響する」と言えるようになり、 改修の見積りが、推測ではなく根拠のある数字になります。

調査の成果物は、そのままドキュメントとしてお渡しします。 次に別の会社へ依頼することになっても、同じ調査をやり直す必要はありません。

AIで変わったこと、変わらないこと

変わったこと：読む速度

数万行のソースコードから、処理の流れ、画面と処理の対応、データの流れを抽出する作業は、 これまで人がひたすら読んで進めるしかありませんでした。 ここが大きく短縮されたことで、「まず数週間の調査から」と言わざるを得なかった案件でも、 着手までの時間と費用を圧縮できるようになっています。

変わらないこと：「なぜ」はコードに書かれていない

コードから読み取れるのは「何をしているか」までです。 「この条件分岐はなぜ必要なのか」「なぜこの処理だけ例外的な扱いなのか」—— その理由は業務の側にあり、ソースコードには書かれていません。

たとえば「特定の取引先だけ締め日の計算が違う」という処理があったとして、 それが現在も有効な商習慣なのか、10年前に終わった取引の名残なのかは、コードを読んでも分かりません。 ここは人が、お客様に確認しながら埋めていく部分です。AIが代わってくれる領域ではありません。

注意点：AIの出力は、必ず突き合わせる

AIによる解析は、もっともらしく見える誤りを含むことがあります。 当社では、解析結果を実際の挙動と突き合わせて検証したうえで、ドキュメントに落としています。 「AIが解析したので正確です」とは申し上げません。速くなったのは読む工程であって、確かめる工程ではありません。

なお、契約上ソースコードを社外に出せないといった制約がある場合は、環境を分けた進め方もご相談いただけます。

着手前に、ご用意いただけると早いもの

ご相談の前に揃えていただく必要はありません。ただ、次のものがあると調査が早く進みます。

• サーバーへのアクセス情報（または、管理している会社の連絡先）
• ソースコードの保管場所
• 過去の改修履歴。正式な記録でなくても、当時のメールや見積書で十分です
• 今いちばん困っていること。そして、いつまでに解決したいか
• そのシステムを毎日使っている方の話

最後の項目は、見落とされやすいわりに有効です。 開発側の資料より、使っている人の話のほうが実態に近いことがよくあります。 「この画面はもう使っていない」「この帳票は手で直してから出している」といった情報は、 どこにも書かれていませんが、改修の範囲を決めるうえで重要です。

なくても進められるもの

次のものは、無くても調査を始められます。

• 仕様書・設計書
• ER図、テーブル定義書
• テスト仕様書
• 当時の開発担当者

これらが無いことを理由に、ご相談を先送りしないでください。 むしろ、無い状態から始めるための工程が、ここまで説明した現状調査です。

直すか、作り直すか

現状が分かると、次は方針の判断になります。判断材料は主に5つです。

2つ目については、サーバーのOSサポート終了を過ぎたらどうなるかで、 主なOS・ミドルウェアの期限を一覧にしています。

見落とされがちな逆説

「古くて分かりにくいから、いっそ作り直したい」というご相談はよくいただきます。 気持ちとしては自然ですが、ひとつ注意点があります。

作り直すには、今の仕様を全部拾い直す必要があります。 仕様書がないシステムほど、この拾い直しが難しく、漏れが出ます。 そして漏れは、たいてい切り替えた後、月末や年度末の処理で発覚します。 「作り直し」は、仕様が分かっているシステムでこそ現実的な選択肢です。

そのため実務では、第三の選択肢を取ることが多くなります。 新旧を並走させ、機能ごとに少しずつ移す進め方です。 古いシステムを動かしたまま、新しい側に機能を一つずつ移していき、 移し終えたものから切り替える。全部を一度に入れ替えないので、問題が起きても戻せます。 期間は長くなりますが、業務を止めずに済み、途中で方針を変えることもできます。

まとめ

• 仕様書が失われるのは、管理の問題ではなく、時間が経てば起きること。問題は、それを理由に判断できなくなること
• 仕様書がないまま改修に入ると、見積りが外れ、関係ない箇所が壊れ、やめる判断もできなくなる
• 最初にやるのは改修ではなく調査。現物を集める → 外から棚卸し → コード解析 → データの流れ → 触ってよい範囲を決める、の5ステップ
• AIで速くなったのは「読む」工程。「なぜそうなっているか」は業務の側にあり、人が確認して埋める
• 仕様書・設計書・ER図は、無くても着手できる。先送りする理由にはならない
• 仕様書がないシステムほど、全面的な作り直しは難しい。並走させて少しずつ移す進め方が現実的なことが多い

「何から聞けばいいかも分からない」という状態で構いません。 現在のシステムについて分かる範囲をお聞かせいただければ、 まず何を調べるべきか、どのくらいの規模になりそうかをご回答します。