"できる"と"運営できる"は全く異なる話である
エージェンシーで複数のブログを運営していると、いつかどこかでこのような結論に達します。
"新しいツールを使うよりも、
現在使っているものをうまく組み合わせて解決してみよう。"
そのため、最も一般的に選択される組み合わせがあります。
- WordPress マルチサイト
- Notionでアカウント・ルールを整理
- Excelでブログリストと権限を管理
この組み合わせは最初はかなり妥当に見えます。
この方法が選択される理由は明確である
この組み合わせの最大の利点は単純です。
- 既に使っているツールである
- 追加費用がほとんどかからない
- "うまく整理すればいい"という確信を与える
つまり、
新しい決定を先延ばしにしながらも問題を解決したような感覚を与えます。
そのため、多くのチームがこの段階を経ます。
しかし、この方法には1つの前提がある
この構造が維持されるためには
常に成立する前提があります。
"すべての人がルールを正確に理解し、
常にそのルールを守る。"
現実ではほぼ不可能な条件です。
- 人は変わり、
- プロジェクトは増え、
- 例外的な状況は必ず発生します
この瞬間から
この組み合わせは少しずつひびが入り始めます。
文書とルールは増えても、安定性は増えない
問題が発生するたびに
チームは次のように対応します。
- Notion文書を1つ作成する
- ルールを1行追加する
- "これは必ず確認してください"と通知する
しかし、重要な事実があります。
文書が増えるほど、
実際の運用安定性は逆に低下するという点です。
なぜなら:
- すべての人がすべての文書を常に見ないためであり、
- ルールは記憶ではなく習慣であるためです
マルチサイトの問題は '技術'ではない
WordPress マルチサイト自体が悪い選択ではありません。
技術的には強力です。
しかし、エージェンシー運営の観点からは
次の質問に答えることができません。
- 顧客ごとに完全な分離が可能か？
- 作成者に必要な権限だけを与えることができるか？
- ミス自体を構造的に防ぐことができるか？
結局、マルチサイトは
運用ポリシーを人が常に改善しなければならない構造です。
この構造の本当の問題は '依存性'である
この組み合わせが維持される間
チームは徐々に特定の人に依存するようになります。
- "これは○○さんが一番よく知っています"
- "その方に尋ねればいいです"
- "以前の設定はその方だけが知っています"
この状態は安定ではありません。
単に問題がまだ発生していない状態に過ぎません。
運用が崩壊する瞬間は常に同じである
この構造が崩壊する瞬間は
ほとんど同じです。
- 中核人材が欠けるとき
- ブログ数が臨界点を超えるとき
- 同時に複数のプロジェクトが重なるとき
その時、チームは気づきます。
"これは私たちがうまくできなかったからではなく、
本来、構造が合っていなかったのだ。"
そのため、この問題は '運用基準'の問題である
ここで重要な結論は次のとおりです。
- 既存のツールが不足しているわけではない
- 実務者が不注意であるわけでもない
個人基準で設計されたツールを
エージェンシー運用に合わせて無理やり使用しているためです。
次の記事では
この基準を最初から異なる方法で設定した場合、
つまり blog.hausがどのような問題から出発したのかを話してみようと思います。
次回予告
〈blog.hausはなぜ 'ブログツール'ではなく '運用システム'なのか〉