PHPの案件情報をながめていると、新しい技術のニュースばかりが目につき、実際の案件情報の中身は見えにくいものです。案件を探す中で多く見つかるのは、ゼロから設計する仕事ではなく、すでに稼働しているシステムに手を入れる案件です。担当する現場の姿を先に知っておくと、参画してからの想定違いを減らせます。この記事では、IPAの調査¹をもとに、PHPの案件が集まりやすい現場の特徴と、受ける前に確かめておきたい順番を整理します。

1. 新しく作るより直す案件が多い理由

レガシーシステムを抱える企業がまだ多い現場

PHPの案件を探していると、真新しい仕組みを一から組み立てる仕事を想像しがちです。ところが実際に多く出ているのは、すでに動いているシステムに手を入れる案件です。まず押さえておきたいのは、利用する側の企業の半数程度が、いまもレガシーシステムを抱えているという調査結果です¹。長く使われてきたシステムほど、直しながら使い続ける前提で運用されています。

開発の進め方についても、同じ傾向が見られます。依然としてウォーターフォール型の手法が主流だと報告されており²、企画・要件定義・設計・実装・確認という順番を段階ごとに区切って進める現場が多いということです。新しい技術を試しながら小さく作り替えていくやり方より、決められた手順を踏んで一つずつ直していくやり方のほうが、PHPの案件では出会いやすくなります。

この2つを合わせて見ると、PHPの案件で求められる力の中心が見えてきます。真新しい発想を形にする力よりも、すでにある仕組みを壊さずに読み解き、決められた手順の中で正確に直していく力です。新規開発の経験しかない開発者にとっては、最初は物足りなく感じる場面もあるかもしれません。むしろ、既存のコードと向き合ってきた経験のほうが、この領域では活きてきます。

案件を探す段階では、募集の文面に「新規」「刷新」といった言葉があっても、中身を読むと既存システムの一部を置き換える作業だったということも珍しくありません。案件情報だけで判断せず、対象になっているシステムがいつから稼働しているのか、どの範囲を直すのかを早い段階で確認しておくと、参画後のずれを防ぎやすくなります。

次の章では、この「直す案件」で仕様がどのような形で渡されるのかを見ていきます。新規開発とは違う進み方を知っておくと、案件情報を読むときの見え方が変わってきます。

図の作成：Remogu編集部。案件の傾向を整理したもので、統計データではありません

2. 仕様は文書で渡される

要件定義と設計はドキュメントが中心

改修案件で最初に向き合うのは、コードそのものではなく文書です。IPAの調査では、要件定義と設計はいまもドキュメントを中心に行われていると報告されています³。口頭でのやり取りだけで進む案件は少なく、仕様書や設計書、変更依頼書といった形で情報が渡されるのが基本の流れになります。

文書が中心になる理由の一つに、システムを利用する側の企業が何を重視しているかがあります。ユーザー企業は品質を最優先事項として捉えていると報告されており⁷、変更内容や確認結果を書面に残すことが、品質を保つための土台になっているためです。口頭の申し送りだけで済ませる現場は、PHPの改修案件では多くありません。

この進み方は、新規開発を中心に経験してきた開発者にとって窮屈に見えるかもしれません。むしろ、文書を丁寧に読み解き、変更理由を言葉で残せる開発者のほうが、この領域では信頼を得やすくなります。仕様が口頭で流れていく現場よりも、文書として積み重なっていく現場のほうが、後から振り返りやすいという利点もあります。

案件を受ける前には、仕様書や設計書がどの程度残っているか、変更の経緯を記録する場所が用意されているかを尋ねておくと安心です。文書が薄い現場では、口頭で聞いた内容を自分でも書面に残しておくと、後々の確認がしやすくなります。

仕様が文書で渡される流れが分かったところで、次はその文書が実際の作業でどこまで役立つのかを見ていきます。文書があっても、影響範囲まで整理されているとは限らないという前提が、次の章のテーマです。

新規開発と改修案件で仕様の渡り方はどう違うか

新規開発の案件と改修案件を並べると、仕様の渡り方の違いがはっきりします。次の表は、どちらの案件でも起点になるものと、求められる進め方の違いを整理したものです。案件情報を読むときに、自分がどちらの流れに入るのかを見分ける手がかりにしてください。

観点	新規開発の案件	既存システムの改修案件
仕様の出発点	企画段階から一緒に組み立てる	既存の文書と現状のコードが起点になる
要件定義の進め方	ヒアリングを重ねながらゼロから固める	既存のドキュメントを読み解く作業から始まる
求められる記録の形	提案書や設計書を新たに作成する	変更内容と理由を既存の文書に反映して残す
評価されやすい点	新しい仕組みを組み立てる発想力	既存の仕組みを壊さずに直す慎重さ

図の作成：Remogu編集部。案件で仕様が渡される流れを整理したもので、すべての案件に当てはまるものではありません

3. 影響範囲が整理されていない前提

設計を意識して整理している企業はまだ少ない

仕様が文書で渡されるとしても、その文書が影響範囲まで整理しているとは限りません。モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側の企業を中心に依然として少ないと報告されています⁴。つまり、どこを直すと他のどこに響くのかが、文書の中で体系的に整理されていない現場のほうが普通だということです。

技術情報の集め方にも同じ傾向が見られます。技術情報の収集は体系的な仕組みを持たないと報告されており⁸、部門としてノウハウを蓄積する仕組みよりも、担当してきた個人の経験に頼る場面が多くなります。担当者が変わると、影響範囲の把握が振り出しに戻ることも珍しくありません。

この前提を知らずに案件に入ると、依頼された一箇所だけを直したつもりが、別の画面や別の処理に影響していたということが起こります。反対に、この前提を先に理解していれば、変更前に影響範囲を尋ねる、テストの範囲を広めに取るといった動き方ができるようになります。整理されていない現場だからこそ、確認する手間を惜しまない姿勢が評価されます。

案件を受ける段階では、変更を依頼する側がどこまで影響範囲を把握しているかを尋ねてみることが手がかりになります。担当者が明確に答えられない場合は、自分で影響範囲を洗い出す時間を見積もりに含めておくと、後から慌てずに済みます。

整理されていない前提を踏まえたうえで、次の章では、書かずに済ませる選択肢が増えている状況を見ていきます。設計の整理と合わせて知っておくと、案件全体の見え方がつながってきます。

整理されている現場と整理されていない前提の現場の違い

影響範囲がどこまで整理されているかによって、作業の進め方は大きく変わります。次の表は、設計の記録が整っている現場と、整理されていない前提で作業を進める現場とで、確認の仕方や依頼内容の伝わり方がどう違うかをまとめたものです。

観点	整理されている現場	整理されていない前提の現場
設計の記録	モジュールやデータの関係が図や文書に残っている	記録が薄く、コードを読んで確認する必要がある
変更時の確認範囲	影響先を仕様書で追える	影響先を推測しながら探ることになる
技術情報の集め方	部門として仕組みを持っている	個人の経験に頼る場面が多い
依頼内容の伝わり方	変更点と理由がセットで渡される	直したい症状だけが渡ることがある

図の作成：Remogu編集部。企業の割合の差を模式化したもので、統計データではありません

4. 書かずに済ませる選択も増えている

ノーコードやローコードを取り入れる企業

すべての作業がコードを書く形で進むわけではありません。一部利用を含めると、全体の約4割の企業がノーコードやローコードの手法を取り入れていると報告されています⁵。簡易な画面や定型の処理であれば、コードを書かずに組み立てる選択肢が広がってきているということです。

この流れは、PHPの案件が減ることを意味するわけではありません。ノーコードやローコードで対応できる範囲が広がる一方で、それらの仕組みでは対応しきれない部分、つまり既存システムとの連携や、細かい業務ルールの実装は、引き続きコードを書ける開発者に委ねられます。書かずに済む範囲と、書く必要がある範囲の線引きを見極める視点が求められます。

約半数のユーザー企業がシステム開発の内製化を進めているという報告もあります⁶。内製化を進める企業では、簡易な部分を社内でノーコードのツールを使って作り、複雑な部分やレガシーシステムとの接続部分を外部の開発者に依頼する、という役割分担が生まれやすくなります。

案件情報を読むときには、依頼内容がシステム全体の作り直しなのか、それとも既存の仕組みに残る複雑な部分だけを担当するのかを見分けることが手がかりになります。後者であれば、ノーコードやローコードでは対応しきれなかった部分を任される案件である可能性が高くなります。

書かずに済ませる選択が広がる中で、PHPの開発者に残る役割は、複雑さが集まる部分を引き受けることに近づいています。次の章では、この役割分担が内製化の途中にある企業でどう現れるかを見ていきます。

この役割分担を理解しておくと、案件を選ぶときに「なぜ外部に依頼しているのか」という理由が見えるようになります。理由が見える案件ほど、参画後に任される範囲もつかみやすくなります。

5. 内製化の途中に入るという構図

内製化の途中で外部に委託される内容

約半数のユーザー企業がシステム開発の内製化を進めているという報告を踏まえると⁶、PHPの案件の多くは、内製化が完了した後ではなく、内製化の途中にある企業から出ていると考えられます。社内に開発の担当者がいながらも、すべてを社内だけで完結させているわけではない、という状態です。

この状態では、外部の開発者に委託される内容も、内製化が進んでいない企業とは違ってきます。社内の担当者が対応できる範囲を担当し、レガシーシステムとの接続や、リスクの高い変更部分を外部に委託する、という分担になりやすくなります。社内の担当者と並走しながら作業を進める場面が増えるということです。

この構図の中では、意思決定を担う責任者の有無が作業の進みやすさを左右します。意思決定を担う責任者を設置していない企業が約半数に上るという報告もあり⁹、社内の担当者だけでは判断できない場面が発生しやすくなります。誰に確認すれば話が進むのかが分かりにくいことも、内製化の途中にある現場ではよく起こります。

案件を受ける前には、社内担当者との役割分担がどうなっているか、判断が必要になったときに誰が窓口になるかを尋ねておくと、作業を始めてからのやり取りがスムーズになります。窓口が明確な案件ほど、依頼内容の変更や確認事項への回答も早く戻ってくる傾向があります。

次の章では、この意思決定の担当者がいない現場で具体的に何が起きるのかを、もう少し詳しく見ていきます。

内製化の段階ごとに変わる委託の中身

内製化がどの段階にあるかによって、外部に委託される作業の中身と、契約や進め方の特徴は変わります。次の表は、内製化に着手する前と、内製化が途中にある企業とで、依頼される内容がどう違うかを整理したものです。

段階	外部への委託の内容	契約や進め方の特徴
内製化に着手する前	開発の大部分を外部に委託する	要件から成果物まで一括で依頼される
内製化の途中にある段階	一部の機能や領域だけを外部に委託する	社内の担当と役割を分けて並走する
意思決定の担当者がいる場合	依頼内容の優先順位が明確になりやすい	判断のスピードが保たれやすい
意思決定の担当者が定まらない場合	依頼内容の優先順位が揺れやすい	判断を待つ時間が生まれやすい

6. 決める人がいない現場で起きること

責任者が定まらないまま契約が続く

意思決定を担う責任者を設置していない企業が約半数に上るという報告は⁹、PHPの案件を受ける開発者にとって見過ごせない情報です。担当者レベルでのやり取りは進んでも、優先順位や予算に関わる判断だけが止まってしまう場面が起こりやすくなるためです。

もう一つの要因として、取引ごとに手間や工数がかかる点を課題として挙げる企業が多いという報告があります¹⁰。契約や発注の手続きそのものに時間がかかると、変更の依頼から実際の着手までの間隔が延びやすくなります。決める人がいないことと、手続きに手間がかかることは、別々の要因でありながら、現場では重なって表れることがあります。

こうした現場では、依頼内容が途中で変わる、確認の返答が遅れる、といったことが起こりやすくなります。開発者側でできる備えとしては、変更依頼を受けた時点で確認事項をまとめて一度に尋ねる、判断が必要な点は早めに共有しておく、といった進め方があります。相手の判断を待つ時間を見込んで、作業の順番を組み立てておくと落ち着いて対応できます。

案件を受ける段階では、契約や発注の手続きにどの程度の時間がかかる企業かを尋ねてみることも手がかりになります。手続きに時間がかかる企業ほど、スケジュールに余白を持たせておく必要が出てきます。

ここまで見てきた特徴を踏まえて、最後の章では、案件を受ける前に確かめておきたい順番を整理します。

7. 受ける前に確かめる順番

4つの観点を順番に確認する

ここまでの内容を踏まえると、PHPの案件を受ける前に確認しておきたい観点が4つに整理できます。1つ目は、仕様書や設計書がどの程度残っているかです。要件定義と設計はドキュメントを中心に行われていると報告されている一方で³、文書の量や更新頻度は企業によって差があります。

2つ目は、影響範囲がどこまで整理されているかです。モジュール性やデータモデルを意識した設計に取り組む企業は依然として少ないという前提を踏まえると⁴、影響範囲を尋ねても明確な答えが返ってこない場合があります。その場合は、自分で確認する時間を見積もりに含めておくことが必要になります。

3つ目は、内製化の状況と社内担当者との役割分担です。社内の担当者がどこまで対応し、どこから外部に委託されるのかを知っておくと、任される作業の範囲がつかみやすくなります。4つ目は、意思決定の窓口です。判断が必要になったときに誰に確認すればよいかが分かっている案件ほど、作業がスムーズに進みます。

この4つの観点は、面談の場で一度にすべて尋ねる必要はありません。案件情報を読む段階、面談の場、参画してからの最初の数週間と、確認するタイミングを分けて進めることもできます。大切なのは、確認せずに進めないことよりも、確認する順番を自分の中で持っておくことです。

PHPの案件は、新しい技術を追いかける案件ではなく、すでにある仕組みと向き合う案件です。既存のコードや文書を読み解く経験があるなら、その経験がそのまま案件選びの軸になります。まずは自分の経験に近い案件がどのような形で出ているのかを見てみることから始めてみましょう。

図の作成：Remogu編集部。確認しておきたい順番を整理したもので、案件ごとに順序が変わることがあります

改修案件では既存のコードを読み解く力が重視されますか

重視される場面は多くあります。既存のコードを短時間で把握し、どこにどんな処理があるかを見つけ出す力は、新しく設計する力とは別の種類の経験です。新規開発の経験が少なくても、既存システムの保守や改修に携わってきた経験があれば、その経験がそのまま強みになります。

仕様書が無い案件では何を確認しておくと安心でしょうか

仕様書が無い、あるいは古いままになっている案件では、現状のコードとデータベースの構成を最初に確認できるかどうかを尋ねてみてください。加えて、直したい症状や変更の目的を、担当者から言葉で聞き取れる機会があるかも確認しておくと、作業を始めてからの手戻りを減らせます。

内製化を進めている企業の案件は、社内とのやり取りが増えますか

社内の担当者と並走する場面は増えやすくなります。ただし、それは負担というより、社内の状況を教えてもらいながら進められるという利点にもなります。役割分担が明確な企業であれば、社内担当者との連携もスムーズに進みます。まずは自分の経験に合う案件がどのような形であるのかを、実際に見てみることから始めてみましょう。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」書かない選択（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」内製化の広がり（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年8月確認）