制作会社がWordPress実装を外注するときの依頼資料と検収表｜デザイン支給から公開まで

デザインが完成したのに、実装が始まってから「この見出しは管理画面で変えられるのか」「スマートフォンでメニューはどう動くのか」「公開作業は誰の担当か」が次々に出てくる。制作会社がWordPress実装を外注するとき、遅れの原因はコードを書く速さだけとは限りません。支給資料と決める人が曖昧なまま進むと、後からの確認と修正が増えます。

この記事は、外部実装担当へ依頼するための資料を、着手前・テスト・公開の三段階で整理します。すべての仕様を最初から完璧にする必要はありません。確定していること、未確定だが着手に影響すること、後で決めてもよいことを分け、誰がいつ判断するかを残します。自社で実装する場合も、社内担当との引き継ぎ表として使えます。

最初に「誰が決め、誰が実装し、誰が承認するか」を分ける

制作会社、実装担当、発注企業の三者がいる案件では、同じ「確認」という言葉に違う仕事が混ざります。制作会社はデザインと顧客要件をまとめ、実装担当は合意した仕様をコードやWordPressへ反映し、発注企業はサービス内容や公開可否を最終確認する、といった分担が考えられます。ただし実際の分担は案件ごとに決めます。担当を決めないまま「任せます」と書くと、原稿の事実確認や公開ボタンの押下まで相手に任せたつもりになることがあります。

初回の依頼文では、次の三つを一行ずつ書きます。「制作会社が確定するもの」「外部実装担当へ依頼するもの」「発注企業の承認が必要なもの」。たとえばデザインデータの提供は制作会社、WordPressテンプレートの作成は実装担当、掲載する料金や事例は発注企業の承認、と分けます。誰かが複数の役割を兼ねても構いません。その場合も判断と実作業を分けて記録すると、変更時の確認先が明らかになります。

この表は契約上の責任を自動で決めるものではありません。案件の見積書や依頼書に、納品物、確認方法、対象外作業を書き込みます。特に顧客との直接連絡、ホワイトラベル、守秘、ソースの保管・返却は、実装担当が外部の場合に早めに合意してください。Acquaへ依頼する場合も制作会社向け案内にあるように、案件ごとの仕様と制作ルールを確認して担当工程を決めます。

支給資料を「着手に必要」と「後から決められる」に仕分ける

最初に送る資料は多ければよいわけではありません。最新版がどれか分からないPDF、複数のFigmaリンク、古い画像フォルダーをまとめて渡すと、実装担当は何を基準にすべきか判断できません。資料名、版、最終更新日、確認者を一覧にし、正本へのリンクを一つ示します。変更した箇所は履歴に追記します。

着手に必要なのは、対象ページとテンプレートの一覧、デザインの正本、利用するWordPress環境、主要な動作、CMSで編集したい範囲、希望する確認日と公開日です。すべての原稿が完成していなくても、仮原稿を誰がいつ正式原稿へ替えるか決まっていれば着手できる場合があります。一方、見出しの長さでレイアウトが変わる、フォームの項目が未定、記事一覧の条件が未定なら、実装方式に影響するため先に確認します。

資料一覧には「確定」「仮」「未提出」を付け、仮のものには期限と決定者を書きます。期限を過ぎたときは推測で作るのではなく、当該箇所を止めるのか、仮仕様で進めて後から追加費用の対象とするのかを合意します。写真やロゴは権利確認も必要です。外部担当へ渡した画像が本番で使えるとは限らないので、仮画像・正式画像を区別します。

依頼時の最低限の表は次の形で十分です。

この表を毎回作り直す必要はありません。案件の共有場所へ置き、版と未確定事項だけ更新します。パスワードそのものをこの表に書かず、権限の付与先と手段を別に決めてください。

デザインは画面幅だけでなく「状態」を指定する

PCとスマートフォンの静止画が二枚あっても、実装仕様がすべて決まるわけではありません。ナビゲーションを開いた状態、フォームの入力エラー、アコーディオンの開閉、カード数が一件のとき、長い見出し、画像がないとき。こうした状態が不明だと、担当者が見た目と動作を補う必要があります。

画面ごとに、デザインの正本、基準幅、境界幅での振る舞い、クリック・キーボード操作、画像比率、見出し・本文の可変長を確認します。すべての幅に完成モックを作る必要はありません。モックがない幅の折り返しや配置について「PCからの縮小」「列の入れ替え」「非表示」などの方針を一文で示し、曖昧な箇所を実装前に質問できるようにします。非表示にすると必要な情報が失われる場合は、別の表示方法を決めます。

たとえば「カードはPCで三列、スマートフォンで一列」だけでは、二列になる幅、写真のトリミング、カードの高さが分かりません。「768px付近は二列、見出しは最大三行でも要素が重ならない。画像の焦点は中央。カード全体をリンクにする」と指定すれば、実装担当も確認箇所を決められます。ここに挙げた幅は説明用の例であり、Acquaや他社の固定仕様ではありません。

デザインレビューでは、色や余白の差だけでなく、クリックできる場所、フォーカスの見え方、縮小時の横はみ出し、画像内の文字の読め方を見ます。制作会社が視覚表現の最終判断を持つ場合は、実装担当が「デザインとの差分一覧」を返し、修正か仕様として許容するかを制作会社が決めます。既存のデザイン確認の進め方は発注企業側のレビューを扱うため、本記事では実装担当との受け渡しに絞ります。

WordPressで「どこを編集できるか」をページ単位で決める

「WordPress化」とだけ書いても、更新できる範囲は決まりません。ページ全体をブロックで編集するのか、固定レイアウトの文章と写真だけを管理画面で替えるのか、記事一覧を自動表示するのか。発注企業の更新担当が何を何回程度変えるかを聞き、実装すべき編集欄を決めます。使わない入力欄を増やすと更新時の迷いが増え、編集できない箇所が多すぎると毎回外注が必要になります。

ページ一覧を、URLではなく「テンプレートの種類」でも整理します。トップ、サービス詳細、事例詳細、記事詳細、一覧、検索、404などで、共通部分と個別部分を分けます。WordPressは表示するURLや内容に応じてテンプレートを選ぶ仕組みがあり、クラシックテーマとブロックテーマでファイルの形も異なります。WordPress公式のテーマ解説とテンプレート階層を実装担当との共通参照にできます。ただし既存サイトで独自の構成を使っている場合は、実ファイルと設定を確認して判断します。

CMS要件には「編集する人」「編集する項目」「入力の制約」「一覧への反映」「公開前の承認」をセットで書きます。たとえば事例なら、会社名、掲載許可、概要、担当範囲、写真、公開日、関連サービスをどう入力するか。画像の比率や代替テキストを誰が確認するか。公開後に同じ種類の記事が増えても一覧が崩れないか。見た目と入力方法を一緒に検収します。

既存サイトへ機能を追加する場合は、テーマ、プラグイン、カスタム投稿、フィールド設定、ビルド環境を先に確認します。「似た機能を作る」だけでは、既存の更新データや他ページへの影響を把握できません。変更対象外のページと、既存の編集データをどう保持するかまで依頼書に記してください。

既存環境とアクセス権を安全に受け渡す

既存WordPressの改修では、デザイン資料だけでなく環境情報が必要です。WordPressとPHPの現在値、使用テーマと子テーマ、プラグイン、独自機能、ソース管理の有無、テスト環境、バックアップ方法を一覧にします。保守されていないプラグインや独自実装があれば、調査時間を見積もりと切り離して確認する方法もあります。見えていない既存環境を「問題ない」と約束しないでください。

アクセス権は必要な作業に合わせて付与します。WordPressには役割と権限の仕組みがあり、投稿の編集とテーマ・プラグインの管理では必要な権限が違います。WordPress公式の権限解説を参考に、誰がどの環境へいつまでアクセスするかを決めます。実装担当へ管理者権限が必要な案件もありますが、共有アカウントを無期限に使い回す前提にしない方が引き継ぎやすくなります。

認証情報を通常の原稿フォルダーや公開チケットへ貼り付けないでください。共有方法、担当者、期限、作業終了後の見直しを決めます。テスト環境には本番と同じ個人情報が含まれることがあるため、複製範囲と保存場所も確認します。どのデータを外部へ渡してよいか判断できない場合は、制作会社と発注企業で決めてから作業を始めます。

作業の入口で保存しておきたいのは、現行サイトの表示やデータの復元点、変更対象ファイル、公開URLの一覧です。バックアップがあるという報告だけでは復旧できるとは限りません。誰が復元し、どの変更まで戻るか、公開日に新しい問い合わせや投稿が入った場合にどう扱うかを決めます。

検収は「見た目が近い」から「使える状態」まで分ける

検収を最後にまとめると、軽い表示差と公開を止める不具合が同じ一覧に並びます。着手前に、対象ページ、画面幅、ブラウザー、操作、合格条件、報告方法を決めます。外部実装担当が自分で確認する項目と、制作会社がデザイン・発注条件として判断する項目を分けます。

「表示は合っているが投稿を一件増やすと崩れる」「テストフォームは動くが本番の宛先は未確認」といった問題は、見た目のスクリーンショットだけでは見つかりません。可能ならテスト環境で実際の編集担当に一件登録してもらい、一覧・詳細・通知まで確認します。実メール送信や外部サービスへの連携は、送信先と条件を合意した範囲で試します。確認できない工程は合格とせず、未確認として引き継ぎます。

検収記録には「再現手順」「期待した状態」「実際の状態」「画面幅・環境」「優先度」「修正後の再確認」を一行にします。「崩れている」だけでは修正者が同じ現象を再現しにくいからです。デザイン差を示すなら正本の版と該当フレームも添えます。修正依頼と新しい仕様追加は分けて扱い、当初の合格条件を後から黙って変更しないでください。

仕様変更・追加費用・連絡を記録する

制作途中の変更は珍しくありません。発注企業から新しいフォーム項目やアニメーションが追加された場合、実装担当は影響するページ、工数、テスト、公開日を返し、制作会社が採用・見送り・別フェーズ化を決めます。追加費用の有無は契約条件で決めるもので、この記事で一律の価格や修正回数を示すことはできません。

変更ログは「依頼日」「元の仕様」「変更内容」「変更理由」「影響箇所」「見積・日程への影響」「承認者」「反映結果」で構成します。口頭で決まった内容も短く書き残してください。元のデザイン正本を黙って上書きすると、なぜ実装画面が前回のレビューと違うか説明できなくなります。版を固定し、差分を共有する方が再確認を減らせます。

外部実装担当が顧客と直接話すかも決めます。制作会社が窓口を担う場合、実装担当からの仕様質問がどこへ届き、誰が顧客へ確認し、回答をいつ返すかを明示します。逆に顧客と直接話す必要がある場合は、制作会社の承認、議題、議事メモの共有先を先に決めます。顧客への無断提案や条件の確約は避けます。

「急ぎの修正」という言葉にも注意が必要です。公開停止につながる障害、公開前の文言修正、追加機能では優先順位と必要な担当が異なります。受付時間、緊急連絡、通常の修正日、公開後の保守範囲を見積もりで分ければ、担当者の無理な待機や想定外費用を減らせます。

公開前後の差分、復元点、引き継ぎを残す

テスト環境で合格した状態を、そのまま本番に反映できるとは限りません。本番のテーマやプラグイン、コンテンツ、URL、外部連携がテストと違う場合があります。公開前に、変更ファイル、データ変更、対象ページ、公開日時、停止を伴うか、復元点、公開の最終承認者を一覧にします。公開担当が実装担当とは限らないので、手順だけでなく操作する人と読戻す人を決めます。

本番反映後は、管理画面の保存結果に加えて、公開URLで主要ページ、画像、リンク、スマートフォン表示、フォーム導線、タイトル・説明文・canonical・robotsなどの管理値を確認します。ここに挙げた項目がすべての案件で実装対象になるわけではありません。実際の変更箇所と既存サイトの仕様に合わせて、確認範囲を合意します。問題が出たときは、変更を止め、原因と戻す範囲を判断します。サイト全体のデータベースを安易に巻き戻すと、公開後に届いた問い合わせや他の更新も失われる可能性があります。

納品時には、変更したファイル、テーマ・プラグイン、CMS編集欄、ビルド方法、ライセンス、残課題、バックアップ先、保守窓口を渡します。制作会社側が顧客へ納品するなら、外部実装担当から制作会社へ渡すものと、制作会社から顧客へ渡すものを分けます。実装担当だけが分かる仕組みにしないことが、次の更新や担当変更を助けます。

成果を評価するときも、「予定日に公開した」で終わらせないでください。発注企業が必要な情報を更新できるか、利用者が問題なく閲覧・問い合わせできるか、制作会社が保守を続けられるかを確認します。検索流入や問い合わせの増減は別の観測であり、この実装依頼だけの成果と断定しません。

そのまま使える依頼書の骨子と、Acquaに任せられる工程

最初の依頼は、下の順番に埋めると「分からないこと」が見えます。未確定は空欄にせず、誰がいつ決めるかを書いてください。認証情報や顧客の個人情報を依頼書本文へ貼る必要はありません。

1. 案件の目的：誰のどの行動を助けるサイトか。今回の実装範囲はどこか。
2. 対象：ページとテンプレートの一覧、既存改修か新規構築か、対象外の画面。
3. 正本：デザイン・原稿・画像の場所と版。仮資料の決定者・期限。
4. 動作：PC/SP・境界幅、操作状態、フォーム、CMS編集欄、一覧条件。
5. 環境：WordPressの現状、テーマ、プラグイン、ソース管理、テスト・本番の権限。
6. 分担：制作会社、実装担当、発注企業の確認・承認・公開・連絡窓口。
7. 日程と費用：質問締切、テスト提出、検収、本番予定、変更時の扱い。
8. 検収・引き継ぎ：合格条件、テスト方法、差分、復元点、納品物、残課題。

一度に全部埋められないなら「ページ一覧とデザインは確定。フォーム送信先と事例の掲載許可は顧客確認中。実装可否の判断に必要な質問を先にください」という伝え方で構いません。実装担当は未確定箇所を見て、先に進められる作業と止めるべき作業を返せます。仕様を隠したまま概算だけを比較するより、見積もりの前提がそろいます。

Acquaは制作会社・広告会社から、コーディング、WordPress実装、既存修正、公開補助、保守OEMなど、案件に応じた工程を相談できます。この記事の確認表に挙げた作業をすべて一括で引き受けるという意味ではありません。支給物、実装範囲、公開担当、検収条件を確認してから対応可否と見積もりを整理します。自社内で進める場合はこの依頼書を社内レビューに使ってください。外部の実装担当が必要な場合は、制作会社向けの相談窓口から概要を伝えられます。

よくある質問

FigmaのURLとPC/SPのデザインだけで見積もれますか。 概算の相談はできますが、CMS編集範囲、動作、既存環境、検収・公開の担当が不明だと前提が変わります。未確定項目を明記して相談してください。

既存WordPressの管理者権限を最初から渡す必要がありますか。 必要な調査や作業に合わせて権限を決めます。現状確認は画面共有や限定的な情報から始められる場合もあります。共有方法と期間は案件ごとに確認してください。

公開まで実装担当へ任せられますか。 権限、バックアップ、公開日時、戻し方、最終承認者が決まれば依頼できる場合があります。テスト環境の納品だけか本番反映までかを見積書で区別してください。

検収後の細かな修正はどこまで含まれますか。 合意した仕様に対する不備の修正と、新しい仕様の追加を分け、対象・回数・期限・費用を契約前に確認します。ここで一律の条件は定めません。

記事内のWordPressの仕組みは2026年9月27日に公式資料と照合しました。個々のサイトの構成や契約条件は、実環境と見積書で確認してください。