トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS

トラブル事例のページ

Last-modified: 2012-09-24 (月) 16:50:34 (2485d)
Top / トラブル事例のページ

トラブル原因分類 FrontPage

3つのトラブル原因

 本事例集を作成する際、我々執筆者は判決文等の資料を収集し、それぞれについてその契約に関連するトラブル原因は何であるかを分析した。そしてこの作業と平行し、契約に関連するトラブル原因を類型化し、表として整理した(後掲表1「トラブル原因分類」のとおり)。この表1を参照すれば分かるように、我々はトラブル原因を大きく以下の3つに整理した。
 1.正式契約書を締結していないのに作業を開始してしまう
 2.作業にあった契約形態になっていない
 3.契約に不備がある
 トラブルの原因が大きく分けて上記の3つに整理されることは、システム開発の現場においては、以下が横行していることを意味する。

  • 正式契約書を締結していないのに作業を開始してしまうことが多い
  • 作業にあっていない契約形態になっていることが多い
  • 契約に不備があることが多い

 個々の事例の分析においては、なぜ上記のような現象がシステム開発の現場で多く発生するのかまで踏み込んで分析を行った。

トラブル原因の更なる分析

1.正式契約書を締結していないのに作業を開始してしまう

 「なぜ正式契約書を締結していないのに作業を開始してしまうのか」を現場に聞くと様々な言い訳を聞く。
 ベンダからは、契約の締結まで待っていたら仕事の納期に間に合わない、契約書の条件云々の話をつめると競争者に取引を取られてしまうとの話等である。仕事をある程度のところまでやってしまえば、ユーザは他に乗り換えもできなくなり、後の条件でもめても仕事は取れるとの読みがあるとの話も聞いた。
この現象はベンダだけの責任ではない。ユーザも、正式な契約書が締結されていないのにベンダが作業を開始していることを黙認している。ユーザも最後はなんとかなるだろうとの甘い認識があるようである。
 こうした言い訳をさらに分析すると、システム開発の契約を作成、締結するのに大変時間がかかるという問題が浮き彫りになってくる。後に詳説するが、システム開発契約は契約の中でもその作成、交渉が難しい部類の契約である。正式契約書を締結していないのに作業を開始してしまうことへの対応は、現場においてシステム開発契約書の作成、交渉、締結を容易にするツールの提供をすることであり、その意味でモデル契約書<第一版>・同<追補版>(あわせて以下「モデル契約書」という。)はともに重要な役割を果たすものである。

2.作業にあっていない契約形態になっていることが多い

 典型的な例は、意味もなく一括契約を締結することである。現場では意味があるというかもしれない。ユーザはシステムの設計から開発までの全部についての予算を確定したいので、これにあった一括契約を締結したいのは当然である。
 しかしながら、契約を多段階契約の形にせず、一括契約にすると、要件定義も行われずどのようなシステムを作るのかも決まっていない段階で、完成したシステムについての代金その他の条件を決めるため、条件について過不足のない契約を作成することは不可能である。
 また、システム開発のための作業には、仕事を完成したかどうかが法的にみてその義務をきちんと果たしたことの判断とされる作業(コードを書く等の開発作業はその典型である。)と業界水準の注意と能力をもって作業を行えば完成如何にかかわらず義務を果したことになる作業(要件定義書の作成支援作業などはその典型である。)があり、それぞれについて義務の内容等を決める法的なフレームワークが異なる。前者を請負契約といい、後者を準委任契約という。一括契約は性質の異なる準委任契約と請負契約を一つにしてしまうので、結果としてそれぞれの場面にそぐわない契約になってしまいトラブルの原因となる。

3.契約に不備があることが多い

 前記のように、システム開発のトラブル原因には大きくわけて3つの類型があるが、その中の「契約に不備があることが多い」については、さらにいくつかの小分類に分けられる。
 分類表にあるC業務範囲、D完成基準・検査、E役割分担・プロジェクト推進体制、F知的財産権、G第三者のソフト、H変更管理がそうした小分類である。これらの小分類はシステム開発の作業の特徴を分析する中ででてきたものである。前記のように、システム開発においては、契約締結時にその成果物が具体的に存在しない。「このようなシステム」との思いはあるが、それは全然具体的なものでなく、そのままではおよそ法的な義務の範囲を決めるに足りるものではない。また、システム開発においては、契約締結後の作業において変更が必ず発生する。変更が起こることがあるというのではなく、変更は必ず起こる。さらにシステム開発の特徴として、ベンダだけでなくユーザの作業が必須であることが挙げられる。システム開発のための作業はユーザとベンダの共同作業であり、ユーザはお金さえ支払えばよいというのものではない。
 システム開発の4つめの特徴としては、契約の当事者として、ユーザ、ベンダの他に、下請け、パッケージソフトの権利者、ハードウェアの権利者、ネットワークの権利者等多数の当事者が登場する。トラブル原因の類型表では、こうした特徴を踏まえて、上記のとおりトラブル原因をさらに細かく類型化している。この類型はトラブル原因のすべてをもれなく重複なく整理するというものではなく、システム開発の特徴を踏まえて、トラブルの性質を整理したものであり、いわば分析のためのキーワードである。

 事例集においてはこうしたキーワードを手掛かりに個々のトラブル事例を分析し、その対策を考えている。これらの作業を通じて得た一つの結論としては、こうした特色のあるシステム開発契約の作成、交渉、締結を行うには契約書の作成にそれなりのテクニックが必要であるということである。多段階契約、変更管理規定、未決事項の処理についての規定、加えてユーザの実施すべき作業を含めて役割分担を明確にする規定、多数当事者の権利関係を明確にするための規定はシステム開発契約には必須である。またシステム開発の成果であるシステムには知的財産権が含まれるので、知的財産権の処理についての規定にも注意が必要である。
 さらに、システム開発契約の交渉で論点となりやすい事項(損害賠償の範囲、知的財産権の帰属、著作権の帰属、瑕疵担保、再委託等)についての規定も重要である。そうしたテクニックを使わずにただ漫然と契約書を作成しようとすると、作成に膨大な時間がかかり、実際の作業と契約書に書いてあることが全く別のこととなってしまって、契約書が何の役にも立たずトラブルが発生する。

トラブルを回避するための根本策

  • 上記のようにみていくとトラブルを回避するための根本策としては以下が認められる。
    • 適切なシステム開発契約を迅速に締結するための工夫
    • 適切なシステム開発契約の形態を選択するための工夫
    • システム開発に特有の問題に適切に対応するための工夫
  • 我々はトラブルを回避するための根本策として上記のように考えるに至ったが、システム開発の契約において何について交渉し、契約書に何を書けばよいかをあらかじめ示しており、システム開発契約特有の問題について最新の「テクニック」を組み込んでいるモデル契約書は、上記の有力なツールとなると考えられる。本書では、各事例について、何がトラブル原因か、どうすればトラブルを避けることができたかの説明を提供しているが、さらにモデル契約書の活用方法についても説明をしているので参考にされたい。

表1 情報システム・ソフトウェア取引のトラブル原因分類

類型分類改善の余地のある事項
(1) 正式契約書を締結していないのに作業を開始してしまうA.正式契約書締結以前の作業開始正式契約書締結以前の作業開始、契約成立をめぐるトラブル
1. 契約成立以前に作業を開始したためトラブルになった事例
2. 契約成立以前に作業を開始したためトラブルになった事例
3. 契約成立以前に作業を開始したためトラブルになった事例
4. 契約成立以前に作業を開始したためトラブルになった事例
5. 契約成立以前に作業を開始したためトラブルになった事例
(2)作業にあった契約形態になっていないB.作業に不適合な契約形態一括請負契約、要件定義の請負契約、異なるベンダへの工程別発注に際しての調整、契約類型(請負か委任か)の不明確さ
6. 契約形態が請負か準委任かで、問題となった事例
7. 契約内容が不明確でトラブルになった事例
(3)契約に不備があるC.業務範囲提案書・見積書の効果についての誤解、議事録その他のドキュメントの効果についての誤解、業務範囲の誤解(瑕疵または債務不履行の主張がなされたがそもそも具備すべき仕様でないとされた場合(要件定義が不十分な場合など))
8. 規模が膨み工数増加分の費用負担が問題となった事例
9. 業務範囲が不明確でトラブルになった事例
10. 要件定義が不十分でトラブルになった事例
11. 要件定義及び変更管理規定が不十分でトラブルになった事例
D.完成基準・検査ベンダへの丸投げ、仕様が決まらない(仕様確定についてのベンダとユーザの意識の乖離)、検査実施方法の規定の欠如、実態を伴わない検収書の発行
12. システム開発の仕事の完成と、不具合による解除の可否が争われた事例
13. 業務範囲・完成基準が曖昧なためにトラブルになった事例
E.役割分担・プロジェクト推進体制ユーザの協力義務についての認識欠如、ユーザ側の業務推進体制の不備、ベンダの下請けへの丸投げ、マルチベンダ体制(ベンダ間の調整)、責任の所在の欠如、パッケージ選定責任に関する取決めの欠如
14. ユーザがシステム開発に協力せず、トラブルになった事例
15. プロジェクトマネージメント義務違反、協力義務違反があった事例
16. 役割分担・プロジェクト推進体制に問題があった事例
17. サーバ・サイジングの誤り等からトラブルになった事例
18. 役割分担が不明確だった事例
19. 役割分担が不明確だった事例
20. プロジェクト体制が不十分だった事例
F.知的財産権知的財産権への理解不足
21. 著作権の帰属が問題となった事例
22. 著作権の帰属と、仕様変更による追加費用負担が争われた事例
G.第三者が権利を有するソフトウェア処理条項の欠如、責任が曖昧、不具合修正ができない
9. 業務範囲が不明確でトラブルになった事例
H.変更管理変更管理手続(作業範囲の変更に際しての納期・金額等の見直しルール)の欠如、連絡協議会の決定事項の効果が曖昧、ユーザの計上基準や規則が曖昧、技術的難易度の共通理解の不足
4. 契約成立以前に作業を開始したためトラブルになった事例
5. 契約成立以前に作業を開始したためトラブルになった事例
8. 工数増加分の費用負担が問題となった事例
10. 要件定義が不十分でトラブルになった事例
11. 要件定義及び変更管理規定が不十分でトラブルになった事例
12. システム開発の仕事の完成と、不具合による解除の可否が争われた事例
17. サーバ・サイジングの誤り等からトラブルになった事例
22. 著作権の帰属と、仕様変更による追加費用負担が争われた事例
その他I.債務不履行・瑕疵担保責任善良な管理者の注意義務違反
12. システム開発の仕事の完成と、不具合による解除の可否が争われた事例
J.リース契約
23. リース契約でトラブルになった事例  
K.自治体関連契約
2. 契約成立以前に作業を開始したためトラブルになった事例
11. 要件定義及び変更管理規定が不十分でトラブルになった事例
20. プロジェクト体制が不十分だった事例