# 実例 1 — PL/SQL 風の業務ロジックを Python に並行稼働で書き換える

第 06 章「業務システムと付き合う ── 並行稼働で書き換える」の主張を裏付ける。

## 章のどの主張に対応するか

> PL/SQL 5,000 行の業務ロジックを Python に翻訳、SI ベンダーの外注見積もり:
> 約 **3,000 万円**。現場担当者が Claude で書き換え、開発期間 1 ヶ月、
> 人件費約 100 万円。**30 分の 1**。

> 業務知識を Markdown 化する作業: 担当者の空き時間でやると 6 ヶ月〜1 年。
> Claude に全コードベースを渡して一気にやれば、**1 週間で 80%**。

(章本文「実例: 数字で見る」より)

これは **並行稼働パターン** そのものを最小サイズで実演する。
SQL 側と Python 側で同じ入力に対して **完全一致** の出力を返すことを
`diff` で確認する。違いが出れば、それは「現場の頭の中にあったが
ドキュメントに書かれていなかった業務ルール」だ。

## やること

1. **既存システム**: `legacy.sql` ── 注文に対する請求計算(送料・会員割引・
   大口割引・税)を SQL の VIEW として実装。SQLite で実行して
   `legacy_output.csv` を出す。
2. **新エンジン**: `new_engine.py` ── 同じロジックを Python 100 行で書き直す。
   ルール定数を **章ごとにコメント付きで定義**する(後で Markdown 化しやすい)。
3. **並行稼働**: `make diff` で 2 つの CSV を `diff -u` で突き合わせ、
   完全一致を確認。違いがあれば差分が表示される。
4. **業務ルールの Markdown 化**: `RULES.md` ── コードから抽出した業務ルール集。
   現場担当者の頭の中にあった暗黙ルールを、Markdown で残す。

## 構成

```
example-1/
├── README.md
├── legacy.sql          ── 既存システム (PL/SQL 風 / SQLite で動く)
├── new_engine.py       ── 新エンジン (Python)
├── RULES.md            ── コードから抽出した業務ルール
├── Makefile
├── results.md
└── out/
    ├── legacy_output.csv  ── 既存の出力
    ├── new_output.csv     ── 新エンジンの出力(同じ内容になる)
    └── diff.txt           ── 並行稼働の差分(空)
```

## 実行

```bash
sudo apt install sqlite3
make clean && make all
```

出力の最後に `✓ 完全一致 ── 並行稼働 OK、新エンジンに切り替え可能` と
出れば成功。

## なぜこれが「実例」になるのか

業務システムの書き換えは、本来こうやる:

1. **既存を止めない**。SQL はそのまま動かし続ける
2. **新エンジンを Python で書く**。Claude に PL/SQL を読ませて翻訳
3. **同じ入力で並行稼働**。出力が完全一致するまで Python を直す
4. **食い違いはルールの炙り出し**。現場の暗黙知を Markdown に書く
5. **完全一致したら切り替える**。SQL を停止、Python だけにする

このフォルダはそれを 50 行のサイズで実演する。

実プロジェクトでは `legacy.sql` が **5,000 行**、`new_engine.py` が
**1,000 行**、`RULES.md` が **3,000 行**になる。SI ベンダーへの
外注見積もりが 3,000 万円のところ、現場 + Claude で 1 ヶ月、100 万円。

これが章で言う「**業務知識は既存システムの中にある。それを少しずつ
Markdown に出す。並行稼働で確認しながら、新エンジンに移していく**」の
最小実演。