Web制作の副業では、HTML・CSSを書けることと、案件を最後まで進められることは別のスキルです。

実案件では、何を作るか確認する → 素材を受け取る → 実装する → 相手に確認してもらう → 修正する → 納品・公開するまでが一つの仕事になります。

まだ案件を探す前なら、先にWeb制作副業の始め方で対応範囲やポートフォリオを整理してください。この記事では、その次の「受注後」に絞ります。

情報の基準日：2026年8月12日
GitHubのPull RequestやCloudflare PagesのPreview仕様は更新される場合があります。実務で使うときはGitHub公式のPull RequestドキュメントとCloudflare Pages公式のPreview Deploymentsも確認してください。

先に結論：完成してから見せるのではなく、確認点を分ける

案件は次の4区間に分けると整理しやすいです。

  1. 着手前：範囲・素材・仕様を確定
  2. 実装中：土台を作り、早めにPreview共有
  3. 確認・修正：指示を一覧化して対応
  4. 納品・公開：最終確認して引き渡す

特に避けたいのが、1週間作り込んだあと初めてクライアントへ見せる進め方です。

最初の認識がずれていた場合、CSSの微調整ではなくHTML構造やページ構成から戻る可能性があります。

Web制作案件を進める前に確認すること

ページと作業範囲

最低限、次を文章で残します。

  • 対象ページ
  • 新規制作か既存修正か
  • PC / タブレット / スマートフォンの対応範囲
  • JavaScriptで必要な動き
  • フォーム実装の有無
  • CMS組み込みの有無
  • 公開作業の有無
  • 納品物

「レスポンシブ対応あり」だけでは、どの画面幅でどこまで調整するか分かりません。

デザインがPCとスマートフォンだけの場合は、タブレット幅をどう補間するかも確認します。

支給素材

  • Figmaなどのデザインデータ
  • ロゴ
  • 写真・イラスト
  • テキスト
  • フォント
  • アイコン
  • 動画

支給予定の素材が未確定なら、仮画像で進めるのか、正式素材を待つのかを決めます。

既存環境

既存サイトへ追加する案件では、コードを書く前に環境を確認します。

  • 使用しているフレームワーク
  • CSS設計
  • JavaScriptの構成
  • Node.jsなどの実行環境
  • Gitの運用
  • buildコマンド
  • deploy方法
  • 本番ブランチ

既存ルールを無視して独自の命名やライブラリを増やすと、納品後の保守が難しくなります。

Web制作案件を受注してから納品する流れ【2026年8月時点】

Step 1：依頼内容を自分の言葉でまとめる

依頼文を読んだら、そのまま着手せず、次のように要約します。

対象：サービスLP 1ページ
実装：HTML / CSS / JavaScript
対応：PC・SP
動き：FAQアコーディオン、ヘッダー固定
納品：GitHubの指定ブランチへPull Request
公開作業：含まない

相手に確認してもらうことで、着手前に認識差を減らせます。

Step 2：不足している素材・仕様を質問する

質問はできるだけまとめます。

例えば、

  • SPデザインがない部分はPCをもとに調整してよいか
  • hover状態は指定があるか
  • フォントはWebフォントかローカルファイルか
  • 画像はWebP等へ変換してよいか
  • フォーム送信先はどこか
  • 対応ブラウザは何か

などです。

後から質問してはいけないわけではありませんが、レイアウト全体へ影響する条件は早めに確認します。

Step 3：作業ブランチを作る

Gitを使う案件では、本番ブランチへ直接変更を積み重ねず、作業用ブランチを分けます。

GitHub公式でもPull Requestは、別ブランチの変更を提案・レビューしてからbase branchへ統合する仕組みとして案内されています。

ブランチ名はチームルールに従います。

例：

feat/service-lp
fix/header-responsive

Step 4：まずHTML構造と大きなレイアウトを作る

最初から影・アニメーション・1px単位の調整まで行わず、

  • セクション構造
  • 見出し
  • 本文
  • 画像領域
  • ボタン
  • PCの大枠

を先に組みます。

この段階でHTMLの意味構造も確認します。

Step 5：レスポンシブ対応を入れる

MDNでは、レスポンシブWebデザインをさまざまな画面サイズ・解像度で使いやすく表示するための考え方として説明しています。

固定幅だけで再現するのではなく、

  • flexbox / grid
  • 可変幅
  • max-width
  • media query
  • viewport設定

を組み合わせます。

スマートフォンだけでなく、中間幅で急に崩れないかも確認します。

Step 6：JavaScriptの動きを追加する

HTML/CSSの構造が安定したあとで、

  • メニュー
  • モーダル
  • アコーディオン
  • タブ
  • スライダー

などを追加します。

キーボード操作やフォーカスの扱いが必要なUIでは、見た目だけで完了としません。

Step 7：Previewを作って途中確認する

Git連携されたCloudflare Pagesでは、production branch以外のbranchからPreview Deploymentを作れます。Pull Requestから固有のPreview URLを作る運用も可能です。

途中確認では、すべて完成している必要はありません。

例えば、

PC/SPの主要レイアウトと基本動作まで実装しました。文言・画像・セクション順と大きなレイアウトに認識差がないか確認をお願いします。

のように確認ポイントを絞ります。

Step 8：自己QAしてから確認依頼を出す

最低限、次を確認します。

  • 横スクロールが出ていない
  • テキストが切れていない
  • 画像比率が崩れていない
  • ボタン・リンクが押せる
  • hoverだけに情報を依存していない
  • メニューを開閉できる
  • console errorが出ていない
  • フォームがある場合は入力・エラー表示を確認

クライアントへ「確認してください」と丸投げせず、自分の確認を先に終えます。

Step 9：修正を一覧化する

修正依頼はチャットを上から追うのではなく一覧化します。

No.場所修正内容状態
1FV見出し改行位置対応済み
2料金表SP余白調整対応中
3FAQ初期表示変更未対応

複数の修正が追加された場合も、どの指示が最新か分かる状態を保ちます。

Step 10：最終差分とPreviewを確認する

GitHubのPull Requestでは、base branchと変更branchの差分をレビューできます。

最終段階では、

  • 意図しないファイル変更
  • デバッグコード
  • 仮テキスト
  • 仮画像
  • console.log
  • 不要な依存追加

が残っていないか確認します。

Step 11：納品・公開する

納品形式は案件に従います。

例：

  • Pull Request
  • ZIP
  • Gitリポジトリ
  • CMSへ反映
  • production deploy

production公開を担当する場合は、Previewで承認を得てから本番へ進めます。

Step 12：公開後確認をする

公開できたことと、正しく動くことは別です。

公開URLで、

  • TOPから対象ページへ移動できる
  • CSS・画像が404になっていない
  • HTTPSで表示できる
  • SP表示
  • フォームやCTA
  • title / description

などを再確認します。

修正回数より「修正の種類」を確認する

「修正2回まで」と決めても、何を修正として数えるか不明だと揉めやすくなります。

例えば、

  • 実装ミスの修正
  • 支給文言の変更
  • デザインそのものの変更
  • 新しいセクション追加

は性質が違います。

見積もり時に、当初仕様に含まれる修正と追加仕様を分けておくと判断しやすくなります。

納品前チェックリスト

表示

  • PC / SPで主要画面を確認
  • 中間幅で崩れない
  • 横スクロールなし
  • 画像切れなし

動作

  • リンク先
  • メニュー
  • アコーディオン等
  • フォーム
  • 外部リンク

コード

  • 意図しない差分なし
  • 不要コードなし
  • lint / test / buildがある場合は実行
  • READMEや手順更新が必要なら反映

公開

  • Preview承認済み
  • production branchを確認
  • 公開URLを確認
  • 公開後に再テスト

独学で詰まったら、何が足りないかを分ける

案件を進めてみると、足りないものが具体化します。

  • HTML/CSSの設計が不安
  • JavaScript実装が止まる
  • Figmaから値を読み取れない
  • Gitのレビュー運用が不安
  • クライアントとの仕様確認が難しい

体系的に学び直したい場合は、Web制作オンラインスクールの比較で学習範囲と支援内容を確認できます。

逆に、制作実績が増えてきたらフロントエンドエンジニアのポートフォリオの作り方へ進み、実務経験を案件単位で整理してください。

さらに案件経験を積み、業務委託へ広げたい場合はフロントエンド向けフリーランス案件サービスの比較が次の選択肢になります。

まとめ

Web制作案件は、コードを書く前後の工程まで含めて仕事です。

仕様確認 → 作業branch → 実装 → Preview → 自己QA → 修正 → 最終差分確認 → 納品・公開後確認の順番を一度固定すると、次の案件でも再利用できます。

最初の案件ほど、完成度を一人で抱え込むより、確認ポイントを小さく区切って進めることが大切です。