Skip to content

Instantly share code, notes, and snippets.

@koyhoge
Last active November 23, 2019 09:40
Show Gist options
  • Save koyhoge/20b4570adcfc2bcab5da to your computer and use it in GitHub Desktop.
Save koyhoge/20b4570adcfc2bcab5da to your computer and use it in GitHub Desktop.
エンジニアのための法律勉強会 #3『判例に学ぶ、納期遅延と瑕疵担保責任についての注意事項』参加メモ

エンジニアのための法律勉強会 #3『判例に学ぶ、納期遅延と瑕疵担保責任についての注意事項』参加メモ

  • 日時: 2015-04-123 19:15-20:50
  • 講師: 野島 梨恵氏 (東京山王法律事務所)
  • 場所: Co-Edo

http://bit.ly/co-edo-2015-04-23-doc

  • 初参加の方が半分くらい

みなさんからもいろいろ教えて下さい

  • エンジニアとは考え方が違う
    • 裁判所は何を考えているのか
    • 法律家はどういう思考回路をたどるのか
  • 法律家はシステム開発に関しては素人
    • 弁護士の99%は素人
    • 裁判官はもっと素人
    • 検察官はもっと素人
      • システム開発に詳しい検察官は見たことがないw

今回の題材

  • 東京地方裁判所平成25年11月12日
    • 平23 (ワ) 28556号
  • 裁判所、弁護士、検察が非常に苦労したということが如実にわかる判決
  • 2年がかりの裁判
  • 判決の原告被告が隠されている。
    • 平成5年の方には出ている
    • 昔は全部出ていたけど、最近はなぜか隠す風潮

どちらが勝った?

  • 525万請求して320万認められる
  • 訴訟費用をどちらが持ったかで買ったか負けたか分かる。
    • この場合は 3:2 くらいで原告の勝ち
    • どっこいどっこい

訴訟費用

  • 何万円かの印紙代
  • 裁判で必要な鑑定費用等
  • 弁護士費用は含まれない
    • US では含まれることが多い。

内容

  • システム開発が完了しても一部の代金を支払ってくれなかった
  • 発注者側は、納期が間に合わなかった、不具合があったことを理由に、その分相殺を主張。
  • あまりに仕様が確定しなくて、一度納期が延長されている。

瑕疵とバグ

  • 法的にはバグという概念はない
  • ものが完成するという前提
  • 何が許されるバグで、何が許されない瑕疵なのか。

もう一つの判例

  • 平5 (ワ) 16569号・平4 (ワ) 14387号
  • 「第三 争点に対する判断」の項が重要
  • システムが動かなかったので、どこに瑕疵があったのか分からなかった。
  • お互いの立ち会いのもとで、異例なことに一種の研究会が開催された。
    • 原告、被告が対立しているが、何が起きたのかを喧々諤々で議論する
    • 対立の中で中立の司法委員がそもそも選べない。
    • 夏休み返上で開催されたことが明記されているw
      • この時代の裁判所はほんとに仕事しなかった
      • もし控訴された場合に、高裁にアピールしたかったのではないか
      • 「審理不尽」と言われることを大変に嫌がる
  • 不具合はいわゆるバグであって、民法上の瑕疵ではなかった。
    • コンピュータプログラムにはバグはありうるものであるから、それが分かったらすみやかに直せ。
  • メールでやればよいのに、電話でやったので言った言わない問題が発生している。
    • 証人の証言が、証拠がないためにことごとく却下されている
    • なにかあったら必ずメール、FAX 等で証拠を残すこと。
  • 発注者が伝えていればそんなに大きな問題にはならなかったのでは。
    • 検証の結果実は簡単に治るバグばかりだった
    • 民法上の瑕疵担保責任を問うほどの不具合ではなかったという判断が行われた
  • 瑕疵とバグとの境界を判断するリーディングケースとなった

再び最初の判決について

  • 納期を遅らせる合意を一度したのは間違いない
  • 受注者側がもう一度納期を遅らせる合意があったと主張しているが証拠がない

仕様確定ははどちらの責任か

  • 納期が遅れたのは、度重なる仕様変更があったと受注者は主張
  • 受注者は、ヒアリング、仕様確定も全部面倒見るとホームページ等で主張していた
    • 受注者が仕様を最終確定する義務を持つと判断された

検収

  • 検収期限終了時のみなし検収は万能ではない
  • あまりにひどい状況だと、みなし検収の成立で免責されるわけではない

無理な仕様変更への対応

  • 変更要求には、納期遅延、追加費用がかかることをきちんと協議せよ
  • 協議した形跡を文書で残せ

Q&A

  • 電話で合意したものを、文書にしてメールで送るのは有効?
    • とてもおすすめ。
    • 反応がなくても、文句を言っていないという事実は大事
    • メールを送っているけど受け取っていないという主張はあまり認められない
  • 協議を申し入れたが受け入れられないという事実を残すには?
    • 協議を申し入れたという書簡を証拠として残す。
    • メールでも良い。
  • 仕様書を書かずに開発をすすめるやり方があるが、その場合の注意点は?
    • 口頭だけですすめるのならば録音が必須なのでは。
  • 録音は相手の許可はいる?
    • 許可がなくても証拠能力は変わらない。許可を取ったほうが円満なだけ
    • 録音は一部だけでは意味が無いので、最初から終わりまで全部取る
  • 「あのシステムといっしょ」という要望にはどこまで判断されるか?
    • おそらくは機能の核心部分。だがどこまでが機能の核心かは割れるだろう。
    • 非常に恐ろしいので安易に同意してはいけない

知識の非対称性

  • 法律家、医者等は国家資格を持っているプロなので、強い説明責任をもつ
  • システム開発は国家資格もなく、本来は発注者とお互い対等の立場のはず
    • しかしシステム開発会社はプロということで、手取り足取りの説明責任を求める判決が出る傾向にある
  • システム開発に請負契約というメソッドは果たして有効なのか
    • 準委任契約の方が実は向いている?

弁護士の選び方

  • その事務所に有名な弁護士がいるからといってその先生が自らやるとは限らない
  • 実際に担当する弁護士とよく話して、お願いするかどうか決めたほうが良い

和解は多い

  • 判決まで行くのは訴えられる事件の10%くらい
  • 和解の場合は絶対に控訴がないので、嫌な差し戻しがない分、裁判所は和解に持って行きたがる
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment