レガシーPHPの移行にAIを使って、結局どこが速くなったか

• 速くなったのは「読む」と「同じ形を量産する」
• 変わらないのは「決める」と「確かめる」
• 全体の時間は減ったが、減り方は一様ではない

レガシーPHPの移行でAIを使ってきた内容を、最後にまとめる。

はっきり速くなった所

共通しているのは、正解が決まっていて、量が多い作業だ。ここは任せるほど速くなる。

まったく変わらなかった所

• 移行するか作り直すかの判断
• どこまでやるかの線引き
• 仕様が分からない処理をどうするかの決定
• 本番に出す判断

決める作業は1秒も速くならない。むしろ、手が速くなった分だけ決める回数が増えて、負担は増えた。

確かめる作業は増えた

これは正直に書いておきたい。書く速度が上がると、確認すべき量も同じだけ増える。

確認を省くと、動くけれど間違っているコードがそのまま残る。結果として、移行作業全体に占める「確認」の割合は、前より高くなった。

時間配分がどう変わったか

感覚でしかないが、だいたいこう変わった。

• 読む・調べる → 減った
• 書く → 大きく減った
• 決める → 変わらない
• 確かめる → 増えた

合計では減っている。ただし「書く時間が減った分がそのまま浮く」わけではない。

やってよかった順

1. 棚卸しを先に作る — 全体像が数字で出る。見積もりも頼み方も全部ここから決まった
2. 移行前の記録を取る — コードを書かない作業だが、効果はいちばん大きい
3. 動くけれど危ない所を先に直す — 落ちるものは必ず気づくので後でよい
4. 呼んでいる関数を一緒に渡す — AIの間違いが目に見えて減った

依頼する側の負担も変わった

棚卸し表を見せられるようになったことで、相手が判断できる情報が増えた。

「全部で200万円です」より、「機械的な置き換えが8割で、判断が要るのが2割。2割の中身はこの一覧です」のほうが、どこを削るかの相談ができる。予算が足りないときに、作業を減らす話ができるようになった。

工程 / 自分でやった時間 / 任せた時間 / 手直しの時間

・いまの仕様の洗い出し
・影響範囲の調査
・書き換え
・動作の確認
・不具合の修正
・手順書の作成

やらなくてよかったこと

全体にテストを書こうとしたこと。着手できずに時間を使った。

カバレッジを目標にしたこと。簡単な所ばかりテストが増えて、肝心の所が手つかずになった。

いきなり静的解析を入れたこと。警告が数千件出て、読む気が失せて止まった。

向いている案件・向いていない案件

同じ形のファイルが大量に並んでいる案件は、AIを使うほど速くなる。

逆に、1ファイルごとに事情が違う案件は、あまり変わらなかった。毎回前提を説明することになり、説明の時間が書く時間を超える。

PHP界隈でこの話が少ない理由

古い資産は多いのに、移行の記録はあまり出てこない。公開しにくい内容だからだと思う。

コードは客先のもので、内容も外に出しにくい。だから、やり方だけを切り出して書ける人が少ない。需要と供給が噛み合っていない分野だと感じる。

費用の出し方が変わった

作業時間に単価を掛ける出し方だと、速くなった分だけ金額が下がる。しかし判断と確認は減っていないので、実際の負担とずれる。

いまは工程ごとに分けて出している。棚卸し、安全化、移行、確認。量で決まる工程と、判断で決まる工程は、同じ考え方で値付けしない。

引き継ぎやすさが上がった

思わぬ副産物として、作業の記録が残るようになった。

棚卸し表、移行前の記録、差分の一覧。これらは全部ファイルとして残るので、途中で人が替わっても状況が分かる。以前は作業者の頭の中にしか無かった。

まとめ

レガシー移行は、AIで速くなる部分とならない部分がはっきり分かれる。

速くなるのは量のある単純作業。変わらないのは判断。そして確認は増える。この前提で計画を立てれば、見積もりも外れにくい。「AIを使えば全体が何割減る」という考え方をやめたところから、うまく回り始めた。