エージェンシーが見つかりました。ポートフォリオも充実していて、費用も妥当で、最初の打ち合わせもうまくいきました。そして契約書が届きました。
多くのクライアントは、作業範囲を確認し、金額を確かめ、スケジュールをざっと確認して、そのままサインします。
これは間違いです。そして、何度となく悪い結果を招いてきた間違いです。
クライアントに最も大きなダメージを与える条項は、目立つものではありません。ほとんどの人が読み飛ばすセクションに潜んでいます——知的財産権、成果物の定義、そして契約終了時に何が起きるか、という部分です。これらの3つの領域が、成功するパートナーシップと「数百万円払ったのに自分のものではないコード、ドキュメントなし」という事態の差を生みます。
契約書にサインする前に交渉すべき内容を解説します。
1. コードの所有権：実際に何に対してお金を払っているのか？
公正な契約では、クライアントがコードを所有します。しかし「公正」はデフォルトではありません——契約書に明記する必要があります。
多くのエージェンシーの契約には、最終支払い後にのみ知的財産権がクライアントに移転するという条項が含まれています。一見合理的に見えますが、実際には何を意味するかを考えてみてください。プロジェクトが半分進んだ時点でエージェンシーを変えたい、または社内に開発を移管したい、あるいは最終請求書に異議を唱えたい場合、エージェンシーはコードベースの法的所有者のままです。持ち出すことはできません。
交渉すべきポイント：
- 所有権は最終支払い時ではなく、各マイルストーンで移転させる。 成果物が承認され、請求書が支払われるたびに、知的財産権も移転します。
- 初日からリポジトリへのアクセス権を確保する。 GitHub、GitLab、Bitbucketなど、バージョン管理リポジトリへの管理者レベルのアクセス権が必要です。読み取り権限や、プロジェクト終了時にのみ付与されるアクセスでは不十分です。もし拒否されたら、理由を聞いてください。
- サードパーティコンポーネントの開示を求める。 オープンソースライブラリ、ライセンス付きSDK、外部ベンダーのコンポーネントはすべてリストアップされるべきです。制限的なライセンスを持つ重要な依存関係が含まれていないか確認する必要があります。
- 受託開発（Work-for-hire）の明記。 多くの法域では、契約に基づいてクライアントのために構築されたソフトウェアはwork-for-hireに該当します。解釈に委ねるのではなく、契約書に明記させましょう。
誠実なエージェンシーであれば、これらの条件に問題はないはずです。抵抗するエージェンシーは、何かを示しています。
2. 引き渡し条件：プロジェクト終了時に実際に何を受け取るのか？
多くのエージェンシーは引き渡しを後回しにします——プロジェクトが「完了」してから考えることだ、と。しかし引き渡しが契約書で定義されていなければ、義務ではなく善意に頼ることになります。
製品リリース可能な状態のアプリを受け取ったのに、ドキュメントが一切なかった、というファウンダーの話を聞いてきました。READMEなし、デプロイガイドなし、インフラ構成の説明なし、アーキテクチャの判断理由の説明なし。技術的にはエージェンシーは納品しました——ただし、長期的な運用に役立つものは何も納品しませんでした。
適切な引き渡しに含まれるべきもの——契約書に正式な成果物として明記する必要があります：
- READMEとセットアップガイド ——ローカル環境での起動方法、環境設定の方法、依存関係の一覧。
- アーキテクチャドキュメント ——システムの全体像：主要コンポーネント、その接続方法、各サービスの役割。詳細な論文は不要ですが、新しい開発者が半日でシステムを理解できる程度の内容は必要です。
- デプロイメントランブック ——ステージング環境と本番環境へのデプロイ手順。ロールバックの方法。使用しているモニタリング設定。
- 環境設定ガイド ——どの環境変数が存在するか、それらが何を制御するか、シークレットはどこに保存されていてどのように更新するか。
- ナレッジトランスファーセッション ——少なくとも1回、リードデベロッパーがあなたのチーム（または次のエージェンシー）にコードベースを説明するワーキングセッション。
これらはオプションの追加項目ではありません。自分たちが構築したものに自信を持っているエージェンシーであれば、ドキュメント化を嫌がることはないはずです。ドキュメンテーションを不要なオーバーヘッドと見なすエージェンシーは、その開発文化を表しています。
3. 解約条件：関係が終わったとき、何が起きるのか？
すべての契約は終わります——円満に、予定より早く、あるいはその中間のどこかで。その後何が起きるかは、最初から定義されるべきであり、プレッシャーの中で交渉されるべきではありません。
これは、ほとんどの契約書が最も不十分に扱うセクションです。曖昧な解約条件は偶然ではありません——エージェンシーに交渉力を与えます。データ、リポジトリ、アクセス権を取り戻すプロセスが定義されていなければ、エージェンシーの協力次第ということになります。それは危険な立場です。
交渉すべきポイント：
- リポジトリ移転のSLA。 リポジトリを自分の組織に移したい場合、どのくらいの時間がかかりますか？48時間が妥当です。「都合のいいときに」では不十分です。具体的な期間を契約書に明記しましょう。
- データエクスポート。 エージェンシーはどんなデータを保持していますか？データベース、バックアップ、アナリティクス、ユーザーデータ。受け取る権利があるものと、そのフォーマットを定義しましょう。
- アクセス権の失効タイムライン。 契約終了時に、エージェンシーのメンバー全員のシステム、リポジトリ、クラウド環境へのアクセス権は、定められた期間内に失効させる必要があります。この条項がなければ、エージェンシーの元従業員が本番環境へのアクセス権を無期限に保持し続ける可能性があります。
- 終了後のサポート。 エージェンシーが質問に答えてくれる期間はありますか？その費用は？元の契約書に30日間の有償Q&Aサポートを定義しておく方が、終了後に交渉するよりもはるかにスムーズです。
- 契約終了後も存続する条項。 守秘義務と知的財産権の移転義務は、契約終了後も有効であるべきです——契約書にその旨を明記しましょう。
注意すべきレッドフラグ： 解約条件について防衛的な態度をとるエージェンシー、具体性を避けるために「一般的な慣行」という言葉を使うエージェンシー、リポジトリへのアクセス権移転前に長い通知期間を必要とする条項を含むエージェンシー。解約時に自分を守ることは当然の権利です。それに抵抗するエージェンシーは、あなたの利益ではなく自分たちの交渉力を守っています。
私たちの考え方
TMNSolutionsでは、クライアントが求めなくても、これらの条項をデフォルトで契約書に含めています——クライアントがそれらを受け取るべきだと信じているからです。コードの所有権はマイルストーンごとに移転します。引き渡しは明確に定義された成果物です。解約条件は明確で公平です。
エージェンシーを評価していて、これらのトピックで候補者が不快感を示すなら、その不快感に注目してください。良いエージェンシーパートナーは、関係を維持するためにコードベースへの交渉力を必要としません。
よく書かれた契約書は、使う必要がないものです。しかし何かがうまくいかなかったとき、それが存在していてよかったと思うはずです。
