題記の特集が気になったので読んでみた。
導入に「システム開発を巡る大型訴訟が続出している」「例外なく訴訟リスクが迫り来る」「訴訟リスク回避への処方箋を探る」という言葉が躍っている。
しかし，分析は深くない。類型が7種類挙げられているが，その分類の方法には疑問があるし，代表例として挙げた裁判例も古い。ちなみに，取り上げられているのは，東京地判平14.4.22*1，名古屋地判平18.6.23*2，名古屋地判平16.1.28*3である。
分厚い契約書を作ったとしても訴訟は避けられない，としているが，紛争現場にいる者からすると当たり前のこと。確かに，契約書は紛争予防ツールとしての一面も有するが，契約書を充実させれば紛争を回避できることにはならない。契約に関するまとめとしても，「訴訟リスクを避けるためには，契約書だけではダメ。『あうんの信頼関係』だけでもダメだ。変わりゆく状況にユーザー企業，ベンダーの双方が対応していくための仕組みを含めて契約を考える必要がある。」というところで分析が止まっている。大手のベンダ，ユーザには契約に対する知見がだいぶ溜まってきており，この程度の分析では読者は満足しないだろう。
また，法律面の注意点として，「民法改正の影響に注意」として，債権法改正に言及しておきながら，すぐ次に「瑕疵と未完成の違いを理解する」という注意点を挙げる。債権法改正によって，瑕疵担保責任が契約不適合の概念にむしろ一本化されていくことを考えると，そこをあまり強調しなくてもよいように思う。また，「完成」の判断基準を「検収書面にサインした段階でシステムは『完成』となる」と言い切ってしまっているのも（紙幅の都合はあるとしても）不正確。多くの事案では完成の判断基準そのものが争われている。
別の注意点として，倒産時のライセンス対抗手段がないことが挙げられているが，システム開発の問題としては相対的に重要性は低い。特許権の通常実施権の当然対抗と，著作権ライセンスとの違いが書かれているが，そもそもシステムの場合は著作権譲渡（ライセンスではない）のケースが多く，対抗制度に触れるのであれば，プログラム著作物の登録制度にも触れてほしかった。
細かい揚げ足を取れば，「訴訟主」という意味の分からない概念が登場するのは困ったもの（文脈からは「原告」がそれに近いといえるが）。システム開発訴訟ではどちらか一方が100%悪い，ということになりにくいために反訴が提起されるも多いので，「ベンダが原告になるケース」などと分類してもあまり意味がないように思う。
「さらば訴訟リスク」というタイトルを掲げ，スルガIBM事件のような事例を挙げて「訴訟リスクが迫っている」という問題提起をするのならば，もう少し深い分析や情報提供をしてほしかったところである。
*1:別館ブログでは，http://d.hatena.ne.jp/redips+law/20100110/1327130501 で取り上げた。
*2:別館ブログでは取り上げていない。
*3:本文中では判決日は記載されていないが，内容からこの判決と見られる。別館ブログでは，http://d.hatena.ne.jp/redips+law/20100108/1327130292 で取り上げた。
