制作会社やデザイン会社が企業サイトのリニューアルを受注し、デザインと顧客対応は社内で担当する。一方、WordPress の実装は、社外のエンジニアや制作パートナーへ依頼する。
このような制作体制は、決して珍しいものではありません。案件ごとに必要な専門性や社内の稼働状況が違うことを考えると、外部パートナーと協力することは、無理のない選択肢の1つだと僕は考えています。
ただし、「デザインができたので WordPress 化の見積もりをお願いします」と伝えるだけでは、正確な金額やスケジュールを出すのが難しい場合があります。
WordPress 制作では、同じデザインであっても、顧客が更新する範囲、使用するテーマ、ブロックエディターの使い方、データ移行、公開作業、納品物、公開後の保守などによって、必要な設計と作業が変わるためです。
この記事では、WordPress 制作の一部または全部を外部パートナーへ依頼するときに、発注前から公開後まで確認したい項目を整理します。
大切なのは、依頼する側がすべての技術仕様を決めてから相談することではありません。すでに決まっていること、まだ決まっていないこと、外部パートナーから提案してほしいことを分け、双方が同じ前提で話せるようにすることです。
「WordPress 化」に含まれる作業は、依頼先によって異なる
「WordPress 化」や「WordPress 実装」という言葉が指す範囲は、制作会社や制作者によって異なります。
たとえば、次の作業がすべて含まれているとは限りません。
- HTML、CSS、JavaScript による静的コーディング
- WordPress の技術設計
- テーマの実装
- 独自ブロックやプラグインの開発
- 投稿タイプやカスタムフィールドの設計
- フォームの設置と送信確認
- 原稿や画像の登録
- 既存サイトからのデータ移行
- ステージング環境の用意
- 本番環境への公開
- 操作マニュアルの作成
- 公開後の保守
発注側は「公開できる状態までお願いしたつもり」でも、実装側は「テーマファイルを納品するところまで」と考えているかもしれません。
このすれ違いは、どちらかの能力や配慮が足りないから起こるとは限りません。同じ言葉から想定している作業範囲が違うことが、原因になる場合も多いのです。
経済産業省の情報システム・モデル取引・契約書でも、ユーザー企業とベンダー企業の役割分担や責任分担を、契約や文書によって具体化する考え方が示されています。WordPress 制作と大規模なシステム開発では規模が異なりますが、「誰が何を担当するのかを確認できる形で残す」という基本的な考え方は参考になります。
確認事項を3つに分けて整理する
依頼前の確認事項は、次の3つに分けると整理しやすくなります。
| 分類 | 意味 | 例 |
|---|---|---|
| 決定済み | 発注側または顧客側ですでに決まっていること | 公開日、ページ構成、支給するデザイン |
| 未決定 | 現時点では決まっておらず、今後の確認が必要なこと | 原稿支給日、既存記事の移行件数 |
| 提案してほしいこと | 技術的な判断を外部パートナーと相談したいこと | テーマ方式、編集方法、プラグイン選定 |
未決定事項があること自体は、問題ではありません。
分からない部分を無理に決めたり、決まったように見せたりするよりも、「ここは未決定です」「この部分は提案してほしいです」と共有した方が、見積もりの前提をそろえやすくなります。
個人的には、外部パートナーとの相性を見るうえでも、未決定事項への向き合い方は大切だと思っています。すぐに金額だけを出すのではなく、判断に必要な情報や選択肢を説明してくれるかどうかも、継続して協力できる相手かを考える材料になります。
1. 案件の目的と、WordPress を使う理由
最初に共有したいのは、ページ数や希望納期だけではなく、サイトを作る目的です。
- 誰に見てもらうサイトなのか
- 公開後にどのような成果を期待しているのか
- 誰が、どのくらいの頻度で更新するのか
- 現在のサイトで何に困っているのか
- WordPress を使いたい理由は何か
WordPress を使うことが顧客から指定されている案件もあれば、制作会社側の提案で選ぶ案件もあるでしょう。
更新担当者がいない、更新頻度が低い、数ページの情報を掲載できれば良いといった条件では、WordPress 以外の方法が適している可能性もあります。反対に、お知らせや事例を継続的に更新したい、社内でページを増やしたい、既存の WordPress データを引き継ぎたいといった要件では、WordPress が合う場合があります。
外部パートナーへ相談する段階で、WordPress の採用自体を見直してはいけないわけではありません。 目的と運用体制を共有したうえで、適した仕組みを一緒に検討できる余地を残しておきたいところです。
2. サイトの規模と必要な機能
「全10ページ」と伝えるだけでは、実装規模を判断できない場合があります。
固定ページが10ページあり、すべて同じレイアウトで文章と画像だけを差し替えるサイトと、10種類の異なるテンプレートや機能が必要なサイトでは、設計や確認にかかる時間が変わるためです。
少なくとも、次の内容を整理します。
- 固定ページ数と、異なるレイアウトの種類
- 投稿、お知らせ、事例などのコンテンツの種類
- 一覧、絞り込み、サイト内検索の有無
- 問い合わせ、予約、資料請求などのフォーム
- 多言語、会員、決済などの機能
- Google Analytics などの計測ツール
- 外部サービスとの連携
- 既存サイトから移行する記事、画像、ユーザー、設定
- URL 変更に伴うリダイレクト
データ移行がある場合は、件数だけでなく、移行後にどこまで整えるかも確認が必要です。古い HTML の調整、リンク切れの修正、画像の差し替え、アイキャッチ画像の設定まで含めるのかによって、作業量は変わります。
3. 社内と社外の役割分担
次に、制作工程ごとの担当者を決めます。
- 顧客との窓口
- 要件整理と仕様決定
- サイトマップやワイヤーフレームの作成
- デザイン
- 静的コーディング
- WordPress の技術設計
- テーマやプラグインの実装
- 原稿と画像の登録
- 制作会社による確認
- 顧客による確認
- 本番公開
- 公開後の保守
特に確認したいのが、外部パートナーへ「決められた仕様の実装」を依頼するのか、「技術設計を含む実装」を依頼するのかという違いです。
ブロックテーマかクラシックテーマか、投稿と固定ページをどう使い分けるか、どこをブロックやカスタムフィールドで編集できるようにするか。このような判断まで依頼する場合は、単純なコーディングだけでなく、要件整理や技術ディレクションの時間も必要になります。
また、外部パートナーが顧客と直接連絡を取るのか、制作会社を窓口にするのかも決めておきます。顧客から外部パートナーへ直接変更依頼が届く状態では、制作会社が把握していない追加作業が発生する可能性があります。
仕様を決める人、作る人、確認する人を分けて考えることが、責任の押し付け合いを防ぐ助けになります。
4. 顧客が更新する範囲と、編集画面の設計
「顧客が更新できるようにする」という要件も、もう少し具体的に分ける必要があります。
- 文章を変更する
- 画像を差し替える
- お知らせや事例を追加する
- セクションを並べ替える
- セクションを追加、削除する
- 新しい固定ページを作る
- メニューや共通パーツを変更する
- 色、余白、文字サイズを変更する
すべてを自由に変更できることが、必ずしも更新しやすさにつながるとは限りません。操作の自由度が高すぎると、意図せずレイアウトが崩れたり、サイト内の表現がばらばらになったりすることもあります。
WordPress には、ブロックの移動や削除を制限する Block Locking API や、レイアウトを保ったまま文章や画像を編集しやすくするコンテンツのみの編集機能があります。
ただし、機能を使えば自動的に使いやすくなるわけではありません。顧客が実際に担当する作業を確認し、必要な自由度と誤操作を防ぐ制限のバランスを考えることが大切です。
5. WordPress の構成方針
技術方式は、名称だけで優劣を決めず、選択理由を確認します。
- 独自テーマか、既存テーマか
- ブロックテーマか、クラシックテーマか
- コアブロック、ブロックパターン、独自ブロックをどう使うか
- カスタム投稿タイプやカスタムフィールドが必要か
- 独自機能をテーマとプラグインのどちらに持たせるか
- 使用するプラグインと、その選定理由
- 将来、誰がどのように改修するのか
WordPress の Theme Handbookでは、ブロックテーマとクラシックテーマの両方が説明されています。ブロックテーマではサイトエディターからサイト全体を編集できる一方、クラシックテーマは主に PHP、JavaScript、CSS を用いて構成します。
実務では、新しい方式だから採用する、使い慣れているから選ぶ、という理由だけではなく、顧客にどこまで編集してもらうのか、制作会社が今後も改修するのか、既存の社内資産や開発ルールがあるのかといった条件も含めて判断したいところです。
有料テーマや有料プラグインを使う場合は、次の点も確認します。
- 契約者とライセンス所有者
- 更新費用を負担する人
- 納品後もアップデートを受けられるか
- 外部パートナーとの契約終了後も利用できるか
- 提供終了や互換性の問題が起きたときの対応
外部パートナーが所有するライセンスで実装できたとしても、納品後も同じ条件で使い続けられるとは限りません。導入時に使えるかだけでなく、運用中に誰が維持するかまで確認します。
6. デザイン、原稿、素材の支給条件
実装を始める前に、支給するデータと完成予定日を共有します。
- Figma などのデザインデータ
- パソコン版とスマートフォン版のデザイン
- ホバー、フォーカス、メニュー開閉などの状態
- フォームの入力、確認、完了、エラー表示
- ロゴ、写真、イラスト、アイコン
- Web フォント
- 原稿、ページ一覧、サイトマップ
- 既存サイトのデータ
- アクセス解析や外部サービスの設定情報
- 素材の利用条件やライセンス
すべての画面を完全に作り込んでから相談しなければならない、という意味ではありません。実装側で補う部分があるなら、その範囲を見積もりに含めるために共有します。
また、実装開始後にデザインや原稿が変更される可能性がある場合は、いつまでの変更を当初見積もりに含めるのか、構造へ影響する変更は追加費用や納期変更の対象になるのかを決めておきます。
7. 対応環境と品質の基準
「主要ブラウザに対応」「アクセシビリティに配慮」「表示速度を改善」といった表現だけでは、完成条件が曖昧です。
次のように、確認する環境と範囲を具体化します。
- 対象とするブラウザ、端末、画面幅
- WordPress と PHP の想定バージョン
- 利用するサーバーの条件
- レスポンシブ表示の確認範囲
- キーボード操作やフォーカス表示
- 見出し構造、代替テキスト、フォームラベル
- フォームの送信と通知メール
- 管理画面での編集操作
- JavaScript のエラーや PHP の警告
- 表示速度を測るページ、環境、指標
- コーディング規約やレビュー方法
WordPress 公式の Accessibility Coding Standardsでは、WordPress コア、WordPress.org のサイト、公式プラグインなど、WordPress の公式エコシステムへ統合されるコードに WCAG 2.2 レベル AA への適合が期待されています。
これは、すべての民間サイトが自動的に同じ適合表明をしなければならない、という意味ではありません。案件で目指す基準と、実際に確認する内容を発注側と実装側で相談するための参考にすると良いでしょう。
品質に関する数値目標を置く場合も、測定条件をそろえます。外部スクリプト、サーバー、計測時期によって結果が変わるものを、前提なしに保証条件へ入れると判断が難しくなります。
8. 見積もり、修正、追加作業の扱い
見積書では、含まれる作業だけでなく、含まれない作業も確認します。
- 作業範囲と成果物
- 見積もりに含まれない作業
- 発注側が用意するもの
- 見積もりの前提となる仕様
- 修正の受付方法と期間
- 追加費用が発生する条件
- 再見積もりを行うタイミング
- キャンセルや延期の扱い
「修正2回まで」のように回数だけを決めても、何を修正と数えるのかで認識が分かれる場合があります。
少なくとも、次の違いを分けて考えます。
- 実装ミスや当初仕様との差異
- デザインとの見た目の差異
- 決定済み仕様の調整
- 実装開始後のデザイン変更
- 顧客からの新しい要望
- ページや機能の追加
金額を比較するときは、総額だけでなく、前提条件と含まれる作業を並べて確認することが大切です。安い見積もりが悪いとは限りません。コンテンツ登録、公開、マニュアル、保守などが含まれていないために、金額が抑えられている可能性もあります。
9. スケジュールと連絡方法
公開日だけでなく、制作会社や顧客が情報を用意する期限も設定します。
- 着手予定日
- デザイン、原稿、素材の支給日
- 技術仕様を決める期限
- 初回確認日
- 制作会社と顧客の確認期間
- 修正期間
- 本番公開日
- 支給や確認が遅れた場合の扱い
あわせて、連絡手段、窓口、定例会議の有無、質問への回答方法、仕様変更を承認する人を決めます。
チャットで素早く相談できることは便利ですが、重要な決定が複数の場所へ分散すると、あとから経緯を追えなくなります。仕様変更、追加費用、公開判断などは、議事録や課題管理ツールなど、双方が確認できる場所へ残す運用を決めておくと安心です。
10. 検収と「完成」の定義
実装完了、納品、検収、本番公開、公開後確認は、それぞれ別の段階です。
たとえば、次のような流れを想定できます。
- 外部パートナーが実装を完了する
- 制作会社が確認する
- 顧客が確認する
- 指摘事項を修正する
- 検収を完了する
- 本番環境へ公開する
- 公開後の表示と機能を確認する
案件によって順番は変わりますが、次の点は決めておきたいところです。
- 誰が最終確認を行うのか
- 何をもって実装完了、検収完了とするのか
- 確認期間は何営業日か
- 指摘事項をどの方法で提出するのか
- 不具合と仕様変更をどう区別するのか
- 公開後に見つかった初期不具合へ、いつまで対応するのか
「完成したと思っていたのに、顧客確認が始まってから大きな仕様変更が入った」という状況を避けるためにも、確認者と確認期間を制作スケジュールへ含めます。
11. 開発環境と公開作業
公開作業は、本番サーバーへファイルをアップロードするだけではありません。
- ローカル、開発、ステージング環境を誰が用意するか
- 本番サーバーへ誰がアクセスするか
- 公開前のバックアップを誰が取得するか
- DNS やドメインの変更があるか
- 独自ドメインのメールへ影響しないか
- 既存 URL のリダイレクトを誰が設定するか
- 公開日時と立ち会いの範囲
- 問題発生時に元へ戻す方法
- 公開後に確認するページと機能
- 旧環境やステージング環境をいつ停止するか
サーバーや DNS の管理画面は、顧客や制作会社が契約したアカウントを使い、外部パートナーには作業に必要な権限だけを渡す形が管理しやすいでしょう。
パスワードをチャットへそのまま貼り付けるのではなく、安全な共有方法も確認します。作業終了後には、不要になったアカウントや権限を削除できるよう、付与した権限を記録しておきます。
12. 納品物と引き継ぎ資料
本番サイトが表示されれば納品完了、という案件もあれば、別の担当者が改修できる状態まで整える案件もあります。
必要に応じて、次の納品物を確認します。
- テーマと独自プラグイン
- Git リポジトリ
- ビルド前のソースコード
package.jsonとロックファイル- ビルド、開発、公開の手順
- データベースとメディアファイル
- 使用テーマ、プラグイン、外部サービスの一覧
- サイト固有の設定一覧
- テスト結果
- 操作マニュアル
- 保守や改修に必要な引き継ぎ資料
Sass、TypeScript、React、@wordpress/scripts などを使用している場合、ビルド済みファイルだけでは後任の担当者が改修しにくいことがあります。
今の外部パートナーだけが扱える状態にしないことは、顧客と制作会社の双方にとって大切です。将来の改修主体を想定し、何を残せば別の担当者が状況を理解できるかを考えます。
13. 権利、ライセンス、秘密保持、実績公開
制作物と第三者サービスの扱いも、発注前に確認します。
- 独自テーマやプラグインの利用条件
- ソースコードの納品範囲
- 他案件への再利用の扱い
- 写真、フォント、テーマ、プラグインなどの第三者ライセンス
- 秘密保持の対象
- ポートフォリオや SNS での実績公開
- 公開前情報を扱う範囲
- 契約終了時のデータ返却と権限削除
権利や契約については、WordPress のライセンスや、使用する第三者素材の条件も関係します。一律の文言で判断せず、案件の契約内容に応じて、必要であれば法律の専門家へ相談してください。
フリーランス法では、従業員を使用しない個人や、代表者以外に役員がおらず従業員も使用しない法人などを、法律上のフリーランスとして定めています。該当する外部パートナーへ業務委託する場合は、取引条件を直ちに書面または電磁的方法 (メール、SNS のメッセージなど) で明示する必要があります。
公正取引委員会の案内では、発注者とフリーランスの名称、業務委託をした日、業務内容、期日、場所、報酬額、支払期日などの明示事項が説明されています。
具体的な適用関係は、発注者と受注者の事業形態や契約内容によって異なります。この記事は法律上の判断を行うものではないため、自社の取引に当てはまるか分からない場合は、公的な相談窓口や専門家へ確認してください。
14. 公開後の保守と責任範囲
公開時点で問題なく動くように実装することと、その後も状態を維持することは、分けて考える必要があります。
- 初期不具合へ対応する期間
- WordPress 本体、テーマ、プラグインの更新
- PHP やサーバー環境の変更
- バックアップと復元確認
- 稼働監視やフォーム送信確認
- 障害発生時の連絡方法と対応時間
- セキュリティ上の問題が見つかったときの対応
- 機能追加や改修
- 制作会社、顧客、他社が変更したあとの責任範囲
WordPress の公式セキュリティドキュメントでも、セキュリティは計画、監視、定期的なメンテナンスを必要とする継続的な取り組みであり、リスクをゼロにするのではなく、軽減と復旧を考えるものとして説明されています。
そのため、「安全なサイトを納品する」という表現だけで、公開後の更新や監視まで含まれると考えるのは危険です。保守を別契約にする場合も、公開後に誰が何を担当するのかを、公開前に決めておきます。
外部パートナーを比較するときに見たいこと
実績数や見積金額は、判断材料の1つです。しかし、それだけでは今回の案件に合うかどうかを判断できません。
可能であれば、次の点も確認します。
- 類似案件で本人が担当した範囲
- どのような技術方針を選び、その理由を説明できるか
- 顧客の編集画面や公開後の運用まで考えているか
- 見積もりの前提と除外事項が分かりやすいか
- 未決定事項への選択肢を示してくれるか
- 問題や遅延が起きたときの連絡方法
- 納品後に別の担当者へ引き継げるか
ブロックテーマを使えるから優れている、実績が多いから安心、見積もりが安いから危険、と一律に判断するのではなく、今回の案件に対して、選択理由と作業範囲を具体的に説明できるかを見たいところです。
依頼内容は、ここまで変えられる
最後に、見積もり依頼の伝え方を比べてみます。
整理前
デザインは当社で作成します。全10ページ程度の WordPress 化と公開をお願いします。
整理後
企業サイトのリニューアル案件です。顧客対応、ディレクション、デザインは当社が担当します。外部パートナーには、WordPress の技術設計、独自テーマの実装、ステージング環境への反映、本番公開を依頼したいと考えています。
固定ページは8ページで、投稿は「お知らせ」と「事例」の2種類です。顧客は公開後、お知らせと事例の追加、固定ページ内の文章と画像の変更を行います。レイアウト変更は想定していません。
テーマ方式は未決定です。顧客の更新しやすさ、今後の保守、当社での改修を踏まえて提案してください。
Figma のデザインは○月○日、原稿は○月○日に支給予定です。フォーム、既存記事の移行、URL のリダイレクト、アクセス解析の設定を含めたいと考えています。
対応ブラウザ、アクセシビリティ、表示速度の確認基準は、相談して決めたいです。公開後の保守は、別契約として見積もりをお願いします。
後者も、すべての仕様が決まっているわけではありません。それでも、担当範囲と未決定事項が見えるため、外部パートナーは質問や提案をしやすくなります。
WordPress 制作を依頼する前のチェックリスト
案件の前提
- サイトの目的と想定する利用者を共有できる
- WordPress を使う理由を説明できる
- ページ、投稿、機能、データ移行の規模を整理している
- 決定済み、未決定、提案してほしい事項を分けている
役割と技術方針
- 社内、顧客、外部パートナーの担当範囲を決めている
- 技術設計を含めて依頼するかを明確にしている
- 顧客が更新する内容と自由度を整理している
- テーマ、ブロック、投稿、プラグインの方針を相談している
- 有料製品の契約者、更新費用、契約終了後の扱いを確認している
支給物と進行
- デザイン、原稿、画像などの支給物と予定日を共有している
- 実装開始後の変更ルールを決めている
- 窓口、連絡方法、仕様決定者を決めている
- 発注側と顧客の確認期間もスケジュールへ含めている
品質、見積もり、検収
- 対応環境とテスト範囲を決めている
- 見積もりに含まれる作業と含まれない作業を確認している
- 不具合、修正、仕様変更、追加作業を区別している
- 検収担当者、確認期間、完了条件を決めている
公開、納品、保守
- 公開担当、バックアップ、切り戻し方法を決めている
- サーバー、ドメイン、DNS、メールへの影響を確認している
- 納品するソースコードと引き継ぎ資料を決めている
- アカウントと権限の付与、削除方法を決めている
- 権利、ライセンス、秘密保持、実績公開を確認している
- 公開後の初期不具合対応と保守範囲を決めている
すべて決まっていなくても、相談できる状態を作る
外部パートナーへ依頼するときに、発注側だけですべての技術仕様を決める必要はありません。WordPress に詳しい担当者が社内にいないからこそ、設計段階から協力してほしい案件もあるでしょう。
まず自分たちで整理できること
最初から技術的な答えを用意する必要はありません。まずは、次の情報を分かる範囲で書き出してみてください。
- サイトの目的と、現在困っていること
- 顧客が公開後に更新したい内容
- 社内で担当できる工程
- ページ、投稿、フォーム、データ移行のおおよその規模
- 支給できるデザイン、原稿、画像、既存資料
- 希望する公開時期と、決まっている社内日程
- 未決定のことと、提案してほしいこと
この段階では、正確な専門用語を使えなくても問題ありません。現在分かっていることと、分からないことを区別できれば、最初の相談に必要な土台を作れます。
早めに外部パートナーへ相談したい状態
次のような状態であれば、仕様を固めてから見積もりだけを依頼するのではなく、要件整理の段階から WordPress に詳しい制作者へ相談した方が良いでしょう。
- 顧客の希望を、WordPress の編集方法へ落とし込めない
- テーマ、ブロック、カスタムフィールドの使い分けを判断できない
- 既存サイトから何を移行できるか分からない
- サーバー、DNS、メールを含む公開作業に不安がある
- 公開後の保守担当が決まっていない
- 見積もりを比較しても、含まれる作業の違いが分からない
判断できない部分を相談事項として共有することも、依頼前の準備の1つです。
オレインデザインの制作会社向け技術支援
オレインデザインでは、制作会社・デザイン会社からの WordPress 実装や技術支援を承っています。デザインデータに沿った実装だけでなく、ブロックエディターをどこまで使うか、顧客が更新する範囲をどう設計するかといった技術方針の検討から参加できます。
要件がすべて決まっている必要はありません。決まっていること、未決定のこと、提案が必要なことを整理しながら、無理のない依頼範囲を一緒に検討します。WordPress 実装の一部、公開後の保守、既存案件の引き継ぎについても、制作会社・デザイン会社向け技術支援からご相談ください。
外部パートナーへ依頼することは、作業を丸投げすることではありません。社内と社外が、それぞれの得意な部分を担当し、判断が必要なところを一緒に考えられる制作体制を作ることです。
この記事が、発注後のすれ違いを減らし、無理なく協力できるパートナーシップを考える参考になれば嬉しいです。
