Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Systemdevelopment 181129231215

725 views

Published on

情報ネットワーク法学会

Published in: Law
  • Be the first to comment

  • Be the first to like this

Systemdevelopment 181129231215

  1. 1. 情報ネットワーク法学会 第 18 回研究大会   「システム開発プロジェクトの中止」 〜その手法とタイミングの見極め〜 TMI 総合法律事務所 弁護士 大井哲也
  2. 2. 2 Ⅰ .ベンダ側の法的主張 
  3. 3. 3  1.債務不履行解除に対する反論 ① 履行遅滞は認められない。 ⇒ 履行遅滞は、ユーザの追加要望に従ったもの。 ②PM 義務違反 ベンダは、ユーザにおける意思決定が必要な事項や、ユーザにおいて解決すべ き必要のある懸案事項等について、具体的に課題及び期限を示し、決定等が行 われない場合に生ずる支障、複数の選択肢から一つを選択すべき場合には、そ れらの利害得失等を示した上で、必要な時期までにユーザがこれを決定ないし 解決することができるように導くべき義務を負い、 また、ユーザがシステム機能の追加や変更の要求等をした場合で、当該要求が 委託料や納入期限、他の機能の内容等に影響を及ぼすものであった場合等に、 ユーザに対し適時その旨説明して、要求の撤回や追加の委託料の負担、納入期 限の延期等を求めるなどすべき義務を負っている。 ⇒ 要求の撤回、追加の委託料の負担、納期延長の申入れがあったかによる。
  4. 4. 4  2.瑕疵担保責任に対する反論 システムの完成があったか? 仕事が当初の請負契約で予定していた最後の工程まで終えているか否か (最終工程完成基準)。   ベンダ側で検収前の作業を全て完了し、プロダクトが、所定の仕様や性 能を客観的に満たす状態になっていれば、完成と言える。 仕事の完成後に瑕疵が判明した場合 ・瑕疵修補請求 ・損害賠償請求 ・契約解除(契約の目的を達成することができない場合)
  5. 5. 5  3.注文者解除(民法 641 条)の主張 債務不履行解除の主張が退けられた場合で、かつ、ユーザによる解除の意思表 示は民 641 条による解除であると主張-債務不履行解除崩れの注文者解除   注文者による完成前の解除と民 641 条による損害賠償 (趣旨) ① 注文者に対して不要な仕事の完成を強制することはなく,かつ社会経済的見 地からも不当 ② 注文者に損害を賠償してもらえれば請負人にとって何ら不利益はない 民法第 641 条(注文者の解除) 請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解 除をすることができる。
  6. 6. 6 【ベンダの債務不履行が認定されず、注文者解除となるケース】 ・ユーザはベンダからの具体的な提案に返答せず、返答を督促されても、  抽象的な要望ばかりを繰り返し、具体的なプロダクト着地への擦り合わせ  を怠った。 ・ベンダはユーザの要望に応えるべく様々な代替案や修正案を提案し、誠実に対    応。 ・ユーザは代替案や修正案に対して何ら応答することのないまま、突如本件請負  契約を解除した。 【ベンダからユーザへの損害賠償】 ベンダが費やしたコスト(開発要員、下請ベンダへの支払い報酬) ベンダが得られたであろう逸失利益(営業利益率)
  7. 7. 7 注文者解除(民法641条) 請負人への損害賠償の範囲は? 以下の両者を含む。 ① ベンダが既に支出した費用と、 ② 注文者解除されずに工事が完成したとすればベンダが得たであろう利益 (=報酬-下請け費用などのコスト) 東京高裁昭和60年5月28日判決は、損害に「逸失利益」も含まれるとする。 (アテハメ) 注文者側の一方的事情により工事中途で解除されるので、材料費や人工(工事や開 発人員)の報酬実費(直接的損害)の賠償を請求することできる。 加えて、工事完成により得べかりし利益(逸失利益)も損害として請求できるとし 、工事代金の5 % を認容した。 注文者解除
  8. 8. 8 但し、解除によってベンダが逆に利益を得ている場合には、 「損益相殺」として当該利益は、損害から賠償額から控除される。   例: ① 既履行部分の原状回復により回復されたパーツ・モジュール・ハードウェアで 転 用・換価できるものがある場合 ② ベンダが請負契約が解除されて、仕事完成義務を免れたために費用の支出を節 約 できた場合の節約された金額 ③ 未履行分の仕事のために手配された人員やハードウェアを他に転用・換価でき る ものがある場合 注文者解除
  9. 9. 9 Ⅱ .ベンダ側の対応策 
  10. 10. 10 1.ベンダの PM 義務は果たしている=仕様確定を効果的に進めるアイデア ステアリング・コミッティの必要的アジェンダ 契約の見直し、修正を必須とする工夫 ⇒ 追加機能の要請、その撤回要請など契約内容の変更事項 の有無を必ずステコミの場で毎回確認する。
  11. 11. 11 (ステアリング・コミッティの設置) 1 ) ユーザ及びベンダは、本件業務が終了するまでの間、その進捗状況、リスクの 管理及び報告、ユーザ及びベンダ双方による共同作業及び各自の分担作業の実 施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決そ の他本件業務が円滑に遂行できるよう必要な事項を協議するためステアリング ・コミッティを開催するものとする。 2 ) ステアリング・コミッティは、原則として、少なくとも月 1 回の頻度で定期的 に 開催するものとし、それに加えて、ユーザ又はベンダが必要と認める場合に随 時開催するものとする。 3 ) ステアリング・コミッティには、少なくともユーザ及びベンダ双方の責任者、 主 任担当者及び部門の責任者が参加するもとする。また、ユーザ及びベンダは、 ステアリング・コミッティにおける協議に必要となる者の出席を相手方に求め ることができ、相手方は合理的な理由がある場合を除き、これに応じるものと する。 ステアリング・コミッティ
  12. 12. 12 4 ) ベンダは、ステアリング・コミッティにおいて、別途ユーザ・ベンダ間にて取り決めた様   式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を確認す   るとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、推進体制の 変更   (人員の交代、増減、再委託先の変更など)の要否、その他、システム開発基本契約及 び   個別契約の変更等を必要とする事由、変更提案書の提出の有無、必要とする事由があ   るときはその 内容などの事項を必要に応じて協議し、決定された事項、継続検討とされた   事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認す   るものとする。 5 ) ユーザ及びベンダは、本件業務の遂行に関し、ステアリング・コミッティで決定された事   項について、システム基本契約及び個別契約に反しない限り、これに従わなければならな   い。 6 ) ベンダは、連絡協議会の議事内容及び結果について、書面により議事録を作成し、これを   ユーザに提出し、その承認を得た後に、ユーザ及びベンダ双方の責任者がこれに記名押印   の上、それぞれ 1 部保有するものとする。ベンダは、議事録の原案を原則として連絡協議   会の開催日から○日以内に作成して、これをユーザに提出し、ユーザは、これを受領した   日から○日以内にその点検を行うこととし、当該期間内に書面により具体的な理由を明示   して異議を述べない場合には、ベンダが作成した議事録を承認したものとみなすものとす   る。
  13. 13. 13   (変更管理手続き) ユーザ又はベンダは、第 34 条(システム仕様書等の変更)、第 35 条(中間資料の ユーザによる承認)、第 36 条(未確定事項の取扱い)に基づく変更提案書を提出し、 かつ、次の事項を記載した書面(以下「変更管理書」という。)を相手方に交付し、 ユーザ及びベンダは、ステアリング・コミッティにおいて変更提案書の内容につき協 議するものとする。 ①  変更の名称 ②  提案の責任者 ③  年月日 ④  変更の理由 ⑤  変更に係る仕様を含む変更の詳細事項 ⑥  変更のために費用を要する場合はその額 ⑦  検討期間を含めた変更作業のスケジュール ⑧  その他変更が本契約及び個別契約の条件(作業期間又は納期、委託料、契約条項 等)に与える影響
  14. 14. 14 機能追加・仕様変更による追加工程による追加報酬請求権の有無 ① 追加工程が当初から予定していた作業工程とは異なる追加工程と評価できるか? ② 追加工程による追加報酬金額の算出方法 の 2 点が問題となる   追加工程と評価できるのはどのような場合か? 基準① 報酬額を決定する際の基礎となった「業務要件」・「業務機能」・「業務に必要な 帳票」に含まれていたか否か? (i) 含まれる⇒工程追加の作業工程含まれる業務は、追加開発作業ではない。 (ii) 含まれない⇒業務機能の追加であり、 [ ベンダが原工程に含まれる・吸収する旨 の意思表示をしない限り、 ] 追加開発作業になる。 注意 ベンダが明示的に意思表示をしておかないと、黙示的にベンダが原工程に含 まれる・吸収する旨の黙示的な意思表示が認定されてしまう。 ⇒ 立証責任はベンダの負担 2.追加機能オーダーの対処法
  15. 15. 15 機能追加・仕様変更による追加工程による追加報酬請求権の有無 基準② いったん仕様が確定した後に仕様の変更があったか否か? (i) 仕様が確定する前の仕様変更⇒追加工程ではない。 (ii) 仕様が確定した後の仕様変更⇒追加工程となる。 (iii) 仕様が確定した後の仕様の詳細化⇒追加工程ではない。 注意  仕様の変更は、システム開発工程においては、当然の前提 開発(コーディング)工程の直前さらには、開発(コーディング)工程中に仕様変 更することは日常茶飯事 ベンダが明示的に (ii) 仕様が確定した後の仕様変更に該当し、かつ、これによる追加 工程により、追加報酬請求権が発生する旨の説明・合意をしないと、黙示的にベン ダが原工程に含まれる・吸収する旨の黙示的な意思表示が認定されてしまう。  ⇒ 立証責任はベンダの負担 2.追加機能オーダーの対処法
  16. 16. 16 ビジネス要件定義が曖昧で、それにより開発スコープが明確でないケースの取扱 い   裁判所の判断傾向  契約書の内容からは、開発スコープの範囲内・外が判別つかない  契約当事者の合理的意思解釈の問題     ・契約書以外の仕様書、見積書、RFP   ・契約締結までの商談内容 例えば、ベンダ作成の提案書   ・ユーザからベンダへの現行機能や業務フロー・業務要件の説明をベンダに    行っていたか   ・業務の性質上から見て、当該システムに当然に含まれる機能か、オリジナルな機    能か   を根拠に判断される。   2.追加機能オーダーの対処法
  17. 17. 17 あるべき姿 無償で引き受ける作業工程と追加報酬を要する工程を切り分け 追加報酬を要する工程を再見積り⇒個別契約の追加的変更契約の締結を徹底   各フェーズの個別契約締結後において、契約当時の合意事項がそのまま変更されずに検収まで進 むシステム開発はむしろ例外的であるという意識のもとにユーザに説明し、契約を建付ける。   契約書での対応 機能追加・仕様変更によるスコープの拡張・追加工数のメカニズムを策定   ベンダ:追加報酬を要する工程を再見積り⇒個別契約の追加的変更契約の申込み ユーザがこれを拒否する場合  次工程に進まない(=システム開発案件からの勇気ある撤退も決断すべき)   ベンダの心情 開発が頓挫したというレピュテーションの毀損を負いたくない   ユーザの心情 S-in が大幅に遅れる   解決策
  18. 18. 18 2 .ユーザの協力義務違反 Redmine などのプロジェクト課題管理票による 協力義務違反の証拠化
  19. 19. 19   プロジェクト管理ソフトウェア(例: Redmine )による課題管理マネジメント   ユーザの協力義務違反が認められる典型例1 ・課題(チケット)の放置 例:「 2 月末日までに、ユーザ部門大井CS部長に、現行システムの画面レイアウト、 画面遷移一覧をご提供頂く。」                  ↓             その後のリプライ無し 「 3 月 15 日まで期限延長」   ユーザの協力義務違反が認められる典型例2 ・ユーザとしての意思決定の遅延 例:「 2 月末日までに、受注管理機能における現行システムを存続させる案1とベン ダ及びユーザシステム部門が作成した業務改善案を盛り込んだ案2を選択頂 く。」                  ↓             その後のリプライ無し 「 4 月 15 日に、ベンダによる両案の説明会をユーザ部門及びシステム部門に対し て開催。そのためのプロコンをベンダが 4 月 1 日までに纏める。」 協力義務違反を立証するための証拠
  20. 20. 20 課題・タスク(チケット) 開発工程管理ソフト上にて、タスクを管理するのに使用される。実施すべき作業、修正すべきバ グなどの一つ一つのタスク・課題を開発工程管理ソフトの中で課題(チケット)として登録する。 1 件のタスクにつき 1 件のチケットを作成し、タスクの内容・優先度・担当者・期日・進捗状況 などを記録する。 チケットを新規に追加し、担当者を割り当て、作業の進捗に応じてそのチケットを更新する。( http://redmine.jp/glossary/)
  21. 21. 21 課題・タスク(チケット)
  22. 22. 22 アクション・プラン 平時からの対応 □ 契約書ひな形の見直し □ 契約書ひな形の情報システム部門への展開・社内勉強会の実施 □ 「有事の対応」をにらんだコンティンジェンシー・プランの策定 □ 情報システム部門との連携業務フローの策定 ・基本契約書ひな形 + 個別契約 + 修正契約の関与の仕方 ・法務のPM業務支援(≠紛争状態になってからの関与) ・ステコミ議事録のレビュー 有事の対応 □ 紛争の「種」や「芽」の段階での法務の関与の仕方 □ ステコミへの参画(場合によっては、出席) □ システム仕様変更提案書の作成・レビュー □ PM・ステコミなどのレイヤーでの配付書面・説明書面・レター・謝罪文の レビュー
  23. 23. 23 ご質問がございましたら下記まで TMI 総合法律事務所 弁護士 大井哲也 〒 106-6123 東京都港区六本木 6 - 10 - 1 六本木ヒルズ森タワー 23F Tel : 03-6438-5554 Mail : toi@tmi.gr.jp URL www.tetsuyaoi.com  FB 、 Twitter ” “大井哲也
  24. 24. 24 主な取扱分野 専門分野は、 M&A 、 IPO 、企業間紛争・訴訟。 ・アプリ・システム開発におけるプロジェクト管理・紛争処理・裁判 ・クラウドコンピューティング、インターネット・インフラ / コンテンツ、 SNS ・アドテクノロジーとビッグデータ利活用 ・情報セキュリティ、情報漏洩インシデント調査・対応・第三者調査委員会 などの各産業分野における実務に精通し、情報セキュリティマネジメントシステム ( ISMS )認証機関公平性委員会委員長、社団法人クラウド利用促進機構 ( CUPA )法律アドバイザー、経済産業省の情報セキュリティに関するタスクフォ ース委員を歴任する。

×