納品時に受け取るファイルとアカウント

コード、原稿、公開手順、明確なアカウント管理権を受け取ります。次の担当者がソースを見つけて文字修正を公開できるか確認します。圧縮ファイルだけでは運用文書の代わりになりません。

ファイルとアカウント制御を分ける

websiteというフォルダーを受け取っても、運用を続けられるとは限りません。ドメイン、DNS、ホスト、ソース、メールが別アカウントにある場合があります。役割、所有者、更新と復旧の担当を一覧にします。

提供者が変わっても続く所有の形を選びます。主要なアカウントを事業側が保持し、必要な権限を技術者へ与える方式を検討できます。この一覧は私的資料で、公開文書に載せる情報ではありません。

独自の原稿やコードと、第三者ライセンスの素材を分けます。写真やソフトウェアの条件が、ファイル送信で消えることはありません。出所、利用条件、契約制約を保存してください。

ソースの版は本当に公開中のものと一致させます。依存の準備、構築、プレビュー、本番への公開を説明し、公開設定を記録します。秘密の名前は説明できても値を一般資料へ書きません。

本文、翻訳、画像、料金データがどこにあるかを明確にします。編集パネルがないなら実際の更新方法を説明してください。記事の構造があることと、ブラウザー編集機能は別です。

小さな文章変更を実演してもらいます。別の専門家がファイルを探し、必要なサービスを推測せず公開できることが重要です。前の版へ戻す方法も含めます。

実ドメインのページ、メニュー、言語切り替えを開き、フォームを試します。有効な相談が保存または受信され、不正入力や停止で架空の成功を出さないか確認します。

ローカルと本番の確認を分けて記録します。所有者の情報や権限が足りないなら、何が必要かを書きます。トップが見えるだけではデータベースやボット対策設定まで確かめたことにはなりません。

納品後の内容変更、障害、更新費、保守の責任を定義します。永久支援という曖昧な文より、具体的な範囲が役立ちます。不要になった一時権限も合意した管理方法で整理します。

次の管理者がソース、ホスト、ドメイン、相談の保存先を説明し、公開手順を見つけられるかを確かめます。これができれば、単にファイルを持っているだけでなく、事業として継続できる引き渡しに近づきます。

具体例: 次の担当者がソースを見つけて文字修正を公開できるか確認します。

守りたい範囲: 圧縮ファイルだけでは運用文書の代わりになりません。