
プログラミングの副業で、表計算の自動化の次に案件数が多いのがWordPressです。世の中の中小企業のサイトの多くがこれで動いていて、作った人がもういない状態で運用されているケースが珍しくありません。
そこに需要があります。ただし、自動化の回で書いた「受けてはいけない依頼」と同じ構造の危険が、この分野にもあります。しかも影響範囲が大きい。公開中のサイトを触る仕事だからです。
この記事では、WordPressのカスタマイズ案件を分解します。扱うのは、案件の種類と相場、受注前の確認、公式が推奨している直し方、受けてはいけない依頼、時間と見積もり、作業前の準備、案件の取り方、つまずく場所です。「やってみたら月いくらでした」という結果報告はしません。
相場はクラウドワークスの公式ページ、動作要件と子テーマの考え方はWordPress公式のドキュメントを一次情報にしています。
WordPressの案件は「作る」より「直す」が多い
まず相場です。クラウドワークスが発注する企業側に公開している数字から、Web制作まわりを抜き出します。
| 依頼の種類 | 相場 | 納期目安 |
|---|---|---|
| ホームページ内の文章変更・画像差し替え(2〜3時間程度) | 30,000円〜 | – |
| サイトコーディング(レスポンシブ無し) | 30,000円〜 | 7日前後 |
| TOPページデザインのみ | 50,000円〜 | 15日前後 |
| デザイン・コーディング(長さ3000px程度のLP) | 100,000円〜 | 20日前後 |
ここで注目してほしいのは1行目です。文章の変更と画像の差し替えという、2〜3時間程度の作業で30,000円から。技術的な難易度は高くありません。それでも相場がこの水準なのは、公開中のサイトを触るリスクが値段に含まれているからです。
難易度ではなく「壊れたときの損失」で値段が決まる
自動化の案件は、失敗しても自分のファイルの中で止まります。WordPressは違います。作業中にサイトが表示されなくなれば、その間の問い合わせも売上も止まります。
だから、作業時間で見積もると必ず安くなります。2時間の作業だから5,000円、という値付けをすると、止まったときの責任まで5,000円で引き受けたことになります。相場が30,000円からという意味を、ここで理解しておいてください。
相手に説明するときも、この言い方がそのまま使えます。「作業自体は2時間ですが、バックアップの取得と、公開中のサイトを触る前後の確認を含めた金額です」。理由が示されていれば、金額は通ります。
入口は「小さい修正」で合っている
とはいえ、最初から大きな案件を狙う必要はありません。文章の差し替え、画像の入れ替え、問い合わせフォームの項目追加。こうした小さい修正から入るのが順当です。
小さくても、手順は大きな案件と同じです。バックアップを取り、検証環境で試し、本番に反映し、確認する。この一連を体に入れるために、最初は小さい案件を選びます。
もう1つの利点は、相手との関係が続きやすいことです。サイトの修正は、一度きりでは終わりません。今回の担当者に次も頼む、という流れが自然に生まれます。
最初の案件は、金額より継続しそうな相手かどうかで選んでください。定期的に更新しているサイトかどうかは、投稿日を見れば分かります。
受ける前に確認する5つのこと
WordPressの案件は、聞かずに受けると見積もりが崩れます。最低限、次の5つを確認してください。
- サーバーとPHPのバージョン:古い環境では動かないプラグインがあります
- テーマは何か、子テーマはあるか:有料テーマか、独自のものか
- バックアップの有無と取り方:誰がいつ取っているか
- 検証用の環境があるか:本番しかないのか
- 管理画面の権限をどこまでもらえるか:管理者か、編集者か
バージョンを聞く理由
WordPress公式は、推奨環境としてPHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上を挙げています。そして、PHP 7.4以上とMySQL 5.5.5以上でも動作はするが、これらは公式のサポート終了を迎えており、サイトがセキュリティの脆弱性にさらされる可能性があると明記しています。
つまり、古い環境のサイトを触る案件では、こちらの作業と関係のない不具合が同時に出る可能性があります。受注前にバージョンを聞き、古い場合は「更新が必要になるかもしれない」ことを先に伝えておく。これだけで、後から責任を問われる場面が減ります。
権限の範囲を先に決める
管理者の権限をもらうと、できることが増える一方で、触れる範囲も広がります。権限が広いほど、何かあったときに疑われる範囲も広い。
作業に必要な最小限の権限で受けるのが基本です。必要になった時点で追加してもらう。「この作業には管理者権限が必要です」と説明できる形で依頼するほうが、相手にとっても安心です。
あわせて、作業が終わったら権限をどうするかも決めておきます。継続の予定がないなら、アカウントを削除してもらう。これをこちらから申し出ると、相手の管理が楽になります。
IDとパスワードの受け渡しにも配慮します。やり取りの履歴に平文で残る形は避け、相手が使っている安全な方法に合わせてください。
テーマを直接編集しない。理由は公式に書かれている
ここが、この分野でいちばん多い事故の原因です。見た目を変えてほしいという依頼に対して、使っているテーマのファイルを直接書き換える。動きます。そして、テーマが更新された瞬間に、その変更は消えます。
公式が挙げている子テーマの利点
WordPressの公式ドキュメントは、子テーマ(child theme)について次の利点を挙げています。
- 変更を持ち運べて、再現できる形にする
- カスタマイズを親テーマから分離しておける
- 親テーマを更新しても、変更が失われないようにする
- 必要なコードだけを書けばよいので、開発時間を節約できる
3つ目が本質です。親テーマの更新は、セキュリティ修正を含みます。更新できない状態を作ることは、サイトを危険なまま放置することと同じです。直接編集は、更新を諦めさせる作り方だということを理解してください。
孫テーマは存在しない
同じドキュメントには「これは現在のところ不可能です。標準のテーマ階層には、親テーマと子テーマの2段階しかありません」と書かれています。子テーマの子を作って整理する、という発想は使えません。
また、子テーマの中で広範囲なカスタマイズを行うと、やがて管理が難しくなる、という趣旨の注意も記載されています。大規模な改修では、元のテーマをフォークして独立したテーマにするほうがよい場合がある、とされています。
ブロックテーマの場合、利用者が管理画面で行ったカスタマイズはデータベースに保存されます。公式はこれを「ある意味で孫テーマのように働く」と説明したうえで、テーマの階層そのものではないと整理しています。
この違いは実務でも効きます。データベースに保存された変更は、テーマのファイルを見ても分かりません。引き継ぎの資料には、ファイルの変更と管理画面での変更を分けて書いてください。
実務での判断
小さな修正なら子テーマ、あるいはプラグインで追加できる範囲で行う。中規模以上なら、子テーマで抱え込まずに構成そのものを相談する。この線引きを最初に伝えておくと、後から膨らみません。
そして、どの方法を選んだかを納品時に説明します。「今回は子テーマに追加しました。親テーマの更新をしても消えません」。この一文が、次の依頼を呼びます。
逆に、前任者が直接編集していた形跡が見つかることもあります。その場合は、勝手に直さず報告してください。「現在の変更は親テーマに直接入っています。更新で消えるため、子テーマへ移す作業をご提案できます」。指摘ではなく提案として出すのが要点です。
受けてはいけない依頼が4つある
技術的にできるかどうかと、引き受けていいかどうかは別です。副業として受ける範囲には、線を引いてください。
1. バックアップが取れない環境での作業
戻せない状態で本番を触るのは、賭けです。バックアップの取り方が分からない相手なら、まずバックアップを取れる状態にすることを最初の作業として提案します。
これ自体が案件になります。そして、以降のすべての作業がやりやすくなります。断るのではなく、順番を変える提案です。
提案の形はこうです。「まずバックアップの取得と、復元手順の確認を行います。その後に今回のご依頼に着手します」。2段階に分けると、相手も納得しやすい。
ホスティング会社の自動バックアップが有効になっている場合もあります。契約内容を確認してもらえば、追加費用なしで条件が整うこともあります。
2. 決済・会員機能の改修
購入や会員登録に関わる部分は、止まったときの損失が直接的です。個人が副業として単独で触る範囲を超えます。
受けるとしても、表示側の変更にとどめる。処理の流れに手を入れる依頼は、法人の制作会社に相談するよう伝えてください。断る理由をはっきり言えることは、実力の一部です。
断り方も決めておきます。「決済に関わる部分は、障害時の影響が大きいため、個人では請けておりません。表示まわりの調整であれば対応できます」。できる範囲を同時に示すと、関係が切れません。
個人情報を扱う会員機能も同じ扱いにします。自動化の回で書いたとおり、個人情報は見ないで作れる形に寄せるのが原則です。
3. 「重いから速くしてほしい」だけの依頼
表示速度の改善は、原因が特定できるまで工数が読めません。サーバーの性能、画像の容量、プラグインの数、テーマの作り。どれが効いているかは調べないと分かりません。
この場合は、調査と改修を分けて見積もります。まず調査だけを受けて、原因と対策の一覧を出す。改修は別途。この分け方なら、時間が読めない仕事を固定価格で抱えずに済みます。
調査の納品物も決めておきます。計測した数値、影響が大きい順に並べた原因、それぞれの対策と想定工数。この3点が入っていれば、相手は次の判断ができます。
調査だけで終わっても構いません。原因がサーバーの性能なら、こちらの作業ではなく契約の変更で解決します。自分の作業にならない結論を出せる人は、信頼されます。
4. 誰が作ったか分からない独自テーマの大改修
前任者が独自に作ったテーマは、構造が読めないことがあります。ドキュメントもなく、命名も規則的でない。この状態での大きな改修は、調査だけで数日かかることがあります。
受注の前に、テーマのファイルを見せてもらってください。見てから判断する、と伝えるのは失礼ではありません。見ずに引き受けるほうが、双方にとって危険です。
見るときの観点は3つです。ファイル構成が一般的な形に沿っているか。コメントや命名から意図が読めるか。外部のサービスに依存している箇所がないか。ここで判断が付かなければ、調査を別見積もりにします。
1件にかかる時間と、見積もりの立て方
作業時間に公的な統計はありません。以下は「文章と画像の差し替え+軽微な表示調整」を想定した本メディアの想定モデルで、統計ではありません。
| 工程 | 時間 | やること |
|---|---|---|
| 環境の確認 | 30分 | バージョン、テーマ、プラグイン構成を把握 |
| バックアップ | 30分 | ファイルとデータベースの両方を取得 |
| 作業 | 60分 | 指定された変更を反映 |
| 確認 | 30分 | 表示、フォーム、スマートフォン表示を確認 |
| 報告 | 30分 | 変更点と、元に戻す手順を書いて渡す |
合計で3時間です。ここで分かるのは、実際の作業は全体の3分の1だということ。残りは確認と記録です。自動化の回と同じ構造で、この分野でも「作る時間」より「壊さないための時間」のほうが長くなります。
見積もりに書く4項目
金額でもめないために、次の4つを書いてください。
- 作業範囲:どのページの、どの部分を変えるか
- 対象外:デザインの提案、文章の作成、プラグインの新規導入など
- 前提条件:バックアップの有無、必要な権限、検証環境の有無
- 不具合対応の範囲:納品後◯日以内の、こちらの作業に起因する不具合は無償
特に3つ目です。前提が崩れた場合(バックアップが取れない、権限が足りない)は、見積もりの前提が変わったことを理由に再見積もりできます。これを書いておかないと、条件が悪いまま作業する羽目になります。
作業を始める前に、戻せる状態を作る
この分野の技術は、実は「戻せること」に集約されます。手順を決めておきます。
バックアップは2種類ある
WordPressのサイトは、ファイル(テーマ、プラグイン、画像)とデータベース(記事、設定)の2つで構成されています。どちらか片方だけでは、元に戻せません。
サーバーの管理画面から取る方法、プラグインで取る方法、契約しているホスティング会社の自動バックアップを使う方法があります。どれを使うかは環境によるので、受注時に確認した情報から選びます。
大事なのは、取るだけでなく戻せるか確認することです。バックアップがあると思っていたら中身が空だった、という事故は起こります。可能なら、作業前に一度戻す手順を確認しておきます。
取得したバックアップの保管場所と保管期間も決めます。相手のサイトのデータを自分の環境に置いたままにしない。作業が終わったら消す、という運用にしてください。
検証環境がない場合の進め方
本番しかない案件も多いです。その場合は、次の順番で進めます。
- バックアップを取る(ファイルとデータベースの両方)
- アクセスの少ない時間帯を選ぶ(深夜や早朝)
- 変更は一度に1つだけ行い、都度確認する
- 問題が出たらすぐ戻し、原因を切り分けてから再開する
この4つを提案の段階で相手に伝えると、それだけで信頼されます。「いつ作業しますか」を聞かれる前に、こちらから深夜帯を提案する。運用を分かっている人だと伝わります。
プラグインを増やす前に考える
機能追加の依頼に対して、プラグインを入れれば解決することは多い。ただ、プラグインは増えるほど更新の手間と衝突の可能性が増えます。
入れる前に、相手に確認してください。「この機能はプラグインの追加で実現できます。今後の更新管理が1つ増えますが、よろしいですか」。判断は相手に委ね、こちらは選択肢を示す。この形が安全です。
選ぶときの基準も持っておきます。更新が続いているか、利用実績があるか、使っているWordPressのバージョンに対応しているか。導入前に公式のディレクトリで確認できます。
案件の取り方と、最初の1件
実績ゼロからの入り方を書きます。
手順1:自分でサイトを1つ作って、壊して、直す
ポートフォリオのために作るのではありません。操作を体に入れるために作ります。テーマを入れ、子テーマを作り、プラグインを入れ、バックアップを取り、わざと壊して、戻す。
特に「戻す」経験が重要です。本番で初めて戻すことになると、手が震えます。自分のサイトで一度やっておけば、手順として処理できます。
壊し方も決めておくと学びになります。テーマのファイルに文法の誤りを入れて画面が真っ白になる状態を作り、そこから戻す。プラグインを更新して表示が崩れる状態を作り、無効化して戻す。実際の案件で起きるのは、だいたいこの2つです。
この練習にかかる費用は、レンタルサーバーの月額だけです。数百円から用意できるので、案件を受ける前の投資としては小さい。
手順2:小さい修正案件から応募する
文章の差し替え、画像の入れ替え、表示の調整。この帯の案件から入ります。提案文には、作業手順を書いてください。バックアップを取ってから作業すること、確認する項目、元に戻す手順を残すこと。
技術の説明より、この手順のほうが相手には伝わります。発注する側がいちばん恐れているのは、サイトが壊れることだからです。
提案文に入れる項目は4つで足ります。作業前にバックアップを取ること。アクセスの少ない時間帯に作業すること。変更を1つずつ反映して確認すること。変更点と戻す手順を書いて渡すこと。
この4行は、どの案件でも使い回せます。案件ごとに変えるのは、対象のページ名と作業内容だけです。
手順3:納品時に「保守の話」をする
1件終わったら、更新の話を必ずします。WordPress本体、テーマ、プラグインの更新は定期的に必要です。これを誰がやっているかを聞くと、たいてい「誰もやっていない」と返ってきます。
ここから月額の保守契約につながります。月1回の更新作業と、動作確認と、バックアップの確認。単発の修正より、この形のほうが双方にとって安定します。
保守の提案では、やることとやらないことを分けて書きます。含むのは更新と確認とバックアップ。含まないのは新機能の追加とデザインの変更。ここを分けないと、月額の中で作業が膨らみます。
金額は、作業時間ではなく「止まらない状態を維持する費用」として示します。更新が滞ったサイトは、ある日突然動かなくなります。その予防に払う金額だと伝われば、継続します。
つまずく場所は決まっている
この分野でつまずくのは、ほぼ5つです。
1. バックアップを取らずに触る
急ぎの依頼ほど、ここを飛ばしたくなります。飛ばしてはいけません。戻せない状態で作業して事故が起きると、副業どころの話ではなくなります。
時間がない場合の判断は明確です。バックアップを取る時間がないなら、その日は作業しない。これを最初に伝えておけば、無理な納期の依頼自体が来なくなります。
急ぎの依頼には、代わりの案を出します。「本日中の反映でしたら、バックアップの取得を含めて3時間ほど必要です。それが難しい場合は、明朝の作業をご提案します」。断らずに、条件を示す言い方です。
2. 複数の変更を同時に入れる
3か所の修正をまとめて反映して、表示がおかしくなる。原因の切り分けに時間がかかります。1つ入れて確認、を繰り返すほうが結局速い。
まとめて反映したくなるのは、確認の手間が惜しいからです。ただ、崩れたときの切り分けにかかる時間は、確認の手間の何倍にもなります。
複数のプラグインを同時に更新するときも同じです。1つずつ更新して表示を見る。面倒に見えますが、これが最短の手順です。
依頼が複数まとまって来た場合は、反映の順番も決めます。影響の小さいものから入れて、最後に影響の大きいものを入れる。途中で問題が出ても、戻す範囲が小さくて済みます。
3. スマートフォン表示を確認していない
パソコンの画面だけで確認して納品すると、スマートフォンで崩れていることがあります。多くのサイトでは、訪問者の大半がスマートフォンです。確認は必ず両方で行ってください。
確認する場所も決めておきます。変更したページ、そのページに移動するメニュー、問い合わせフォーム、そして記事の一覧。変更が他に波及していないかを見ます。
実機がなければ、ブラウザの表示幅を狭めて確認します。完全ではありませんが、大きな崩れはこれで見つかります。
4. 変更点を記録していない
どのファイルの何行目を、なぜ変えたか。これを残していないと、次に触るときに自分でも分かりません。別の人が引き継ぐときはなおさらです。
納品時に、変更点の一覧と元に戻す手順を渡してください。この資料があると、次の依頼が来る確率が上がります。引き継げる形で納品する人に、次の仕事が集まります。
書式は決めておくと毎回使えます。日付、変更したファイルまたは画面、変更の内容、戻す手順。4列の表で足ります。
記録はこちらの資産にもなります。同じような依頼が来たときに、手順を見返せば作業が速くなります。
5. 相手の運用を聞かずに提案する
使いやすい管理画面に変える提案をしても、相手が普段どう更新しているかを知らなければ的外れになります。誰が、どの頻度で、どこを更新しているのか。聞いてから提案してください。
聞き方は簡単です。「ふだんサイトを更新されるのはどなたですか。月にどれくらいの頻度で、どのページを触られますか」。この2問で、提案すべき方向が決まります。
更新する人がパソコンに不慣れなら、手順書を1枚付けるだけで喜ばれます。技術的な改修より、こちらのほうが効くことも多い。
30代につながるのは、他人の資産を壊さない作法
このメディアは、20代の副業を「30代に何が残るか」で選ぶ立場で書いています。WordPressの案件で残るのは、特定の管理画面の操作ではありません。
残るのは、他人が運用しているものに手を入れるときの作法です。現状を把握する、戻せる状態を作る、一度に1つだけ変える、記録を残す。この4つは、システムでも、業務フローでも、組織の仕組みでも同じです。
30代になると、既にあるものを引き継いで改善する仕事が増えます。ゼロから作る機会より、誰かが作ったものを触る機会のほうが多い。そのときに、壊さずに変えられる人は重宝されます。
もう1つ残るのが、リスクを金額として説明する力です。2時間の作業がなぜ30,000円なのか。止まったときの損失を引き受けているからだ、と説明できる。この感覚は、自分の仕事の値付けにも、他人への発注にも効きます。
まとめ
- WordPressの案件は「作る」より「直す」が多い。文章変更と画像差し替え(2〜3時間程度)で30,000円から、レスポンシブ無しのコーディングで30,000円から(クラウドワークス発注相場)
- 値段は難易度ではなく壊れたときの損失で決まる。作業時間だけで見積もると必ず安くなる
- 受注前に5つ確認する。サーバーとPHPのバージョン、テーマと子テーマ、バックアップ、検証環境、権限の範囲
- 公式の推奨はPHP 8.3以上・MariaDB 10.11以上またはMySQL 8.0以上。PHP 7.4やMySQL 5.5.5でも動作はするがサポート終了済みで、脆弱性の可能性が明記されている
- テーマを直接編集しない。公式は子テーマの利点として「親テーマを更新しても変更が失われない」ことを挙げている。孫テーマは存在せず、階層は親と子の2段階のみ
- 1件の想定モデルは3時間で、実作業は3分の1。残りは環境確認、バックアップ、確認、記録
よくある質問(FAQ)
未経験でもWordPressの案件は受けられますか。
文章の差し替えや画像の入れ替えといった小さい修正から入れます。ただし、その前に自分でサイトを1つ作って、テーマを入れ、子テーマを作り、バックアップを取り、わざと壊して戻す、という一連を経験してください。本番で初めて「戻す」ことになると、判断が遅れます。
2〜3時間の作業で30,000円は高くないですか。
作業時間ではなく、引き受けている責任で考えてください。公開中のサイトを触るので、表示が止まれば問い合わせも売上も止まります。クラウドワークスが発注者向けに公開している相場でも、この帯の作業が30,000円からとされています。安く受けると、止まったときの責任まで安く引き受けたことになります。
テーマのファイルを直接編集するのはなぜ駄目なのですか。
親テーマが更新されると、直接加えた変更は失われるからです。WordPress公式は子テーマの利点として「親テーマを更新しても変更が失われないようにする」ことを挙げています。更新にはセキュリティ修正が含まれるため、更新できない状態を作ることは、サイトを危険なまま放置することと同じです。
表示が遅いので速くしてほしい、という依頼は受けるべきですか。
原因が特定できるまで工数が読めないので、調査と改修を分けて見積もってください。まず調査だけを受けて、原因と対策の一覧を出す。改修は別途。この分け方なら、時間の読めない作業を固定価格で抱えずに済みます。
副業として始めるとき、確定申告や会社への影響はどうなりますか。
この記事ではWordPressの案件の中身だけを扱っています。副業全般の論点は姉妹メディア「20代の放課後」で扱っています。確定申告と20万円ルール、副業の始め方を参照してください。
案件に入る前に、子テーマの公式ドキュメントを読む
親テーマと子テーマの関係、上書きできる範囲、階層が2段階しかないこと。ここを理解しているかどうかで、納品物の寿命が変わります。