• 更新作業が案件数に比例して増える：10案件あれば毎月10回の更新と確認
• 緊急対応が読めない：脆弱性が公表されれば、その日のうちに全案件を確認することになる
• 属人化する：担当者が不在のとき動けない
• 収益にならない時間が増える：更新作業は請求しづらい

案件が増えるほど、制作に使える時間が削られていきます。しかも保守作業は、うまくいって当たり前で、評価されにくい仕事でもあります。

特に読めないのが緊急対応

定常業務は計画できますが、脆弱性の公表時期は選べません。制作の締切と重なったときに、社内だけで捌ききれるかが実質的な分かれ目になります。数十件の管理サイトがあれば、確認だけで丸一日が消えます。

定常業務

• 本体・プラグイン・テーマの更新と、更新後の表示確認
• バックアップの取得と保管
• 死活監視

臨時対応

• 脆弱性公表時の一斉確認と緊急更新
• 改ざん・障害発生時の調査と復旧
• PHPバージョンアップへの対応
• サーバー移転

効果が大きいのは臨時対応の方です。定常業務は社内でも計画的に処理できますが、臨時対応は自社の繁忙と無関係に発生します。

1. 更新前に検証環境で確認するか

本番でいきなり更新する運用かどうかです。エンドクライアントのサイトで表示が崩れれば、責任を問われるのは発注元である制作会社です。

2. バックアップの世代数と復元実績

取得しているだけで戻せない例は多くあります。世代数も重要で、1世代しか保持していなければ、改ざんに気づくのが遅れた場合に戻す先がありません。

3. 脆弱性公表時の初動

見落とされがちですが最も重要な項目です。全案件のバージョンを即座に把握できる体制かどうかで、初動が数時間変わります。

1件ずつ管理画面にログインして確認する体制だと、数十件で半日が消えます。管理サイトのバージョンを一覧で持っている委託先であれば、「対象は何件、うち何件が対応済み」を即答できます。

4. 報告の形式

エンドクライアントへそのまま提出できる形かどうかです。作業報告書があれば、制作会社側で書き直す手間が省けます。

5. エンドクライアントとの関係

直接接触しない契約になっているかを確認してください。下請けとして受ける側の姿勢の問題であり、窓口はあくまで制作会社様、という形を明示している委託先を選ぶと安心です。

1サイトあたり月額数千円〜が目安ですが、単価だけでなく臨時対応が含まれるかで実質的なコストは変わります。

定常業務だけ安く請け負い、障害対応は都度見積もりという形だと、いざというときに動けません。エンドクライアントから「すぐ直してほしい」と言われている場面で、見積もりのやり取りから始めることになります。

自社で抱える場合のコストとも比較してください。月1回の更新確認を10案件分行えば、それだけで10〜20時間です。担当者の時給換算に加え、その時間を制作に充てた場合の売上も含めて考えると、判断しやすくなります。

保守を外部に出すことに抵抗がある場合もありますが、「体制として複数人が対応できる」ことはむしろ説明材料になります。

担当者1人に依存している状態の方が、クライアントにとってはリスクです。「担当者が不在でも対応できる体制を整えました」という説明は、後ろ向きな話ではありません。

作業報告書が出る形にしておけば、毎月何をしているかも示せます。保守費用の妥当性を説明する材料にもなります。

いきなり全案件を委託する必要はありません。次のような始め方があります。

• 更新作業だけ依頼し、障害対応は自社で持つ
• 緊急時のみのスポット契約にする
• 手離れさせたい案件だけ、数件から委託する

数件で運用の質を確認してから広げる方が、認識のずれが起きにくくなります。

• 保守負担は案件数に比例する。特に臨時対応が読めない
• 委託先選びで最重要なのは脆弱性公表時の初動体制
• バージョンを一覧で把握できているかを確認する
• エンドクライアントとの窓口が守られる契約かを確認する
• 数件から始めて、運用の質を確認してから広げる