更新範囲・管理方法・既存環境など、見積り前に確認しておきたい項目を整理します。
WordPress案件の見積りでは、デザインカンプに見えているページだけを数えても、実際の制作範囲を把握できないことがあります。
「ブログを付けたい」
「問い合わせフォームが欲しい」
「このサイトのようなものを作りたい」
クライアントからの要望はシンプルでも、その言葉だけでは必要なページや機能、実装方法までは分かりません。
受注したあとで、
「このページも必要だった」
「ここはクライアント自身で更新したかった」
「この機能を入れるには、別の対応も必要だった」
と分かれば、見積りに入れていなかった作業が増えてしまいます。
WordPress案件では、見積りを出す前に「画面に見えているもの」だけでなく、実際に必要になるページ、更新方法、納品後の管理、既存環境まで確認しておく必要があります。
私が事前に確認しておきたいと考えているポイントを、7つに分けて紹介します。
1．「何ページあるか」を自分でも確認する
クライアントから、
「このサイトと同じくらいのものを作りたいのですが、いくらくらいですか？」
と、参考サイトのURLだけを渡されることがあります。
このとき、トップページや目についた数ページだけを見て「○万円くらいです」と答えるのは避けたいところです。
まず参考サイトを実際にたどり、どのようなページがあるのかを確認します。
特に見落とされやすいのがブログです。
「ブログのページ」とひとまとめにされることがありますが、WordPressでは、たとえば次のようなページがあります。
- 投稿一覧ページ
- カテゴリーページ
- タグページ
- 投稿詳細ページ
デザインカンプには投稿一覧と投稿詳細だけが用意されていて、カテゴリーやタグのページまでは考えられていないこともあります。
参考サイトをもとに見積る場合は、こちらでも制作対象を確認し、
「今回は、この○ページを制作する想定での見積りです」
と、どこまでを含めているのか分かるようにしておきます。
また、同じ「1ページ」でも作業量は同じではありません。
短い会社概要ページと長いLPでは工数が違いますし、複雑なレイアウトやアニメーションがあれば、その分だけ実装と確認にも時間がかかります。
そのため、参考サイトを見るときはページ数だけでなく、
本当にそのサイトと同程度のページ数・ボリューム・動きを求めているのか
まで確認します。
2．デザインされていない画面がないか確認する
デザインカンプが一通り揃っているように見えても、実装に必要な画面がすべて用意されているとは限りません。
たとえば問い合わせフォームなら、
「入力画面はあるけれど、確認画面と送信完了画面がない」
ということがあります。
サイト内検索があれば、検索窓だけではなく検索結果を表示するページも必要です。
ECサイトなら、商品ページだけでなく、
- カート
- 購入手続き
- 決済
- マイページ
など、ユーザーが操作した先にも複数の画面があります。
ブログも同じです。
投稿一覧だけでなく、カテゴリー、タグ、投稿詳細など、実際にユーザーがたどるページまで確認します。
見積り前には「カンプが何枚あるか」だけで判断せず、一度利用者になったつもりで、
「問い合わせボタンを押したあとは？」
「検索したあとは？」
「記事一覧から記事を開いたあとは？」
と、操作の流れをたどってみます。
その先に必要になる画面が、デザインとして用意されているかを確認します。
カンプの枚数と、実装しなければならない画面数は同じとは限りません。
3．どこを更新できるようにするのか決める
「WordPressだから、更新できるようにしてください」
これだけでは、実装方法を決めることはできません。
確認したいのは、
どこを、誰が、何のために変更したいのか
です。
たとえばLPでも、
- 価格だけ変更したい
- キャンペーン期間を変更したい
- 写真や文章も差し替えたい
- 公開後の変更は制作者へ依頼する
といった違いがあります。
どこまでクライアント自身で変更するのかによって、必要な仕組みも変わります。
HTMLで制作するLPでも、
「できるだけテキストにしてください」
と依頼されることがあります。
ただ、「できるだけ」では人によって想定している範囲が違います。
たとえば、
- 見出しまでHTMLにするのか
- 装飾されたキャッチコピーは画像にするのか
- 価格や注意書きだけテキストにするのか
によって作り方も工数も変わります。
私の場合、判断が曖昧なときはデザインカンプ上の該当箇所に色を付けてもらうなどして、テキストとして実装する場所を明確にします。
必要であれば、こちらでカンプに色を付けて、
「この部分をテキストとして実装する想定ですが、よろしいですか？」
と確認することもあります。
「更新できるようにする」という言葉だけで合意せず、実際にどこを変更できるようにするのかまで決めることが重要です。
4．「誰が更新するのか」まで考える
更新できる仕組みを作っても、実際に使う人が操作できなければ意味がありません。
そこで、更新箇所と一緒に、
「実際に更新するのは誰ですか？」
という点も確認します。
たとえば、
- Web担当者が更新する
- 店舗スタッフが更新する
- 社長自身が更新する
- 制作者へ毎回依頼する
では、使いやすい仕組みが違います。
WordPressの更新方法にも、ブロックエディターやカスタムフィールドなど複数の方法があります。
制作者にとって扱いやすい方法が、クライアントにとっても使いやすいとは限りません。
Webサイトの操作に慣れていない人が更新するのであれば、入力欄を分かりやすく分けるなど、使う人に合わせた仕組みにしたほうが運用しやすくなります。
また、制作時に決めた運用方法が、その後もずっと続くとは限りません。
以前、制作時にはデザインを優先し、
「クライアント側で更新できる必要はない」
という前提で作られたサイトについて相談を受けたことがあります。
ところが運用が始まってから、コストを抑えるためにクライアント自身で更新したいという方針に変わりました。
しかし、コンテンツはテンプレートへ直接ハードコーディングされており、管理画面から簡単に変更できる作りではありませんでした。
WordPressで作られているからといって、すべての文章や画像を管理画面から変更できるとは限りません。
あとから更新方法を変える場合、追加のカスタマイズが必要になることもあります。
将来の運用をすべて予測することはできませんが、制作時点で少なくとも、
- 誰が更新する予定なのか
- どのくらいの頻度で更新するのか
- どこまで自分たちで変更したいのか
は確認しておくと、実際の運用に合った作り方を選びやすくなります。
5．納品後、WordPressを誰が管理するのか確認する
確認しておきたいのは、記事や画像の更新だけではありません。
WordPressそのものを、納品後に誰が管理するのかも決めておく必要があります。
たとえばWordPressをインストールするとき、制作を担当したコーダーが自分のメールアドレスを管理者メールアドレスとして登録することがあります。
制作中であれば、それでも問題ない場合があります。
ただ、そのまま納品すると、WordPressからの通知が納品後もコーダーへ届き続けることがあります。
一方でクライアントには通知が届かず、WordPressやプラグインの更新が必要なこと自体が伝わっていない、という状態になる可能性もあります。
納品前には、
- 納品後の管理者は誰なのか
- WordPressやプラグインを誰が更新するのか
- 保守契約を結ぶのか
- クライアント自身で管理するのか
を確認します。
クライアント管理にするのであれば、管理者メールアドレスをクライアント側のものへ変更するといった引き継ぎも必要です。
サイトを作る人と、納品後に管理する人は同じとは限りません。
「納品したら終わり」なのか、「その後の保守まで担当する」のか。
ここを決めておくと、納品後の担当範囲も分かりやすくなります。
6．既存サイトの改修は、画面だけを見て見積らない
新規制作以上に注意したいのが、既存のWordPressサイトを修正・改修する案件です。
ブラウザに表示されているサイトだけを見ても、内部でどのように作られているのかは分かりません。
たとえば、
「ここの文字を変更したい」
「この部分にボタンを一つ追加したい」
という依頼なら、見た目だけでは簡単そうに感じるかもしれません。
しかし、実際に確認すると、
- 独自に改修されたテーマ
- 古いPHP環境
- 特定のプラグインへの強い依存
- テンプレートへの直接記述
などが見つかることがあります。
私の場合、可能であればWordPressのログイン情報だけでなく、サーバーやFTPの情報も預かり、実際の環境を確認します。
見るのは、たとえば次のような項目です。
- WordPressとPHPのバージョン
- 使用しているテーマと子テーマ
- 使用中のプラグイン
- 有料プラグインの有無
- テンプレートへ直接ハードコーディングされているか
- 固定ページ側にコンテンツが入っているか
- 独自の仕組みやフレームワークが使われていないか
ここまで確認するのは、依頼された変更そのものよりも、その変更を安全に行うための別作業が必要になることがあるからです。
ボタンを一つ追加するだけでも、その前にテーマの構造を調べなければならないことがあります。
PHPのバージョンが古ければ、安易に環境を変更すると別の部分が動かなくなる可能性もあります。
有料プラグインを使っていれば、ライセンスや更新状況の確認が必要になる場合もあります。
こうした事情は、サイトの表側だけを見ても判断できません。
既存サイトの改修では、すぐ金額を出すのではなく、
「今、このサイトがどういう状態なのか」
を確認してから見積ることが重要です。
7．実装方法が分からない機能は、仕様を決める前に相談する
WordPress案件を受けるからといって、すべての機能について自分一人で実装方法まで判断できる必要はありません。
たとえばクライアントから、
「いくつかの質問に答えると、回答によって違う結果を表示する診断コンテンツを作りたい」
と相談されたとします。
あるいは、
「流入してきた広告媒体によって、LPのCTAのリンク先を自動的に変えたい」
という要望が出てくることもあります。
こうした機能を作った経験がなければ、
- そもそも実現できるのか
- どんな方法で作るのか
- どのくらい工数がかかるのか
- クライアントから何を聞けばよいのか
が分からなくても不思議ではありません。
避けたいのは、分からない状態のまま、
「たぶん、こういう作り方だろう」
と仕様を決めて見積りを出してしまうことです。
受注後になって、
「想定していた方法では作れなかった」
「実装に必要な情報を聞いていなかった」
「見積った工数では収まらなかった」
となれば、制作側だけでなくクライアントにも影響します。
分からない機能が出てきたら、全部を理解してから相談する必要はありません。
クライアントから要望を聞いた段階で、
「こういう機能を希望されているけれど、実現できる？」
「見積り前に何を確認しておけばいい？」
「クライアントには、どこまで仕様を決めてもらえばいい？」
と技術者へ相談できます。
その時点で相談すれば、実装方法を考えながら、クライアントへ追加で確認する内容も整理できます。
仕様が固まってから技術者へ渡すのではなく、仕様を決める段階から相談する。
そういう進め方もできます。
見積り前に確認したい7項目
WordPress案件の見積りでは、デザインカンプやページ数だけでは見えない作業があります。
見積りを出す前に、最低限次の7項目を確認してみてください。
- 必要なページはすべて把握できているか
- デザインされていない画面はないか
- どこを更新できるようにするのか
- 誰が更新するのか
- 納品後は誰がWordPressを管理するのか
- 既存サイトなら内部環境を確認できているか
- 分からない機能を自分だけで判断していないか
この中に、
「ここは自分では判断しにくい」
というものがあれば、その段階で技術者へ相談して構いません。
私も、クライアントから要望を聞いたばかりの段階で、
「これは実現できる？」
「何を確認しておけばいい？」
「どのくらいの工数を見ておけばいい？」
というところから相談を受けています。
必要であれば、実装方法や確認事項を整理したあと、そのままコーディングやWordPress制作まで担当することもできます。
仕様が固まってから依頼するのではなく、仕様を固めるために相談する。
技術的に判断できない要件が出てきたときは、無理に答えを出してから進めず、その段階で一度相談してください。