IT関係の訴訟は長期化する
ITがらみの訴訟が増えています。かく言う私も以前、IT会社で顧客企業と係争問題を抱えていました。私の場合、訴えたほうではありますが、それでもやはり２年以上の長期にわたり相当な時間と労力を割く必要に迫られ、苦労したのを覚えています。
一度は互いに信頼関係を結び、協力してシステムを構築していこう、と誓った相手とそのような関係になるのは気持ちの良いものではありません。有名なITがらみの訴訟はIBMとスルガ銀行の一件ですが、確か数年にわたり争っていた記憶があります。
どちらが悪いのか、（100%どちらかが悪いと言うことはないのだと思いますが）外部からは判りにくいのがIT訴訟の特徴で、民事なので、裁判所も強制的に何かをするようなこともなく、IT訴訟は概して長期化します。
結局は契約関係がどうなっていて、その期間に実際に起こった事実がどうであったのか、取り交わした提案書、契約書類などの文書類やメール、議事録などの根拠となる証拠を洗いざらい提出させられます。
これらの証拠を客観的に見て、事実関係がどうであったかを判例などに照らし合わせて裁判官が判断していくわけですが、とにかく互いに提出する証拠となる書類が多くなるのがIT訴訟の特徴かと思います。また、他にも長期化するには理由があります。
- 裁判官がITを含めた技術的な内容になじみが無い場合が多い
- どちらか一方でも弁護士がIT訴訟に不慣れだと、そこの理解に時間がかかり、通常では考えられないような主張を平気でしてくる
- その時、実際はどうであったのか事実関係が判りにくい（当事者でもITに関する前提知識の無い顧客企業は認識が違う場合がある）
どうしてもIT会社と訴訟になってしまうことがある
訴訟のきっかけ、タイミングはほぼ決まっています。ウォーターフォール開発モデルの開発工程の前後にそのポイントはあります。ウォーターフォール開発モデル自体が海外では既に使われていない古いスタイルなのですが、その辺りは下記を参考にして頂くとして、
ウォーターフォール開発では、IT会社は受注時は安く見せて受注を獲得する為に、特に追加開発の規模を少なめに見積もります。（業務要件が解らないのですから当然追加開発などが少なくなる方向になります）
企業の意思決定者は、その金額なら、と意思決定しますが、実際に業務要件を聞いていくと開発規模が膨らむので再見積もりをして、実際の要望に沿った開発工数に基づく見積りを出すと、当初の2倍、3倍の金額となってしまうのです。
IT会社の人間はそれが判っているので、提案時点から「要件確定後に再見積もりを実施します」と小さな文字で書いておきます。ですから、金額が膨れ上がるのが当然なのです。
現場の実務担当者にヒアリングすると、担当者は見積金額やその前提など知っているはずもなく、仕事が楽になったほうが良いので、必要そうな機能は全て要望します。管理者は実業務を知らないケースが多いため、現場が必要だと主張すると否定できません。
また、要件確定後の再見積もり、開発部分の契約を何とか乗り切るとシステム会社内での実際のコーディングに入りますので、多少の開発遅れなど有ったとしても、そこで訴訟問題が出ることは殆どないと思います。
その後、実際の開発が終わるころになるとテスト工程が始まりますが、開発したプログラムを現場ユーザーに見せると、イメージが違う、やっぱりここの動きはこうだ、追加でこれも無いと業務出来ない、と始まります。
ここでも管理者は現場を押さえられないので、追加開発を次々に盛り込んでいきます。ウォーターフォール開発モデルでは、一旦確定した要件を後から変更すると、全て追加費用扱いですので、その追加費用の見積もりを持っていくと、そんなはずではない、とここで訴訟になります。
そもそもこのようなシステム開発の進め方に問題があるのだと思いますが、その辺りは下記を見て頂くとして、そのようなもしもの事態にどう備えたら良いかが重要です。
多少面倒でも、IT会社との契約がどのような内容になっているのか十分理解した上で、下記のような点を常に念頭に置いておく必要があります。
- 現在の契約類型を意識し、IT会社に求める点は求めていく
- 議事録、メールなどの文言には常に注意する
当然ですが、議事録やメールのやり取りは、後々必要となる可能性がありますので、抜けが無いように、立ち話ししたような内容でもその後確認のメールを送っておく等の一手間が後々自分を守ることになります。
また、そこで使う用語も基本的には自社の立場で、高いお金を出して請負開発を委託しているのに、準委任契約と主張されるような用語を使用してはいけません。
- 契約前から作業はさせない
これもよくある事ですが、「カットオーバーから逆算すると直ぐにでも開始しないと間に合わない、事前着手や内示書をもらえれば作業に着手します。」と言うころし文句です。これらの言葉はIT会社の営業の上等手段ですから決して乗ってはいけません。
法律事務所には得意分野がある
ご存知の方も多いのではないかと思いますが、法律事務所には得意不得意があります。殆どの２，３人の弁護士がいるような事務所は離婚訴訟や、相続、金銭トラブルなどしか扱ったことがなく、特許やIT訴訟などの技術分野の訴訟は全く素人だと思ったほうが良いです。
私が訴訟を抱えていた時は、たまたま知り合いの弁護士が、「下町ロケット」と言うドラマにもなった小説のモデルとなった法律事務所で働いていた関係でそちらに相談しました。
そのような技術訴訟を専門とした法律事務所には、元々エンジニアで、その後法科大学院に行って弁護士になったような方が多く在籍し、話もスムーズでした。
一方、相手方は会社の委託している顧問弁護士が出てきて、ITのことが全く分からず、その弁護士にこちらがいろいろと一般的なITの進め方を教育しているような感じで、それもあり、なかなか進まなかったのです。
とにかく、望ましいことではありませんが、そのような事態になったら、IT訴訟の知見がある弁護士（事務所）に相談することをお勧めします。相談だけであれば、然程高額を請求される事もないかと思います。
その時主張すべきこと、日頃から注意すべきこと
- 善管注意義務違反
こちらは知っておいて損はない用語だと思います。
「受託者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う」とあります。（民法第644条）
この点は訴訟になると必ず問われる点です。仮に契約上100%IT会社が正しくても、この点を持ち出されると、善管注意義務違反が有ったのではないかとIT会社は見られ、減額されるケースが多いようです。
- プロジェクトマネージメント義務違反
この言葉も覚えておいて損は無いと思います。これは、法律の条文に規定されている義務ではなく、判例上用いられるようになった用語です。
ベンダ企業は、ユーザ企業のシステム開発への関わりについても、適切に管理し、システム開発について専門的知識を有しないユーザ企業によって開発作業を阻害する行為がされることのないようユーザ企業に働きかける義務（以下、これらの義務を「プロジェクトマネージメント義務」という。）を負っていた。
との東京地裁が平成１６年３月１０日に出した判決にある、ことば「プロジェクトマネージメント義務」が頻繁に使われるようになったものです。今だ法律的な位置付けが確定していませんが、ユーザー企業としてはこの点を主張していくのが定石となっているようです。
簡単に言うと、システム会社はITのプロなのだから素人であるユーザー企業をプロジェクト管理として導く責任があるだろう、と言っているのです。具体的には下記の内容が含まれます。
- 進捗管理・阻害要因排除義務
- 発注者管理義務
- ユーザー企業の協力義務
一方、ユーザー企業にもよく指摘される点があります。それがこちらで、
委託者(ユーザ企業)が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担する。
と東京地裁の判例で示されたもので、こちらも法律の条文に規定されている義務ではありませんが、よく用いられるようになってきているようですので、ユーザ企業としては、指摘されないように注意が必要ではあります。
