このエントリーをはてなブックマークに追加

https://coedo-dev.doorkeeper.jp/events/23338

コワーキングスペースの利用料も込で、¥2,000也


第一回のイベントページ

第二回のイベントページ

資料

こちらにも @koyhoge がまとめてくださっています


先に感想

  • 野島先生が面白い
    • 異業種(弁護士先生)ということと野島先生自身の話の上手さも相まって、すごく刺激になった。
    • 「(システム屋を指して)お互い、専門分野については素人なので、お互いの観点から意見を交わしたい」ということを最初におっしゃられており、すごく好印象だった。
  • 証拠が何においても重要なファクターを握っている
    • 裁判所は事実を証拠から確認するところ
    • 自分が困るようなら積極的に残すべき(法律的観点)。ただし内容によってはそれが不利になることもあり得る
  • ドキュメントを書かない開発ってどうなるんだろうという私の質問
    • 重要なことはやはりコンセンサスを取った証拠を残しておくべき(ということにしかならない)
    • やっぱり、自分をまもるためという意味だと、多少スピードが遅くなったとしても要所要所のコンセンサスとその証拠作りが必要ですね
  • 今のところのシステム関係の裁判(判例)は専門外の人たちが判断しているというところもあり、システム開発自体がどういうものかという認識の上にあるものではない、と感じた
    • つまりもめるとめんどくさいことになりがちなのでは、と思う。
    • そういうこともあるので、日頃の関係性づくりは十分に、念入りに行わないといけないなと思った次第

※専門用語等あり、聞き間違いなどあるかもしれません。その点留意のうえ、読んでいただければと思います

19:15 ~

野島先生

  • 企業法務メイン
  • システム開発専門じゃない
  • 幾つかシステム系の案件に関わってきた
  • 「裁判所が何を考えているか、法律家がどういう思考回路をたどるのか」という視点で解説
  • システム開発者の目線と討論したい
  • (システム開発に関して)弁護士は素人、裁判官はもっと素人

  • (野島先生も)最初の頃、要件定義、バグ、検収とはなにか?という感じだった

  • 発注者の弁護の場合、弁護士も素人だし発注者も素人なので余計わかんなくなったりする

判例1 H25.11/12

  • 判決の読み方

    • 事件番号から、提訴されたときがわかる(2年がかりは長い方。1年〜2年ぐらいが多い。それより長いと大きな裁判という印象)
    • 一部認容:原告の訴えのいくらかは認められた、という意味
    • 上訴等:確定← 上告がなかったということ
    • 判例に会社の名前が出ていない? 最近隠す風潮があるのはなんでだろう?
      • 調べればわかること、らしい
    • 主文と事実及び理由:元々の請求額と、認められた額。この判決でいうと、半分くらい勝ってる?
      • 訴訟費用をみると、勝ち負けの感じが見える。3:2なので、勝ったのか負けたのかうーんて感じ
      • 訴訟費用に弁護士費用は含まれない。アメリカでは含まれる。
        • 訴訟費用は、鑑定費用(例:子供のDNAを調べる)、印紙代とか
          • 余談:DNA鑑定は確信をもって大体やるので、ひっくり返るってことは経験上ない
  • 内容について

    • 甲・乙がお互いに請求権がある場合、相殺できる。ただし、支払い期限が来ていた場合。
  • 瑕疵

    • 本来の目的を遂行出来ないような不具合
    • でも、システム開発の場合、納品しても不具合が出るので、直しながら使っていく(普通の受託契約と違う。例:家を建てる、など)
    • 許容されるバグと、それに対しそこに収まらないもの(瑕疵)
    • 法律上はバグというものはない
    • 瑕疵はそもそも工事関係に当てはまる概念

判例2 H9. 2/18

  • 何が瑕疵で、何がそうでないか
  • 結構長い裁判
    • 平成8年に民事訴訟法 改正(大変だったらしい)
  • ☆梶谷玄、梶谷剛 日弁連
  • システム裁判のはしりのようなやつ(昭和とかには見られなかった)
    • システム開発に関する最高裁の判例も、まだあんまりない

p.20

  • ☆判決文の検索サービス
    • 最高裁のHPでも検索できる
  • ポイントは「争点に対する判断」を見ると良い
  • 喧嘩ばっかしていたので、お互いを交えてのシステムの研究会を行った
    • ↑のような第三者を入れて委員会を立ち上げるっていうのはあることだが、そこを選ぶのも争いがあったりする。
  • 「夏季の休みも返上して」w
    • なぜこれを裁判官が書きたかったのか?
    • 高裁へのアピール材料
    • 判決が高裁に怒られないかどうか、というのが判例を書いている思惑
    • ☆審理不尽
  • 当時の裁判所は全然働かなかった

p.22

  • バグの内容がいろいろ書かれているが、民法上の瑕疵には当たらない
  • 「運賃修正の不具合」
  • 「運行キャンセル不能の不具合」
    • 本稼働後に発見されるバグもある
    • ↑は認識しておくべき
    • ただし、これは直していかないといけない
      • すみやかに直す&代替措置を入れる
      • ↑が出来ない場合や、数がおおくてシステムの稼働が出来ないような場合は、瑕疵になる

p.25

  • 電話で↑のような不具合改修をお願いすると「言った、言わない」になる(メールでやればいいのに)
  • 証拠が無いからことごとく認められていない
    • 裁判は証拠を見る場所。ホントかどうかではない。
    • 大事なことはメール&FAXでやりとりすることをおすすめ
  • 不具合の指摘をしていない、という解釈がされている。
    • 実はバグは軽微なものばかりだった

p.31

  • まとめ

その場のみんなでお話

  • 「すぐ直せるかどうか」と「クリティカルかどうか」は関係がない
    • 1行でシステム全体止まることあるし

また戻って判例1へ

p.8

  • 納期を遅らせる合意を2回している(原告側)
    • 2回めの方は書面になくて、2回めの方は裁判所は認めていない
  • 度重なる仕様変更と、契約外の主張があった(原告側)
    • 仕様を確定させる義務がある、納期までの段取りも決める(裁判所)
    • 仕様の確定の責任はどっちにあるのか?
      • 仕様書を確定させてから
      • 見積もりを出すための費用は? 永遠の課題。
    • 仕様はお互いで確定させるもの?
      • 提案書に書いてある約束事とか
        • この判例では、手とり足取り、みたいな書き方をしていたのでは?

  • 営業上のニーズと技術上の問題の妥協点
  • これやったら遅れるor費用がかかるよ、ということを受注者はプロとして発注者に教える
  • 共同作業の協力を盛り込む、協議の内容を証拠に残す

  • 補修を続けておけば、瑕疵にはならないという逃げ道の補修期間はいつまで?

    • 「補修はしません」は逆にリスキーということ
    • 瑕疵担保責任の期間はちゃんと書いておく
  • 新しい機能かどうか

    • 最初の仕様書にのってるかどうかとか
    • 仕様書もバージョンアップしていく
  • お互いのサインを入れた議事録を残す

  • 電話で話したことをメールで送って相手が返事していないことは証拠能力的にはどうか?

    • 「メールを受け取っていない」という主張は認められていない
    • 返事していないことに、異議は認めていない、と判断される
  • n次請けのときに、エンドの納期が動かせないとき、なんか解決策はあるのか?

    • デザインにかかる期間と、開発にかかる期間を別に取り上げておくなどの解決策は?
    • 協議をしたいけど、協議が受け入れられない場合は?
      • 内容証明までしなくても、配達証明、最悪メールでも
        • 普通郵便は送った証拠にはならない
        • 受け取ったことをその場で写真にとる、とか、やったりもする
        • 内容証明を受け取ってくれない人がいる
  • 仕様書がない

    • チケット管理とかそういうのが仕様になるのでは
    • 録音
      • 相手の許可は要らないけど、同意はとっておいたほうが
      • 会議を最初から最後までとっておく。
        • 日付を最初にいっておく、最後に「会議を終わります」の宣言
    • 要求がふわっとしている
      • ふわっとしたことの確認のための書面を作る
  • 「あのシステムと一緒のやつ」

    • Yahooみたいなの、LINEみたいなの
    • 機能の核心部分がやはりポイント
      • ↑を確定させていくのが本来の共同作業
      • 受注側に、うまく運ぶ能力がすごく求められる
      • 弁護士は資格があるけど、エンジニアは資格ない。でもプロとしてそんなに責任があるのかな?医者とか弁護士並みの責任を求められている。
      • でもこういう傾向だから自衛しなきゃ
    • UI、UX、パフォーマンスとか
  • 請負と準委任

    • 弁護士とか医者は準委任。請負は「完成させます」という約束
    • バグという概念は、請負という概念とは相容れない
    • 今後準委任の比率が高まっていくのでは、発注者としては目利きをしないといけない
      • 医者と弁護士はなぜ↑のようなことが成り立っているのか?「この人はほんとに出来るのか?」
        • 資格が難しかった頃は、質がある程度担保されていた。
        • 仕事を争うようになってきていて、出来ないのにやっちゃう人が増えてきている(システムと似ている!)
        • お客さん→弁護士会→業務停止命令 ということがありえるので、注意はする
        • 弁護士会に守られているという面もあるし、弁護士会に目を付けられると大変
  • 弁護士選び

    • よく話してみて、信頼できるかどうか
    • 偉い先生とか、評判を判断材料にしない
    • 関係づくりは大事
  • 和解だと判決がでない

    • 判決がでるのは10% ほとんどが和解で終わる
    • 和解は高裁にいかない
  • 検索サービス

    • 最高裁のページで無料で見れるのは、最高裁がお気に召したもの
    • 各社いろいろある

アンケート後日