作ったサイトを、
世に出し、守る。

基本は「依頼 → ヒアリング → 設計・制作 → テスト → 納品」。

人や案件で中身は変わりますが、骨格は共通です。公開（納品）と保守運用までを一本の流れとして見ると、どこで何を決めておくべきかが分かります。

1. 依頼・相談— 目的・予算・納期をざっくり確認し、対応可否と概算を返す。
2. ヒアリング・要件確認— 目的／ターゲット／ゴール／素材／ドメイン有無を固める（→ 02章）。
3. 見積・契約— 作業範囲・ページ数・修正回数・納期・支払・権利の帰属を文書化。
4. 設計— 構成（サイトマップ）とワイヤー、原稿骨子。LPは「ファーストビュー→ベネフィット→証拠→CTA」の縦構成。
5. デザイン— カンプ（PC／スマホ）、トンマナ、使用フォント・写真・アイコンのライセンス確認。
6. 制作（実装）— レスポンシブなコーディング、フォーム、計測タグ。公開前のステージングで確認。
7. テスト・検収— 要件と1項目ずつ突き合わせ、崩れ・リンク・フォームを確認して合意（→ 07章）。
8. 納品・公開— 本番へ公開、DNS切替、SSL確認、解析・サーチコンソール登録、納品物一式を引き渡し（→ 06章）。
9. 保守・運用— 更新・バックアップ・SSL/ドメイン/サーバー管理・障害対応（→ 08章）。

発注者が「決め切る核」は4つ。

サイトの目的とKPI・対象読者・掲載情報の範囲・更新体制。ここが曖昧なまま進むと、後工程のやり直しと追加費用トラブルの原因になります。丸投げにさせず、ヒアリングで引き出すのが要です。

事業・目的

• サイト／LPの目的と「成功の定義（KPI・ゴール）」
• 想定コンバージョン（購入・予約・資料請求・電話・LINE登録）とCTAの内容
• ターゲット（年齢・地域・課題・PC主体かスマホ主体か）
• 競合・参考サイト（良い例／悪い例と理由）、希望トンマナ

コンテンツ・素材

• 原稿は誰が用意するか（支給／こちらでライティング）
• 写真・ロゴ・図版の有無と形式。どこで手に入れたもので、使ってよい許可があるか（＝入手経路と権利）も確認
• 必要ページ・セクション、フォーム項目、必要機能（予約・決済・多言語・ブログ）

インフラ・権利

• 独自ドメインの有無（新規取得か既存か）、取りたい文字列
• サーバーの有無、現行サイトの有無（新規かリニューアルか）
• 名義は誰にするか（原則お客さん名義 → 04・06章）
• 既存のアナリティクス／サーチコンソール／広告アカウントの有無

進行・条件

• 希望納期・公開希望日、繁忙期
• 予算レンジ（広告運用予定があれば月額広告費も）
• 更新頻度の見込み（公開後どれくらい触るか＝保守設計に直結）
• 連絡手段・レスポンス速度の期待値、決裁者は誰か

作ったサイトを公開する「9つの方式」。

公開方法は「誰が今後直すか」「商用で使えるか」「いくらかかるか」で選びます。まず最初に、見落としやすい商用利用のルールから。

一覧で比べる

引き継ぎやすさ（ロックインの少なさ）：レンタルサーバー＋WP ＞ WordPress.com ＞ Cloudflare/Netlify/GitHub Pages（Git前提）＞ Readdy（書き出し時）。Wix・Framer はエクスポート不可で、GUI更新は楽でも外部へ持ち出せません。

「住所（ドメイン）」と「置き場所（サーバー）」。

Webサイトは、ドメイン＝住所、サーバー＝建物（置き場所）、DNS＝住所から場所への案内、SSL＝通信の鍵（https）でできています。この4つの関係と「名義」を押さえると、公開も引き継ぎも迷いません。

公開方法フローチャート。

迷ったら「公開後、だれが更新するか」から下りていきます。費用やデザイン以上に、実運用（誰が保守し、誰が触り、どう引き継ぐか）が方式を決めます。

誰が直せるかで決まる

ケース別のおすすめ

「公開して終わり」にしない。

納品物・権利・アカウントをきちんと渡すことが、後任が困らない納品です。

納品物の一覧（例）

著作権はひと言で渡らない

フォント・写真・アイコンのライセンス

使用した素材の名称＋ライセンス種別＋取得元URL＋有効期限を一覧にして納品します。Webフォント（Adobe Fonts等）は契約者に紐づくことがあり、お客さん側でも有効かを確認。入手経路が不明な素材は使わない（支給素材でも権利問題は解消しません）。

アカウントの安全な受け渡し

• 平文メール1通で送らない（パスワード管理ツールの共有、別便・別チャネルで）
• 担当者個人のメール名義に依存しない。会社として複数人で管理できる構成に
• 解析・広告は「所有者＝お客さん、制作者＝編集権限」で入る（離脱時に困らない）

要件と1項目ずつ突き合わせる。

「動くはず」で公開しない。下の観点を一つずつ確認し、お客さんの合意（書面・メール）を残します。

「維持する保守」と「育てる運用」。

「保守」の中身は会社ごとにバラバラです。何をどこまでやるかを具体化してから金額を決めます。大きくは、安全に維持する保守と、成果を出すために育てる運用に分かれます。

契約・見積で決めておく8項目

1. 保守（維持）と運用（更新）の線引き（含む／含まない作業）
2. 更新回数の上限と超過単価
3. 軽微修正が有償になる境目（テキスト差し替えは無償／デザイン改変は有償 等）
4. 対応時間・着手の目標時間（個人なら「◯営業日以内に着手」が現実的）
5. 連絡手段・窓口・決裁者
6. バックアップの頻度・保存世代・復元の範囲
7. サーバー・ドメイン費を保守費に含むか実費請求か
8. 契約期間・解約予告・解約時の引き継ぎ（データ・アカウント返却）

運用の基本（セキュリティ・速度・SEO）

• セキュリティ：CMS/プラグインを最新に、ログイン強化（強固なPW・2段階認証）、改ざん監視
• バックアップ：定期自動＋作業前の手動。復元できるかまで確認（取るだけにしない）
• SSL：https常時化、証明書の有効期限監視・自動更新、混在コンテンツなし
• 表示速度：画像最適化（WebP・圧縮）、キャッシュ、Core Web Vitals を定点観測
• SEO：title/meta・見出し構造、サイトマップ送信、GA4・サーチコンソールで監視、リンク切れ点検

もめ事は、技術より「言葉」から。

「言った・言わない」を防ぐ

要件定義書＋見積書で範囲を固定し、打ち合わせは毎回議事録をメールで共有して承認を残す。ページ数・修正回数・原稿担当・対象外作業を文書に明記します。

修正の無限ループを防ぐ

依頼側は小修正〜全面作り直しまで同じ「修正」と呼びがち。制作側が修正の種類を分類して提示し、指示は文章で復唱＋「修正◯回目」と番号を明示して記録。仕様変更は追加見積に回します。

制作者が離脱しても困らない設計

• ドメイン・サーバー・各アカウントはお客さん名義・お客さん管理（最重要）
• 資産の所在（登録者・契約者・ソース・各アカウント名義）を一覧化しておく
• 属人的な独自実装を避け、標準的な構成で後任が引き継げるように

無料ツール依存のリスク

• サービス終了・規約変更が事前通知なく起こり得る（規約に免責条項が入っていることも）
• 無料プランは商用不可のことがある。公式規約で一次確認し、商用可のものだけ使う
• データ移行性：エクスポート不可のツール（Wix/Framer等）は乗り換えで作り直しに。事業の顔は独自ドメイン＋標準構成で

契約の前に、これだけは。