20組勉強会20130125v1
- 1. 情報システム開発をめぐる紛争と予防対策 2013年1月25日 弁護士 伊藤 雅浩 内田・鮫島法律事務所 ©Copyright Masahiro Ito All Rights Reserved 1
- 2. 自己紹介① 伊藤雅浩 弁護士 内田・鮫島法律事務所 略歴 – 名古屋大学大学院工学研究科情報工学専攻 – アクセンチュアにてSAP導入(FI，ABAP/4)，サプライチェーンマネジメ ントシステムの企画設計・開発運用 – スカイライト・コンサルティングにて大規模基幹系システム開発のプロ ジェクトマネジャー等に従事 – 一橋大学法科大学院修了後，弁護士 – IT，ネット企業等を対象に，知的財産，企業法務を中心に取り扱う ©Copyright Masahiro Ito All Rights Reserved 2
- 3. 自己紹介② 伊藤雅浩 弁護士 内田・鮫島法律事務所 著作等 – IT判例メモ （http://d.hatena.ne.jp/redips+law/） – 「システム開発中断をめぐる紛争予防・解決のポイント」旬刊経理情報 2012年6月1日号 – ビジネステレビ誠「教えて！ビジネス上のトラブル」コーナー ©Copyright Masahiro Ito All Rights Reserved 3
- 4. 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 4
- 5. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 5
- 6. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 紛争になりやすい土壌がある 柔軟な 変更要求 頻繁な 短納期 技術刷新 階層的な 目に見えない 受発注 成果物 ©Copyright Masahiro Ito All Rights Reserved 6
- 7. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 経営上インパクトが大きい 当社が、平成14年4月に受注し開発を行なってきたサービス業向け基幹シ ステム開発プロジェクトについて、お客様との仕様認識の相違や確定の遅 れ、変更の多発、さらには新技術に対する未習熟や工程管理が不充分な ことから手戻り作業が発生する等、様々な問題が発生いたしました。これに より、当該プロジェクトの完了までには著しい規模の肥大化と大幅な納期 の延伸が余儀なくされることとなりました。費用、規模、納期等においてお 客様と当社の間に大きな認識の相違が生じており、当社はこれ以上当該プ ロジェクトを継続することにより発生する費用的要員的ロスの拡大を勘案し、 総合的な経営判断から作業の中止と当該受注契約の解約を決定し、お客 様と協議のうえ合意するにいたりました。 これに伴いソフトウェア開発に係る仕掛品の廃却とそれに伴う諸費用等 1,260百万円を平成16年3月期において特別損失に計上することといたし ました。 大手SI事業者プレスリリースより ©Copyright Masahiro Ito All Rights Reserved 7
- 8. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 経営上インパクトが大きい 調査報告書指摘事項への三者の対応状況に対する当委員会の評価をま とめれば、運営基盤システムは、最終稼働の可能性が全く無いとは言えな いものの、最適化計画の予定どおり平成２６年１月に稼働することはほぼ 不可能であると考えられる。また、Ａ社から提案されている平成２９年１月で あっても、最終稼働が実現するとの確証を得る程度にまで技術的な裏付け があるとは認められない。 すなわち、本プロジェクトは、今後設計書の修正等に相当の期間を確保し たとしても、最終稼働が実現するとされる時期（平成２９年１月）までには、 約５年またはそれ以上の期間を要する状況にあり、かつ、当該時期に最終 稼働するかどうかも極めて不透明な状況に陥っていると言わざるを得ない 特許庁情報システムに関する技術検証委員会「技術検証報告書」より ©Copyright Masahiro Ito All Rights Reserved 8
- 9. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 ありがちな紛争の例① 「はじめてほしい」と言われて作業に着手したが・・ 結局取締役会の承認が得られな かったので作業中止してください。 それは困ります。少なくとも作業分 の報酬は支払ってください。 ユーザ ベンダ 契約成立を巡る問題 2章で ©Copyright Masahiro Ito All Rights Reserved 9
- 10. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 ありがちな紛争の例② 納期になって，ベンダが納品を申し出たが・・ 納品するといわれても，これでは 完成したものとはいえない 承認いただいた要件定義書どおり には完成しています ユーザ ベンダ システム完成を巡る問題 3章で ©Copyright Masahiro Ito All Rights Reserved 10
- 11. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 ありがちな紛争の例③ 稼働間近のテストを経て様々な指摘・要望が発生したが・・ 仕様変更にあたる部分は，追加の 報酬支払をコミットしてください これのどこが仕様変更ですか。要 件定義が甘かったところを詳細化 しただけですよ ユーザ ベンダ 追加費用を巡る問題 3章で ©Copyright Masahiro Ito All Rights Reserved 11
- 12. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 ありがちな紛争の例④ 検収をして，ユーザ側のテストで多数の不具合が発生した・・ 不具合があまりにもひどい上に， 収束しないので代金は払えません いずれも仕様ですし，修正するとし てもすぐに直る問題です ユーザ ベンダ 不具合を巡る問題 4章で ©Copyright Masahiro Ito All Rights Reserved 12
- 13. 1 2 3 4 5 6 1.1.よくある紛争例 1 2 3 4 5 ありがちな紛争の例⑤ 設計フェーズまでは順調に進捗し，代金が払われたが・・ 結局システムは完成しなかったか ら，支払済みの前フェーズの代金 も全て返還してもらいたい 前フェーズの契約は，別の契約で すし，検収もらっているので返還 ユーザ は応じかねます ベンダ 損害の範囲の問題 5章で ©Copyright Masahiro Ito All Rights Reserved 13
- 14. 1 2 3 4 5 6 1.2.システム開発紛争の特徴 1 2 3 4 5 専門性を要し，長期間，解決コストがかかる – 二重の専門性 • 裁判所，弁護士は，システム開発プロセス，技術，業界知識に詳し くない • 完成，不具合等の認定には，ユーザの業務の理解が求められる – 解決までの時間が長い • 紛争発生から，訴訟による解決完了まで3年，5年以上かかるケー スは珍しくない – 社内リソースの負担が大きい • 使う見込みのないシステムのあらさがしや，資料の整理など，エン ジニア，システム部門の負担が大きい – 二重の負担 • 一人の担当者が前向きの仕事（現行システムの仕事）と後ろ向き の仕事（紛争解決支援）の両面の作業を求められる ©Copyright Masahiro Ito All Rights Reserved 14
- 15. 1 2 3 4 5 6 1.3. システム開発に関する契約論の前提 1 2 3 4 5 契約の種類 物・情報を制作・譲渡する サーバ/機器を販売する 売買契約・リース契約 ソフトウェアの開発を受託する 請負契約・委任契約 （業務委託契約と呼ばれることも コンテンツの制作を受託する 多い） 本日の対象 物・情報を使用させる ソフトウェアを使用許諾する 使用許諾契約 （ライセンス契約ともいわれる） コンテンツを使用許諾する ©Copyright Masahiro Ito All Rights Reserved 15
- 16. 1 2 3 4 5 6 1.3. システム開発に関する契約論の前提 1 2 3 4 5 • 民法上の契約の分類 – 民法上は，「請負契約」「委任契約*」を定めている。 – 契約書に書かれていない事態が生じたとき，適用される条 文が異なる。 請負契約 委任契約 委託する主題 仕事の完成 事務の処理 善良な管理者の注意を 受託者の義務 仕事を完成させる義務 もって事務の処理を行う義 務 納期遅延の場合の債務不 履行責任 善良なる管理者の注意を 責任 払っていない場合の債務 不具合がある場合の瑕疵 不履行責任 担保責任 など * 正式には準委任契約という ©Copyright Masahiro Ito All Rights Reserved 16
- 17. 1 2 3 4 5 6 1.3. システム開発に関する契約論の前提 1 2 3 4 5 • 一般的な分類（契約書の名称では判断できない） 仕事の範囲が明確で，仕事の完成が必 要なとき 物・データ等の納品が必要なとき 請負契約 納品物の不具合が発覚した際に交換・修 正が必要なとき アドバイス，情報提供など，「仕事の完 成」という概念がないとき 委任契約 範囲が明確でなく，契約目的にしたがっ て作業内容を柔軟に決めたいとき ©Copyright Masahiro Ito All Rights Reserved 17
- 18. 1 2 3 4 5 6 1.3. システム開発に関する契約論の前提 1 2 3 4 5 請負と準委任の性質が混在する契約もありうる 東京地裁平成24年4月25日判決より 本件個別契約の契約書では，・・が認められるのであり，さらに は，Ｙが作業の有無にかかわらず月額メンテナンス料を支払う とされていた（契約書８条(5)）のであるから，本件個別契約は， 本来は準委任契約に近い性質を有していたものとみるのが相 当である。 しかし，本件個別契約の契約書の作業内容（２条）には，本来， 請負として把握するのが相当である「ソフトウェアの軽微な改 変又は機能追加」が含まれていて，契約書の７条が報酬支払 いの前提としてＹによる「検収」を定めており，Ｙからのクレーム に押され，実績工数を大きく下回る請求工数となることが常態 化していたから，その後の運用の実態において，本件個別契 約の実質は請負に近いものとなっていた。 ©Copyright Masahiro Ito All Rights Reserved 18
- 19. 1 2 3 4 5 6 1.3. システム開発に関する契約論の前提 1 2 3 4 5 基本契約と個別契約 • 多段階で契約し，共通する条項を基本契約に定めることが 多い • 途中で頓挫した場合，過去に遡って返還を求められるか 紐づく契約すべてに共通して適用されるルール。単体では 基本契約 一部を除いて権利義務は生じない。 システム 要件定義 基本設計 開発 テスト 移行 プロジェクトマネジメント ©Copyright Masahiro Ito All Rights Reserved 19
- 20. 1 2 3 4 5 6 1.4. 基本契約書中の重要条項 1 2 3 4 5 検収 第○条（検収） 「検査仕様書」の作成 1. ユーザは，納入物を受領後，検査期間内に遅 主体，時期，承認方 滞なく検査仕様書に基づいて検査する。 法は？ 2. ユーザは，納入物が，前項の検査に適合する 場合，検査合格証をベンダに交付する。検査に 開発フェーズの検収 合格しない場合，ユーザは，ベンダに対し，不 と，ユーザテストとの 合格となった具体的理由を書面にて交付し，修 正・再納入を求めることができる。 関係は整理されてい るか？ 3. ユーザが検査期間内に，具体的理由を示して 異議を述べないときは，検査期間満了時に検 査合格とみなす。 「検査に適合」の条件 4. 検査合格をもって検収完了とする。 は明確にできるか？ ©Copyright Masahiro Ito All Rights Reserved 20
- 21. 1 2 3 4 5 6 1.4. 基本契約書中の重要条項 1 2 3 4 5 瑕疵担保責任 第○条 瑕疵担保責任 瑕疵担保期間の始期 1. 検収完了後１２ケ月以内に，本件システムに および終期。検収後， 瑕疵（納品された仕様書との不一致，論理的誤 本番稼動まで長期間 りおよび当然有すべき品質を具備していないこ とをいう。以下同じ。）が発見された場合，乙は， あいてしまう場合など 当該瑕疵を無償で補修する。 の対処。商法526条と 2. 前項の瑕疵を補修した後の手続は○条に従う。 の関係。 【商526】「買主が六箇月以内にその瑕疵を発 3. 第１項の瑕疵は，瑕疵が甲の提供した資料ま 見したとき」の代金減額・損害賠償。 たは甲の指示によって生じたときは適用しない。 ただし，乙が当該資料または指示が不適切で 瑕疵の定義。「乙の責 あることを知りながら告げなかったときはこの限 めに帰すべき瑕疵」 りではない。 「仕様書との不一致」 など。 ©Copyright Masahiro Ito All Rights Reserved 21
- 22. 1 2 3 4 5 6 1.4. 基本契約書中の重要条項 1 2 3 4 5 著作権帰属 第○条（納入物の著作権） 著作権の帰属はユー 1. 納入物に関する著作権（著作権法第27条及び ザにとって必ずしも必 第28条の権利を含む。以下同じ。）は，乙また 須ではない。（使用・メ は第三者が従前から保有していた著作物の著 ンテなどは問題なく行 作権を除き，甲より乙へ委託料が完済されたと える） きに乙から甲へ移転する。かかる移転の対価 は委託料に含まれるものとする。 2. 乙は，甲に対し，前項において乙または第三者 に著作権が留保された著作物について，本件 留保される範囲は納 システムを自己利用するために必要な範囲で 品時に明確に。 無償で利用することを許諾する。乙は，かかる 利用について著作者人格権を行使しない。 ©Copyright Masahiro Ito All Rights Reserved 22
- 23. 1 2 3 4 5 6 1.4. 基本契約書中の重要条項 1 2 3 4 5 損害賠償 第○条（損害賠償） 損害の種類による限 1. 甲および乙は，本契約および個別契約の履行 に関し，相手方の責めに帰すべき事由により損 定をどう考えるか。 害を被ったときは，相手方に対し，現実かつ直 接に被った通常の損害の賠償を請求すること ができる。 額による限定。 2. 前項の損害賠償の累計額は，債務不履行，不 法行為その他請求の原因を問わず，原因と なった個別契約に定める委託料の額を上限と する。ただし，損害賠償義務者の故意または重 大な過失に基づく場合には，この制限を適用し ない。 ©Copyright Masahiro Ito All Rights Reserved 23
- 24. 1 2 3 4 5 6 1.4. 基本契約書中の重要条項 1 2 3 4 5 （参考）重大な過失 「ほとんど故意に近い著しい注意欠如の状態」 不備のある更新プログラムによってデータを消失させたという積極的な 過失であること、（中略）積極的に情報セキュリティの不備を生じさせて ファースト いたこと、担当者Aが、本来上長の許可が必要であることを認識しなが サーバ事件 ら、無許可で本件メンテナンスを行ったことを考慮すれば、ファースト サーバの過失は、軽過失の枠内ではあるものの、比較的重度の過失で あった（ファーストサーバ 第三者調査委員会報告書・2012年8月） システム開発の頓挫を招いた責任がほぼIBMのプロジェクトマネジメン スルガvs ト責任にあるとしながらも「故意またはこれと同視すべき重過失」にあた IBM事件 るとはしていない（東京地裁平成24年3月29日判決） ジェイコム株 取消注文が入らなかったという点については重過失を認めず，注文取 消の連絡を受け取った後，一定時間後も対応しなかった点のみを重過 誤発注事件 失とした（東京地裁平成21年12月4日判決） ©Copyright Masahiro Ito All Rights Reserved 24
- 25. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 25
- 26. 1 2 3 4 5 6 2.1. ケース① 1 2 3 4 5 この場合，A社は作業分の報酬を請求できるだろうか A社の営業マンa氏は，B社のb課長と新販売システム構築に 関する商談を行っていた。b課長は，A社に頼む見込みだから， チーム編成と作業準備にかかってくれとお願いした。 A社はさっそく従業員ほか，協力会社も含めてメンバーを集め て，B社に「契約書案」を提出した上で，作業準備に取り掛かっ た。（契約書は署名・捺印されていない） 6週間後・・ 結局予算が下りず，待ったがか かった。申し訳ない。 要件定義はほぼ終わってますよ。成 果物提出するので払ってください。 ユーザ ©Copyright Masahiro Ito All Rights Reserved ベンダ 26
- 27. 1 2 3 4 5 6 2.1. ケース① 1 2 3 4 5 問題の所在 契約が成立していれば，「委託者による解除」だと いえるため，損害賠償として作業分の報酬相当額 を請求できそうだ cf. 請負契約の場合，「注文者は，いつでも損害を賠償して契約の解除をすることができる。」 （民法641条）。準委任契約の場合，「当事者の一方が相手方に不利な時期に委任の解除をし たときは，その当事者の一方は，相手方の損害を賠償しなければならない。」（民法651条2項）。 課長の「口頭での依頼」と，「契約書（案）」だけで 契約成立が認められないと，ただの（無償の）営業 活動で終わってしまうおそれがある ©Copyright Masahiro Ito All Rights Reserved 27
- 28. 1 2 3 4 5 6 2.2. 契約は成立しているか 1 2 3 4 5 法律上は，口約束でも契約は成立するが・・ 業務用コンピューターソフトの作成やカスタマイズを目的とする 請負契約は，業者とユーザ間の仕様確認等の交渉を経て，業 者から仕様書及び見積書などが提示され，これをユーザが承 認して発注することにより相互の債権債務の内容が確定した ところで成立するに至るのが通常であると考えられる。 名古屋地裁平成16年1月18日判決より • ベンダの提出した提案書は，必ずしもユーザの業務内容を十分 検討した具体的なものではなかった • ユーザが採用通知を出しているとしても，交渉の相手方を絞り込 契約成立を んだという意味を有するにとどまる 否定した • 本件では，カスタマイズの有無など，仕様確認を経てからカスタ マイズの範囲や費用の合意が取れた段階で契約が成立するこ とが予定されていた ©Copyright Masahiro Ito All Rights Reserved 28
- 29. 1 2 3 4 5 6 2.2. 契約は成立しているか 1 2 3 4 5 裁判では，企業間取引において，契約書が取り交わさ れていない場合，契約の成立が容易に認められない 東京地裁平成17年3月28日判決より •キックオフミーティングについては，ユーザ •金額に関する交渉がメール等で数 の責任者が出席しておらず，出席を依頼し 回にわたって行われた た事情もない •ユーザから「契約締結に関する覚 •作業に着手していたことをユーザは認識し 書締結しましょうか」というメールが ていたが，ベンダが有償であることを明確 あった に説明していたことはなく，有償作業に入 •キックオフミーティングが開催され， るという合意があったと認めることはでき 議事録も作成され，捺印があった ない •ベンダは作業に着手していた 契約成立を否定した ©Copyright Masahiro Ito All Rights Reserved 29
- 30. 1 2 3 4 5 6 2.2. 契約は成立しているか 1 2 3 4 5 –肯定例 • システム開発総額の見積書が提示されたものの，開発範囲はFit&Gapの結 果によって決まるなどの記載に照らすと開発契約は成立していないがパッケ ージライセンス契約と要件定義にかかる契約は成立している（東京地判平 21.9.4） – 否定例 • 正式には上層部の決裁が必要であったことは双方了解しており，契約書も案 文のやり取りにとどまっていたことから契約は成立していない（東京地判平 20.9.30） • 前半フェーズでは書面による注文があったが，後半フェーズで書面がなかっ た等により後半フェーズについては契約が成立していない（東京地判平 19.11.30） – 中間（？） • 基本契約書には開発の個別契約は書面交付により成立するとされていたに もかかわらず，書面がなかったことから請負契約は成立していないが，要件 定義等を内容とする準委任契約は口頭により成立していた（東京地判平 19.1.31） ©Copyright Masahiro Ito All Rights Reserved 30
- 31. 1 2 3 4 5 6 2.3. 契約が成立していないと請求できないか 1 2 3 4 5 契約締結上の過失に基づく損害賠償の可能性 契約締結上の過失論 契約成立過程における一方当事者の故意・過失によって相手 方が損害を被った場合には，一定の要件を満たせば，何らか の責任を肯定すべきという法理。 加藤新太郎編「契約締結上の過失」（新日本法規）2頁より • 契約締結交渉の成熟度が高いこと 代金等の契約の主要部分の合意状況 認められる 契約書等の書面提示の状況 要件 内金等のやり取りの有無 • 信義則違反と評価される帰責性があること 効果 • 信頼利益の賠償（過失相殺の可能性あり） ©Copyright Masahiro Ito All Rights Reserved 31
- 32. 1 2 3 4 5 6 2.3. 契約が成立していないと請求できないか 1 2 3 4 5 契約締結上の過失論に基づく損害賠償の場合，満額認 められることは難しい。 東京地裁平成19年11月30日判決より •基本契約には発注書・請書のやり取りに よって個別契約が成立するとしているので， •基本契約が締結され，その後第1 契約は成立していない フェーズの発注・作業が完了した •先行フェーズでも注文書発行前から作業 •第2フェーズが開始したが，正式な が行われ，当然継続すると思われていた 発注書は交付されなかった こと •親会社の承認が得られなかったと •ユーザは注文書が発行されない可能性が して，1ヵ月後に中止となった あることを知りながら作業遂行を漫然と容 認した •交渉の過程で請求額1.5億円のうち， 約2000万円が支払われた •もっとも，ベンダも損害拡大を防ぐ対応を 取るべきだった 請求額の7割認容 ©Copyright Masahiro Ito All Rights Reserved 32
- 33. 1 2 3 4 5 6 2.3. 契約が成立していないと請求できないか 1 2 3 4 5 2割の過失相殺が認められた事例。 •Ｙは，同年４月以降，同年７月４日の打合せに 至るまでの間，ＸがＹとの打合せに基づいて本 東京地裁平成24年4月16日判決より 件システムの構築に向けた仕様の確定等の具 体的作業を行っており，それに必要な費用を支 出していることを認識しながら，Ｘの提出した見 •1.6億として提案し，コンペの 積書の見積内容や見積金額に疑問や不満を述 結果，内定したことが通知さ べることもなく，これらの作業に協力しており，そ れた。 れにもかかわらず，見積金額の合意成立の見 •仕様の打ち合わせが繰り返 込みがないことを理由として本件業務委託契約 され，1.3億円に減額。 の締結を拒絶するに至ったのであるから，その ようなＹの対応は，上記のような信頼を抱いてい •Xから正式発注提示の依頼 たＸとの関係においては，信義則上の義務に違 が繰り返されたが，結果的に 反したものと認めるのが相当であり，Ｙは，本件 半年後に金額が折り合わず 業務委託契約の締結を信頼したためにＸが支 に物別れ。 出した費用等の損害について不法行為による 賠償責任を負うというべきである。 ただし2割の過失相殺 ©Copyright Masahiro Ito All Rights Reserved 33
- 34. 1 2 3 4 5 6 2.3. 契約が成立していないと請求できないか 1 2 3 4 5 –肯定例 • 他のベンダも提案に加わったが形式的なものであるなどと説明して設計業務 の一部を実施させていたことから，ユーザには契約準備段階における信義則 違反がある（東京地判平20.7.29） – 否定例 • ユーザが契約締結前に作業を着手するよう求めたこともなく，契約締結が確 実であるとの過大な期待を抱かせた事情もないことからユーザに契約締結上 の過失もない（東京地判平20.9.30） • ユーザは発注の意思を明確にしておらず，見積額が上昇したことに納得せず に提案を拒否したことなどの事情の下では，ユーザに信義則上の注意義務 違反はない（東京地判平17.3.28） –（参考）商法512条に基づく請求 • 「商人がその営業の範囲内において他人のために行為をしたときは、相当な 報酬を請求することができる。」に基づいて，契約なくして報酬請求を認めた 事例もある。 ©Copyright Masahiro Ito All Rights Reserved 34
- 35. 1 2 3 4 5 6 2.4. 紛争予防・早期解決のために 1 2 3 4 5 書面を取り交わす前に作業着手することは双方にとってリスクが あることに留意（契約書がないから契約書でヘッジすることもできない） ユーザの立場から ベンダの立場から • 社内の意思決定が完了していない場合， • 有償の作業，そうでない作業の区別は， ベンダに対し，明確にその意思を伝え，曖 明確に伝える 昧にしない • 書面がない段階での作業着手は極力さけ • スケジュール立案の起点は，契約締結時 る 点とする • 担当者ベースでも，内示書を提示してもら • 意思決定に時間がかかるときは，先行着 う 手分について費用が発生し得ることにつ いて覚悟する • 内示書には，できれば，契約不成立時の 清算条項を設けたい（期間経過，投下工 数に応じた清算など） • 協力会社に委託する際は発注者としての 注意を ©Copyright Masahiro Ito All Rights Reserved 35
- 36. 1 2 3 4 5 6 2.4. 紛争予防・早期解決のために 1 2 3 4 5 内示書のサンプル ○○プロジェクト ○○工程の着手依頼 契約成立を明示的に 1. 表題の件に関し、正式契約に先立ち、貴社に対し本文書で の内示を致しますので、下記案件に関し、期日通りの着手、 否定することになった 及び必要な準備をお願いします。 としても，一方的に破 2. 掲題の業務委託は、諸条件について協議・合意の後、双方 棄した場合には，損 の当事者の代表者、代表者に授権された者の記名・捺印 ある契約書の取り交わしによって締結されるものとします。 害賠償ないし報酬請 3. 尚、本内示による着手後、途中解約および正式契約を締結 求できるような建てつ しない事由が発生した場合、着手によって生じた費用は、 けとなっている。 協議の上清算に応じるものとします。 記 (a) 案件 清算方法を明示する (b) 工程 ことが望ましい。 (c) 期間 ・・・ ©Copyright Masahiro Ito All Rights Reserved 36
- 37. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 37
- 38. 1 2 3 4 5 6 3.1. ケース② 1 2 3 4 5 このまま頓挫した場合，法律関係はどうなるだろうか。 要件定義，基本設計と，形式的にはフェーズが進行し，両フェー ズの検収完了と共に，代金がB社からA社に支払われた。しかし， 実態は，未確定の要件・課題が山積しており，先送りしただけに すぎないことを，A社B社のリーダークラスは知っていた。 納入予定の２週間前 来月には完成します。納入予定日 からは３週間ほど遅れてしまいま すが，検収をお願いします。 何言ってるんだ。テストをしてる形 跡もみられないし，こちらの仕様が ユーザ 反映されてないじゃないか。 ベンダ ©Copyright Masahiro Ito All Rights Reserved 38
- 39. 1 2 3 4 5 6 3.1. ケース② 1 2 3 4 5 さらに１カ月後 完成したと言われたが，使える状態 ではないし，テストが完了した証拠 もない。これでは受け取れない。 要件定義書に対応する仕様はす べて実装済みです。テストのエビ ユーザ デンスは納品物ではありません。 ２週間以内に検収してください。 ベンダ B社（ユーザ）は，報酬支払を免れることができるか。 A社（ベンダ）は報酬請求できるか。 ©Copyright Masahiro Ito All Rights Reserved 39
- 40. 1 2 3 4 5 6 3.1. ケース② 1 2 3 4 5 システムは完成したか（争点①），未完成の場合，どち らに責任があるか（争点②）が問題となる。 争点① 争点③ システムは Yes 重大な瑕疵が No 契約解除は 完成したか 報酬支払義務 あるか できない 発生 No Yes 争点② ベンダに Yes ユーザの 債務不履行があったか 損害額の判断 No 民法641条の cf. 「注文者は，いつでも損害を賠償して契約の解除を することができる。」（民法641条）。 検討 ©Copyright Masahiro Ito All Rights Reserved 40
- 41. 1 2 3 4 5 6 3.2. システムは完成しているか（争点①） 1 2 3 4 5 法律上は，目的物の引渡し（完成）によって報酬請求権 が生じるが・・ 請負人が仕事を完成させたか否かについては、仕事が当初の 請負契約で予定していた最後の工程まで終えているか否かを 基準として判断すべきであり、注文者は、請負人が仕事の最 後の工程まで終え目的物を引き渡したときには、単に、仕事の 目的物に瑕疵があるというだけの理由で請負代金の支払を拒 むことはできない 東京地裁平成14年4月22日判決より 「最後の工程」とは？ 他の基準を用いた裁判例もある ©Copyright Masahiro Ito All Rights Reserved 41
- 42. 1 2 3 4 5 6 3.2. システムは完成しているか（争点①） 1 2 3 4 5 不具合はありつつも，本番稼動させている場合は，ほ ぼ「完成」が認められる。 東京地裁平成22年1月22日判決より •事務システムの元請と，下請との間 の紛争 •新システムのプログラムを開発し，本番稼 働を開始するまでの作業が最終の工程 •システム稼働後も種々のトラブルが あった •本番稼働後の作業は本番稼働前の仕事 の成果物の不備を補修する別個の債務 •下請は報酬残額と契約外に行った 作業の報酬を請求(約6.5億円)した •ユーザにおいて本番稼動を開始している のに対し，元請がシステムの瑕疵 ことから，仕事の完成が認められる などを理由に23億円の損害賠償を 請求 完成を認定 （ただし瑕疵の論点あり） ©Copyright Masahiro Ito All Rights Reserved 42
- 43. 1 2 3 4 5 6 3.2. システムは完成しているか（争点①） 1 2 3 4 5 工程の点を問わず，要求仕様を実現しているかどうか で判断した事例もある。 東京地裁平成22年9月21日判決より •新システムの構築に当たっては，旧システ •ユーザが，システムは完成していな ムの機能を基本的に踏襲することが，ベン いとして検収を拒絶し，開発契約を ダの債務の内容だった 解除 •ユーザの業務フローの重要な部分につい •ベンダはシステムは完成していると て旧システムの機能を踏襲しておらず，そ して1.1億円を請求し，ユーザも反 のことについてユーザの同意を得ていな 訴として損害賠償1.2億円を請求 い 完成を否定 コンサルティング契約の性質や，システム改修にかかる損害に関する判断も興味深い ©Copyright Masahiro Ito All Rights Reserved 43
- 44. 1 2 3 4 5 6 3.2. システムは完成しているか（争点①） 1 2 3 4 5 契約上，完成の判断基準を定める 第○条 1. 乙は甲に対し，○月○日までに，別 「検査仕様書」とは何か 紙1記載の納入物を納品書とともに • 誰が作るものか 納入する。 • いつまでに作るものか 2. 甲は，納入があった場合，検査仕 • 検査仕様書の確定プロセス 様書に基づいて次条に定める検査 • 契約上の「検査」「検収」と，実務上の を行う。 「運用テスト」「UAT」との違いは 3. 乙は，納入物の納入に際し，甲に 対して必要な協力を要請できるもの とする。 ©Copyright Masahiro Ito All Rights Reserved 44
- 45. 1 2 3 4 5 6 3.2. システムは完成しているか（争点①） 1 2 3 4 5 契約書からシステム完成判断基準が読み取れない場合，完成の 立証に相当の労力を要することになり，泥沼化の原因となる。 ユーザの立場から ベンダの立場から • 最後の工程は「検収」で，検収合格が • 「これを作れば完成」という仕様を明 報酬請求権が生ずる条件という立場 確にし，かつ契約書から紐づける をとる • システム完成の基準を契約上明らか • 「検査しない」ではなく，「検査」したう にし，それに沿うように行動する（つま えで，理由をつけて「不合格証」を交 り検収ができる状態まで持っていく 付する 等。）→立証負担の緩和 • 再検査が予定されているので，一度 • 工程表を双方で合意し，変更後の工 の不合格で解除することは危険 程も逐次合意を取る ©Copyright Masahiro Ito All Rights Reserved 45
- 46. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 原則として，ベンダが完成の責任を負う 東京地裁八王子支部平成15年11月5日判決より ベンダは， コンピューターソフトウェアの開発，販売，コンサルティング等の専門企業 であり，システムを構築するについては，顧客であるユーザから，その業 務の内容等必要な事項を聴取し，その結果に基づいて，ユーザのシステ ム導入目的に適うシステムを構築すべき義務を本件請負契約に基づき 負うものと解される ユーザも， 一つの企業体として事業を営み，その事業のためにシステムを導入する 以上，自己の業務の内容等ベンダがシステムを構築するについて必要と する事項について，正確な情報をベンダに提供すべき信義則上の義務を 負うものと解される。 ©Copyright Masahiro Ito All Rights Reserved 46
- 47. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 ベンダはプロジェクトマネジメント責任を負う 東京地裁平成16年3月10日判決より 原則，「ベンダ＝専門家」「ユーザ＝ 1. ベンダは，専門業者として，自ら有 素人」という考え方に立っている。 する高度な専門的知識と経験に基 づき，システムを完成させるべき債 しかし，下請関係の場合，むしろ委 務を負っている。 託者も専門家であるため，この考 2. ベンダは，期限までに完成させるよ え方は修正されると考えられる。 う，常に進捗状況を管理し，開発作 業を阻害する要因の発見に努め， 裁判上も「プロジェクトマネージメント これに適切に対処すべき義務を負 義務」という用語が登場する。 う（これを「プロジェクトマネージメン ト義務」という。）。 こうした義務は，契約書上明示され 3. ベンダは，専門的知識を有しない ていなくとも，契約の性質上，発生 ユーザに阻害する行為がされること するものだとされている。 のないよう働きかける義務を負う。 ©Copyright Masahiro Ito All Rights Reserved 47
- 48. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 プロジェクトマネージメント義務の中身とは？ 東京地裁平成16年3月10日判決（カスタムメイド開発型）より ベンダは、ユーザにおける意思決定が必要な事項や、ユーザにおいて解決す べき必要のある懸案事項等について、具体的に課題及び期限を示し、決定等 が行われない場合に生ずる支障、複数の選択肢から一つを選択すべき場合 には、それらの利害得失等を示した上で、必要な時期までにユーザがこれを 決定ないし解決することができるように導くべき義務を負い、また、ユーザが システム機能の追加や変更の要求等をした場合で、当該要求が委託料や納 入期限、他の機能の内容等に影響を及ぼすものであった場合等に、ユーザに 対し適時その旨説明して、要求の撤回や追加の委託料の負担、納入期限の 延期等を求めるなどすべき義務を負っていたということができる。 • 「課題があります」「決めてください」というだけでは足りない。 • 仕様追加・変更があった場合にも，それが与える影響を説明し，場合に よって撤回させるなど，ユーザをリードしなければならない。 ©Copyright Masahiro Ito All Rights Reserved 48
- 49. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 プロジェクトマネージメント義務の中身とは？ 東京地裁平成24年3月29日判決(スルガvsIBM事件，パッケージ型)より 本件のように、ベンダとユーザとの間でパッケージ型システム開発が行われる場合、パッ ケージの選定は、開発の対象となるシステムの根幹を成すものであり、その適切な選定、 開発方法の採用は極めて重要な課題である。システム開発の専門家であるベンダは、 パッケージの選定に当たり、パッケージの機能・性能、設定・導入の容易性、導入実績、 パッケージの提供者の導入実績、経営の安定性、技術力、カスタマイズへの積極性その 他関連する諸事情を考慮して、ユーザが構築しようとしているシステムに最適のパッケー ジを選定した上、これに適した開発方法を採用しなければならず、そのために、ベンダは、 ユーザへの提案前に様々な観点からパッケージの機能、開発手法、リスク等について十 分に検証又は検討しなければならないものというべきである。 加えて、それまで日本の銀行の基幹系のシステム開発において海外のパッケージが用い られたことはなかったのであり、しかも、ベンダは、製造業や流通業でのパッケージ・ベー ス・アプローチの経験はあるが、銀行のシステムをこの手法で開発した経験がなかったの であるから、ベンダとしては、本件システム開発に当たって、より慎重に、パッケージの機 能、開発手法、リスク等について検証又は検討し、適切な開発方法を採用しなければなら ないものというべきである。 ©Copyright Masahiro Ito All Rights Reserved 49
- 50. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 スケジュール遅滞，スコープ変更は早めの情報共有を 前掲スルガvsIBM事件より ユーザとしては、本件最終合意が締結された時点において、ベンダが提案した開発手 法に従ったシステム開発に問題があるとは認識していなかったし、本件最終合意書で 定められたベンダの支払金額には相応の根拠があると信頼していたものというべきで ある。 また、本件最終合意書が交わされた後、ベンダの提案した開発手法に誤りがあるとし てこれを変更する提案がされ、旧ＢＲＤ及び新ＢＲＤが行われたとしても、その経緯の 中で、ベンダは、ユーザに対し、本件最終合意書の内容は両者間の合意であり、これ を実現する方向で開発を進めるなどと述べ、本件最終合意書の内容を尊重する姿勢を 表明していたのであるから、ユーザは、少なくとも、平成１８年８月にベンダからサービ スインの時期の修正について提案がされるまで、平成２０年１月に一斉切替えによる サービスインを行うことが無理であるとは考えていなかったし、また、同月にベンダから 追加費用の負担についての申出がされるまで、ユーザにおいて追加費用の負担を考 慮する必要はないと考えていたのである。そして、そのような認識の下で、上記各現行 契約及び個別将来契約に基づく代金を支払ったものである。 ©Copyright Masahiro Ito All Rights Reserved 50
- 51. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 プロジェクトマネージメント義務の中身とは？ 東京地裁平成22年5月21日判決より そもそも，納期を守れるよう業務を管理することは請負人であるベンダの責任範囲であ る上，単品入出力ソフト及び予約管理システムの開発の追加によっては，本件システ ム自体の開発にはやり直しの必要が生じることがなく，ユーザとしても基本的機能が早 期に問題なく動くことを求めていたものであることは，＜略の＞とおりであるから，ベン ダとしては，基本的機能であって，当初契約の内容であった本件システムの開発に精 力を傾注し，これを先行させるべきことは当然であったものであり，その間における ユーザによる要求についても，信義則に反するところがあったとは認められない。 （納期延長の合意があったとの主張に対し）開発遅延を理由とするソフトウェア開発契 約の解除は，注文者にとっても，発注のやり直し等による不都合が生じる場合が少なく ないことから，注文者としては，開発が遅滞した状態にあったとしても，直ちに契約を解 除することなく，暫定的に請負人に協力して開発を進めていかざるをえない。そうすると， 上記＜略＞にみたように，注文者であるユーザが，納期直前に変更や追加を要望した り，遅延したスケジュールを前提として自己の作業を進めたりしたからといって，ユーザ において，納期の延長を積極的に承諾する意思があったものと認めることはできない。 ©Copyright Masahiro Ito All Rights Reserved 51
- 52. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 ユーザも責任を負う場合がある。 前掲東京地裁平成16年判決の続き 1. オーダーメイドの開発では，受託者のみではシステムを完成させることは できない。 2. ユーザが開発過程において内部の意見調整を行うなど，役割を分担する ことが必要である。 3. ユーザは，ベンダから必要な協力を求められた場合，これに応じて必要な 協力を行うべき義務（これを「協力義務」という。）を負っている。 ベンダ 共同作業 ユーザ ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾄ義務 協力義務 • ユーザの意思決定支援 • 資料の提供その他ベン • 開発対象の制御 etc ダに対する協力 etc ©Copyright Masahiro Ito All Rights Reserved 52
- 53. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 要件を決める責任はユーザにある 東京地裁平成22年7月22日判決より ソフトウェアの開発は，注文者側と請負人側との間で開発すべきソフトウェアの性能， 仕様，形態等に関する具体的なイメージを共有するため，注文者側の技術担当者と請 負人側の技術担当者との間に密接な協力関係があることが必要不可欠であるところ， 特に，開発の出発点である要件定義を確定する工程については，注文者の要求をまと める工程であると定義されるとおり，注文者側の意向によってその内容が決せられるこ とになるのであるから，注文者側がどのような内容のソフトウェアの開発を望んでいる かを提示又は説明する責任は，注文者側にそのような能力がないことが前提になって いるなどの事情がない限り，注文者側にあるというべきである。 • 要件定義工程では，要件を決める責任は原則としてユーザにある ©Copyright Masahiro Ito All Rights Reserved 53
- 54. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 要件を拡大させた場合，当初の契約金額で開発せよと 要求することはできない （つづき） 一般に，要件定義が定まらない時点で締結されるシステム開発に係る契約については， 開発規模それ自体の大きさなどを想定して契約金額が決められるのであるが，契約当 事者間において開発内容を具体化していくその後の打合せにおいて，備えるべき新た な機能の追加など，当初の契約段階で客観的に想定されていた開発規模を超える内 容のシステム構築を注文者が求めたような場合には，契約当事者の合意の基礎となっ た事情に変更が生じているのであるから，注文者は，上記内容のシステム開発を当初 の契約金額の範囲で受注者に対して製作することを求めることはできないものと解す べきである。 • 契約段階で想定されていない要件が出された場合，契約金額の範囲で 開発を求めることはできない ©Copyright Masahiro Ito All Rights Reserved 54
- 55. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 追加費用請求，納期延長の提案を拒んだからと言って 直ちに協力義務違反というわけでもない （前掲スルガvsIBM事件） ユーザは、本件最終合意書で定められたユーザの支払金額には相応の根拠があると 信頼していたものであり、また、旧ＢＲＤ及び新ＢＲＤが行われた経緯の中で、ベンダは、 ユーザに対し、本件最終合意書の内容は両者間の合意であり、これを実現する方向で 開発を進めるなどと述べ、本件最終合意書の内容を尊重する姿勢を表明していたので あって、これによれば、ユーザが、平成１８年１２月に被告から追加費用の負担につい ての申出を受けた際、ユーザの対応に不信感を抱いたとしても不思議なことではなく、 また、ユーザの支払金額の増額については、ベンダ側から増額の根拠について十分な 理由が提示されない限り、これに応ずる必要はないと考えることにも合理的な理由が あるというべきである。 • 追加請求に応じなかったことについて，情報提供，交渉経緯に照らして， ユーザ側の協力義務違反を認めなかった ©Copyright Masahiro Ito All Rights Reserved 55
- 56. 1 2 3 4 5 6 3.3. 未完成の責任はどちらにあるか（争点②） 1 2 3 4 5 判例で示された義務の履行を確実に行ったということを示すエビ デンスを残す。 ユーザの立場から ベンダの立場から • ベンダが提示した課題，未決事項に • 契約で，未解決事項，仕様変更の取 対し，適時に対応できないときは，そ 扱いについて定める の理由と期限の変更を伝えて，記録 • 課題を適時に提示し，期限管理を する 行ったこと（課題管理シート），決定を • 提示された仕様に納得いかないとき 促したこと（議事録）を記録し，双方で は，具体的理由を付した書面により 共有する 修正を求める • スケジュール，スコープの変更申し出 は適時に行い，変更があった場合に は，合意があったことを記録する ©Copyright Masahiro Ito All Rights Reserved 56
- 57. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 プロジェクトマネジメント義務を尽くした（違反した）ことの 立証は非常に困難 – 義務内容が不明確なので立証命題が特定しづらい – 「各場面で必要適切な対応をする義務」だとすると，事実の 時間的範囲は広範囲になる – 開発プロジェクトでは多数の人間が関与し，膨大な資料が 作成される（全部提出しても弁護士・裁判官は読めない） – 開発プロジェクトのときから，２，３年たった後に義務履行の 立証を求められる プロジェクト推進中から，将来の紛争に 備えた記録の作成・保存が求められる ©Copyright Masahiro Ito All Rights Reserved 57
- 58. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 制度的に確立された証拠（建築確認申請書類，カルテ 等）がない 証拠の種類 – 契約書，提案書 – 記名・押印等のあるレター 訴 訟 – 紛争発生後の内容証明郵便等 に – 用語辞典，技術辞典などの公刊物等 お け – 議事録 る – 課題管理票，仕様変更一覧等の管理票 証 明 – メール（内部・相手方に提示されたもの） 力 – 設計書，仕様書 – 証言，陳述書 ©Copyright Masahiro Ito All Rights Reserved 58
- 59. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 スルガvsIBM事件の証拠(*)の例 （「次世代金融サービスシステムのご紹介」と題する提案書） 「次世代金融サービスシステム」の目標である「顧客中心」の商品・サービスを「プロダ クトビルド」（自由設計）できる機能を実現するためには、先行している欧米のパッケー ジの有効活用が優位である。 「短期間でパッケージを構築するには、ゼロからの開発ではなく実績のあるパッケージ を有効活用して開発する方が優位である。」 （「ステアリング・コミッティの議事録」におけるG専務（IBM)の発言） 「Ｃｏｒｅｂａｎｋがどこまでできるのか、これまでＩＢＭは分かっていなかった。ＢＲＤにより 肌で感じることができた。」 （IBM作成による平成１８年１２月１１日付け書面） 本件プロジェクトのコストが増大した理由の一つとして、IBMによる「Ｃｏｒｅｂａｎｋの成熟 度の見誤り」 (*)スルガvsIBM事件では，証拠の閲覧制限のため，証拠そのものは閲覧できない。判決文に引用された限度での例示にとどまる。 ©Copyright Masahiro Ito All Rights Reserved 59
- 60. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 証拠の例―IBMのプロジェクト管理義務履行に関し （IBM社長作成の１９年６月２５日付け書簡） 本件プロジェクト中断の原因として、「プロジェクト開始時において、Ｃｏｒｅｂａｎｋの機能 の充足度や開発手法の検証が不十分であった」、「プロジェクトの初期の段階で開発手 法の選択を誤った」 （ステアリング・コミッティの議事録） Ｄ専務（スルガ）が、期限は守られるのか、費用は予算内に収まるのか、日本の銀行の 標準機能として持つべき機能は実現されるのかという３点につき、当初の計画どおり対 応してほしいと述べたのに対し、（IBMは）異議を唱えなかった （プロジェクト進捗会議の議事録） スルガが現在のＢＲＤの方向性はこれでよいのか、当初の目的としては工数削減が あったと思うが、現時点での検討結果を見ると、より良いものを開発することで工数が 増えていると思われる旨質問したのに対し、横展開の観点から、追加費用及びスルガ 側工数増加は発生しないため問題はない旨答えた ©Copyright Masahiro Ito All Rights Reserved 60
- 61. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 証拠の例―スルガの協力義務履行に関し （ステアリングコミッティの議事録―平成17年4月8日）におけるIBM発言 ＢＰＲについてはこれで終わりということではなく一つのチェックポイントとして考えてい る。検討着手した時点では見えないところもあり、どうかと思うところもあったが、こう やって具体的な数値（削減商品数やグループ数）を出すことができた。スルガの担当者 の方には負担をかけ、ありがとうございました。 （ステアリングコミッティの議事録―平成18年8月9日）におけるIBM発言 パッケージに合わせることについては、スルガの協力に感謝する。無駄を省くことがで きた。 （帳票数の推移） 本件最終合意書が交わされた時点での帳票数は４６１７個であったところ、その後の経 過を見ると、原告は、平成１８年８月３１日までに帳票数の削減を行い、バッチ帳票が４ １７１個（うち重複帳票２６３５個）となったこと ©Copyright Masahiro Ito All Rights Reserved 61
- 62. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 証拠の例 平成18年12月11日（IBM作成の「新経営システム」構築プロジェクトの今後の進め方に 関するご相談」） ａ 本件最終合意書での計画が継続できなくなり、ＢＲＤを実施しなくてはならなく なった理由について、〈１〉パッケージ・ベース・アプローチが徹底されておらず、現行機 能からの積み上げで要件定義を行ったため、パッケージ機能に整合しない仕様になっ ている可能性があり実装段階でその不整合が顕在化するリスクが認識されたこと、ま た、パッケージ機能及びメリットを十分に享受できないシステムとなる可能性が生じた こと、〈２〉システム化対象範囲が基幹系だけでなく極めて多くのコンポーネントに及び、 かつ一括リリースとなっていたため、安全かつ確実なサービスインへ向けて多大なリス クが認識されたことが挙げられた。（略） ｃ 今後原告に追加で発生する総費用は、全スコープを実現する場合には、被告に 対する支払費用１２７億円、それ以外に掛かる費用（サービスイン延期に伴う費用）約３ ８億円を合計した約１６５億円である。（略） ｄ 今回提案したスコープで本件プロジェクトを実施することを承認していただきたい。 ｅ 被告に対する追加費用として約３４億円、残存及び追加ハードウェア、ソフトウェ ア費用（約１９億円。サービスイン後５年間と想定したもの。）を平成１９年１月中旬をメ ドに契約していただきたい。 ©Copyright Masahiro Ito All Rights Reserved 62
- 63. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 証拠の例 平成19年6月1日（スルガ・IBM役員打ち合わせ） Ｄ専務が、「Ｃｏｒｅｂａｎｋのことを分からず進めてきたことが誤りですよね」と質問したとこ ろ、Ｇ専務は、「全部理解はしていました。ただ、日本の銀行の諸制度に合致させること が難しかったのは事実です。現実解としてパフォーマンスの問題が出ることが分かりま した。もちろん最初からは分かっていませんでした。世の中が変わったため、難しくなっ てしまったのです。」と答えた。 Ｄ専務が「どちらに責任があったのでしょうか。当社が悪かったのでしょうか。」と尋ねた ところ、Ｇ専務は、「このような状況に陥った責任は感じています。」と返答した。また、 Ｇ専務は、勘定系はＣｏｒｅｂａｎｋでは難しいのは事実ですと述べた。 Ｄ専務が、「コアバンクは選択ミスだったのですか。」と質問したところ、Ｇ専務は、「結果 としてそうなってしまいました。システムの真ん中はそうなってしまいましたが、周辺は 生かしたいと思います。」と返答した。これに対し、Ｄ専務が「それでは、途中でなぜ分 からなかったのですか。ＢＲＤのとき、何で提案してくださらなかったのですか。Ｃｏｒｅｂａ ｎｋに問題があると言ったのはＧさんですよ。」と質したところ、Ｇ専務は、「そのとおりで す。自分でチェックはできませんでした。技術側から何とかなるだろうと言われ、ＢＲＤ を進めました。真実は話したとおりです。勘定系はだめでした。」と述べた。 ©Copyright Masahiro Ito All Rights Reserved 63
- 64. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 議事録 – プロジェクト中の義務履行（懈怠）を示す最重要ツール。 – 「打合せ議事録やメールは，仕様変更がされた経緯，開発工程の遅延 原因を探る証拠としても重要」by裁判官 – 会議体の位置づけを明確にする（契約書に定められた「連絡協議会」な のかetc）。 – 相手方の確認・閲覧の記録も残す。 – プロジェクト固有の方言ばかりでは，第三者が読んで理解できない。第 三者（裁判官）が読んでもわかるように。 – 不本意な内容が書かれた場合でも，事実と異なるときは，修正を求める （たとえ修正されなかったとしても意味はある）。 – 依頼・要望なのか，合意なのか，事実の確認なのか。 – 宿題については期限を定め，その履行結果も残す。 – 将来「事実と違う」という主張が出される場合に備え，録音する。 ©Copyright Masahiro Ito All Rights Reserved 64
- 65. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 課題管理・仕様変更管理票 – 「プロジェクトマネジメント義務」「協力義務」履行（懈怠）の実 態を立証する有効なツール。 – 件数，工数など定量的に評価しやすいため，全体をつかみ やすい。 – 文書の位置づけは，契約書あるいは下位文書としての「プロ ジェクト管理規程」などにおいて定めておく。 – 起票，期限，終了日，責任者などを記録する。 – 決定・対応を促したこと，事情により期限までに対応できな いこと事情も，管理票または議事録に記録する。 ©Copyright Masahiro Ito All Rights Reserved 65
- 66. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 報告書・通知書 – ユーザからベンダに対し「遅延（あるいは悪品質）の程度， 原因（責任の所在）と改善策」を示した書面の提出を求めら れることがある – 責任者名義で，自己に不利益な事実を認める内容を含む書 面は，重要な証拠となる – （書きたくないけど書かなければならないとき） • 提出を求められた経緯を書面，メールで残す • （求められた内容と一致しなくとも）自己の見解を記した書面を提出 する • 再提出したことになったとしても，第一版の記録は残る ©Copyright Masahiro Ito All Rights Reserved 66
- 67. 1 2 3 4 5 6 3.4.義務履行の立証 1 2 3 4 5 報告書の例 プロジェクト遅延に関する報告 このたびは，新○○システムの開発において，貴社にご迷惑をおか けし，大変申し訳ありません。表題の件につきまして，弊社の見解を 報告いたします。 ここまで書いて しまうと，後のリ 1 状況 カバーはかなり 平成24年11月末時点で，単体テスト80%完了，結合テスト40% 厳しい。 完了しているべきところ，11月末時点において，プログラミング 80%完了，単体テスト40%完了，結合テスト進捗ゼロという状況 にあります。期間にして1.5か月の遅れが生じています。 2 原因 想定していた難易度よりも高かったこと，キーパーソンの体調不 良により離脱したこと，増加した要員のスキル不足によりコミュ ニケーション不足が生じたこと，PMのスキルが高くなかったこと が挙げられます。 3 対策 Aツールに熟練したSEを追加投入し，担当役員がPMに加わる ことにより，プロジェクト体制を強化します・・・ ©Copyright Masahiro Ito All Rights Reserved 67
- 68. 1 2 3 4 5 6 3.5.工数・機能増加分の請求可否/ケース③ 1 2 3 4 5 ベンダは追加費用を請求できるだろうか 製品グループＸのための受発注システム開発を受注したA社は， 基本設計の結果，120機能の開発を行うとし，Ｂ社に承認された。 途中で，B社は，製品グループＹについてもスコープに含めるよう 要求してきたが，Ａ社は，おおむね機能は共通すると判断し，特 に異議を出さず，契約書の修正も行わなかった。 いつのまにか，開発ボリュームは，180機能ほどになり，稼働時 期も4か月延長された。しかし，増えた60機能は，純粋に製品グ ループＹによるものでもない。 開発ボリュームが1.5倍になったの で，追加で50%支払ってください。 ©Copyright Masahiro Ito All Rights Reserved 68
- 69. 1 2 3 4 5 6 3.5. 工数・機能増加分の請求可否 1 2 3 4 5 次のような場合に追加請求が認められやすい もともとの受託範囲が明 • 追加分と，そうでない部分が明瞭に区別さ 確であること れないと追加請求の前提を欠く もともとの金額算定の根 • 「大変だった」というだけでは金額算定がで 拠が明確であること きない • 契約の成立の際の議論と同様に，有償作 業であることの認識・認容が求められる ユーザ側にも追加・変更 • 「認識・認容」の立証は困難なので，契約上 の認識があること に変更フロー・手続を定め，それを履践す る ©Copyright Masahiro Ito All Rights Reserved 69
- 70. 1 2 3 4 5 6 3.5. 工数・機能増加分の請求可否 1 2 3 4 5 –追加請求認容例（東京地裁平成17年4月22日判決） ① プログラム数が当初の182本から414本まで増加し，分割して検収も行われ た（当初の範囲と，追加の範囲が区別されやすい） ② 当初想定されていた現行オフコン業務だけでなく，個別の出版社対応業務 が追加された ③ 見積書には，機能追加等により工数に大幅な変動が生じたときは別途相談 させていただくとの記述があった – 否定例（東京地裁平成7年6月12日） ① ヒアリングベースで3.5万ステップ，35-40人月と見積もられて約2800万円と された ② 実際には10万ステップを超えたことから約1.4億円を請求した 裁判所は「専門的知識、能力を有するベンダとしては、契約を締結前にシステ ムの内容を理解し、それを前提として受託業務の規模を判断し、見積額を算定 することが可能だった」とし，金額も工数をベースに算定されたものではないとし た ©Copyright Masahiro Ito All Rights Reserved 70
- 71. 1 2 3 4 5 6 3.5. 工数・機能増加分の請求可否 1 2 3 4 5 （参考）その他の追加請求に関する裁判例 – 見積に基づいて発注がなされた以上，工数超過しても請求 が認められないとした事例（東京地判平24.4.25） – 追加報酬支払の合意を否定した事例（東京地判平23.6.3） – 機能数の増大は認めたが，当初金額を大幅に超える追加 支払いの合意を否定し，実績工数からの出来高について当 初見積額を勘案して請求を一部認めた事例（東京地判平 23.4.27） – 明確な合意はないが，商512条に基づいて経過期間分の報 酬を認めた例（東京地判平22.1.22，東京地判平15.5.8） ©Copyright Masahiro Ito All Rights Reserved 71
- 72. 1 2 3 4 5 6 3.5. 工数・機能増加分の請求可否 1 2 3 4 5 「仕様変更・報酬変更」を契約書レベルでルール化することと，開 発開始時点の仕様・報酬算定根拠を明確化しておく ユーザの立場から ベンダの立場から • 何でも押し込むという姿勢は避ける • 契約で，仕様変更の取扱いについて 定める • 工数ベースで発注しない • その手続きに乗らない（有償の）変 • プログラム本数，機能数などは，開発 更・追加作業は行わない（現場にも徹 の方法によっていくらでも分割・統合 底させる） できるため，報酬算出の基礎とするこ とは避けるべき • 追加要望はベンダ側にもコントロール する義務があることに留意 ©Copyright Masahiro Ito All Rights Reserved 72
- 73. 1 2 3 4 5 6 3.5. 工数・機能増加分の請求可否 1 2 3 4 5 変更の条件を契約中に定め，それに沿って運用する。 業務委託契約で見られる条文案 第●条（抄） 1. 本契約の内容は、甲乙双方記名捺印した書面によってのみ変更することが できる。 2. 次の各号の一に該当する事態が生じた場合、乙は甲に対し、成果物の納 入期限及び委託料の変更を請求することができる。その場合、甲及び乙は、 納入期限及び委託料の変更に関して協議の上定める。 ① 甲の指示、仕様又は設計その他の変更又は追加等 ② 以下略 3. 万一前項に基づく納入期限又は委託料の変更について協議が整わない場 合、乙は、本契約又は個別契約の全部又は一部を解除することができるも のとし、甲に対し、それまでに要した費用及び本業務の報酬等、その進捗 の度合いに応じた委託料相当額の償還を求めることができる。 実務レベルでは，より詳細な決定フローについて合意しおくべき ©Copyright Masahiro Ito All Rights Reserved 73
- 74. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 74
- 75. 1 2 3 4 5 6 4.1. ケース④ 1 2 3 4 5 ユーザは代金を支払わなければならないか。 ベンダA社が開発したシステムは，十分な検収手続を経ないま まB社による検収確認書が交付され，本番稼働が開始された。 その直後から，現場から凄まじいクレームが来て，取り急ぎ旧シ ステムに戻す作業が行われた。 トラブルの要点は，①レスポンスが悪く，受注業務に耐えられな いこと，②従来のシステムにできたことができなくなっていること 受注1件登録するのに3分もかか るのでは話にならない。 チューニングはしますが，慣れの 問題もあります。パフォーマンス検 ユーザ 証の結果は良好です。 ベンダ ©Copyright Masahiro Ito All Rights Reserved 75
- 76. 1 2 3 4 5 6 4.1. ケース④ 1 2 3 4 5 システムの完成を前提に，契約解除しうるだけの瑕疵と いえるか（争点③）が問題となる。 争点① 争点③ No システムは Yes 重大な瑕疵が 契約解除は 完成したか あるか できない No Yes cf. 「仕事の目的物に瑕疵があるときは，注 争点② 文者はその瑕疵の修補を請求することがで きる。」（民法634条1項条）。 ベンダに Yes ユーザの 「仕事の目的物に瑕疵があり，そのために契 債務不履行があったか 損害額の判断 約をした目的を達することができないときは， 契約の解除をすることができる」（民法635 条）。 No 民法641条の 検討 ©Copyright Masahiro Ito All Rights Reserved 76
- 77. 1 2 3 4 5 6 4.2 契約を解除できる「瑕疵」とは 1 2 3 4 5 システムにおける「瑕疵」とは何か。 東京地裁平成9年2月18日判決より いわゆるオーダーメイドのコンピューターソフトのプログラムで（略）プログラムにバグが 生じることは避けられず，その中には，通常の開発体制におけるチェックでは補修しき れず，検収後システムを本稼働させる中で初めて発現するバグもあり得るのである。 （略）顧客としては，（略）構築しようとするシステムの規模及び内容によっては，一定の バグの混入も承知してかからなければならないものといえる。 プログラムにいわゆるバグがあることが発見された場合においても，プログラム納入者 が不具合発生の指摘を受けた後，遅滞なく補修を終え，又はユーザーとの協議の上相 当と認める代替措置を講じたときは，右バグの存在をもってプログラムの欠陥（瑕疵）と 評価することはできないものというべきである。 「遅滞なく補修できない」and「代替措置が講じられな い」ものが「瑕疵」にあたる ©Copyright Masahiro Ito All Rights Reserved 77
- 78. 1 2 3 4 5 6 4.2 契約を解除できる「瑕疵」とは 1 2 3 4 5 解除が認められた例 解除が認められなかった例 在庫照会の検索処理に30分以上の 証明書類の発行不具合 時間を要する。 学生個人情報の漏えい システム内容を変更した後の朝は，起 （東京地裁平成22年1月22日判決― 動に数十分の時間を要する。 瑕疵として認められたものもある） （東京地裁平成14年4月22日判決） 商品コードの桁が多く，使い勝手が悪 300件の在庫引当に44分以上の時間 い。 を要する。 伝票が一画面で確認できない。 一括在庫引当中には，他の商品マス タを使用する処理ができない。 数値入力が煩雑。 （東京地裁平成16年12月22日判決） （前掲東京地裁八王子支部判決） ©Copyright Masahiro Ito All Rights Reserved 78
- 79. 1 2 3 4 5 6 4.2 契約を解除できる「瑕疵」とは 1 2 3 4 5 パフォーマンス値の合意がない場合。 前掲東京地裁平成16年判決より コンピュータ処理を導入する以上は大幅な時間短縮を期待するのが通常であ り、従来の手作業と時間的に変わらないようなシステムをわざわざ数千万円も の多額の費用を投じて開発するとはおよそ考え難い。 したがって、本件システムにおける一括在庫引当処理の時間に関しては、当事 者間に処理時間の長さにつき明示の合意がないとしても、同程度のシステム に通常要求される内容に適合せず、他方で、前記したような処理時間を許容す るような合意を認めることもできないのであるから、瑕疵に該当するというほか ない。 明確な合意がなくとも，常識レベルに達していなけれ ば瑕疵になりうる ©Copyright Masahiro Ito All Rights Reserved 79
- 80. 1 2 3 4 5 6 4.2 契約を解除できる「瑕疵」とは 1 2 3 4 5 バグ検知・修正の責任は原則としてベンダにある。 前掲東京地裁平成16年判決より システム開発におけるバグの除去は、あくまで第一次的には請負人の責任で あり、当該システムの納入後、定められた期間内ないし一定の相当期間内に、 当該システムが実用に耐えうる程度にまでなされるべきであり、注文者の指示 による仕様の変更等であればともかくとして、少なくとも通常のシステムにおい て存在することが許されないような不具合については、注文者の指摘を待つま でもなく、請負人が当然に自ら是正すべきであり、注文者が当該システムに対 する不具合を具体的に指摘できない限り、当該不具合が注文者の責任によっ て生じたものとして解除を制限することは許されないというべきである。 言われなかったから直してない，という論理は通用しない ©Copyright Masahiro Ito All Rights Reserved 80
- 81. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 81
- 82. 1 2 3 4 5 6 5.1. ケース⑤ 1 2 3 4 5 ベンダが支払うべき金額は？ 要件定義，基本設計までは順調に進捗し，B社からA社に，2 フェーズ分として，8000万円が支払われた。 しかし，開発フェーズで，A社はシステムを完成させることができ ず，納期延期を繰り返したが，最終的にB社から解除された。 開発フェーズの代金は払えないの は当然として，前フェーズで支払っ た8千万円も返してもらう。 前フェーズ分については検収も終 わっています。実質的にも，今後 ユーザ も再利用可能です。 ベンダ ©Copyright Masahiro Ito All Rights Reserved 82
- 83. 1 2 3 4 5 6 5.1. 契約解除の効果 1 2 3 4 5 問題の所在 要件定義 基本設計 開発 A契約 B契約 C契約 – 前工程A,B契約と，後工程C契約は別の契約 – C契約には債務不履行があるが，A,B契約においては債務 不履行がない – C契約の損害賠償条項には契約金額を上限とする定めが あるから，C契約を解除するだけでは支払済みのA,B契約 代金を取り戻せない – C契約の債務不履行を理由として，C契約だけでなく，A,B契 約も解除できるか ©Copyright Masahiro Ito All Rights Reserved 83
- 84. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 多くの契約では，責任限定条項がある 第○条（損害賠償） 「直接」「現実」「通常」の損害に限定。 「間接」「逸失」「特別」の損害は含まれな 1. 本契約に違反して，相手方に い。 損害を与えたときは，直接か つ現実に生じた通常損害に 違反行為が複数あった場合，その損害 限り，賠償する責を負う。 額の累計額が制限される。 2. ただし，前項の損害の累計額 は，当該行為の原因となった 当該個別契約で実際に支払われた額を 個別契約に基づいて甲から 返還することで足りる。 乙に対して支払われた委託 料の額を上限とする。 支払い前ではそもそも賠償請求 できないか？ ©Copyright Masahiro Ito All Rights Reserved 84
- 85. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 検収済みの契約も解除できるか。 最高裁平成8年11月12日判決より 同一当事者間の債権債務関係がその形式は甲契約及び乙契約といった二個 以上の契約から成る場合であっても、それらの目的とするところが相互に密接 に関連付けられていて、社会通念上、甲契約又は乙契約のいずれかが履行さ れるだけでは契約を締結した目的が全体としては達成されないと認められる場 合には、甲契約上の債務の不履行を理由に、その債権者が法定解除権の行 使として甲契約と併せて乙契約をも解除することができるものと解する。 スポーツ施設の利用を目的とするリゾートマンションにおいて，プー ル完成遅延を理由にスポーツ施設利用契約（甲契約）を解除した 場合，マンション売買契約（乙契約）も解除できるとした 開発契約の解除により，先行するフェーズの契約の解 除が認められるか ©Copyright Masahiro Ito All Rights Reserved 85
- 86. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 請負契約の解除とともにサーバ売買契約も解除したケ ース。 東京地裁平成18年6月30日判決より 本件契約（注：開発基本契約）は、（略）ウインドウズサーバーによるデータベースの開 発を前提にしており、そのことからこれまでの使用していたマッキントッシュサーバーか らウインドウズサーバーに変更することを前提として、Ｘはウインドウズ用の本件サー バーを購入したのであって、本件データベースの開発がなければ本件サーバーを購入 していない関係にあるといえる。 （中略） このように本件サーバーにかかる売買契約は本件契約と一体であり、本件契約の解除 事由は当然に本件サーバーの購入にかかる売買契約の解除事由に該当するものとい うべきである。 請負＋売買のケースで，双方の解除を認めたケース ©Copyright Masahiro Ito All Rights Reserved 86
- 87. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 不法行為に基づく損害賠償を認めたケース。 前掲東京地裁平成24年3月スルガvsIBM判決より ＜事実関係＞平成17年9月30日にユーザ・ベンダ間で「最終合意書」と題する書面が交 わされ，それぞれの個別契約が締結されていった。 • ベンダに支払う金額の総額は約90億円 • 個別契約が締結されるまでは本合意書によって何ら法的拘束力を受けない • 損害賠償 契約責任・不法行為等の請求原因を問わず現実・通常・直接損害のみとし，個 別契約代金相当額を限度額とする 故意または重過失が認められるときは支払済み累計額相当額とする 前述の例のように，（ユーザにとって）厳しい責任限定が 付せられていた ©Copyright Masahiro Ito All Rights Reserved 87
- 88. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 (承前) ベンダの「プロジェクトマネジメント義務違反」を認めたうえで，不法行為に基づ く損害賠償義務を認めた。 • 個別契約に基づいて支払った額の合計約49億円（一部は控除） • 資産の額として支払った額の合計約17億円 • ベンダ以外の者に支払った額のうち現に利用している額を除いた額の合計約8.6億 円 • （逸失利益）約42億円については認めなかった • ベンダからの損益相殺（成果物の客観的価値相当分の減額）については認められな かった 個別契約について逐一「債務不履行」を認定することな く，「不法行為」責任を認めた。 支払済の額を超えて認めたわけではないため，減責条 項にも抵触しない。 ©Copyright Masahiro Ito All Rights Reserved 88
- 89. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 一つの契約の中間検収に基づいて支払われた代金も 損害として認められたケース。 東京地裁平成22年5月21日判決より (2500万円の請負開発のうち，中間検収で800万円が支払われていた)。 上記システムは，Ｘが中間金の支払を得る関係からもともとは１つであった本 件システムの一部を分割したものに過ぎない上，＜略＞（検収後に「発注・仕 入れ・在庫・移動関連仕様再検討」という作業があったことなどから）Ｙによる解 除時点においても，発注・店舗在庫管理システムが未完成であったと推認され るところでもあるから，形式的に検収が済まされていたとしても，Ｙによる解除 の効果は発注・店舗在庫管理システムについても及ぶことになる。 実質的には未完成であったこともうかがわれ，便宜的に 分割したような場合には，解除の効果は全体に及ぶ ©Copyright Masahiro Ito All Rights Reserved 89
- 90. 1 2 3 4 5 6 5.2. 契約解除の効果 1 2 3 4 5 基本契約とともにフェーズごとに個別契約を締結し，こ まめに回収し，リスクヘッジを図るという手法は必ずしも 通用しない。 後続の乙契約での債務不履行を理由に，甲契約も解除 できるかどうかは，事案に依存する 甲契約，乙契約が不可分一体の契約であることは，書 面上明確にしておきたい いわゆる「基本契約書」はベンダが総額・期間を含めて 開発についてコミットすることを約する書面ではない ©Copyright Masahiro Ito All Rights Reserved 90
- 91. 1 2 3 4 5 6 5.3. 基本合意書 1 2 3 4 5 「基本合意書」の取り交わしが望ましい。 基本合意書（例・骨子） ベンダの提案書の内 1. ユーザは，ベンダによる別紙提案書の内容を 評価した結果，ベンダを次世代基幹系システム 容を中心に盛り込む。 （本件システム）の開発を委託する主たる業者 に指名する。 2. 本件システムの範囲は・・とする。 スコープが拡大した 場合には追加請求の 3. 本件システムの開発費総額は，○億円とする。 根拠になり得る ベンダは，これを変更する必要があると認める ときは，合理的な説明をしなければならない。 4. 本件システムの稼働時期は，○年○月とする。 全体金額等に法的拘 ベンダは，これに延期する必要があると認める 束力が生じるかは， ときは，合理的な説明をしなければならない。 書きぶりに依存する。 ©Copyright Masahiro Ito All Rights Reserved 91
- 92. 1 2 3 4 5 6 5.3. 基本合意書 1 2 3 4 5 「基本合意書」の意義。 前掲スルガvsIBM事件判決より （最終合意書に記載の総額約90億円という記載等について，法的拘束力を有 するものではないとしたものの・・） 上記支払総額の規定が設けられたのは両当事者が目標とする重要な指針を 定める趣旨であることは疑いのないところであり、本件最終合意書が交わされ た平成１７年９月３０日の時点において、ベンダは、本件システム開発のコスト 見積りの前提となる基礎数値を確定させてユーザの支払金額を決めたもので あることなどからすれば、上記支払総額の規定された本件最終合意書が交わ されたとの事情が、ベンダの信義則上ないし不法行為上の義務違反の有無を 考慮するに当たり意味を有し得るものであることを否定するものではない。 具体的な効果については触れていないが，結果（多額の賠 償額認容）に大きな影響を及ぼしたものと思われる ©Copyright Masahiro Ito All Rights Reserved 92
- 93. 1 2 3 4 5 6 5.3. 基本合意書 1 2 3 4 5 基本合意書をめぐる留意事項 – 多段階契約で進める場合には，ユーザ・ベンダ間における 全体的・基本的な合意事項を確認するために必要 – 法的拘束力の有無・程度や，記載内容は，当事者間の交 渉，プロジェクトの成熟度に応じて変わり得る – プロジェクトの進捗に応じて，全体予算，スケジュールの確 度も上がることから，適宜アップデートが望ましい – スルガvsIBM事件にて大きな影響を与えたのは，要件定 義を約1年実施した後の「最終合意書」であること（確度の 高い段階での合意には意味がある） – ユーザの要望によりスコープが拡大する場合には，追加 請求の根拠となり得る ©Copyright Masahiro Ito All Rights Reserved 93
- 94. 1 2 3 4 5 6 5.4. 損害賠償の範囲/ケース⑥ 1 2 3 4 5 ベンダはユーザの人件費も賠償すべきか？ A社はシステムを完成させることができず，納期延期を繰り返し たが，最終的にB社から解除された。 8カ月のプロジェクトが無駄になっ た。当社従業員の賃金相当額を 支払ってもらう。 代金はまだ支払われていません。 人件費はどのみちかかっていたの ユーザ ですから，賠償対象外です。 ベンダ ©Copyright Masahiro Ito All Rights Reserved 94
- 95. 1 2 3 4 5 6 5.4.損害賠償の範囲 1 2 3 4 5 社員の人件費が損害として認められる可能性は低い – 発注者の作業には，瑕疵の対応と，本来行うべき運用管 理の作業とが含まれており，いずれが瑕疵によって生じた 損害なのかは区別できない（東京地判平成22年1月22日判決） – 社内人件費は，雇用している限り必然的に支出すべき経 費であり，これらの社員が他の業務に従事することにより 具体的に利益が得られた等の特段の事情がない限り損害 とは認められない（東京地判平成16年12月22日判決） 逸失利益・機会損失等も認められにくい – 予定どおり完成させられるか，完成させていたとして主張 するような利益を上げられたかは不確定（前掲スルガIBM判決） – 契約を解除した以上，完成義務を前提とする改修費用は 損害に当たらない（東京地判平成22年9月21日判決） ©Copyright Masahiro Ito All Rights Reserved 95
- 96. 1 2 3 4 5 6 本日の進行 １ システム開発を巡る紛争の概要 ２ プロジェクト開始直後に頓挫したケース ３ システム完成が遅延あるいは中断したケース ４ システムの不具合を巡るケース ５ システム開発紛争における損害論 ６ システム開発紛争の解決手続 ©Copyright Masahiro Ito All Rights Reserved 96
- 97. 1 2 3 4 5 6 6.1. 紛争の発生と専門家の関与 1 2 3 4 5 修復不能な段階では，証拠作成の最後のチャンス – 訴訟になった後に作成した証拠（陳述書等）は万能ではな い – 証拠づくり（相手方に対する要望，自己の立場・正当性の 主張書面など）ができる最後のチャンス – 契約上求められている手続の確実な履践（検収不合格通 知，履行の催告，解除通知等） ©Copyright Masahiro Ito All Rights Reserved 97
- 98. 1 2 3 4 5 6 6.1. 紛争の発生と専門家の関与 1 2 3 4 5 専門家に相談するときに用意したいもの – 初回相談 • 相手方との接点発生から現在までの経緯をまとめたもの – それぞれの書面（証拠）とのリファレンスが取れると望ましい • RFP，提案書，契約書，納品書等 • システムの全体構成，スケジュール，体制等がわかるもの – 追々用意したいもの • 会議体ごとの議事録（時系列） • 課題管理票，仕様変更管理票 • 重要なやり取りが行われたメール – 作成を検討したいもの • 納品物の確定日付取得 • 事実実験公正証書 ©Copyright Masahiro Ito All Rights Reserved 98
- 99. 1 2 3 4 5 6 6.1. 紛争の発生と専門家の関与 1 2 3 4 5 第三者を交えた解決は総力戦 ベンダ（請負人） ユーザ（発注者） 多くはシステム・ 業界の素人 開発 システム 経営者 法務 弁護士 弁護士 法務 経営者 営業 ユーザ 当事者からの距離が遠 技術・ユーザ業務を く，事実・主張を伝える 裁判所/仲裁人 理解する必要あり のが困難 ©Copyright Masahiro Ito All Rights Reserved 99
- 100. 1 2 3 4 5 6 6.1. 紛争の発生と専門家の関与 1 2 3 4 5 多様な手続がある 厳 訴訟 柔 格 軟 性 法的拘束力 司法 弱 調停 強 調停案に応じなく 仲裁/ てもよい ADR 当事者 和解 柔 仲裁合意が必要 軟 ©Copyright Masahiro Ito All Rights Reserved 100
- 101. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 訴訟は時間がかかるか？ （東京地裁平成9年2月18日判決より） Ｘが指摘した本件システムの不具合は，多数個所に上るものであり（６０か所以上），こ れらについてＸはプログラムの欠陥によって生じる現象であると主張し，Ｚらはこれを 争っている。 （略）現実に本件システムを用いた業務が行われていないことから，本件システムを稼 働させた場合にどのような不具合が起こるかを裁判所が認定するには困難が伴い （略），審理の見通しを立てることが困難であった。 （略）平成４年８月２０日に提起され，平成８年１２月１７日に口頭弁論が終結されるま でに，３２回の口頭弁論期日が持たれたが（略），最後の２回を除く３０回の口頭弁論 期日は，争点に関する議論及び争点の整理にあてられたことになる。 特に平成６年４月２５日の第１３回口頭弁論期日以降，裁判所において次回までの目 標を定めた上で，裁判所外でＸをＺの代理人及び担当者が中心となって，本件システ ム稼働上の不具合の存否を当事者間で検証する作業が行われた。厳しく対立し，多 岐にわたっていた争点の整理のために，Ｘ，Ｙ，Ｚの三者が協働して裁判所外で右のよ うな検証作業を行ったことは，争点整理の方法として極めて異例である。 ©Copyright Masahiro Ito All Rights Reserved 101
- 102. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 続き （東京地裁平成9年2月18日判決より） この争点整理の経過については，裁判所の助言のもととはいえ，主張において厳しく 対立する当事者が協働して作業手順の協議をし，協働して問題点の検証作業を実施 し，その結果，右のような争点整理の結果が生まれたものであり，争点整理において 専門知識を必要とする事件に関する一つの先駆的試みといえよう。 右当事者間の本件検証実験及び原因解明作業は実質二年余りにわたって行われ， 特に，平成６年７月から８月までの二カ月にわたる作業は，裁判所が夏季休廷期間中 であるにもかかわらず，ＸとＺの代理人及び担当者が中心となって，夏季の休みも返 上して，連日，協議して行われたものであることを記しておきたい。 （略） その結果としての前記作業に基づく解明度は，極めて高いものであったといえる。 異例ともいえる判示があった ©Copyright Masahiro Ito All Rights Reserved 102
- 103. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 最近の裁判所の印象・特徴（東京地裁） – 裁判官が書いたシステム開発紛争に関する論考（判例タ イムズ1349号「ソフトウェア開発関係訴訟の手引」，同 1340号「ソフトウェア開発関連訴訟の審理」 – 同種事件の多数発生・提起 – 専門委員の積極的採用 – 調停の活用 裁判所の利点 – 判断の均質・ブレが出にくい，中立 巷にいわれているほど，「時間がかかる」「裁判官はわかっ ていない」というわけではない。 当事者（代理人）次第の面もある。 ©Copyright Masahiro Ito All Rights Reserved 103
- 104. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 短くて1年，3年かかることも通常。 スルガ H20.3 H24.3 現在 IBM 控訴中 事件 専門委員（元SIer等）が 関与することも多い 原 訴状 1～2カ月サイクル 控訴 提出 告 第1回 第2回 検証 証人 判決 弁論 弁論 尋問 被 答弁書 確定 提出 告 弁論準備手続や調停 瑕疵があるのか，完成 （いずれも非公開）に回 しているのかを裁判所 ることも多い の関与の元に確認する 反訴が提起される ことも多い ©Copyright Masahiro Ito All Rights Reserved 104
- 105. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 争点整理のための弁論準備手続のほか，（職権により） 調停に付されることも多い – 調停委員3名（裁判官，弁護士，専門家） – （東京地裁の場合）システム開発紛争を多く取り扱っている 調停委員に配転される – 訴訟における弁論準備手続より，積極的に争点・証拠の整 理が行われる傾向 – 和解による終了の確率は高い – 調停が成立しない場合には，より長期化する可能性 – 調停部での争点整理・心証が引き継がれない可能性 早期・合理的解決を図るには適している ©Copyright Masahiro Ito All Rights Reserved 105
- 106. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 技術的な争点があるときは専門委員が参画することがあ る – 多くはベンダ出身者 – 裁判所のアドバイザであって，鑑定等をするものではない – メリット • 鑑定と比べて簡易・迅速な判断 • 柔軟な対応が期待できる • 現場を知っていることにより，当事者も和解しやすい 人に依存するところが大きいが，事例は増えてきている ©Copyright Masahiro Ito All Rights Reserved 106
- 107. 1 2 3 4 5 6 6.2. 訴訟 1 2 3 4 5 システムの完成，瑕疵の存否が激しく争われるケースで は，検証が行われる – 裁判所の関与の下で，システムを動作させて動作検証する – 目的を明確にする必要がある • （例）システムテストのシナリオ達成率を確認するのか • （例）表示上の不具合，処理時間は業務上の使用に耐えうるものか – 紛争発生から一定期間経過しているため，環境の設定が困 難であり，不具合が再現させられないことも多い – 環境，データ，シナリオについて，裁判所（専門委員），ユー ザ，ベンダで合意するのに手間取る 目的が明らかでないと，徒労に終わる危険がある ©Copyright Masahiro Ito All Rights Reserved 107
- 108. 1 2 3 4 5 6 6.3. ADR 1 2 3 4 5 ADRの特徴 – インフォーマル，簡易・迅速 – 低コスト（早期に解決するため） – 非公開 – 専門家第三者の関与 – 実績は・・・？ ソフトウェア紛争に特化したADR機関 – SOFTIC （財)ソフトウェア情報センター – IT-ADRセンター ©Copyright Masahiro Ito All Rights Reserved 108
- 109. 1 2 3 4 5 6 6.4. 紛争に備えて・・ 1 2 3 4 5 早め早めの措置，専門家へのアクセスが予防・短期解 決につながる 1 2 3 4 契約書は，後に紛争になった場合の処理の基準になる。 1 想像力を働かせた契約書 よく想像力を働かせてつぶさにチェックする。 後になって「義務を履行していた」という証拠を残すことは 2 義務履行の記録保存 困難。リアルタイムに記録する。 相当程度紛争が成熟したら，専門家とも連携して事実を 3 訴訟を意識した行動 積み上げる（検収不合格通知の送付等）。 当事者の記憶は薄れ，記録は散逸しがち。代理人と連携 4 早めの証拠整理 し，早い段階から必要な記録の整理と人材を確保する。 ©Copyright Masahiro Ito All Rights Reserved 109
- 110. ありがとうございました 伊藤 雅浩 内田・鮫島法律事務所 http://www.uslf.jp/ ito@uslf.jp 本日提示した判例 がもう少し詳しく紹 介してあります。 IT判例メモ http://d.hatena.ne.jp/redips+law/ 誠ブログ http://blogs.bizmakoto.jp/mito/ IT業向け法律問題情報サイト http://www.it-houmu.com/ ©Copyright Masahiro Ito All Rights Reserved 110