結論から書くと、PHP のバージョンアップの見積を左右するのは、コードの量より 「開けてみないと分からない部分」の大きさ です。上げる幅、フレームワークとライブラリの対応状況、テストの有無、検証環境を作れるかどうか。この4つが分からないほど、受ける側は失敗に備えた分を上乗せするしかありません。
逆に言えば、依頼する前に情報を揃えるだけで、見積の幅は狭くなります。費用を下げる工夫としては、作業を削るより先に、不確かさを減らすほうが効果があります。見積が高くなる仕組みそのものは「業務システムの見積が高くなる理由と、安く抑える要件の書き方」でも説明しています。
見積を左右する要素
受ける側が見ているのは、主に次の項目です。
| 要素 | 作業が増える方向 | 確かめ方 |
|---|---|---|
| 上げる幅 | 何世代も上げる、7 系から 8 系をまたぐ | 今と移行先のバージョン |
| フレームワーク | 新しい PHP に対応していない、更新が止まっている | フレームワークとそのバージョン |
| ライブラリ | 移行先の PHP に対応していない、手で置いたものがある | composer.lock、composer prohibits |
| テスト | 無い。動作の確認が人の手作業になる | テストの有無と、今も通るか |
| 環境 | 検証環境が無い、本番を再現できない | 本番のコピーで動かせるか |
| 確認の範囲 | 定期処理や外部連携が多い、受け入れの担当がいない | 機能と連携の一覧 |
上げる幅
PHP には、バージョンごとの 移行ガイド があります。上げる幅が大きいほど、確認するガイドと非互換の項目が増えます。特に 7 系から 8 系への移行は変更が多く、PHP 8.0 の非互換の一覧には、each() や create_function() の削除、数値と文字列の比較の結果が変わる変更などが並んでいます。エラーにならずに結果だけが変わるものは、見つけるのに時間がかかります。
フレームワークとライブラリ
フレームワークが移行先の PHP に対応していなければ、PHP の更新はフレームワークの更新とセットになり、作業は別の規模になります。ライブラリも同じです。Composer を使っていれば、composer prohibits に PHP のバージョンを渡すと、その PHP への更新を妨げているパッケージを一覧にできます。
composer prohibits php 8.4逆に、Composer を使わずに手でファイルを置いたライブラリは、出どころと版を調べるところから始まるので、作業が読みにくくなります。
テストと環境
テストが無ければ、確認は画面を操作する手作業になります。検証環境が無ければ、まずそれを作る作業が必要です。h-system が行う引継ぎ調査でも、ローカルで環境を再現できないことは、ドキュメントが無いことと並んで典型的に見つかる問題です。どちらも、改修そのものとは別にかかる費用です。
見積が「調査」と「改修」の2段階になる理由
古いシステムのバージョンアップでは、最初の見積を調査と改修の2段階に分けることがあります。調査では、検証環境で移行先の PHP にしてコードを動かし、エラーと非推奨の警告、ライブラリの対応状況を洗い出します。これが終わると、改修の作業量をかなり具体的に見積もれます。調査の成果物は、エラーと警告の一覧、ライブラリごとの対応状況、作業の見積と残るリスクの4つが基本です。
依頼する側から見ると、最初に払うのは調査の費用だけで、改修を進めるかどうかは結果を見てから判断できます。調査の結果は手元に残るので、ほかの会社に改修を頼む場合にも使えます。
参考までに、h-system が PHP 7 系から 8 系へ上げた業務システムでは、期間は数週間でした。上げる幅やライブラリの状況、テストの有無で大きく変わるため、あくまで一例です。
依頼の前に用意すると見積の幅が狭まる情報
全部が揃っていなくても構いません。分からない項目は「不明」と書くだけでも、受ける側の判断材料になります。
| 情報 | 調べ方 |
|---|---|
| 今の PHP のバージョン（Web とコマンドラインの両方） | 管理画面、php -v |
| 移行先のバージョンと、上げる理由・期限 | サーバー提供元からの通知など |
| フレームワークとそのバージョン | composer.lock、管理画面の表示 |
composer.json と composer.lock |
リポジトリ、本番サーバー |
| ソースコード一式と、本番と同じものか | 本番のファイルとの比較 |
| 止まると困る機能の一覧（重要な順） | 利用者への聞き取り |
| 定期処理と外部連携 | crontab -l、管理画面のスケジュール設定 |
| 検証環境を用意できるか、本番のデータを使えるか | 社内の取り決め |
| 受け入れの確認を誰がするか | 社内の担当者 |
特に効くのは、止まると困る機能の一覧 と 受け入れの確認の担当 です。確認の範囲が決まっていないと、受ける側は全機能の確認を前提に見積もることになります。
見積を比べるときに見ること
複数の見積を比べるときは、金額だけでなく、何が含まれているかを揃えて比べます。
- 非推奨の警告をどこまで直すか。 PHP 8.1 では組み込み関数の引数に null を渡すことが、PHP 8.2 では動的プロパティの作成が非推奨になりました。警告を残したまま「動く」状態で終えるのか、警告まで消すのかで作業量は大きく違います。
- ライブラリの置き換えを含むか。 対応していないライブラリが見つかった場合の扱いが書かれているか。
- 確認の方法。 誰が、何を確認するのか。テストを追加するのか。
- 本番の切り替えと戻し方。 切り替えの手順と、問題が出たときに戻す手順を含むか。
- 追加費用の条件。 調査で分からなかった問題が後で見つかった場合にどうするか。
安い見積は、範囲が狭いだけということもあります。範囲が揃っていない見積を金額だけで比べると、後から追加の費用が出て、結果的に高くつくことがあります。
依頼する側の工夫で費用を抑える
情報を揃える以外にも、依頼する側が決められることで、作業の量を減らせます。
使っていない機能を先に止める。 古いシステムには、今は誰も使っていない画面や帳票、問い合わせフォームが残っていることがあります。利用者に確認して不要なものを止めれば、直す箇所も確認する箇所も減ります。公開範囲が減るので、セキュリティの面でも効果があります。
受け入れの確認を社内で担当する。 止まると困る機能の一覧をもとに、確認の手順を社内で実行できれば、その分の作業は見積から外せます。業務の正しい動きを一番よく知っているのは利用者なので、確認の精度も上がります。
段階に分けて依頼する。 たとえば最初の段階は「サポート期間内の PHP で、主な機能が動くこと」までにして、非推奨の警告の解消やライブラリの置き換えは次の段階に回す、という分け方です。1回の金額が小さくなり、途中で判断し直す機会もできます。
期限に余裕を持って相談する。 期限が迫っていると、調査に時間をかけられず、分からない部分を広めに見積もるしかなくなります。サポートの期限は前もって分かっているので、早めに相談するだけで選べる手が増えます。期限を放置した場合のリスクは「サポート切れ PHP を放置するリスクと、対応の優先順位」にまとめています。
h-system でできること
h-system では、PHP のバージョンアップを、調査から改修、本番の切り替えまで開発者本人がお引き受けしています。まず調査で、移行先のバージョンで動かしたときの問題とライブラリの対応状況を洗い出し、作業の範囲と費用をご説明してから改修に進みます。上の表の情報が揃っていなくても、分かる範囲でお知らせいただければ構いません。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。