「基幹システムを刷新したい。でも、作った人がもういない」

この相談を、この一年で何度も受けました。業種はさまざまですが、状況は驚くほど似ています。VB6、Access、Delphi、Excel VBA、あるいはオフコン。日々の業務は問題なく回っている。しかし中身を説明できる人が社内に一人もいない。

そして、ほぼ全ての企業が同じ場所で止まります。刷新の見積が取れない、という場所です。

なぜ見積が取れないのか

ベンダーに相談すると「まず現行調査から」と言われます。当然です。何を作り直すのか分からなければ、工数は出せません。

ところが、その現行調査の見積が数千万円になる。ここで話が止まります。「調べるだけで数千万」という提案は、多くの企業で稟議が通りません。かといって調べなければ刷新の見積も出ない。投資判断に必要な情報を得るための投資が、それ自体として大きすぎるという構造的な行き詰まりです。

結果として、毎年「来年こそは」と先送りされ、システムはさらに古くなり、分かる人はさらに減っていきます。

「刷新するか」と「何があるか」は別の問題

ここで重要なのは、意思決定の順序です。

多くの企業が「刷新するかどうか」を先に決めようとします。しかし判断材料がないのだから、決めようがありません。決めるべきなのは逆の順序です。

  1. まず、現行システムに何があるかを明らかにする
  2. その情報をもとに、刷新するかどうかを決める

当たり前に聞こえますが、実務ではこの二つが一つの契約に束ねられているために順序が崩れます。「刷新プロジェクト」という大きな箱の中に調査が含まれていると、調査だけを買うことができない。だから判断できないまま、大きな契約を結ぶか、何もしないかの二択になってしまう。

調査を独立した商品として切り出す。これだけで、この膠着はほどけます。

仕様書の復元とは、具体的に何をするのか

「現行調査」という言葉は曖昧なので、当社が実際に何を作るかを書きます。

1. 資産の棚卸し

画面、帳票、バッチ処理、外部連携。まず全ての一覧を作ります。ここで頻繁に発覚するのが、誰も使っていない機能が全体の3〜4割あるという事実です。刷新の対象を減らせるので、この時点で費用の見通しが変わることがあります。

2. データベース論理設計の復元

テーブル定義、リレーション、そして「実際にデータが入っている項目はどれか」。設計上は存在するが10年間NULLのままのカラム、という例は珍しくありません。逆に、カラム名と実際の用途が乖離しているケースもあります（備考2 に業務上重要なコードが入っている、など）。

これは設計書を読んでも分かりません。実データを見ないと分からない種類の情報です。

3. 業務ロジックの抽出

分岐条件、計算式、例外処理。「なぜこの条件があるのか」という背景まで含めて文書化します。

ここは機械だけでは完結しません。コードから抽出できるのは「何をしているか」までで、「なぜそうしているか」はコードに書かれていないからです。ただし重要なのは、ヒアリングの前に「何を聞くべきか」が全て洗い出されている状態を作ることです。これがあると現場担当者へのヒアリングが数時間で済みます。逆にこれがないと、何ヶ月も探り合いが続きます。

4. 現行挙動を固定する自動テスト

これが最も重要な成果物です。

刷新において本当に怖いのは、機能が足りないことではありません。気づかないうちに挙動が変わっていることです。月末処理の端数計算が1円ずれる。特定条件でだけ帳票の並び順が変わる。こうした差異は、リリース後何ヶ月も経ってから発覚します。

現行システムの入出力を大量に採取し、それを再現するテストスイートを先に作っておく。すると刷新は「未知のものを作る」作業ではなく、「テストを全て通す」という機械的に判定可能な作業になります。

なぜ今、この工程が安くなったのか

率直に言えば、既存コードの読解と仕様抽出が、この2年で最も生産性の上がった工程だからです。

数十万行のVB6コードを読んで処理フローを図示する、という作業は、従来は熟練エンジニアが数ヶ月かける仕事でした。現在は、それが大幅に短縮できます。

ただし、誤解のないように書いておきます。AIが出した抽出結果をそのまま納品することはできません。 抽出漏れ、誤読、そして「コードにはこう書いてあるが実際の運用は違う」というケースが必ずあります。検証は依然として人間の仕事であり、当社の見積はこの検証工程を省かない前提で組んでいます。

安くなったのは調査全体ではなく、その中の一工程です。それでも、従来の数分の一にはなります。

復元した仕様書は、他社に発注しても構わない

当社では、この現行システム調査を2週間・定額で提供しています。そして、その結果を持って他のベンダーに発注していただいて構いません、と最初に伝えています。

理由は単純で、仕様書とテストスイートがある状態で相見積を取ったほうが、発注側にとって圧倒的に有利だからです。各社が同じ前提で見積を出すので比較ができる。「調査してみないと分かりません」という留保が消えるので、金額が膨らみません。

そのうえで当社を選んでいただけるなら、それは調査の内容を見て判断された結果ということになります。その順序が、双方にとって健全だと考えています。

まとめ

  • レガシー刷新が止まる原因は、技術力ではなく投資判断に必要な情報が存在しないこと
  • 「刷新するか」を決める前に、「何があるか」を明らかにする工程を独立させる
  • 成果物は、資産の棚卸し・DB論理設計・業務ロジック・現行挙動を固定する自動テスト
  • この工程のコストはここ2年で大きく下がった。ただし検証は人間の仕事として残る

現行システムの状況について、まずは30分の技術相談でお聞かせください。どこから手を付けるべきかの一次見解を、その場でお返しします。