本日，SOFTICのセミナー『判例から学ぶ DX時代のシステム開発トラブルを防ぐ知恵 』に出席した。
「DX時代の」という枕詞がつくものの，基本的には，それ固有の話はそれほどない。
５つの判例を取り上げて詳細に紹介し，それぞれ実務への教訓を導き出すスタイルだった。たまたま１つを除いて別館ブログで取り上げたもの（以下のリンク参照。残りの１つも目を通したことはあった。）だったが，やはり多くの人の目から見て検討を加えただけに，自分には気づかない指摘もあって勉強になった。
最初の判例は，契約締結を前提に作業を進めていたものの中止になったため，ベンダが契約の成立と予備的に契約締結上の過失を主張して報酬請求していた事案。
次の判例は，同じく契約締結上の過失が問題となった事例だが，途中まで進んだうえで基本設計後半の工程の契約成否が問題となった。ユーザの契約締結上の過失が認められた事案。
3つ目も契約の成否が問題となった事例（東京地裁平成30年1月31日判決。ブログ記事なし。）だが，元請けと下請けの争いの事案であり，しかも両者の経営統合が検討されていたという特殊な事情もあった。
4つ目は少々古いが，不具合か仕様か，という典型的な争点があった事例で，システム開発の裁判例が少ないころはよく参照されていた。
最後は，「コンサルティング契約」が請負と準委任と複合的な性質を有することや，上流工程を担当したベンダの責任が認められるなど，なかなか衝撃的な判断が含まれる事案。
自分自身が裁判例を見ながら，実際の紛争を取り扱っていつも思うのは，裁判所の判断を抽象化して，少ない事例から中途半端な規範を導くのが大変危険だということ。「▲▲裁判例によれば，〇〇をしておけば債務不履行にならない。」などの教訓などがそれである（もちろん，本日の報告者もそんな安易な規範，教訓を導いているわけではなく，慎重かつ丁寧に分析しているので，報告者への批判の趣旨ではない。）。
判決まで至る事例は，こじれにこじれた事案の中でも，さらにその中でもこじれて訴訟になり，さらに裁判所や調停委員らの尽力もむなしく和解に至らなかったケースなので，判決文だけからは読み取れないような複雑な特殊オブ特殊な事情があるに違いない。なので，判決文に表れない裁判所の「価値判断」が先行して後から理屈付けがなされている可能性もあり，なかなか一般化しにくいのである。
だからといって法律家である以上，公になった裁判例を分析することが，目の前の紛争において裁判所の判断を予測するための最適な方法の一つであるので，こうして悪戦苦闘をし続けなければならない。裁判所の判断を批判したり整理・分析した結果をアウトプットすることで，裁判所の判断のヒントを与え，予測可能性を高めることにもつながる。
