東京高判平25・9・26 (企画・提案段階について)

基本情報

裁判年月日 平成25年 9月26日
裁判所名 東京高裁
裁判区分 判決 事件番号 平２４（ネ）３６１２号
事件名 損害賠償・請負代金等反訴請求控訴事件 〔IBM 対 スルガ銀行事件・控訴審〕
裁判結果 原判決変更 上訴等 上告、上告受理申立て（不受理決定）

プロジェクト・マネジメント義務の定義

企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する。

求められる作為

①     (提案する) システム開発技術等をユーザーに説明する。
②     プロジェクトを立案する。(目標の設定，開発費用，開発スコープ及び開発期間の組立て・見込みなど，プロジェクト構想と実現可能性に関わる事項の大枠)
③     リスクを抽出・分析し、これに適切に対処する。
④     企画・提案段階において抽出されたリスクについても、これを適切に説明し、ユーザーの信頼を損ねないような対処を行う。

※ただし、事前検証等の方法，程度等は自ずと限られ，ユーザー側から得られる情報や協力にも限界があるから、プロジェクトの進行過程で生じてくる事情，要因等について漏れなく予測することはもとより困難である。この段階における検証，説明等に関する義務は、このような状況における予測可能性を前提とする。

※ユーザー側にも、開発対象業務の分析と、ベンダーの説明を踏まえたリスク分析が求められる。

※システム開発対象の技術等と開発対象業務について、情報の非対称性、能力の非対称性が双方に存在する。

本件(フェーズⅠ) におけるプロジェクト・マネジメント義務違反 (否定)

(検証の十分性について)
（ベンダーは）本件システム開発開始の２年以上前から，ＮＥＦＳＳを企画・開発するチームを立ち上げて，Ｃｏｒｅｂａｎｋの機能や充足度について検証を行っていたことが認められ，その検証が杜撰なもので，およそ検証に値しないものであったということはできない。

(パッケージソフトウェア選択の妥当性について)
Ｃｏｒｅｂａｎｋ自体が邦銀の勘定系システムに導入するソフトとしての性能をおよそ備えていなかったとは認めることはできない。(中略) Ｃｏｒｅｂａｎｋは，業務フローを組み込むことを避け，業務を構成する処理工程を部品化して，これを呼び出す形でシステム形成をする可変性・柔軟性の高いソフトであると認められるから，適切な開発手法によれば，邦銀の勘定系業務に適用し得る。

(開発方針について)
ユーザー (被控訴人) は，ベンダーがカスタマイズベース・アプローチを選択したことが誤りであり，(開発方針に関する) 検討・検証を，企画・提案段階で実施すべきであったと主張するが、本件基本合意①の開発方針における新業務・機能項目として「現行システムで提供している商品，サービス，契約などは現行レベルを維持し，継続してお客さまに提供可能であること」が掲げられ、ステアリング・コミッティ(においてもユーザーが)、被控訴人は独自性を大事にしており，事務の標準化について，現状からダウンすること，顧客に影響を与えることは許されない。この点については譲れない。」旨の発言があったこと等、ユーザー側も旧システムに基づく業務形態中 ，維持すべき点があることを意識し，それを維持する意向であることを明らかにしていた。
カスタマイズベース・アプローチがシステム開発において許容することのできない手法選択の誤りであったと認めることはできない。

(パッケージ開発ベンダーとの開発体制について)
確かに、(パッケージ開発ベンダーとの) 開発体制には円滑とは いいがたい点が存し，機動的な対応力が不足したことは認められるけれども、ベンダーは二年以上前から、パッケージ開発ベンダーとＣｏｒｅｂａｎｋの日本化の作業を進めており，ソフトウェアの改変権をめぐる調整に円滑さを 欠く点があったとしても企画・提案段階から共同関係を構築し得ないような 状況にあったとは認めることはできない。

(ユーザーとの信頼維持について)
ベンダーが、(唐突に) Ｃｏｒｅｂａｎｋに代えてＴＣＢを提案し、ユーザーとベンダーとの信頼関係を失わせることになったことは、本件システム開発上の問題点に対する適切な対処と説明を怠った結果の表れであり、この段階におけるプロジェク ト・マネジメントの不足である。

(リスクの抽出と管理について)
他方、仮に，ベンダーが，本件システム開発の企画・提案段階から，想定されていた開発費用，開発スコープ及び開発期間では，システム開発を完成させることが不可能であることを既に認識し，あるいは容易に認識することができたとすれば，(これも) プロジェクト・マネジメントに関する義務違反である。

若干の考察

本判決においては、本件基本合意前 (開発契約締結前) においてベンダーにプロジェクト・マネージメント義務違反があったことは否定しているが、この段階においてもベンダーにプロジェクト・マネージメント義務があること自体は否定していない。
ただ、本件においてもそうであるように、契約締結前の段階においては、「事前検証等の方法，程度等は自ずと限られ，ユーザー側から得られる情報や協力にも限界があるから、プロジェクトの進行過程で生じてくる事情，要因等について漏れなく予測することはもとより困難」としている点は実務の面から見ても納得のできるところであると考えられる。
ただし、この段階においても、想定されていた開発費用，開発スコープ及び開発期間では，システム開発を完成させることが不可能であることをベンダーが認識していたか、あるいは容易に認識し得たのであれば、これを分析し、管理し、ユーザーの信頼を損ねないように説明するとともに対処を検討、実施することは、ベンダーのプロジェクトマネージメント義務であるとしている。
これらを考えると、契約締結前の段階におけるプロジェクト・マネージメント義務違反の有無は、信義則違反と不法行為というコンテキストで判断されると考えられる。これについても実務面から見て受け入れられる判断の道筋ではあるが、信義則違反という一般条項に頼らざるを得ないのか、例えば、金融商品取引におけいて取引業者が顧客に行う危険の説明義務のように、専門家としてシステム開発に伴う危険を説明する義務、つまり専門家責任としても検討される余地はあると思うが、その点について、本判決の契約締結前のプロジェクト・マネージメント義務に関する判断では言及していない。

参考条文

(基本原則)
第1条
2 権利の行使及び義務の履行は、信義に従い誠実に行わなければならない。

(不法行為による損害賠償)
民法第709条
故意又は過失によって他人の権利又は法律上保護される利益を侵害した者は、これによって生じた損害を賠償する責任を負う。