西安のWebサイト制作契約を締結する際、「ソースコード一式を納品する」という表現だけでは明確さに欠けます。どのファイルを納品するのか、どのような利用が認められるのか、独自にデプロイできるのか、サービス停止後にどのように移行するのかを、それぞれ明記しましょう。コードの圧縮ファイルを受け取っても、著作権をすべて取得したことにはならず、別のサービス会社に切り替えてそのまま保守を続けられるとも限りません。
見積もりを比較する前に、プロジェクトが受託開発、オープンソースシステムのカスタマイズ開発、SaaSプラットフォームを利用したサイト構築のどれに当たるかを確認しましょう。3つの方式では納品範囲が異なるため、契約書で「ソースコードは甲に帰属する」という同じ一文だけでまとめることはできません。
受託開発では、本プロジェクトで新たに作成したフロントエンドとバックエンドのコードを納品対象とし、必要な改変、デプロイ、委託保守の権限を取り決めることができます。サービス会社が以前から保有する汎用フレームワークやツールライブラリを含めるかどうかは、別途明記する必要があり、すべてがプロジェクトとともに譲渡されると考えてはいけません。
オープンソースシステムを基に開発したWebサイトでは、既存のプログラム、商用プラグイン、新たに追加したコードを区別する必要があります。オープンソースであっても利用条件がないわけではありません。商用プラグインはインストール済みでも、ドメインとの紐付け、サイト数の制限、契約満了後の更新料が定められている場合があります。
SaaSによるサイト構築では通常、プラットフォームの利用サービスが提供され、プラットフォームの基盤となるソースコードは納品対象外です。その場合は、コンテンツやデータのエクスポート、ドメイン管理、更新ルール、解約・移行方法を特に確認しましょう。企業が独自デプロイを明確に求める場合は、選定段階でその条件に対応していないプランを候補から外す必要があります。
例えば、易营宝のようなサイト構築と海外マーケティングを一体化したSaaSプランを検討する際は、プラットフォームの利用権、Webサイトデータのエクスポート、マーケティングアカウントの管理方法をそれぞれ確認しましょう。「サイト構築サービスを提供する」ことを「プラットフォームのソースコードを提供する」ことと解釈してはいけません。
契約書の別紙には、「納品対象、ファイル内容、権利の範囲、制限条件」の形式を採用できます。納品しない部分についても、名称、用途、代替手段または更新条件を明記し、検収時になって主要機能が追加の利用許諾に依存していると判明する事態を避けましょう。
デザインのソースファイル、開発履歴一式、社内テストツールを納品するかどうかも個別に記載し、Webサイトの稼働に必要なコードと混同しないようにしましょう。パスワードやAPIキーなどの機密情報は安全な方法で引き渡し、引き渡し後に変更する必要があります。

ソースコードは納品物であり、著作権や利用許諾は権利に関する取り決めです。契約では、本プロジェクトで新たに作成した成果物、サービス会社が以前から保有する成果物、第三者の成果物を区別し、それぞれについて帰属または許諾範囲を定めましょう。
その後の保守を元のサービス会社に依存しないことが主な目的であれば、企業が自ら変更できるか、他社に保守を委託できるか、サーバーを移行できるか、合意した範囲内でWebサイトをデプロイできるかを明確にしましょう。「永久使用」とだけ記載しても、デプロイ数、利用主体、改変権限が不明確なままになる可能性があります。
カスタマイズ開発の成果物に関する著作権の譲渡を求める場合は、具体的な権利、対象となる成果物、効力発生条件を明記します。第三者のコンポーネントについては、そのライセンスに従う必要があり、包括的な条項を一つ設けるだけで既存の利用許諾に代えることはできません。
より有効な検収方法は、契約で定めた独立した環境で、納品資料に基づいて一度デプロイし、ページへのアクセス、管理画面へのログイン、コンテンツ公開、フォーム送信、ファイルアップロードなどの主要機能を確認することです。問い合わせメール、決済、物流のインターフェースがある場合は、アカウントを再設定した後の呼び出し動作も確認します。
これにより、ファイルがそろっているように見えても、Webサイトがサービス会社から開示されていないインターフェース、ライセンスサーバー、暗号化モジュールに依存し、環境を変更すると動作しなくなるというよくある問題を発見できます。使用を認める依存関係については、利用条件と費用を事前に明記しましょう。
マーケティングサイトを移行する場合は、価値のあるページURL、SEOタイトル、ディスクリプション、リダイレクトルールに加え、必要な分析設定やコンバージョントラッキング設定も引き継ぐ必要があります。Webサイトが表示できても、従来のプロモーション施策がすべて引き継がれたとは限りません。
契約では、ソースコードの納品、デプロイ検証、瑕疵の修正を検収条件に含め、それに対応する支払い時期を検収結果と連動させましょう。公開後に引き続き変更するコードについても、更新版の納品時期を定め、古いバージョンが渡されるのを防ぐ必要があります。
西安のWebサイト制作の見積もりを比較する際は、開発費、ソースコード納品費、第三者の利用許諾料、デプロイ・移行費、継続サービス費に分けて確認しましょう。見積もりが安くても、長期にわたり有料インターフェースへの依存が必要なら、解約コストが増える可能性があります。汎用的な基盤コードのすべての譲渡を求めれば、初期費用が上がる場合もあります。
長期的な追加開発、複数システムとの連携、または自社運用が必要なWebサイトでは、独立したデプロイと保守の権限を重視するのが適しています。標準的な企業紹介サイトにSaaSを利用する場合は、データをエクスポートできること、費用を予測できること、契約終了後の移行方法を重点的に確認しましょう。
以下の文言を納品条項のたたき台とし、別紙で具体的な内容を補うことができます。
「乙は、別紙『ソースコードおよび関連資料の納品一覧』に従い、最終検収バージョンと一致するプログラムのソースファイル、データベース構造および合意したデータ、リソースファイル、依存関係一覧、デプロイ資料を納品する。プロジェクトで新たに作成した成果物、乙が以前から保有する成果物、第三者のコンポーネントの権利帰属、利用許諾の範囲および制限条件については、それぞれ別紙に従う。納品成果物は、合意した環境において資料に沿ってデプロイでき、合意した機能検収に合格するものとする。開示されていない必須の依存関係によりデプロイまたは実行ができない場合、乙は合意した期間内に不足分を補完するか、修正する。」
さらに、納品日、修正期限、移行支援の範囲、契約違反時の対応を追加しましょう。契約締結前にサービス会社に一覧の各項目を記入してもらうほうが、「ソースコード一式を納品する」という曖昧な一文を残すより、支払う費用で最終的に何を得られるのかを判断しやすくなります。
関連記事
関連製品