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

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

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

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

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

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

案件を探す段階では、文面に「新規」「刷新」といった言葉があっても、中身を読んで既存システムの一部を置き換える作業と分かったときは、対象のシステムがいつから稼働しているのか、どの範囲を直すのかを早い段階で確認します。参画後のずれを防げます。

次は、この「直す案件」で仕様がどのような形で渡されるのかです。

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

2. 文書で渡される仕様

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

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

文書が中心になる理由の一つに、システムを利用する側の企業が何を重視しているかがあります。ユーザー企業は品質を最優先事項として捉えていると報告されており¹、変更内容や確認結果を書面に残すことが、品質を保つための土台になっているためです。

この進み方は、新規開発を中心に経験してきた開発者にとって窮屈に見えるかもしれません。文書を丁寧に読み解き、変更理由を言葉で残せることが、この領域で役に立ちます。

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

次は、文書があっても影響範囲まで整理されているとは限らない、という前提です。

新規開発と改修案件の仕様の渡り方の違い

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

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

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

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

設計を意識して整理する企業の少なさ

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

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

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

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

次は、書かずに済ませる選択肢が増えている状況です。

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

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

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

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

4. 書かずに済ませる選択の広がり

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

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

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

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

案件情報を読むときには、依頼内容がシステム全体の作り直しなのか、それとも既存の仕組みに残る複雑な部分だけを担当するのかを見分けることが手がかりになります。後者なら、複雑な部分を任される案件として読みます。

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

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

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

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

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

この構図の中では、意思決定を担う責任者の有無が作業の進みやすさを左右します。意思決定を担う責任者を設置していない企業が約半数に上るという報告もあり¹、社内の担当者だけでは判断できない場面が出てきます。

案件を受ける前には、社内担当者との役割分担がどうなっているか、判断が必要になったときに誰が窓口になるかを尋ねます。

では、意思決定の担当者がいない現場で、具体的に何が起きるのでしょうか。

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

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

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

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

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

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

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

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

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

最後に、案件を受ける前に確かめる順番を整理します。

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

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

PHPの案件を受ける前に確かめる観点は、4つに整理できます。1つ目は、仕様書や設計書がどの程度残っているかです。要件定義と設計はドキュメントを中心に行われていると報告されていますが¹、手元の案件で仕様書や設計書がどの程度残っているかは、案件ごとに尋ねて確かめます。

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

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

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

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

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

8. よくある質問

利用する側の企業は、システムの何を最も優先していますか

ユーザー企業は品質を最優先事項として捉えていると報告されています¹。

ノーコードやローコードは、どの程度の企業が取り入れていますか

一部利用を含めると、全体の約4割の企業が取り入れていると報告されています¹。

システム開発の契約で、企業が課題に挙げる点は何ですか

取引ごとに手間や工数がかかる点を課題として挙げる企業が多いと報告されています¹。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年10月確認）