私は、モバイルアプリケーションを開発し、CISに拠点を置くIT会社の弁護士です。その活動の性質上、顧客との契約に署名するプロセスと密接に関連しています。顧客は最近、「テンプレート契約」の条件に同意しないよう努力しています。 そして今、次の英国の顧客は、私たちが通常提供する保証義務の構成の見直しを要求しています。 顧客の便宜のために、英国の法律が適用法として選択されています。これは、保証などの困難な条件の交渉における特定の困難を意味します。
可能な限りリスクから身を守ることは顧客の完全に自然な願いです。セールスマネージャーは非常に粘り強く、すべての法的詳細に時間を浪費しないことを要求します。
第一に、顧客にすべての保証を与え、それによって管理者との良好なクライアントと友好関係を維持するという要望があります。 私たちのチームは効率よく時間通りに働き、主に化粧品の問題で顧客との問題が発生します。 しかし、これは無制限の保証の準備ができているということですか？
私たちも他の国内開発会社も準備ができていないことを確信しています。 そして、弁護士の主な仕事が法的リスクを認識して軽減することである場合、私たちが顧客に提供できる保証と、どの保証を船外に残すかについて考える必要があります。
少し調査した後、このテーマに関する私の結論を共有したいと思います。
まず、ちょっとした理論：
「英国のIT法の保証とは何ですか？」
保証は契約上の義務です。 この用語は、一般的な法制度の国の法律の典型です。 保証を通じて、取引相手の1つは、現実の特定の事実または将来発生する事実が真実であることを保証します。
一般的な保証は次のとおりです。
機能の保証 -パフォーマンスの保証。
所有権の保証は、製品の所有権を移転する際の法的所有権の純度の保証です（開発者はそのようなサービスを提供する権利を持っています）。
侵害保証 -開発プロセス中に著作権侵害がないことの保証。
商品性の保証-使用する製品の適合性の保証。
特定の目的に対する適合性の保証 -「お客様の目標が達成されます」。
容量に関する保証-開発者が法的文書に署名することを許可されていることの保証。
ウイルスおよび無効化コードに関する保証-製品のウイルスセキュリティの保証。
互換性の保証は 、当事者のハードウェアの互換性の保証です。
同時に、一般的な保証の中で、特別なグループを「暗黙の保証」として識別することができます。これは自動的にソフトウェア開発契約の一部です。 これらの保証の効果を明示的に除外しない限り、これらの保証はこの契約に基づく法的関係にも適用されます。 たとえば、黙示的保証には、1）所有権の保証、2）侵害の保証、3）商品性の保証、4）特定の目的に対する適合性の保証が含まれます。
特定の状況でのみ関連する可能性がある特定の目標を達成するために、当事者が契約の他の保証を提供する場合があることに注意してください。 それらの内容は、当事者の実際の意図と保証の性質を正確に反映する必要があります。
理論から実践へと移行する時が来ました。 将来的には、あらゆる種類の保証についてさらに詳しく話します。最も人気のある機能保証から始めることをお勧めします。 私の場合、この保証に関して顧客との意見の相違はありませんでしたが、慎重に取り、いくつかの文言を作成することをお勧めします。
成功した処方の例：
1.「提供者は、納入後1年間に、ソフトウェアが別紙Aの5番目に設定された技術仕様に記載されているように実質的に機能することを保証します」
2.「プロバイダは、インストール後最初の180日間、各新モジュールが「公式製品ドキュメント」という見出しの下でプロバイダが発行したドキュメントに実質的に準拠することを保証します。」
ソフトウェアパフォーマンス保証とは、ソフトウェアが開発プロセスの不可欠な部分である技術仕様に従って（少なくとも保証期間中に）機能することを意味します。 このような保証を策定する際の開発者の主なタスクは、操作性の正確さ、およびこの操作を説明するドキュメントのリストを正確に判断することです。
成功例1の文言は、このタスクにうまく対処しました。 この例は、「 実質的に（実質的に） 」という用語を使用しているという点でも幸運です。 この用語は、ソフトウェア開発者を、顧客による軽微な（化粧品の）欠陥の識別から生じる問題や義務に関連するリスクから保護します。 当然、機能の記述に関して技術仕様の準備を真剣に検討する価値があります。 成功した例1は、仕様を信頼し、仕様が適切であり、当事者の真の意図を反映していることを前提としています。
成功した例No. 2はさらに進んで、必要な文書に添付され、製品に関連するすべての文書のパッケージを結合する条件付きラベル「 Official Product Documentation 」を使用しています。 この措置がプロジェクトワークフローの体系化の優れた例であることは注目に値します。 成功した例2は、その予防設計「 実質的な適合 -本質的なコンプライアンス」でも注目に値します。 実際、開発の最後に製品が設計ドキュメントに従って完全に機能するかどうかはわかりません。 この設計の目的は、全体的なパフォーマンスの保証に柔軟性を追加することです。
実際には、次のような不幸な処方に遭遇する可能性があります。
• 「プロバイダは、ソフトウェアが正常に機能することを表明および保証します」-この場合の「正常に機能する状態」とは何ですか？ この言い回しはあまりにも曖昧であり、その不確実性は顧客側のクレームのリスクをもたらします。
•「 プロバイダは、ソフトウェアがそのドキュメントに従って機能することを表明および保証します」-「ソフトウェアドキュメント」とはどういう意味ですか？ 「ソフトウェアのドキュメント」では、製品開発プロセスに関連するドキュメントを無制限に理解できます。 しかし、セールスマネージャーやビジネスアナリストとのやり取りをここに含めるとどうなりますか？ 電子を含む手紙は文書であり、製品を指します。 しかし、通信に記載された規定に従って機能するソフトウェアが必要ですか？ 私たちは、たとえば技術仕様を作成するなど、手紙を書くことにそれほど真剣ではないので、そうではないと思います。 レターでは、多くのことを約束するか、何かを約束することができます。そして、仕様がレターよりも大きな法的効力を持っていることを証明する必要があります。 結局のところ、プロジェクト文書の階層にレターを含めて、レターの優先ルールを規定する人はほとんどいません。
また、パフォーマンス保証は、そのコンテキストで規定されている特定の要件に対処できます。 例： 「プロバイダーは、インストールされた成果物がない場合、別紙Cに記載された速度で購入および販売取引を処理するシステムの能力を損なうことを保証します」 。
結論：
そのため、開発者の最も重要な保証の1つを検討しましたが、いくつかの保証があり、それらも慎重に扱う必要があります。
この保証は、契約に含める価値があります。 お客様がソフトウェアが将来動作するかどうか、または障害が発生した場合に少なくとも法的救済を受けるかどうかを確認せずに契約に署名することはほとんどありません。 同時に、過去10年間に開発され、誰もが忘れていた製品に無制限の頭痛がしたくないので、保証期間（たとえば、「インストール後の最初の180日」）を制限する価値があります。
興味深い場合は、他の種類の保証の機能に関する質問と、暗黙の保証の影響を正しく除外する方法について質問に答えることができます。
英語の契約におけるソフトウェアパフォーマンスの保証（パート1）
All Articles