書籍② ＩＴ判例で学ぶマネジメントと紛争対応
この電子書籍「ＩＴ判例で学ぶマネジメントと紛争対応」は、重要な論点を含むＩＴ判例について、事案全体の流れの中で判旨をかなり詳細に引用したうえ、論点単位である程度完結した説明を試みたものです。判例を素材としてＩＴ法を理解し、マネジメントや紛争対応に役立てたい方に向いています。平成２９年債権法改正に対応済みです。
|
|
訴訟には、「平成２６年（ワ）第１２３４号」という形式の事件番号が付けられる。このうち「平成２６年」の部分は、訴訟が受け付けられた暦年を表している。他方で、判決が出ると、「東京地判平成２８年１２月２５日」などと呼びならわす。日付の部分は、言うまでもなく判決の言渡し日である。つまり、これらが分かれば、いちいち事件記録に当たらなくても、その訴訟の大体の係属期間を計算することができるわけである。
試みに、本書で採り上げた裁判例について、提訴から第一審の判決までの訴訟期間をこの方法で計算してみると、（年の半ばに提訴したと仮定して）平均で３年強となる。「裁判の迅速化に関する法律」で２年以内の終局が目標とされていることから考えても、かなり長い部類に入る。世の中の大半のシステム開発プロジェクトよりも、更に長くかかっていることになる。
筆者が最初に関与したＩＴ訴訟も、３年以上かかった。しかも、その事案は、提訴に至るまでに調査や交渉等に相当な期間を費やしていたから、判決で全てが終わったのは、開発プロジェクトが始まってから実に１０年後であった。訴訟は控訴されずに一審だけで終わったのだが、これは両当事者ともその時点で既に「疲弊」していたからかもしれない。そして、この紛争解決のため、ユーザ側では（頓挫した開発プロジェクトで予定していた）新システムの実現が１０年間凍結されたままとなってしまった。
ＩＴ訴訟は（これを生業とする筆者にとっては残念なことであるが）、開発頓挫にせよ、情報流出にせよ、既に発生してしまった損害を当事者間でいかに分担するかというだけの問題で、いかにも「後ろ向き」である。もちろん、起きてしまった紛争に透明性のある決着を付けるには訴訟によるのが正攻法であるし、長く苦しい訴訟追行を通して危機管理の視点が身に着くといった余得がないこともない。しかし、少なくとも、新しいものを生み出す「前向き」のビジネスとは、大きく違っていると言わざるを得ない。
そこで重要になってくるのが、いかに紛争を予防するかという視点である。本書の表題を「マネジメントと紛争対応」としたのは、そうした問題意識からである。残念ながらＩＴの世界に「銀の弾」はなく、内容的には至らないところも多くあるが、多少なりとも読者の参考になれば幸いである。
実質的な保証の役割を期待するのであれば別であるが、この事案のように、ただ形式を整えるだけの目的で当事者を増やすのは、多くの場合賢明でない。関与する当事者が増えるだけでも契約関係が複雑になるし、かえって権利義務の連鎖が弱くなる意味もある。筆者の経験では、独立した元従業員に業務委託する際、わざわざ「信用力のある」企業を介在させたところ、その企業の方が倒産してしまい、支払った報酬もろとも消えてしまったことがある。（解説）
残念なことに、ＩＴの現場では裁判所が考えるほど、記録や資料を残す習慣があるわけではない。現に動くシステムを作成することが至上の価値であり、第三者に理解させるためのドキュメントには気が乗らない、という意識もあろう。また、障害等の緊急時であれば、混乱した現場でなすべきことは第一に作業であり、悠長に記録を取っている余裕はない、という現実（あるいは言い訳）もあろう。（解説）
この事案では、請負契約書は作成されずに、納期間近に注文書のみが交付されている。その注文書は、代表者ではなく担当取締役の名義であり、制作物として２１本のコンテンツの記載があった。《ベンダ》からすれば、不利なところもある書類だったわけであるが、交付された時期や状況から、請負契約の成立のみならず、コンテンツが制作不足であるにもかかわらずシステム完成が認められる決定打となったのである。（解説）
「判例ではこのようになっている」などと言われると、どうにも逃れられない法的な縛りがあるようにイメージされがちだが、そうではない。場合によっては、「このような判断がなされた実例が少なくとも一つある」というだけのことかもしれず、その先踏襲されるかどうかは、もっぱら（法的あるいはＩＴ的な）判断の妥当性にかかっているのである。（解説）
その意味では、ほとんどの開発は、「旧システムを踏襲」するものと言える。問題は、その踏襲の程度であり、具体的に何を踏襲し何を踏襲しないか、踏襲しないとすればどうするかである。そうである以上、その肝心の部分をぼやかしたまま「旧システムを踏襲」といった包括的な合意をすることは、最も避けなければならないことである。（解説）
上記事案の《ベンダ》は、独自の生産性テーブルを持っていたようであるが、独自の生産性テーブルは一般的な統計資料等によってそれ自体の信用性を争われることがあろう。逆に、独自の生産性テーブルを持っていない中小のベンダであれば一般的な統計資料等を用いるしかない。この場合は、操作されていないという意味の信用性はあるとしても、問題となっている事案への適合性の点では劣ることになる。（解説）
《ベンダ》は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、《ベンダ》は、注文者である《ユーザ》のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない《ユーザ》によって開発作業を阻害する行為がされることのないよう《ユーザ》に働きかける義務（以下、これらの義務を「プロジェクトマネージメント義務」という。）を負っていたというべきである。（判例）
ベンダとしては、契約の範囲を超えていても、自らの利益を多少削るくらいであればプロジェクトの円滑な進行を重視して、あえて追加費用の請求を試みない場合が少なくない。厳密に言えば追加変更であっても、いちいち追加費用を求めることは、いかにも「カネ」ばかりを求めているようで、ユーザから強い反発を受けるからである。しかし、追加費用を求めないでいると、ユーザの追加変更要求にブレーキがかからず、「暴発」への途を辿ってしまう。それを義務違反と言われたのでは、ベンダとしては踏んだり蹴ったりの感もあるが、少なくとも突然の「暴発」を回避することはベンダの責任と言うほかない。（解説）
ベンダとユーザーの間で、システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては、システム開発技術等とシステム開発対象の業務内容等について、情報の非対称性、能力の非対称性が双方に在するものといえ、ベンダにシステム開発技術等に関する説明責任が存するとともに、ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ、システム開発について自らリスク分析をすることが求められるものというべきである。（判例）
本事案で問題になったのは非機能要件の一種であるが、機能要件に注意が集中するあまり、一般に非機能要件は合意漏れを起こしやすい。排他制御などは、それとして取り上げることは、稀であろう。特に中小規模の開発では完全は期しがたいところであるが、性能、運用時間、バックアップ、操作性、セキュリティ、といった重要事項には目配りしておくべきである。（解説）
ベンダとしては、請負となるアプリケーション部分さえ完成させてしまえば、準委任であるデータ移行が完了しなかったためにシステムが稼働しなくても、法的責任を免れることができる。契約全体から見ればごく一部の作業の契約類型が変わるだけで、結果的な責任状況に大きな違いが出るのである。（解説）
市販ソフトウェアの画面については、本事案と同様に「類似性」の一本勝負となりやすい。スクラッチ開発の固有ソフトウェア等と異なり、むしろ「依拠」（少なくとも参考にしているという意味で）しているのが通常であろうから、後発製品の開発では先行製品の創作的特徴がどこにあるのかを十分に検討したうえで、これを注意深く避けることが必要である。（解説）
判旨では、契約した「当時の技術水準に沿ったセキュリティ対策」が必要とされ、ハッキング等のリスク状況の高まりに応じて必要レベルが変わっていくことが示されている。セキュリティ対策としては当然のことながら、法的な評価としても、構築当時には「適格」であったものが、数年間のうちに「不適格」となり得るわけである。（解説）