忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3 
 人格訴訟とは、相手方に対する人格的非難を公に実現することを目的とした訴訟のことです。良く知られているところでは、離婚訴訟にはそうした傾向が色濃く出ます。そこでは、相手方(つまり現配偶者)を「有責」に追い込むために、徹底した非難の応酬が繰り広げられます。しかも、訴訟では、「(婚姻)破綻の原因は相手方の性格にある」といった抽象的な主張では意味がありませんから、「夫は某日、某所において『○▲○▲○▲』という暴言を吐いた」であるとか、「妻は某日、某所において『■▽■▽■▽』の暴挙に及んだ」といった、具体的・迫真的な(聞くに堪えない?)人格非難に至ります。

 これとそっくり生き写しなのが、システム開発訴訟です。プロジェクトが途中で破綻してしまった場合、客観的に破綻したことは争えませんから、その責任原因が勝敗を決します。訴訟で相手方(つまりプロジェクの元同士)を「有責」に追い込むためには、「(プロジェクト)破綻の原因は相手方の能力不足にある」といった抽象的な主張では意味がありませんから、「ベンダのリーダーAは、入門書に書いてある『○▲○▲○▲』の業務知識すら有していなかった」であるとか、「ユーザの業務担当者Bは、『■▽■▽■▽』程度の確認一つに3か月もかかった挙げ句...」といった、具体的・迫真的な(聞くに堪えない?)人格非難に至ります。
 しかもシステム開発訴訟の場合、プロジェクトがトラブルに陥ると相当のストレスが長期間続きますし、危機的状況に陥ってからも何とか破綻を免れようと双方が相当の妥協を強いられます。そうした状況を経て来ているわけですから、かなりの集団的「怨念」が溜まっています。また、自らがやってきたことに対する職業的なプライドの、ネガティブな発露ということもあるのでしょう。それで「人格訴訟」となるわけですが、最も合理的に進めなければならない開発プロジェクトの後始末が、最も感情的な要素を含んでしまうというのは、何とも皮肉なものです。ある裁判官曰く、「システム開発訴訟で出てくる陳述書は、どうにも読む気がしない」。

拍手[0回]

PR
author : ITS 
 スルガ銀行と日本IBMとの間の訴訟に控訴審判決が出され、即上告となってから1年以上が経過しました。日本IBMのぼほ全面敗訴となった第一審判決では、ベンダの責任の重さがが耳目を集めましたが、控訴審判決では時期を区切ったプロジェクトマネジメント義務違反の判断手法に注目が集まりました。第一審と同様に契約責任に縛られない不法行為責任と捉えた点が特徴的ですが、結果的にベンダの責任が若干軽減されたことにも表れているように、システム開発紛争において中間的な結論を導く可能性が秘められており、その射程が気になるところです。
 
 ただ、控訴審判決そのままの理論構造は、限定的な通用範囲にとどまると思われます。控訴審判決の理屈をごく大雑把に言えば、海外パッケージの邦銀ユーザへの初適用という、(ギャップが大き過ぎて)不可能であったがそれが明らかではなかったプロジェクトが、その進行に従って不可能と判明したにもかかわらず、中止も軌道修正もないまま続行され(これがプロジェクトマネジメント義務違反)、無駄なプロジェクト費用を発生させた(これが賠償すべき損害)、というものです。このような判決は、義務違反の時期が賠償すべき損害の画定とストレートに対応する、きれいな枠組みに事案が嵌ったからこそ可能であったという見方もできます。
 例えば、不可能と判明した時点で直ちに中止され、その後に無駄なプロジェクト費用が発生しなかった場合、義務違反はなく賠償すべき損害もゼロということになるのでしょうか。結局のところプロジェクトは頓挫したのだから、それ以前にかかった費用も遡って無駄になったのではないか、というのがこの種の紛争での従来からの問題認識であったと思われます。義務違反の内容を控訴審判決のように捉える限り、それ以前の費用は初めから不可能だったことを不可能と正しく認識するためのやむを得ない費用だったと考えるほかありません(実際、フィット&ギャップ分析の本質はこのようなものです)。いずれにしても、控訴審の考え方から先の問題認識に直ちに答が出てくるものではありません。
 もちろん、別の注意義務(違反)を想定することはできます。実際、よほど背伸びしたプロジェクトでない限り、プロジェクトが途中で頓挫するのは、それが初めから不可能であったからではなく、可能ではあったがユーザかベンダ(あるいは双方)に何らかのやり損いがあるからです。この場合、もしそのやり損いが注意義務違反と評価されるのなら、その前後を問わずプロジェクトに費やされた費用は、賠償されるべき無駄になった費用というほかないのではないか。これは先ほどの議論より一般的で、しかもより強力です。そしてやはり、控訴審の考え方からは答は出てきません。
 もともと、「プロジェクト・マネジメント義務」という抽象的なラベルには殆ど意味はありません。重要なのは、事案の具体的状況に照らした注意義務の具体的内容であり、具体的な損害の範囲です。その意味では、控訴審判決は、注意義務違反の具体的行為と、それと相当因果関係に立つ損害を拾うという、ある意味当たり前の、しかしその限度では通用範囲の広い判決ということになるのでしょう。

拍手[0回]

author : ITS 
 それまで順調に動いていたシステムが、突然ダウンしました。よくよく調べてみると、データベースの定義に余計なユニーク指定のあるのが原因でした。この手の話は良く聞きますが、何かのヒントを含んでいるように思えます。

 ベテラン技術者の曰く、データベース設計をした担当者は、ユニーク指定の意味が、指定のデータでレコードを一意に特定「できる」ことにあるのではなく、一切の重複データの存在を「許さない」ものであることを、理解していなかった。例えば、請求テーブルがあったとして、取引先と請求日を合わせれば、通常はまずユニークになるものです。しかし、そのようなものにユニーク指定すれば、何かの例外データ(例えば、移行データ)を遭って、たちまちアベンドしてしまいます。何よりも、わざわざユニーク指定する「意味」がありません。同じデータ項目の重複を許さない、そのことを、システムを強制終了させてでも貫徹させなければならない場合こそが、ユニーク属性の出番なわけです。
 話を法律に移して、業務提携の契約書を作る場面を考えます。この場合、取扱商品や営業地域が(放っておいても)現にこうなっている、ということは書く必要がありません。プレゼン資料などに、書きたければ書いても構いませんが、それだけの話です。契約書に書くべきは、取扱商品や営業地域の切り分けをして、(破りたくても)その切り分けは守らなければならない、という場合です。自社の主力である「○○端子」を提携先が扱ってもらっては困る、そのことを、裁判に訴えてでも貫徹させなければならない場合こそが、契約書の出番なわけです。こちらの方は、そうでなくても、契約書が無駄に長くなる以上の不都合はないかも知れませんが。
 言葉を換えれば、「世界がどうなっているか(As-Is)を記述する」ことは、ユニーク指定がそうであるのと同様に、契約書の役割ではありません。「世界がどうあるべきか(To-Be)を宣言する」ことが、ユニーク指定がそうであるのと同様に、契約書の役割です。

拍手[0回]

author : ITS 
 契約書のリーガルチェックの目的は、契約にまつわる法的リスクへの対応です。リスクとは、「有利になるかも知れないが、不利にもなり得る」という不確定性を言いますから、単純な有利/不利とは話が違います。よく、リーガルチェックの際に、「出来るだけウチに有利に」と言う人がいますが、本当にそれだけのことならリーガルチェックなど要らなくなりそうです。有利にするには、(売り手であれば)代金をうんと上げれば良いだけのことで、難しい理屈は何も要らないわけですから。

 もっとも、リスクの所在が有利/不利に影響を与える場合は、いくらでもあります。例えば、損害賠償の制限条項は、損害賠償を請求したり請求されたりという法的リスクに直結しますが、損害を発生させる事象が起きた場合の損害負担という経済的リスクを当事者間にいかに配分するかという問題ですから、リスクを押し付けた方が有利で、押し付けられた方が不利であるのは間違いありません。その意味では、上のような言い分にも、一理あると言えないこともありません。
 ただし、代金などの有利/不利と違うところは、将来どのような損害が生じるのか、しないのかは不定であって、しかも多くの場合、当事者はこれに影響を与えることができるところです。システム開発の失敗による損害であれば、これを回避するためにマネジメント活動を行うことができます。その意味で、より良くこれをコントロールできる者(例えば、ベンダ)にリスク負担させる方が良い、という理屈があり得ます。つまり、適切なリスク配分は、当事者双方が直面するかも知れない「負のパイ」を小さくするのです。そうすると、すべての負のパイを相手方に押し付けられるほど強い交渉力を持っていない当事者は、自らコントロールしやすいリスクを引き受けることと、相手方に自らがコントロールし易いリスクを引き受けてもらうことを引き換えにする、という取引が勘定に合うことでしょう。
 リーガルチェックの役割の一つは、そのような取引の可能性を提示することにあるわけです。

拍手[1回]

author : ITS 
 協議条項という、恐らくは日本独特の契約条項があります。「本契約について疑義を生じた場合、信義誠実の原則に従い甲乙協議し、円満に解決を図るものとする。」というようなものです。日本人論で著名な山本七平氏は「日本資本主義の精神」の中で、協議条項は要らないと述べています。協議条項があってもなくても、日本人同士の契約は、結局は話し合いで決まるから、というのがその理由です。

 多くの法律家も、協議条項は不要であると考えます。ただし、その理由は山本氏とは違って、契約書は裁判所での判断の規範となるものであるが、協議条項はその役に立たないから、というものです。もっとも、契約書は何か事が起きたときに裁判所で機能するだけのもの、というわけではなく、事が起きないように当事者の行動を律する、言わば「導きの星」としての機能もあります。
 ただし、それは裁判所に行けば結局そのような判断を受けるのだから、という裁判規範としての担保があればこそ、というのが法律家の言い分です。協議条項で言えば、もし協議を尽くさないままに裁判に訴えても、裁判所は訴えそのものを認めない(いわゆる「門前払い」)、という効力が前提だということです。確かに、協議条項にそこまでの効力はないでしょう。
 しかし、例えば、システム開発契約のプロジェクト計画書に書かれた規範、「次工程に入る前に、前工程の完了判断を経ること」のようなものはどうでしょうか。これが裁判規範になるかと言われれば、プロジェクト計画書が契約内容に取り込まれているかどうかによる、というのが一応の答です。しかし、プロジェクトメンバーは、裁判所での最終審判を怖れてプロジェクト計画書に従うわけではありません。裁判所が何と言おうと言うまいと、プロジェクトを成功させるために、これに従うわけです。その意味では、厳とした規範性があるわけです。
 協議条項にも、もしかすると、そのような意図があるのかも知れませんが、山本氏は、そうしたことまで十分承知のうえで、あえて「書かずもがな」だと喝破したものでしょう。

拍手[0回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin