トップ › お役立ち記事 › Web制作・デザイン
Web制作・デザインWordPressエンジニアのスキルシートの書き方|面談で評価される実績の見せ方
公開 2026-10-29 監修:株式会社エージェントベスト
WordPressエンジニアのスキルシートは、WordPressとPHPの版、テーマの種類、自分で作ったブロックやプラグインを分けて書き、保守の仕事は更新の手順と頻度まで書くのが基本です。「WordPressでのサイト構築」とだけ書いたシートでは、管理画面での組み立てなのか、PHPでの開発なのか、運用中のサイトを守る仕事なのかが読み手に伝わりません。
スキルシート全体の構成はスキルシートの基本で解説しています。PHP全般の書き方はPHPエンジニアのスキルシートの記事にまとめているため、この記事ではWordPressに特有の書き分けに絞ります。
読み手がWordPressのシートで探すこと
WordPressの案件の担当者がシートで最初に探すのは、おおむね次の点です。
- どの版のWordPressとPHPで作業したか
- テーマの種類(ブロックテーマか、クラシックテーマか、その中間の作りか)
- 独自のブロックやプラグインを自分で書いたか
- 運用中のサイトの更新や不具合対応を担ったか
- サーバーや表示速度の改善まで関わったか
構築の案件では前の3つ、保守の案件では後の2つが特に重く見られます。ここが探さずに見つかるシートは、構築の案件と保守の案件のどちらにも合うかを判断しやすくなります。
技術欄は「本体」「PHP」「作り方」を分けて書く
版は作業した時点のものを書く
WordPressの開発者向けの資料では、WordPressの版ごとに対応するPHPの版が示されています。2026年10月時点では、WordPress 7.0と7.1は PHP 7.4〜8.5、6.9は7.2〜8.5に対応しています。版によって使える機能も、動くPHPも違うため、読み手は版の数字を手がかりに経験の新しさを判断します。
| 書き方 | 読み手の受け取り方 |
|---|---|
| WordPress、PHP | いつの経験か分からず、案件に合うか判断できない |
| WordPress 6.x→7.x、PHP 8.1→8.3 | 比較的新しい版で、版の更新も経験したと分かる |
| WordPress 5.x(クラシックエディタ)、PHP 7.x | 古いサイトの保守や移行で判断材料になる |
版を更新したプロジェクトは「○→○」と前後を書きます。自分が担当した期間の版を書くのが基本で、触っていない版をプロジェクト全体の版として書かないよう注意します。
テーマの種類とエディタを書く
同じテーマの開発でも、ブロックテーマとクラシックテーマでは作り方が大きく違います。「オリジナルテーマ開発(ブロックテーマ、テーマ設定ファイルで色と余白を管理)」「クラシックテーマの保守(ブロックエディタへの移行を一部担当)」のように、種類と担当を一言で添えます。
よく使ったプラグインは役割と一緒に書く
プラグインの名前を並べるだけでは、導入しただけか、設定や拡張まで行ったかが分かりません。「多言語化のプラグイン(翻訳の運用ルールを設計)」のように、何をしたかを括弧で添えます。業務で使った有料のプラグインや社内のツール名は、外に出してよいかを確かめてから書きます。
自作したブロックとプラグインの書き方
自分で書いたコードの経験は、WordPressのシートでいちばん差がつく部分です。名前ではなく、何のために作り、何を判断したかを書きます。
- 独自ブロック:何の入力を楽にするために作ったか、設定で何を絞ったか、block.jsonやJavaScriptで書いたか、PHPだけで作ったか
- プラグイン:既製品で足りなかった理由、どのフックを使ったか、管理画面の設定ページを作ったか
- 外部連携:どのデータを、どの方向に、どの頻度でやり取りしたか
ブロックの開発の基本は、公式の資料ではblock.jsonでの定義とJavaScriptでの開発として説明されています。どちらの作り方の経験かを書いておくと、読み手は案件に合うかを判断しやすくなります。
保守の仕事は手順と頻度で書く
保守の経験は「保守運用を担当」と書かれがちですが、これでは何をしていたかが伝わりません。次の3つを書くと、運用中のサイトを任せられるかが伝わります。
- 対象:サイトの数と種類(企業サイト、メディア、会員制のサイトなど)
- 頻度と手順:更新の頻度、検証環境での確認、バックアップと戻し方
- 対応した出来事:更新による不具合、PHPの版の更新、改ざんや不正なログインへの対応
障害の件数や具体的な被害は、守秘義務に触れることがあります。その場合は「更新後の表示崩れを検証環境で事前に発見する手順を整えた」のように、状態の変化で書けば十分です。外に出してよい範囲の判断はスキルシートと守秘義務の記事をご覧ください。
プロジェクト欄の記入例(架空)
次は、書き方の型を示すための架空の例です。実在の案件や人物ではありません。ご自身の経験に置き換えてお使いください。
例1:構築と機能開発
期間:○年○月〜○年○月(半年程度)
案件概要:(架空)BtoB企業の製品紹介サイトの新規構築
規模・立場:制作チーム数名(うち自分は実装の担当)
使用技術:WordPress 7.x(ブロックテーマ)、PHP 8.3、JavaScript、Git
新しく作ったもの:製品のカスタム投稿タイプと絞り込み検索。製品の仕様表を入力する独自ブロックをblock.jsonで定義して開発
工夫したこと:入力する人が見た目を崩さないよう、ブロックで選べる色と余白を絞った
例2:保守と移行
期間:○年○月〜現在(1年以上)
案件概要:(架空)複数の企業サイトとメディアの保守
規模・立場:保守の担当として単独で参画
使用技術:WordPress 6.x→7.x、PHP 7.4→8.3、MySQL、サーバーの管理画面
保守したもの:月1回の本体・プラグインの更新。検証環境で表示と主要な機能を確かめてから本番に反映
移行したもの:PHPの版の更新に合わせ、動かなくなった古いプラグインを置き換え、独自に改変されていたテーマの処理をフックに移した
例のように「新しく作ったもの」「保守したもの」「移行したもの」を分けた行を作ると、読み手は自分の案件に近い経験をすぐに見つけられます。
書き直すタイミング
WordPressは大型の更新が続くため、版の数字は少し時間がたつと古く見えます。案件が終わったときや、新しい版で作業したときに、技術欄の版と担当内容を書き足しておくと、応募のたびに慌てずに済みます。
公開しているサイトやコードの扱い
WordPressの仕事は公開されたサイトとして残るため、URLを載せたくなるかもしれません。ただ、制作会社や発注元の了承がないと載せられないことが多く、公開後に他の人が手を入れて、自分の担当した部分が分からなくなっていることもあります。載せる場合は、了承を得たうえで「担当:製品ページのテンプレートと検索機能」のように範囲を添えます。
自分で作ったプラグインやブロックをGitHubなどに置いている場合は、何を見てほしいかを一言添えて載せます。載せ方の注意点はポートフォリオとGitHubの記事で解説しています。
よくある質問
担当したサイトが多すぎて、全部書ききれません。
すべてを同じ分量で書く必要はありません。期間・件数・主な担当をまとめた行を一つ作り、深く関わった数件だけをくわしく書く形が向いています。応募する案件に近いものを優先して選んでください。
管理画面での設定が中心の経験は、書いても評価されませんか?
設定や運用の経験も、運用中のサイトを支える仕事として書く価値があります。ただし、コードを書いた経験と混ぜずに分けて書くことが大切です。何を設定し、何に困って、どう解決したかを書くと伝わりやすくなります。
デザインも担当していた場合は、どう書けばよいですか?
担当した範囲が分かるように、デザインと実装を別の行に分けて書きます。主な担当が実装であれば、その順番で並べてください。デザインを軸にして案件を探す場合は、デザインの実績が先に来るように並べ替えたシートを別に用意しておくと、読み手が判断しやすくなります。
参考にした公的情報・資料
- PHP Compatibility and WordPress Versions(Make WordPress Core)
- Fundamentals of Block Development(WordPress Developer Resources)
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。