修正、納品、コードの所有について

修正は合意済みの仕事を調整し、範囲変更は新しい要件を加えます。事前に区別しましょう。見出し変更は修正でも、予約エンジン追加は新機能です。コード納品で第三者のライセンス所有権まで移るわけではありません。

修正を承認済み範囲との関係で決める

修正は合意した作業の調整です。見出し、写真の切り抜き、既存区画の余白などが例になります。言語、サービスページ、予約エンジンの追加は新しい要件です。具体例を先に決めると、同じ言葉を違う意味で使うことを防げます。

意見はページ、起きている問題、望む結果を一つの一覧にします。複数の担当者が確認する場合は、送る前にまとめてください。同じ見出しについて相反する指示を渡しても、制作側だけでは解決できません。

不具合と新しい好みも分けます。合意どおりに保存しないフォームは修正が必要です。承認済みの方向を新しい責任者の好みで変える場合は、範囲と日程を相談します。

現在のソース、原稿、構築と公開の手順、ドメイン、ホスティング、外部依存を列挙します。一般的なチェック表を渡すだけでなく、実際の実装に対応させてください。

文章を一つ直して公開する方法を説明してもらいます。次の担当者がファイルを見つけ、構築し、正しい環境へ公開できるでしょうか。管理画面がない場合は更新方法を率直に説明します。ブログ構造があってもブラウザーの編集画面があるとは限りません。

コードの所有と第三者ライセンスを区別します。フォント、写真、テーマ、ライブラリーの条件は残ります。秘密の値は公開ソースや一般の納品資料に入れず、適切な非公開経路で権限を扱います。説明書には必要な設定の名前を記録できます。

完成原稿でページを開き、電話画面のメニュー、入力エラー、有効な相談を試します。成功表示だけでなく、実際の記録を確認してください。詳細ページで言語を変え、重要なリンクも追います。

確認記録には実施内容、渡したもの、所有者が設定する外部項目を分けて書きます。ローカル試験は本番の秘密設定やデータベースの証明ではありません。ドメイン権限などが必要なら、具体的に記録します。

納品後に何が修正対象で、内容変更はどう依頼し、保守をどこまで行うかを決めます。生涯サポートや無制限の修正という曖昧な約束より、小さく明確な責任が運用しやすくなります。

所有者がソースと本番アカウントを見つけられるかを最後に確かめましょう。納品はファイル送信だけでなく、受け取ったものを理解し、別の専門家が再調査から始めずに継続できる道筋を渡すことです。

具体例: 見出し変更は修正でも、予約エンジン追加は新機能です。

守りたい範囲: コード納品で第三者のライセンス所有権まで移るわけではありません。