テーマ・プラグイン・権限・バックアップなど、触る前に確認したい項目を整理します。
「既存サイトのボタンを一つ追加してほしい」
「この部分だけレイアウトを変更してほしい」
画面を見る限りでは、簡単な修正に見えるかもしれません。
ところがWordPressの場合、ブラウザに表示されているページを見るだけでは、そのサイトが内部でどのように作られているのか分かりません。
テーマのテンプレートに直接書かれているのか。固定ページから管理しているのか。プラグインが生成しているのか。それとも独自の仕組みが組まれているのか。
見た目は同じでも、修正方法も必要な工数も変わります。
特に他社が制作したWordPressを修正するときは、
「どこを直すか」だけでなく、「現在どんな環境で動いていて、安全に修正できる状態なのか」
まで確認してから作業範囲を決めます。
1．必要なログイン情報と権限を確認する
既存のWordPressサイトを修正するときは、まずどこへアクセスする必要があるのかを確認します。
基本となるのは、WordPressの管理画面です。
ただし、管理画面へログインできるだけでは対応できない作業もあります。
私は原則として、WordPressに加えてFTPへ接続できる情報もお願いしています。
PHPファイルなどを変更した結果、エラーが発生すると、WordPressの管理画面そのものへ入れなくなる可能性があるからです。
その場合でもFTPへ接続できれば、変更したファイルを元へ戻せます。
クライアントがFTP情報を把握していない場合は、レンタルサーバーの管理画面へログインできる情報を確認します。
ここで意外と多いのが、
「WordPressのログイン情報」と「サーバーのログイン情報」
が区別されていないケースです。
「サーバーの情報をください」と伝えても分からない場合は、
「このページからログインできる情報をお願いします」
と、利用しているレンタルサーバーのログインページを具体的に案内すると伝わりやすくなります。
WordPressの権限は作業内容に合わせる
WordPressのアカウントを発行してもらう場合は、ログインできるかどうかだけでなく、どの権限が付いているかも確認します。
すべての作業で管理者権限が必要なわけではありません。
既存の記事や固定ページの文章・画像を変更するだけで、必要な編集画面へ入れるのであれば、現在の権限で対応できることもあります。
一方、他社制作サイトの見積り前調査では、
- 使用しているテーマ
- プラグインの構成やバージョン
- WordPress本体の状態
- 各種設定
- 今回の修正に関係する機能がどこで管理されているか
といった確認が必要になることがあります。
この場合、権限が限定されたアカウントでは必要な情報を確認できないことがあるため、調査用として管理者権限のアカウントをお願いすることがあります。
考え方としては、
「とりあえず管理者権限をもらう」のではなく、「今回どこを確認・変更するのかに合わせて必要な権限を用意してもらう」
という形です。
既存の管理者アカウントのIDとパスワードを共有してもらうのではなく、作業者用のアカウントを新しく発行してもらう方法もあります。
作業終了後にそのアカウントを削除してもらえば、クライアントが普段使っているログイン情報を共有せずに済みます。
サーバーやドメイン情報が必要になることもある
すべての案件で、サーバーやドメインの情報まで必要になるわけではありません。
今回どこまで変更するのかによって判断します。
たとえば、
- PHPのバージョンを確認・変更する
- SSLの設定を変更する
- FTP情報を確認する
- サーバー側の設定を変更する
といった作業が必要なら、レンタルサーバーの管理画面へ入れる状態にしてもらいます。
さらに、
- ドメインとサーバーの紐づけを変更する
- DNS設定を変更する
といった作業まで含まれる場合は、ドメイン管理サービスの情報も必要です。
最初からすべてのIDとパスワードを集めるのではなく、今回の作業範囲に必要なログイン情報と権限を用意してもらうと考えると整理しやすくなります。
2．正式な見積り前にサイトの中を確認する
他社制作サイトでは、できるだけ正式な見積りを出す前にWordPressへログインし、現在の状態を確認します。
公開ページだけを見て、
「この修正なら○円くらいです」
と決めてしまうのは避けたいところです。
公開ページを見ることと、WordPressの中を見ることは、建物の外観を見ることと内部を調査するくらい違います。
WordPressでは、テーマ、テンプレート、固定ページ、プラグインなど、さまざまな処理を経た結果がHTMLとしてブラウザに表示されています。
外から同じように見えても、内部の実装はまったく違うことがあります。
まず確認したいのは、
- WordPress本体のバージョン
- PHPのバージョン
- 使用しているテーマ
- 使用しているプラグイン
- 各プラグインの更新状況
です。
古い環境では、今回使おうとしているプラグインが対応していないこともあります。
長期間アップデートされていないテーマやプラグインが残っている場合は、今回の修正とは直接関係がなくても、将来的に互換性やセキュリティ上の問題が出る可能性があります。
ただし、見つけた問題をすべて今回の修正へ含める必要はありません。
依頼された修正に関係するものと、今後の保守として考えるものを分けます。
3．修正したい内容がどこで管理されているか確認する
次に確認するのが、今回変更したい内容がどこで管理されているかです。
同じWordPressサイトでも、作り方はさまざまです。
たとえば、
- 固定ページ
- 投稿
- テーマのテンプレートファイル
- カスタムフィールド
- ページビルダー
- プラグイン
- 独自に作られた管理機能
などがあります。
ここが分からないままでは、正確な工数を出せません。
たとえば、
「既存ページの文章を少し変更するだけ」
という依頼だったとします。
固定ページから文章を変更するだけなら、比較的短時間で対応できるかもしれません。
ところが実際にはテンプレートへ直接書かれていて、
「今後はクライアント自身でも更新できるようにしたい」
という要望まで含まれるのであれば、単なる文章変更ではありません。
固定ページやカスタムフィールドなどへ移し、管理画面から更新できる仕組みに変更する必要があります。
当然、必要な工数も変わります。
だから私は、見積りを出してから初めて中を見るのではなく、できるだけ見積り前に現在の実装方法を確認します。
4．独自実装や特殊な構成がないか確認する
他社制作サイトでは、一般的なWordPressの作り方がされているとは限りません。
独自のフレームワークが組まれていたり、通常とは違う構成になっていたりすることもあります。
たとえば、
- functions.phpに大量の独自処理が書かれている
- 独自プラグインが使われている
- プラグイン本体が直接改造されている
- 用途の分からない独自ファイルが残っている
- 一般的なテーマ構成とは違う方法でページが生成されている
といったケースです。
こうしたサイトでは、
「WordPressなら普通はここを編集すればいい」
という方法が通用しないことがあります。
修正内容そのものは簡単でも、
どこを変更すれば目的の結果になるのかを特定するための調査
に時間がかかることがあります。
この調査工数も、他社制作サイトを見積るうえでは無視できません。
5．子テーマとライセンスを確認する
子テーマが使われているか
テーマをカスタマイズする場合は、子テーマが使われているかも確認します。
子テーマがない場合は、
- 親テーマをそのまま使っているだけなのか
- 親テーマ自体を直接書き換えているのか
まで確認します。
親テーマを直接変更している場合、テーマをアップデートすると、その変更内容が上書きされる可能性があります。
そのため作業内容によっては、子テーマの導入を含めて見積ることもあります。
ただし、
「正しい作り方だから必ず子テーマに変更する」
と一方的に決めるわけではありません。
子テーマを用意すれば、その分の工数もかかります。
現在の環境のまま修正することをクライアントが希望する場合には、
テーマをアップデートすると今回の変更内容が失われる可能性があること
を事前に伝えます。
必要であれば、
「テーマアップデートによって変更内容が消失した場合は保証対象外」
などの条件も見積書へ記載します。
必要な工数とリスクを説明したうえで、どこまで対応するのかを決めます。
有料テーマ・プラグインはライセンスも確認する
有料テーマや有料プラグインが使われている場合は、
「そのライセンスを誰が所有しているのか」
も確認します。
他社制作サイトでは、以前の制作会社が所有しているライセンスを使って構築されていることがあります。
その制作会社との契約が終了すると、アップデートや有料機能を利用できなくなる場合があります。
今回の修正に関係する製品であれば、
- 誰がライセンスを所有しているか
- 現在も有効なのか
- アップデートできるのか
- 今後も使い続けられるのか
を確認します。
たとえば、サイト全体がElementor Proに依存して作られていたとします。
クライアント自身は制作会社へすべて任せていたため、ライセンスについて何も知らない。
確認するとライセンスが失効しており、今回必要な機能を利用できない。
その場合は、
- クライアント自身にライセンスを契約してもらう
- 別の方法で実装する
- 代替プラグインへ変更する
といった判断が必要になります。
別の方法へ変更するのであれば、調査や実装にも追加の工数がかかります。
こうした事情も、見積り前に分かるほど安全です。
6．問題が起きたときの戻し方を決める
既存サイトを触るからといって、私はすべての案件でサイト全体のバックアップを取っているわけではありません。
作業範囲と、問題が起きた場合の戻し方で判断します。
たとえば、テンプレートファイルを一つ変更するだけなら、変更前のファイルをローカルへ保存しておくだけで十分な場合もあります。
一方で、
- 複数のファイルを変更する
- データベースへ影響する
- プラグインを大きく変更する
- WordPress本体やPHPを更新する
といった場合は、サイト全体のバックアップを取ることもあります。
Gitでバージョン管理されているサイトなら、その運用方法も確認します。
制作会社や複数の担当者が同時に触っている場合は、誰がどこを変更したのか分からなくならないようにする必要があります。
サーバーの自動バックアップも確認材料にはなりますが、それだけを当てにはしません。
サーバーによっては自動バックアップが有料オプションで、クライアントが契約していないこともあります。
また、サイト全体を復元すると、今回の作業後に行われた投稿更新などまで元へ戻ってしまう可能性があります。
重要なのは、
「バックアップを取ったか」ではなく、「今回の作業で問題が起きたとき、どの方法なら安全に元へ戻せるか」
を考えておくことです。
7．古い環境を勝手にアップデートしない
他社制作サイトへログインすると、
「WordPressもPHPもプラグインも何年も更新されていない」
ということがあります。
だからといって、依頼された修正と一緒に、勝手にすべてアップデートすることはしません。
現在の環境のまま依頼された修正を実現できるのであれば、まずその修正を行います。
古い環境については、
「現在かなり古いバージョンで動いているため、このままでは将来的に不具合やセキュリティ上の問題が発生する可能性があります」
と別の話として伝えます。
必要であれば、
「アップデート対応もできます」
と提案します。
一方、今回の修正を実現するためにアップデートが必要なら話は別です。
たとえば、追加したいプラグインが現在のPHPでは動かない場合です。
その場合は、
「今回の機能を追加するには、先にPHPの更新が必要です」
と理由を説明し、今回の修正とは別の作業として見積りへ追加します。
古いサイトのアップデートは、ボタンを一つ追加するような修正とは性質が違います。
PHPを上げたことで古いプラグインが動かなくなるなど、別の不具合が発生する可能性があるからです。
修正は修正、保守は保守。
分けて説明したほうが、
「少し直してもらうだけなのに、なぜこんなに費用がかかるの？」
という疑問も生まれにくくなります。
8．本番で直すか、テスト環境を作るかを決める
すべての修正でテスト環境を作る必要はありません。
判断基準の一つは、
「問題が起きたときに、すぐ元へ戻せるか」
です。
たとえば、対象ファイルを一つ変更するだけで、問題が起きても変更前のファイルへ戻せるなら、本番環境で対応することもあります。
一方で、
- PHPのバージョンを変更する
- WordPress本体を大きく更新する
- 複数のプラグインへ影響する変更を行う
- サイト全体の表示や機能へ影響する可能性がある
といった場合には、テスト環境を作って事前に確認することがあります。
テスト環境を作ること自体にも作業時間はかかります。
必要な場合は、
- テスト環境構築
- アップデート検証
などとして見積りへ入れます。
安全のために必要な工程だからといって、見えないところで無料対応する必要はありません。
9．既存の不具合と今回の修正を切り分ける
他社制作サイトでは、今回の修正とは関係のない不具合がすでに存在していることもあります。
注意したいのは、修正後にクライアントがその不具合へ初めて気づいた場合です。
「今回の修正で壊れたのでは？」
と思われる可能性があります。
だからといって、着手前にサイト全体をくまなく調査し、すべての状態を記録するのは現実的ではありません。
私は、作業中に既存の不具合へ気づいた場合には、
「今回の修正箇所とは別ですが、こちらに以前からの不具合と思われる症状があります」
と伝えるようにしています。
先に共有しておけば、今回の作業との切り分けもしやすくなります。
軽微なものであれば、状況によっては費用内で対応することもあります。
それなりの作業が必要なら、
「こちらも修正できますが、追加で○円かかります」
と提案します。
原則として、既存不具合の修正は今回の作業範囲外です。
必要であれば、この点も見積書へ記載しておきます。
10．想定外の作業が必要なら、いったん止める
事前に調査していても、実際に作業を進めて初めて分かることはあります。
たとえば、
「ボタンを一つ追加するだけ」
だったはずが、既存のテンプレート構造そのものを変更しなければ実現できない。
使う予定だったプラグインが、現在のPHPやWordPressに対応していない。
こうした場合に、こちらの判断だけで作業範囲を広げることはしません。
基本は、
- 調査する
- 現在の状況を説明する
- 必要な作業を提示する
- 追加見積りを出す
- 承認をもらう
- 作業する
という順番です。
クライアントへ説明するときも、
「PHPのバージョンが……」
「プラグインの互換性が……」
と技術用語だけを並べないようにします。
クライアントが知りたいのは専門用語ではなく、
「なぜ最初に聞いていた修正だけでは済まないのか」
だからです。
たとえば、
「古い設備のままでは新しい機器を取り付けられないので、先に設備側の対応が必要な状態です」
と説明すれば、状況を想像しやすくなります。
Webサイトも、作って終わりではありません。
長く使っていれば、WordPress本体、PHP、テーマ、プラグインなどの環境は古くなっていきます。
これまで定期的に保守されていれば、今回は依頼された修正だけで済んだかもしれません。
しかし、長期間メンテナンスされていなかったため、新しい機能を安全に追加するには、先に環境を整える必要がある。
そこまで説明できれば、追加作業が必要な理由も理解してもらいやすくなります。
技術を知っていることと、技術を相手が理解できる話に置き換えられることは別です。
既存サイトの修正では、この説明も大切な仕事の一つです。
他社制作WordPressを修正する前の確認項目
他社が制作したWordPressだからといって、それだけで断る必要はありません。
危険なのは、
「見たところ簡単そうだから、○円でできます」
と、内部を確認せずに約束してしまうことです。
見積り前には、少なくとも次の点を確認します。
- 必要なログイン情報と権限がそろっているか
- WordPress本体やPHPのバージョンはどうなっているか
- どのテーマ・プラグインが使われているか
- 修正したい内容はどこで管理されているか
- 独自実装や特殊な構成がないか
- 子テーマが使われているか
- 有料テーマ・プラグインのライセンスは利用できるか
- 問題が起きた場合に元へ戻せるか
- 本番作業でよいか、テスト環境が必要か
- 今回の修正と既存不具合・保守作業を切り分けられているか
ここまで確認してから、作業範囲と金額を決めます。
もちろん、デザイナー自身がPHPやテーマの構造を解析する必要はありません。
クライアントから、
「以前、別の会社に作ってもらったWordPressなんですが、修正できますか？」
と相談されたら、
「既存サイトなので、一度コーダーに中の状態を確認してもらってから正式にお見積りします」
と答えれば十分です。
分からないから案件を断るのでも、分からないまま金額を約束するのでもありません。
安心して仕事を受けるために、見積り前に内部を確認する。
私は、すでに完成しているWordPressサイトについても、実際の環境を確認したうえで、修正方法や必要な作業を一緒に整理しています。