移行をやめて作り直したほうが安い場合の見分け方

• 移行のほうが安い、は思い込みのことがある
• 判断材料は行数ではなく、分岐と仕様の所在
• 迷ったら一部だけ移して測る

古いシステムは移行するものだと決めてかかっていたが、作り直したほうが安い場合がある。見分け方を整理した。

行数では判断できない

1万行だから大変、3千行だから簡単、という比例はしなかった。

3千行でも、分岐が深く絡んでいれば読むだけで何日もかかる。逆に1万行でも、同じ形の画面が50枚並んでいるだけなら作業は軽い。

見るのは量ではなく、形がそろっているかどうかだ。

仕様がどこにあるか

いちばん効いた判断材料がこれだった。

• 仕様書がある → 作り直しが現実的
• 仕様書は無いが、動きを知っている人がいる → どちらでもよい
• 誰も知らず、コードだけが正解 → 移行一択

3番目の場合、作り直すと何を作ればいいか誰にも分からない。コードを読んで仕様を起こす作業が発生し、それは移行と同じ手間になる。

分岐の数を数える

走査スクリプトに、if・else・switch・三項演算子の数を数える処理を足した。

分岐の数 / 行数 = 分岐密度

この密度が高いファイルは、読み解くのに時間がかかり、テストも書きにくい。密度の高いファイルが全体の何割かで、作業量の見当がついた。

外部とつながっている数

決済、外部API、メール送信、バッチ。つながり先が多いほど作り直しは重い。

移行なら、つながり方はそのまま持っていける。作り直すと相手先の仕様を全部調べ直すことになる。相手が古いAPIだと、資料が残っていないこともある。

AIに判断させない

コードを渡して「移行と作り直し、どちらがよいか」と聞くと、それらしい答えは返る。

しかしAIは予算も納期も社内の事情も知らない。返ってくるのは一般論で、判断材料にはなるが判断にはならない。

使い方としては、「このコードを読んで、仕様として何を実現しているか箇条書きにして」のほうが役に立った。判断は人、読解はAI。

迷ったら一部だけ移す

机上で比べても決まらないときは、1画面だけ実際に移してみることにした。

かかった時間を測り、同じ画面が何枚あるかを掛ける。これがいちばん確からしい見積もりになった。やってみると、想像より速いことも遅いこともある。

作り直しを選ぶ場合の注意

作り直しは、途中で止めると何も残らない。移行は途中で止めても一部が良くなる。

この違いは大きく、予算が確定していない案件で作り直しを選ぶのは危ない。止まった時点で、古いシステムがそのまま残る。

混ぜる選択肢

全部を同じ方針にしなくてよい。

• よく使う画面 → 作り直して使い勝手も直す
• たまにしか使わない管理画面 → 移行だけして、見た目は変えない
• 誰も使っていない画面 → 消す

3番目が意外と多い。アクセスログを見て使われていない画面を先に消すと、対象が減って全体が軽くなる。

古いPHPのまま延命する選択

移行も作り直しもせず、サーバーのPHPだけ古いまま使い続ける現場もある。短期的には最も安いが、代償がはっきりしている。

• セキュリティ更新が止まり、脆弱性が出ても塞がらない
• 対応するサーバーが減り、引っ越し先が限られる
• 触れる人が減り、改修の単価が上がっていく

決めずに先送りした結果としてこうなっている場合が多い。延命を選ぶなら、いつまで延命するかを同時に決める。期限が無い延命は、ただの放置になる。

判断を記録に残す

どちらを選んだかより、なぜそう決めたかを残しておくほうが後で効いた。

移行の途中で「やっぱり作り直したほうが」という話が出たとき、判断の前提が変わったのか、気分の問題なのかを切り分けられる。

まとめ

移行か作り直しかは、行数では決まらない。仕様がコードにしか無いなら移行、人や文書にあるなら作り直しも選べる。

決め手が無ければ、1画面だけ移して時間を測る。想像で比べるより、よほど早く答えが出た。