Instantly share code, notes, and snippets.

Embed
What would you like to do?
エンジニアのための法律勉強会#1『受託開発における契約時の注意事項』参加メモ

エンジニアのための法律勉強会#1『受託開発における契約時の注意事項』参加メモ

前提

  • システム開発そのものは素人だけど、裁判にはクライアント/開発側の両方で関わったことがある。
  • 裁判官はもっとシステム開発については分かってない。
    • 弁護士を通じてしか当事者と話すことがないので分からなくてもしょうがない
    • プラクティス勉強会というのを裁判官が開いているよう
  • 体系立ててまとまった書籍はない
    • 古い本しかない

民法上の請負契約

  • ソフトウェアは前提になっていない
    • 建築の契約が前提になっている
  • ある仕事を「完成」させることにより報酬
  • 請負 <-> 委任
    • 弁護士、医者は委任契約
  • 請負人の自由度が高い
    • 細かな報告が必要等、委任はそうではない
  • 「仕事の完成」とは何なのか? がソフトウェア開発の場合は明確ではない
    • この点が訴訟で問題になるところ
  • 民法641条
    • 損害賠償の範囲は、どこまでが損害なのかがいつも訴訟で問題になる。
  • 委任契約もある
    • 明らかに完成を目的にしていないもの
    • 時間単位で報酬が支払われる等

問題点

  • なにが完成なのかよく分からない
  • 作業が始まっても仕様の確定をしていてよく分からない
    • 仕様が変更されるケースも多い
    • 追加代金が発生するなのか否か
    • 裁判官には、その仕様変更の重要性が理解できない
  • 追加費用の発生が必要だと思ったら、すぐに書面でその旨を表明するように
    • 書面はメールでも良い
    • ただ相手が同意したかどうかわからないので、本当は申入書を手渡して印鑑を押してもらうのが良い
    • チャットも証拠にはなる
      • 離婚訴訟ではチャットがもっとも証拠として多いw
  • きちんと契約書を作りましょう
  • 検収してテストして検収印をもらう
    • 検収印をもらったから完成とは限らない
    • たまにくつがえることがある
      • テストがきちんと行われなかったことをクライアントが証明してしまった
    • 検収の詳細を書類に残しておくと良い
    • 特定期間に何らかの異議がなければ検収完了したものとみなすという契約があるが、それは有効
      • 「書面で異議がなければ」という文面にしておくと良い
  • バグの存在
    • バグの重要性は食い違うことが多い
    • 本番稼動で実際に使えたのか? というのが今のところの裁判の基準のよう
  • 開発工程表が終わりまでいっているかを裁判官が気にする
  • 瑕疵責任は請負のみに存在する
    • 当然ながら委任契約にはない
  • QA:「異議なしは同意したとみなされる」の見逃し、聴き逃しはケースバイケース
  • QA:コミュニケーションミスによるトラブルが案外多い
  • QA: 基本合意と個別合意は、通常は個別合意のほうが優先される
    • どちらが優先するのかを明示的に書いておくのが良い

建築との違い

  • 建築には「建築確認」というフェーズがある
    • 添付書類があるのでなんとなく分かる
  • ソフトウェアの場合は何を見ればよいのかよく分からない
    • これさえ見れば分かるものを意図して作っておいたほうが良い
    • 判断する裁判官は素人
      • 最近ようやく USB メモリを使うようになった
      • 「親と裁判官は選べない」

委任契約と準委任契約

  • 委任契約は法律に関するもののみなので、それ以外は準委任契約
  • 善良な管理者としての注意義務違反
    • 「ベストを尽くさなかった」ことを判断をするのはかなり面倒
  • 契約書の題名では分からない

実際の契約書を見てのケーススタディ

  • kintone アプリ制作業務委託契約書
  • 期日までの仕様と明確にするだろう
  • 電子メールだとアドレスまで書いておくようにする
  • 両者協議の上「書面をもって」定める
    • 証拠がないものは存在しないとみなされる
    • ボイスレコーダーでも証拠にはなるが、結局文字起こしすることになる
      • 録音に同意があるかどうかは法律的には問題ない
      • 一言断って了解を得た方がトラブルにはならないだろう
  • 「異例の事態」がなにを意味するのか不明確
    • 「〜などの異例の事態」と例示しておくのが良い
  • お金をいつどういう方法で払ってもらうのかが不明確
    • 納品なのか、検収なのか、再検収があったらどうなるのか
  • 「合理的な根拠にもとづいて計算した」
    • 計算根拠をつけて請求したほうが良いだろう
  • 電子メールは「送信した段階で通知したものとみなす」という文章を入れるケースが多い
  • 責任制限
    • 損害賠償が請負代金に制限されるかどうかは、必ずしもそうではない。
    • 書いておくに越したことはないだろう
  • 機密保持条項は契約が終了しても有効としておくケースが多い

想い

  • 契約書は夢の設計図です。
  • うまく設計して下さい
  • 検索すると沢山例があるので、たくさん見てうまいものを探って下さい

富士ソフトウェア開発事件

  • 東京地裁昭63(ワ) 第10967号
  • 判決が出るまで7年越し
    • この当時は珍しくなかった
    • 現在は3〜4年越しはあるがそれ以上はあまりない
  • 見積りに「35,000ステップ程度と見込まれる」と書いておけば結論は違ったかもしれない

時効について

  • 仕事が完成したという事実があるから瑕疵が発生する
    • 時効は1年
  • 仕事が完成しなければ債務不履行
    • 時効は3年
  • 時効は近々法改正が行われる予定

QA

  • 和解の確率は多い?
    • 多い。80%くらい
  • 顧問契約は壁が高い
    • 30分5,000円が基本的な金額なので、スポットで来てもらっても良い
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment