「PHPで構築された基幹システムの保守」——引き取り先の案件情報に並ぶのは、たいていこの一行だけです。中に入ってみるまで、何がどれだけ依存していて、どこのサポートが切れているのかは分かりません。古いPHPの案件そのものは珍しい話ではなく、むしろよくある入り口です。問題になるのは良し悪しではなく、引き取る前にその内側が見えているかどうかという一点です。

1. 古いPHPの案件はなぜ多いのか

「枯れた技術だから」余っているわけではない

古いPHPの案件が目につくのは偶然ではありません。IPAの調査では、利用する側の企業の半数程度が、いまもレガシーシステムを抱えていることが分かっています¹。基幹の業務を支えるシステムほど、動いている間は置き換えの優先順位が上がりにくく、長く稼働し続けます。

一方で、開発を担う側だけでなく、利用する側の企業でも内製化の動きが進んでいます。約半数の企業がシステム開発の内製化を進めており、人材の確保と新しい技術への対応が課題になっています²。社内の担当者だけでは手が回りきらず、外部に開かれる場面が増えています。

引き取る側から見ると、これは技術が古いから案件が余っているという単純な話ではありません。長く動いてきたシステムには、現場の判断や取引先との調整が積み重なっています。動かし続けてきた実績そのものが、引き取る側に評価される値になります。

スキルの新しさよりも、動いているものを壊さずに引き継げる姿勢のほうが、この領域では評価されやすくなります。求められるのは、枯れた技術への抵抗感ではなく、中身を確かめる姿勢です。

面談の場で聞かれることも変わってきます。単に「PHPの経験年数」を問われるだけでなく、これまでどんな改修を任され、どこまでの範囲を一人で見てきたかという、任された裁量の広さを尋ねられる場面が増えます。

自分の経験を振り返るときも、書いたコードの量よりも、既存の仕組みを壊さずに機能を足した経験のほうが、この領域では語れる材料になります。

ただし、珍しくないという事実は、中身がそろって見えることを意味しません。案件情報の一行の裏側には、把握されていない依存関係が隠れている場合があります。

ここまでの背景を知っているかどうかで、案件情報を読む目も変わってきます。「PHPの保守」という一行を見たときに、その奥にどんな状態が広がっているかを先に想像できるようになります。

次に確かめたいのは、その依存関係とOSSの方針が、引き取る前にどこまで見えているかという点です。

2. 引き取る前に見えていないもの——依存と方針

案件情報の一行の内側にあるもの

案件情報に書かれる範囲は、たいてい「保守」「改修」といった業務の名前までです。その内側にどんな依存関係があり、OSSの利用方針がどう定められているかは、書かれていないことがほとんどです。

IPAの調査によると、OSSの利用方針やOSPO(OSSプログラムオフィス)の整備は、いまも途上にあります⁶。方針が定まっていないということは、何を使ってよいか、誰が判断するのかが、現場の慣習に委ねられているということでもあります。

SBOM(ソフトウェア部品表)のような、依存関係を一覧で管理する仕組みの導入も限定的です⁷。一覧が無いと、あるライブラリの対応が必要になったとき、それがどこで使われているかを探すところから始めることになります。

確認できるかどうかで引き取り方が変わります

表にまとめたのは、案件情報だけでは見えにくい2つの観点です。OSSの利用方針とSBOMなどの管理体制は、どちらも「整っている前提」で引き取ると、後になって着手の重さに直結します。面談の段階で確認できるかどうかで、案件の性格はかなり変わります。

確認する観点	現場でよくある状態	引き取る前に確認したいこと
OSSの利用方針	方針やOSPOが整っていない場合があります6	方針が明文化されているか、誰が判断する立場にあるか
依存関係の管理	SBOMなどによる一覧管理の導入は限定的です7	依存ライブラリの一覧がどこまで整備されているか

依存の一覧が無い状態で引き取ると、脆弱性の対応が必要になるたびに、まず「どこに影響するか」を洗い出す作業から始まります。作業の速さよりも、影響範囲を確かめる粘り強さのほうが、ここでは効いてきます。

面談で確認できるとよいのは、「依存関係の一覧はありますか」という一問です。即答できる現場もあれば、確認して折り返すという現場もあり、その反応だけでも整備の度合いが見えてきます。

依存の一覧が手元に無い現場ほど、引き取った直後の数週間は、既存コードを読み解く時間の比重が大きくなります。着手前にその時間をどこまで見込んでおくかが、進め方の見通しを左右します。

読み解く時間そのものを負担と捉えるより、依存関係を洗い出す作業を自分の成果として言語化しておくほうが、次の案件を選ぶときの材料になります。何を確認し、何を整理したかは、後から振り返れる形で残しておきたいところです。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

案件情報に書かれていない部分を、面談で確認できるかどうか——この一点だけでも、引き取った後の負担の見え方は変わってきます。次に見ていくのは、その負担が実際にどう積み上がっていくかという順番の話です。

3. 「実施事項が多い」は量ではなく順番の問題

積み上がるのは対応の量ではなく判断の回数

古いPHPの案件を引き取ると、脆弱性への対応で実施事項が多岐にわたることに気づきます⁹。一つひとつは難しい作業でなくても、数が増えると、どこから手をつけるかという判断そのものが負担になっていきます。

実際、リソースに限りのある開発者にとって、どれから着手するかの判断に迷うことは、よくある課題として挙げられています¹⁰。量が多いこと自体よりも、優先順位を決める材料が無いことのほうが、着手を遅らせる原因になります。

ここで手がかりになるのが、実施事項をレベルで分けるという考え方です。基本となるレベルに位置づけられる対応が示されており¹⁵、そこを起点に順番を組み立てられます。

面談で優先順位の考え方を尋ねると、「まず動くようにする」だけの現場と、「まず基本のレベルをそろえる」現場とでは、任される作業の順番がまったく違って見えてきます。

まず基本の層から手をつける

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

全部を同時に進めようとすると、判断の回数が積み重なり、どれも中途半端になりがちです。基本の層から順に手をつけていくほうが、後から振り返ったときに説明のつく進め方になります。

引き取った直後にすべてを洗い出そうとするのではなく、まず基本の層を固め、そこから広げていく——このリズムを持っておくと、実施事項の多さに振り回されにくくなります。

自分の経験の中で、複数の対応事項を順番に整理し直した経験があるなら、それはこの現場でそのまま活きる材料になります。件数の多さに動じない姿勢のほうが、速さよりも信頼につながります。

順番の組み立て方が見えてくると、次に気になるのは「いつまで対応すればよいのか」という期限の話です。

4. サポートの期限が決まっていない現場

期限を示さないと、期待だけが膨らむ

古いPHPの案件で見落とされやすいのが、サポートの期限です。方針を示さないままだと、利用する側は長期にわたるサポートを期待することになります¹¹。示していないだけで、期待は自然と長く伸びていきます。

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

引き取る側からすると、この期待の伸び方は他人事ではありません。期限が決まっていない対応を任されると、いつまで稼働が発生するのか見通しが立たないまま、関わり続けることになりやすいからです。

期限が決まっていない案件を任されたときは、稼働の見込みを自分から確認しておくことが役に立ちます。いつまでという区切りが無いなら、どの頻度で振り返るのかだけでも決めておくと、進め方が変わってきます。

これまでの案件で、終わりの見えない対応を任された経験があるなら、その進め方を振り返っておくと、面談での説明にも使える材料になります。

期限を示すかどうかで期待の伸び方が変わります

期限を示すかどうかで、利用する側の期待の膨らみ方と、引き取る側の負担の見え方はどちらも変わります。面談の段階で、対応の期限についてどこまで言語化されているかを確かめておく価値があります。

観点	期限を示す場合	期限を示さない場合
利用する側の期待	対応の範囲と終わりが伝わります	長期にわたるサポートを期待されることになります11
引き取る側の負担	稼働の見通しを立てやすくなります	いつまで関わるか分からないまま稼働が続きやすくなります

期限がはっきりしないまま案件を進めると、対応の終わりが見えず、次の案件への切り替えのタイミングも読みにくくなります。期限の有無を後から確かめるより、先に条件として確認しておくほうが、進め方の見通しは立てやすくなります。

期限が見えていないという状態は、そのまま放置してよいものでもありません。次に見ていくのは、期限が無い状態でも対応を続けるための、監視という仕組みです。

5. 監視は一度では終わらない

出荷後も情報収集は続く

期限が明確でない対応を続けるうえで欠かせないのが、監視の仕組みです。構成管理の資料をもとに、出荷後も継続して脆弱性情報を収集することが挙げられています¹²。一度点検して終わりではなく、情報を継続して集め続けることが前提になっています。

集めた情報についても、そのまま対応に回すわけではありません。まず、その情報が実際に再現するかどうかを確認する工程が置かれています¹³。再現の確認を挟むことで、対応の的が絞られていきます。

この2段構えの流れ——情報を集め続けることと、再現を確認すること——を知っているかどうかで、引き取った案件への向き合い方は変わります。情報が来るたびに慌てて対応するより、集める仕組みと確かめる手順を先に整えておくほうが、落ち着いて進められます。

監視を一度きりの点検だと捉えていると、対応は後手に回りやすくなります。継続する前提で仕組みを組んでおけば、実施事項が増えても、どこかで手が止まることは避けやすくなります。

情報を集める仕組みと、再現を確認する手順が既にある現場なら、引き取った直後から落ち着いて対応に入れます。逆に、その仕組みが無い現場では、まず仕組みを整えるところから任される場合もあります。

どちらの現場であっても、情報を継続して集め続ける前提を共有できているかどうかを、面談で確認しておく価値があります。

継続する仕組みに関わった経験は、単発の改修より語りにくく感じるかもしれません。それでも、情報を集め続ける体制のどこに関わったかを具体的に言葉にできれば、次の案件でもそのまま評価される材料になります。

情報を集め、再現を確認したあとに残るのは、どれから対応するかという優先順位の判断です。

6. 優先順位は被害の大きさと起きやすさで置く

量ではなく2つの軸で並べ替える

実施事項が多岐にわたり、監視を続ける中で情報が積み上がっていくと、次に必要になるのは並べ替える基準です。被害の大きさと発生の可能性という2つの軸からリスクを分析するという考え方が示されています¹⁴。

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

見つかった順に対応するのではなく、この2軸に沿って並べ替えると、後回しにしてよいものと、先に手をつける対応との境目がはっきりします。優先順位を先に決めておくほうが、実施事項が増えたときにも判断がぶれにくくなります。

面談で「優先順位はどう決めていますか」と尋ねてみると、被害の大きさと起きやすさという2軸で答えが返ってくる現場もあれば、明確な基準が無い現場もあります。この違いは、引き取った後の進め方に直結します。

被害の大きさと起きやすさで置き場所が決まります

被害の大きさと起きやすさを組み合わせると、対応の優先度は4つの位置づけに分かれます。すべてを同じ重みで扱うのではなく、この目安を面談や引き継ぎの場で共有できるかどうかを確認しておくと、引き取った後の進め方がぶれにくくなります。

位置づけ	被害の大きさ	起きやすさ	対応の目安
最優先	大きい	高い	先に着手する対応
次点	大きい	低い	備えを整えておく対応
早めに解消	小さい	高い	早めに片づける対応
様子を見る	小さい	低い	状況を見ながらの対応

2軸で並べ替える発想を持っているかどうかは、面談でのやり取りにも表れます。優先順位の基準について尋ねてみると、その現場が実施事項をどう捉えているかが見えてきます。

自分の経験の中で、複数の対応事項を2軸で整理し直した経験があるなら、面談でそのまま語れる材料になります。

7. 進め方と評価の軸——文書中心・品質重視の現場で

開発手法と評価の軸を知っておく

古いPHPの案件を引き取る現場は、進め方そのものにも特徴があります。開発手法はいまもウォーターフォールが主流です⁴。要件定義と設計についても、ドキュメントを中心に進められ、モデリングツールの活用はごくわずかにとどまっています⁵。

速さよりも、手順と記録が重視される現場だということです。ドキュメントを整えながら進める経験は、コードを速く書く経験よりも、こうした現場では評価につながりやすくなります。

評価の軸についても、押さえておきたい傾向があります。利用する側の企業は品質を最も重視しています³。仕様どおりに動くことに加えて、変更の影響範囲を丁寧に説明できるかどうかが、信頼につながります。

セキュリティに関するガイドラインの整備状況は、利用する側の企業では4〜5割にとどまっています⁸。整っている依頼元もあれば、そうでない依頼元もあるということです。面談の段階で、ガイドラインの有無や監視の体制について尋ねておくと、引き取った後の進め方の見通しが立てやすくなります。

これらの傾向を知っておくと、面談での受け答えも変わってきます。スピード感を強調するよりも、手順を踏んで進められることを伝えるほうが、この領域では信頼につながりやすくなります。

ここまで見てきた依存の見えにくさ、実施事項の順番、期限の曖昧さ、監視の継続、優先順位の付け方は、どれも引き取る前に確認できることばかりです。確認する材料を持っているかどうかで、案件を選ぶときの安心感は大きく変わります。

古いPHPの案件は、経験がまだ少ない状態でも引き取れますか

経験がまだ少ない状態であっても、引き取れる案件はあります。この領域で重視されるのは、コードを速く書く経験よりも、手順を丁寧に残しながら進める姿勢です。開発手法はいまもウォーターフォールが主流で⁴、要件定義や設計もドキュメントを中心に進められています⁵。経験の長さよりも、記録を残しながら着実に進められるかどうかが問われます。

文書が中心の現場では、どんな進め方が求められますか

文書を中心に進める現場では、要件定義や設計の内容がドキュメントとしてまとめられ、モデリングツールの活用は限られています⁵。開発手法もウォーターフォールが主流のため⁴、工程ごとに区切って進める形が基本になります。口頭でのやり取りよりも、書き残した内容が判断の根拠になる場面のほうが目立ちます。

品質を重視する現場では、何を評価されますか

品質を重視する現場では、動作の正しさに加えて、変更が及ぼす影響範囲を説明できるかどうかが評価されます。利用する側の企業は品質を最も重視する傾向にあり³、セキュリティのガイドライン整備は4〜5割にとどまるため⁸、依頼元によって求められる水準に差があります。面談の段階で、その現場がどこまで基準を明文化しているかを確認しておくと、評価の軸がずれにくくなります。

自分に合う古いPHPの案件は、どうやって探せますか

自分に合う古いPHPの案件を探すなら、まず案件情報を眺めるだけでなく、実際にどんな条件で募られているかを確認するところから始めてみましょう。Remoguの案件は、90%以上がフルリモートで進められます。場所に縛られず、これまで積み上げてきた経験を活かせる案件かどうかは、登録して条件を確認してみることで見えてきます。古いPHPの現場を、避ける対象ではなく選べる選択肢の一つとして、まず一度確かめてみませんか。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」前提の広さ（2025年4月）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地（2025年4月）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」進め方の前提（2025年4月）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の空白（2025年4月）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」依存の見える化（2025年4月）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」整備の差（2025年4月）
＊9 IPA「脆弱性対処に向けた製品開発者向けガイド」量の問題（2026年3月）
＊10 IPA「脆弱性対処に向けた製品開発者向けガイド」順番の問題（2026年3月）
＊11 IPA「脆弱性対処に向けた製品開発者向けガイド」期限の不在（2026年3月）
＊12 IPA「脆弱性対処に向けた製品開発者向けガイド」監視の継続（2026年3月）
＊13 IPA「脆弱性対処に向けた製品開発者向けガイド」確認の段（2026年3月）
＊14 IPA「脆弱性対処に向けた製品開発者向けガイド」優先順位の付け方（2026年3月）
＊15 IPA「脆弱性対処に向けた製品開発者向けガイド」最初の一手（2026年3月）