東京地裁平成 21 年（ワ）第 34501 号 損害賠償請求事件ディスカッションメモ
2017 年 7 月 19 日
発表者：康本・重村（担当）
１．東京高裁平成 25 年 9 月 26 日判決（スルガ銀行・日本 IBM 事件）との比較
両事件とも、パッケージ製品利用のシステム開発が頓挫したという点は同じである。

①システム

トクヤマ・TIS 事件

スルガ銀行・日本 IBM 事件

事業活動全般（販売、生産、銀行業務全般をつかさどる物流、購買、人事）を管理す「新経営システム」

る独自の財務会計システム（IRIS）を ERP パッケージを中心に基幹システムを再構築する
②

パッケージ

・SAP ソフトウェア

・銀行業務全般：IBM 製※ただし、化学産業の目標業

NEFSS

務プロセスは、被告独自のテ ・NEFSS のうち、勘定系部分ンプレート（TCM テンプレー：FIS 社製 Corebankト）に合わせる形の設計方法であった。
③

取引金額

概算 17 億円

115 億 8000 万円

④

開発手法

プロトタイプウォーターフォールに近い当時一般的とされた開発手法⑤

開発の頓挫した

テスト、導入フェーズ

要件定義

時期
⑥契約の締結・委託料支払状況
スルガ銀行・日本 IBM 事件
締結日

契約書名

金額

委託料支払

H16/9/29

本件基本合意①95 億円―

H16/9/30

IBM 支援サービス契約

約 7 億 2,319 万円

不明

H16/12/29

本件基本合意②

H16/12/29

IBM システムインテグレーシ

不明（①を変更）

―

35 億円

不明

ョン契約
H17/9/30

本件最終合意89 億 7,080 万円―

H18/3/31

本件未払個別契約①

2 億 5,725 万円

未払い

H18/9/29

本件未払個別契約②

約 11 億 1,969 万円

未払い

・裁判所は、本件最終合意において締結されるべきとされた個別将来契約の大半が締結されていないことから「支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえない」として最終合意の金額等の拘束力を認めなかった。
・最終合意締結前には本件基本合意に基づく 16 件の個別契約が、最終合意締結後には未払個別契約①②の他導入・保守に関する契約も締結し、一部支払がされていた。

トクヤマ・TIS 事件○＝裁判所が締結及び契約の拘束力を認めた△＝裁判所が締結を認めなかったが、委託料の支払い義務を認めた（商法 512 条）
締結日

契約書名

金額

委託料支払

○

H18/12/11

業務委託基本契約書――○

H18/12/11

検討フェーズ個別契約書

7,425 万円

済○H19/4/1

導入フェーズ―SYM 個別契約

1 億 6,275 万円

済○H19/6/30

導入フェーズ―PRT 個別契約

1 億 8,252 万円

済○H20/2/5

導入フェーズ―DVL 個別契約

不明

済

○

H20/4/20

ERP 導入―IMP フェーズ個別契不明

済

1 億 5,750 万円

未払い

約 7,221 万円

半額未払い

約H20/11/20○

IMP フェーズ延長（10-12 月分）
個別契約△

H20/12/26 頃IMP フェーズ延長契約２（約 3,610万円）○H21/1/7 頃

ERP 追加開発（平成 20 年 12 月

約 2,829 万円

未払い189 万円

未払い15 日時点分）契約△

H20/12/18 頃

ヘルプデスク支援契約⑦裁判所が認定した PM 義務の内容
スルガ銀行・日本 IBM 以下４つの時点に分けて判断した。
Ｉ 企画準備から本件基本合意①締結前

この段階での PM 義務の存在を認めたうえの段階（企画・提案）で PM 義務（不法行為上の義務）違反についての故意又は過失はないとした。

Ⅱ 本件基本合意①締結から本件基本合 ・遅くとも、本件最終合意を締結する段階に意②締結前の段階（計画・要件定義）おいては、PM 義務違反（不法行為及び債務Ⅲ 本件基本合意②締結から本件最終合不履行）が認められるとした。

意締結前の段階（計画・要件定義）・義務違反の程度は故意又は重過失には及ば

Ⅳ 本件最終合意締結から本件システムない。

開発終了の段階（計画・要件定義、実践）
PM 義務の具体的な内容
・ベンダーとして通常求められる専門的知見を用いてシステム構築を進め、ユーザーに必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整を行いつつ、本件システム完成に向けた作業を行うこと（プロジェクトマネジメント）
・ベンダーとして、修正の必要性と、修正が開発目的等に照らして許容限度を超える場
合は、局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負うトクヤマ・TIS 事件
・自らが有する専門的 知識と経験に基づき，本件システム開発に係る契約の付随義務として，本件システム開発に向けて有機的に組成された各個別契約書や本件提案書において自らが提示した開発手順や開発手法，作業工程等に従って自らなすべき作業を進める
・常に本件プロジェクト全体の進捗状況を把握し，開発作業を阻害する要因の発見に努め，これに適切に対処する・注文者である原告の本件システム開発へのかかわりなどについても，適切に配意し，パッケージソフトを使用したＥＲＰシステム構築プロジェクトについては初めての経験であって専門的知識を有しない原告において開発作業を阻害する要因が発生していることが窺われる場合には，そのような事態が本格化しないように予防し，本格化してしまった場合にはその対応策を積極的に提示する義務
具体的には、
被告は，原告における意思決定が必要な事項や解決すべき必要がある懸案事項等の発生の徴候が認められた場合には，それが本格的なものとなる前に，その予防や回避について具体的に原告に対して注意喚起をすべきであるし，懸案事項等が発生した場合は，それに対する具体的な対応策及びその実行期限を示し，対応がされない場合に生ずる支障，複数の選択肢から一つを選択すべき場合には，対応策の容易性などそれらの利害得失等を示した上で，必要な時 期までに原告において対応することができるように導き，また，原告がシステム機能の追加や変更の要求等をした場合，当該要求が委託料や納入期限，他の機能の内容等に影響を及ぼすときには原告に対して適時にその利害得失等を具体的に説明し，要求の撤回，追加の委託料の負担や納 入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務⑧PM 義務の法的性質
・スルガ銀行・日本 IBM 事件：本件最終合意締結後の契約について債務不履行解除を認めた
・トクヤマ・TIS 事件：付随的義務違反であるとした（契約解除を認めなかった）※両事件とも、「付随的義務違反」と解釈するのが通説である。
⑨損害の算定・スルガ銀行・日本 IBM 事件
IBM への支払額＋本件システム開発のために IBM 以外に支払った額※ただし、IBM への支払額は本件最終合意締結後の契約及び締結後の作業の対価※逸失利益は契約条項の賠償範囲の制限により請求ができない・トクヤマ・TIS 事件
原告（トクヤマ）が請求する賠償額（18 億 0,113 万 4,321 円）の 3 割相当額
※上記原告請求額は、当事者間の契約により制限された額（個別契約金額の総額）であり、実際には原告は TIS 以外に支払った開発費用等を合わせると約 40 億円を支払っていることが認定されている。

２．本判決において被告が認定された義務違反について① 付随義務である PM 義務違反
裁判所は、「被告は，検討フェーズからＩＭＰフェーズに至るまでの全ての個別契約のサービス及び納入物に関して，原告から検収を受けるとともに代金の支払を滞りなく受けてきた。
そうすると，被告には，上記各個別契約における主たる債務たる給付目的自体に関して債務不履行があったということはできない。」と認定し、PM 義務違反と解除の関係について「・・・それら注意義務は飽くまで信義則に基づく付随的なものであるから，それを根拠として，上記各契約の拘束力を全て解消するような解除を認めることはできないと解するのが相当である。
」としている（判決 47 頁～48 頁）。更に、プログラムの品質については、「被告において，プログラム品質の問題に関して付随義務の違反があったとまではいうことはできない。
」（同 55 頁末尾）
「仮に本件プロジェクトを中止しなければ完成したであろう本件システム開発を自らの判断で中止するに至ったということができる。」と認定している（同 56 頁下から 5 行目）。
・ユーザーが中止しなければシステムが完成したであろうことまで認定しているにもかかわらず、ベンダーは付随義務違反で賠償責任を負わなければならないのか。

② 仕様自体の不適合
・裁判所は、仕様自体の不適合に関する付随義務違反（判決 52 頁イ）を認定しているが、「仕様不適合」は付随義務違反ではなく契約違反（債務不履行）ではないのか。
⇒「仕様不適合」を生じさせるような PM 義務違反という意味なので、付随義務違反
３．PM 義務の変化＜参考＞○東京地判平成 16 年 3 月 10 日 東京土建国民健康保険組合事件
ベンダは、契約書・提案書で提示した開発手順・手法で開発を進め、進捗状況を管理し、開発を阻害する要因を発見し、（適時・適切に）対処すべき義務を負い、さらに、ユーザによって作業を阻害される行為がないよう働きかける義務を負う（プロジェクトマネージメント義務）。
具体的には、ユーザが機能の追加等の要求をした場合、当該要求が委託料や納入期限等に影響を及ぼすものであった場合にユーザに対し適時その旨説明して、要求の撤回や追加の委託料の負担等を求めるなどの義務である。
○旭川地判平成 28 年 3 月 29 日（日経コンピュータ 2016 年 10 月 13 日号 28 頁より）
※病院情報管理システムの開発の稼働が遅れた事案（パッケージカスタマイズ）。
ユーザーの要望受け入れで開発が遅延すると予測できる場合、ベンダー側は「（使用凍結の）合意を理由に拒絶する」か、代替案を示す等して「原告に開発要望を取り下げさせるなどの対応を取るべき」である。
・実際に本判決レベルの PM 義務を果たすこと、また果たしていることを立証することはハードルが高いように感じられる。

４．ユーザーの協力義務＜参考＞○東京地判平成 16 年 3 月 10 日 東京土建国民健康保険組合事件
オーダーメイドのシステム開発はベンダのみでは完成できず、ユーザは、開発過程において、どのような機能を要望するのかを明確に伝え、ベンダとともに検討し、画面や帳票を決定し、成果物の検収をするなどの協力義務がある。
具体的には、ベンダから求められた際に、ユーザが適時適切な意思決定をしてない点が協力義務違反であるとされた。
・本判決においては「ユーザーの協力義務」については言及がない。賠償請求額の 7 割減の根拠は不明である。

５．ベンダー対ベンダー（例：プライムベンダーが下請ベンダーに開発を委託する場合）
における PM 義務＜参考＞○東京地判平成 22 年 7 月 13 日
大学のサーバシステムの構築業務
A⇒B⇒C⇒Y⇒X とシステム開発を委託し、X が Y に対し Y の PM 義務違反により想定外の人件費相当額の損害を被ったとして損害賠償請求をした事案。
「本件請負契約が、サーバシステムの構築という専門的な業務に関するものであることからすれば、これを請け負った X は、専門業者として納期までに作業を終えて納品する目的を達成するため、自己の作業の進行方法、管理、スケジュールの調整を含めた裁量権を有していたものと解される」・ユーザー側に情報システム専門子会社が加わっていた場合に PM 義務の評価は変わるか。
本判決においては原告のシステム専門子会社株式会社トクヤマ情報サービス（TJS）が存在しているが、特に言及がない。

６．契約書上に「PM 義務」を定めることは有効な解決手段であるのか。どのように定めるのか。
以上