受託制作物を「渡せる状態」で作る — 引き継ぎ設計の勘所
受託したサイトが「作った本人しか触れない状態」では、資産ではなく負債になります。更新手順・触ってはいけない場所・設定の在りか——この三点を最小限で残す引き継ぎ設計を、一人会社のWordPress受託の実体験から書きました。
受託したサイトが「作った本人しか触れない状態」で納品される。それは資産ではなく、負債です。
渡せる状態で作る——これは技術ではなく、設計の問題だと思っています。
私たちの答えは、シンプルです。残すのは三点だけ。日常の更新手順。触ってはいけない場所。設定の在りか。この三つがあれば、作った本人が不在でも、最低限は回ります。
私たちは社長1名とAI（COO役）だけの会社で、複数の中小企業さま向けに WordPress サイトを受託運用しています。数を重ねて、痛感したことがあります。――いいテーマを組むことより、「自分がいなくても回る形」で渡すことのほうが、ずっと難しい。この記事は、その引き継ぎ設計を、受託する側の視点で言葉にしたものです。
🧩「触れるのが自分だけ」が最大のリスク
納品直後は全部が頭の中にある。でも記憶は数か月で薄れる。属人化は事故のときだけ牙をむく。
納品直後は、すべてが頭の中に入っています。どのプラグインが何のために入っているか。なぜこの設定にしたか。どこを触ると壊れるか。
問題は、その記憶が数か月で確実に薄れることです。
半年後、「文言を一行だけ直したい」という依頼が来る。ところが、自分ですら管理画面のどこを開けばいいか思い出せない。——正直に言うと、これは一度や二度ではありませんでした。
属人化の怖さは、事故のときにだけ牙をむく点にあります。作った本人が忙しい。あるいは連絡がつかない。そのときお客さま側で何もできないと、小さな修正が止まり、やがてサイトごと放置されます。
渡せる状態とは、この「本人不在でも最低限は回る」を成立させること。私たちはそう捉えています。
📋README に「既設端末の更新手順」を必ず残す
開発者向けの構築手順ではなく、お客さまが実際に触る最短経路を、README の冒頭に置く。
私たちが受託リポジトリで徹底しているのは、README の冒頭に「既設端末の更新手順」を、平易な言葉で書くことです。
開発者向けの構築手順ではありません。実際にお客さまや別の担当者が触るときの、最短経路を先に置く。
たとえば「更新はこのブランチに push すれば自動で反映される」「本番を触る前に、必ずステージングで確認する」。日常の一手を、そのまま手順にします。
コツは、コマンドを並べないこと。「何をしたいときに、どこを開いて、何を確認して終わるか」を、ひとつの流れで書きます。
手順書は、長くなるほど誰も読みません。だからよくある更新の上位いくつかに絞って、それ以外は「迷ったら連絡してください」と正直に書く。——全部を書こうとしないことが、かえって読まれる手順書につながりました。
🚫「触ってはいけない場所」を明示する
やり方より効くのは禁止事項。理由を添えて「ここ以外は自由に触っていい」を渡す。
手順書は「やり方」を書きます。でも引き継ぎでより効いたのは、「触ってはいけない場所」を書くことでした。
私たちは README に「設定ファイル上書き禁止」という項目を設けています。自動生成される設定や、環境ごとに差し替わる値を、手で書き換えないように、と。
ここが守られないと、次のデプロイで変更が消える。あるいは本番と開発の設定が食い違って、原因不明の不具合になる。
禁止事項は、理由とセットで書くと守られます。「ここは自動生成されるので、手で直しても次回上書きされます」——この一言を添えるだけで、触っていい場所と悪い場所の境界が伝わります。
禁止だけを並べると、窮屈に見えるかもしれません。でも実際には逆で、「ここ以外は自由に触っていい」という安心を渡すための線引きなんです。
🗺️設定の在りかを一枚の地図にする
鍵やパスワードの値は書かない。「どこに何があるか」の所在だけを一覧にして渡す。
引き継ぎで一番聞かれるのは、意外にも「あの設定はどこにあるのか」でした。
ドメインの管理。メールの送信設定。外部サービスの鍵。フォームの送信先。これらは管理画面・環境変数・外部サービスのダッシュボードに散らばっていて、作った本人以外には、まず見つけられません。
だから私たちは、値そのものは残さず、「どこに何があるか」だけを一覧にして渡します。
鍵やパスワードの実体をドキュメントに書かないことは、徹底しています。書くのは「この鍵は、このサービスの管理画面のここで発行・確認できる」という所在だけ。
所在の地図があれば、いざというとき別の人でもたどり着けます。値を平文で残さないので、安全面でも無理がない。——一石二鳥なんです。
✂️属人化を避ける「最小限」のドキュメントとは
渡すのは更新手順・禁止事項・設定の在りかの三点だけ。網羅より、詰まりから逆算する。
ここまでを一言でまとめると、渡すべきドキュメントは三点に絞れます。日常の更新手順。触ってはいけない場所。設定の在りか。
この三点があれば、作った本人が不在でも、最低限は回ります。
逆に、これ以上を最初から完璧に書こうとすると、どうなるか。書く側が疲れて、更新されなくなる。そして「古い手順書」という、別の負債が生まれます。
大事なのは、ドキュメントを一度きりの納品物にしないこと。運用の入り口として、育てていく。
私たちは修正依頼が来るたびに、README に一行足りていなかった箇所を見つけて、その場で追記しています。実際に人が詰まった場所こそ、書くべきだった項目だからです。——網羅ではなく、詰まりから逆算して最小限を保つ。これが受託する側にとって、一番続けやすいやり方でした。
🔑まとめ — 渡せる状態は納品品質そのもの
動くだけでは終わりじゃない。本人がいなくても回る形にして、初めて資産になる。
受託制作は、動くものを作って終わり、ではありません。
作った本人がいなくても回る形にして、初めて、お客さまにとっての資産になります。
更新手順。触ってはいけない場所。設定の在りか。この三点を、最小限でいいので残す。それが属人化を避ける、一番実務的な一歩だと私たちは考えています。
派手さはありません。でも——半年後の自分と、次に触る誰かへの手紙のつもりで、私たちは書いています。
あなたの受託でも、まずは README の冒頭に「更新手順」の一行だけ、足してみませんか。そこから始めれば、十分です。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する