WordPress構築の修正を何回まで受けるか｜先に決めておく

WordPress構築の修正対応が終わらない。この相談は、フリーランスの受注トラブルの中でも上位に来る傾向があります。結論から書きます。原因は「修正回数を決めていないこと」ではありません。回数を決めていても揉める案件は普通にあります。本当の原因は、何を1回と数えるかを決めていないことです。

「修正2回まで」と書いた見積書を出していても、1回の修正依頼に30項目が並んでいたら意味を持ちません。逆に、1項目ごとに1回と数えるなら、発注者は最初の連絡で使い切ってしまいます。この記事では、WordPress構築という業務の性質を踏まえて、契約前に何をどこまで決めておけば修正対応が回るのかを整理します。

WordPress構築の修正が膨らむ構造的な理由

まず、なぜこの職種で修正が膨らむのかを押さえます。個々の発注者の性格の問題ではなく、業務の性質から来ています。

発注側に「完成」の基準がない

WordPressでサイトを作るという依頼は、成果物の輪郭が発注側の頭の中にしかありません。しかも、その輪郭は作っていく過程で変わります。

紙の資料と違い、Webサイトは動きます。実際に画面を触ってみて初めて「思っていたのと違う」が生まれる。この現象自体は自然なもので、避けられません。問題は、この自然な変化を「修正」として無制限に引き受ける契約になっていることです。

だから、着手前に完成の基準を文書にしておく必要があります。ワイヤーフレーム、デザインカンプ、機能一覧。この3つが確定していれば、それに合致しているかどうかで完成を判定できます。確定していない状態で作り始めると、判定基準が存在しないまま制作が進みます。

「修正」と「追加」が混ざる

現場で最も多い摩擦がここです。発注側から見れば、どちらも「直してほしいこと」であり、区別する動機がありません。

デザインカンプ通りに作られていない箇所を直すのは修正です。カンプになかった機能を足すのは追加です。前者は制作側の責任で無償、後者は別途の見積もりが必要。この線引きを契約書に書いていない案件では、後から説明しても納得を得にくくなります。

正直なところ、この区別を口頭の説明だけで通そうとするのは無理があります。着手前に書面で示し、依頼のたびにその文書を参照する運用にしないと機能しません。

関係者が増えるほど指示が矛盾する

企業のサイト構築では、途中から関係者が増えることがよくあります。担当者が作ったサイトを、上長が見て、営業部門が見て、最後に経営層が見る。

各段階で違う指示が出て、前の指示と矛盾する。この状態になると、修正の回数を数えること自体が無意味になります。前回の修正を戻す作業が発生するからです。

対策は、窓口を1人に固定してもらうことです。契約時に「ご指示は◯◯様に集約していただけますでしょうか」と依頼する。社内の意見調整は発注側の仕事であり、こちらが引き受ける範囲ではありません。この線引きを最初に伝えておくことが、結果的に双方の工数を減らします。

回数だけを決めても機能しない

「修正2回まで」という条件が形骸化する理由を具体的に見ます。

何を1回と数えるかを定義する

修正1回の定義には、実務上いくつかの数え方があります。

依頼の回数で数える方法。1通の連絡にまとまった依頼を1回とする形です。運用は単純ですが、1通に大量の項目が入ると破綻します。

項目数で数える方法。修正の項目を数えて上限を設ける形です。粒度の判定が難しく、「この2項目は実質1つでは」といった議論が起きます。

工程で数える方法。デザイン確認の段階で1回、実装後の確認で1回、公開直前の確認で1回、といった形です。WordPress構築ではこの方式が最も実態に合う傾向があります。工程ごとに確認のタイミングを設ければ、発注側もいつまでに何を見ればよいかが分かります。

実務では、工程で区切ったうえで「各回の修正項目は◯項目まで」と併記する形が扱いやすいところです。数字そのものは案件の規模で決めれば構いません。決めていないことが問題を生みます。

受付期間を決める

回数と同じくらい重要なのが、いつまで受け付けるかです。

納品後3か月経ってから「ここも直してほしい」と連絡が来るケースは珍しくありません。制作の記憶は薄れ、環境も変わっている。この状態での対応は、実質的に新規案件と同じ工数がかかります。

対策として、検収の期間を明示します。「納品後2週間以内にご確認いただき、修正のご希望をお知らせください。期間内にご連絡がない場合は検収完了として扱います」といった形です。この一文があるかないかで、案件の終わり方がまったく変わります。

対象の範囲を分ける

修正の対象を、デザイン、機能、コンテンツの3つに分けて考えます。

デザインの修正は、カンプとの差異なら無償、カンプ自体の変更なら有償。機能の修正は、仕様書通りに動いていなければ無償、仕様外の挙動を求めるなら有償。コンテンツの修正は、原稿の差し替えなのか、文章の作成まで含むのかで扱いが変わります。

この3分類で整理しておくと、依頼が来たときの判定が速くなります。判定に迷う時間そのものが、実は大きなコストです。

契約前に決めておく6項目

ここまでを踏まえて、着手前に文書化すべき項目を整理します。

完成の定義

何をもって完成とするかを書きます。確定したデザインカンプ、機能一覧、対応ブラウザと端末、表示速度の基準があるならそれも。この定義が検収の基準になります。

「イメージ通りであること」といった主観的な基準は書きません。判定できない基準は、あってもなくても同じです。

修正の回数と単位

前段で述べた通り、工程ごとの回数と、各回の項目数の上限を書きます。あわせて、上限を超えた場合の扱いも書きます。追加費用が発生するのか、次工程に持ち越すのか。

修正の受付期間

納品後いつまで受け付けるか。そして、期間経過後の扱い。無償対応の終了時期をはっきりさせます。

修正に含まれないもの

含まれないものを列挙するのが最も効きます。新規ページの追加、仕様変更を伴う機能追加、コンテンツの原稿執筆、写真の撮影と加工、外部サービスとの新規連携、WordPress本体やプラグインの定期更新。

こうした項目は、書いていなければ「当然含まれる」と解釈されがちです。書いておけば、依頼が来たときに見積もりの話へ移行できます。

追加費用の扱い

範囲外の依頼が来たときに、どう処理するかを書きます。都度見積もりを出すのか、時間単価で精算するのか。処理の手順を決めておくと、その場で判断できます。

ここで重要なのは、範囲外の依頼を断らないことです。断ると関係が悪くなります。「別途お見積もりします」と返すのが、双方にとって健全な運用です。

公開後の保守との切り分け

構築の修正対応と、公開後の保守は別の契約です。ここを分けておかないと、公開後の不具合対応や更新作業が無限に続きます。

保守を受けるなら、別契約として月額で設計します。受けないなら、公開後の対応範囲を契約書に明記して終了させます。曖昧にしたまま公開すると、無償の保守要員になります。

見積書と提案書にどう書くか

決めた内容を、実際の書面にどう落とすかです。

見積書の明細には、作業項目と併せて「修正対応:デザイン確認時1回、実装後1回、公開前1回（各回◯項目まで）」といった形で入れます。金額の内訳の一部として書くと、条件であることが伝わりやすくなります。

提案書には、進行のスケジュールと確認のタイミングを図で示します。いつ発注側の確認が必要になるかが見えると、相手も社内調整の予定を立てられます。確認が遅れると全体が後ろにずれることも、この図で伝わります。

契約書には、完成の定義、検収の期間、修正の範囲、追加費用の扱いを条項として入れます。ひな型を使う場合でも、業務の内容欄に実態を書き込んでください。「WordPressサイトの構築業務」とだけ書かれた契約書は、後から範囲を争う余地を残します。

私が受け持った案件で、契約書を交わさずにメールのやりとりだけで進めたことがあります。関係が良好だったので問題ないと考えていました。ところが担当者が異動し、後任の方に前提が引き継がれていなかった。結果として、範囲の説明を一からやり直すことになりました。書面は相手を疑うためではなく、人が入れ替わったときのために作るものだと理解しました。

他社が作ったWordPressの修正を引き受けるとき

構築案件と並んで多いのが、既存サイトの修正依頼です。ここは別の注意が要ります。

着手前に必ず調査工程を挟む

他社が作ったWordPressサイトは、中身が予測できません。テーマが独自開発なのか既製品のカスタマイズなのか、プラグインが何個入っているか、子テーマが使われているか、直接ファイルを書き換えていないか。

調査せずに「対応できます」と答えるのは危険です。開けてみたら想定の何倍も工数がかかる、という事態が普通に起きます。

こうした引き継ぎ案件の難しさは、制作側からも共有されています。

実際に、そのようなケースでのご依頼やお問い合わせを多数いただいた経験から、他社制作のWordPressを修正・改修できるかを検討していきたいと思います。 出典: adatype.co.jp

古いバージョンとプラグイン依存の問題

引き継ぎ案件で最も工数が読めなくなるのが、WordPress本体やプラグインが古いまま運用されているケースです。

しかしながら、実際には古いバージョンのまま運用されているWordPressサイトも少なくありません。そのような環境では、すでに導入されているプラグインに準じて修正や改修を行う必要がありますが、プラグイン自体の仕様が古いために、現在の仕様に対応できない、または技術的に制限があるといった問題が生じることがあります。このような場合、プラグイン及びWordPress本体のアップデートを行なったり、プラグインを使用せず自作のプログラムを作成したりするなど代替手段の検討が必要となります。 出典: adatype.co.jp

つまり、頼まれた修正そのものは小さくても、その前提としてアップデートが必要になり、アップデートすると別の箇所が壊れる、という連鎖が起きます。この可能性を見積もりの前に伝えておかないと、追加の作業を無償で背負うことになります。

調査だけを先に有償で受ける

この問題への実務的な対処が、調査を独立した工程として先に受けることです。

現状のバージョン、プラグインの構成、テーマの実装方法、サーバー環境、バックアップの有無。これらを調べたうえで、修正の可否と工数を報告する。ここまでを1つの成果物として納品します。

調査を有償にすることに抵抗を感じる人がいますが、実際には発注側にも利点があります。調査結果は資産として残り、他の会社に依頼する場合にも使えるからです。「調査の結果、対応が難しいと判断した場合はここで終了できます」と伝えると、受け入れられやすくなります。

正直なところ、無償で調査して見積もりを出す商習慣は、この職種では割に合いません。調査そのものに専門性と時間がかかるためです。

そもそも修正を減らす進め方

回数を決めることと同じくらい効果があるのが、修正が発生しにくい進め方を設計することです。

工程を細かく区切って、その都度確認をもらう

一気に作り上げてから見せると、直したい箇所がまとめて出てきます。しかも、後から構造に関わる指摘が出ると、作り直しの範囲が広くなります。

対策は、工程を区切って確認をもらうことです。サイト構成の確認、ワイヤーフレームの確認、デザインの確認、実装の確認。各段階で承認をもらってから次に進みます。

この進め方の利点は、後戻りの範囲が限定されることです。デザインを承認した後に構成の変更を求められた場合、それが範囲外であることを示す根拠になります。承認の記録が、そのまま線引きの証拠になります。

承認は口頭ではなく文面でもらってください。「この内容で進めます」というこちらのメッセージに「はい」と返ってきた記録があれば十分です。堅苦しい書式は要りません。

判断を求めるときは選択肢を出す

「どうしますか」と聞くと、発注側は考え込んで返事が遅れ、しかも後から気が変わります。

代わりに、選択肢を2つか3つ出して選んでもらいます。「A案は情報量が多く一覧性が高い、B案は視線の誘導が明確で回遊しやすい」といった形で、それぞれの性質を添える。選ばれた理由が記録に残るため、後から覆りにくくなります。

これは意思決定の負荷を減らす配慮でもあります。発注担当者は社内で説明する必要があり、比較の材料があるほうが動きやすい。

実物に近い形で早めに見せる

WordPressの案件では、静止画のデザインカンプだけで承認をもらうと、動く状態を見た段階で必ず認識のずれが出ます。

対策は、早い段階で実際に動く形を見せることです。テーマの初期設定を済ませた状態のステージング環境を、デザイン確定の前に触ってもらう。スマートフォンでの見え方、メニューの開き方、スクロールの挙動。この時点で違和感を潰しておけば、実装後の修正が減ります。

正直なところ、この工程を省く案件ほど後半で荒れます。早めに見せるのは手間ですが、後の修正の総量と比べれば圧倒的に軽い作業です。

修正のやりとりを軽くする運用

契約で範囲を決めたうえで、日々の運用も設計します。

指示の受け取り方を固定する

修正依頼をメールの本文やチャットで散発的に受けると、抜け漏れが発生します。

対策は、依頼のフォーマットを固定することです。対象ページのURL、該当箇所（スクリーンショットに印を付ける）、どう変えたいか、優先度。この4項目を書いてもらう形にします。

フォーマットを渡すと発注側の負担が増えるように見えますが、実務では逆です。何を書けばよいか分かるほうが、発注側も楽になります。文章で長く説明する手間が省けるからです。

ステージング環境で確認してもらう

本番環境で修正しながら確認してもらうのは避けます。作業中の状態が公開されてしまううえ、修正が終わるまで見せられません。

ステージング環境を用意して、そこで確認してもらう。この運用にすると、発注側は好きなタイミングで見られ、こちらは本番を壊すリスクなく作業できます。確認のURLを渡すだけで済むため、やりとりの回数も減ります。

修正リストを1か所で管理する

修正項目を一覧で管理し、その一覧を発注側と共有します。表計算ソフトで十分です。

項目、状態（未着手・対応中・対応済・確認待ち・範囲外）、担当、期限。この4列があれば運用できます。特に「範囲外」の状態を明示できることが重要です。範囲外だと判定した項目を一覧に残しておくと、追加見積もりの話をするときの材料になります。

この一覧があると、修正の回数を数える作業も自動的に片づきます。何回目の修正で何項目を処理したかが記録として残るからです。

依頼の優先度を相手に決めてもらう

修正項目が多いとき、すべてを同じ重さで処理すると公開日に間に合いません。

優先度を付けるのは発注側の仕事です。「今回の対応枠では上位◯項目まで処理できます。優先順位をお知らせください」と返す。こちらで勝手に取捨選択すると、後から「あれが直っていない」という指摘を受けます。

優先度を相手に決めてもらうと、依頼そのものが減る効果もあります。順位を付ける過程で「これは急ぎではない」と発注側自身が判断するためです。

画面の記録を残す

修正前後の画面をスクリーンショットで残します。「直したはずの箇所が戻っている」といった認識の食い違いが起きたとき、記録があれば数分で解決します。

動作に関わる修正なら、画面録画も有効です。動きを言葉で説明するより、録画を送るほうが早く正確に伝わります。

公開後の対応をどこで区切るか

構築案件で見落とされやすいのが、公開直後に発生する対応の扱いです。

不具合と修正は別のものとして扱う

公開後に「表示が崩れている」「フォームが送信できない」といった連絡が来ることがあります。これは修正ではなく不具合です。

仕様通りに動いていない状態を直すのは、契約上の履行義務の範囲であり、修正回数とは無関係に対応すべきものです。ここを修正回数にカウントすると、発注側との信頼関係が壊れます。

一方、「公開してみたら文言を変えたくなった」は修正であり、範囲と回数の対象です。この2つを混同しないよう、契約書で「不具合の対応」と「修正の対応」を分けて書いておきます。

不具合の対応についても期間を区切ります。公開後1か月以内に判明したものは無償対応、それ以降は保守契約の範囲、といった形が扱いやすいところです。

更新作業は保守契約に寄せる

WordPressは本体とプラグインの更新が継続的に発生します。この作業を構築の契約に含めてしまうと、終わりのない業務を抱えることになります。

構築契約では「納品時点の環境で動作すること」までを保証し、以降の更新対応は別契約とする。この切り分けを最初に伝えておきます。

発注側にとっても、更新を放置したサイトが脆弱性を抱えるリスクは無視できません。保守を提案する形で伝えると、条件の話が前向きな相談になります。断る話ではなく、続ける話として持ち出すのがコツです。

引き継ぎ資料を残す

公開時に、管理画面へのログイン方法、使用しているテーマとプラグインの一覧、カスタマイズした箇所、バックアップの取り方をまとめた資料を渡します。

この資料があると、発注側が自分でできる範囲が広がり、細かい問い合わせが減ります。一方で「この人は引き継ぎまで丁寧にやる」という評価が残り、次の依頼に繋がります。ノウハウを出し惜しみするより、資料を残したほうが結果的に受注に効く傾向があります。

修正が終わらない案件をどう止めるか

それでも終わらない案件は発生します。止め方を決めておきます。

まず、契約書に書いた回数と受付期間を根拠に、現在の状況を文書で共有します。「契約上の修正対応は◯回で、現時点で◯回目です。以降のご依頼は別途お見積もりとなります」と、事実だけを書きます。

このとき感情を入れないことが重要です。相手を責める書き方をすると、関係が壊れて支払いにも影響します。淡々と条件を示し、次の選択肢を提示する形にします。

支払いについては、法律上の枠があります。フリーランス保護新法では、発注事業者は成果物を受け取った日から起算して60日以内のできる限り短い期間内に支払期日を定める義務があります。修正が終わっていないことを理由に支払いを無期限に引き延ばすことは認められません。制度の詳細や相談窓口は公正取引委員会の公開情報で確認できます。すでに支払いが滞っている場合は、行政の相談窓口や弁護士への相談を検討してください。

なお、契約書を交わしていない案件でこの状況になった場合、主張の根拠が弱くなります。だからこそ、着手前の書面が重要になります。書面は揉めてから作れません。

職種の広がりと、次の受注に繋げる考え方

WordPress構築の修正対応を仕組み化できると、他の開発案件でも同じ設計が使えます。

Webサイトの構築から一歩進んで、業務システムやアプリケーションの開発に広げる道があります。アプリケーション開発のお仕事には、この領域で求められる進め方や技術要件がまとまっています。修正範囲の切り分けという考え方は、開発案件でそのまま通用します。

AI活用の支援は、既存のWeb制作スキルと相性の良い領域です。AIコンサル・業務活用支援のお仕事では、企業の業務にツールを組み込む種類の仕事が扱われています。サイト構築で培った要件整理の力が活きます。

マーケティングやセキュリティ寄りに広げるなら、AI・マーケティング・セキュリティのお仕事が入口になります。WordPressは脆弱性の管理が継続的に必要なため、セキュリティの知見は保守契約の提案材料にもなります。

技術職全体の市場での位置づけは、ソフトウェア作成者の年収・単価相場で公的な職業分類に基づくデータを確認できます。自分のスキルセットがどの職種区分に近いかを把握しておくと、案件選びの判断が速くなります。

ネットワークやサーバーの基礎を体系立てて固めたいなら、CCNA（シスコ技術者認定）のような資格が選択肢に入ります。WordPressのトラブルはサーバー側に原因があることも多く、この領域の知識は調査工程の精度を上げます。

海外の発注者との取引に興味があるなら、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で契約の考え方を確認しておくと役に立ちます。修正範囲の定義は、海外案件ではより厳密に求められる傾向があります。

運営者として見てきた、修正で消耗しない人の共通点

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、修正対応で消耗しない人は、断るのが上手い人ではありません。着手前に決めることを決めている人です。

条件を先に出すと受注が減るのではないか、という不安を持つ人は多い。ただ、運営者として見てきた限りでは、条件を明示している人のほうが継続的な取引に繋がっています。発注側にとっても、範囲が見えている相手のほうが社内で説明しやすく、追加依頼も出しやすいからです。曖昧なまま始めた案件は、途中で双方が疲れて自然消滅する傾向があります。

もう1つ、長く続く関係に共通しているのが、間に仲介が入らない直接の取引だという点です。中間マージンが乗らないぶん、同じ予算で依頼者はより多くの作業を頼めますし、受け手は手数料0%で手取りが厚くなります。加えて、修正の範囲や追加費用といった細かい条件を、当事者同士で直接調整できる。仲介を挟むと、条件変更のたびに承認の階層が増え、話が進みません。この違いが、修正対応の負荷にそのまま出ます。

修正回数を決めるという作業は、相手を縛るためのものではありません。どこまでやれば終わりなのかを両者が共有するための作業です。終わりが見えている仕事は、発注側にとっても進めやすい。この視点で条件を設計すると、交渉が対立ではなく合意の作業になります。

よくある質問

Q. WordPress構築の修正は何回まで受けるのが適切ですか？

回数の数字より、何を1回と数えるかを決めるほうが重要です。実務で扱いやすいのは工程で区切る方法で、デザイン確認時に1回、実装後に1回、公開前に1回とし、各回の修正項目数に上限を併記します。回数だけを決めても、1回の依頼に大量の項目が並べば意味を持ちません。

Q. 「修正」と「追加」の線引きはどう決めればよいですか？

確定したデザインカンプや機能一覧と実装が食い違っている箇所を直すのが修正で、これは制作側の責任として無償です。カンプになかった機能やページを足すのは追加で、別途見積もりが必要です。この線引きは着手前に書面で示し、依頼のたびにその文書を参照する運用にしないと機能しません。

Q. 他社が作ったWordPressの修正依頼は、そのまま受けてよいですか？

着手前に調査工程を挟んでください。テーマの実装方法、プラグインの構成、本体のバージョン、サーバー環境を確認しないと工数が読めません。古いバージョンのまま運用されている場合、頼まれた修正の前提としてアップデートが必要になり、それによって別の箇所が壊れる連鎖が起きます。調査は独立した有償の工程として受けるのが安全です。

Q. 修正が終わらないまま支払いも止まっている場合はどうすべきですか？

契約書に定めた修正回数と受付期間を根拠に、現状を文書で共有し、以降は別途見積もりとなる旨を事実として伝えます。フリーランス保護新法では、発注事業者は成果物の受領日から60日以内のできる限り短い期間内に支払期日を定める義務があります。修正未了を理由に支払いを無期限に延ばすことは認められません。滞納が続く場合は行政の相談窓口や弁護士に相談してください。