対外公開版（匿名化済み） — 顧客名・案件名・固有ライブラリ／パス／プログラム名は一般化しています。用語は青点線にマウスオーバーで定義を表示。巻末「用語集」も参照。
この章の位置づけ：
次回の作業手順の正本は「0章（完成版手順）」。
ここは、なぜその順になったかの振り返りである。着手時に通読しなくてよい。
一言でいうと
最初は「AIにソースを渡せばレポートが書ける」と思いがちだった。
実際に効いたのは逆で、人が読む文章より先に、機械が数えられる根拠を作ることだった。
根拠が揃ってから文章化し、査読で件数を合わせ、CRUD図やテーブル定義書はレポートのあとにまとめて作り直す。
この順を守ると、同じ直しを何度もやらなくて済んだ。
振り返りのフロー（経緯用）
A
棚卸し
機能ごとに、どのプログラム・どのファイルが関係するかを機械抽出する
↓
B
小さくレポート化
1〜5件ずつ文章化し、査読で件数と確度を合わせる
↓
C
手元で精度上げ
列パーサでPARTIALを詰め、画面ワイヤーを足し、HTML化する
↓
D
派生資料をまとめて更新
CRUD図 → テーブル定義書 → リンク張り直し
↓
E
静的で残った穴だけ実機
DSPDBR・開ファイル・LIBL
↓
F
影響調査に使うか判断
手順が回ることと、その1本を根拠にしてよいかは別判定
なぜこの順が手戻りが少なかったか
レポートの章立てを途中で変えると、HTMLもCRUDも定義書も全部追いつかせることになる。
うまくいったのは、成果物の形は固定したまま、抽出器と突合だけを厚くした（蒸留）ことだった。
400件を一気に回さなかったことも大きい。
1〜5件で査読し、件数と確度が合ってから次へ進む。
ここで妥協すると、あとの一括直しが効かず、個別に戻ることになる。
実機は最後にした。
ソースと既存の一覧で埋められるところを埋め、残った穴だけ実機に聞く。
依頼する側も取る側も、その方が楽だった。
やって失敗しやすかったこと
- F仕様の IF/UF だけで「更新する」と確定する
- RPG IVの列だけ見て、RPG III資産を取りこぼす
- レポートだけ直して、CRUD図と定義書を更新しない
- 画面ワイヤーをプレースホルダのまま残す
- PARTIALを消すために実機を先に全部取ろうとする