自社開発なのにPHPがEOLのまま、塩漬けの会社を見極める転職基準

入社初日、先輩に教わった手順で開発サーバーにつないで php -v を打つと、画面には「PHP 7.4.33」と出た——。自社開発を選んで転職した方から、この一行をきっかけに相談を受けることがあります。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、「自社開発なら技術は新しいはず」という期待と、入社後の実態がずれる相談は、バージョンの話に限っても珍しくありません。今回は、EOL（サポート終了）を過ぎたPHPが放置される会社を入社前にどう見極めるか、入ってしまった場合に何を積み、いつ見切りをつけるかを、実体験を交えてお伝えします。

目次

1. 自社開発でもPHPがEOLのまま、塩漬けの会社は珍しくない
2. PHPとフレームワークのサポート期限を整理する
3. フレームワークは「PHPと別に」期限がある
4. EOL放置は技術ではなく、組織の意思決定の問題として表れる
5. 求人票で塩漬け度を読む手がかり
6. バージョンの記載があるか、どう書かれているか
7. 業務内容の「保守・改修」の比重
8. 歓迎スキルの並び方
9. カジュアル面談・面接で聞く質問
10. 相談事例：本番が「PHP 7.4.33」のまま1年以上動いていた職場
11. 在籍中に積める資産：アップグレードそのものより「進め方」を残す
12. 見切りをつけるタイミングの目安
13. 提案しても予算が付かない期間
14. EOLを過ぎた状態でセキュリティ事故や障害が起きたとき
15. 市場価値の観点
16. よくある質問
17. まとめ

自社開発でもPHPがEOLのまま、塩漬けの会社は珍しくない

まず前提を確認しておきます。PHP公式の一覧では、PHP 7.4は2022年11月28日、8.0は2023年11月26日、8.1は2025年12月31日にEOLを迎えています。最終リリースはそれぞれ7.4.33、8.0.30、8.1.34です。冒頭の「7.4.33」は、7.4系の最後のバージョンという意味でした。

つまり2026年10月1日時点で、7.4・8.0・8.1の本番稼働は、セキュリティ修正が一切出ないバージョンの上で動いていることになります。

では世の中にどれくらい残っているのか。W3Techsの統計では、PHPを使う公開Webサイトのうちバージョン8が64.3%、7が27.8%、5が7.8%でした（取得日2026年10月1日。出典：W3Techs「PHPのバージョン別割合」）。これは公開サイト全体の数字で、自社開発企業の業務システムの分布ではありません。「自社開発企業の何割が塩漬け」とまでは言えないので、そこは区別して読んでください。

ただ、7系や5系が「まだ一定数残っている」ことは確かです。そして私の見る限り、自社開発という看板と、技術基盤が新しいかどうかは、ほとんど相関しません。

自社開発は「自分たちのプロダクトを持っている」という事業形態の話で、エンジニアリングの更新頻度を保証するものではないからです。売上を立てている本番が古いPHPで安定して動いているなら、経営側から見れば「触らないのが合理的」になります。

同じ構造で起きる別の失望、たとえばレビュー文化の欠如については、自社開発に転職したのにコードレビュー文化がない会社を入社前に見抜く方法でも書きました。バージョン放置はそれと並ぶ、「看板と実態のずれ」の典型です。

なお、PHPという言語自体を否定したい話ではありません。PHP 8系は性能も型の仕組みも大きく改善されていて、8系を前提に積極採用する会社も多くあります。問題は言語ではなく、更新されないまま放置されている状態です。

PHPとフレームワークのサポート期限を整理する

判断の物差しとして、サポート期限を一度表にしておきます。PHP公式の「Supported Versions」と「EOL」の記載に基づき、確認日は2026年10月1日です（出典：PHP公式 Supported Versions）。

見てほしいのは8.2の行です。「今ちゃんと動いている会社」でも、8.2のまま止まっていれば約3か月後にEOLが来ます。EOLは一度越えたら終わりの話ではなく、毎年やってくる更新作業を継続できているかという運用能力の指標になります。

フレームワークは「PHPと別に」期限がある

もう一つ、見落とされやすいのがフレームワーク側の期限です。Laravelは公式のリリースノートで、バグ修正18か月・セキュリティ修正2年という方針を示しています。Laravel 12の公式ページ記載では、Laravel 10のセキュリティ修正期限は2025年2月4日、Laravel 11は2026年3月12日、Laravel 12は2027年2月24日です。CakePHPも、4.4・4.5のセキュリティ修正は2026年9月9日で終わっています。

Symfonyの5.4はセキュリティ修正が2029年2月まで続くLTSですが、最低要件はPHP 7.2.5です。フレームワークのサポートが残っていても、その下で動かしているPHPがEOLということは、仕組みの上で起こりえます。

ポイント： 見るべきは「フレームワークの名前」ではなく、「本番のPHPのバージョン」と「フレームワークのバージョン」の組み合わせです。片方が新しく見えても、もう片方が止まっている会社はあります。

なお、CakePHPの2系・3系については、確認できた公式表に載っていないため、サポートの扱いを断言しません。求人で見かけたときは、バージョンだけで判断せず、次に書く質問で実態を確かめるのが確実です。

EOL放置は技術ではなく、組織の意思決定の問題として表れる

エンジニア本人の視点だと「なぜ上げないのか」と思いますが、放置される理由はたいてい技術的な難しさではありません。私が相談を受けてきた範囲では、次の三つに集約されます。

三つ目が厄介で、PHPを上げようとすると、依存ライブラリが対応していない、フレームワークも上げないと動かない、フレームワークを上げるには独自のカスタマイズを書き直す必要がある、と芋づる式に作業が膨らみます。見積もりを出した瞬間に、経営側が「その工数は今期は出せない」と判断する。この流れで、1年、2年と止まります。

ここで大事なのは、塩漬けが「エンジニアが怠けているから」ではなく、「更新を意思決定する人が、リスクを認識していないか、後回しにしている」から起きている点です。つまり、あなたが入社してから個人の努力で変えにくい種類の問題です。

そう考える理由はシンプルで、バージョン放置は、予算・優先順位・採用・テストへの投資がすべて同じ方向を向いたときにしか解消しないからです。だから転職の判断では「今のバージョン」より、「更新を止めている構造があるか」を見るほうが有効です。

なお、「技術的負債を理由に転職する」こと自体の面接での語り方は、技術的負債を転職理由にしたら二次面接で詰まった話で整理しています。今回は、入る前の見極めに絞ります。

求人票で塩漬け度を読む手がかり

求人票は、読み方によって塩漬け度の手がかりが取れます。私が候補者と一緒に見るときに目を向けるのは、次の三点です。

バージョンの記載があるか、どう書かれているか

「PHP 8.x」「Laravel 10以上」のようにバージョンが具体的に書かれていれば、少なくとも書いた人は把握しています。一方、「PHP」「CakePHP」とだけある求人は、ぼかしているのか把握していないのか、それだけでは分かりません。

ただし、バージョンが書いてあれば安心とも限りません。たとえば「PHP 7.4」と明記された求人は、塩漬けを正直に出している点でむしろ誠実です。応募するかどうかは、その後の質問で決めればよいと考えています。

業務内容の「保守・改修」の比重

業務内容が「既存サービスの保守・改修」だけで、アップグレードや基盤整備、テスト整備に触れていない求人は、更新が仕事として認識されていない可能性があります。逆に「バージョンアップ対応」「負債の返済」「CI導入」が仕事に含まれている求人は、組織が意識している証拠です。

歓迎スキルの並び方

歓迎スキルに「テストコード」「CI/CD」「Docker」「静的解析」が並んでいる会社は、開発環境を整える側にいます。歓迎スキルが「PHP実務経験」「MySQL」だけのときは、特別な整備はなさそうだと読みます。

ただ、求人票だけでは断定できません。求人票は塩漬け度の「手がかり」であって、判定は面談でするものだと考えてください。

カジュアル面談・面接で聞く質問

ここが一番効く部分です。逆質問の一般論はIT転職の面接で使える逆質問に任せ、ここではPHPの塩漬け度に特化した質問に絞ります。

質問の中身より大切なのは、答え方です。

バージョンを即答できて、「次はこう上げる予定です」と具体的に語れる会社は、更新を運用に組み込んでいます。反対に「えっと、最近は上げていないですね」「詳しい者に確認します」が続くとき、更新は誰の仕事でもないのだと私は受け取っています。

質問は詰問にならないよう、「入社後に私が関わる可能性があるので教えてください」と添えると、答えやすくなります。また、カジュアル面談の段階で聞くほうが、面接で聞くより正直な答えが返りやすいです。面談の場の使い方は、カジュアル面談の評価はどこまで合否に影響するかも参考にしてください。

外形的な指標として、カンファレンスへのスポンサー出稿や登壇実績を見る方法もあります。詳しくはカンファレンスのスポンサーページで技術文化を見極める方法で書いています。

相談事例：本番が「PHP 7.4.33」のまま1年以上動いていた職場

冒頭の場面の続きです。Tさん（34歳・経験10年）は、受託のWeb制作会社で数年、案件ごとに技術を変えながら開発してきた方でした。「自社のプロダクトを長く育てたい」と考え、会員向けの通販サイトを運営する中堅の事業会社（社員70名規模）に、自社開発のバックエンドエンジニアとして転職しました。

面談では「使っているのはPHPとフレームワークです」と聞いていましたが、バージョンまでは聞いていませんでした。入社して分かったのは、本番のPHPが7.4.33で、フレームワークも古い版のまま、テストはほぼなく、依存ライブラリの一部は更新が止まっているという状況でした。

Tさんは最初の3か月で、何が壊れるかを洗い出し、段階的にPHP 8系へ上げる計画を資料にまとめて上司に出しました。ところが返ってきたのは「必要なのは分かるが、今期は新機能のリリースが優先」という答えでした。次の期の計画会議でも同じ扱いでした。

その後、Tさんは打ち手を変えます。アップグレード全体ではなく、まずテストを整備する小さな提案に絞りました。決済まわりの主要な動線だけ、自動テストを書き始める。これは「障害を減らす」という名目で、承認が下りました。

結末は、きれいな成功ではありません。PHPのアップグレード自体は、Tさんが在籍した14か月の間に着手されませんでした。ただ、テスト整備の実績と、アップグレードの工数見積もり・段階計画をTさんは職務経歴書に書けるようになり、次の転職で「更新を仕組みにする会社に入りたい」と面談で質問を重ね、本番が新しい版で動いている会社から内定を得ました。年収はほぼ横ばいでしたが、本人は「環境が変わったことが一番大きい」と話していました。

私がこの話で伝えたいのは、入社後に動くことは無駄ではないが、会社を変える保証にはならないという点です。

在籍中に積める資産：アップグレードそのものより「進め方」を残す

すでに塩漬けの会社にいる場合、辞める前に積める資産があります。PHPが上がるかどうかは自分の力では決められませんが、職務経歴書に書ける材料は自分で作れます。

ポイントは、成果が「PHPを8.3に上げました」でなくても構わないことです。上げられなかった場合でも、計画・見積もり・テスト整備・影響調査の実績は、次の面接で「更新を主体的に進められる人」の根拠になります。

私はこれを、COBOL・VB6からモダン言語へ転向する年数の記事や、jQuery中心の保守からモダンフロントエンドへ移る記事でも似た形で書いてきました。古い技術の現場にいること自体は不利ではなく、そこで何を主体的に変えようとしたかが評価を分けます。

保守業務の実績を転職先に伝わる言葉に直す方法は、SES・保守5年の経験を自社開発向けに書き換える方法に整理しています。職務経歴書の書き方に迷ったら、あわせて確認してください。

見切りをつけるタイミングの目安

塩漬けの会社に入ってしまったとき、すぐ辞める必要はありません。ただ、いつまでも残るのも違います。私が相談で目安にしている基準を挙げます。

提案しても予算が付かない期間

アップグレードか、せめてテスト整備を提案して、2〜3回の計画サイクル（半年〜1年程度）回しても何も動かないなら、会社の意思決定が変わる見込みは薄いです。Tさんのように、小さな提案に切り替えて通るかを確かめるのは有効ですが、それでも動かなければ、見切りの判断材料がそろったと考えます。

EOLを過ぎた状態でセキュリティ事故や障害が起きたとき

事故が起きても更新の優先順位が上がらないなら、組織がリスクを学習していない状態です。むしろ、事故をきっかけにアップグレードが予算化されることもあります。事故後の会社の動きは、見切りの判断として分かりやすい材料です。

市場価値の観点

古いPHPに長く関わること自体は、悪いことではありません。ただ、新しいバージョンやモダンな運用を経験せずに年数だけが積み上がると、次の転職での選択肢が狭まります。年齢が上がるほど、「何を主体的に改善した人か」の説明が求められるので、動くなら早いほうが有利です。

私は、「在籍中に積む期間」の上限を1年半くらいに置いて考えるよう、相談者にはお伝えしています。もちろん個人差はありますが、期限を決めずに待つと、ずるずる3年、4年と過ぎてしまうからです。

よくある質問

PHP 7.4を使っている会社は、すべて避けるべきですか。 一律に避ける必要はありません。大事なのは、塩漬けを自覚していて、上げる計画や体制があるかです。「7.4だが今期に8.3へ段階移行する」と具体的に語れる会社は、むしろ入社後に主体的に関われる余地が大きい場合もあります。

フレームワークがLaravelなら、モダンだと考えてよいですか。 言い切れません。Laravel自体は活発に更新されていますが、古い版のまま止まっている会社もあります。たとえばLaravel 10のセキュリティ修正は2025年2月に期限を迎えています。フレームワーク名ではなく、バージョンと更新履歴を面談で確認してください。

カジュアル面談でバージョンを聞くのは失礼になりませんか。 失礼にはなりません。技術基盤を把握しようとする姿勢として、むしろ好意的に受け取られることが多いです。「入社後に関わる範囲を理解したいので」と理由を添えるのが無難です。

古いPHPの経験しかない場合、転職で不利になりますか。 PHP 7系の経験があること自体は不利ではありません。不利になりやすいのは、更新や改善に関与した形跡が書類から読み取れないケースです。前項の「在籍中に積める資産」にあるような、棚卸しや計画、テスト整備の実績を書いておくと、印象が変わります。

今の会社で提案が通らないとき、何か月待つべきですか。 一律の答えはありませんが、私は半年〜1年の間に、提案の規模を変えて2〜3回試すことを勧めています。それで動かなければ、見切りの目安と考えてよいでしょう。

まとめ

PHPがEOLのまま放置される会社は、自社開発であっても存在します。そして問題の本質は、バージョンの数字そのものではなく、更新を止めている組織の構造があるかどうかです。

見極めの手順を整理すると、求人票でバージョンの記載・業務内容・歓迎スキルから手がかりを取り、カジュアル面談で本番バージョン・直近のアップグレード実績・テストとCIの有無を聞き、答え方で更新が運用に組み込まれているかを判断する、という流れになります。

入社後に塩漬けと分かったら、すぐ辞めるのではなく、棚卸し・計画・テスト整備のような、職務経歴書に残る資産を積みながら、半年〜1年で動くかを見ます。動かなければ、そこで見切りをつける。この順番が、無駄に消耗せず、かつ次の選択肢を狭めない進め方だというのが、この記事で一番伝えたかったことです。

なお、本記事のPHP・フレームワークのサポート期限は2026年10月1日時点のものです。予定を含む日付は変わる可能性があるため、応募前にPHP公式の最新の表で確認してください。