「動いているものを、新しいバージョンに上げるだけですよね」
言語やフレームワークのバージョンアップを外部に頼むとき、この認識のまま話が始まることがあります。見積もりを出すと「そんなにかかるんですか」と言われ、こちらは説明の言葉を探すことになります。動いているものを動いたまま持っていくのが、なぜ新規開発より安くならないのか。
この説明に使える数字が、8月末に公開されました。
16年ぶりの移行が公開した数字
EVE Online を運営する CCP（Fenris Creations）が、2026年8月25日に Python 2.7 から Python 3 への移行を開始したことを発表しました。同ゲームは2003年のサービス開始時から Stackless Python で動いており、最後の大きな更新は2010年の Stackless Python 2.7 です。16年ぶりということになります。
対象は240万行の Python コード。一部は Python 2.7 より前、2.3 や 2.5 の時代の書き方で書かれており、Python 3 はそもそも構文として受け付けません。
ここまでは想像どおりの話です。興味深いのは最初のスキャン結果です。
- 95.9% のファイルが、すでに両方のバージョンでコンパイルできた
- Python 3 が構文として拒否する「ブロッキング行」は約3,300行
- その一方で、Python 2 と 3 で挙動が異なる箇所は約20,000箇所あり、これらは手作業でのレビューが必要
240万行に対して構文エラーが3,300行、というのは「思ったより少ない」という感想になる数字です。CCP 自身も嬉しい驚きだったと書いています。移行の作業は、Python コミュニティのツール（futurize など）を使う段階と、EVE 固有の事情に踏み込む段階に分かれて進みます。
3,300 と 20,000 の差が、見積もりの差
この2つの数字は、性質がまったく違います。
3,300行は、機械が見つけてくれます。 構文として通らないので、実行する前に止まります。修正の方針も決まっており、多くは機械的に置換できます。ここだけを見て工数を出すと、金額は小さくなります。
20,000箇所は、機械が見つけても、正しさは機械が判断できません。 構文としては通ります。実行もされます。ただし結果が変わります。
Python 2 と 3 の代表的な違いを挙げると、整数どうしの除算の結果、文字列とバイト列の扱い、辞書の順序、比較のルール、例外の書き方あたりです。このうち最も危険なのは、金額や数量の計算に効くものです。
割り算の結果が切り捨てられるかどうかが変わったとき、プログラムはエラーを出しません。請求額が1円ずれた状態で、そのまま処理が最後まで走ります。テストが通り、画面も正常に表示され、月末になって経理から連絡が来ます。
「そのまま動く」を確認する手段があるか
移行の見積もりを読むときに確認すべきなのは、修正の工数ではなく、修正が正しいことをどう確認するかです。
理想は、移行前のシステムに対して十分なテストがある状態です。その場合、移行後に同じテストを流して結果を比べられます。ただし、10年以上動いてきた業務システムにその状態を期待できることは、あまりありません。
テストが揃っていない場合に取れる手段は、おおむね次のどれかです。
- 本番の入出力を記録して、新旧に同じ入力を流して結果を比べる。 実際に使われている経路だけを確認できます。使われていない経路は確認できません
- 重要な処理に限定してテストを先に書く。 全部は無理なので、金額計算・在庫・権限のように間違えたときの影響が大きいところから書きます
- 一定期間、新旧を並走させて出力を突き合わせる。 手間はかかりますが、確認としては最も強い方法です
どれを選ぶかで金額は変わります。見積もりを比較するときは、どの手段を前提にした金額なのかを揃えてから比べてください。手段を書いていない見積もりが最も安く見えます。
なお、テスト自体の工数の見積もりが外れる理由についてはテストの工数見積もりで2回の掛け算が抜ける話に書いています。移行案件では、この見落としがそのまま乗ってきます。
発注する側が決めておくこと
期間中に機能追加を止めるかどうか。 移行と機能追加を並行すると、確認すべき差分が動き続けます。止められないなら、その前提で計画を立てる必要があり、期間は延びます。「止めない」と決めるのは構いませんが、決めないまま始めるのがいちばん高くつきます。
どこまでを移行の範囲にするか。 動いてはいるが誰も使っていない機能が、たいてい見つかります。それらを移行の対象から外す判断は、発注側にしかできません。外せる機能を洗い出すだけで、20,000箇所のうち何割かが消えます。
いつまでに終わらせる必要があるのか。 サポート終了に伴う期限があるのか、単に古いから直したいのか。前者なら、サポート終了日から逆算する進め方になります。後者なら、業務を止めない範囲で段階的に進める余地があります。
つまずきやすいところ
「移行と同時に作り直す」に流れないでください。 どうせ触るなら画面も新しくしたい、という話は必ず出ます。ただし同時にやると、不具合が出たときに移行が原因なのか改修が原因なのかを切り分けられません。画面の作り直しは移行のあとに回すほうが、結果的に早く終わります。
移行が終わったら保守が減る、とは限りません。 新しいバージョンで動き始めた直後は、想定していなかった箇所の不具合が出ます。保守の契約を移行完了と同時に薄くする計画は、時期をずらしてください。
次にやること
移行を検討しているシステムについて、現在どのバージョンで動いているかと、そのバージョンのサポートが切れているかを確認してください。切れているなら、期限のある案件です。
そのうえで、いま自動で流せるテストがどれだけあるかを開発側に聞いてください。「ほとんどありません」という答えが返ってきた場合、移行の見積もりに含まれるべき最大の項目は、修正ではなく確認の手段です。
レガシーシステムの移行範囲の切り分け、確認手段の設計、段階的な移行計画の策定については、グリームハブの開発・AI・自動化のご相談で承っています。対象システムの規模と現在のテストの状況によって進め方が変わるため、お問い合わせからご相談ください。
Sources
- The Move to Python 3 Begins! — EVE Online
- EVE Online: The Move to Python 3 Begins! — Simon Willison’s Weblog
- 巨大オンラインゲーム「EVE Online」。ゲームを支える240万行のPython 2.7のコードをPython 3へ移行すると発表 — Publickey
- Built on ‘a codebase older than some of you,’ EVE Online is undergoing a major code migration — Massively Overpowered
