PHPエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

PHPエンジニアのスキルシートは、PHP本体とフレームワークの版を分けて書き、「新しく作った仕事」と「既存のコードを直した仕事」を別の行に書くのが基本です。PHPの案件は新規開発と既存システムの改修・バージョンアップが混ざっているため、読み手はまず「どちらの経験がどれだけあるか」を探します。そこが一目で分かるだけで、提案できる案件の幅が変わります。

スキルシート全体の構成はスキルシートの基本で解説しています。この記事では、PHPのエンジニアが書くときに迷いやすい部分に絞って説明します。

読み手がPHPのシートで最初に確かめること

PHPの案件の担当者がシートを開いて最初に見るのは、おおむね次の4点です。

• PHPの版とフレームワーク（Laravel、CakePHP、Symfony、独自フレームワークなど）
• 新規開発か、運用中のサービスの機能追加か、古いシステムの改修か
• サービスの種類と規模（利用者向けのWebサービス、社内の業務システム、ECなど）
• テスト・静的解析・CIなど、安全に変えるための仕組みに関わったか

案件で求められるスキルそのものはPHPの案件で求められるスキルの記事にまとめています。スキルシートでは、それらの経験が「どの案件で、どの深さで」あったのかを、読み手が探さずに見つけられるように並べます。

技術欄は「PHPの版」と「フレームワークの版」を分ける

PHPのシートでよくあるのが、技術欄に「PHP、Laravel」とだけ書く形です。これでは、古い版の保守なのか、新しい版での開発なのかが分かりません。PHPは版によって書き方や使える機能が大きく違い、フレームワークも版ごとにサポートの期限があるため、読み手は版の数字を重く見ます。

版が途中で変わったプロジェクトは、「○→○」のように移行の前後を書きます。これだけで、バージョンアップに関わったことが伝わります。古い版の経験も隠す必要はありません。古いシステムの改修案件では、むしろ判断材料になります。

独自フレームワークや素のPHPの経験

社内独自のフレームワークや、フレームワークを使わないPHPで長く開発してきた方もいます。その場合は「独自フレームワーク（MVC構成、ORMなし）」のように、構成の特徴を一言添えると、読み手が中身を想像しやすくなります。名前の知られたフレームワークでないことは不利とは限らず、「既存のコードを読んで直せる人」を探している案件では評価の対象になります。

「作った仕事」と「直した仕事」を分けて書く

PHPの経験を棚卸しすると、新しい機能を作った仕事と、すでに動いているコードを直した仕事が混ざっているはずです。整理の進め方はPHPエンジニアの独立の記事で扱っているので、ここではシート上の見せ方を説明します。

プロジェクト欄の「担当内容」を、次のように2つに分けると読みやすくなります。

• 新規に作ったもの：画面・API・管理機能・外部サービスとの連携など、自分が設計から関わった機能
• 改修・保守したもの：不具合の調査と修正、性能の改善、バージョンアップ、脆弱性への対応

同じプロジェクトの中で両方を担当していた場合も、1行にまとめず分けて書きます。「機能追加と保守を担当」と書くより、何を作り、何を直したかが並んでいるほうが、運用中のサービスに入る案件でも新規開発の案件でも、合うかどうかを判断しやすくなります。

WordPressや制作案件の経験の書き分け

WordPressなどのCMSの経験は、どこまで踏み込んだかで評価が大きく変わります。「WordPress」とだけ書くと、管理画面での設定なのか、PHPでの開発なのかが伝わりません。

制作会社出身の方は、多くの案件を短い期間で担当していることがよくあります。1件ずつ同じ分量で書くとシートが長くなるので、「期間・件数・主な担当」をまとめた行を作り、特に深く関わった数件だけをくわしく書く形が向いています。

性能改善とセキュリティ対応の書き方

PHPの案件では、遅い画面やSQLの改善、脆弱性への対応が日常的に発生します。これらはシートで差がつきやすい部分ですが、「パフォーマンス改善を担当」と書くだけでは伝わりません。次の3つをそろえて書きます。

1. どうやって原因を見つけたか：遅いクエリのログ、実行計画、プロファイラーなど
2. 何を変えたか：インデックスの追加、N+1の解消、キャッシュの導入、処理の非同期化など
3. どれくらい良くなったか：前後の比較

前後の比較は、具体的な秒数やアクセス数が守秘義務に触れることがあります。その場合は「応答時間がおおむね半分に」「タイムアウトが出なくなった」のように、相対的な表現や状態の変化で書けば十分です。社外に出してよい範囲の判断はスキルシートと守秘義務の記事をご覧ください。

セキュリティ対応も同じで、「脆弱性診断の指摘に対応」だけでなく、「ファイルアップロードの検証と保存場所を見直した」「SQLの組み立てをプレースホルダーに統一した」のように、何を変えたかを書きます。

プロジェクト欄の記入例

次は、書き方の型を示すための例です。業種や規模はぼかしてあり、実在の案件ではありません。ご自身の経験に置き換えてお使いください。

期間：○年○月〜○年○月（1年程度）
案件概要：小売業向け 会員制ECサイトの運用と改修
規模・立場：開発チーム数名（うち自分はバックエンドのメンバー）
担当工程：詳細設計、開発、テスト、リリース後の保守
使用技術：PHP 7.4→8.x、Laravel 8→10、MySQL、Redis、Docker、GitHub Actions
新規に作ったもの：ポイント付与の管理画面とバッチ処理の設計・実装
改修・保守したもの：PHPとLaravelの版の更新。PHPStanを導入し、警告を段階的に減らしてから版を上げた。注文一覧のN+1を解消
工夫・成果：版の更新を機能ごとに分けてリリースし、大きな障害なく切り替えた。注文一覧の表示がおおむね半分の時間になった

この例のように、「新規に作ったもの」と「改修・保守したもの」を分けた行を作ると、読み手は自分の案件に近い経験をすぐに見つけられます。

GitHubや個人の成果物の扱い

業務のコードは公開できないことがほとんどなので、PHPの案件でも、GitHubのリポジトリはあくまで補足として扱われます。載せる場合は、次の点を整えておくと読み手に意図が伝わります。

• 小さくてもよいので、Laravelなどで作ったアプリにテストとREADMEがある
• 版の更新や静的解析の設定など、実務で大事にしていることがコードから分かる
• 業務のコードや設定値、顧客の情報を含んでいない

シートには「GitHub：URL（Laravelで作った予約管理のサンプル。テストとCIを設定）」のように、何を見てほしいかを一言添えます。URLだけを置くと、読み手はどこを見ればよいか分かりません。技術記事を書いている場合も同じように、テーマを一言添えて載せます。

よくある質問

古いPHPの経験しかありませんが、そのまま書いてよいですか？

そのまま書いてかまいません。版の数字を正確に書けば、古いシステムの保守や移行の案件で判断材料になります。新しい版に触れている場合は、学習中のものと実務のものを分けて書き添えると、面談での食い違いを防げます。

複数のフレームワークを使ってきた場合、どう並べればよいですか？

スキル一覧では、フレームワークごとに実務の期間と主な版を書きます。応募する案件で使うフレームワークを上に並べると、読み手が見つけやすくなります。プロジェクト欄には、そのプロジェクトで使ったものだけを書きます。

フロントエンドも少し担当していた場合、書いたほうがよいですか？

担当した範囲が分かるように書いておくと、判断材料になります。たとえば「Bladeでの画面実装」「Vue.jsの既存画面の修正」のように、どこまで触ったかを具体的に書きます。主な担当がバックエンドであれば、その旨が分かる順番に並べてください。