経営者コミュニティ「経済界倶楽部」

みずほ証券誤発注事件とスルガ銀行事件高裁判決後に見るシステム開発の留意点

経営者のためのグローバル法務最前線

システム開発で顧客のベンダーへの協力は義務

 東京高等裁判所は2013年7月、東京証券取引所がみずほ証券による誤発注の取消処理を適切に行うことができるシステムを提供できなかったとして、107億1200万円あまりの損害賠償の支払いを命じました。

 また、同年9月には、顧客であるスルガ銀行のシステムに関して、システム開発ベンダーのIBMのプロジェクト・マネジメント義務違反を認め、41億7200万円あまりの損害賠償の支払いを命じました。

 今や会社の業務は、コンピューターシステムの力なくしてはなし得ませんが、コンピューターシステムは、一般的なモノづくり以上に顧客の関与が必要になり、ベンダーの力だけで完成することはできません。そして裁判所もシステム開発に関して、これまで顧客のベンダーへの協力義務を、一定程度、法的な義務として認めています。

 コンピューターシステムの開発プロジェクトの成功には、ベンダーと顧客との間で適切で明確な協力・コミュニケーション体制を構築することが重要になってきます。双方の協力・コミュニケーション体制の構築の一例としては、双方の役割分担、合意事項、合意形成方法、合意(仕様)変更ルールの明確化などを挙げることができます。

 一般的な取引であれば、当事者の合意事項は契約書のみで規定されることが通常でしょうが、システム開発の実務では、これらが契約書のみで規定されることはむしろ少なく、提案書、議事録、議事録添付の説明資料などで合意され、明確化されるケースも多くあります。

 また、裁判所は、コンピューターシステムはベンダーの力だけで完成できないという認識を大前提とし、顧客の協力義務を認めながらも一貫してベンダー側に「プロジェクト・マネジメント義務」を認めてきました。裁判所は、その具体的な内容を示すことによって、ベンダー側がシステム開発でなすべき指針を与えているようにも思われます。

 この2事件のうちスルガ銀行事件では、まさにこの「プロジェクト・マネジメント義務」の存否と内容が争われたのですが、両事件ではほかに、議事録の位置付けや契約書における責任制限条項の適用範囲について非常に興味深く、今後の実務にも大きな影響を与えると思われる判断が示されています。

 これらの2点について裁判所がどのように考えているのかを紹介しつつ、顧客(ユーザー)側、ベンダー側の双方が留意すべき点についても併せて示します。

「プロジェクト・マネジメント義務」とは何か

 システム開発は、要件定義、基本設計、詳細設計、開発(単体・結合、システムテストを含む)、受入(運用)テストなどの段階(フェーズ)を経て完成に至ります。

 これらの段階(フェーズ)の中で、基本設計以降、開発フェーズまでに関する契約の法的性質は、一般的に請負契約であると言われています。民法の条文に照らしてみますと、請負契約上、ベンダーが果たすべきは「仕事の完成」(民法632条)、言い換えれば、注文を受けたコンピューターシステムの開発を完成させること、ということができます。しかしその完成には顧客側の関与と作業が必要不可欠です。

 このため裁判所は、ベンダー側に「プロジェクト・マネジメント義務」なるものを認め、義務違反があった場合にベンダーの債務不履行を認めることとしてきました。

 そして、裁判所は顧客側の関与と作業を得ることを前提に、「プロジェクト・マネジメント義務」の内容として、「合意された納入期限までにシステムを完成させるよう、顧客とベンダーで合意され、あるいは通常利用される開発手法などにしたがって開発を進めるとともに、常に進ちょくを管理し、開発を阻害する要因の発見に努め、これに適切に対処する義務」を求めてきました。

 この考え方はスルガ銀行事件の第一審判決でも踏襲されました。そして控訴審の東京高裁は、これを一歩進めて、段階別の「プロジェクト・マネジメント義務」の存在を認めました。

 まず、東京高裁は、同義務が契約締結前のベンダーによる企画・提案段階にも存在するとして、ベンダーには自らの提案内容を検証し、その時点で合理的に期待し得る予測可能性を基準として提案上のリスクを顧客に説明する義務があることを認めました。

 一方、東京高裁はそのような企画・提案段階では、顧客側にもベンダーからの説明を踏まえ、システム開発について自らリスク分析をすることが求められる可能性があることを指摘しました。

 また、システム開発構想などに一定の修正があることは当然想定されるものであるから、企画・提案段階の計画通りにシステム開発が進行しないことなどをもって直ちに企画・提案段階でのベンダーのプロジェクト・マネジメントに関する義務違反があったとは言えない、と判断しました。

 スルガ銀行事件で東京高裁が示したこの基準が他の事例にも同様に当てはまるかどうか、またこの判示自体の当否については、立場の違いなどからさまざまな評価があり得ますが、システム開発の実情から考えれば、より実態に近い公平な判断がなされたと評価することができ、この点では相当程度の先例的価値があると言えます。

スルガ銀行事件高裁判決後に見るシステム開発の留意点とは

 スルガ銀行事件東京高裁判決は、最終合意締結以降、ベンダーには「本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダーとして通常求められる専門的知見を用いてシステム構築を進め、ユーザーに必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整などを行いつつ、本件システム完成に向けた作業を行うこと(プロジェクト・マネジメント義務)」が求められると判断しました。この一般論自体は、目新しいものではありません。

 しかし、契約書締結後でも開発の遂行過程で計画を変更しなければならない場合があることを認めた点、その場合ベンダーは、具体的な局面に応じて顧客(ユーザー)側のメリット・デメリットを考慮し、適時適切に開発状況の分析、開発計画の変更の要否とその内容、開発計画の中止の要否とその影響などについても顧客に対して説明する義務を負う、と判断した点は、新しい側面であると言えます。

 東京高裁の判断からすれば、当初想定されていた開発計画を変更せざるを得なくなった場合に、このような説明義務を果たしていただけで直ちにベンダーが債務不履行責任を免れるのではなく、説明義務を果たしたことを前提に、顧客との間で適切な協議を行い、その了解を得ながら適宜必要とされる修正や調整などを行いつつ、本件システム完成に向けた作業を行うことが求められることになります。

 もっとも、システム開発の実情を見るとこのような場合、顧客はベンダーが約束した開発計画と異なることを主たる理由として、協議そのものや「必要とされる修正、調整」に応じることを拒み、プロジェクトが頓挫、遅延することが少なくありません。

 他方、ベンダーの現場担当者は、このような場合でも、安易に開発中止を提案せず、種々の対応策を検討して何とか完成させようと試みるのが一般的です。したがって、このように誠実な対応をした結果の責任の公平な分担については、後知恵の弊に陥ることがないよう慎重に判断することが裁判所には求められます。

 その意味では

①顧客が不合理に協議に応じなかった場合に発生した損害の公平な分担の枠組み、

②ベンダーが開発計画や開発手法の変更に関し顧客に対して説明をすべき時期と内容

 については、今後の事例の積み重ねによってさらに検討されるべき課題となるでしょう。

 ただ、そのような枠組みなどが裁判上明らかになるまでは、ベンダー側は開発計画に変更の必要性が生じた場合には、適切に議事録または電子メールなどで必要な説明をするとともに、顧客の承認を取得するよう努め、顧客が「必要とされる修正、調整」に応じなかった場合には、その事実や理由も含めて記録を残しておくこと、またベンダーと顧客との間の責任の公平な分担の枠組みについても、できる限り詳細かつ明示的に契約書または提案書に落とし込んでおくことが、リスク・マネジメントの観点から必要になるでしょう。

みずほ証券誤発注事件、スルガ銀行事件共通の重要な争点とは

 免責条項または責任限定条項の適用範囲は、みずほ証券誤発注事件、スルガ銀行事件とも重要な争点となりました。

 免責条項、責任限定条項は、企業間取引の場合であれば公序良俗に反するとか、故意か「重過失」がある場合を除き、当事者を有効に拘束するというのがこれまでの裁判例です。

 スルガ銀行事件では、当事者間の最終合意書に「契約違反、不法行為などの請求原因を問わず、現実に発生した通常かつ直接の損害に対してのみ、損害発生の直接原因となった各関連する個別将来契約の代金相当額を限度とし、また、いかなる場合にも予見の有無を問わず特別の事情から生じた損害や第三者からの損害賠償請求に基づくスルガ銀行の損害については責任を負わない」旨の規定がありました。

 しかし同事件の控訴審判決は、スルガ銀行がIBM以外の第三者との契約に基づいて最終合意以降に支払ったソフトウエア開発費用などについては「各関連する個別将来契約の代金相当額を限度」という規定は適用されず、これらの代金相当額を超える部分について免責されない、と判断しました。

 この契約解釈には疑問がありますが、今後契約書を作成する際には、裁判所がこのような契約解釈をする可能性があるということを認識しつつ、たとえ文言的には重複しても、第三者とのソフトウエア開発などに関する契約に基づく支払額まで当然に免責されるような明示的規定を置くことも検討する必要がありそうです。

 みずほ銀行誤発注事件では「重過失」の意味が争われ、東京高裁は、「重過失」とは結果予見可能性および容易性を前提として、注意義務違反の程度が「顕著」である場合をいう、と判断しました。みずほ銀行誤発注事件では「重過失」の意味が一審と控訴審で若干異なってとらえられたことからも明らかな通り、今後、裁判所でも判断が分かれる可能性があります。

 また裁判所による「顕著」のあてはめによっては、後知恵でベンダーやシステム提供者にバグ回避の可能性と容易性が認定され、利用者にばく大な損害が認定されてしまう可能性も否定できません。実務的には「重過失」の意味を当事者間で合意しておくなどの措置も、今後検討に値するものと思われます。

 

【みずほ】関連記事一覧はこちら

【霞が関番記者レポート】の記事一覧はこちら

 
経済界 電子雑誌版のご購入はこちら!
雑誌の紙面がそのままタブレットやスマートフォンで読める!
電子雑誌版は毎月25日発売です
Amazon Kindleストア
楽天kobo
honto
MAGASTORE
ebookjapan
 

雑誌「経済界」定期購読のご案内はこちら

経済界ウェブトップへ戻る