Web制作の依頼手順｜発注後のキックオフから納品まで

Web制作会社へ依頼する会社を決めても、プロジェクトが自動で進むわけではありません。目的、担当者、原稿、デザイン確認、変更依頼、公開判定の決め方が曖昧だと、制作会社から質問が来るたびに社内調整が止まり、納期と費用の見通しが崩れます。

発注後に大切なのは、依頼者と制作会社が同じ「完成」を見られる状態を作ることです。この記事では、依頼書、キックオフ、要件と設計、制作、変更管理、受入テスト、公開、引渡しを、次へ進むための合意ゲートとして整理します。制作会社の比較や選び方はホームページ制作会社の選び方ガイドへ分け、本記事は発注先が決まった後の実務に限定します。

Web制作の依頼は7つの合意ゲートで進める

工程表の日付だけでは、次に進んでよいか判断できません。各工程に成果物、確認者、完了条件を置きます。全員が細部を承認するのではなく、内容、ブランド、法務、技術、公開を誰が決めるかを分けます。

ゲート	主な成果物	依頼者が決めること	次へ進む条件
1 依頼書	目的、対象、範囲、除外、予算、希望時期	何を成功とするか	依頼範囲と見積前提が一致
2 キックオフ	体制、連絡、会議、承認、課題台帳	責任者と承認者	誰がいつ決めるか明確
3 要件・設計	サイト構成、機能、画面、原稿、移行、受入条件	必要・不要の境界	制作対象が確定
4 制作	原稿、画像、デザイン、実装、レビュー記録	段階ごとの内容承認	未決事項が見える
5 変更管理	変更票、影響、追加費用、納期、承認	変更するか見送るか	口頭依頼を残さない
6 受入・公開	テスト結果、残課題、バックアップ、公開・復元手順	公開可否	重大不具合0、戻せる状態
7 引渡し	データ、権限、ライセンス、マニュアル、変更履歴	受領と保管担当	運用を継続できる

ゲートは作業を遅くするためではありません。未確定のまま先へ進み、後工程で大きく戻ることを防ぐための短い確認です。小規模サイトなら、依頼書とキックオフ、要件と設計を同じ会議で扱えます。ただし、何を合意したかは必ず残します。

合意の記録には、決定日、決定内容、理由、判断に使った資料、承認者、影響するページや工程を残します。後から担当者が変わっても「なぜこの仕様になったか」を説明できるため、過去の議論を繰り返さずに済みます。未決事項は決定済みと混ぜず、選択肢、確認先、担当、期限を付けます。期限までに決まらない場合は、制作を止めるのか、仮置きで進めるのか、対象外へ移すのかも明記します。会議後は決定事項と宿題だけを短く共有し、認識違いがあれば次の制作に入る前に修正します。最新版の記録場所も全員で統一します。

依頼書は1ページで目的と境界をそろえる

発注書や契約書とは別に、プロジェクトの判断基準を一枚へまとめます。資料を厚くするより、関係者が同じ言葉で説明できることが重要です。最低限、目的、対象者、優先行動、対象ページ、必要機能、社内支給物、対象外、公開希望、予算条件、成果指標を記載します。

目的は「作ること」ではなく公開後の変化で書く

「ホームページを新しくする」だけでは、デザイン、文章、機能の優先順位を決められません。「営業前の説明不足を減らす」「採用候補者が仕事内容を判断できる」「古い会社情報をなくす」のように、誰の何が変わるかを書きます。問い合わせ数などの数値だけでなく、営業で同じ質問が減る、更新担当が自社で直せるといった運用上の変化も対象にできます。

対象外を明記して期待のずれを防ぐ

ロゴ変更、写真撮影、原稿作成、翻訳、サーバー移行、メール設定、広告運用、公開後の記事制作など、今回は含めないものも書きます。後から必要になった場合は変更として検討します。「当然含まれると思った」を減らせるため、対象外は否定ではなく将来判断の保留欄です。

キックオフで責任者と連絡ルールを決める

キックオフの目的は挨拶ではなく、意思決定の経路を作ることです。依頼者側のプロジェクト責任者、内容確認者、ブランド・法務確認者、技術担当、最終公開承認者を確認します。制作会社側も、窓口、ディレクター、デザイナー、実装、品質確認の担当を示します。

一つの課題台帳と一つの正式窓口を使う

メール、チャット、会議、口頭で別々に依頼すると、最新版が分からなくなります。質問、回答、決定、保留、担当、期限を一つの課題台帳へ集めます。チャットで決まったことも、台帳へ転記して正式記録にします。制作会社への指示は窓口を通し、部署ごとに相反する依頼を直接送らないようにします。

承認期限と不在時の代理を決める

制作スケジュールは、作る時間だけでなく依頼者が確認する時間で決まります。原稿3営業日、デザイン5営業日など標準確認日数を置き、承認者が不在のときの代理を決めます。期限までに回答がないことを自動承認にはせず、どの工程が止まるかを可視化します。

要件と受入条件を同時に決める

「機能を作る」と「完成したと判断する」は対です。問い合わせフォームなら、項目、必須条件、確認画面、自動返信、通知先、エラー表示、保存の有無、計測、個人情報の扱いを決め、どのテストが通れば受け入れるかまで書きます。要件だけ先に増やし、最後に品質を相談すると検証時間が足りなくなります。

要件は読者・運用・技術の3面で確認する

読者：誰が、どの端末で、何を理解し、どの行動へ進むか。
運用：誰が更新し、承認し、古い情報を見つけ、障害時に連絡するか。
技術：CMS、外部連携、性能、セキュリティ、アクセシビリティ、計測、バックアップをどう満たすか。

要件定義そのものの失敗原因や成果物を深く確認したい場合は、Webプロジェクトでの要件定義の失敗原因へ役割を分けています。本記事では、その要件を制作工程で合意し続ける方法を扱います。

アクセシビリティは公開前の追加検査にしない

デジタル庁のウェブアクセシビリティ導入ガイドブックは、発注・受託業務で知っておくべき点やスマートフォン対応を含めて説明しています。対象とする基準、キーボード操作、見出し構造、代替テキスト、色だけに頼らない表現、拡大表示などを設計・原稿・実装・受入の各段階へ入れます。

原稿と素材はページ台帳で管理する

制作が止まりやすいのは、誰がどの原稿を用意するか曖昧なときです。サイトマップとは別にページ台帳を作り、旧URL、新URL、ページ名、目的、主担当、原稿状態、画像状態、確認者、公開可否を持たせます。リニューアルなら、残す、統合する、書き直す、削除するを一件ずつ決めます。

支給原稿も制作会社原稿も責任者を一人にする

複数部署が同じ原稿へ別々に修正を入れると、正本が分かりません。ページごとに内容責任者を一人置き、法務や専門担当の指摘をまとめて返します。制作会社が書く場合も、事実確認、表現確認、最終承認は依頼者が行います。確認コメントには「好み」ではなく、対象読者、事実、ルール、目的のどれに基づくかを添えます。

画像の権利と掲載条件を台帳へ残す

写真、イラスト、アイコン、人物、顧客ロゴ、地図、画面キャプチャは、出所、利用許諾、掲載期限、クレジット、加工可否を確認します。社員写真でも退職後の扱いを決めます。生成画像を使う場合は生成元、用途、編集内容を残し、実在人物・企業・商品を誤認させないようにします。

デザインレビューは段階ごとに見る範囲を変える

最初のデザイン確認で文章の一字一句、機能、スマホ表示まで同時に議論すると、何が確定したか分かりません。構造、視覚、実装の順に確認します。

段階	主に確認すること	まだ確定しないこと	承認記録
ワイヤー	情報の順番、ページ間導線、必要部品	色、細かな写真、装飾	構造承認
ビジュアル	ブランド、文字、色、余白、代表画面	全ページの実装差異	デザイン承認
プロトタイプ	主要操作、スマホ、フォーム、動き	最終データ・全端末	操作承認
テスト環境	実データ、リンク、表示、機能、計測	本番環境固有の設定	受入候補

承認後に前段へ戻る変更は、修正回数ではなく変更要求として扱います。依頼者が気軽に頼みにくくするためではなく、納期と費用への影響を判断できるようにするためです。

変更要求は影響を見てから承認する

制作中に新しい希望が出ること自体は失敗ではありません。市場、法令、社内方針、利用者の反応によって必要な変更もあります。問題は、口頭で追加し、誰も総量を把握しないことです。

IPAの変更管理プロセス資料は、変更要求がプロジェクト計画、費用、品質、予定へ与える影響を示して合意する考え方を説明しています。Web制作でも、変更内容、理由、影響ページ、追加作業、費用、納期、代替案、承認者を変更票へ残します。

変更票は6項目で十分

何を変えたいか
なぜ必要か
影響するページ・機能・データは何か
費用・納期・品質・運用への影響は何か
代替案や次期対応はあるか
誰がいつ承認したか

小さな文言修正でも、共通部品や規約、計測、翻訳へ波及する場合があります。反対に、影響が小さく契約内なら、制作会社が簡易承認で処理できる基準を決めておきます。

受入テストは依頼者の業務で確認する

制作会社のテストが合格していても、依頼者が実際の利用方法で確認する受入テストが必要です。採用担当が求人を更新できるか、営業が問い合わせ通知を受け取れるか、広報が記事を下書き・承認・公開できるかなど、日常業務のシナリオで試します。

領域	確認例	合格条件	証拠
内容	会社情報、料金、連絡先、表記	承認済み正本と一致	ページ台帳と画面
表示	PC、タブレット、スマホ、文字拡大	欠け・重なり・横はみ出しなし	幅別スクリーンショット
操作	ナビ、検索、ボタン、キーボード	主要行動を完了できる	手順と結果
フォーム	入力、エラー、送信、通知、自動返信	個人情報を安全に受け渡せる	テスト送信記録
SEO	title、canonical、robots、構造化データ	設計値と一致	HTML・検査結果
計測	閲覧、クリック、送信完了	同意条件を守りイベント受信	デバッグ記録
運用	下書き、承認、更新、復元	担当者が手順を再現できる	操作記録

不具合は重要度を分けます。個人情報漏えい、送信不能、主要ページ表示不能、公開禁止情報の露出は公開停止です。軽微な余白や表現は、公開後対応に回すか依頼者が判断します。残課題を0に見せるのではなく、担当と期限を付けて公開判断に含めます。

公開計画にはバックアップと復元を入れる

公開はファイルを置く一回の操作ではありません。公開前スナップショット、変更対象、作業順、担当、監視項目、異常条件、戻し方、連絡先を一枚へまとめます。WordPress公式のバックアップ解説が示すように、一般的なWordPressサイトを完全に戻すにはファイルとデータベースの双方が必要です。取得しただけでなく、復元に使えることを確認します。

URLが変わる案件だけ移行表を作る

リニューアルでURLが変わる場合は、旧URLと新URLを一対一で対応させます。Google Search Centralのサイト移行ガイドは、URL対応表、永続リダイレクト、canonical、内部リンク、サイトマップ、Search Consoleでの監視を案内しています。無関係な旧ページをすべてトップへ転送せず、内容が対応する移行先を決めます。

URLを変えない制作では、この工程を形式的に増やす必要はありません。ただし、公開前後のHTTP状態、canonical、robots、主要リンク、フォーム、計測、サイトマップは確認します。大きな変更を一度に重ねる場合は、切り分け可能な順番へ分けます。

個人データへ触れる委託は権限と監督を決める

問い合わせ、会員、採用応募、購入などの個人データをテストや移行で扱う場合、制作会社へ管理者権限を渡すだけでは不十分です。個人情報保護委員会の委託先管理資料は、委託先の選定、契約、取扱状況の把握を示しています。

本番データを使う必要があるか。匿名・ダミーデータで代替できるか。
誰に、どの環境・期間・権限を与えるか。
再委託や外部クラウドの利用をどう確認するか。
ログ、持ち出し、保存、削除、事故報告をどう扱うか。
公開・引渡し後に不要なアカウントと鍵を停止したか。

依頼者側も任せきりにせず、契約した安全管理が実行されているかを確認します。フォームの送信試験では実在顧客の情報を使わず、テスト用データを使います。

引渡しはデータ・権限・運用を三つに分ける

公開できたことと、依頼者がサイトを保有・運用できることは別です。契約終了や担当変更のときにも困らないよう、引渡し一覧を作ります。

区分	受領するもの	確認すること
データ	ソース、CMS、原稿、画像、動画、設定、バックアップ	形式、最新版、復元方法、保管先
権利	ドメイン、素材ライセンス、フォント、プラグイン、外部サービス	契約名義、利用範囲、更新費、譲渡可否
権限	サーバー、DNS、CMS、解析、Search Console、メール	所有者、管理者、二要素認証、不要アカウント停止
運用	更新手順、承認手順、障害連絡、保守範囲	担当者が再現できるか
証跡	要件、設計、テスト、変更履歴、残課題	どの状態を納品したか追跡できるか

データの所有や契約名義が不明な場合は、公開直前まで待たず早めに確認します。制作会社を変えたときに継続できない状態は、納品物が足りないだけでなく事業リスクです。

公開後30日までを制作計画に含める

公開日は終了ではなく、実環境での確認開始です。公開直後、翌営業日、1週間、30日で見る項目を分けます。

時点	確認すること	異常時の対応
公開直後	HTTP、主要ページ、画像、canonical、robots、フォーム、計測	停止条件なら復元
翌営業日	通知、メール、エラーログ、主要端末、社内更新	担当へ修正票を発行
1週間	404、リダイレクト、Search Console、サイトマップ、問い合わせ	URL表と内部リンクを修正
30日	主要行動、流入、更新運用、残課題、利用者の声	次の改善を別案件として判断