PHP/Laravelエンジニアを業務委託で確保する方法｜保守とECの発注設計

社内で PHP/Laravel 製のシステムを支えていたエンジニアが抜けた瞬間、状況は一気に変わります。障害の一次対応が誰にも振れない、事業部から依頼された機能追加が止まる、そして「このシステム、そもそも何がどう動いているのか説明できる人がいない」という事実が表に出てきます。正社員採用に動いても母集団はすぐには集まらず、経営層からは「外部に頼むならいくらで、何を頼むのか整理して持ってこい」と言われる。ここから業務委託の検討が始まるケースは少なくありません。

このとき多くの発注担当者がつまずくのは、知識が足りないからではありません。「発注前に何を決めておけばよいのか」という項目のリストが手元にないことが原因です。対象のバージョン範囲はどこまでか、保守と新規開発を同じ人に同じ契約で頼んでよいのか、社員と同じ朝会に入れたら偽装請負になるのか、単価 60 万円と 100 万円の違いを経営層にどう説明するのか。判断材料が揃わないまま稟議と契約に進むことになるため、決めきれないまま発注し、稼働もコストも読めなくなります。

しかも PHP/Laravel には、他の技術スタックにはない固有の事情があります。PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日に終了し、Laravel は LTS（長期サポート版）という仕組み自体をすでに持っていません。つまり「今動いているものを維持する」という依頼だけでは、数か月後に必ずバージョンアップの話が発生します。この論点を発注条件に書いておくかどうかで、後の追加費用が大きく変わります。

本記事では、PHP/Laravel エンジニアを業務委託で確保する方法を、レガシー保守案件と EC・新規開発案件に分けて整理します。発注前に決める 3 つの前提、案件性質による発注設計の違い、4 つの調達ルート、準委任と請負の選び方、フリーランス新法・取適法で増えた発注者側の義務、2026 年時点の単価相場、スキル見極めのチェックリスト、そして発注書・RFP に落とす項目までを、そのまま社内共有できる粒度でまとめました。

なお、本記事に記載する法令の解釈や税務上の扱いは一般的な整理です。実際の契約書・発注書の作成時には、自社の法務部門または顧問弁護士・税理士に確認してください。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

PHP/Laravelエンジニアを業務委託で確保する前に決める3つの前提

募集要項を書き始める前に、必ず確定させておきたい前提が 3 つあります。この 3 点が曖昧なまま募集をかけると、応募してくるエンジニアのスキルが自社環境と噛み合わない、あるいは契約後に「これは範囲外です」という追加費用の交渉が発生する、という 2 つの問題が同時に起こります。

前提1｜自社のPHPバージョンとサポート期限を確認する

最初に確認するのは、本番環境で動いている PHP のバージョンです。php -v の出力、あるいは phpinfo() の表示で確認できます。複数のサーバーやコンテナが混在している場合は、すべての実行環境について確認してください。

PHP 公式のサポート状況は次のとおりです（PHP: Supported Versions、2026 年 8 月時点）。

ここから読み取るべき事実は 3 つあります。

1. PHP 8.1 以前はすべてサポート終了済みです。7.4 や 5.6 で動いているシステムは、脆弱性が見つかっても公式パッチが提供されません
2. PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日で終了します。本記事執筆時点（2026 年 8 月）から残り約 4 か月です
3. セキュリティサポート期間中のバージョンでも、アクティブサポートが終了していれば通常のバグ修正は行われません

この事実を発注条件に翻訳すると、「委託範囲に PHP のバージョンアップを含めるか、別発注にするか」という論点になります。含めない場合、保守委託の途中でサポート切れが発生し、セキュリティ監査やカード情報を扱う環境の要件を満たせなくなる可能性があります。含める場合は、調査・改修・テストの工数が上乗せされるため、単価または期間の見直しが必要です。

判断に迷う場合は、募集の時点で「現行バージョンの維持を主とし、アップグレードの要否調査までを含む。実際の改修は別途見積」という切り方をしておくと、後の交渉が整理されます。

前提2｜Laravelのバージョン差が委託範囲に与える影響を把握する

次に Laravel のバージョンです。composer.json の laravel/framework の指定、または php artisan --version で確認できます。

Laravel には重要な特徴があります。すべてのリリースについてバグ修正は 18 か月、セキュリティ修正は 2 年で終了し、LTS（長期サポート版）は提供されていません（Laravel Release Notes - Support Policy）。Laravel 6 を最後に LTS の運用は行われていないため、「LTS を選んでおけば長く使える」という前提は現在では成り立ちません。

2026 年 8 月時点のサポート状況は次のとおりです。

発注設計上とくに重要なのは、Laravel 13 が PHP 8.3 以上を要求する点です。つまり PHP 8.2 で動いているシステムは、Laravel 13 に上げるためには PHP のアップグレードが先に必要になります。そして前提 1 のとおり、その PHP 8.2 自体が 2026 年末でサポートを終えます。

この 2 つが重なると、「Laravel のアップグレード」と「PHP のアップグレード」を切り離せない案件になります。募集要項に「Laravel 12 系の保守」とだけ書いて発注すると、この連鎖に気づいた時点で追加見積が発生します。委託範囲を決める際は、次の 3 択のどれを採るかを先に決めてください。

• A: 現行バージョン維持のみ（アップグレードは対象外。期限到来時に別案件として起票する）
• B: 維持 + アップグレード計画の策定まで（実行は別発注。調査と工数見積を成果物にする）
• C: 維持 + アップグレードの実行まで（期間・予算を厚めに確保する）

前提3｜社内に残るレビュー担当を決めてから募集する

3 つ目は体制の前提です。外部のエンジニアが書いたコードを、社内の誰が確認して本番反映を承認するのかを決めてから募集してください。

社内に PHP を読める人が 1 人もいない状態で業務委託を入れると、次の 2 つのリスクが同時に発生します。

• 成果物の品質を評価できず、検収が「動いているように見えるか」だけの判断になる
• 委託が終わったあとに、新しいブラックボックスが 1 つ増える

レビュー担当は必ずしも PHP を書ける必要はありません。仕様の意図を説明でき、変更内容の影響範囲について質問できる人であれば機能します。それも難しい場合は、調達ルートの選定時に「レビュー体制も含めて提供できる相手」を条件に入れる、あるいは月数時間だけ別のシニアエンジニアにレビューを委託する、という設計を検討してください。

レガシー保守とEC・新規開発で発注設計が変わる理由

ここからが本記事の中心です。同じ「PHP/Laravel エンジニアの業務委託」でも、レガシー保守案件と EC・新規開発案件では、要求スキル・契約形態・稼働の見積り方・成果物の定義がすべて変わります。これを一括りにして発注すると、どちらかが必ず破綻します。

レガシー保守案件で起きること

レガシー保守案件の典型的な状況は、PHP 7.x 以前または Laravel 6〜11 系で動いており、設計書が残っておらず、前任者もいない、というものです。この状況で最初に発生するのは開発ではなく調査です。

調査フェーズで起きることは次のとおりです。

• 画面や API の実際の挙動から、仕様を逆算する作業が発生する
• 「意図的な仕様」なのか「放置されたバグ」なのかを判別できないコードが出てくる
• 依存ライブラリのバージョンが古く、composer update を実行できない
• テストコードが存在しないため、変更の影響範囲を機械的に検証できない

秋霜堂株式会社でも、前任者が不在でドキュメントも残っていない既存システムについて、初期調査から改善対応までを継続的に実施した実績があります（出典: 秋霜堂の受託実績、事例ブログ掲載の既存システム大規模改善案件）。この種の案件で共通するのは、着手時点では工数を正確に見積れないという点です。

したがってレガシー保守案件の発注設計では、次の 2 点を必ず織り込んでください。

• 最初の 1〜2 か月を「調査フェーズ」として明示的に切り出す。成果物は「現状把握レポート」「改善課題の一覧と優先度」とし、この時点では機能改修を成果物にしない
• 調査フェーズの結果をもって、以降の契約条件（期間・稼働時間・単価）を見直す前提を契約書に書いておく

「調査に時間がかかること」を想定外の事態として扱うのではなく、最初から計画に入れておくことが、レガシー保守案件で最も効く発注設計です。

EC・新規開発案件で起きること

EC サイトの機能追加や新規開発の案件では、性質がまったく異なります。既存コードの解読よりも、外部連携と非機能要件の難易度が支配的になります。

• 決済 API 連携: 決済代行会社の仕様に沿った実装が必要で、テスト環境の払い出しに事業者側の手続き期間がかかる
• 在庫の整合性: 同時購入時の排他制御、キャンセル・返品時の戻し処理など、トランザクション設計の巧拙が事故に直結する
• キャンペーン期間の負荷: セール開始直後のアクセス集中に耐える設計が必要で、平常時のパフォーマンスだけでは判断できない
• リリースタイミングの制約: 販促スケジュールに紐づくため、納期が動かせない

EC・新規開発案件で重要なのは、繁忙期の稼働を契約で確保できているかです。セール直前の 2 週間だけ稼働を厚くしたいのに、他の案件と掛け持ちしていて動けない、という事態は珍しくありません。稼働形態を決める際に「特定期間の稼働増を事前に合意する条項」を入れるか、そもそも稼働に余裕のある調達ルートを選ぶかを判断してください。

案件性質別の発注設計対比表

2 つの案件性質を並べると、発注設計の違いは次のように整理できます。

この表の使い方は単純です。保守と新規開発の両方を 1 人に依頼する場合でも、契約は分けるか、少なくとも業務範囲と成果物を別建てで書くということです。同じ契約書に混ぜ込むと、検収の基準が定まらず、稼働の配分についても揉めます。

業務委託でエンジニアを確保する4つの調達ルートと選び方

前提と案件性質が整理できたら、どこから調達するかを決めます。主要なルートは 4 つあり、それぞれリードタイム・単価・スキル担保の責任所在・契約主体が異なります。

4つの調達ルートの比較

リードタイムと単価はトレードオフの関係にありません。むしろ相関するのは「スキル担保の責任を誰が負うか」と「単価」です。開発会社経由が高くなるのは、要員の交代・品質保証・体制維持のコストが乗るためであり、そこに価値を認めるかどうかが選定の分かれ目になります。

保守案件の調達で優先する条件

レガシー保守案件では、次の 3 点を優先してください。

1. 継続性: 短期で抜けられると調査の蓄積がゼロに戻ります。最低 6 か月、できれば 1 年の継続を前提に合意できる相手を選びます
2. 代替要員の確保: 個人 1 名に依存すると、体調不良や他案件との衝突がそのまま業務停止になります。開発会社経由であれば要員交代の条項を、個人と直接契約する場合はバックアップ体制の有無を確認します
3. 稼働の分散: 週 5 日フルではなく、月 60〜80 時間程度の枠で複数月にわたって確保するほうが、保守案件では現実的です。障害対応の待機と定常改修を両立させやすくなります

新規開発案件の調達で優先する条件

EC・新規開発案件では、優先する条件が変わります。

1. スキル適合: 決済・在庫・キャンペーンといったドメインの実装経験があるか。Laravel の経験年数だけでは判断できません
2. 成果物責任: 請負で発注する場合、契約不適合責任の期間と範囲を明確にできる相手か。個人との直接契約では、この責任を実質的に負いきれないケースがあります
3. チーム連携: 社内のデザイナー・マーケ担当・決済代行会社との調整が発生します。技術力だけでなく、仕様確認のコミュニケーションが取れるかを面談で確認してください

準委任と請負の選び方と、偽装請負にしない運用設計

契約形態の選択と、稼働開始後の運用ルールは、発注前に必ず決めておくべき項目です。ここを曖昧にしたまま「とりあえず来てもらう」と、労働者派遣法上の問題に発展する可能性があります。

準委任契約と請負契約の違い

2 つの契約形態は、何に対して対価を払うかが根本的に異なります。

原則として、レガシー保守は準委任、仕様が固まった新規開発は請負が基本形です。保守案件を請負にすると「調査に時間がかかったが成果物ができていない」場合に報酬を巡って揉め、新規開発を準委任にすると「稼働はしたが機能が完成していない」という状態が許容されてしまいます。

契約形態の選定基準をさらに詳しく検討したい場合は、準委任契約と請負契約の違いを発注者視点で整理した記事も参考にしてください。

偽装請負に近づく5つの運用パターンと言い換え方

業務委託契約であっても、実態として発注者が受注者に指揮命令を行っていれば、労働者派遣に該当すると判断される可能性があります。判断は契約書の形式ではなく実態に即して行われ、その基準は厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる 37 号告示）および疑義応答集で示されています。

PHP/Laravel エンジニアの日常業務に落とすと、次の 5 パターンが要注意です。

重要なのは、発注者が仕様や品質基準を伝えること自体は問題ないという点です。問題になるのは、業務の遂行方法や労働時間の配分を発注者が決めている状態です。この線引きをより細かく確認したい場合は、偽装請負の判定チェックリストで自社の運用を点検してください。

契約書に必ず書く6項目

契約形態を決めたら、契約書には最低限次の 6 項目を明記します。

1. 業務範囲: 対象システム、対象のバージョン範囲、含まない業務（例: インフラ構築、他システムの改修）を明示する
2. 成果物: 準委任なら稼働報告書と作業ログ、請負なら納品するコード・設計書・テスト結果を具体的に列挙する
3. 検収基準: 何をもって完了とするか。「受入テストの合格」であれば、テスト項目を誰が作るかまで決める
4. 稼働形態: 月間の稼働時間枠、上限・下限、超過時の精算方法、リモート/常駐の別
5. 秘密保持: 本番データの取り扱い、開発環境へのアクセス範囲、個人情報を含むデータのマスキング方針
6. 中途解除: 解除の条件と予告期間。後述の法令上の予告義務と整合させる

とくに 1 の「含まない業務」は書き漏らしやすい項目です。EC 案件では「決済代行会社との調整」「本番リリース作業」「リリース後の監視」が範囲に入るかどうかで、実際の負荷が大きく変わります。

工数管理・稼働報告を適法に運用する方法

準委任契約では稼働時間が対価の根拠になるため、稼働の把握は必要です。ただし方法を誤ると偽装請負の要素になります。

適切な運用は次のとおりです。

• 報告の粒度は月次または週次の合計時間とし、日々の始業・終業時刻を管理しない
• 報告フォーマットは「作業内容の概要 + 時間数」とし、時間帯の記録は求めない
• 稼働の上限・下限を契約で定め、超過が見込まれる場合は事前に協議する運用にする
• 進捗の確認は「課題ごとのステータス」で行い、「今日は何時間働いたか」で行わない

進捗が見えないことへの不安から日次の細かい報告を求めたくなりますが、それは指揮命令に近づく運用です。不安の解消は、報告頻度ではなく「課題の粒度を細かく分けて発注する」ことで解決してください。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

フリーランス新法・取適法で変わった発注者側の義務

2024 年 11 月と 2026 年 1 月に、業務委託の発注者側に関わる法制度が続けて変わりました。既存の発注書テンプレートをそのまま使っていると、要件を満たさない可能性があります。

適用関係を先に整理します。

• フリーランス・事業者間取引適正化等法（フリーランス法、2024 年 11 月 1 日施行）: 従業員を使用しない個人事業主・一人法人（特定受託事業者）へ業務委託する場合に適用されます（公正取引委員会 フリーランス法特設サイト）
• 中小受託取引適正化法（取適法、2026 年 1 月 1 日施行。旧・下請法）: 従来の資本金基準に加えて従業員数基準が新設され、対象取引が拡大しました（政府広報オンライン）
• 委託先がフリーランス（特定受託事業者）に当たる場合は、フリーランス法が優先して適用されます

つまり、個人のエンジニアに直接発注するならフリーランス法、開発会社に発注するなら取適法を確認する、という整理になります。どちらに当たるかは自社と相手方の規模で決まるため、契約前に法務部門で確認してください。

発注時に明示する取引条件

フリーランス法で最も違反の多い項目が、取引条件の明示義務です。書面または電磁的方法で、次の内容を発注時点で明示する必要があります。

• 業務の内容
• 報酬の額
• 支払期日
• 発注事業者・受注者の名称
• 業務委託をした日、給付を受領する日（納期）
• 給付を受領する場所

報酬の支払期日については、給付を受領した日から起算して 60 日以内のできる限り短い期間内に定める必要があります。再委託の場合は元委託者からの支払期日から 30 日以内という別のルールが適用されます。

PHP/Laravel の委託で実務的に注意すべきなのは、「業務の内容」の書き方です。「Laravel の保守」とだけ書いた発注書では、明示義務を満たしているとは言いがたく、実務上も範囲を巡るトラブルの原因になります。前述の「契約書に必ず書く 6 項目」の粒度で記載してください。

6か月以上の継続委託で必要になる30日前予告

見落とされやすいのが解除時のルールです。6 か月以上継続する業務委託（継続的業務委託）を中途解除する場合、または契約を更新しない場合は、原則として 30 日前までに予告しなければなりません。予告日から解除日までの間に受注者から理由の開示を求められた場合には、理由を開示する義務も生じます。

保守委託は継続前提で始まることが多いため、この規定に該当しやすい類型です。実務上は次の点に注意してください。

• 年度末で保守委託を打ち切る場合、2 月末までには予告が必要になる計算です。予算確定を待ってから通知すると間に合わない可能性があります
• 契約更新の判断時期を、予告期限から逆算して社内スケジュールに組み込んでください
• 受注者側に責任がある場合や、業務委託期間が 30 日以下の短期である場合など、予告が不要となる例外も定められています

取適法で追加された価格協議・支払条件のルール

2026 年 1 月施行の取適法では、旧下請法から次の点が追加・強化されました（中小企業庁 ミラサポplus、公正取引委員会 リーフレット）。

• 協議に応じない一方的な代金決定の禁止: 受託側から価格協議の求めがあったにもかかわらず、協議に応じない、または必要な説明・情報提供を行わないまま代金を一方的に決めることが禁止されました
• 手形払いの禁止: 支払手段としての約束手形等の交付が禁止されました
• 従業員数基準の新設: 資本金基準に該当しなくても、従業員数の基準を満たせば適用対象になります
• 買いたたきの禁止（従来から継続）: 通常の対価に比べて著しく低い代金を定めることは禁止されています

PHP/Laravel の委託で効いてくるのは、価格協議のルールです。長期の保守委託では、稼働の実態が当初の想定とずれることがよくあります。「調査に想定以上の時間がかかっているので単価を見直したい」という申し出があった場合、協議に応じず従前の金額を押し通すと問題になり得ます。契約書に単価改定の協議条項をあらかじめ入れておくことで、この論点は運用可能な形になります。単価をどう交渉・改定するかについては、業務委託の単価交渉を発注者側の視点で整理した記事も参考になります。

PHP/Laravelエンジニアの業務委託単価相場と予算の組み方（2026年）

稟議で必ず問われるのが金額の根拠です。ここでは公開されているエージェントの案件データをもとに、レンジと補正の考え方を整理します。

PHP・Laravel案件の単価レンジ（稼働形態別）

複数の案件データベースが公開している数値は次のとおりです（いずれも 2026 年時点）。

平均値が 64 万円と 80 万円で大きく開いていますが、これは母集団の違いによるものです。掲載案件の累計を対象にしているか、直近募集中の案件に絞っているかで水準が変わります。稟議資料に使う場合は、単一の平均値ではなくレンジで示し、出典と母集団を併記することをおすすめします。

実務的な目安としては、次のように整理できます。

なお、これらは受注者に支払われる金額の水準です。エージェント経由の場合は仲介手数料が別途乗るか、この金額に含まれているかを必ず確認してください。

案件性質による単価の補正

上記のレンジは、そのままでは自社案件に当てはまりません。案件性質による補正が必要です。

レガシー保守案件の補正要因

• 調査工数の不確実性: 着手初期は成果が見えにくく、稼働時間に対して機能改修が進みません。この期間を織り込んだ予算にする
• 古い環境の扱い: サポート切れの PHP バージョン、composer update が通らない依存関係など、対応できる人材の母数が少ないため単価が上振れる傾向があります
• ドキュメント作成: 調査結果のドキュメント化を成果物に含める場合、その工数を別途見込む

EC・新規開発案件の補正要因

• 繁忙期の稼働確保: セール期間の稼働増を事前に押さえる場合、待機分を含めた条件になります
• 決済・在庫のドメイン知識: 経験者は限られるため、汎用的な Laravel 案件より高くなる傾向があります
• 納期の硬さ: 販促スケジュールに紐づく案件は、スケジュールリスクが単価に反映されます

予算計上と税務上の扱い

稟議で正社員採用と比較する際は、次の点を押さえておくと説明しやすくなります。

• 勘定科目: 業務委託の報酬は販売費及び一般管理費の「外注費」または「支払手数料」として計上するのが一般的です。給与とは区分されます
• 法定福利費が発生しない: 社会保険料の会社負担分（健康保険・厚生年金・雇用保険等）は発生しません。正社員の場合は、厚生年金保険料率 18.3%（労使折半）に加え、全額事業主負担の子ども・子育て拠出金 0.36%（令和 8 年度）、都道府県ごとに定まる健康保険料率の会社負担分、雇用保険・労災保険の事業主負担分が上乗せされ、給与の 15% 前後が別途かかります（日本年金機構、全国健康保険協会 令和8年度保険料率）。単純な月額の比較では業務委託が割高に見えても、総コストでは逆転することがあります
• 消費税: 課税仕入れとして扱われます。仕入税額控除の適用には、相手方が適格請求書発行事業者であるかの確認が必要です
• 源泉徴収: 個人に支払う報酬でも、システム開発・プログラム作成の対価は所得税法が定める源泉徴収の対象に原則として該当しません。ただし業務の内容によって判断が分かれるため、税理士に確認してください
• 契約と実態の一致: 実態が雇用に近いと判断されると、給与認定や社会保険加入の問題に発展します。前述の偽装請負の論点と地続きです

正社員採用との比較資料を作る場合は、「月額単価 × 稼働月数」だけでなく、採用コスト、教育期間、法定福利費、退職リスクまで並べると、経営層への説明が通りやすくなります。採用コストのうち人材紹介の手数料は、理論年収（初年度の想定年収）に対して 30〜35% 程度が一般的な水準とされ、IT 人材のように採用難易度が高い職種ではさらに上振れすることがあります（マンパワーグループ）。

スキルの見極めチェックリストと面談で確認する質問

スキルシートに「PHP 8 年、Laravel 5 年」と書かれていても、それが自社環境で通用するかは分かりません。年数ではなく、確認すべき項目に分解します。

PHPバージョンに関する確認項目

• 直近 2 年で担当したシステムの PHP バージョンはいくつか（8.x か、7.x 以前か）
• サポート終了済みのバージョンで稼働するシステムの運用経験があるか
• PHP のメジャーバージョンアップ（7.x → 8.x 等）を完了させた経験があるか。その際に何が壊れ、どう対応したか
• declare(strict_types=1) の有無や型宣言の運用について、方針を持っているか
• 非推奨機能・破壊的変更の情報をどこで収集しているか

自社が PHP 7.x で動いている場合、「8.x の新規開発しか経験がない」人材は適合しません。逆に自社が最新環境で新規開発を進めたい場合、7.x の保守経験だけの人材では設計の引き出しが不足します。

Laravelバージョンとアップグレード経験の確認項目

• 担当した Laravel のバージョン（6 / 8 / 9 / 10 / 11 / 12 / 13 のどれか）
• Laravel のメジャーバージョンアップを実施した経験と、その規模
• composer.json の依存解決で詰まった経験と、その解消方法
• Eloquent のリレーション設計、N+1 問題の検出と対処の経験
• 静的解析（PHPStan / Larastan）とテスト（PHPUnit / Pest）の運用経験。導入から回した経験があるか
• CI/CD パイプラインの構築・運用経験

とくに 3 番目と 5 番目は、レガシー保守案件での実力差が出やすい項目です。テストがない状態でどう安全に変更を入れるかについて、具体的な手順を語れるかを確認してください。

EC・決済まわりの実装経験の確認項目

EC 案件では、以下を追加で確認します。

• 決済代行会社（GMO ペイメントゲートウェイ、SBペイメントサービス、Stripe 等）との API 連携経験
• 3D セキュア 2.0 対応の実装経験
• 在庫の排他制御をどう実装したか（悲観ロック / 楽観ロック / キューによる直列化のいずれか、およびその選択理由）
• キャンペーン時のアクセス集中に対する対策（キャッシュ設計、DB のスロークエリ対策、キューによる非同期化）
• 返品・キャンセル時の在庫と会計データの整合性をどう担保したか
• PCI DSS への対応が必要な環境での作業経験（カード情報を非保持化する構成の理解）

面談で必ず聞く5つの質問

抽象的なスキル確認ではなく、次の 5 問を投げると実力が見えやすくなります。

1. 「直近で担当したシステムの PHP と Laravel のバージョンを教えてください。そのバージョンが選ばれていた理由は何でしたか」 — バージョンへの意識と、環境の背景を捉える力を確認できます
2. 「テストコードがない既存システムに機能追加する場合、最初の 1 週間で何をしますか」 — レガシー保守案件での動き方が具体的に見えます
3. 「本番で原因不明のエラーが出ています。ログはあるが再現手順が分かりません。どう調査を進めますか」 — 障害対応の思考プロセスが確認できます
4. 「これまでで最も判断に迷った技術選択と、その結果を教えてください」 — 意思決定の質と、振り返る習慣の有無が分かります
5. 「私たちの社内には PHP を読める人が今いません。この状況で、どうやって成果を確認してもらうのがよいと思いますか」 — 発注者の制約を理解した上で提案できるかを確認できます。5 問目は、レビュー体制が薄い企業ほど重要です

発注書・RFPに落とす項目と、稼働開始後の運用設計

ここまでの判断を、実際の発注ドキュメントに落とし込みます。

発注書・RFPに書く8項目

この 8 項目がそのまま、冒頭で述べた「発注前に決めておくべきこと」の答えになります。稟議資料を作る際は、この表を埋める形で進めると抜け漏れが起きにくくなります。

稼働開始後の同期とレビュー体制

発注して終わりではありません。稼働開始後の運用も設計しておきます。

• 週次の同期: 進捗確認ではなく「課題の棚卸し」を目的にします。完了した課題、着手中の課題、判断待ちの課題を並べ、判断待ちを解消するのが発注者側の仕事です
• コードレビュー: 社内にレビュアーがいる場合はプルリクエスト単位で確認します。いない場合は「変更内容と影響範囲の説明」を文章で受け取り、その説明が理解できるかを確認するだけでも一定の効果があります
• 契約更新前の稼働レビュー: 更新判断の 1 か月以上前に、稼働の実態と当初想定のずれを確認します。単価改定の協議が必要な場合はここで着手します
• 判断の記録: 「なぜこの実装を選んだか」を課題管理システムに残す運用にしておくと、委託終了後の資産になります

引き継ぎドキュメントの必須項目

委託終了時に何を受け取るかを、契約時点で決めておいてください。ここを決めずに終えると、新しいブラックボックスが増えるだけになります。

必須項目は次のとおりです。

1. 未解決課題リスト（最優先）: 認識しているが手を付けていない不具合・技術的負債・リスクの一覧。「調査したが原因が特定できていない事象」も含めます
2. システム構成図: サーバー構成、外部連携先、データの流れ
3. バージョン情報とサポート期限: PHP・Laravel・主要ライブラリの現行バージョンと、それぞれのサポート終了日
4. 環境構築手順: ローカル環境を立ち上げる手順。実際に手順どおりに動くことを確認済みであること
5. デプロイ手順とロールバック手順: 本番反映の手順と、失敗した場合の戻し方
6. 定期作業の一覧: バッチ処理、cron、証明書更新など、定期的に発生する作業とその時期

1 の未解決課題リストを最優先に置くのは、これが最も引き継がれにくく、かつ次の担当者が最も必要とする情報だからです。「動いているものの説明」よりも「動いていない・怪しい箇所の説明」のほうが、引き継ぎの価値は高くなります。

まとめ

PHP/Laravel エンジニアを業務委託で確保する際の要点は、次の 3 点に集約されます。

1. 保守と新規開発で発注設計を分ける: 契約形態（準委任 / 請負）、成果物の定義、稼働形態、求めるスキル、引き継ぎ責任のすべてが案件性質によって変わります。1 人に両方を依頼する場合でも、業務範囲と成果物は別建てで記載してください
2. バージョンのサポート期限を委託範囲の条件に書く: PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日に終了し、Laravel 13 は PHP 8.3 以上を要求します。アップグレードを委託範囲に含めるかを、募集の時点で決めておくことで追加費用の交渉を避けられます
3. 法改正で増えた明示義務・予告義務を発注書に反映する: フリーランス法の取引条件明示義務と 60 日以内の支払期日、6 か月以上の継続委託における 30 日前予告、取適法の価格協議義務。既存の発注書テンプレートが対応できているかを法務部門で確認してください

次に進めるアクションは、以下の順序をおすすめします。

1. 対象バージョン範囲の確定: 本番環境の PHP・Laravel バージョンを洗い出し、アップグレードを委託範囲に含めるか（維持のみ / 計画策定まで / 実行まで）を決める
2. 契約形態の選定: 保守は準委任、新規開発は請負を基本形として、案件を分類する
3. 面談チェックリストの準備: 本記事のスキル確認項目と 5 つの質問を、自社の技術構成に合わせて調整する
4. 発注書ドラフトの作成: 「発注書・RFP に書く 8 項目」を埋め、法務部門でフリーランス法・取適法への対応を確認する

この 4 ステップを終えた段階で、経営層への説明材料と、募集要項の骨子が同時に揃います。

関連情報

外部人材の活用を社内で検討・提案する際の資料としては、お役立ち資料もあわせてご覧ください。発注の判断材料を整理した資料をダウンロードいただけます。

PHP/Laravel システムの保守体制や、発注範囲の切り分けについてご相談されたい場合は、お問い合わせフォームからお問い合わせください。要件が固まっていない段階からのご相談も承っています。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。