受託開発で意外と揉めるのがサーバーの引き渡しだ．名義・請求・権限・保守範囲を曖昧にすると，納品後にトラブルの火種になる．

対象は受託開発を手がける個人・小規模事業者．読み終えたとき，VPSを「揉めずに渡す」ための設計が手に入ります．

なぜ納品環境の設計が重要か

サーバーは請求が継続的に発生する資産だ．名義や支払いが曖昧だと，「誰が払うのか」で必ず揉める．

また権限を渡しすぎても，握りすぎてもトラブルになる．保守範囲とセットで線引きを最初に決めるのが肝心だ．

名義と請求 ― 「誰の契約か」を最初に決める

VPSをクライアント名義で契約してもらうか，自社契約のまま保守費に含めるかを，着手前に合意する．後出しは禁物だ．

請求が自社を経由するなら保守契約に明記，クライアント名義なら引き渡し手順を決めておく．

権限の分離 ― 渡すものと残すもの

root権限を全部渡すか，保守用に自社のアクセスを残すかを線引きする．保守を請けるなら後者が現実的だ．

退任・契約終了時にアクセスをきれいに剥がせる設計（個別ユーザー・鍵管理）にしておくと，移行が揉めない．

保守範囲の線引き ― どこまでが自分の責任か

OS更新・監視・バックアップ・障害対応のどこまでを請けるかを契約書に明記する．「なんとなく面倒を見る」が最悪のパターンだ．

保守を請けないなら，引き渡し時点で運用手順を渡し，以降は責任外と明確にする．

ドキュメントと再現性 ― 属人化を避ける

構成・設定・復旧手順をドキュメント化して渡す．Docker化＋compose1枚なら，環境そのものが再現可能な引き継ぎ資料になる．

「自分しか分からない環境」は，納品物として欠陥だ．誰でも再構築できる状態を目指す．

引き渡しチェックリスト

渡す前に次を確認する．名義・請求・アクセス権・保守範囲・ドキュメント・バックアップ．これらが揃って初めて「納品」だ．

  • 契約名義と請求の流れが書面で合意済みか
  • 保守範囲と責任の線引きが明記されているか
  • 構成・復旧手順のドキュメントとバックアップを渡したか

補論：渡しやすいVPSは「再現性」と「明快な管理画面」

引き渡しのスムーズさは，環境の再現性と管理画面の分かりやすさに左右される．複雑で属人的な構成ほど，引き継ぎで揉める．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ は管理画面が分かりやすく，スナップショットで引き渡し時点の状態を保全できる．Docker化した構成と組み合わせれば，クライアント側での再構築・検証も容易になり，納品トラブルを減らせる．

クライアントのブランドに合わせた独自ドメインは 取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ で取得し，名義もクライアント側にしておくと，引き渡し後の所有関係がすっきりする．

よくある質問

Q1：サーバー名義は自社とクライアントどちらが良い？

保守を長期で請けるなら自社契約も有り，所有権を明確にしたいならクライアント名義．いずれも着手前に書面合意が大原則だ．

Q2：保守を請けない場合の渡し方は？

運用手順書＋バックアップ＋アクセス一式を渡し，「以降は責任外」と契約に明記する．Docker化しておくと再現性が高く親切だ．

Q3：契約終了時のアクセス剥がしは？

個別ユーザー・個別鍵で管理しておけば該当アクセスだけ無効化できる．共有rootの渡しっぱなしは後の事故の元だ．

まとめ ― 「名義・権限・範囲・再現性」を先に決める

受託の納品環境は，名義・請求・権限・保守範囲・再現性を着手前に決めておけば，納品後に揉めない．

まずは「誰が払い，誰が直し，どこまでが自分の責任か」を契約書に一文ずつ落とそう．曖昧さを潰すことが，最高のリスク管理になる．