LASSIC Media らしくメディア
PHPエンジニア不足とレガシー保守を受託・ニアショアで補完する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- PHPは案件数が多い一方、レガシー保守に対応できる採用候補は限られており、内製一本での人材確保には限界があります
- PHP 5系・7系などサポート終了バージョンのまま放置すると、セキュリティリスクと属人化リスクが複合的に高まります
- 受託開発・ニアショア・フリーランス活用という補完手段を組み合わせ、PHP 8.x/Laravelへの段階移行を進めることで、安定した保守体制を構築できます
目次
PHPエンジニアの需給：Laravel人気・案件は豊富・レガシー保守人材は希少
PHPエンジニア不足の補完策とは、PHP（Laravel等）による開発・レガシーシステムの保守において自社採用だけでは人材を確保しきれない場合に、受託開発・ニアショア・フリーランス活用といった外部の技術力を組み合わせてシステムの開発・保守を継続させる取り組みです。
PHPはWebシステムで広く使われており、フレームワークとしてはLaravelが高い人気を維持しています。Stack Overflow Developer Survey 2024*1では、PHPは回答者が使用する言語の上位に位置づけられており、業務システム・ECサイト・CMSなど幅広い用途で稼働中のシステムが存在します。
案件数の面では、各エンジニア向けフリーランスエージェントの公開データ（市場参考値・2025年時点）によると、PHP/Laravel案件は引き続き一定の規模で流通しています。ただし、これは参考値であり一次資料ではないため、最新の案件状況は各エージェントのサイトで個別にご確認ください。
レガシー保守人材が希少なのはなぜか
PHPの需要は続く一方で、新規採用では敬遠されやすい面があります。GoやRust、TypeScriptといったモダンな言語を選好するエンジニアが増えており、「PHP 5系・7系のレガシーコードを読んで保守できる人材」を市場から探すのは難しい状況です。
経済産業省「IT人材需給に関する調査」（2019年公表）*2では、2030年にかけてIT人材の需給ギャップが高位シナリオで約79万人に達する見通しが示されています。PHPのレガシー保守に対応できる人材は、このギャップの中でも特に希少なカテゴリに属します。
また、レガシーPHPの保守に必要なスキルは以下のように多岐にわたります。社内でこれらをすべて満たす人材を育成・確保するのは、時間とコストの両面でハードルが高いといえます。
- 旧バージョンPHPの知識：PHP 5.x・7.x系の文法・関数・挙動の理解
- フレームワーク経験：CodeIgniter・CakePHP・Zend Framework など旧世代フレームワークの保守経験
- バージョンアップ対応：非推奨関数の置き換え・後方互換性の確認・依存ライブラリの更新
- テスト整備：既存コードへのPHPUnitテスト追加・リグレッションテストの構築
- インフラ知識：Apache/Nginx設定・MySQL・Linux環境でのデプロイ・運用
レガシーPHPを放置するリスク：サポート終了・属人化・改修困難・セキュリティ
「動いているから問題ない」という理由でレガシーPHPのバージョンアップを後回しにすることは、複数のリスクを同時に抱え込むことになります。主要なリスクを4つの観点から整理します。
セキュリティリスク：サポート終了バージョンへの脆弱性放置
PHPの各バージョンにはアクティブサポートとセキュリティサポートの期限があります（最新のサポートスケジュールは公式 php.net で確認することを推奨します）。セキュリティサポートが終了したバージョンでは、新たに発見された脆弱性に対して公式パッチが提供されません。
この状態で稼働し続けると、不正アクセス・SQLインジェクション・リモートコード実行などの攻撃を受けるリスクが高まります。個人情報や決済情報を扱うシステムであれば、情報漏えいに伴う法的・経営的な損害につながる可能性があります。サポート終了バージョンの放置は、対策コストより損害リスクが大きくなりやすい判断ミスといえます。
属人化リスク：担当者が離職すると保守が止まる
レガシーPHPの保守を特定の担当者に依存している場合、その人が離職・異動すると保守ノウハウが失われます。旧バージョン特有の挙動・設計の経緯・非標準の実装を理解している担当者がいなくなると、障害対応や機能追加に大きなリードタイムが発生します。
ドキュメントが整備されていないコードベースほどこのリスクは高くなります。属人化が進んだ状態で担当者交代が起きると、新担当者がキャッチアップするまでの期間中に運用品質が低下する可能性があります。
改修困難リスク：新機能追加・連携が困難になる
旧バージョンのPHPはモダンなAPIやライブラリに対応していないことがあります。たとえば、OAuth 2.0対応のSDKや最新のAWSサービスクライアントなど、PHP 8.x以降を前提としたライブラリを旧バージョンの環境に組み込もうとすると、互換性の問題で動作しないケースがあります。
新機能の追加や外部サービスとの連携のたびに「まず環境の問題を解決する」工数が発生するため、開発のスピードが落ちます。競合他社がモダンな環境で素早く機能を追加できる状況と比べると、事業上の機会損失につながります。
採用・外注のしにくさ：候補者が限られる
旧バージョンのPHPやレガシーフレームワーク環境への参画を嫌がるエンジニアは少なくありません。採用においても「PHP 5系環境での保守」という条件は応募数を減らす要因になりやすく、外注先の選定においても対応できるベンダーが限られます。バージョンアップを進めることで、採用・外注の選択肢を広げる効果も期待できます。
補完の選択肢：受託・ニアショア・フリーランス・内製育成の比較
PHPエンジニアの不足とレガシー保守の課題に対しては、複数の補完手段があります。それぞれの特徴を比較し、自社の状況に合った組み合わせを選ぶことが重要です。
| 補完手段 | 向いているケース | メリット | 留意点 |
|---|---|---|---|
| 受託開発 | 仕様が固まっており、成果物の納期・品質を優先したい場合。 レガシー移行の特定フェーズを切り出して委託したい場合。 |
品質・納期の責任が委託先に帰属する。 内部工数を圧迫しにくい。 |
仕様変更が頻繁だとコストが増えやすい。 ブラックボックス化リスクへの対策が必要。 |
| ニアショア （地方・準国内拠点） |
長期の継続保守・段階移行を安定したコストで委託したい場合。 オフショアより品質・コミュニケーション重視の場合。 |
時差・言語の障壁が少なく品質管理しやすい。 コストを一定抑えながら国内水準の品質を期待できる。 |
適切な委託先の選定に時間がかかる場合がある。 業務ドメイン知識の移転が必要。 |
| フリーランス活用 | 特定スキル（Laravel・PHP 8.x移行等）のスポット補完が必要な場合。 社内チームに即戦力として加わってほしい場合。 |
スキルセットを指定して採用できる。 短期〜中期の需給調整に柔軟に対応できる。 |
管理・マネジメントは自社が担う必要がある。 長期安定性・属人化リスクへの配慮が必要。 |
| 内製育成 | 中長期的に内製比率を高めたい場合。 業務ドメイン知識を内部に蓄積したい場合。 |
知識・技術が社内に残る。 長期的なコスト低減につながりやすい。 |
即効性がなく、育成リードタイムが発生する。 育成中の戦力不足をどう補うか別途検討が必要。 |
多くの場合、単一の手段だけで補完を完結させるのは難しく、「受託でレガシー移行の山場を乗り越えつつ、ニアショアで継続保守を担う」「フリーランスで即戦力を補完しながら内製育成を並走させる」のような組み合わせが現実的です。
受託・ニアショアで補完する進め方：現状把握からPHP 8.x/Laravel移行・保守体制まで
補完策を実行に移す際の進め方を4つのフェーズで整理します。いきなり移行作業に着手するのではなく、現状を正確に把握することから始めることが、失敗を避ける上で大切なポイントです。
フェーズ1：現状把握とドキュメント化
まず、稼働中システムのPHPバージョン・フレームワーク・依存ライブラリ・データベース構成を棚卸しします。この情報が整理されていないと、外注先への正確な要件伝達ができません。
あわせて、現行コードのドキュメント状況を確認します。仕様書・設計書が存在しない場合は、外注先がコードリーディングから着手することになり、見積もりに影響します。既存の担当者が知っている仕様・設計意図を可能な限りテキスト化しておくことで、引き継ぎコストを下げられます。
フェーズ2：移行・保守の優先順位づけと委託範囲の設計
セキュリティリスクが高い箇所（サポート終了バージョン上で稼働する決済・認証・個人情報処理機能）から優先的に対処することを検討してください。全体を一括で移行しようとすると工数・リスク・コストがかさむため、段階的なフェーズ計画を立てることが重要です。
委託範囲を設計する際は、「外注でやること」と「内部で管理すること」を明確に分けます。コードの所有権・デプロイの権限・本番環境への接続権限など、セキュリティ上の境界線をあらかじめ合意しておくと、委託開始後のトラブルを減らせます。
フェーズ3：段階移行の実施（PHP 8.x/Laravel）
PHP 8.x系への移行では、廃止された関数・変更された挙動への対応が中心作業になります（具体的な変更点はPHP公式の移行ガイドで最新版を確認することを推奨します）。Laravelへの移行・バージョンアップも同様に、公式ドキュメントの移行ガイドを参照しながら進めます。
移行前にPHPUnitを用いたテストを整備しておくと、移行後のリグレッション（意図しない動作変化）を検出しやすくなります。テストカバレッジが低いコードベースへの移行は、外注先にとっても高リスクの作業であるため、テスト整備を移行前の必須工程として位置づけることをお勧めします。
フェーズ4：保守体制の構築とドキュメント維持
移行が完了した後も、継続的なセキュリティパッチの適用・ライブラリの更新・監視対応が必要です。ニアショアや受託先との長期保守契約を締結し、対応フロー・エスカレーション経路・定期レポートの形式を事前に合意します。
運用引き継ぎの際には、システム構成図・デプロイ手順・障害対応フローなどのドキュメントを受け取ることを契約条件に含めることが重要です。ドキュメントなしで引き継いでしまうと、再び属人化のリスクが生じます。
委託先の選び方：PHP/Laravel実績・レガシー移行経験・テスト/CI・コミュニケーション
PHPのレガシー保守・移行を外注する際の委託先選定では、一般的なシステム開発の外注とは異なる確認ポイントがあります。以下の4つの軸で評価することを推奨します。
PHP/Laravel実績の確認
公開ポートフォリオや提案書に、PHP/Laravelを用いた開発・保守の具体的な事例が含まれているかを確認します。特に、移行前のバージョンと移行後のバージョン、移行の規模・期間が記載されているかがポイントです。Laravelのバージョンアップ（例：Laravel 8→10系）の経験があるかどうかも、レガシー対応力の指標になります。
レガシー移行経験の有無
新規開発の実績は豊富でも、既存の旧バージョンコードへの対応経験が少ない会社は、レガシー移行プロジェクトで想定外のコストや工期遅延が発生しやすくなります。「どのようなレガシーシステムの移行に対応してきたか」を具体的に確認し、類似規模・類似バージョンの経験があるかを判断材料にしてください。
テスト・CI/CD整備の体制
移行前後のテスト自動化（PHPUnit）・CI/CD（継続的インテグレーション/継続的デリバリー）整備への取り組みを確認します。テストのないまま移行を進める委託先は、リグレッションを見落とすリスクが高くなります。GitHubやGitLabのCI設定・テストカバレッジの管理方針を事前に確認しましょう。
コミュニケーション体制と元請体制
定例ミーティングの頻度・進捗報告の形式・障害時の対応フローを事前に確認します。元請（プライムベンダー）として窓口を一本化できる体制の委託先を選ぶと、複数の下請け会社を経由した場合のコミュニケーションロスを減らせます。レガシー保守のように長期にわたる関係では、コミュニケーションの質が委託成果に直結します。
また、委託先のエンジニアがLASSICのような元請体制の中で保守に携わる場合、「どのチームが最終的な品質責任を持つか」が明確になることで、品質管理のブレが生じにくくなります。
まとめ：PHPレガシー保守と外注補完を成功させる3つの判断軸
本稿では、PHPエンジニア不足の背景・レガシーPHPを放置するリスク・補完手段の選択肢・進め方・委託先選定の方法を整理しました。要点を3つに集約すると次の通りです。
第一に、PHPは案件数が多い一方でレガシー保守人材は希少であり、採用一本足の戦略では安定した体制を維持しにくくなっています。受託・ニアショア・フリーランス活用の組み合わせによる補完が現実的な対策です。
第二に、サポート終了バージョンのPHPは放置するほどセキュリティリスク・属人化リスク・改修困難リスクが複合的に高まります。段階的なPHP 8.x/Laravel移行を「コスト」ではなく「リスク低減への投資」として位置づけることが重要です。
第三に、委託先の選定ではPHP/Laravel実績・レガシー移行経験・テスト/CI体制・コミュニケーション体制の4軸で評価し、元請（プライムベンダー）として窓口を一本化できる体制を持つパートナーを選ぶことで、長期保守の安定性を高められます。
よくある質問
PHPエンジニアの採用が難しい理由はなんですか？
PHPはWebシステムで広く使われており案件数は多い一方、新規採用市場では「枯れた技術」として敬遠される傾向があります。特にPHP 5系・PHP 7系など旧バージョンのレガシーシステムを保守できる経験者は希少で、給与水準の高いGoやRustなどモダン言語への転換を希望するエンジニアも増えています。経済産業省「IT人材需給に関する調査」（2019年公表）でもIT人材不足の拡大が見込まれており、PHPのレガシー保守人材確保は今後さらに困難になる見通しです。
PHP 5系・PHP 7系のレガシーシステムをそのまま使い続けてもよいですか？
セキュリティの観点から推奨できません。PHP 5.6系・PHP 7.4系はすでにセキュリティサポートが終了しており（サポート状況は公式 php.net で最新情報を確認してください）、脆弱性が発覚しても公式パッチは提供されません。放置を続けると不正アクセス・情報漏えいのリスクが高まります。段階的なバージョンアップへの移行計画を立てることを検討してください。
受託開発とニアショアはどう使い分ければよいですか？
成果物の仕様が固まっており納期と品質を優先したい場合は受託開発が向いています。一方、仕様が変化しやすい場合や、継続的な改修・運用保守を長期委託したい場合はニアショア（地方拠点やオフショアに近いコスト感で国内品質を確保できる形態）が適します。レガシーPHPの段階移行のように長期にわたる作業はニアショアのラボ型契約との相性がよいといえます。
PHP 8.xやLaravelへの移行はどの程度の工数がかかりますか？
システムの規模・コードの品質・テストカバレッジによって大きく異なります。一般的には、事前のコード調査・依存ライブラリの棚卸し・テスト整備・段階移行・検証という工程が必要で、規模が大きいほど複数フェーズに分けて対応することになります。公式の移行ガイドや各バージョンの廃止・変更事項（php.net の移行ガイド参照）を確認しながら、外注先と工程を設計することをお勧めします。
委託先にPHP/Laravelの実績を確認する際に見るべきポイントはなんですか？
PHP/Laravelの公開ポートフォリオや、レガシーPHPからの移行経験の有無を確認することが出発点です。加えてテスト自動化（PHPUnit）・CI/CD整備の実績、コードレビュー体制、ドキュメント化への取り組みを確認しましょう。元請（プライムベンダー）として窓口を一本化できる体制かどうかも、コミュニケーションコスト管理の観点で重要なポイントです。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Stack Overflow「Developer Survey 2024」（2024年公表）
- *2 出典：経済産業省「IT人材需給に関する調査」（2019年公表）
