PHPエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのPHPエンジニアがつまずきやすいのは、「改修」という言葉の範囲があいまいなまま動くこと、請負のWeb制作で修正の回数に際限がなくなること、テストのない既存コードをどう扱うかの判断、セキュリティと性能の見落とし、障害対応で稼働が膨らむことです。PHPは新しく作る仕事と動いているものを直す仕事が混ざっているため、「どこまでが自分の仕事か」が見えにくいことから、多くのつまずきが起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、PHPエンジニアならではの場面と対策を整理します。契約の形の基本はPHPエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「改修」の範囲が、ついでの作業で広がる

契約書には「既存システムの改修」とだけ書かれ、現場では「ついでにPHPの版も上げてほしい」「古いライブラリも置き換えてほしい」と期待されていた、という食い違いはよく起きます。PHPの改修は、直そうとすると周りのコードも直したくなる場面が多く、引き受けた範囲が少しずつ広がりやすいのが特徴です。

対策：参画前に、担う作業（機能の改修、不具合の修正、テストの追加など）と、担わない作業（版の更新、インフラの変更、デザインの修正など）を言葉で確かめておきます。版の更新は作業量が読みにくいため、改修とは分けて扱うのが安全です。範囲の外の依頼が来たときの扱いは作業範囲が広がったときの記事をご覧ください。

請負のWeb制作で修正が終わらない

企業サイトやECサイトを請負で作る案件では、納品後に「ここも直してほしい」が続き、報酬に見合わなくなることがあります。制作の仕事は見た目の好みが入りやすく、「修正」と「追加の依頼」の線が引きにくい分野です。

対策：見積もりの段階で、作るもの、作らないもの、修正の回数と期限、検収の方法を書面やメールで残します。見積もりの作り方は見積書の作り方、報酬が確定する仕組みは検収の記事で解説しています。

請負で負う責任の範囲を読んでいない

請負では、納めたものが契約の内容に合わない場合、修正などを求められることがあります。契約書に、不具合が見つかったときの対応の期間や範囲が広く書かれていると、納品後も長く負担が続くことがあります。

対策：契約書の責任に関する条項を、署名の前に読みます。気になる文言は、エージェントや発注側に確かめてください。判断に迷う場合は弁護士などの専門家に相談するのが安全です。準委任と請負の違いは準委任契約と請負契約の違い、請負の責任は契約不適合責任の記事をご覧ください。

指揮命令の形が社員と変わらなくなる

発注側の社員リーダーの下で、作業の順番や時間まで細かく指示されるようになると、準委任の契約と実態がずれてきます。少人数の自社サービスの現場に長く入るほど、この状態に気づきにくくなります。考え方は偽装請負の記事で解説しています。

現場でのつまずき

既存のコードを否定してしまう

参画してすぐに「このコードはひどい」「作り直したほうが早い」と口にすると、そのコードを書いてきた社員との関係が悪くなります。古い書き方のコードは、当時の制約の中で動かしてきた結果であることがほとんどです。

対策：最初は現場のコードの書き方に合わせ、困っている点が見えてから、一つずつ提案します。変えるときは、何が良くなるのかと、どこまで変えるのかを先に説明します。参画初月の進め方はPHPエンジニアの参画初月にやることで整理しています。

テストのないコードを一気に書き換える

良かれと思って大きく書き換えた結果、動いていた機能が壊れ、原因の切り分けに時間がかかることがあります。PHPの古いコードは、仕様がコードにしか残っていないことが多く、書き換えで仕様そのものを失うこともあります。

対策：変える前に、今の動きを固定するテストを書きます。テストが書きにくいコードなら、まず入出力を記録して比べる形でも構いません。変更は小さく区切り、一つずつレビューを通します。

本番で直接直してしまう

小さな修正を本番サーバーで直接行い、リポジトリと本番のコードがずれる、という事故は、古い現場で起きやすい事故です。緊急の対応を頼まれたときに、断りにくくて手を出してしまう場面もあります。

対策：本番に直接手を入れない決まりを、参画の初期に発注側と確かめます。やむを得ず直した場合は、その日のうちにリポジトリに反映し、記録を残します。

仕様が業務担当者の頭の中にしかない

業務システムやECの改修では、「この条件のときはこう計算する」という決まりが、コードにも資料にもなく、業務の担当者だけが知っている、という場面がよくあります。聞かずに実装すると、後から「そうではない」と差し戻されます。

対策：仕様を決めるときは、業務の担当者に例を出して確かめます。確かめた内容は、チケットや議事録に残し、後から参照できるようにします。

技術でのつまずき

Laravelを「動かせる」止まりで入ってしまう

Laravelの案件に、ルーティングとEloquentが使える程度で入ると、キュー、認可、イベント、テストといった仕組みを前提にしたコードを読み解けず、見積もりが大きくずれます。「Laravel経験あり」の中身を、自分でも発注側でも軽く見てしまうことから起きます。

対策：面談の段階で、どの機能をどう使った経験があるかを正直に話し、参画後は現場のコードの構成を最初の週に読み切ります。求められる中身はPHPの案件で求められるスキルで整理しています。

遅いSQLとN+1を見落とす

Eloquentは書きやすい反面、一覧画面で関連するデータを読むたびにSQLが発行され、データが増えてから遅くなることがあります。開発環境のデータが少ないと気づけず、本番で問題になってから指摘を受けることがあります。

対策：一覧や集計の処理では、発行されるSQLの数と実行計画を確かめる習慣を持ちます。データ量が本番に近い環境で確かめられるかを、参画の初期に聞いておきます。

セキュリティをフレームワーク任せにする

Laravelには多くの対策が組み込まれていますが、古いコードや独自の仕組みではそれが効いていないことがあります。生のSQLを文字列でつなぐ、テンプレートのエスケープを外す、ファイルのアップロードの中身を確かめない、といった書き方が残っていても、「フレームワークが守ってくれる」と思い込むと見落とします。

対策：入力の検証、出力のエスケープ、認可の判定、アップロードの扱いの4点は、既存のコードを触るたびに確かめます。脆弱性診断の指摘を受けたときは、その修正を自分の経験として記録しておきます。

サポートの終わった版で改修を続ける

PHP公式サイトのサポート方針では、各版に公開から2年間の通常サポートと、その後2年間のセキュリティ修正のみの期間があり、2026年10月時点で8.2のセキュリティサポートは2026年12月31日までとされています。サポートの終わった版で動くシステムの改修を引き受けると、セキュリティの修正が出ない状態で作業を続けることになります。

対策：参画前に、版を上げる計画があるのか、当面はそのまま使う方針なのかを確かめます。上げる作業を頼まれていないのに、改修のついでに大きく直すのは、範囲の食い違いにつながります。

お金でのつまずき

障害対応やリリース前後の稼働超過が精算されない

ECサイトのセール前後、業務システムの月末処理、本番の障害対応では稼働が延びやすく、精算幅を大きく超えることがあります。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事、休日や深夜の作業の扱いは休日・深夜に作業したときの報酬で解説しています。

請負の検収が遅れて報酬が確定しない

Web制作の請負では、納品しても発注側の確認が進まず、検収が遅れて報酬の支払いも遅れることがあります。修正の往復が続くと、いつ確定するのかが見えなくなります。

対策：検収の方法と期限を契約や見積もりに書いておきます。フリーランス法では、発注側は報酬の支払期日を、成果物を受け取った日から60日以内のできる限り短い期間で定めることになっています（2026年10月時点、公正取引委員会の案内による）。支払いが遅れたときの対応は報酬が支払われないときの対処をご覧ください。

小さな制作案件を抱えすぎて時間が足りなくなる

知人からの紹介で小さなサイトの制作や保守を複数抱えると、一つひとつは小さくても、連絡と修正に時間を取られ、月単位の案件に影響することがあります。

対策：請け負う件数と、月に使える時間の上限を決めておきます。掛け持ちの考え方は複数の案件を掛け持ちするときの注意点で整理しています。

開発の節目で契約が終わり、次の案件探しが遅れる

大きな機能のリリースや版の更新の完了で、契約が更新されないことがあります。フリーランス法では、6か月以上続く業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。それでも、終わってから探し始めると空白が長くなります。

対策：契約期間と開発の節目を並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

よくある質問

参画してから、聞いていた仕事と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、範囲外の作業が当たり前になり、後から戻しにくくなります。

納品したサイトに不具合が見つかったら、無償で直す義務がありますか？

請負では、納めたものが契約の内容に合わない場合、修正などを求められることがあります。ただし、どこまでが契約の内容で、どこからが追加の依頼かは、契約と見積もりの書き方で変わります。契約書の責任の条項を読み、判断に迷う場合は弁護士などの専門家にご相談ください。

既存のコードの品質が低く、見積もりどおりに進みません。どう伝えればよいですか？

遅れの原因を「コードが悪い」ではなく、「テストがないため動作の確認に時間がかかる」「仕様が資料にないため確認の往復が多い」のように、事実として伝えます。あわせて、テストを足す、仕様を確かめる場を設けるといった手を提案し、見積もりの見直しを窓口と相談してください。