MIC

読み込み中 0%

MICMIC

Webサイト開発契約の成果物を明確に記載する方法 MIC Studio

·

Webサイト開発契約で最もトラブルになりやすいのは価格ではなく、成果物の範囲です。本記事ではソースコード、デザインカット、ドメイン・サーバー、管理画面アカウント、検収基準の5分類に分けて解説し、そのまま契約書に転記できる書き方を提示するとともに、MIC Studio のような外部チームに依頼するのが適切なケースについて説明します。

多くの経営者はWebサイト開発契約を結ぶ際、見積もりと工期に注意が向き、成果物の欄には「Webサイト一式、ソースコード一式」と適当に書いてしまいます。プロジェクトが完了してから、デザインカットがもらえない、管理画面のアカウントが受注者側にある、サーバーが相手名義である、バナーを1つ変更するのにも追加費用がかかる、といったことに気づくのです。


これは誰が悪いのではなく、契約が明確に書かれていないことが原因です。成果物を具体的に書くほど、後々楽になります。以下、5つの分類に分けて説明し、それぞれそのまま修正して使える書き方を示します。


一、ソースコードとデプロイパッケージ:「何を、どう渡すか」を明確に


ソースコードは最も曖昧になりやすい項目です。契約書には次の3点を明記することをお勧めします。どのコードを納品するか、どのような形式で納品するか、納品後に単独で稼働できるか。


実行可能な書き方は、フロントエンドのソースコード、バックエンドのソースコード、データベース構造ファイル、デプロイ手順書をパッケージ化して納品し、納品後は発注者が自社サーバー上で独立してデプロイ・稼働できることを約定する、というものです。


注意すべき点は2つあります。1つは「ソースコードを提供する」とだけ書いてデータベース構造を書かない場合、コードを受け取っても稼働できないこと。もう1つは、コード内で受注者が独自に構築したプライベートコンポーネントや暗号化ファイルを参照しており、表面上は納品されていても実際には相手から切り離せないことです。企業サイトのようなプロジェクトでは特に注意が必要で、多くのテンプレートサイトのいわゆるソースコードは、実際にはライセンス付きの二次カプセル化です。


ミニプログラム開発の場合は、さらに明確に記載する必要があります。ミニプログラムの主体アカウントは発注者に帰属し、コードは発注者自身の開発者バックエンドに提出できること。


二、デザインカットと素材:スクリーンショットだけを渡さない


デザイン成果物には、編集可能なソースファイル(Figma、Sketch、PSDなど)、スライス画像リソース、フォントとアイコンの使用説明を明記することをお勧めします。


JPGのスクリーンショットだけを渡すのは、渡していないのと同じです。後でデザイナーを変更したり、キャンペーンページを展開したりする際に、すべて描き直しになります。


さらに、素材の著作権帰属も約定する必要があります。受注者が使用する画像、フォント、アイコンが商用利用可能かどうか、著作権紛争が発生した場合に誰が責任を負うか。この条項はWebサイト開発プロジェクトではよく見落とされますが、実際に問題が起きると即座に公開停止となります。


三、ドメイン、サーバー、アカウント:所有権は必ず明記


これは紛争が多発する領域です。契約書には、ドメインは発注者名義で登録され、サーバーまたはクラウドアカウントは発注者が実名で購入し、受注者は開発・運用期間中の必要な操作権限のみを保持することを明記すべきです。


具体的なシナリオ:ある企業がコーポレートサイトのリニューアルを行い、完了後にドメインが前のサービス業者の手にあることに気づき、更新には追加費用、移管には協力が必要で、1ヶ月遅延したケースがあります。


そのため、納品リストには以下を記載する必要があります。ドメイン管理アカウント、クラウドサーバーアカウント、データベースアカウント、管理画面管理者アカウント、ICP登録情報、サードパーティサービス(SMS、決済、地図)のアカウントとキー。引き継ぎ時には項目ごとに確認し署名します。


四、管理画面とドキュメント:使えて初めて納品


管理システムの納品はアカウントだけではありません。機能一覧、フィールド説明、ロール権限説明、よくある操作マニュアルも含まれます。


オンラインまたはオフラインの引き継ぎトレーニングを1回実施し、画面録画を保存することを約定することをお勧めします。これにより人員異動の際、新しい同僚が自分で確認できます。


App開発や複雑な管理画面プロジェクトでは、APIドキュメントとバージョン履歴の提供も求め、後続の他システム連携を容易にすべきです。


五、検収基準:「使える」を測定可能な項目に


検収条項は実行可能でなければなりません。機能は要件定義書に基づき項目ごとに検収、主要ブラウザと機種の互換性リスト、ページ読み込み時間の上限、Webサイトセキュリティテストの基本項目(一般的なインジェクション、権限昇格、機密情報露出の調査など)を記載することをお勧めします。


同時に、欠陥修正期間と対応期限、検収不合格時の是正ラウンド数も約定します。


注意:「発注者が満足することを基準とする」や「業界標準に適合する」といった検証不可能な表現は書かないでください。


MIC Studio に依頼するのが適切なケース


以下のような状況にある方は、ぜひご相談ください。要件がすでに明確で、実行可能な納品リストが必要な場合。既存システムのリバーステストやセキュリティ調査が必要な場合。あるいは社内に専任の技術者がいないが、アカウント、ソースコード、ドキュメントをすべて自社で保持したい場合。


当社は企業サイト、ミニプログラム開発、App開発、スクリプト開発を行い、セキュリティテストも承っています。契約段階では成果物を項目ごとに表にまとめ、添付資料として署名に含めることで、後々の繰り返しの説明を避けます。


3つの実行可能な提案


1. 成果物を表形式の添付資料にし、「名称、形式、納品時期、検収方法」を項目ごとに記載し、署名確認する。

2. 契約前にドメインとクラウドアカウントが誰の名義かを確認し、自分の名義でない場合は、まず移管してから開発を相談する。

3. 最終支払いの割合を検収に連動させ、10%~20%を引き継ぎトレーニング完了、アカウント確認完了後に支払う。


契約を細かく書くのは不信感からではなく、双方が説明に費やす時間を減らすためです。