yasulab/report.md Secret

## report.md

      
    Raw
  

              report.md
            
          
    プロマネトエンジニアのための法律勉強会「本当にあった怖い話」
次のイベントに参加してきたので、そのレポートを書いています。
イベント情報

プロマネとエンジニアのための法律勉強会～弁護士が教える本当にあった怖い話～
ITコンサル時代、とある案件で裁判に発展したことをきっかけに弁護士に転身した講師が、システム開発・運用保守をめぐって起きたトラブルの実例を紹介するとともに、紛争回避、解決へのポイントを解説します。

注文書や契約書を取り交わさないままズルズルと進めたケース
要件が確定しなかったことによって遅延したケース
品質や納期に問題があった場合に、書面で非を認めてしまったケース
�- 契約書の規定に損害賠償額の上限がありながらも機能しなかったケース

URL: https://atnd.org/events/67263
講師


伊藤雅浩 弁護士 @redipsjp (blog: Footprints)
弁護士法人内田・鮫島法律事務所

96年名古屋大学大学院工学研究科修了。
アンダーセンコンサルティング（現アクセンチュア）等にて、ERPパッケージソフト、基幹系情報システムの導入企画・設計等の開発業務やITコンサルティング業務に従事。
とある案件が裁判に発展したことをきっかけに弁護士を志し、創設一期生として一橋大学法科大学院へ。07年一橋大学法科大学院卒業。08年弁護士登録。
以来、情報システムやインターネットビジネスに関わる法律問題やベンチャー法務等を扱う。著書 『システム開発紛争ハンドブック―発注から運用までの実務対応』 ほか。
背景


日本では判例ベースで話が進んでいる
実際の判決が与える影響が強い
「本当にあった怖い話」の事例を勉強しよう

今回はベンダー系の事例を中心に紹介


事案1: 要件定義における問題

契約が締結されることを信じて行った作業が無駄になったケース
(東京地裁平成17年3月28日判決)

契約書をする前に作業を進めたんだけど、やっぱしダメだった
金額の交渉をしている間もエンジニアを遊ばせたくない
だから並行して進めることが多い
口頭での「お願いします」は法的効力があるのか?

口約束でも契約は成立するが、企業間の契約もその限りではない
ドラフトで優先交渉権があるようなもの。やはりサインは大事
契約の締結までに行う作業も有償である と伝える義務があった


契約が成立していない場合は泣き寝入り?


契約が不誠実な交渉により破棄された場合は、その限りではない。例:

システムの開発を外注し、外注先との契約を先延ばしした
その間も開発作業をするよう催促した
その後、契約を破棄し、成果物を社内エンジニアに引き継がせた


契約不成立になったときにどう処理をするか という書面をもらう

契約は成立してないけれど、契約成立上の過失で請求できる
逆の立場 (発注する側) でも同じ
「仕事にならないかもしれないけど大丈夫?」という同意を得るべき


事例2: 追加要望における遅延の責任について

ユーザーからの追加要望があったものの遅延の責任はベンダにあるとされたケース
(東京地裁平成26年4月7日判決)


納期の延期を繰り返された


原因はどっち? 要件定義を覆したユーザ or 調整に失敗したベンダー?

遅れた責任はどっちにあるのか?


裁判所の判断: 合意があったかどうか?

ほとんどのベンダーは謝罪をすぐする傾向がある
悪いことではないが、法律的には確実に不利になる
責任があるとみなされ、紛争時には負ける可能性が高い


「私たちは悪くない」と証明する責任はベンダー側にある


ユーザーに過失がなければ減額することはできない
  仕様書での明確な確認がなされておらず、
  ユーザの上記要求が仕様変更であるのか、
  ユーザーの当初からの要求が実現されているのかが判然としない


事案3: 要件定義がブレブレで確定しなかったケース

3年近く経過してもなおシステム設計書が確定せず、やり直しが繰り返されたケース
(東京地裁平成22年7月22日判決)

ユーザーの担当者がコロコロと変わり、要件定義が決まらない
ベンダーは金額を返金し、成果物も渡して撤退した
ユーザーはベンダーを訴えた
裁判結果: ベンダーの勝ち

要件定義はユーザーが主体的にやらなくてはいけない
明らかに当初の内容より大幅に仕様が増えた
「元の金額でやれ」と言ったユーザも悪いが... 840万で全部やります! という売り文句を使ったベンダー側にも責任はあった
3年かかった開発は契約が不成立・返金で、弁護士費用もかかった

ベンダー側にとっても良い結果ではなかった


こうなる前に何か対策は取れなかったのか?


事案4: PMが実施されなかったケース

銀行の勘定系システムの導入が途中で頓挫したケース
(東京地裁平成25年9月26日判決)

IBMからスルガ銀行に打診があり、スルガ銀行もIBMに発注した
全体金額について定めた書面「最終合意書」を締結

段階的に発注するのは不安だったから、ユーザは上限を決めたかった
3億円を上限とする合意書をユーザは求め、ベンダーは受け入れた
提案書には3億円(概算)と書くが、実際には増える傾向があるので、ユーザから見たら不安だった
提案書の概算はあくまで目安であって、法的拘束力はない (3億円じゃなくてもよい)
全体金額に合意して欲しいユーザー vs. 未来を予測するのは難しいと思うベンダー
結論: 2年後に契約は破棄された


裁判所における判断:

ベンダーがダメになった時点を特定し、その時点より後の金額を返還しろという論理で裁判所は動いた
1審: 最初からダメだった

プロジェクトの立案・リスク分析はベンダーの責任
提案がそもそも間違っていた => 最初から間違っていた
リスクに対する十分な説明がなされていなかった
PMがしっかりとマネージしなかったのが悪い
提案段階も裁判では参照される


裁判所の考えと対策


PMの義務とは? 裁判所の考え:

契約文言から一義的に定まるものではない
色々な局面に応じた適切な分析、変更、説明の義務がPMにある
IBMなら十分に認識できたでしょ?
「完成しなさそうだから今やめたほうがお得ですよ」と伝える義務がベンダーにあった という判断


ユーザーの義務とは? 裁判所の考え:

受託者のみでは完成しない (協力義務)
ただし、協力義務に違反した事例はほぼない
ほとんどの場合、PM義務に違反したとなる


なぜベンダーは不利なのか? 証明の問題:

PM義務を尽くしたことを立証するのは難しい
「ちゃんとやってました」とは?
役割分担 (立証命題) の明確化
将来の紛争に備えた記録の作成・保存が求められる


どうやって証明をするのか? 議事録で証明:

要件定義(BRD)
異議に答えなかった
揚げ足をとる発言が議事録に残ると不利
議事録の意義: ただ作るだけではダメ。プロセスも大事
IBMはステアリング・コミッティ (意思決定のプロセスの記録) を作っており、これは良かった
プロジェクトの状況を示す証拠は議事録が最も強い

例: oo週間遅れている、回答がなかった、うまくいっていない


ただし、漫然とした議事録には意味がない

cf. 経済産業省が作っているモデル契約書:
連絡協議会ではooを決められる とある
契約書に「連絡協議会」とあれば、議事録のタイトルも「連絡協議会」とするべき
第3者(裁判官)が読んでも理解できるかどうかを常に意識する


もしユーザー側との調整がうまくいかなかったら、うまくいかなかった証拠 (議事録) を残しておこう!


事案5: 議事録がうまくいった例

ユーザからの求めに応じて提出した顛末書を根拠に責任を認めたケース
(東京地裁平成25年5月31日判決)

議事録から証明されたこと:

単体テストがほとんどうまくいかなかった
全社をあげて取り組むべきだった
しかし、純分に取り組まれなかった
=> したがって、非を認めるべきである
(不利な事実を認める証拠は、裁判では認められやすい)
ベンダー側が非を認めるときは慎重に!

逆に、書面での合意を相手から求められたときは「弁護士を通さないと合意できない」といってまずは弾くことも大事


事例6: 追加請求が認められない事例

追加業務が発生したとして増額を求めたが、追加報酬請求が否定されたケース
(東京地裁平成23年6月3日判決)

追加請求は認められづらい。必要な３つの要素:

もともとの受託範囲が明確であること
もともとの金額算定の根拠が明確であること
ユーザー側にも追加・変更の認識があること

有償作業であるという認識が必要
議事録に残しておくと確実


工数・機能増加分の請求可否:

Functionポイント、ステップ工数があっても難しい
「1機能いくら?」「1ステップいくら?」という合意が必要
PMが上記のことを把握している必要がある
最悪のケース: 契約書に書いてあるが実践していない


事例7: 必要なセキュリティ対策がなされなかった

重過失により、責任上限条項が撤廃されたケース
(東京地裁平成26年1月23日判決)

免責条項22項: ... 故意または重過失が認められる場合を除き、責任を負わない
重過失とは?

法律上の定義はないが、事例から帰納的に境界線は見える

著しい注意義務違反(重過失):

それをやったらマズイよね、っていうのがすぐ気付くレベル
それに気づいていたらすぐ回避できたよね、っていうレベル
ただし「バグがある == 重過失」ではない


事例: ジェイコム株 誤発注 事件

みずほ証券のミスにより300億円の損失
こんなバグに気付かないなんて可笑しい
散々忠告をされたにも関わらず対処しなかった
=> (部分的に)重過失が認められた


責任限定条項などの免責条項があっても、重過失であれば吹っ飛ぶ

このような例があるため、免責条項があっても裁判所も詳しく聞いてくる


ユーザーが超えるべき壁:

SQLインジェクション対策をしなかったことは重過失なのか?
IPAから散々の注意があったが、対応していなかった
OSSを使ってシステムを構築するのであれば、明らかな脆弱性について対策を講じなければ重過失として判断されうる

ただし、新たに発見された脆弱性については重過失にはならない可能性がある
いずれにせよ、今後もケースバイケースで判断されていくだろう


参考


書籍: システム開発紛争ハンドブック―発注から運用までの実務対応
IT判例メモ: http://d.hatena.ne.jp/redips+law/
IT業向け法律問題情報サイト: http://www.it-houmu.com/