PHPエンジニアのフリーランス面談でよく聞かれる質問と答え方の準備

PHPエンジニアのフリーランス面談でよく聞かれるのは、直近の案件で設計から運用のどこまでを担ったか、Laravelなどのフレームワークをどう使い分けたか、テストのない既存のコードをどう直したか、遅い処理やセキュリティの問題にどう対応したかです。面談官は、知っている機能の数より「このコードベースを任せたら、壊さずに前へ進めてくれるか」を確かめようとしています。

答えるときは、模範解答を覚えるより、自分の経験から「調べて、判断して、直した場面」を3〜4つ選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではPHPの面談に固有の質問に絞ります。

PHPの面談で面談官が見ていること

PHPの案件の面談に出てくるのは、開発チームのリーダーやテックリード、小さな会社ではCTOや事業の責任者です。自分でもPHPを書いている人が多く、話の中に出てくる判断の根拠と、言葉の正確さを聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 任せられる範囲：設計、実装、テスト、リリース、運用のどこまでを一人で回せるか
2. 既存のコードへの向き合い方：テストや文書がないコードを、どう調べて、どう安全に直すか
3. チームとの相性：レビューの受け方と出し方、仕様が曖昧なときの確認の仕方が、自分たちのやり方に合うか

PHPは経験者が多い言語のため、「PHPとLaravelが書ける」だけでは差がつきません。以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「直近の案件で、どこからどこまでを担当しましたか」

確かめたいのは、任せられる範囲です。チームの人数、自分の役割、設計・実装・テスト・リリース・運用のうち担ったもの、PHPとフレームワークの版を短く伝えます。「Laravelで開発していました」で終わると、範囲が見えません。

架空の例：「5名のチームで、Laravel 10のAPIと管理画面の実装を担当しました。テーブル設計はリーダーと相談して決め、リリースの作業は自分で行っていました。インフラの構築は別の担当者がいました」

2. 「Laravelのどの機能を、どんな意図で使いましたか」

PHPの面談に特有の質問です。使った機能の名前より、なぜその使い方を選んだかを聞いています。たとえば、処理をコントローラーに書かずにサービスクラスやジョブに分けた理由、Eloquentで済ませた箇所と生のSQLを書いた箇所の分け方、認可をポリシーで書いた理由などです。

フレームワークの流儀に従った判断と、あえて外した判断の両方を話せると、設計の意図を理解して使っていることが伝わります。求められるスキルの中身はPHPのスキルの記事で整理しています。

3. 「テストのないコードを直すとき、どう影響範囲を調べましたか」

最もよく掘り下げられる質問です。PHPの案件は既存システムの改修が多く、この答えで信頼の度合いが決まります。次の順番で組み立てると伝わりやすくなります。

• 何を手がかりに該当する処理を見つけたか（ルーティング、ログ、画面からの追跡など）
• 呼び出し元と、同じテーブルを触る処理をどう洗い出したか
• 直す前に、どの単位でテストや動作確認を足したか
• どの範囲まで確かめてからリリースしたか
• 結果と、次に生かしたこと

「気をつけて直しました」だけで終わると、手順が見えません。調べ方の手順を話せると、ほかのコードベースでも同じようにできると受け止められます。

4. 「PHP本体やフレームワークのバージョンアップの経験はありますか」

PHPは版ごとにサポートの期限があり、版上げの仕事が繰り返し生まれます。経験があれば、どの版からどの版へ上げたか、どう計画したか、何が動かなくなり、どう検証したかを話します。経験がなければ、無理に作らず、非推奨の書き方への対応や、ライブラリの更新で似た作業をした経験を話しましょう。

5. 「遅いページやSQLをどう見つけて、どう直しましたか」

性能の問題への向き合い方を確かめる質問です。N+1の問題やインデックスの不足といった典型的な原因の名前を挙げるだけでなく、何で計測して、何を根拠に原因だと判断したかを話します。直した後に、どう効果を確かめたかまで話せると、再現性のある対応だと伝わります。

6. 「セキュリティで気をつけていることは何ですか」

SQLインジェクション、XSS、CSRF、認可の漏れなど、Webの代表的な脆弱性への対策を、フレームワークがどこまで守ってくれて、自分で何を守る必要があるかを分けて話します。「Laravelが守ってくれる」で終わると、生のSQLや認可の実装で穴を開ける人だと見られかねません。レビューで実際に指摘した、または指摘された経験があれば、その場面が最も伝わります。

7. 「仕様が曖昧なとき、どう進めますか」

自社サービスの案件でよく聞かれます。面談官は、止まって待つ人か、勝手に決めて進める人か、確かめてから進める人かを見ています。誰に、どのタイミングで、どんな選択肢を示して確かめたかを、具体的な場面で話しましょう。レビューの指摘を受けたときの対応の仕方も、同じ観点で見られています。

8. 「生成AIをコードを書くときにどう使っていますか」

2026年10月時点では、この質問も増えています。使っているかどうかより、出てきたコードをどう検証しているか、チームのルールや機密の扱いをどう守っているかが見られます。使っていない場合も、その理由を話せれば問題ありません。

9. 「稼働の条件と、開始できる時期を教えてください」

稼働日数、リモートの希望、出社できる頻度、開始できる時期を正確に答えます。ここで曖昧に答えると、後の条件の調整で食い違いが起きます。希望は面談の前に整理しておき、スキルシートと同じ内容を伝えましょう。

技術課題やコーディングテストへの備え

PHPの面談では、面談の前後に技術課題が出されることがあります。形は案件によって違います。

課題の分量が大きすぎる場合や、業務に近い成果物を無償で求められる場合は、受けるかどうかを考える材料になります。考え方は技術テストの記事と無償の課題の扱いで解説しています。

準備は「調べて直した場面」を3〜4つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：既存コードの改修、版上げ、性能の改善、セキュリティの対応、仕様の確認など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、調べ方、選択肢、選んだ理由、確かめ方、結果、学びを書き出す
3. 技術の数字をそろえる：PHPとフレームワークの版、チームの人数、担当した期間を、どの場面でも同じ数字で言えるようにする
4. 2分版と5分版をつくる：最初は2分で話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた版や役割と、話の内容が一致しているかを確かめる

スキルシートとの一致は特に大切です。面談官はシートを見ながら質問するため、「シートにはLaravelと書いてあるが、話を聞くと保守で少し触っただけ」のようなずれがあると、ほかの記述も疑われます。シートの書き方はPHPのスキルシートの記事、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

面談の相手によって重心が変わる

PHPの面談は、相手によって聞かれる内容の重心が変わります。

受託の案件では、受託会社と発注元の両方と面談することがあります。受託会社の面談では工程と文書の経験、発注元の面談では説明の分かりやすさに重心を置くと、限られた時間を有効に使えます。

PHPならではの逆質問

面談の終わりには、こちらから質問できる時間があります。逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。PHPの案件では、次の点を聞いておくと判断がしやすくなります。

• PHP本体とフレームワークの版、版上げの予定の有無
• テストコードの有無と、CIで何を自動で確かめているか
• レビューの体制（誰が見るか、プルリクエストの大きさの目安）
• 本番へのリリースの手順と頻度、障害時の連絡と対応の体制
• 自分のほかにPHPを読める人がいるか、設計の相談相手は誰か
• 開発環境（貸与端末か、自分の端末か）とリモートの条件

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。逆質問で聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点はPHP案件の選び方で整理しています。

よくある質問

Laravel以外のフレームワークの経験が中心でも、Laravelの案件の面談は通りますか？

CakePHPやSymfonyなどの経験があれば、MVCの考え方やORMの使い方は共通しているため、面談で見送られる理由にはなりにくいです。ただし、Laravelに固有の仕組み（サービスコンテナ、ミドルウェア、ジョブなど）を自分で触って理解しておくと、質問に具体的に答えられます。触った範囲を正直に伝えることが大切です。

面談でコードを見せてほしいと言われたら、何を見せればよいですか？

公開してよい個人のリポジトリがあれば、構成とテストが整っているものを選びます。業務で書いたコードは守秘の対象になるため見せられません。その場合は、設計の考え方を口頭や図で説明できるように準備しておきましょう。公開の成果物の扱いはポートフォリオとGitHubの記事で解説しています。

面談で見送られやすい答え方はありますか？

技術名を並べるだけで判断の中身が出てこない、既存コードの直し方を聞かれて「気をつけて直す」としか答えられない、稼働の条件が面談ごとに変わる、といった点が挙げられます。見送られやすい理由は面談で見送られる理由の記事で解説しています。