DX

設計書のない基幹システムを90万行から読み解いた――動くコードを絞る調査事例

目次

「直したいのに、誰も中身が分からない」。ある引き取り案件では、担当者がすでに退職し、設計書も残っていませんでした。ソースコードは約90万行あり、本番環境と引き継いだ開発環境にも差異がありました。どのコードが現在の動作に対応しているのかさえ、すぐには判断できない状態です。

この案件で最初にしたのは、90万行すべてをきれいな設計書へ戻すことではありません。今も動いている処理を特定し、コードが表す業務上の意味を根拠付きで言葉にし、修正後の挙動を確かめられる範囲を作ることでした。結果として、古い設定を参照して計算結果がずれていた箇所を見つけ、安全を確認しながら修正できました。以下は、機密に関わる業種・機能名・数値を伏せた調査事例です。

問題は90万行という規模より、「何が正しいか」を確認できないこと

行数の多さは調査工数に影響します。しかし、この案件を難しくしていた本質は、コードが多いことだけではありませんでした。本番で動いているもの、開発環境に残っているもの、過去に作られたまま使われていないものが混在し、判断の基準点がありませんでした。

経済産業省の2018年の「DXレポート」は、2017年の調査を基に、約8割の企業がレガシーシステムを抱え、約7割がデジタル化の足かせだと感じていたと紹介しています。同レポートは、レガシー問題の本質を単なる技術の古さではなく、自社システムの中身が見えず、自分たちで修正できない状態として整理しています。

この見方に立つと、最初の目標は「古い技術を新しくする」ではなく、「事実をたどって変更判断ができる状態へ戻す」になります。そのために、次の問いから確認しました。

  • 本番では、どの実行物と設定が使われているのか
  • 引き継いだソースは、本番の動作と対応しているのか
  • 日次・月次・年次で起動する処理は何か
  • 修正した場合、正しさを誰がどのデータで判断できるのか

設計書がないまま、いきなりリプレースの範囲や改修費用を決めても、前提がずれていれば判断もずれます。まず「調べれば確かめられる状態」を作ることが、改修にも作り直しにも共通する入口でした。

先に固定したのは、読む対象ではなく「現在地」

ソースコードを読み始める前に、本番と開発環境の差異を整理しました。ここを飛ばすと、詳しく解析したコードが実際には使われていない、という事態が起きます。「コードが事実」と言えるのは、そのコードが現在の実行物や設定と対応していると確認できた後です。

調査対象には、プログラム本体だけでなく、データベース定義、設定ファイル、帳票、定期実行処理、外部ファイルとの連携も含めます。古い基幹システムでは、画面の入力規則やデータベース側の処理に業務ルールが分散していることがあります。プログラムのロジックだけを読んでも、全体の挙動は復元できません。

また、受領した時点のソースと設定には基準となる版を付けます。バージョン管理がなければ、スナップショットとして固定し、後から加わった変更と混ざらないようにします。調査結果にも、どの版を見て判断したかを残します。

「コードを正とする」は、「手元にあるファイルを無条件に信じる」という意味ではありません。本番の実行物、設定、データベース、運用手順との対応を確認し、基準点を固定して初めて、コードを判断材料として使えます。

この準備で得られるのは、完成した設計書ではなく、調査の土台です。対象が固定されると、「この説明はどの版のどの処理に基づくのか」を後から追えるようになります。担当者の記憶とコードの動作が食い違った場合も、どちらかを感覚で選ばず、差異として調べられます。

約90万行を均等に読まず、今も動く経路から範囲を絞った

約90万行を上から順に同じ深さで読む方法では、時間を使う割に、重要な処理へなかなか届きません。この案件では、画面操作や定期処理などの入口から呼び出し関係をたどり、現在使われている可能性が高い経路を先に洗い出しました。参照するテーブルや外部ファイルも合わせて確認し、処理のまとまりを作ります。

その過程で、大半が現在は使われていないと考えられるコードだと分かりました。ただし、呼び出し元が見つからないだけで削除してよいとは判断しません。設定による動的な呼び出し、年に1度だけ使う処理、障害時に手動で動かす処理は、通常の調査では見落としやすいためです。

そこで、調査結果を次の3つに分けました。

区分判断の仕方次の扱い
稼働を確認できた処理画面、定期実行、ログ、データ更新などから利用を確認優先して仕様と影響範囲を整理
未使用の可能性が高い処理呼び出し元や運用実績を確認できない削除せず、候補として記録
判断材料が不足する処理動的呼び出しや例外運用の可能性が残る業務担当者への確認事項にする

この分け方により、調査対象を小さくしながら、未確認のものを誤って捨てるリスクも抑えられます。すべてを理解してから1か所を直すのではなく、変更に必要な経路と、その周辺の影響範囲を優先して確定していく進め方です。

特に先に確認したのは、止まると日々の業務へ直接影響する処理です。重要度はコードの複雑さだけでは決まりません。毎日使うのか、締め日にだけ使うのか、止まったときに手作業で代替できるのかを現場へ確認し、読む順番へ反映しました。

コードを業務の言葉へ変え、事実と推測を混ぜない

稼働する処理を絞った後は、入力、計算、条件分岐、出力、外部依存を機能ごとに整理しました。ここではAIも使います。AIは長い処理の概要や分岐を表にする叩き台づくりには役立ちますが、その説明を確定事項としては扱いません。

各説明には、根拠となるファイル名、行番号、基準にした版を紐づけます。そして、確認状況を「確認済み」「要ヒアリング」「未検証」「誤り」に分けました。根拠を示せない説明や、名前だけから推測した意味は、設計書や改修判断へ混ぜません。

コードから分かるのは「どの条件で、何を計算し、どこへ保存するか」です。一方で、「なぜその条件になったのか」「現在もその例外が必要か」は、コードだけでは確定できません。ここは業務担当者へ、処理の説明と該当箇所を見せながら確認します。

本案件で見つかった、古い設定を参照して計算結果がずれていた箇所も、この突き合わせから発見しました。コード上の参照先だけを見て「バグ」と断定したのではありません。現在の運用で使う設定、期待する計算結果、影響する処理を確認してから、修正対象として確定しました。

AIによる整理と人による確認の境界は、仕様書のない業務システムは、生成AIで読めるのかでも詳しく整理しています。今回のような事例では、AIの速さよりも、根拠へ戻れることのほうが重要でした。

読み解いた成果を、「安全に1か所直せるか」で確かめた

調査資料が増えても、実際の修正に使えなければ、システムはまだ「触れる状態」に戻っていません。そこで、見つけた計算のずれについて、現象の再現、原因箇所の特定、修正、回帰確認、承認という順で進めました。

回帰確認では、修正対象の結果だけでなく、同じ設定やデータを参照する周辺処理も確認します。古い基幹システムでは、1つの値を複数の帳票や集計が参照していることがあります。目の前の数字が合っただけで完了にすると、別の締め処理で差が出る可能性が残ります。

IPAの「システム再構築を成功に導くユーザガイド 第2版」は、現行システムの仕様が曖昧なまま新システムの開発へ着手することが、再構築後のトラブルにつながると説明しています。また、企画・計画段階でリスクと対応を整理し、ユーザ企業と開発企業で合意することを重視しています。この考え方は、全面再構築だけでなく、小さな改修でも同じです。

今回の読み解きで残したものは、分量の多い設計書だけではありません。

  • 現在の稼働を確認できた機能と処理経路
  • 業務ルールと、その根拠となるコードの対応
  • まだ確認できていない処理と、担当者への質問
  • 修正時に比較すべき入力と期待結果
  • 本番反映前に確認する範囲と承認手順

これらが揃うと、次の改修で同じ場所を最初から調べ直す必要が減ります。作り直す場合も、残す機能、廃止する機能、旧システムと同じ結果を求める範囲を話し合えるようになります。読み解きの成果は、文書のページ数ではなく、次の判断と検証に再利用できるかで評価すべきだと感じています。

まとめ

設計書のない約90万行の基幹システムでも、現在の実行物とソースの対応を確認し、稼働する経路から範囲を絞れば、修正に必要な事実を復元できます。大切なのは、全体を一度に理解したように見せることではありません。確認できた事実、現場へ聞くこと、まだ分からないことを分け、根拠へ戻れる形で残すことです。

この案件では、稼働処理を絞り込み、コードを業務の言葉へ変え、古い設定を参照していた計算のずれを修正しました。1か所を安全に直せたことで、調査結果が実務で使えることも確かめられました。

設計書がない場合に、最初から作り直すか、現行を使い続けるかの2択で決める必要はありません。まずは本番で動いている版、止められない処理、期待結果を確認できる担当者の3点を押さえると、「どこまでなら安全に触れるか」が見え始めます。より一般的な改修の進め方は、仕様書のない業務システムは直せるのかで紹介しています。

システムレスキュー

設計書がない、担当者が退職した、本番と開発環境に差異がある業務システムを、現状把握から引き継ぎます。

/service/system-rescue/

関連記事