1. システム開発契約における
システムイニシアティブの留意点
－各種裁判事例も交えて－
株式会社ＪＴＢ情報システム
常務取締役 経営企画部長
野々垣 典男
n_nonogaki@jss.jp
1

2. 略歴
１９８３年４月 株式会社日本交通公社（現ジェイティービー）入社
渉外営業部門及び経営企画
部門及び経営企画部門を担当
渉外営業部門及び経営企画部門を担当
１９９７年４月 同社 情報システム部マネージャー
１９９８年４月 株式会社ＪＴＢ情報システム 企画部マネージャー
２００１年６月 ＪＴＢ ＩＴ企画チームマネージャー
２００６年６
２００６年６月 株式会社ＪＴＢ情報システム 執行役員 グループＩＴ推進室長
２００９年２月 ＪＴＢ ＩＴ企画部長
２００９年２月 ＪＴＢ ＩＴ企画部長
２０１０年１０月 株式会社ＪＴＢ情報システム 取締役
２０１１年６月より
２０１１年６月より現職
経済産業省
情報システムの信頼性向上のための取引慣行・契約に関する研究会委員
ソフトウェア紛争のＡＤＲに関する調査研究委員会委員
情報システム・ソフトウェア取引高度化コンソーシアム委員
情報サービス産業における下請取引等に関する研究会委員
ソフトウェア情報センター
ソフトウェア紛争解決センター 仲裁人・あっせん人候補者
日本経済団体連合会
高度情報通信人材育成部会委員
2

3. システムは「難しい」
（http://www.projectcartoon.comより） 3

4. システム開発でトラブルを防ぐ方法
契約書
契約締結
契約書の条項
プロジェクトマネジメント
進捗管理
予算管理
変更管理
コミュニケーション
4

5. 経済産業省「モデル取引・契約書」の知名度
（企業規模別）
全体(n=996) 5 4 32 51 7
1000人未満(n=683) 3 4 30 54 8
1000人以上(n=313) 9 4 36 46 4
0% 20% 40% 60% 80% 100%
活用している 活用を検討中 知っている 知らない 興味がない
JUAS「企業IT動向調査2011」より
JUAS「企業IT動向調査2011」より
IT動向調査2011
5

6. ベンダーとの契約の有無
（企業規模別）
全体(n=1016) 68 24 8
300人以上(n=316) 61 27 12
300～1000人未満(n=373) 65 27 8
1000人以上(n=327) 77 19 4
0% 20% 40% 60% 80% 100%
すべて契約書を交わしている 一部で契約書を交わしている 契約書を交わさない
JUAS「企業IT動向調査2011」より
JUAS「企業IT動向調査2011」より
IT動向調査2011
6

7. 契約書で定める事項（複数回答）
秘密保持契約 81
著作権の帰属 63
損害賠償 58
ユーザとベンダーの役割分担 52
契約類型 50
第三者ソフトの責任分担 39
機能要件及び非機能要件 34
変更管理手続き 30
ベンダー任せでわからない 10 全体(n=944)
その他 2
0 20 40 60 80 100
(%)
JUAS「企業IT動向調査2011」より
JUAS「企業IT動向調査2011」より
IT動向調査2011
7

8. ＪＴＢでのシステム開発トラブルのケース
（日経コンピュータ 2004年7月26日号、2004年11月15日号）
8

9. 訴訟までの経緯
対象システム
宿泊予約システムの再構築
1999年7月 開発着手（2002年1月稼働予定）
2000年3月 要件定義終了
2000年10月 ベンダーより稼働の半年延伸の要請
2000年12月 開発破綻
（開発費用の倍増、稼働の１年延伸）
2001年1月 契約解除、費用返還を求め交渉開始
2001年7月 提訴
2001年10月 ベンダーより反訴
9

10. 訴訟の経過
膨大な準備書面のやりとり
「見えない世界」に裁判官が理解できず
調停委員会に委ねられるも不調に終わる
プロジェクトマネジメントの観点からの鑑定依頼
プロジェクトマネージャー・鑑定人の証人尋問
提訴から３年が経過
和解交渉
やむなく和解案受け入れ
10

11. 主な争点
当社の主張 相手の主張
当初計画していた要件から大 当初聞いていた内容から大き
① 要件の追加・ きな変更は無い。要件定義工 く膨らんだ。全く別のシステ
変更 程で確定した内容からの追加・
変更は「変更依頼書」を提示
ムという感じ。一部の追加・
変更については「変更依頼書」
していた。 を受け取っていない。
基本設計工程の納品物は納入 中間成果物として納めている。
② 納品物 が遅れたうえ内容も不十分で 検収書は無いが「みなし検収」
間違いも多く、検収できない。 に該当する。
プロジェクトマネジメントを システム開発は共同作業であ
③ プロジェクト 適切に実施していない。 り、発注者こそ実施すべき
マネジメント プロジェクトマネジメントを
実施していない。
開発着手前に締結した「合意 開発工程ごとの「個別契約」
④ 合意書の法的 書」に記載の費用は法的拘束 の合計額が開発費用
拘束力 力を持つ
11

12. 訴訟を振り返って
システムの常識は、世の中の非常識？
なぜこんなに時間がかかるのか？
調停委員って何？
訴訟対応に専任要員が必要？
訴訟のデメリットは？
12

13. システムトラブルの訴訟事例
ケース 概 要
貨物会社Ａが給与 貨物会社ＡがシステムベンダーＢの販売する給与パッケージソフトをカスタマイズし
システムの開発を て導入する計画であったが、予定よりも機能が膨らんでカスタマイズが困難な状況
断念し、システムベ に至った。本システムと連携する人事システムは稼働済みであったが、単独で使用
ンダーＢを提訴 するメリットが無いために、人事システムと共に契約解除し、ＡはＢに支払い済み費
用の返還を求め提訴した。結果としてＢはＡに一定の金額を支払って和解した。
医療機器商社Ｃが 医療機器商社ＣはシステムベンダーＤにERPパッケージ（Oracle EBS）をベースに
処理性能の不満か 業務系システムの再構築を委託した。当初計画から１０ヶ月延伸して稼働はしたも
らシステムベンダー のの、Ｃの期待したレスポンスが出ずＤに対応を求めたが、Ｄは「ハードウェアのサ
Ｄを提訴 イジングはＣの責任」と主張したために、ＣはＤを提訴した。
損害保険会社Ｅの 損害保険会社Ｅは基幹業務システムの開発をメーカーＦに委託した。開発に着手し
未払い費用の支払 てしばらくすると要件は膨らみ開発が遅延すると共に、開発費用が当初計画の３倍
いを求めメーカーＦ に膨れ上がった。一旦は開発範囲・費用を確定したが、その後しばらくしてＥが開発
が提訴 を中止したため、ＦはＥに費用支払いを求めて提訴した。
地方自治体Ｇはシ 地方自治体Ｇはパッケージソフトを利用した業務系システムの開発をシステムベン
ステム開発を中止 ダーＨに委託した。同ソフトの機能不足でシステム化実現が困難になったことからシ
しシステムベンダー ステム開発を中止し、Ｈに支払い済み費用の返還を求めた。一方Ｈは未払い分費
Ｈに費用返還要求 用をＧに求めたことから訴訟となった。
（「日経コンピュータ」より） 13

14. システム取引トラブル事例の分析①
2010年1月～3月に「情報システム・ソフトウェア取引高度化コンソー
シアム」が過去のトラブル事例を分析し、トラブル原因により１１に分
類した。
分類 改善の余地のある事項 例
A 正式契約書締結以前の作業 正式契約書締結以前の作業開始、契約
成立をめぐるトラブル
開始
B 作業に不適合な契約形態 一括請負契約、要件定義の請負契約、異
なるベンダーへの工程別発注に際しての
調整、契約類型（請負・委任）の不明確さ
C 業務範囲 提案書・見積書、議事録その他のドキュメ
ントの効果についての誤解
D 完成基準・検査 ベンダへの丸投げ、仕様が決まらない、
検査実施方法の規定の欠如
14

15. システム取引トラブル事例の分析②
分類 改善の余地のある事項 例
E 役割分担・プロジェクト推進 ユーザの協力義務についての認識欠如、
ユーザ側の業務推進体制の不備、ベンダ
体制
の下請けへの丸投げ
F 知的財産権 知的財産権への理解不足
G 第三者が権利を有する 処理条項の欠如、責任が曖昧、不具合修
正ができない
ソフトウェア
H 変更管理 変更管理手続きの欠如、連絡協議会の決
定事項の効果が曖昧
I 債務不履行・瑕疵担保責任 善良な管理者の注意義務違反
J リース契約
K 自治体関連契約
15

16. 情報システム・ソフトウェア取引トラブル事例集
経済産業省 情報システム・ソフトウェア取引高度化コンソーシアム 編
http://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf
16

17. システム契約に関する留意点
正式契約書を締結してから開発に着手する
ベンダーの言うなりにならない
ユーザ側で契約書のひな形を持つ
ＲＦＰに契約書を添付して見積り条件にする
ＩＴ法務担当者を養成する
ＩＴ法務担当者は契約面のみではなく、システム開発の
ステアリングコミッティにも参画する
「工程別多段階契約」に潜むリスク
開発費用総額を合意する時期
17

18. 開発規模と契約形態
タイプＡ タイプＢ タイプＣ タイプＤ タイプＥ
要件定義 準委任 準委任 準委任 請負 自社開発
設計 準委任 準委任 請負 請負 自社開発
実装 準委任 請負 請負 請負 自社開発
10人月未満(n=661) 15 8 23 34 20
10～100人以上(n=551) 11 9 36 37 7
100～500人月未満(n=323) 9 10 38 38 5
500人月以上(n=209) 10 11 37 39 3
0% 20% 40% 60% 80% 100%
タイプＡ タイプＢ タイプＣ タイプＤ タイプＥ
JUAS「企業IT動向調査2011」より
JUAS「企業IT動向調査2011」より
IT動向調査2011 18

19. 大手メーカーと金融機関との訴訟事例
時期 出来事
2004年9月 新システムを95億円で開発するとした「基本合意書」
「基本合意書」を交わし要件定義を開始
「基本合意書」
2005年9月 「最終合意書」を交わす
新システムを89億7080万円で開発し、2008年1月に稼働させるとした「最終合意書」
「最終合意書」
2006年8～9月 要件定義が難航、「稼働を延伸したい」
「稼働を延伸したい」とするベンダー提案を拒否
「稼働を延伸したい」
11月 「全面稼働を2008年12月に遅らせたい」
「全面稼働を 年 月に遅らせたい」
月に遅らせたい」とするベンダー提案を了承
2007年4月 「採用するパッケージソフトを変更したい」とのベンダー提案を拒否
「採用するパッケージソフトを変更したい」
5～7月 ベンダーに開発の中止を通知、ベンダーの債務不履行により個別契約を解除すると通知
2008年3月 ベンダーに111億700万円の損害賠償
億 万円の損害賠償を求める訴訟を東京地方裁判所に提訴
万円の損害賠償
8月 反訴、未払い代金など13億7400万円を請求
ベンダーがユーザを反訴
反訴 億 万円を請求
2009年1～4月 ユーザとベンダーの双方が、システムの専門家などの意見書を提出
意見書を提出
2010年2～3月 計３回の証人尋問
証人尋問が開かれる
証人尋問
2011年7月 証人尋問が開かれる
証人尋問
10月 結審
2012年3月(予定) 一審判決
日経コンピュータ(2011年11月10日号)より
19

20. 訴訟事例の主な争点
「最終合意書」の法的拘束力
要件定義書の流用可否
パケージソフト利用開発における
開発途中での採用ソフト変更可否
20

21. 判例から得られるシステム開発における教訓
東京地裁平成16年3月10日判決より
ベンダーはプロジェクトマネジメント義務を負う
ユーザが協力義務を履行しないと損害賠償責任を負う
変更管理手続きのあいまいさが問題を先送りする
提案書は契約内容と成り得る
請負か準委任かを定めなければ責任も不明確になる
日経コンピュータ(2007年10月15日号)より
21

22. トラブルが発生したら・・・
当事者の話し合いによる解決（交渉）
非公開で当事者のみが交渉で解決する。
手続きの厳格性に関する規制はない。
裁判外紛争解決手続（ＡＤＲ）
非公開で調停、仲裁により第三者が関与して解決にあ
たる。当事者は調停者、仲裁人を選任できる。
（例）ソフトウェア紛争解決センター
http://www.softic.or.jp/adr/index.htm
訴訟
基本的には公開により裁判官が法令等による所定手
続きにしたがって裁判を行う。
裁判所による調停に移行することもある。
22

23. 参考文献
「ユーザを成功に導く
システム開発契約
クラウドを見据えて」
弁護士 西本 強
（日比谷パーク法律事務所）
商事法務 刊
「トラブルを防ぐＩＴ法務」（日経コンピュータに連載中）
弁護士 上山 浩
（日比谷パーク法律事務所）
23