ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

イメージ

IT調達の最適化:契約交渉における留意点

ITマネジメント (ITM) /ITM-13-09
Research Note
E. Matsubara, S. Yamanoi
掲載日:2013年9月24日/発行日:2013年2月25日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2013年10月15日(火)〜17日(木)に開催する 「Gartner Symposium/ITxpo 2013」 のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)

 

IT調達の最終結果として、特定のベンダーと契約を締結することになる。本リサーチノートでは、提案要請書 (RFP) の送付から始まる契約交渉および契約内容について、注意すべきポイントを説明する。

要約

主要な所見

    ● 契約交渉におけるユーザーとベンダーのパワー・バランスは、特定のベンダーに内示を与えた時点で、ベンダー側に大きく有利に傾く。

    ● ユーザーが契約書の雛型を持っている割合は非常に少ないが、ベンダーは雛型を必ず持っている。

推奨事項

    ● 契約交渉は、ベンダーに内示を出した後に始めるのではなく、RFP作成以降のベンダー選定プロセスの一部と考え、主要な項目について内示を出す前に、ベンダーからの言質を取っておく。

    ● 契約交渉においては自社の契約書の雛型を提示し、その土俵の上で相手側と交渉できれば、有利な条件を確保できる。雛型を持っていない場合は、外部で公表されている雛型を徹底的に活用する。


分析
一般的に契約書の内容としてはどのような項目があるか。契約書の雛型としてよく使われている経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」による『〜情報システム・モデル取引・契約書〜 (受託開発 (一部企画を含む)、保守運用)〈第一版〉』では、以下の8章からなるソフトウェア開発委託基本モデル契約書を提示している。
    ● 第1章 総則

    ● 第2章 本件業務の推進体制

    ● 第3章 本件業務

    ● 第4章 契約内容等の変更

    ● 第5章 資料及び情報の取扱い

    ● 第6章 権利帰属

    ● 第7章 保証及び責任

    ● 第8章 一般条項
この雛型の前提は、委託側は民間大手企業に、受託側は情報サービス産業となっているので、社内のリソースが不足している中堅企業が利用する場合には、外部のコンサルタント等の活用を考慮すべきである。また、この雛型は、「ソフトウェア開発委託基本モデル契約書」というタイトルに示されるように、基本契約と個別契約の2本立てで作られている。

これらの項目に含まれる主要なポイントについての注意点は、以下のとおりである。

契約類型
準委任契約と請負契約では、ベンダーの成果物責任について大きな違いがあり、成果物の完成責任があるのは請負契約である。しかし、システム開発プロジェクトでは契約時に成果物を定義している外部仕様が明確になっているケースは少なく、一般的には、外部仕様の作成もプロジェクトの一部とするケースが多い。この場合、外部仕様作成までの作業は準委任契約とし、内部仕様作成以降の作業を請負契約とすることをガートナーでは推奨している。

この契約形態を取った場合、RFPとしては内部仕様作成以降の作業も含めた提案を依頼し、ベンダー選定においては、内部仕様作成以降も含めた提案を受け取り、外部仕様作成までの準委任契約と、内部仕様作成以降の作業を請負契約にする2段階の契約とするか、プロジェクト自体を外部仕様作成までと、内部仕様作成以降に分けて、ベンダー選定も2回行うやり方がある。ただし、後者が適用できるのは、その業界の特徴に詳しいコンサルティング企業等で、自社ではシステム開発を行っていないという場合に限られる。また、費用増大のリスクもある。

検収・支払い条件
内部仕様作成以降の作業を請負型で契約する場合、いくつかの工程が完了したら、そこで作成した内部仕様書に対して検収を行う多段階契約をベンダーが提案してくることがある。この提案を受け入れる場合は、次のフェーズへの移行を判断する検収基準を明確にしておく必要がある。原則的には、システムが稼働して初めてユーザー企業にとってのビジネス的な効果が挙がるので、内部仕様作成から稼働までは1つの請負契約としてベンダーの完成責任を求めることを契約上明記するのが理想であろう。ただし、検収まではまったく支払わないというのではなく、プロジェクトやベンダーの規模に応じて、中間支払いを行うことを考えるべきである。

損害賠償責任
請負契約を締結した場合、ベンダーの開発業務の結果、ユーザー企業が損害を受けた場合についての賠償責任を規定する。対象となる損害の範囲、賠償金額の上限、賠償金額の算定の仕方、開発遅延の取り扱いについて、モデル契約では、ユーザー企業とベンダー企業の合意に基づくとしており特定の方法を提示していない。これらの項目については、通常、以下のようになっている。
    対象となる損害の範囲:通常損害に限定され、特別事情による損害や、逸失利益、間接損害については賠償されない。

    賠償金額の上限:契約金額を上限とする場合が多い。この場合、多段階契約になっていると、契約金額は各個別契約の金額となるので、この点からも多段階契約には注意が必要である。

    賠償金額の算定の仕方:損害の範囲を通常損害に限定した場合でも、ベンダー側に損害の責任が100%ある場合はまれで、両者の責任配分の議論は難しい。

    開発遅延の取り扱い:開発業務の場合、ユーザー企業がシステムを実利用するのは検収をした後なので、それ以前の段階でユーザー企業に大きな通常損害が生じることはない。請負の開発契約において最も発生する度合いが高いのは、開発の遅延である。しかし、逸失利益は対象となる損害の範囲外であり、対象となるのは、稼働していれば不要になるはずであった既存システムのリース料や保守料ぐらいである。この逸失利益の保証を求めるのであれば、開発遅延1日につき、契約金額のある割合を延滞損金として支払うよう記載すべきである。

    運用停止の取り扱い:クラウド・サービスが停止した場合、ユーザー企業はオンライン・ショップの停止といった大きな影響を被る。サービスの実質的な停止が長期に及んだ場合、この被害額はサービス利用料に比べるとはるかに大きいので、通常の契約に含まれる年間ないし月間の利用料を上限とする損害賠償条項ではカバーできず、データ誤消去のように金銭的に解決できない状況も発生する。したがって、賠償金条項だけではなく、自社で独自にバックアップを取るといった対策を考える必要がある。
著作権の帰属
著作権の帰属については、モデル契約ではベンダーにすべての著作権を帰属させる場合【A案】、汎用が可能なプログラム等の著作権をベンダーに、それ以外の権利をユーザーに帰属させる場合【B案】、汎用が可能なプログラム等の著作権をベンダーに、それ以外を共有とする場合【C案】の3案を併記している。

ユーザー企業が、開発されたアプリケーション・ソフトウェアの著作権を持っていなくても、複製物の所有権を持っていれば、プログラムについては一定の改変、複製・翻案が著作権法により許容されており、ITグループ会社を含むベンダーを使ってアプリケーションの維持管理を行うことも可能である。ただし、仕様書の改編については、ユーザー側で可能となるように、著作権の共有も含めて明確にすべきである。

したがって、ユーザー企業が著作権の保有を主張する理由としては、自社のノウハウ等の流出を防ぐこと、開発費用をユーザー企業が負担していること、第三者に将来的に販売することが考えられる。
    ● 自社のノウハウ等の流出については秘密保持義務の適用で防止できるので、著作権を保持する必要はないと考えられる。

    ● ベンダーの開発費用の見積もりが、開発に要する総人月のコスト+間接コストになっているのであれば、ユーザー企業が開発費用をすべて負担しているので、成果物の著作権を主張することは、妥当性がある。しかし、前述のように、ユーザー企業が著作権を保持することのビジネス的なメリットがあまりないとすれば、著作権の帰属は価格交渉の1つの「てこ」として使うべきである。

    ● 開発されたアプリケーション・ソフトウェアには、ベンダーが以前から著作権を保有している共通ルーティンが含まれているのが一般的であり、ユーザー企業が、単独でそのアプリケーション・ソフトウェアを第三者に販売することは難しいと考えられる。
第三者監査への対応
クラウド・サービスを利用する場合、サービスの提供にかかるベンダーの業務が適切に行われているかについて、ユーザー側が自社または第三者を使って監査する権利を確保するか、サービスの提供側がSSAE16や86号監査のような第三者監査を取得することを盛り込むべきである。もちろん、複数のユーザー企業から同様の監査を受けることは、サービスの提供側も大変になるので、第三者監査の取得が望ましい。

フリー・ソフトウェア・オープンソース・ソフトウェア (FOSS) の利用
FOSSの利用をベンダーが提案してきた場合、ユーザー企業側のリスクとしては、ソフトウェア・バグへの対応と、FOSSが第三者の特許権等の知的財産権を侵害していて訴えられる可能性がある。ソフトウェア・バグへの対応については、OSやミドルウェア等の第三者ソフトウェアのバグと同様に、FOSSを使う側のソフトウェアを改修してバグを回避するか、ソースコードが公開されているOSSの場合であればOSS側を修正することで対応させるべきである。

次に、FOSSが第三者の知的財産権を侵害している場合は、特許権侵害による使用差し止めの措置を受ける可能性もゼロではない。しかし、特許申請には非公開期間がある上に対象となる特許の数も多いので、FOSSが知的財産権を侵害していないことを確認するのは実質的に不可能である。このリスクを避けるためには、GNU General Public License (GNU GPL/GPL) のような厳密にライセンシング・ポリシーや統制されたコミュニティ、開発ロードマップを持ったOSSを使用するやり方がある。また、ある程度のリスクをベンダーとシェアして、万が一知的財産権の侵害で訴えられた時は、共同して対抗することや、費用を折半して知的財産権を侵害しないソフトウェアを開発することを契約に盛り込むべきである。

その他の留意事項
    ● 提案書と契約書の記載内容に整合性があることを確認すべきである。過去にユーザー企業とベンダーの間で訴訟となったケースの中には、実現機能について提案書と契約書の記載内容の違いに端を発したものがある。原則的には契約書の法的効力が優先するため、IT部門は、トラブルを避けるためにも、提案書内容の実現が契約書上も文言として具体的に義務付けられていることを確認する必要がある。

    ● 請負契約の場合、ベンダーの作業をユーザー企業が直接指示することはできない。このため、進捗状況や品質に関するベンダーのパフォーマンスがブラックボックス化し、ユーザー企業側からの把握が困難になる場合がある。そこで、請負契約の場合も、プロジェクトに対するレビュー権・監査権をユーザー側が保持する旨の一文を条項に含めておくことが望ましい。請負契約の範囲において、ベンダーがサブ・コントラクターを使用するケースでも、サブ・コントラクターのプロフィールの提示、直接面接する機会の設定、委託範囲・工数の限度枠の設定など、プロジェクト内容の透明化を図る仕組みを検討すべきである。
ベスト・プラクティス
    ● 配布するRFPで、ベンダーに契約書の雛型の提出を求める。

    ● ベンダーに内示を出す前に契約交渉を開始し、契約書の主要項目について言質を取る。

    ● 各契約項目の留意点について、チェックをかける。


    推奨リサーチ
    ・ 「IT製品等の購入契約交渉時に最低限守るべき9つの心得」(ITM-11-02、2011年2月4日付)
    ・ 「IT調達の最適化:調達プロセスのステップと体制の整理>」(ITM-13-07、2013年2月25日付)
    ・ 「IT調達の最適化:RFP作成における7つの留意点」(ITM-13-08、2013年2月25日付)


ITM: ITM-13-09

※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright