ブログ
火消しからフレームワークへ:クライアントサイト保守の成熟度モデル
ローンチ後の保守システムを構築し、1社のクライアントから多くのクライアントへと拡大しても、チームを燃え尽きさせない。
概要
サイトをローンチし、請求書を送った。ところがクライアントから何かが壊れたと電話がかかってきて、午後いっぱいを使ってログイン情報を思い出し、自分の判断を解読し、謝罪することになる。この記事では、保守の成熟度モデルについて説明します。クライアントが1社のとき、数社のとき、多数のとき、それぞれ何をすべきかを解説します。チェックリストがヒロイズムに勝る理由、ドキュメントがプロダクトである理由、ローンチは始まりに過ぎない理由を学べます。さらに、自動化に対する異論も紹介します。理解していないものを自動化してはいけません。最後には、クライアントとあなたの利益の両方を守る、再現可能なハンドオフプロセスを手に入れられます。
クライアントのサイトは公開され、ローンチも順調に終わった。請求書を送り、ラップトップを閉じて、次の仕事に移る。6週間後、メールが届く。「サイトがダウンしています」。バックアップが動いているかどうかわからない。ドメインを誰が所有しているのかわからない。どのホスティングアカウントにファイルがあるのか思い出せない。あなたがシステムなのだ。そしてシステムには記憶がない。
これはホスティングの問題ではなく、プロセスの問題です。この記事は、クライアントサイト保守の成熟度モデルです。ビジネスの規模が大きくなるにつれて、アプローチを変える必要があります。1サイトで機能するヒロイズムは、20サイトではあなたを破綻させます。ここでは、あなたとクライアント、そして彼らのサイトの関係がどのように進化すべきかを説明します。
| ステージ | 状況 | 破綻するもの | 必要なもの |
|---|---|---|---|
| ステージ0:ヒーロー | 1〜3サイト、すべてのパスワードを保持 | あなたの記憶 | 小さなドキュメント習慣 |
| ステージ1:チェックリスト | 4〜10サイト、まだ自分で作業している | あなたの一貫性 | 再利用可能なチェックリストとリテーナー |
| ステージ2:オペレーター | 10サイト以上、作業が自分より長持ちしなければならない | あなた | システム、委任、所有権のマッピング |
ステージ0:ヒーローフェーズ — 自分を代替可能にする
基本原則:1〜3サイトのうちは、あなた自身がシステムです。あなたの記憶がデータベースです。それはデータベースが消えるまで機能します。まだ複雑なプロセスは必要ありません。必要なのは習慣です。
クライアント用フォルダを作成し、次の4つを入れましょう:ドメイン登録機関、ホスティングプロバイダー、DNS設定、バックアップ場所。ログイン資格情報はメールではなくパスワードマネージャーに保存してください。もし構築プロセス自体に再現可能なエージェンシープロセスがなければ、それを先に整えましょう。混乱した状態を引き渡すことはできません。
例:ブティックフィットネススタジオが5ページのサイトを依頼してきました。あなたはドラッグ&ドロップビルダーでサイトを構築し、ドメインを接続してアクセス権を渡します。ドキュメントはなし。3か月後、彼らはクラススケジュールのページを依頼します。あなたはどのビルダーを使ったのか、誰のログインなのか、どうやって入るのかを思い出せません。ここでパスワードリセットに1時間費やします。その1時間は、ドキュメントを省略したことに対して支払う税金です。
この段階では、所有権に関する2つのルールが適用されます。第一に、ドメインはクライアント名義にしましょう。ICANNのドメイン登録プロセスによると、登録には登録者の連絡先情報が必要です。その連絡先情報があなたのものなら、実質的にその資産はあなたのものです。クライアントが離れる場合、ドメインを持ち出せないかもしれません。彼らのアイデンティティを人質にしないでください。第二に、コンテンツ資産はクライアントに所有させましょう。彼らの画像、ロゴ、コピーを、彼らがアクセスできるフォルダに置きます。彼らが去るなら、自分のものを持って去ることができます。そして彼らはあなたのことを覚えているでしょう。
ステージ0では、自分を代替可能にすることが目標です。クライアントがあなたの記憶なしでは生き残れないなら、彼らは決して去らず、あなたも決してスケールしません。
ステージ1:チェックリストフェーズ — 一貫性は天才に勝る
基本原則:4〜10サイトになると、記憶は負債になります。どのプラグインを更新すべきか、どのバックアップが実行されたか、どのクライアントがロゴを変更したかを思い出せません。必要なのは才能ではなく、トリガーです。
まずセキュリティから始めましょう。UpGuardのウェブサイトセキュリティのベストプラクティスがベースラインを示しています:ソフトウェアを最新に保つ、MFAなどの強力な認証を要求する、ユーザー権限を制限する、定期的にバックアップする、SSL/TLS暗号化を使用する。これらを毎月の反復チェックリストとして、すべてのアクティブなサイトで実行します。
再利用可能なチェックリストが1つあれば十分です。プラットフォームとプラグインを更新する。バックアップが実行されたか確認する — ファイルを1つ復元して証明する。ユーザーアカウントと権限を確認する。SSL証明書の有効期限を確認する。マルウェアをスキャンする。先月の稼働時間を確認する。1サイト30分、3時間ではありません。
次に、そのチェックリストを中心に保守リテーナーを構築します。月額サブスクリプションとしてパッケージ化し、1ページのダッシュボードを含めます:含まれるもの、追加料金がかかるもの、連絡先。そのダッシュボードは法的契約ではなく、関係を築くためのドキュメントです。「ちょっとした修正」が項目として明確になるため、スコープクリープを防ぎます。
例:フィットネススタジオのクラススケジュールプラグインがコアアップデート後に壊れたとします。ステージ0なら、修正して次に進みます。ステージ1では、チェックリストに「ステージングコピーで先にプラグインを更新する」とあります。リテーナーがその時間をカバーします。クライアントには、消防士ではなくプロフェッショナルに見えます。違いはスキルではなく、プロセスです。
注意:チェックリストが形だけのものになってはいけません。確認せずにチェックを入れると、バックアップが静かに失敗しているのに「バックアップ成功」をクリックすることになります。推測せず、確認しましょう。
あなたを救うハンドオフドキュメント
どんなツールを買うよりも価値があるドキュメントが1つあります:ハンドオフドキュメントです。1ページにまとめましょう。次の質問に答えられるようにします:サイトは何で動いているのか、ドメインは誰が所有しているのか、コンテンツの真実の源泉はどこか、月額リテーナーには何が含まれるのか、明確に範囲外なのは何か、バックアップはどこにあるのか。
サイトに触れるたびに更新し、各変更に日付を記入します。これは自己目的のドキュメントではなく、プロダクトとしてのドキュメントです。休暇に行くとき、請負業者を雇うとき、最終的にエージェンシーを売却するとき、この1ページがあれば、あなたなしでビジネスは回ります。
ハンドオフドキュメントはチーム全体が見られる場所に保管しましょう:共有ドライブ、CRM、プロジェクト管理ツールなど。メールで送って失くすようなPDFにしてはいけません。それが一人の頭の中にあるなら、存在しないのと同じです。
ステージ2:オペレーションフェーズ — あなたなしで動くシステム
基本原則:規模が大きくなると、サイトを1つずつ保守することはできません。日々の注意なしで機能するシステムが必要です。最大の変化は所有権です。他の誰かが同じ水準で作業を行える必要があります。
システムごとにアクセスを分離します。ドメイン登録機関、ホスティング、DNS、アナリティクス、メール — それぞれをマスターレコードの行にします。クライアントごとに、誰がそれぞれを所有しているか、誰がDNSを変更できるか、誰がドメインを更新できるかを文書で回答します。そのレコードは自分のパスワードボールトだけでなく、チームと共有しましょう。
次に、個々のタスクからセキュリティプログラム思考へ切り替えます。UpGuardのウェブサイトセキュリティガイダンスにある追加の対策 — Webアプリケーションファイアウォール、定期的な監査、継続的なモニタリング、ユーザー教育 — は、サイトごとのタスクではなく、ポートフォリオの決定です。信頼するモニタリングアプローチを一度決定し、すべてのクライアントを同じ基準で設定します。
SEOにも同じ扱いが必要です。Digital Marketing Instituteは、SEOをコンテンツ、構造、技術要素を最適化して検索エンジンのランキングとユーザーエクスペリエンスを向上させることと説明しています。その中核的なプラクティス — 技術的セットアップ、HTTPS、XMLサイトマップ、robots.txt — は、ローンチ当日の雑用ではありません。それらは劣化します。規模が大きくなったら、SEOを月額サービスとしてパッケージ化します:メタデータの確認、壊れたリンクの発見、クロールエラーの確認、サイトマップの更新。初日からのSEOとセキュリティについては別途執筆しました。ここでは、それらは継続的な義務です。
変更管理フローを構築します。クライアントが修正を依頼したら、記録し、見積もり、実行し、文書化します。15分未満なら、実行して記録します。それより大きいものは、次のメンテナンスウィンドウか新しい見積もりに回します。このフローがリテーナーを収益性の高いものに保ちます。これがないと、「小さなリクエスト」ごとに請求できない時間を1時間ずつ消費します。
すべての変更を、日付、担当者、理由とともに記録します。このログは、クライアントがサイトがハッキングされたとか「あなたが何かを変えた」と主張したときに必要になる監査証跡となります。ログはあなたの証拠です。
各クライアントと四半期ごとにメンテナンスレビューを行います。10分間です。何を更新したか、何が壊れたか、次に何が壊れるかを示します。このレビューは早期警戒システムです。クライアントはここで新しいサービスラインについて教えてくれ、そこで新しいサイトセクションを依頼する前に。
ノーコードはハンドオフをなくさない
ノーコードビルダーはこれを同時に簡単かつ難しくします。簡単なのは、クライアントがログインして自分でコピーを編集できるからです。難しいのは、「クライアントが編集できる」が「クライアント自身が壊した」になるからです。ハンドオフ時に権限を設定します:クライアントには編集者ロール、あなたには管理者ロール。変更はまずステージングエリアに公開します。
サイトがこれほど簡単に編集できるのに、なぜ毎月料金を請求するのかとクライアントが尋ねたら、答えがあります:それが壊れないようにしているのはあなただからです。その反論は予測可能です。更新の電話が出る前に、ノーコードへの反論を克服する方法を読んでおけば、自信を持って会話に対応できます。
自動化する前に:異論
誰もがメンテナンスを自動化せよと言います。彼らは間違っています — 少なくとも最初は。理解していないプロセスを自動化すると、ただ早く壊れるだけです。
バックアップシステムを新人に説明できないなら、自動バックアップツールはあなたを救いません。どのプラグインアップデートがサイトを壊すか知らなければ、自動アップデートはサイトをダウンさせます。自動化は能力を増幅しますが、代替にはなりません。
少なくとも3回手動で実行し、文書化したものだけを自動化しましょう。その後、ツールに任せます。
致命的な道は、ステージ0からステージ2にスキップすることです。ログイン情報を1つも書き留めないうちに、フリート管理ダッシュボードを導入します。ダッシュボードはブラックボックスになります。以前よりも悪化します。ステージを順に進みましょう。
成熟度モデルは一方通行のはしごではない
成熟度モデルは一度登ったら終わりのはしごではありません。サイトは老朽化し、クライアントは変わり、チームは入れ替わります。後退することも予想しましょう:チェックリストをスキップする人を雇ったり、移行中にドキュメントを失ったりするでしょう。それでいいのです。重要なのは方向性です。
最初の行動はこれです。クライアントを1社選び、次の5つを書き留めます:ドメイン登録機関、ホスティングプロバイダー、DNSプロバイダー、バックアップ場所、そして管理者ログインの所有者。今日の午後に行いましょう。そして、自分が望むステージではなく、実際にいるステージを判断します。もしパスワードを知っているのが自分だけなら、ステージ0です。別のツールを買う前にそれを修正しましょう。
ハンドオフがプロダクトです。そのように扱いましょう。クライアントのビジネスが変わったときに情報アーキテクチャを見直し、サイトが壊れたときに見直すのではありません。存在しなかった構造を修正するツールはありません。
そしてクライアントとの関係を思い出してください:あなたの仕事は、クライアントのサイトを退屈なものにすることです。彼らがホスティング、アップデート、バックアップについて考えなくていいようにするのです。それらについて考えなくなった日が、彼らが更新する日です。

