旧コードの読み方 — 地図が無い状態から、動いている・死んでいる・欠陥・休眠を分ける

🎯 この記事の範囲

第 1 回 で、原典は仕様書ではなく動いている実装だと書いた。本記事は、その原典を どう見つけるか、どう読むか です。

現場の起点は、ファイル一覧ではありません。リポジトリの URL はある。作者はいない。パスが分からない。AI にリポジトリを渡して「移植して」は、読み方ではありません。先に地図を出し、読ませる順番と、読んだ結果の置き場を決めます。

🗺️ リポジトリは分かる、パスは分からない

他人が作ったシステムを自分のプロジェクトへ入れるとき、分かっているのはリポジトリだけ、ということが多いです。SVN か Git か、クローンできるか。そこまでです。画面名とソースの対応、正本の世代、死んでいる分岐の場所は、リポジトリを開いただけでは出ません。

ここはステアリングを組む前の仕事です。設計文書の前に、調査としての AI を使います。

• 画面・帳票・ジョブの名前から、複数世代を横断してファイルを列挙する
• 「確認」と書いてよいのは、ソース上の存在まで。稼働と正しさはまだ書かない
• ヒットしなかった名前は、無いと決めず「対象確認中」に残す
• 地図が無いのに「移植して」と出すと、AI は見つかったファイルだけを全体だと思い、欠落は誰にも見えない

調査クエリの対象は、既存コードと既存ドキュメントの事実に限ります。作成中の設計への採否は、調査に含めません。地図が出てから、機能 ID の台帳に行を作ります。

📚 旧実装は 1 本ではない

CTS の業務まわりを読むと、少なくとも次が同時に残っています。

「最新の MAUI だけ読めば足りる」は成り立ちません。ラベルの座標は 2008 年の生成処理にあり、紙面の条件は RDLX にあり、自動印刷の欠陥は WPF の共有可変値にあります。AI に渡す順番は、画面の新しさではなく、その機能の正本がある世代です。

調査時点で「確認」と書いてよいのは、ソース上の存在です。稼働・完成・業務上の正しさは、ソースを読んだだけでは保証しません。台帳の冒頭にその一文を置きます。

🧾 最初の成果物は、機能 ID の台帳

置換のコミットより先に、行を作ります。1 行はだいたい次です。

• 機能 ID（W01, W02, …）
• 旧業務の根拠（画面、API、ジョブ、RDLX）
• 新側の操作
• 必要なデータとサーバー
• 工程（今やる / 後で / 対象確認中）
• 判定（移植 / 統合 / 廃止 / 欠陥として直す / 休眠として再利用）

現行業務だけでも 20 行を超えます。画面・帳票・ラベル・取込が並ぶので、全部を第 1 工程に入れないことが、台帳の仕事です。

独立業務（受注編集、売上消込、メール管理、労務）は、Controller の存在を確認した、とだけ書きます。基本範囲の見積もりへ無条件に含めません。未確認行を残したまま全体完了にしない、が台帳の閉じ方です。

🟢 動いている / ⚫ 死んでいる / 🔴 欠陥 / 💤 休眠

四分類は感想ではありません。根拠を添えます。今は動かないことと、捨てることは同じではありません。

動いている

現場が今日も通る経路です。検品のスキャン順、7 商品ごとの改ページ、社内出荷番号の Code128、加工指示の日本語 QR、Windows キューへの無人印刷。ここは座標も条件も、旧実装を正とします。

「動いている」でも、巨大 ViewModel や静的な共有リストは 構造の流用候補 であって、コピー対象ではありません。業務順序は残し、通信と状態復旧は再設計します。

死んでいる

ソースにはあるが、現行業務が通らず、別系統でも要らない ものです。

• 旧拠点の会社名・住所がソースに直書きされているラベル
• 単一商品前提で、途中の明細を上書きするサーマル納品書
• 今の現場では使わない、拠点固有の優先分岐
• 互換のためだけに残したい、と呼ばれている未使用分岐

死んでいるコードを「互換のため」に移植すると、新 SaaS が旧テナントの墓地になります。固定住所は、明示した差出人データへ戻します。追跡番号は発行済み値を受け取るだけで、採番しません。旧コードが持っていた「黙って採番する」「黙って ? に置換する」は、死んでいるか欠陥です。

休眠

今のラインでは止まっているが、別のフロント／バックで同じ機能が欲しいものです。ソースがあることと、現行業務が通ることは別です。

• 過去の業務 Web で動かしていた一覧・取込・補助画面を、今の API と画面へ移したい
• 実運用では止まった帳票定義だが、別系統の紙面として載せ替えたい
• 端末を替えたあとも、同じ操作手順が要る

休眠は、死んだ原紙の復活ではありません。後期仕様を正として載せ替える のであって、止まった画面をそのままコピーしません。欲しい機能 ID だけを台帳に残し、受入テストがあるものだけ移植します。テストが無い休眠は、動いている機能より先に、第 4 回の TDD へ落とします。

欠陥

動いているが、正しいとは限りません。

• 取得引数ではなくプロセス全体の可変値で帳票種別を選ぶ。手動操作のあと、発払データにコレクト紙面が載る余地がある
• RDLX の Fields!!ShipmentId のような誤記
• COD 帳票だけ印刷日欄が幅 2mm
• 共有境界を両側が描いて、罫線が二重幅になる

欠陥は再現しません。直した事実を台帳に残し、旧式を「互換オプション」にしない。AI は欠陥を丁寧に移植したがります。禁止は会話ではなく、変換器に書きます。

⛔ 未知の式は、変換を止める

RDLX の取り込みは、座標と表示条件を読み、許可した式だけを C# の固定処理へ対応付けます。未知の項目・結合・式・スタイルは import を失敗させます。実行時に VB も、利用者が入力したテンプレートも評価しません。

許可した式 → Builtin / Field / Literal
未知の式   → 変換を止める（推測で Scriban に落とさない）

帳票に埋め込まれた固定店名も、データ項目へ戻します。ソースに残った店名リテラルを、新テンプレートの既定値にしてはいけません。

元ファイルのハッシュと、意図した差分は変換台帳に残します。AI が「近い式だから」と足した行は、差分に出ます。出なければ、その変換は使わない。

同じ態度を、SBPL と API にも適用します。未対応文字の黙った置換、データ中の ESC、未マップ JSON、CLR の型名復元は、いずれも未知です。未知は止める。

🤖 AI に渡す単位

一度に渡すのは、機能 ID 数行と、その正本がある世代のファイルです。旧デスクトップ全件と MAUI 全件と RDLX 全件を、同じプロンプトに載せません。

渡す指示の核は次です。

1. この機能 ID の正本は、この世代のこのファイルである
2. 動いている座標・条件は維持する
3. 死んでいる分岐は移植しない。理由を台帳に 1 行書く
4. 休眠は、欲しい機能だけ後期仕様で移す。死んだ原紙は復活させない
5. 欠陥は再現しない。直す内容を台帳に 1 行書く
6. 未知の式・項目が出たら止める。推測で埋めない
7. 受入は次のテスト名である（無ければテストを先に書く）

「全部新しくして」は、第 1 回で捨てた新規のつもりです。読み方を固定すると、生成されるコードの形が変わります。

✅ 第 2 回まとめ

• 起点は、リポジトリは分かるがパスが分からない状態である。ステアリングの前に調査で地図を出す
• 旧実装は 1 本ではない。正本がある世代から読む
• 最初の成果物は機能 ID の台帳。未確認行があるうちは完了にしない
• 動いている / 死んでいる / 欠陥 / 休眠を、根拠付きで分ける。今は動かないことは、捨てることではない
• 未知の式は変換を止める。ハッシュ付きの変換台帳を残す
• AI に渡すのは機能 ID 単位。全部移植は禁止

次回「寄せる境界・寄せない境界」では、読んだ結果をどの契約に載せ、何を機種の言語のままにするかを書きます。

📚 シリーズ記事

🔗 関連リソース

• レガシー置換とは — シリーズ総論
• ActiveReports → Playwright + Scriban 移行 — RDLX を許可した式だけ移植した実例
• AS/400 モダナイゼーション戦略 — ドメイン知識の抽出。本記事は端末・帳票のソース抽出
• モダナイゼーション