WordPress構築のもう一度頼まれる人｜次に繋がる終わり方

2026年8月13日

朝比奈蒼

この記事のポイント

✓WordPress構築でリピートされる人は何が違うのか
✓納品後30日の動き方まで
✓次の依頼に繋がる終わり方の手順と判断基準を整理しました

WordPress構築でリピートされる人と、一度きりで終わる人。この差がどこで生まれるのかを、納品前後の実務に絞って整理します。結論から言うと、分かれ目は技術力ではなく「終わり方」です。同じ品質のサイトを納めても、引き渡しの段取りが整っている人には次の相談が来て、整っていない人には来ません。発注側が次も同じ人を選ぶのは、その人が優秀だからというより、別の人を探し直すコストを払いたくないからです。この記事では、その「探し直したくない」と思わせる状態をどう作るかを、検収の基準づくりから納品後30日の動き方まで手順として書きます。

もう一度頼まれる人と、一度きりで終わる人の違い

発注側が次も同じ人に頼む理由は品質より切り替えコスト

制作会社や事業会社がWordPress構築を外部に頼むとき、担当者が一番恐れているのは「また一から説明し直すこと」です。サイトの構造、使っているプラグイン、テーマの改変箇所、独自に足したフィールド。これらは引き継ぎ資料がなければ担当者の頭の中にしか残らず、次の人に頼むときは調査費が別途かかります。

ここに、リピートの本質があります。発注側は毎回「同じ人に頼む」と「新しい人を探す」を天秤にかけていますが、この天秤は最初から傾いています。新しい人を探すと、募集して、選考して、仕様を説明して、環境を渡して、既存構造を読んでもらう時間が発生する。同じ人に頼めばその全部が省ける。つまり、こちらが何もしなくても同じ人に頼む側に重みが乗っている状態が普通なのです。

にもかかわらず一度きりで終わるとすれば、その重みを打ち消すだけのマイナスが積み上がったということになります。連絡が遅かった、仕様の解釈違いで揉めた、納品後に触れる資料がなかった、追加作業の見積もりが毎回不透明だった。正直なところ、リピートされない人の多くはコードの品質ではなくここで落としています。

技術力の差より、引き渡しの手触りの差が効く

WordPressの構築では、実装のうまさが発注側から見えにくいという特徴があります。テンプレート階層を正しく使っているか、クエリの投げ方が適切か、フックの当て方が保守しやすいか。これらは同業者なら評価できますが、発注担当者には判別できません。

判別できるのは、管理画面から自分で更新できるか、更新のときに壊れないか、聞きたいことがあったときにすぐ答えが返るか。この3点です。逆に言えば、この3点を意図的に設計しておけば、実装が地味でもリピートされる側に回れます。

3点のうち特に効くのが「壊れないか」です。カスタム投稿タイプの表示に投稿数の上限を決め打ちしていたせいで記事が増えたら一覧が途切れた、といった事故は、担当者の記憶に強く残ります。逆に、担当者が何度更新しても崩れないサイトは、それだけで信頼の証拠として機能します。

リピートは納品後に作るものではなく着手前から仕込むもの

多くの人が誤解しているのは、リピートを納品後の営業活動だと思っている点です。実際には、次の依頼が来るかどうかは着手前の合意形成でほぼ決まっています。何をもって完成とするか、修正は何回まで受けるか、公開後の不具合は誰がどこまで見るか。これを最初に文章にしているかどうかが、最後の印象を左右します。

なぜなら、最後に揉めるのは常に「どこまでが契約範囲か」だからです。ここが曖昧なまま進むと、終盤で受け手は「無償対応が続く」と感じ、発注側は「まだ終わっていないのに終わりと言われた」と感じます。双方が不満を持ったまま終わった案件から、次の依頼は生まれません。

着手前に決めておく、次に繋がる終わり方の設計

検収の基準を先に文章にする

検収基準とは「どうなったら完成とみなすか」の定義です。これを口頭の「いい感じにお願いします」で済ませると、終盤で必ず紛糾します。次の項目を、着手前に箇条書きで合意しておきます。

・対象ページの一覧と、それぞれの完成状態（デザイン再現なのか、コンテンツ流し込みまで含むのか）・対応するブラウザとバージョンの範囲・スマートフォンでの表示確認端末（画面幅の下限をいくつに置くか）・表示速度の目標値を置くかどうか、置くなら測定ツールと合格ラインを何にするか・お問い合わせフォームの送信テストの合否基準・原稿と画像の支給期限、支給が遅れた場合の納期の扱い

このうち最後の項目は必ず入れます。WordPress構築の納期遅延で最も多い原因は実装ではなく、発注側からの原稿と画像が揃わないことです。ここを最初に文章化しておくと、遅れが発生したときに責任のなすりつけ合いにならず、淡々と納期を引き直す会話ができます。この一手間があるだけで、終盤の空気は大きく変わります。

修正対応の範囲と期限をあらかじめ切る

修正回数の取り決めは、受け手を守るためだけの仕組みではありません。発注側にとっても「あと何回使えるか」が見えるので、フィードバックの出し方が慎重になります。回数が無制限だと、思いついた順に小出しの指示が飛んできて、双方の時間が溶けます。

実務では次のように切ります。デザイン確認の段階で2回、実装後の確認で2回。1回あたりの修正指示は、日時を区切ってまとめて出してもらう。範囲外の変更（ページ追加、構成変更、機能追加）は別見積もりとする。この「範囲外は別見積もり」を最初に言っておくのが重要で、後から言うと値上げ交渉に聞こえてしまいます。

期限も切ります。納品後14日以内に検収連絡がない場合は検収完了とみなす、という一文を入れておくと、案件が宙に浮いたまま何ヶ月も終わらない事態を防げます。契約や取引条件の書面化については、フリーランス関連の法制度を所管する官庁の資料も参照できます（公正取引委員会）。

保守と運用をどう扱うかを最初に話題に出す

構築だけを請けて終わるか、公開後の保守も見るか。これは納品時ではなく着手前に一度話題に出しておきます。着手前なら「どうしますか」と中立に聞けますが、納品時に出すと売り込みに聞こえるからです。

その場で決まらなくてもかまいません。「公開後にプラグインの更新やバックアップをどう回すかは、公開前にもう一度相談させてください」と伝えておくだけで、後で自然に話を戻せます。この予告があるかないかで、公開直前の会話の入りやすさがまるで違います。

引き渡しの実務手順

権限とアカウントの棚卸し

引き渡しで最初にやるのは、アカウントの整理です。ここが雑だと、後々のトラブルが全部こちらに返ってきます。

・レンタルサーバーの契約者名義が誰か（受け手名義のままにしない）・ドメインの管理者と更新期限・WordPressの管理者アカウントの一覧と、不要な作業用アカウントの削除・使用したテーマやプラグインの有償ライセンスの名義と更新期限・外部サービス（フォーム、解析、地図、フォント）の連携キーの所有者・データベースの接続情報の保管場所

特に有償ライセンスの名義は要注意です。受け手のアカウントで購入したライセンスをそのまま使っていると、受け手が更新を止めた瞬間にサイトが更新を受けられなくなります。発注側の名義で購入してもらうか、名義移管の手順を資料に書いておきます。

運用マニュアルは操作手順ではなく判断基準を書く

引き渡し資料としてマニュアルを作る人は多いのですが、多くが「投稿の新規追加ボタンを押します」という操作手順書になっています。これはあまり読まれません。管理画面の操作は見れば分かるからです。

読まれるのは判断基準を書いた資料です。

・アイキャッチ画像は横幅いくつで書き出すか、圧縮の目安はどれくらいか・カテゴリーとタグの使い分けのルール（どちらに何を入れるか）・触ってはいけない設定はどれか、触ると何が起きるか・プラグインを新しく入れたくなったときに、事前に相談してほしい種類はどれか・サイトが表示されなくなったときに、最初に確認する順序

この形の資料は、担当者が困ったときに開かれます。開かれる資料を作った人は覚えてもらえます。ページ数は多くなくてよく、A4で数枚に収まる密度のほうが実際に使われます。文書としての体裁を整える基準を持っておくと作業が速くなるので、書式の型を体系的に学びたい場合はビジネス文書検定の出題範囲が参考になります。文書の目的別の構成や、読み手に負担をかけない書き方が整理されています。

拡張余地を残した作りにする

次の依頼は、たいていサイトの拡張から来ます。記事一覧に絞り込みを付けたい、実績ページに種別を足したい、トップに新着を出したい。このとき、最初の実装が硬すぎると「作り直しになります」という返答しかできなくなり、そこで話が終わります。

WordPressの投稿一覧まわりは、後から表示項目を足すことが前提の作りにしておきます。テーマ制作の解説記事でも、この点は繰り返し指摘されています。

実際のデザインではカテゴリーや投稿者、更新日、抜粋等・・・今日使用した関数以外にも使用する可能性があると思います。出典: tomiwa-tech.co.jp

初期のデザイン案に更新日や執筆者の表示がなくても、後から足せる場所を空けておく。テンプレートを部品に分けておき、一覧の見た目を変えるときに触る箇所を1ヶ所に集める。この設計をしておくと、追加の相談が来たときに「数時間でできます」と答えられます。この返答ができる人には、次も相談が来ます。

引き渡しの場を作業ではなく打ち合わせにする

資料を送って終わりにせず、画面を共有しながら30分から60分の引き渡し打ち合わせを設定します。そこで担当者に実際に1件、投稿を作ってもらいます。

この場は品質確認の場ではなく、担当者に「自分で触れる」という感触を持ってもらう場です。ここで詰まった箇所が、その後の問い合わせが来る箇所になります。詰まった箇所だけを資料に追記すれば、マニュアルの精度が一気に上がります。

納品後の最初の30日をどう使うか

初期不具合の窓口と対応範囲を明示する

公開直後は必ず何かが出ます。フォームの自動返信が迷惑メールに入る、特定の環境で画像が縦に伸びる、スマートフォンで固定ヘッダーが本文に重なる。これらを「バグ」と呼ぶか「仕様変更」と呼ぶかで揉めやすいので、線引きを先に伝えます。

合意した仕様どおりに動いていないものは無償で直す。仕様書になかった挙動の変更は別見積もり。この線引きを納品時のメールに1行で書いておくだけで、公開後の会話が穏やかになります。

窓口も明示します。連絡手段をどれにするか、返答の目安を何営業日にするか。「平日1営業日以内に一次返答します」と書いておけば、担当者は安心して待てます。返答が早い人が信頼されるのは事実ですが、常に即答するより「いつ返ってくるか分かる」ほうが評価されます。

アクセスの初動を一緒に見る

公開して2週間ほど経ったら、解析データを見る場を作ります。これは無償のサービスではなく、次の提案の材料集めです。

見るのは3点。どのページが見られているか、どこで離脱しているか、どの経路から来ているか。ここに、発注側が気づいていない課題が必ずあります。会社概要より採用ページのほうが見られている、実績ページの2ページ目でほぼ全員が帰っている、といった事実は、担当者にとって発見になります。

この場を持つと、次の依頼が発注側から出てきます。こちらから「追加でいかがですか」と言わずに済むので、営業色が出ません。実務としては、解析ツールの読み方をこちらが説明できる状態にしておく必要があります。データ分析やマーケティング領域まで扱えると相談の幅が広がるので、隣接領域の仕事の内容はAI・マーケティング・セキュリティのお仕事にまとまっている整理が参考になります。どんな役割がどんな成果物を出すのかが職種別に書かれています。

更新運用が回っているかを確認する

引き渡しから1ヶ月経った時点で、担当者が実際に更新できているかを確認します。更新されていない場合、原因はたいてい3つのどれかです。操作が分からない、更新する内容が決まらない、そもそも担当者が異動した。

3つ目が起きていると、次の依頼の窓口が消えます。この確認を怠って半年後に連絡したら担当者がいなかった、という事例は珍しくありません。月に一度、短い連絡を入れておくだけで、この事故は防げます。

次の依頼が生まれる話の持っていき方

「次どうしますか」ではなく「次はここが効きます」

納品後に「何かあればお声がけください」と伝えるのは、ほぼ効果がありません。発注側は何を頼めるか分かっていないからです。分からないものは思いつかず、思いつかないものは発注されません。

効くのは具体的な提案です。「実績ページの滞在時間が長いので、ここに問い合わせ導線を足すと効果が見込めます」「記事が増えてきたので、カテゴリーの絞り込みを付けると回遊が改善します」。この形なら、担当者は社内で稟議を上げられます。

提案は必ず、観測した事実とセットにします。事実がないと単なる売り込みになり、あると相談になります。この差は大きく、同じ内容でも受け取られ方がまったく違います。

保守契約という形にするかどうかの判断

定期的な作業を契約にまとめるかどうかは、作業量が読めるかで決めます。プラグインの更新、バックアップの確認、表示の点検といった定型作業は月次契約に向いています。一方、内容が読めない改修を月次に含めると、こちらが持ち出しになります。

契約にする場合は、含む作業と含まない作業を明記します。含まない作業の代表は、コンテンツの制作、デザインの変更、新機能の追加です。ここを曖昧にすると「月額を払っているのだから」という理由でどこまでも要求が広がります。

契約にしない選択も十分ありです。都度見積もりのほうが、双方の期待値がずれません。判断の基準は、発注側にサイトを触れる人がいるかどうかです。いるなら都度で足り、いないなら月次にしたほうが双方が楽になります。

紹介が生まれる終わり方

リピートの次に大きいのが紹介です。紹介は、担当者が社内や取引先で「あの人に頼んだらよかった」と口に出した瞬間に発生します。口に出させるのは、成果物ではなく体験です。

具体的には、締め切りを守ったこと、質問への返答が明快だったこと、こちらが気づいていない点を先に指摘してくれたこと。この3つが揃うと、担当者は人に話します。技術の話は社内では伝わりませんが、この3つは伝わります。

リピートが途切れる典型的な失敗

属人化しすぎる

自分にしか分からない作りにすれば次も頼まれる、という考え方は逆効果です。発注側から見ると、それは「この人がいなくなったら詰む」というリスクにしか見えません。リスクを感じた担当者は、次の案件で別の人を試します。

正しいのは、誰でも引き継げる状態にしたうえで、それでも自分に頼むほうが速いと感じてもらうことです。引き継ぎ可能にしても、実際に引き継ぐには時間がかかります。その時間を払いたくないから同じ人に頼む、という構造が最も安定します。

連絡の遅さが信頼を削る

返信の遅さは、実装の遅さより強く印象に残ります。担当者は社内で進捗を聞かれる立場にあり、返事がないと社内で困るからです。

即答できない内容でも、受け取ったことだけは早く返す。「確認して明日中に回答します」の1行があるかないかで、担当者の社内での立場が変わります。この配慮ができる人は、内容が同じでも評価が違います。

追加作業を曖昧なまま飲み続ける

小さな追加依頼を無償で受け続けると、短期的には感謝されますが、長期的には壊れます。作業量が積み上がって受け手が消耗し、途中から急に「これは有償です」と言い出すことになるからです。この転換は、発注側から見ると態度が変わったように映ります。

最初から線を引いておけば、この転換は起きません。「5分で終わる範囲は無償、それを超える場合は先に見積もりを出します」といった基準を先に共有しておけば、都度の判断で悩まずに済みます。

公開して終わりにする

公開日をゴールに置くと、そこで関係が切れます。公開はスタートであって終わりではない、という前提を最初から共有しておくと、公開後の連絡が自然になります。

具体的には、着手時のスケジュール表に「公開後2週間の初期対応期間」と「公開1ヶ月後の振り返り」を最初から書き込んでおきます。予定表に載っていることは実行されますが、載っていないことは実行されません。

単発型の受け方と、継続前提の受け方の比較

観点	単発型の受け方	継続前提の受け方
検収基準	口頭の合意で進める	着手前に文章化して共有する
修正回数	決めずに走る	段階ごとに回数と期限を決める
引き渡し資料	操作手順のみ	判断基準と障害時の初動を含める
実装方針	提示されたデザインに最短で合わせる	表示項目の追加を前提に部品化する
公開後	連絡がなければ終了	初期対応期間と振り返りを予定に入れる
提案の出し方	何かあればと伝える	観測した事実とセットで具体案を出す
権限とライセンス	受け手名義のまま	発注側名義に整理して引き渡す

この表の右側は、どれも技術的に難しいことではありません。ほぼ全部が段取りの話です。だからこそ、経験年数が浅くても今日から実行できます。逆に言えば、実装が上手い人でも右側をやっていなければ単発で終わります。

初心者が最初に整えるべき3つのポイント

使い回せる引き渡しテンプレートを1つ作る

案件ごとにゼロから資料を作ると、忙しい終盤に手を抜くことになります。引き渡し資料のひな型を1つ作っておき、案件ごとに差分だけ書き換える運用にします。含める項目は、アカウント一覧、更新手順、触ってはいけない設定、障害時の初動、問い合わせ窓口の5つです。

このひな型があると、引き渡しの質が案件の忙しさに左右されなくなります。品質の安定は、それ自体が信頼になります。

質問リストを持っておく

着手前のヒアリングで聞き漏らすと、後で必ず手戻りします。毎回同じことを聞くための質問リストを持っておきます。更新頻度、更新する人、既存の解析ツール、既存のドメインとサーバー、社内の承認フロー、公開希望日とその理由。この6項目を聞くだけで、見積もりの精度が上がります。

特に「公開希望日とその理由」は重要です。理由が展示会や新製品発表なら日程は動きませんが、なんとなくなら調整できます。この一言を聞けるかどうかで、無理な進行を引き受けずに済みます。

技術の幅を1段階だけ広げておく

WordPress構築だけで完結する案件は減っており、周辺の相談が一緒に来ます。サーバーやドメインの設定、SSL、メールの配送、簡単なサーバー監視。ここまで答えられると、相談の窓口として選ばれやすくなります。

ネットワークやサーバーの基礎を体系的に押さえたい場合、CCNA（シスコ技術者認定）の学習範囲は実務と重なる部分が多く、通信の基本やトラブル切り分けの考え方が身につきます。資格を取ること自体が目的でなくても、出題範囲を学習の地図として使えます。開発寄りに幅を広げたい場合は、アプリケーション開発のお仕事で扱われている業務の内容を見ると、どこまで踏み込めば案件の幅が変わるかの目安が掴めます。

市場の構造から見た、リピートの経済的な意味

単発の積み上げと継続では、同じ稼働でも残るものが違う

構築案件を毎回ゼロから探して受ける働き方は、稼働時間のうち相当な割合が営業と仕様把握に消えます。継続で受ける場合、この部分がほぼ不要になります。同じ稼働時間でも、実作業に充てられる割合が変わるということです。

エンジニア職の報酬水準の考え方は職種によって大きく異なりますが、ソフトウェア作成者の年収・単価相場には職種ごとのデータが整理されており、自分の立ち位置を客観的に確認する材料になります。制作物の文章や運用ドキュメントまで担う場合は、著述家，記者，編集者の年収・単価相場のデータも併せて見ると、担当範囲と対価の関係を捉えやすくなります。

20年この市場を見てきた立場からの観察

在宅ワークと業務委託のマッチングを長く運営してきた立場から言えば、長く続いている人ほど、単発の作業をこなす時間より「この人に任せると楽だ」と思わせる関係づくりに時間を使っています。彼らは特別に速いわけでも、特別に技術が深いわけでもありません。共通しているのは、引き渡しの資料が整っていること、連絡の返しが読みやすいこと、そして相手が困る前に先に知らせていることです。

もう1つ、運営者として見てきた限りではっきりしているのは、中間マージンが乗らない直接の取引ほど関係が長続きするという点です。仲介の手数料が積み重なると、発注側は同じ予算で頼める量が減り、受け手は同じ作業で残る額が薄くなる。両方が少しずつ我慢する構造では、追加の相談は起きにくくなります。手数料0%で直接やり取りできる関係では、依頼側は同じ予算でもう1本頼めるし、受け手は手取りが厚いぶん丁寧に向き合える。この「双方が少しずつ得をする」状態が、リピートが自然に続く土台になります。

私自身、初めて請けた構築案件では引き渡し資料を1枚も作らず、公開して安心して連絡を止めてしまったことがあります。3ヶ月後に「更新の仕方が分からない」と連絡が来たとき、担当者の口ぶりで、その3ヶ月ずっと放置されていたことが分かりました。作ったものが使われていない期間があったという事実は、報酬をもらった後でも重く残ります。それ以来、引き渡しの打ち合わせは必ず入れています。

海外案件や別領域でも同じ構造が働く

この「終わり方でリピートが決まる」構造は、日本国内の案件に限りません。海外のプラットフォーム経由の取引では、評価とレビューが可視化されるぶん、終わり方の丁寧さが次の受注に直結します。海外案件の進め方の実際はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で手順が整理されており、提案から納品までの流れの違いが分かります。

年齢や経歴に関係なく、この構造は同じです。長く会社員として働いた経験を活かして独立するケースでも、実装の速さより段取りの安定で選ばれる場面は多く、定年後のフリーランス独立｜退職金を活かした起業プランと注意点にはその立ち上げ方の注意点がまとまっています。制作を軸にしながらマーケティング側へ役割を広げていく道筋については、Webマーケティングフリーランスで海外ノマド！年収、スキル、成功への道で必要なスキルの組み合わせが整理されています。