企業サイトに納品説明を掲載する際、多くの企業は「期日通りに納品します」や「専門チームが保証します」といった一言だけを記載し、顧客にとっては何も伝わらないことがよくあります。本当に実用的な納品説明は、顧客が契約前に明確に理解できるようにする必要があります：何を受け取るのか、プロセスはどう進むのか、いつ完了するのか、どうすれば検収合格とみなされるのか。これにより、後々のトラブルを減らし、企業の専門性も示せます。
納品説明は4つの質問に答える
納品説明を書く前に、顧客が最も気にする4つのことを考えましょう：
- 何を納品するのか：具体的な成果物は何か。例えば、ウェブサイトのソースコード、デザインファイル、操作マニュアル、トレーニング動画、またはこれらすべてを含むのか。
- どのように納品するのか：顧客への受け渡し方法は、オンライン送信、オフラインでのコピー、または顧客のサーバーへのデプロイか。
- いつ納品するのか：契約締結から納品までにかかる期間はどのくらいか、段階的な納品があるか。
- どうすれば納品完了とみなすのか：検収基準は何か。例えば、ページが正常に表示される、機能が使用可能、資料が揃っている、顧客が確認後に納品完了とする。
この4つの質問を明確に書けば、納品説明はほぼ成功したも同然です。
納品説明の内容構成
納品説明は長文である必要はありませんが、構造は明確であるべきです。以下のセクションに分けることをお勧めします：
1. 納品リスト
すべての成果物をリストアップし、できれば表やリスト形式にします。例：
- ウェブサイトのソースコード（データベーススクリプトを含む）
- デザインソースファイル（PSDまたはAI形式）
- 管理画面操作マニュアル（PDF）
- 管理者アカウント（初期パスワードは変更が必要）
- ドメイン設定手順書（必要な場合）
各項目の後に説明を追加できます。例えば「ソースコードは本プロジェクト専用であり、サードパーティ製コンポーネントのライセンスは含まれません」など。
2. 納品プロセス
プロジェクト開始から最終納品までの手順を説明し、顧客が各段階で何を受け取るかを理解できるようにします。例：
- 要件確認：双方で機能リストとデザイン案を確認します。
- 開発・テスト：内部テスト完了後、テスト環境のURLを提供します。
- 顧客検収：顧客がテスト環境で確認し、修正依頼を出します。
- 本番リリース：本番サーバーにデプロイし、ドメイン設定を完了します。
- 資料納品：すべての成果物とアカウントを提供します。
3. 納品期間
予定期間を明記しますが、不確定要素があるため、具体的な日付は避けます。「契約締結および前払い金受領後、30営業日以内に初版を納品します」と書き、「顧客の都合による遅延が生じた場合、納品期間は順延されます」と補足します。
4. 検収基準
どのような場合に顧客が検収合格とするかを明確にします。例：
- すべての機能が要件定義書通りに正常に動作する。
- ページが主要ブラウザ（Chrome、Edge、Safari）で正常に表示される。
- 管理画面に正常にログインし、操作できる。
- 顧客が納品確認書に署名またはメールで確認する。
書き方のポイント
顧客が理解できる言葉を使う
「デプロイ」「イテレーション」などの技術用語を多用せず、「ウェブサイトをサーバーに配置して訪問者がアクセスできるようにする」と説明します。やむを得ず使用する場合は、初出時に括弧書きで説明を加えます。
範囲と例外を明示する
納品説明は約束書ではありません。納品範囲に含まれない状況を明確に記載します。例えば「サードパーティ製プラグインの購入費用は含まれません」「顧客が自らコンテンツを修正するためのトレーニングは含まれません」。これにより、顧客の非現実的な期待を防ぎます。
コミュニケーションの節目を強調する
プロセスの中で「顧客の協力が必要な箇所」を明記します。例えば「ロゴのソースファイルを提供」「トップページのデザイン案を確認」。納品は一方的な待ち時間ではなく、双方の協力であることを顧客に理解させます。
更新と維持
納品説明は一度書いたら終わりではありません。企業のサービス内容、プロセス、製品バージョンが変わった場合は、速やかに更新します。例えば、アフターサポート期間を追加した場合や、新しい成果物の種類を導入した場合は、同期して修正します。定期的に確認し、内容が実際の状況と一致していることを保証することをお勧めします。
最後に
納品説明は企業サイトのコンテンツの一部であり、適切に書けば信頼性が向上します。しかし、より重要なのは、実際の実行が説明通りであることです。説明で「24時間以内に応答」と約束したなら、それを実行する必要があります。そうでなければ、どんなに素晴らしい説明もネガティブな評価の原因になります。
