古い PHP フレームワークのシステム、書き換えか延命かの判断基準

結論から書くと、判断の出発点は「コードが古いかどうか」ではなく、そのシステムをあと何年、どのくらい変更しながら使うか です。あまり変更せず数年使うなら延命、変更が多く長く使うなら段階移行が有力で、全面書き換えは条件が揃った場合に限るのが安全です。

書き換えは魅力的に見えます。ただ、今のシステムには、仕様書に残っていない業務のルールが詰まっています。何となく作り直すと、それを失うことになります。

3つの選択肢

まず、選択肢を整理します。

実際にはこの中間もあります。たとえば、延命で当面のリスクを下げてから、変更の多い機能だけ段階的に移す、といった組み合わせです。

判断に使う6つの基準

1. 業務の寿命

そのシステムが支える業務は、今後も続くのか。3年後に事業の形が変わる、パッケージ製品に置き換える予定がある、という場合は、大きな投資をする理由が薄れます。システムよりも先に、事業側の見通しを確認します。

2. 変更の頻度

年に数回の小さな修正で済んでいるのか、毎月のように機能を追加しているのか。変更が少ないなら、読みにくいコードでも実害は限られます。変更が多いのに触るのが怖い状態は、継続的な費用が発生しているので、投資を回収しやすくなります。

3. フレームワークの状況

公式の情報を確認します。主なものを挙げます。

• CodeIgniter 3: 公式の 3.x から 4.x への案内には、CodeIgniter 4 はフレームワークの書き直しで後方互換性がなく、アップグレードというよりアプリケーションの変換と考えるほうが適切である、と書かれています。「少し上げるだけ」では済みません。
• Zend Framework: プロジェクトは Laminas へ移っています。Laminas は Zend Framework をコミュニティで継続するものですが、Zend Framework 1 のコードがそのまま動くわけではありません。
• CakePHP: 公式のリリースポリシーに、メジャーリリースは一般に後方互換性がない、とあります。
• Symfony: 公式のリリース情報に、バージョンごとの保守期限が明記されています。
• Laravel: 公式の表に、バージョンごとのセキュリティ修正の期限があります。

更新が止まったフレームワークでも、すぐに動かなくなるわけではありません。問題は、フレームワーク自身の脆弱性を自分たちで修正する必要が出ること、PHP の新バージョンへの対応を自力で行うことです。

4. 今の PHP で動かせるか

延命が現実的かどうかは、実際に調べないと分かりません。PHP のサポート期限内のバージョンで動かすと、どのくらいの箇所が問題になるかを調査します。検証環境で実際に動かしてエラーを洗い出せば、作業量の見当がつきます。

例として、h-system では Zend Framework 1 で構築された不動産業向けのクラウドシステムを PHP 8.1 で動作するように対応しました。更新の止まったフレームワークでも、状況によっては延命できるということです。ただ、これがどのシステムにも当てはまるわけではありません。

5. 仕様を説明できる人がいるか

全面書き換えの最大のリスクは、今の動きが正しい理由を誰も説明できないことです。「このケースだけ計算が違う」といった処理には、たいてい業務上の理由があります。担当者が残っていないなら、まずコードから仕様を復元する必要があり、それだけで大きな作業になります。

6. データと外部連携

データベースの設計と外部連携は、アプリケーションよりも長く生き残ります。データに不整合が多い、連携先が多く停止調整が難しいといった場合は、一度の切り替えの難易度が上がるので、段階移行に寄せたほうが無難です。

全面書き換えで失敗しやすい点

失敗の多くは、次のパターンに当てはまります。

• 「今と同じものを新しく」を要件にしてしまう。 仕様書がないので「今と同じ」を誰も定義できず、受け入れの基準がなくなります。機能ごとに、残す、捨てる、変えるを決める必要があります。
• 旧システムの変更が止まらない。 書き換えている間も業務は変わるため、新旧の両方に修正が必要になり、ゴールが遠ざかります。
• 切り替えが遠すぎる。 全部できるまで使ってもらえないと、問題の発見が遅れます。
• データ移行を後回しにする。 実データは想定以上に例外が多いものです。早い段階で試行します。
• 作り直せばきれいになると期待する。 複雑さの多くは業務そのものに由来するので、技術を替えても消えません。

段階移行の進め方

段階移行では、入口で振り分けて、新しい機能だけ新しいアプリケーションで処理します。すぐに全部を移さなくてよいのが利点です。

1. 今のシステムを動かせる状態にする（PHP のサポート内へ、または公開範囲の制限で当面のリスクを下げる）
2. 新旧の間の共通部分（ログイン、データベース）の扱いを決める
3. 変更の多い機能、または独立性の高い機能から移す
4. 移した機能の旧コードは残さず削除する

欠点は、併存している間の構成が複雑になることです。途中で止まると両方を保守し続けることになるので、完了条件を決めておくか、途中で止まっても価値が残る順番で進めます。

費用は「今後の総額」で比べる

3つの選択肢を比べるときは、最初の費用だけを見ないでください。延命は初期費用が小さい反面、その後の改修のたびに時間がかかり、数年後にまた対応が必要になることがあります。全面書き換えは初期費用が大きいものの、新旧の二重の保守や切り替えの費用も見込む必要があります。

比べるときは、次の項目をそれぞれの案で並べます。

• 最初の改修や開発の費用
• 今後の改修で見込まれる費用
• サーバーやサポートの費用、再度の更新が必要になる時期
• 切り替えに伴う業務側の負担（データの確認、操作の教育、停止の調整）
• 何もしなかった場合のリスク

金額の精度は最初から高くなくて構いません。調査の結果で見直せばよく、大事なのは「何もしない」も含めて、選択肢を同じ形式で比べることです。

判断に迷ったときは、次の順で考えてみてください。

1. 3年後も今の業務でこのシステムを使っているか → いいえなら延命か、入れ替えの検討
2. 変更はこれからも頻繁にあるか → いいえなら延命
3. 止められるか、規模は小さいか、仕様を説明できる人がいるか → すべてはいなら全面書き換えも候補、それ以外は段階移行

h-system でできること

h-system では、古い PHP やレガシーフレームワークで作られたシステムの調査、改修、移行をお引き受けしています。いきなり作り直すのではなく、まず現状を調べて影響の範囲を確認し、選択肢ごとの作業量と影響をご説明したうえで進め方をご相談します。CodeIgniter 3 / 4、CakePHP、Symfony、Zend Framework 1、Laravel、フレームワークを使わない素の PHP の実務経験があり、経験のない構成は調査のうえで対応できるかをお伝えします。初回のご相談と概算のお見積りは無料で、調査だけのご依頼も可能です。