ブログ運用の引き継ぎは「ドキュメント問題」じゃない。「設計問題」だ。
「前任者が辞めたので、ブログの更新をお願いします」——この一言で始まる地獄を、私は何度も見てきた。共有フォルダにはファイル名が「最終版_v3_確定_修正2.docx」のWordが転がっていて、CMSのログイン情報はSlackの過去ログを30分掘らないと出てこない。トーンマナーは前任者の頭の中にしかなかったから、新担当が書いた記事は読者から見て「なんか違う」ものになる。
つまり、3ヶ月前に異動を告げられた企業のWeb担当者。あるいは、副業ライターの契約が切れて急にブログ運用を巻き取ることになったマーケ担当。この記事はそういう人のために書いている。
ただし先に断っておくと、私が話すのは「引き継ぎ資料の上手な書き方」ではない。引き継ぎで品質が落ちる本当の原因は、資料の有無じゃなくて運用そのものの設計にある。私はWriters-hubでブログ運用のパイプライン——文体ルール、チェックリスト、品質ゲート、テンプレート、判断ログ——を実際に設計して回してきた。その経験から言えることを書く。
担当者が変わると何が壊れるか
引き継ぎマニュアルは「取扱説明書」だと思われている。でも実態は「レシピ本」に近い。
取扱説明書なら、書いてある通りにやれば同じ結果が出る。でもブログ運用は違う。「記事のトーンは明るめで」「ターゲットに合わせて調整してね」——こういう指示は、書いた本人にしか再現できない。レシピ本に「塩少々」と書いてあるのと同じで、「少々」の感覚は料理した人の中にしかない。
担当交代で壊れるのは、具体的にはこの3つだ。
- 暗黙知の消失: キーワード選定の基準、記事構成の判断軸、「この話題は触れない」という暗黙のルール——全部、前任者の頭の中にだけあった
- トーンの崩壊: 文体ガイドラインが「カジュアルで親しみやすく」程度しかなく、後任者が書くと読者に「なんか違う」と思われる
- 更新頻度の低下: 何をどう書けばいいか分からないから手が止まる。結果、週1更新が月1になり、検索順位が下がり始める
私がWriters-hubで仕組みを設計する中で痛感したのは、引き継ぎの品質は「引き継ぎの瞬間」に決まるのではなく、「日常の運用設計」で決まるということだ。逆に言えば、日常の運用が仕組み化されていれば、引き継ぎは「フォルダの場所を教える」だけで済む。
引き継ぎマニュアルに書くべき5つの項目
ここからは、実際にマニュアルに何を書くかの話。順番に行く。
1. 文体ガイドライン——「判定可能な」ルールにする
ここ、一番大事。
「トーンは明るめで」ではなく、○×で判定できるルールとして書き出す。私がWriters-hubで実際に運用しているのは、こういう形式だ。
悪い例:
記事のトーンはカジュアルで親しみやすい感じにしてください。専門用語は避けて、読みやすくしましょう。
良い例:
- 一人称は「私」。「弊社」は使わない - 敬体と常体を混在させてよい。ただし同一段落内では統一 - 専門用語は初出時に（）で補足。2回目以降は補足なし - 数値の主張には必ず出典を付ける。出典なき数値は書かない - 「画期的な」「革新的な」「注目すべき」は使用禁止。具体的な事実で置き換える
前者は「解釈の余地」が広すぎる。後者は判定可能だ。ルールを満たしているかどうかを、書いた本人以外でも○×で判断できる。
「お願いで守れることは仕組みで守る必要はないが、仕組みで守るべきことをお願いで済ませるな。」
これが設計思想の核。トーンのような品質に直結する判断基準は、お願いではなくルールにする。ルールにすれば、引き継ぎの瞬間に「感覚を伝える」必要がなくなる。
2. キーワード選定基準——「なぜこのKWを選ぶのか」を残す
これ、抜けがちだけど引き継ぎで一番差がつくポイント。
前任者がどのツールで、どんな基準でキーワードを選んでいたか。検索ボリュームの下限は？ 競合の強さはどこまで許容する？ 自社の専門性と合致しないKWはどう除外する？
具体的には、以下を書き残す。
- 使用ツール: Semrush、ラッコキーワード、Search Consoleなど
- 選定基準: 月間検索ボリュームの目安、競合難易度の上限、自社の専門領域との距離感
- 除外基準: 「このジャンルは扱わない」「このクライアントの競合に触れない」といった暗黙のNG
- 選定の判断ログ: 過去に「なぜこのKWを選んだか」の記録が3件でもあると、後任者の立ち上がりが段違いに速い
ここを「前任者のセンスに任せていた」状態だと、担当交代のたびにKW戦略がリセットされる。
3. 記事テンプレート——構造の標準化
記事構成を毎回ゼロから考えさせるのは、引き継ぎの敵だ。
テンプレートといっても、全記事を同じ型に押し込む話じゃない。記事タイプごとに「骨格」を定義するということ。
- ハウツー記事: リード文 → 課題提示 → 手順（番号付き）→ まとめ
- 事例紹介: リード文 → Before → 施策内容 → After（数値）→ 横展開の示唆
- コラム: 一行キャッチ → エピソード → 展開 → 設計思想 → 本音の着地
骨格があれば、「何を書くか」に集中できる。「どう構成するか」で迷う時間が消える。
ただし——ここは正直に言うと——テンプレートは「守破離」の「守」でしかない。テンプレ通りに書ける状態を作るのが引き継ぎの第一歩で、崩せるようになるのは担当者が育ってからの話だ。最初から「自由に書いてください」は、引き継ぎじゃなくて放置。
4. 公開前チェックリスト——品質の「下限」を仕組みで守る
記事の品質を担保するのは、書く人のスキルだけじゃない。公開前のチェック工程が効く。
私が使っているのは「構造化4条件」というチェックだ。
- 要点: ベタ書きになっていないか。必要な情報だけに絞れているか
- グルーピング: 粒度がバラバラでないか。同じレベル感の項目が同じ階層にあるか
- 階層化: 要約→詳細の順序になっているか。俯瞰してから掘り下げる構造か
- コミットメント: 「誰が書いても同じ文章」になっていないか。この記事でしか読めない主張があるか
特に4番目。これは「構造は整っているけど中身が空虚」なケースを検出するためのもの。テンプレートに沿って書いたけど結局何も言っていない記事——引き継ぎ後に一番出やすい症状なんだよね（まあ、引き継ぎ前でも出るけど）。
チェックリストの設計原則は、主観的な「良い/悪い」ではなく、判定可能な問いにすること。「読みやすいか？」はダメ。「H2見出しだけ読んで記事の全体像がわかるか？」なら、誰でも判定できる。
5. 公開フロー——「誰が・何を・どの順で」を図にする
最後に、記事が書かれてから公開されるまでのフローを明文化する。
- ドラフト → セルフチェック（チェックリスト照合） → レビュー（誰が？） → CMS入稿 → 最終確認 → 公開
各ステップで「誰が担当するか」「承認は必要か」「使うツールは何か」を書いておく。ここが曖昧だと、「前任者はレビューなしで公開してたんですか？」「CMSの操作って誰に聞けばいいんですか？」という質問が引き継ぎ後に延々と発生する。
フローは凝ったものじゃなくていい。箇条書きで十分。大事なのは書いてあることだ。
なぜ「仕組み」が先で「人」は後なのか
ここまで読んで、「そこまでガチガチにしなくても……」と思った方もいると思う。
気持ちはわかる。でも考えてみてほしい。担当者が変わるたびに品質が落ちて、立ち上がりに3ヶ月かかって、その間に検索順位が下がって流入が減る——そのコストと、ルールファイルを1つ作るコスト、どっちが高いか。
仕組み化の本質は、個人の能力に依存しない品質の下限を作ることだ。上限は人次第。でも下限が担保されていれば、担当変更で「ゼロに戻る」ことはない。
明日からできることを3つだけ挙げる。
- 今の運用で「暗黙のルール」になっているものを5つ書き出す。トーン、KW選定基準、入稿手順、画像ルール——なんでもいい。書き出すだけでいい
- 公開前チェックリストを3項目で作る。「H2見出しだけ読んで全体像がわかるか」「主張に根拠があるか」「タイトルとリード文で記事の価値が伝わるか」——判定可能な問いの形で
- 次に記事を書く時、「なぜこのKWを選んだか」「なぜこの構成にしたか」を1行メモで残す
全部を一度にやる必要はない。1つ仕組みを作って、回して、調整して、また1つ。引き継ぎマニュアルを「完成させてから渡す」のではなく、日常の運用そのものを引き継ぎ可能な形にしていく。地味だけど、これが担当変更で品質を落とさない方法だと、私は思っている。
まあ、全部完璧に仕組み化できている組織があったら、それはそれで別の意味で心配だけどね。仕組みは「完成するもの」じゃなくて「更新し続けるもの」だから。