ウェブサイト構築サービスの調達で最も争いになりやすいのは、サイトが開くかどうかではなく、どの状態をもって納品完了とするのか、公開後に問題が発生した場合に誰が対応するのかという点です。ウェブサイトの設計・保守契約(contrat de conception et de maintenance de site web)を締結する際は、ページ、機能、検収方法、保守の範囲を実行可能な別紙に明記し、支払いの節目を納品成果に対応させる必要があります。
ウェブサイト構築契約の見積もりには、サイトの利用開始後に継続して発生する費用も含めるべきです。ドメイン、サーバー、システムライセンス、後続の修正を誰が負担するかは、実際の調達コストに直接影響します。これらの事項が「1年間の保守を提供」とだけ記載されている場合、初年度の見積もりが低くても、各社の実際の提案を比較することは困難です。
契約には、ウェブサイトの言語バージョン、ページの種類、セクション数、主な機能、対応要件を列挙する必要があります。たとえば、多言語サイトでは、翻訳とアップロードをサービス提供者が行うのか、それとも企業が訳文を提供するのかを明確にします。また、「製品紹介」についても、製品カテゴリ、詳細ページの項目、画像の枚数、一括登録方法を具体的に定める必要があります。問い合わせフォームについては、必須項目、受信先メールアドレス、通知方法、テスト方法を明記します。
ページ数の算定基準も明確にする必要があります。同一テンプレートを使った複数の製品詳細ページを、テンプレート数で数えるのか、実際の登録件数で数えるのか、上限を超えた場合にどのように課金するのかを定めます。企業が提供する文章、画像、製品資料については、提出時期と形式を合意します。サービス提供者が担当するデザイン、制作、登録作業は別途明記し、プロジェクトが遅延した際に双方が相手方の責任と主張する事態を防ぎます。
契約に検索エンジン最適化の基本設定が含まれる場合は、ウェブサイトに備わる機能と最終的なマーケティング成果を区別します。各ページのタイトルと説明文の設定、サイトマップの生成、ページのリダイレクト設定は、確認可能な納品項目です。一方、検索順位、インデックス登録数、問い合わせ件数は、コンテンツ、競争環境、検索エンジンのルールにも左右されるため、曖昧な約束だけを検収基準とするのは適切ではありません。広告配信や長期的なコンテンツ運用も、ウェブサイト構築費用に含まれるものと想定すべきではありません。

検収用の別紙には、テスト環境、ブラウザーとモバイル端末の対応範囲、テスト用アカウント、確認項目、結果の記録方法を明記します。問い合わせ機能を例にすると、テスト情報を送信した後、指定したメールアドレスに該当項目を含む通知が届くことを定められます。同時に、管理画面に記録が保存されるか、迷惑情報のフィルタリングが通常の問い合わせに影響しないかも確認します。
機能以外に、多言語ページに欠落や誤ったリダイレクトがないか、画像やダウンロードファイルにアクセスできるか、既存サイトのリニューアル時に維持すると合意したURLがリダイレクトされているかも確認します。性能指標を定める場合は、テストツール、対象ページ、ネットワークや端末の条件、サードパーティ製プラグインが結果に与える影響も明記します。「表示速度が速い」とだけ定めることは避けるべきです。
検収手順には、検収提出、問題の報告、修正、再検収、確認書への署名それぞれの期限を定め、公開を妨げる重大な不具合と、主要機能に影響しない一般的な問題を区別します。期限内に回答がない場合に検収済みとみなすかどうかについては、通知方法と期限の起算日を明確にします。未解決の不具合がある場合も、ウェブサイトが公開されたことだけをもってすべての作業が完了したとするのではなく、問題、修正期限、未完了事項を記録する必要があります。
保守には通常、障害修復、セキュリティ更新、バックアップからの復旧、コンテンツ修正、機能調整が含まれますが、作業量には大きな差があります。契約には、対応時間、受付窓口、料金に含まれる修正回数または作業時間、上限を超えた場合の見積もり方法を明記します。「無料修正」が文章や画像の差し替えを指すのか、新しいページのデザイン、インターフェース開発、機能変更まで含むのかも明らかにする必要があります。
障害対応では、応答時間と復旧時間を区別します。前者は受付を確認して対応を開始するまでの期限、後者はサービスを復旧するまでの期限です。ウェブサイトにアクセスできない、問い合わせ機能が動作しない、一部の表示に異常があるといった状況に応じて、異なる優先度を定めることができます。サードパーティのクラウドサービスの障害や、企業が必要な権限を速やかに提供しなかったことによる遅延についても、通知、記録、連携対応の方法を明記する必要があります。すべての問題を一律に免責事項とするのは適切ではありません。
バックアップ条項には、バックアップの頻度、保存期間、保存場所、復旧範囲、復旧テストの実施予定を明記します。「定期的にバックアップする」と定めるだけでは、障害発生後にウェブサイトを復旧できることの保証にはなりません。データベースとアップロードファイルを別々にバックアップする場合は、両者を一緒に復旧できるかも確認する必要があります。保守期間の起算日を公開日、検収日、支払日のいずれとするかも、契約で明確にします。
単に日付に基づいて支払うよりも、段階的な支払いのほうが納品リスクを管理しやすくなります。契約では、デザイン案の確認、テスト環境の納品、正式検収などの節目に支払いを連動させ、各節目に対応する成果物と確認方法を明記できます。最終金額の割合は双方の協議で決めますが、主要機能、資料の引き渡し、不具合の修正が明確になる前に、ウェブサイトが公開されたという理由だけで全額を支払うべきではありません。
見積書では、初期構築費、年間保守費、クラウドリソース費、ドメイン費、証明書費、プラグインまたはライセンス費を分け、価格の適用期間、更新方法、税負担を明記します。アクセス数、ストレージ容量、サードパーティAPIの使用量に応じて課金する項目については、料金に含まれる上限、超過分の算定方法、費用の確認手順を明確にします。年度予算管理手続きが必要なプロジェクトでは、国有企業における年度投資予算の策定戦略と実践も参考にしながら複数年度にまたがる支出を整理できますが、具体的な費用は契約書と見積書の別紙に従います。
要件変更は書面による手続きで確認します。変更を提案し、費用と工期を評価したうえで、双方の合意後に実施します。確認されていない新たな要件を、当初契約の作業に自動的に含めたり、サービス提供者が一方的に追加料金を請求したりすべきではありません。一方が資料の提出、フィードバック、支払いを遅らせて進捗に影響する場合は、通知方法と工期の調整手順を定める必要があります。
ドメイン登録情報、クラウドサービス、アクセス解析ツール、広告アカウントについて、所有者、管理者権限、更新費用の負担者を明確にします。可能であれば、関連アカウントは企業が保有し、必要に応じてサービス提供者に操作権限を付与することが望ましいです。サービス提供者が代理で保有する場合は、引き渡しの条件、時期、必要な証憑を定めます。そうしないと、契約終了後に企業が更新、DNS設定の変更、サービス提供者の変更をすみやかに行えないおそれがあります。
ウェブサイトの納品では、カスタム開発とSaaS型ウェブサイト構築を区別する必要があります。カスタム開発の場合は、ソースコード、デザインファイル、データベース構造、デプロイ用ドキュメントの納品範囲と使用権を明確にします。SaaSプラットフォームでは、契約期間中の利用権、エクスポート可能なページとデータの形式、プラットフォームのテンプレートやシステムを移行できるか、サービス終了後のアクセス可能期間を重点的に確認します。「ウェブサイトは企業の所有物」とあるだけで、プラットフォームソフトウェアやサードパーティ製コンポーネントのすべての権利が譲渡されたと推定することはできません。
顧客からの問い合わせや連絡先などの情報を扱う場合は、双方のデータ処理権限、秘密保持義務、安全対策、インシデントの通知、契約終了後のデータのエクスポートと削除について定め、適用法令とウェブサイトサービスの提供地域の要件に照らして確認する必要があります。サービス提供者がサードパーティ製プラグインや下請業者を利用する場合も、その責任範囲と必要な権限付与の条件を明確にします。
納品の遅延、検収不合格、重大な障害の長期未復旧、無断でのデータ利用などについて、それぞれ是正期限、違約責任、解除条件を明記します。違約金や損害賠償の方法は契約金額と損失リスクを踏まえて協議し、「違反当事者がすべての責任を負う」とだけ記載しながら、適用条件や対応手順を定めないことは避けるべきです。
契約締結前に、当事者の名称、契約締結権限、振込先口座、請求書発行情報を確認し、本文、見積書、要件一覧、検収基準、サービス水準に関する別紙の優先順位を確認します。国境を越える契約や複雑なデータ処理を伴う場合は、準拠法、紛争解決方法、契約書の言語版も確認する必要があります。重要な条項については、プロジェクトの状況に応じて法律の専門家による確認を受けることができます。
関連記事
関連製品


