作った人がいなくても回るサイトの渡し方

サイトを渡すときに残すのは、日常の更新手順・触ってはいけない場所・設定の在りかの3つです。これがあれば、作った本人がいなくても最低限は回ります。全部を書こうとせず、人が詰まった場所から書き足します。

作った本人しか触れない状態で渡されたサイトは、資産というより負債になります。半年後に「文言を1行直したい」と頼まれたとき、作った本人ですら管理画面のどこを開けばよいか思い出せない。私たちにも、これは一度や二度ではありませんでした。

私たちは、いくつかの WordPress サイトの保守を請け負っています。この記事は、サイトを「作った人がいなくても回る形」で渡すために、私たちが残しているものの記録です。

「触れるのが自分だけ」がいちばんの危険

渡した直後は、すべてが作った人の頭の中にあります。けれども記憶は数か月で薄れます。その状態が問題になるのは、作った人が忙しいときや連絡がつかないときです。

どのプラグインが何のために入っているか、なぜこの設定にしたか、どこを触ると壊れるか。渡した直後なら全部覚えています。問題は、それが数か月で確実に薄れることです。

作った人に頼れないとき、お客さんの側で何もできないと、小さな修正が止まり、やがてサイトごと放置されます。「渡せる状態」とは、本人がいなくても最低限は回ることだと私たちは考えています。

1. 日常の更新手順を、冒頭に書く

説明書の冒頭には、お客さんや別の担当者が実際に触るときの最短の道筋を書きます。コマンドを並べるのではなく、「何をしたいときに、どこを開いて、何を確かめて終わるか」を1つの流れで書きます。

開発者向けの構築手順は、後ろに回します。冒頭に置くのは、たとえば「お知らせを追加するときは、管理画面の『投稿』を開き、公開したらトップページで表示を確かめる」のような、日常の1手です。

手順書は長くなるほど読まれません。よくある更新の上位いくつかに絞り、それ以外は「迷ったら連絡してください」と書きます。全部を書こうとしないことが、かえって読まれる手順書につながりました。

2. 触ってはいけない場所を、理由と書く

引き継ぎでいちばん効いたのは、やり方より「触ってはいけない場所」を書くことでした。理由を添えると守られ、それ以外は自由に触ってよいと伝わります。

私たちは説明書に「上書きしてはいけないファイル」の項目を置いています。自動で作られる設定や、環境ごとに値が変わる設定のファイルです。ここを手で書き換えると、次の更新で変更が消えたり、本番と開発の設定が食い違って原因の分からない不具合になったりします。

禁止だけを並べると窮屈に見えますが、理由を1行添えると受け取り方が変わります。「ここは自動で作られるので、手で直しても次の更新で上書きされます」。この線引きは、「ここ以外は自由に触ってよい」という安心を渡すためのものです。

3. 設定の在りかを、1枚の地図にする

引き継ぎでいちばん聞かれるのは「あの設定はどこにあるのか」です。値そのものは書かず、「どこに何があるか」だけを一覧にして渡します。

鍵やパスワードの値は、説明書に書きません。書くのは「この鍵は、このサービスの管理画面のここで確かめられる」という在りかだけです。在りかの地図があれば、別の人でもたどり着けますし、値を書いていないので安全の面でも無理がありません。

網羅せず、詰まった場所から足す

最初から完璧に書こうとすると、書く側が疲れて更新されなくなります。修正の依頼が来るたびに、足りなかった1行をその場で書き足します。

説明書を一度きりの納品物にすると、すぐに「古い手順書」という別の負債になります。私たちは、修正の依頼が来るたびに、説明書に足りていなかった箇所を見つけて書き足しています。実際に人が詰まった場所こそ、書くべきだった項目だからです。

まずは説明書の冒頭に、日常の更新手順を1つだけ書いてみてください。半年後の自分と、次に触る誰かへの手紙のつもりで書くと、続けやすくなります。

よくある質問

参考・出典

• Roles and Capabilities（WordPress.org）編集者・投稿者など、権限の種類と範囲の公式説明
• Backups（WordPress Advanced Administration Handbook）「更新の前には必ずバックアップを」とする公式の手引き