2025.11.27

新人Webディレクターのための修正対応ガイド|見積もり・保守契約・進行の考え方

Wataru Machishima

GEAR8のディレクター待島です!

Webディレクターとして働き始めると、最初に任されることが多いのが「サイトの修正対応」です。
「テキストを1行変えるだけなのに、いくらで見積もればいいのか?」「保守契約と都度見積もりはどう使い分けるのか?」と悩む方も多いはずです。

「この数字を新しい料金に変えるだけなので、さっと直せますか?」

Webの運用をしていると、そんな「ちょっとした修正」の相談は日常的に届きます。作業としては数分で終わりそうに見えることも多いので、「はい、すぐやります!」と答えたくなる気持ちはよく分かります。

でも、Webディレクターの役割は「とにかく早く直すこと」だけではありません。
見積もりが妥当か、リスクはつぶせているか、チームや外注先の工数は守れているか、そして何よりクライアントに不安を与えない進め方になっているか。こうした視点を持てるかどうかで、仕事のクオリティが大きく変わります。

この記事では、新人Webディレクター向けに、

  • 見積もりとミニマムチャージの考え方
  • 内製と外注で変わるコストの見え方
  • 修正依頼にすぐ飛びつく前に確認しておきたいポイント
  • Backlogを使ったタスク管理の工夫

を整理していきます。

1. 「1行だけのサイト修正」に隠れたWebディレクターにとってのリスク

クライアントから見ると、数字をひとつ変えるだけ、文言を一文差し替えるだけ、といった具合に画面上の変化はとても小さく見えます。

一方で、Webディレクターの目線だと、その前後でこんな仕事が発生します。

  • 依頼内容を受け取って要点を整理
  • どのページ・どのファイルが対象かを確認
  • 関わるメンバー(社内のデザイナーやエンジニア、場合によっては外部パートナー)に仕様を共有
  • テスト環境で表示や動作を確認
  • 本番環境に反映したあとも、最終確認をして、クライアントに完了報告と必要な説明を行う

修正作業自体が仮に1時間満たなかったとしても、コミュニケーションや確認に同じくらい、あるいはそれ以上の時間がかかることも少なくありません。

それなのに、作業時間だけを見て「30分だから、ざっくり◯円くらいでいいか」と考えてしまうと、

  • 追加修正や確認が1回増えただけで、すぐに想定工数をオーバーする
  • 「この程度なら安くやってくれる会社」という印象だけが残る
  • 外注を使った瞬間に、会社としての利益が消えてしまう

といったことが起こります。

新人Webディレクターにとって大事なのは、

修正依頼=「目に見える作業」+「目に見えにくいコミュニケーションと確認」のセットである

と捉えることです。

2. ミニマムチャージ(最低料金)とサイト修正の見積もり・単価設定

そこで多くの制作会社が設けているのが、ミニマムチャージ(最低料金)です。

どんなに小さな修正でも、依頼内容の把握や対象範囲の確認、指示出し、テスト確認、本番反映、報告までをひとつの「対応セット」と考え、一定額をいただくという考え方です。 

例えば、

  • 軽微な修正1回あたり、会社として「◯円を下回らない」ようにしておく
  • 内容や頻度によって金額のレンジを社内ルールとして決めておく

といったイメージです(あくまで例です)。

金額の絶対値よりも大事なのは、「このセットにはこれくらいの手間がかかる」という感覚をチームで共有しておくことです。

細かな追加見積もりではうまくいかない理由

実務では、こんなことがよく起こります。

最初の指示通りに修正したあとで、

  • 「よく見ると、別の場所も直したいです」
  • 「すみません、数字が少し違っていました。あと1箇所だけ…」

という追加依頼が入るケースです。

そのたびに「では、1,000円追加で…」と細かく見積もりを出し直すのは、クライアントにとっても制作側にとってもストレスですし、「細かく請求されている」印象にもつながりかねません。

そこで、たとえば「軽微な修正は、◯円の中で「数回の微調整」までは含めて対応する」と決めておくと、「ちょっとした追加」はその範囲で吸収しつつ、対象が増えたり内容が大きく変わる場合は別途相談、という線引きがしやすくなります。

ミニマムチャージは、「ぼったくるため」ではなく、

事前にルールを決めておくことで、クライアントにも社内にも分かりやすい形で約束を守るための仕組みと考えると理解しやすいと思います。

3. 内製か外注か?押さえておきたいコストの考え方

もうひとつ意識しておきたいのが、「誰が作業するか」でコストの構造が変わるという点です。

社内のデザイナーやエンジニアが対応する場合、発生しているコストが見えにくいことがあります。とはいえ、他案件の時間を削って対応している以上は、会社としてのリソースを使っていることに変わりはありません。

一方で、外部のパートナー企業にお願いする場合は、

  • 相手に支払う金額
  • 自社の利益(いくら残すのか)
  • 外注とのやり取りにかかる時間

をまとめて考えなければいけません。

ありがちな失敗は、クライアントへの請求額と、外注先への支払額がほぼ同じになってしまうパターンです。これでは自社に利益は残らず、外注とのコミュニケーションに使った時間も回収できません。

新人Webディレクターとしては、

  • この修正は社内対応を前提にしているのか
  • 外注が絡む場合、その分のやり取りの時間も見積もりに含まれているか

といった視点で、先輩や上長が作る見積もりを観察してみてください。見積書の「裏側にある考え方」が少しずつ見えてきます。

4. サイト修正依頼の進め方|新人Webディレクターの対応フロー

では、実際に修正依頼をもらったとき、ディレクターは何を確認すれば良いのでしょうか。
ここからは、手を動かす前のチェックポイントを順番に見ていきます。

4-1. スコープ(対象範囲)の確認

例えば、

  • 「この商品名を新しい名前に変更してください」
  • 「料金表の見せ方を変えてください」

といった依頼が来たとします。

このとき、目の前の1ページだけを直してしまう前に、

  • 同じ情報を使っているページやPDF、ブログ記事などが他にないか
  • 管理画面やデータベースにも同様の情報が登録されていないか

を一度立ち止まって考えます。

最低限でも、

「今回の修正対象は◯◯ページのみでよろしいでしょうか?
他のページや資料にも同じ情報がある場合、あわせて更新するかどうか教えてください」

と確認する癖をつけておくと、後から「ここは変わっていない」と言われるリスクを大きく減らせます。

4-2. タイミングの確認

「◯月◯日までに画像を新しいものに変えてください」「キャンペーンの開始に合わせて文言を差し替えたいです」といった依頼の場合も、期日だけ見て「その日までに変えればOK」とは考えません。

  • いつから新しい情報を出して良いのか
  • 事前告知の期間が必要なのか
  • 店頭表示や社内告知など、他のチャネルとの整合性はどうか

といった点を確認します。

たとえば、キャンペーン開始日の午前0時ちょうどで切り替えるべきなのか、それとも前日から告知として出してよいのか、など。ここを丁寧にすり合わせることで、クライアント側の社内調整やユーザー体験に与える影響を最小限にできます。

4-3. 意図の確認(スクリーンショットを使う)

レイアウトや配置の変更が絡む依頼では、文章の指示だけだと解釈が分かれがちです。

「全体のバランスを崩さない程度に、ここを上の方に寄せてください」
「このボタンの位置を、もう少し目立つところに動かしたいです」

といった依頼が来たら、Gyazoなどのスクリーンショットツールで現状画面を共有し、

「この部分を、この位置に移動するイメージで合っていますか?」

と確認してしまう方が早く、そして安全です。

お互いの頭の中にあるイメージを、いったん画面上で揃えてから作業に入るイメージです。結果として、手戻りが減り、対応スピードも上がります。

4-4. テスト環境 → 本番環境の二段構え

可能であれば、

  1. テスト環境で修正
  2. テスト環境で自社・クライアント双方が確認
  3. 問題がなければ本番環境に反映

という流れを基本にします。

クライアント側の事情で「テスト確認は省略して良いので、本番に直接反映して欲しい」というケースもありますが、その場合でも社内では一度検証環境でチェックしてから本番反映する、あるいはバックアップを取ってから作業するなど、ユーザー側に影響が出ないようなガードを用意しておくことが大切です。

4-5. 担当者変更時は「ルールの棚卸し」をする

クライアント側の担当者が変わると、それまで口頭で積み重ねてきた「いつものやり方」が一度リセットされます。

テスト環境での確認フロー、見積もり〜着手までの段取り、修正内容の共有方法(メール、チャット、Backlogなど)。こうしたものを改めて共有し直す「ルールの棚卸し」をしておくと、「前任のときはこうだったのに」というギャップを減らせます。

新人Webディレクターほど、「前からこうだったので…」で済ませず、一度文章にして説明してみると、自分の頭の整理にもなります。

5. Webディレクションの契約形態|都度見積もりと保守契約の使い分け

修正対応のスタイルは、大きく分けて「都度見積もり」と「保守契約(定額)」の2パターンがあります。

5-1. 都度見積もり

依頼が発生するたびに内容をヒアリングし、「今回はこれくらいの作業なので、この金額です」と見積もりを出して、承認後に着手するやり方です。

内容やボリュームが案件ごとに大きく変わる場合や、レイアウト変更や機能追加など比較的重めの作業が混ざる場合には、この方がフェアになりやすいです。一方で、軽微な修正でも毎回見積もりと承認が必要になるため、やり取りの手間と時間は増えます。

5-2. 保守契約(定額制)

毎月あらかじめ決めた金額をいただき、その範囲内でテキスト修正や画像差し替えなどをまとめて対応する形です。たとえば、

月◯回までの軽微な修正を、月額◯万円で対応、といったイメージです。

クライアントにとっては、「ちょっとした修正なら気軽に相談できる」「毎回金額の確認をしなくて済む」という安心感があります。制作側にとっても、「スコープ内の修正はすぐ着手」「大きな改修は別途見積もり」という切り分けがしやすくなります。

大事なのは、保守で対応する範囲をできるだけ具体的に決めておくことです。
テキスト差し替えや既存画像の入れ替えは含むが、レイアウトを大きく変える作業や新規ページ追加は都度見積もり、といった線引きを、契約時に文章で残しておきましょう。

新人Webディレクターとしては、「このクライアントの依頼パターンだと、どちらの契約が向いていそうか」「どんな線引きをしておけば、お互いに気持ちよく続けられそうか」を先輩と一緒に考えてみると、提案の幅が広がります。

6. Backlogを使ったタスク管理・進行管理のコツ

内容や見積もりの考え方がどれだけ良くても、タスク管理が曖昧だと最後にバタバタします。ここでは、Backlogを使う前提で、Webディレクター目線の工夫をいくつか紹介します。

6-1. 親子課題でタスクを分解する

ひとつの修正依頼の中に、

  • 表示テキストの変更
  • 管理画面の更新
  • デザインの微調整

など複数の作業が含まれていることはよくあります。
これを1つの課題だけで管理すると、「一部だけ終わっているのに完了にしていいのかどうか分からない」「どこか1つが抜けていた」ということになりがちです。

そこで、

  • 依頼全体をまとめる課題
  • 個別の作業ごとの課題

という構造に分けると、どの作業がどこまで進んでいるか、誰が担当しているかが一目で分かります。Backlogは親子課題が1階層まで(孫課題は作れない)なので、その前提で分け方を工夫してみてください。

 

6-2. 「完了条件」をチェックリストで明文化する

1つの課題の中に、「テスト環境での確認」「本番反映後の再確認」「クライアントへの報告」など複数のステップが含まれることも多いです。

その場合は、課題の説明欄に簡単なチェックリストを書いておくと便利です。

  • テスト環境での表示確認(PC・スマホ)
  • 本番反映後の最終確認
  • クライアントへの完了報告

といった具合に、「ここまで終わったら完了」というラインを文章で定義しておくと、担当者間の認識ズレが減り、引き継ぎもしやすくなります。

6-3. 課題テンプレートで「毎回同じ説明」を省略する

アクセス解析レポートの作成や、月次の定型更新など、やることがほぼ決まっているタスクは「課題テンプレート」に登録しておきます。

参照すべきスプレッドシートのURL、納品物の保存先フォルダ、報告時に必ず触れるポイントなどをテンプレートに書いておけば、新人Webディレクターでも「この通りに進めれば大きくは間違えない」という状態をつくれます。

7. 新人Webディレクターがつまずきやすいポイントまとめ

新人や、これからWebディレクターになりたい人からは、次のような質問をよくもらいます。

  • サイトの文言修正は、どこからどこまでを1セットとして見積もれば良いのか
  • 軽微な修正でも、都度見積もりにするべきか、保守契約でまとめるべきか
  • 内製と外注で単価や対応スピードはどう変わるのか
  • Backlogなどのツールで、修正タスクをどう分解・管理すれば抜け漏れを防げるのか

この記事は、こうした質問に対するひとつの答えとして、「現場での考え方」と「進行の工夫」を整理したものです。全部を一度に完璧にやる必要はありませんが、少しずつ実践していくことで、クライアントにもチームにも安心して任せてもらえるWebディレクターに近づいていけます。

8. おわりに:不安にさせず、迷わせず、待たせないディレクションへ

ここまで紹介してきた内容は、どれも自分たちの工数や利益を守るだけでなく、

  • クライアントに不安を与えない
  • 依頼から完了までの流れを分かりやすくする
  • いつ依頼されても、一定の品質とスピードを保つ

ための「裏側の工夫」です。

新人Webディレクターにとって大切なのは、「早く直す」「安くやる」ことだけではありません。

ちゃんと確認してから動き、必要な説明をきちんと行い、万が一のリスクにも目を配りながら進行することで、「あのディレクターに任せておけば安心」という信頼が少しずつ積み上がっていきます。

次に「ちょっとした修正」の依頼が来たとき、この記事で触れたポイントをひとつでも思い出してもらえたら嬉しいです。

9. GEAR8に関心を持ってくださった方へ

GEAR8では、タイミングを見ながら少しずつ新しい仲間を迎え入れています。
いま大々的な募集をしているわけではありませんが、

  • 将来的に、Webディレクションやデザインの現場で一緒に仕事をしてみたい
  • 北海道やアジア拠点をベースに、クライアントと長く伴走するような仕事に興味がある

そんなふうに感じてくださる方がいれば、採用情報をご覧いただけると嬉しいです。

採用に関する情報は、GEAR8のサイトにまとめています。

どんな働き方やプロジェクトに関わっているのか、まずは情報収集のつもりで覗いてみてください。将来どこかのタイミングで、一緒に仕事ができたらとても心強いです。

Facebook
Twitter

Wataru Machishima

1985年3月北海道登別市生まれ。小樽、函館を経て13歳から札幌在住。パンダは特別好きではなかったですが、10年も担当動物として一緒にいて今や愛着もひとしおです。

大学在学中のインターン経由で翻訳会社へ入社し営業マンとして外国語のツールやウェブ制作に携わりました。制作会社に移り3ヶ月だけウェブデザイナー、その後ディレクターとなり2年で167件のディレクションを担当し精神を鍛えたのち、2012年からGEAR8でディレクターです。

夏は主にファミキャンで道内キャンプ場にいます。テントはOGAWA(2022年〜)、良さげなギアを見てはポチり過ぎて赤字になります。ディレクションという仕事が好きで、担当するクライアントのためにいろいろ思考を深めます。国内のウェブ系勉強会に参加とたまに登壇も。気軽に声をかけてください!