WordPressでホームページを作るかどうかは、製品名の知名度だけでは決められません。公開後に誰が何を更新し、判断できない問題を誰へ相談するかまで確認する必要があります。
メリットとデメリットは、サイトの構成や運用体制によって変わります。候補となる構成を実際に確認し、自社の作業へ当てはめて判断します。
必要な更新作業から検討する
最初に、公開後に変更する情報を一覧にします。お知らせ、サービス案内、採用情報などを分け、変更する人と承認する人を決めます。
更新の回数ではなく、一回の作業に必要な原稿、画像、確認項目を書き出します。自社で行う作業と制作会社へ依頼する作業を区別します。
WordPressを候補にする場合は、予定する作業を管理画面で実演してもらいます。説明だけで判断せず、担当者が安全に操作できる範囲を確かめます。
メリットは更新体制で決まる
承認済みの原稿を担当者が反映できる構成なら、日常の変更を社内で行う選択肢になります。ただし、操作できることと、公開内容を判断できることは別です。
社内更新を利点として考えるなら、入力方法、確認用の画面、差し戻し、公開後の確認までを一連の手順として試します。担当交代時の教育方法も確認します。
後から別の機能を加える予定がある場合は、希望だけを伝えるのでは不十分です。候補の構成で対応できるかを、公式資料と制作仕様で確認します。
デメリットは保守範囲に表れる
管理する人が決まっていないサイトでは、変更依頼や問題時の判断が止まります。誰でも触れる状態にせず、通常作業と管理作業の責任を分けます。
外部の構成要素やサービスを組み合わせる提案では、管理対象が増えます。各要素の提供元、確認方法、問題時の窓口を一覧にしてください。
仕様や提供条件は変わる可能性があるため、記憶で運用手順を書きません。利用中の構成に対応する公式資料を確認し、参照日を作業記録へ残します。
管理権限と公開承認を分ける
権限は役職ではなく作業に合わせて決めます。原稿入力、内容確認、公開、管理設定を分け、必要な範囲だけを担当者へ割り当てます。
管理に使う認証情報は、個人の連絡先や共有文書へそのまま残しません。保管方法、利用できる人、担当変更時の手続きを社内規程に合わせます。
公開を急ぐ場合も、承認を省略しないことが大切です。事実確認が終わらない内容は下書きとして保留し、確認先と再開条件を記録します。
制作会社へ同じ条件で聞く
制作会社を比べるときは、WordPressを使うかだけでなく、完成後に受け取るものと支援範囲を同じ依頼票で確認します。
- 自社で変更できるページと項目
- 制作会社へ依頼する管理作業
- 追加機能を判断する資料と手順
- 問題が起きたときの連絡経路
- 変更前の保存と復旧を判断する担当
- 契約終了時に受け取るデータと記録
「対応可能」という回答だけで終わらせず、対象、前提、対象外を見積書や仕様書へ残します。確認できない機能や効果は採用理由にしません。
導入後の引き継ぎを設計する
公開時には、管理者、契約、操作資料、原稿や画像の保管場所を一覧にします。制作時の担当者だけが分かる状態を残さないようにします。
最初の更新は範囲を限定し、依頼から公開後の確認までを実際に行います。迷った箇所を操作資料へ戻し、次の担当者が同じ手順で進められるかを見ます。
構成を変更するときは、対象、影響範囲、戻し方、承認者を先に決めます。公式資料で判断できない項目は、提供元または保守担当者へ確認します。
