厦門のウェブサイト制作会社を選ぶ際、ソースコードの納品条件をどのように取り決めればよいですか？

厦門のウェブサイト制作会社を選ぶ際は、契約書に「ソースコード一式を納品する」と記載するだけでは不十分です。どのファイルを納品するのか、どのような利用が認められるのか、独立してデプロイできるのか、どのように検収するのかも明確にする必要があります。そうしないと、サイト公開後にアーカイブを受け取っても、データベースや依存コンポーネント、実行許諾が不足し、サーバーやサービス提供会社を変更できない可能性があります。

調達段階ではまず、購入するのが独立してデプロイ可能なウェブサイトなのか、年単位で契約するウェブサイト構築サービスなのかを確認してください。前者の場合は、ソースコード、データ、デプロイ資料を納品物に含める必要があります。後者の場合、プラットフォームのソースコードが提供されるとは限らないため、データのエクスポート、ドメインの管理権限、契約終了時の移行支援について重点的に取り決めます。この2種類のプランを、「ソースコードは甲の所有とする」という一文だけで済ませることはできません。

まず確認すること：ソースコードの納品か、管理画面の利用権のみか

管理画面の管理者アカウントがあれば、企業がコンテンツを管理できることは確認できますが、ウェブサイトのプログラムを取得したことにはなりません。ブラウザーで表示できるページのコードも、ビジネスロジック、インターフェース、データベース構造を含むプロジェクト全体のソースコードとは異なります。

見積もりを比較する際は、見積書の添付資料に次の3点への回答を記載するよう、サービス提供会社に求めるとよいでしょう。企業指定のサーバーにウェブサイトをデプロイできるか。契約更新を停止した場合、どの機能が使えなくなるか。許諾された範囲内で、第三者の技術チームが保守を引き継げるか。「プラットフォームのサポートが必要」という回答があった場合は、「後日協議」とするのではなく、依存項目と費用を引き続き明らかにしてください。

SaaS型のウェブサイト構築が不適切というわけではありません。しかし、企業が将来的な独立運用を明確に求める場合は、契約締結前に独立デプロイの選択肢があるかを確認してください。サイト公開後になってから、プラットフォームの基盤コードの開示を求めることは避けましょう。

納品リストはファイルや資料のレベルまで明記する

以下の内容を契約書の添付資料にまとめ、「納品」「該当なし」「第三者の許諾」と明記することをおすすめします。サービス提供会社が「サイト一式をまとめて納品」という一言ですべての責任を曖昧にするのを防げます。

本番環境のパスワードやAPIキーをコードパッケージに直接記載するのは避けてください。安全な方法で別途引き渡し、移管後にキーを変更し、サービス提供会社に不要となった権限を取り消す必要があります。

ソースコードを受け取っても、すべての知的財産権を取得したことにはならない

ウェブサイトでは通常、カスタムコード、サービス提供会社が保有する既存コンポーネント、第三者ソフトウェアが組み合わせて使用されています。契約では、それぞれの権利を個別に取り決める必要があります。カスタム部分の権利帰属または利用許諾、既存コンポーネントを継続利用できるか、第三者コンポーネントにどのライセンスが適用されるかを明記してください。サービス提供会社に譲渡する権限のない権利の譲渡を求めたり、支払い後にすべての著作権を自動的に取得できると考えたりしてはいけません。

調達側にとってより直接的な判断基準は、企業が自ら、または第三者に委託して、ウェブサイトを変更、バックアップ、デプロイ、保守できるかどうかです。また、これらの権利がドメイン、サーバー台数、利用期間、契約更新の条件によって制限されるかも確認してください。関連する許諾は、ウェブサイトの実際の運用に必要な範囲を網羅し、終了条件も明記する必要があります。

フォント、画像、商用プラグインも、現在のドメインでの利用のみ許諾されている場合があります。ドメインの変更、多言語サイトの複製、新規サイトの追加にあたって、追加購入が必要かどうかを事前に確認してください。サービス提供会社は把握している制限を開示する必要があり、「ソースコードは納品済み」という説明を、ライセンスに関する説明の代わりにすることはできません。

ファイルが揃っているかだけでなく、独立して動作するかを検収する

ファイルをダウンロードして解凍できることは、引き渡しの一部にすぎません。より確実な検収方法は、合意した独立したテスト環境で、納品ドキュメントに従って再デプロイし、契約範囲内の主要機能を確認することです。

1. 納品バージョンと公開中のバージョンを照合し、バージョン番号、納品日、ファイルのチェックサム情報を記録して、古いバージョンを受け取ることを防ぎます。
2. 企業の技術担当者または委託先の第三者がドキュメントに従ってインストールし、依存コンポーネントを入手できること、設定項目に漏れがないこと、開示されていないリモート認証の制限がないことを確認します。
3. ページへのアクセス、管理画面での編集、フォーム送信、ファイルアップロードをテストします。ECサイトの場合は、誤って実際の取引を発生させないよう、注文および決済のテストフローも確認します。
4. データと添付ファイルを復元できるか確認し、既存のURL、リダイレクトルール、合意したSEO設定が維持されているかを確認します。

テスト環境で本番の決済サービスやメールサービスなどを再利用できない場合は、代替の確認方法を事前に取り決めてください。検収で見つかった不具合は記録に残し、デプロイを妨げる問題と一般的な不具合に分けて、修正期限と再検収の方法を明記します。

納品時期、残金、契約終了時の責任をあわせて取り決める

ソースコードの納品をプロジェクト終了時の一度だけにするのは避けましょう。テスト検収時と本番公開時に、それぞれ該当バージョンを納品し、その後の有償改修でもソースコードとドキュメントを同時に更新するよう取り決めることができます。残金の支払条件は、単に「ウェブサイトにアクセスできること」ではなく、合意した納品物と検収結果に連動させる必要があります。

契約条項は、次のような考え方で具体化できます。乙は合意した時期に、添付資料に記載されたソースコード、データ、デプロイ資料を納品する。甲または甲の委託先は、合意した許諾範囲内でデプロイ、変更、保守を行うことができる。未納品の項目および第三者による制限は契約締結前に明記する。不足が見つかった場合、またはドキュメントどおりにデプロイできない場合、乙は合意した期限内に不足分を補い、再検収に協力する。具体的な期限、検収条件、契約違反時の対応については、双方が記入し確認する必要があります。

契約終了に関する条項では、データのエクスポート期限、形式、移行支援の範囲、料金体系、データの保管方法も明確にしてください。ドメインの登録名義人と主要アカウントは、できる限り企業が管理しましょう。引き渡しの確認が完了する前に、本番データを無断で削除してはなりません。

厦門のウェブサイト制作サービス提供会社を選定する際は、機密情報を削除した納品リスト、デプロイ手順書のサンプル、ライセンス上の制限一覧を提出するよう求めるとよいでしょう。「ソースコードはすべて渡す」と約束するだけで、独立デプロイの条件や検収方法を明確にすることを避けるプランは、移行可能なウェブサイトとして購入すべきではありません。