WordPress構築の受ける相手を見きわめる｜断ってよい依頼

2026年3月19日

丸山桃子

この記事のポイント

✓WordPress構築クライアントの選び方を
✓引き合いの段階で確かめる項目
✓断ってよい依頼の見分け方

WordPress構築クライアントの選び方を調べている人の多くは、たいてい一度痛い目に遭っています。着手してから要件が膨らみ続けた、原稿がいつまで経っても届かない、公開直前になって「やっぱり全体的にイメージが違う」と言われた。そういう経験をした後で、次はどう見きわめればいいのかを探している。結論から書くと、見きわめの勝負は契約書ではなく、引き合いの最初の一往復で決まります。この記事では、初回の問い合わせから着手までのあいだに確かめるべき項目、断ってよい依頼の具体的な特徴、そして角を立てずに断るための実務を、受注側の手順として並べます。

WordPress構築で「相手を選ぶ」という発想が必要になった理由

WordPressは世界のWebサイトの4割超で使われているCMSです。裏を返すと、発注する側にとって「WordPressで作れる人」は珍しい存在ではなくなりました。専門会社もいれば、制作会社の下請けもいれば、個人で受けているフリーランスもいる。同じ「WordPressサイトを作ります」という看板の下に、まったく違うサービスが並んでいる状態です。

発注側から見た景色は次のようなものです。

株式会社インスパイアデザインは、2024年時点で13年以上にわたる豊富な経験を持つWordPressに特化した専門会社です。これまでに1,000件以上のプロジェクトを手がけており、大手企業や行政機関を含む多くのクライアントから信頼を得ています。出典: geo-code.co.jp

こういう会社が並ぶ紹介記事を読んだうえで、発注者は個人にも声をかけてきます。つまり相手はすでに比較検討のモードに入っている。ここで「ご依頼ありがとうございます、なんでもやります」と応じてしまうと、専門会社と同じ守備範囲を、個人の体制で引き受けることになります。これが後の破綻の入口です。

「作る」より「作ったあと」で工数が決まる

WordPress構築の見積もりが外れる最大の原因は、構築そのものではなく、構築の周辺にあります。テーマの実装やカスタム投稿タイプの設計は、経験があれば工数を読めます。読めないのは、原稿の到着時期、写真の有無、既存サイトからの移行データの汚れ具合、更新担当者のITリテラシー、そして「誰がOKと言うのか」が決まっていない組織構造です。

制作の主戦場は、この10年で「作る」から「作ったあと運用させる」へ移りました。納品後にクライアントが自力で更新できる状態を作るところまでが仕事に含まれる、という期待が標準になっています。管理画面から不要なメニューを消し、権限を絞り、マニュアルを渡す。ここまでやって初めて「使えるサイト」と評価される。だからこそ、運用する人が誰なのかを最初に確かめないと、作業量が青天井になります。

相手を選ばないと、値引き競争にしか出口がなくなる

見きわめをしない受注が続くと、稼働が読めない案件で予定が埋まります。予定が埋まっていると、条件のいい引き合いが来たときに受けられない。受けられないから稼働率を維持するためにまた条件の悪い案件を取る。この循環に入ると、判断材料が「空いているかどうか」だけになり、相手を選ぶという発想そのものが消えます。

私が最初に請け負ったアパレルブランドのサイトでも、これに近いことが起きました。EC機能はいらないと言われて受けたのに、途中から「商品を並べるページくらいはほしい」となり、次に「在庫が切れたら自動で非表示にできないか」となった。ひとつひとつは小さな要望に見えるのですが、積み上がると別の見積もりになる仕事でした。断らなかったのは、その時点で他に受けられる案件がなかったからです。相手を選ぶ余地は、稼働に余白がある人にしかありません。

引き合いの段階で必ず確かめる項目

初回のやりとりで確かめる項目は、多くありません。ここを型にしておくと、返答の内容そのものが相手の見きわめになります。答えられない項目が多いほど、社内で決まっていないということです。

誰が最終的にOKを出すのか

最初に聞くべきはこれです。窓口担当者と決裁者が違う場合、窓口の人が良いと言ったデザインが、社長のひと言でひっくり返ることがあります。役職者が途中から登場する案件は、確実に手戻りが発生します。

聞き方は事務的で構いません。「公開可否の最終判断は、どなたが行われますか」「デザイン確認の際、ご確認いただく方は何名になりますか」。この2つだけで、意思決定の構造がおおよそ見えます。確認者が多いほど、意見の総和ではなく最大公約数のデザインになり、修正の往復が増えます。3名を超えるなら、確認回数を契約で区切る前提で臨みます。

何のために作るのか

「今のサイトが古いので」は目的ではありません。古いことで何が困っているのかが目的です。問い合わせが来ない、スマホで見づらいと言われる、採用応募が集まらない、自分たちで更新できず外注費がかさむ。困りごとが言語化されている相手は、完成物の評価軸を持っています。評価軸がある相手の「イメージと違う」は、具体的な指摘に変換できます。

逆に目的が言語化されていない相手は、完成した瞬間に評価軸を作り始めます。作り始めた評価軸は、たいてい最初の要件と噛み合いません。ここが検収の紛糾する場所です。

既存サイトはどうなっているか

リニューアルなら、現状の把握が工数の大半を左右します。確認するのは、現在のCMSは何か、記事は何ページあるか、URLの構造を維持するのか、独自に作り込まれた機能があるか、ドメインとサーバーの管理権限を誰が持っているか。

管理権限は特に重要です。前の制作会社が契約者のままになっていて連絡が取れない、という状況は珍しくありません。この場合、移行作業に入る前に契約関係の整理が必要になり、それは制作者の仕事ではありません。誰がその整理をやるのかを決めずに着手すると、なぜか制作者が代行することになります。

公開後の更新は誰がやるのか

社内の担当者が更新するのか、更新も外注し続けるのかで、作るものが変わります。社内更新なら管理画面を絞り込み、投稿の型を固定し、崩れない仕組みを用意する必要がある。これは見た目に出ない作業なので、見積もりに書いておかないと「何もしていないのに高い」と受け取られます。

ブログを書き始めてからのサイトアドレス変更は、記事の評価がリセットされたり、ほかのサイトからのリンクが無効になったりとデメリットが大きいのでご注意ください。出典: xserver.ne.jp

こうした「後から変えると損をする設定」は、着手前に確定させておく項目です。運用者が決まっていない案件では、この確定が誰の判断でも下りません。

原稿と写真は誰が用意するのか

制作が止まる原因の上位は、ほぼ常に素材待ちです。文章と写真をクライアントが用意する前提なのに、その担当者が本業のかたわらで作業する場合、想定の何倍も時間がかかります。ここを「ご用意ください」で終わらせず、いつまでに、誰が、どの形式で出すかまで詰めます。

素材の遅れが読めるなら、契約に反映できます。素材が全部揃った日を起点に納期を数える、という書き方にしておけば、遅延の責任の所在が動きません。詰めずに着手すると、遅れた理由が誰にあっても、遅れているのは制作者という見え方になります。

予算と納期はどう決まったのか

金額そのものより、その数字がどこから来たかを聞きます。他社の見積もりを見て決めた予算なのか、社内で先に枠が確保されているのか、根拠なく「このくらいだろう」と置かれた数字なのか。根拠のない予算は、途中で増えることも減ることもあります。

納期も同じです。展示会、キャンペーン、決算、採用の募集開始。外部の日程に紐づいた納期は動きません。動かない納期に対して素材の到着が読めない案件は、構造的に間に合わない案件です。

この場合、受けるか断るかの前に、公開の段階を分ける提案をします。日程に間に合わせる必要があるのは、たいていサイト全体ではなく一部です。トップページと申し込み導線だけを先に公開し、残りを後から追加する形にすれば、動かない日程と読めない素材を両立できます。段階公開の提案は、相手の目的を守りながらこちらの工程も守る手段なので、断る前に一度は出す価値があります。提案しても「全部同時でないと意味がない」と言われるなら、そこで見送る判断がしやすくなります。

断ってよい依頼の具体的な特徴

見きわめの結論は、たいてい次のどれかに当てはまります。ひとつ当てはまっただけで断る必要はありませんが、複数が重なる案件は、受けた後の負荷が跳ね上がります。

決裁者が最後まで出てこない

打ち合わせに来るのが窓口担当者だけで、「上に確認します」が繰り返される案件です。承認の往復が入るぶん、単純に工程が伸びます。それ以上に問題なのは、こちらの意図が伝言で伝わることです。デザインの意図は伝言に乗りません。乗らないまま否決され、理由も伝言で返ってきます。

対処は、断る前に一度だけ「決裁者の同席」を条件として出すことです。同席してもらえるなら、案件の質が一段上がります。断られたら、確認の往復を見込んだ条件で組み直すか、見送ります。

見積もりだけを繰り返し求めてくる

要件が固まらないまま、パターン違いの見積もりを何度も求められる状態です。相手は比較検討をしているだけで、まだ発注の意思がありません。見積もり作成は無償の作業です。2回目までは提案の一部として応じ、3回目が来た時点で、要件定義そのものを工程として提案します。

要件定義を有償の工程として切り出せば、相手の本気度がはっきりします。払う気がないなら、そこで話は終わります。終わったほうが、双方の時間を守れます。

参考サイトが雰囲気でしか語られない

「こういうおしゃれな感じで」と大手ブランドのサイトを提示されるケースです。参考として悪くはありませんが、そのサイトのどこを参考にしたいのかが言語化されていないと、再現しようがありません。写真の質なのか、余白の取り方なのか、動きなのか、情報量の少なさなのか。

言語化を手伝うのは制作者の仕事です。ただし、聞いても「なんとなく」しか返ってこない相手は、完成後も「なんとなく違う」と言います。この「なんとなく」は修正指示として成立しないので、無限に往復します。

素材が揃う見込みがない

写真がない、原稿を書ける人がいない、ロゴの元データが行方不明。それでも「うまいことやってください」と言われる案件です。素材の制作は別の仕事なので、範囲に含めるなら見積もりに入れる、含めないなら着手条件にする。どちらもしないまま進めると、制作者が撮影も執筆も肩代わりすることになります。

「安くしてくれたら次の仕事も出す」

次の仕事が実在した例は、ほとんどありません。仮に実在しても、一度下げた条件が次で戻ることはありません。将来の受注を担保に現在の条件を下げる交渉は、受けない方針を最初から決めておくと迷いません。

検収の基準が「イメージ」しかない

何をもって完成とするかが、感覚語しかない案件です。ページ数、実装する機能、対応ブラウザ、表示速度の目標、修正回数。これらを事前に文字にできない相手とは、完成の合意が作れません。合意のない完成は、支払いの合意にも届きません。

依頼の出どころ別に、見るべき点は変わる

同じWordPress構築でも、誰から来た依頼かによって、確かめる順番が変わります。出どころは大きく4つに分かれます。

事業会社から直接来る依頼

いちばん条件を作りやすい形です。目的を持っている本人と話せるので、要件のずれが小さい。一方で、Web制作の進め方を知らない相手が多く、こちらが工程を設計して案内する必要があります。デザインの確認とは何をする時間なのか、テスト環境とは何か、公開作業に何が必要か。この説明を省くと、相手は「まだ何も見えない」という不安を、修正指示の形で出してきます。

確かめる順番は、決裁者、目的、素材、更新担当者の順です。制作の常識を前提にせず、専門用語を使うたびに一度言い換える。手間に見えますが、この手間が後の手戻りを丸ごと消します。

制作会社の下請けとして入る依頼

要件がすでに整理されているぶん、着手は早い。確かめるべきは、エンドクライアントとの距離です。直接やりとりできるのか、すべて元請け経由か。経由の場合、仕様の質問への回答が返るまでの時間が工程を支配します。回答待ちで手が止まる日数を、あらかじめ工程表に織り込んでおきます。

もうひとつ、検収の主体を確認します。元請けが検収するのか、エンドクライアントのOKが出るまで検収されないのか。後者の場合、こちらの手を離れた領域の事情で支払いが遅れます。支払期日の起点を、納品日に固定できるかどうかを先に詰めます。

広告代理店やコンサルティング経由の依頼

サイトが施策の一部として位置づけられているため、目的は明確なことが多い。注意点は、施策の変更にサイトが引きずられることです。キャンペーンの方針が変われば、構築中でも構成が変わります。変更を織り込む前提で、変更の扱いを最初に決めておく必要があります。

知人や過去の顧客からの紹介

信頼関係がある分だけ、条件の話が後回しになります。ここがいちばん危険です。紹介案件ほど、作業範囲と支払い条件を文字にしておく。関係が良好なうちに書いた条件は、関係が揺れたときに双方を守ります。「知り合いだから細かいことは」と言われたときこそ、事務的に一枚残します。

見きわめを毎回同じ精度で行うための道具

見きわめを勘でやっていると、忙しい時期ほど雑になります。忙しい時期に取った案件が後で効いてくるので、順序が逆です。精度を一定に保つには、道具を3つ用意します。

問い合わせフォームの質問項目

問い合わせを受け取る入口に、質問項目を置きます。サイトの目的、公開希望時期、現在のサイトの有無、原稿と写真の準備状況、公開後の更新担当者。これだけで、条件の合わない相談の一定数は送信前に離脱します。離脱してもらったほうが、双方の時間を守れます。

初回返信のテンプレート

返信の型を作っておくと、返答の質が疲労に左右されません。型に入れるのは、確認したい項目、想定される進め方の概要、こちらの稼働可能時期、そして概算を出すために必要な情報の一覧です。テンプレートは相手を機械的に扱うためではなく、聞き漏らしをなくすために使います。

判断の記録

受けた案件、断った案件、その理由を一行ずつ残します。半年ためると、自分がどういう相手と噛み合い、どういう相手で消耗しているかが数えられる形になります。記憶は都合よく書き換わるので、書いた記録のほうが信用できます。断った案件がその後どうなったかまで追えると、判断の精度はさらに上がります。

断り方の実務

断ることを決めたら、伝え方は事務的にします。理由を詳しく述べると、そこを潰せば受けてもらえると受け取られ、交渉が続きます。

早く断るほど双方の損が小さい

引き合いの初日に断るのと、提案書を作った後に断るのとでは、相手が別の発注先を探す時間がまったく違います。断る判断は、迷いを持ち越さずにその場で下したほうが、相手にとっても誠実です。

使える文面の型

角が立ちにくいのは、能力ではなく体制の話にすることです。「今回のご要件を、ご希望の時期に十分な品質で進められる体制が取れません」。この形なら、相手の依頼内容を否定していません。加えて、可能なら代替案をひとつ添えます。時期をずらせば受けられるのか、範囲を絞れば受けられるのか、それとも今回は見送りなのか。

条件を提示して断る形にしておくと、相手が条件を満たしてくる場合があります。その場合は、最初より良い状態で受けられます。

全部断らず、範囲を切って受ける

断るか受けるかの二択にしなくても構いません。構築だけ受けて原稿制作は範囲外にする、初期構築のみで運用保守は含めない、リニューアルではなく既存サイトの改修に絞る。範囲を切って受ける提案は、相手にとっても予算が読みやすくなります。

案件の性質によっては、そもそも自分より適した職能があります。マーケティングや広告運用まで求められている引き合いなら、AI・マーケティング・セキュリティのお仕事で扱われるような領域の担当者と組んだほうが、結果が出ます。サイトの構築とアプリケーション寄りの開発が混在する依頼であれば、アプリケーション開発のお仕事の分類にあたる工程を切り分けて、別の担い手に渡すほうが早い場合もあります。全部を自分で抱えないほうが、相手の満足度は上がります。

受けると決めた後に固定しておくこと

見きわめを通過した案件でも、条件を文字にしなければ同じ問題が起きます。着手前に固定するのは次の4点です。

作業範囲を機能単位で書く

「トップページと下層5ページ」ではなく、実装する機能で書きます。お問い合わせフォームの項目数、記事一覧の絞り込み条件、多言語対応の有無、外部サービスとの連携。ページ数で書いた範囲は、ページの中身が膨らんだときに歯止めになりません。

変更の扱いを先に決める

修正を無料で何回まで受けるか、それを超えたら別の扱いにするか。ここを決めていないと、修正が終わりません。決めておくと、相手も優先順位をつけて指示を出すようになります。制限は相手を縛るためではなく、指示の質を上げるために置きます。

支払いの区切りを工程に紐づける

着手時、デザイン確定時、公開時のように、工程に紐づけて区切ります。一括後払いは、完成の定義が揺れたときに全額が宙に浮きます。フリーランスの取引については、発注者が書面で条件を明示する義務や、報酬の支払期日に関する規律が法令で定められています。制度の内容はe-Govで条文を確認できます。

公開後の窓口を決める

公開して終わりではなく、公開直後の不具合対応をどこまで含めるかを決めます。期間を区切って含める形が扱いやすい。含めないなら、公開後の相談は別途という一文を入れておきます。

あわせて、プラグインやWordPress本体の更新を誰が行うかも決めます。放置された更新は脆弱性として残り、問題が起きたときに「作った人」に連絡が来ます。契約上の責任がなくても、連絡は来ます。だからこそ、更新の担当を文字にしておく意味があります。担当しないと決めたなら、その旨を納品時の資料に残す。担当するなら、その作業を継続的な取り決めとして切り出す。どちらかにしておけば、公開の数か月後に発生する連絡が、無償の緊急対応にはなりません。

着手後に相手が変わったときの引き返し方

見きわめを通しても、着手後に条件が変わることはあります。窓口担当者が異動する、決裁者が交代する、途中で親会社の意向が入る。このとき、最初の合意が無効になったかのような要求が来ます。

引き返す手順は決まっています。まず、変更の内容を書き出して相手に確認します。口頭で流れてきた要望を、こちらが文字にして返す。次に、その変更が範囲の内か外かを判定します。判定の基準は、着手前に固定した機能一覧です。基準が文字になっていれば、この判定は感情の問題になりません。範囲外なら、追加の工程として扱うか、今回は見送るかを提示します。

ここで避けたいのは、判定を曖昧にしたまま「今回だけ」と受けることです。一度受けると、その後の変更もすべて同じ扱いを期待されます。断るのが難しければ、受けたうえで「今回は範囲外の作業を追加費用なしで対応した」と記録に残し、相手にも共有します。無償で対応した事実が見えていれば、次の判断はしやすくなります。

担当者が交代した場合は、前任者との合意事項を一枚にまとめて渡します。引き継ぎが行われていないことが多く、後任は経緯を知らないまま指示を出しています。経緯を渡すのは制作者の仕事ではありませんが、渡さないと同じ議論を最初からやり直すことになります。

市場の側から見た「選ばれ方」

20年この市場を見てきた立場から言うと、長く続いている人は、断る力と同じくらい「断らずに済む相手を集める仕組み」を持っています。仕組みといっても大げさなものではなく、過去の仕事の見せ方、問い合わせフォームに置いた質問項目、初回返信のテンプレート。この3つが整っているだけで、条件の合わない引き合い自体が減ります。見きわめは、来た依頼を選別する作業ではなく、来る依頼の質を変える作業です。

もうひとつ、運営者として見てきた限りでは、間に何社も入る取引ほど、条件の説明が曖昧になります。伝言が増えるほど要件は劣化し、劣化した要件が制作者に届く。直接取引の価値は、受け取る側の手取りが厚くなることだけではありません。依頼者の言葉が原型のまま届くので、そもそも手戻りが起きにくい。手数料0%のような仕組みが効くのは、金額の話としてより、依頼者と制作者のあいだの情報の劣化が起きにくいという構造の話としてです。

職域データから読む、受ける相手の広げ方

受ける相手を絞り込むと、案件の総量が減ります。減った分をどこで埋めるかを決めておかないと、選別は続きません。埋め方は2つあります。ひとつは扱う職域を隣に広げること、もうひとつは既存の相手との取引を深くすることです。

職域を広げる方向では、Web制作と親和性の高い領域を見ておくと判断が早くなります。ソフトウェア開発の職域については、ソフトウェア作成者の年収・単価相場で職種としての位置づけを確認できます。原稿制作まで含めて受ける形を検討するなら、著述家，記者，編集者の年収・単価相場で編集職の役割を把握しておくと、範囲を切る交渉がしやすくなります。

海外の発注者に範囲を広げる選択肢もあります。日本語話者向けの実務手順はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法にまとまっており、言語の壁より契約書式の壁のほうが高いことがわかります。契約条件を先に文字にする作法は、国内の取引にもそのまま持ち込めます。

深くする方向では、構築後の運用を引き受ける形が現実的です。ネットワークやサーバー周りの基礎知識があると、保守の相談を受けたときに一次判断ができます。体系的に学ぶならCCNA（シスコ技術者認定）の出題範囲が目安になります。

取引を深くするうえで効くのは、技術の幅よりも、相手の社内で使える形の資料を出せるかどうかです。構築の途中経過を、社内会議にそのまま持ち込める一枚に落として渡す。この一枚があると、窓口担当者は上司への説明に苦労しません。説明に苦労しない相手は、次も同じ人に頼みます。逆に、技術的には正しくても社内で説明できない資料しか出てこない制作者は、担当者が交代した瞬間に切り替えられます。見きわめる側であると同時に、見きわめられる側でもあるという前提を忘れないほうが、判断が甘くなりません。

受ける相手を見きわめるという行為は、依頼を値踏みすることではありません。自分が良い仕事をできる条件を先に定義して、それを満たす相手とだけ組む、というだけのことです。定義がないから断れず、断れないから条件の悪い仕事で埋まる。順番はいつもこうなっています。定義を先に書くところから始めれば、断る場面そのものが減っていきます。