ホームページの更新が止まる理由。担当者任せにしない運用のつくり方

更新が止まっていると、「担当者がもっと時間を取れれば」と考えがちです。ところが実際に止まっている依頼をたどると、原稿が担当者に届いていない、テストアップしたまま上長が承認をしていない、ということもあります。原稿待ちなのか、承認待ちなのか、入力の時間がないのか。どこで止まっているかによって、助けるべき相手は変わります。

必要なのは、担当者を励ますことより、「次に誰が動くか」が決まっていない場所を見つけることです。その場所は、直近の更新を1件たどれば見えてきます。

止まっている更新を1件たどる

直近で公開できなかった情報を1件選び、依頼から公開までを順に追います。「忙しかった」で終えず、次の工程へ進むために何が足りなかったかを書き出します。

止まる場所	よくある不足	見直すこと
情報の収集	何を渡せばよいか依頼元が分からない	依頼時に聞く項目
原稿の作成	元情報が足りない	情報を持つ担当者
内容の確認	最終的に判断する人が決まっていない	承認者と期限
入稿	操作や画像加工が難しい	入力方法とテンプレート

右列のとおり、止まった工程によって直す対象は違います。入稿で止まっているのに受付の様式を整えても、承認待ちなのに担当者の作業時間を増やしても、依頼は進みません。

未着手の件数より、待っている理由を見る

更新依頼が10件たまっていたら、待っている理由で分けてみてください。元情報が足りないもの、掲載してよいか確認中のもの、公開日を待っているもの。こう分けると、担当者の作業量だけでは解けない問題が見えてきます。

営業部門から実績の掲載を頼まれたものの、顧客の掲載許可がまだ取れていない。この状態で先に必要なのは、入稿ではなく許可の確認です。誰が顧客に確認し、回答をどこへ残すかを決めない限り、担当者をいくら急かしてもこの依頼は動きません。

一方、担当者がすぐ手を動かせる依頼だけで予定が埋まっているなら、作業量と体制の問題です。公開順の調整、素材の準備を依頼元へ戻すこと、入稿の外部委託などを検討します。

依頼を1か所に集め、次に動く人を書く

メール、チャット、口頭で受けた依頼を、1つの一覧に集めます。依頼が担当者の受信箱や記憶に埋もれず、今どこで止まっているかを誰でも確かめられる状態にするためです。

記録する項目は、依頼内容、元情報、希望日、作業担当、承認者、現在の状態です。受付日と、最後に状態が変わった日も残しておくと、長く止まったままの依頼を見つけやすくなります。判断に使わない項目は入力が続かない原因になるため、増やしすぎないようにします。

状態は「次の作業」を動詞で書く

状態欄が「確認中」だけでは、誰の返答を待っているのか分かりません。「営業担当が掲載許可を確認する」「事業責任者が料金表を承認する」のように、次の行動と担当者を書きます。期限を過ぎたときの連絡先も決めておけば、Web担当者が毎回判断者を探し回らずに済みます。

定期的な確認の場では、全件を報告するより、止まっている依頼と期限が近い依頼に絞ります。担当者が判断できない項目だけを責任者へ上げ、着手できる作業は進めます。確認の頻度は依頼数や公開期限に合わせ、管理のための会議そのものが負担になっていないかも見直してください。

依頼時に聞く項目を、更新の種類ごとに絞る

すべての依頼に長い申請書を求めると、受付を統一しても使われなくなります。日時や連絡先の変更なら、対象のページ、変更前後の内容、反映希望日、確認者が分かれば進められるでしょう。新しいサービスの掲載なら、目的、対象者、提供範囲、料金や利用条件など、原稿に必要な情報が増えます。

あわせて、情報の出所も残してもらいます。価格なら承認済みの資料、イベントなら開催要項、実績なら掲載可能な範囲を確認した記録です。担当者が過去のメールから正しい版を探す時間が減り、どの資料をもとに更新したかを後から確かめられます。

「急ぎ」とだけ書かれた依頼には、理由と期限を確認します。イベントや商品の発売などに合わせた変更と、単に早いほうがよい変更では優先度が違います。依頼元の勢いではなく、期限の根拠と影響で順番を決められるようにしておきます。

よく出す記事は、型と公開基準を先に決める

お知らせ、実績、イベント案内のように繰り返し出す記事は、見出しと必要な項目を決めた型を用意します。原稿を書く人は空欄を埋めればよく、確認する人も抜けている項目をすぐ見つけられます。

型を決めるときに、写真を必須にするかも決めます。見た目をそろえたい実績記事では写真を求め、営業日の変更のような連絡は文字だけで出してよい、という区別です。ここを決めないまま「写真があるほうがよい」で運用すると、写真待ちが公開を止める理由になります。

承認は省かず、判断する範囲を分ける

すべてを経営者が確認する運用では、確認が1人に集中して止まりやすくなります。かといって、担当者だけで価格や契約条件を変えてよいわけでもありません。表記の訂正は入稿担当、通常のお知らせは部門の責任者、料金や提供条件の変更は事業責任者というように、変更の種類ごとに確認者を分けて社内で合意します。

原稿の事実確認と、画面の表示確認も別の作業です。価格や条件は情報を持つ部署、表記やリンクは入稿担当、公開の最終判断は権限を持つ人と分けます。全員が同じ範囲をなんとなく見る方式では、確認が重なる一方で、肝心の項目が誰にも見られないまま公開されることがあります。

承認者には、判断する箇所が分かる形で渡します。ページのURLだけを送るより、変更の目的、対象箇所、公開希望日を添えたほうが、何を判断すればよいか伝わります。

多くのCMSはユーザーごとに権限の設定が可能です。WordPressの場合で言えば、標準の「寄稿者」は自分の投稿を書けても公開はできず、「編集者」は他の人の投稿も公開・管理できます。下書きまでを担当者、公開を判断者と分ける運用は、画面の権限と合わせて設計できます。

出典：Roles and Capabilities – WordPress.org Documentation

緊急時の承認者も、平常時に決めておく

誤った電話番号の修正など、すぐ直すべき変更もあります。緊急だからといって確認の記録をなくすのではなく、急ぎの変更を誰が承認できるかを平常時に決めておきます。通常の担当者が不在のときの連絡先を定め、対応後に変更内容を共有する流れも用意します。

公開したことと、更新が終わったことを分ける

公開ボタンを押した後も、対象ページで正しく表示されるか、関連ページに古い情報が残っていないかを確かめます。例えばサービス名を変えたなら、一覧ページ、会社案内、問い合わせフォームの選択肢にも同じ名称が使われているかもしれません。依頼を受けた1ページだけ直して完了にすると、サイトの中で説明が食い違います。

確認を終えたら、依頼元に対象ページと反映内容を伝え、一覧の状態を完了にします。期限を過ぎると不要になる情報なら、非公開や見直しの予定も同時に登録してください。

新規掲載と、既存情報の点検を別の予定にする

新しいお知らせには依頼が来ますが、古いページの誤りは誰からも指摘されないことがあります。毎週記事を出すことだけを目標にすると、終了したサービスや古い料金が残ったままになりかねません。更新頻度とは別に、必要な情報が正しく保たれているかを見る予定を持ちます。

最初は、主力サービス、会社情報、問い合わせ先に絞って、情報を持つ部署と確認する時期を決めます。料金は価格改定のとき、役員や所在地は登記や人事の変更のときのように、変更が起きる社内業務と結びつけると点検が漏れにくくなります。過去のイベント案内は一律に消さず、終了したことが分かるか、現在の受付と誤解されないかで扱いを決めます。

人を増やす前に、任せる範囲を決める

外部に更新を頼んでも、情報が正しいかどうかの判断や、事業上の判断は自社に残ります。原稿作成、画像加工、入稿、表示確認のどこを任せ、元情報と最終承認を誰が持つかを決めます。ここまで整理できていれば、外部に渡す範囲も見積もりの前提も具体的になります。

社内で更新を続ける場合は、担当者の不在に備えて、依頼の一覧と操作手順を他の人も見られる状態にします。実際に別の人が下書きを1件作り、迷った箇所を手順に書き足すと、資料があるだけの引き継ぎを避けられます。ログイン情報の扱いと権限は、社内の管理ルールに合わせてください。

入力の操作そのものが負担で止まっているなら、業務の流れではなく編集画面の問題です。この場合はCMSの入力項目や部品を見直す対象になります。

新しい流れは、更新1件で試す

最初からすべての依頼を分類し直す必要はありません。よくある更新を1件選び、受付から公開後の確認まで新しい流れで進めます。その途中で、入力したのに誰も使わなかった項目と、何度も聞き直した情報を記録します。

前者は一覧から減らす候補、後者は受付時に聞く候補です。公開までの日数だけでなく、情報を待った時間と作業した時間を分けて見れば、次に変える工程を選べます。

AIで半自動化すれば、担当者の仕事は「確認と公開」になる

流れが整ったら、作業そのものをAIに任せる方法もあります。例えば、ニュースリリースの原稿を渡せば、AIがそれを記事の形に整えてCMSに下書きとして登録し、担当者は内容を確かめて公開するだけ、という運用ができます。業界の動きや自社の発表を集めさせて、お知らせの下書きを書かせることも可能です。

公開まですべて自動にすることもできます。ただ、意図しない内容の記事が上がってしまうおそれがあるため、おすすめは半自動化です。AIが下書きまでを担当し、事実の確認と公開の判断は人が行う。先ほどの「承認は省かず、判断する範囲を分ける」を、そのままAIとの分担に当てはめる形です。

原稿を書く、画像をそろえる、入力するといった手間がなくなれば、更新が止まる理由の多くが消えます。担当者に残るのは、チェックと公開だけ。忙しい時期でも更新を続けやすくなります。

まとめ｜更新停止を、担当者個人の問題にしない

更新は、次に誰が動くかが決まっていない工程で止まります。原稿待ちなら情報を持つ部署へ、承認待ちなら判断する人へ。止まった工程に合わせて、依頼時に聞く項目、承認の範囲、公開後の確認のどれを直すかを決めます。

手始めに、直近で公開できなかった更新を1件選び、今だれの資料や返答を待っているのかを書き出してみてください。新しい流れはその1件で試してから広げます。流れが整えば、下書きまでをAIに任せて、担当者の仕事を確認と公開に絞ることもできます。