女性向けエンジニアスクール
3秒でわかる
作った成果物を契約で決めた形にそろえて依頼者へ引き渡す工程。コードだけでなく手順書や検収の合意まで含み、ここを外すと請求が通りません。
もう少し詳しく
どういうものか
納品は、受注した側が作った成果物を依頼者の管理下へ移す工程です。渡すものはソースコード一式だけではありません。ビルド済みの成果物、環境構築とデプロイの手順書、テストの実施記録、設定ファイルのサンプル、これらを契約書に書かれた形式でそろえます。
渡した時点で終わりではなく、依頼者が中身を確認して合格と判断する検収を経て、はじめて納品が完了した扱いになります。請求書を出せるのも検収の後です。
なぜ必要か
開発の途中では「動いている環境」が作った本人の手元にしかありません。納品という区切りを置かないと、依頼者は自分たちで動かす手段を永久に持てず、担当者が抜けた瞬間にシステムが止まります。何をどの状態で渡せば完了なのかを先に文書で決めておくことが、追加作業の押し付け合いを防ぐ唯一の方法です。
具体例
タグを打って、その時点のソースを固めて、改ざん検知用のハッシュを添える。個人開発の受託でもこの三点はやります。
git tag -a v1.2.0 -m "release for delivery"
git archive --format=zip --prefix=fleama/ v1.2.0 -o fleama-v1.2.0.zip
sha256sum fleama-v1.2.0.zip > fleama-v1.2.0.zip.sha256納品物の一覧は口約束にせず、チェックリストとして相手に共有します。どのブラウザで、どのバージョンの実行環境で動作を確認したのかも、同じ文書に書き残します。後から動かないと言われたとき、確認した範囲が書面にあるかどうかで話の進み方が変わります。
つまずきやすいところ
.env の実値をコミットから外したのはよいが、.env.example を入れ忘れて相手が起動できない、という事故が非常に多い似た用語との違い
| 語 | 何を指すか |
|---|---|
| デプロイ | 動くサーバーへ配置する技術作業。社内でも毎日やる |
| リリース | 利用者が使える状態にして公開すること |
| 納品 | 成果物の所有と責任を依頼者へ移す契約上の行為 |
| 検収 | 依頼者が納品物を確認して合格を出す行為 |
覚え方
デプロイは機械に渡す、納品は人に渡す。渡した後の責任が誰にあるかで区別します。
