どうも、木谷です
今回はITベンダーと揉めないための契約書作りの注意点についてまとめました
契約書作りは自社が積極的にならないと揉める
さていよいよベンダーとの契約段階です
やはり、法的な要素も絡んできますのでしっかりしておきたいところです
契約がなぜ重要か？
新システムの規模が大きくなれば多少なりとも揉め事は起きるでしょう
「ああ言った」「いやこう言った」と双方にとって不毛な争いをしてしまわないために契約書があります
契約書に明記していることならば、口を出せません
また、無駄な論争を避けて、ベンダーとの良好な関係を保つことでプロジェクトがスムーズになります
契約は基本的に一度限りですので、しっかりと事前準備をしましょう
ベンダーが作った契約書を鵜呑みにしてはいけない
と契約書の重要性を述べましたが、自社が契約を把握していなければ意味がありません
契約書自体は、ベンダーが作っても自社が作ってもどちらでも良いです
ただ、ベンダーが作った契約の内容ならばしっかりと確認する必要があります
ベンダーにとって都合の悪い条件がすべて削除されていることもしばしばあるからです
記載内容の誤りはRFPで指定した条件と照らし合わせることでチェックできますが、条項の削除となると発見できないこともあります
なので原則、契約書は自社で作りましょう
自社で要求したい条項をすべて盛り込んで、その契約書でベンダーと手続きを進めます
契約書での注意点
では具体的に、揉めやすい要因となる部分を見ていきましょう
著作権は自社が持つ
著作権がどちらにあっても一見トラブルにはつながらないように思えますが…実際にあった例を見ていきましょう
基本契約書がないまま進めると…
あるシステムでは障害が多発していました
現場からはクレームの嵐でどうにか対処しなくてはいけません
ベンダーには何度も改善の要求をしていますが、なかなか手を付けようとしません
しまいには仕様変更として追加料金を求めてきたのです
さすがに、と思ったユーザー企業は新たなベンダーを開拓しようとします
すると、今契約しているベンダーよりも質がいい上に料金も安いベンダーを見つけます
これを期に、ベンダーチェンジをしようとしますが、現在契約しているベンダーから「著作権はウチにあるので、システムは最初から作りなおしてください」と言われました
慌てて契約書を確認すると、「基本契約書」自体が存在しなかったのです
「個別契約書」だけがあり、そこには著作権の記載がされていなかったのです
結局、そのベンダーは著作権を主張しゆずる様子がなかったので、しぶしぶ保守契約を延長したそうです
いまでもそのユーザー企業はベンダーに高い費用を払い続けています
出典 ： Web幹事
スクラッチ開発の著作権
スクラッチ開発の著作権は必ず自社で持ちましょう
自社のシステムでもサービスでも、ベンダーが作ったとはいえ費用を払ったのは自社です
当然、著作権は自社にあると認められるべきで、これを契約書に明記しなければなりません
特にスクラッチ開発は自社オリジナルの作品です
でも、もしベンダーが著作権を持っていれば、システム修正はそのベンダーしかできなくなります
つまりベンダーチェンジができないのです
ベンダーはそれを理解した上で足元を見た交渉が可能となります
先ほどの例のように「嫌なら今のシステムを捨てて他社さんに乗り換えてください」と言われれば抵抗する術がありません
RFPに「自社に著作権は帰属させる」と盛り込んでいても、契約書には平気で「ベンダー側に帰属する」と変更してくるベンダーもいます
契約を交わす際には細心の注意を払って確認したいところです
なお、著作権とは別に「著作者人格権は行使しない」という一文もセットでも盛り込んでおきます
この一文を入れておかないと、作った本人以外が勝手に修正できなくなるためです
パッケージの著作権
パッケージの著作権は当然ベンダー側にあります
しかし、カスタマイズの部分はどうでしょうか？
自社でカスタマイズ費用を払って、機能を付け加えたのにそのカスタマイズ部分の著作権をベンダーが持ってしまうと…
ベンダーはパッケージにその機能を追加して、販売することができます
競合他社は自社が支払ったカスタマイズ費用よりもおそらく低い値段でその機能をつけることができるのです
もしベンダーが「パッケージ本体」に追加したいというならカスタマイズ費用はベンダー負担となるような交渉を仕掛けるべきです
「自社負担の部分は、自社が著作権を持つ」に徹しましょう
瑕疵担保責任期間は１年
おそらく一度は耳にしたことがあると思います
後のリスクを最小限にするためにぜひとも知っておいてほしい部分です！
不備は後から発覚する
「請求金額が少ないようなのですが大丈夫でしょうか？」
取引先からの連絡で事態は発覚します
導入したシステムに不備があり、請求金額が通常より安くなってしまう場合があるのです
その８ヶ月間で３２件間違った状態で請求をしており、合計するとかなりの金額になります
システムの担当者はベンダーにすぐさま連絡をいれますが、ベンダーは体制が組めないので少し待ってくださいと言われてしまいます
感情的になった担当者は、すぐに無償対応をするように要求しますが…
「瑕疵担保責任期間を過ぎています。今さら言われましても…。」
よくみると瑕疵担保責任期間は６ヶ月となっていました
ベンダーへ損害賠償請求をしましたが、同じく６ヶ月で期限切れでした
未来に発生する障害に備える
この、瑕疵担保責任の期限切れの例では、やはり担当者がしっかりと契約を把握している必要がありました
万が一損害を被っても、ベンダーが保証してくれるだろうと安心しきっていたために起こってしまった事故です
もし瑕疵担保責任が６ヶ月と知っていたならもっとシステムの本番稼働でも注意していたはずです
ただそれでも６ヶ月という期間では発見に至らない不具合というものもあります
そこでGALが推奨する瑕疵担保責任期間はずばり１年です
１年を通すことで、特定の行事は一度は通ることになるので、バグの発見もしやすいでしょう
また民法上では瑕疵修補期間は１年と決められているので、決して長過ぎるというわけではないのです
同様に、損害賠償責任期間も１年にしましょう
どんなすぐれたベンダーでも、不具合を作ってしまうことは珍しいことではありません
バグは起こるものと知っておけば、毅然とした態度をとれるはずです！
原則、契約書は自社で作る
著作権は必ず自社で持つ
瑕疵担保責任期間・損害賠償責任期間は１年とする
契約後の金銭トラブルについてはこちらの記事をお読みください！
