プロジェクト・マネジメント義務と協力義務

IT・情報セキュリティ
尾城 亮輔弁護士

 当社はベンダーです。当社が受託しているシステム開発プロジェクトが上手くいかず、ユーザーと協議のうえで、プロジェクトを中止することになりました。当社は、プロジェクトが失敗した理由は、ユーザーが合理的な理由なく多数の仕様変更を要求してきたことにあると考えていますが、このような場合の法的な責任について、どのように考えればよいのでしょうか。また、ユーザーから報酬を支払ってもらうことはできるのでしょうか。

 ベンダーの債務不履行責任とユーザーの報酬支払義務は、両当事者の帰責事由の有無によって判断されます。システム開発では、プロジェクト・マネジメント義務と協力義務という概念を用いて、帰責事由の有無の分析を行うのが一般的です。
 ベンダーは、プロジェクト・マネジメント義務として、開発作業を適切に進めるとともに、専門的な知識を有しないユーザーが適切にプロジェクトに関与するように働きかける義務を負っており、他方で、ユーザーは、協力義務として、適時に仕様の決定等を行うとともに、資料等の提供その他の必要な協力を行うべきとされています。
 このような義務は、システム開発の共同作業的側面に基づくものであり、当該プロジェクトにおけるベンダーとユーザーとの役割分担に即した分析を行う必要があります。

解説

プロジェクトが失敗したときの法的責任

 システム開発プロジェクトが途中で頓挫してしまった場合、法律的には2つの点が問題になります。

  1. ベンダーは債務不履行責任(損害賠償の支払義務など)を負うのか
  2. ユーザーは報酬を支払わなければならないのか

 ①については、ベンダー(債務者)に帰責事由がないときには、ベンダーは債務不履行責任を負わないことになります。また、②については、両当事者がプロジェクトの継続は困難であると判断したということから、ベンダーの債務(仕事の完成ないし事務の遂行)は履行不能に陥ったといえるため、危険負担の問題として処理されることになります。

 いずれについても、どちらの当事者に帰責事由があるのかという点によって結論が分かれることになり、下記の表のように整理することができます。

プロジェクト失敗の原因 ベンダーの債務不履行責任 ユーザーの報酬支払義務
① ユーザー側の帰責事由による ×
② 双方ともに帰責事由なし × ×
③ ベンダー側の帰責事由による ×

プロジェクト・マネジメント義務と協力義務

法的な位置づけ

 システム開発は、一般的にベンダーとユーザーの共同作業により進められ、各当事者が適切にその役割を果たすことが必要であるといわれており、帰責事由の有無を分析する際にも、このようなシステム開発の特殊性を考慮する必要があります。そこで、帰責事由を分析するための概念として用いられているのが、プロジェクト・マネジメント義務協力義務です。

*なお、ここではベンダーの義務違反を評価するための概念であると説明をしていますが、理論的には、さらに進んで、協力義務違反によりユーザーの債務不履行責任を認めることも考えられます。ただし、ユーザー側の帰責事由が認められれば、通常は、ベンダーの報酬請求権(仕様変更の合意が認められれば、工数が増大した分も含む)が認められるため、協力義務違反によるユーザーの債務不履行責任を議論する実益がないケースが多いのではないかと思われます。

プロジェクト・マネジメント義務と協力義務に関する判決

 プロジェクト・マネジメント義務と協力義務という用語を初めて用いたとされるのは、東京地裁平成16年3月10日判決・判タ1211号129頁です。同判決は、まず、プロジェクト・マネジメント義務について以下のように述べています。

  1. ベンダーは、納入期限までにシステムを完成させるように、開発契約の契約書およびシステム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負う。
  2. システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、ベンダーは、注文者のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザーによって開発作業を阻害する行為がされることのないようユーザーに働きかける義務(プロジェクトマネージメント義務)を負っていた。

 上記の①は、開発作業を適切に進めるという本来の債務を説明したものといえますが、②は、そこからさらに進んで、ベンダーには、専門的な知識を有しないユーザーに対して働きかける義務があるとしている点が注目されます。

 そして、同判決は、「より具体的に説明すれば」として、ベンダーが行うべき義務として以下の内容をあげています。

  • ユーザーにおける意思決定が必要な事項や、ユーザーにおいて解決すべき必要のある懸案事項等について、具体的に課題及び期限を示すこと
  • ユーザーによる決定等が適時に行われない場合に生ずる支障を説明すること
  • 複数の選択肢から一つを選択すべき場合には、それらの利害得失等を示したうえで、必要な時期までにユーザーがこれを決定ないし解決することができるように導くこと
  • ユーザーがシステム機能の追加や変更の要求等をした場合で、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすものであった場合等に、ユーザーに対し適時その旨説明して、要求の撤回や追加の委託料の負担、納入期限の延期等を求めること

 プロジェクト・マネジメント義務について上記のように述べる一方で、同判決は、ユーザーの協力義務について、以下のように述べています。

  • システム開発契約では、ユーザーが開発過程において、内部の意見調整を的確に行って見解を統一したうえ、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要である。このような役割を委託者であるユーザーが分担していたことにかんがみれば、本件電算システムの開発は、ユーザーと受託者であるベンダーの共同作業というべき側面を有する。
  • したがって、ユーザーは、システムの開発過程において、資料等の提供その他システム開発のために必要な協力をベンダーから求められた場合、これに応じて必要な協力を行うべき契約上の義務(協力義務)を負っていた

 このように、プロジェクト開発においては、ユーザーが機能の内容等を決定し、検収などの役割分担を分担することが必要であるとし、資料の提供その他の必要な協力を行うべき契約上の義務を負っていたとしています。  

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

(1)ベンダーは適切なサポートを行い、意思決定の責任はユーザーが負う

 プロジェクトは納期を持ち、有限の予算や人員で、所定の目的を達成することが求められます。したがって、プロジェクトを成功させるためには、発生する課題や要望に対して一定の優先順位をつけ、取捨選択をすることが必要になります。
 他方、プロジェクトは誰のために行うかというと、ユーザーのためです。情報システムは、ユーザーの経営課題を解決するために開発されるものですから、プロジェクトに対する意思決定は本質的にはユーザーによって行われる必要があります。

 このように、ユーザーは、プロジェクトにおける意思決定権者としての役割を担うことになります。しかし、その役割を果たすためには、技術的な理解が必要な場合もありますし、プロジェクトの見通し(特に、仕様変更をするという決定をした場合に納期にどのような影響が出るかなど)を適切に把握して、適切な判断をすることは困難です。

 プロジェクト・マネジメント義務は、このようなギャップを埋めるためのものであり、システムの専門家として、ベンダーはユーザーの意思決定をサポートすることが求められることになります。他方、最終的な意思決定は、ベンダーではなくユーザーが行うべきものであり、ベンダーが適切なサポートを行っていた以上は、その意思決定の責任はユーザーが負うと考えるのが適切であるといえます。

(2)ベンダーによる説明義務の側面が強調された判決

 たとえば、東京高裁平成25年9月26日判決・金判1428号16頁(いわゆるスルガ銀行・IBM事件)は、以下のように述べており、ベンダーによる説明義務の側面が強調されています。

  • システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダーとしては、そのような局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負うものというべきである
  • 本件システム開発を推進する方針を選択する以上、ユーザーに対し、ベンダーとしての知識・経験、本件システムに関する状況の分析等に基づき、開発費用、開発スコープおよび開発期間のいずれか、あるいはその全部を抜本的に見直す必要があることについて説明し、適切な見直しを行わなければ、本件システム開発を進めることができないこと、その結果、従来の投入費用、更には今後の費用が無駄になることがあることを具体的に説明し、ユーザーである被控訴人の適切な判断を促す義務があったというべきである。また、本件最終合意は、前記のような局面において締結されたものであるから、控訴人は、ベンダーとして、この段階以降の本件システム開発の推進を図り、開発進行上の危機を回避するための適時適切な説明と提言をし、仮に回避し得ない場合には本件システム開発の中止をも提言する義務があった

(3)仕様凍結合意のあとにユーザーから多数の追加開発要望が出された事案

 また、札幌高裁平成29年8月31日判決は、仕様凍結合意のあとにユーザーから多数の追加開発要望が出されたという事案ですが、裁判所は以下のように述べています。

 ベンダーは、プロジェクト・マネジメント義務の履行として、追加開発要望に応じた場合は納期を守ることができないことを明らかにしたうえで、追加開発要望の拒否(本件仕様凍結合意)を含めた然るべき対応をしたものと認められる。
 これを越えて、ベンダーにおいて、納期を守るためには更なる追加開発要望をしないよう注文者(ユーザー)を説得したり、ユーザーによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、ベンダーにプロジェクト・マネジメント義務の違反があったとは認められない。

 このように適切な説明等の対応をしていたにもかかわらず、ユーザーが追加開発要望をしたのであれば、その責任はベンダーではなく、ユーザーが負うべきと考えることができます。

まとめ

 プロジェクト・マネジメント義務や協力義務は、まだ十分な議論がなされているとはいいがたい分野ですが、システム開発がベンダーとユーザーの共同作業によって行われるという点が基礎にあります。当該プロジェクトにおいて、両当事者の役割分担はいかにあるべきかという観点から検討を行うのが適切であり、たとえば、ユーザーが情報システム部門を有し、十分な体制を組んでプロジェクトを推進していたかといった点も考慮要素となり得ます。このように、プロジェクト失敗時の法的責任を検討するためには、多角的にプロジェクトを検証することが必要になります。  

参考文献



裁判例から考えるシステム開発紛争の法律実務」(商事法務、2017)
著者:難波修一、中谷浩一、松尾剛行、尾城亮輔
定価:本体4,600円+税
出版社:商事法務
発売日:2017年2月
コンテンツの更新情報、法改正、重要判例をもう見逃さない!メールマガジン配信中!無料会員登録はこちらから
  • facebook
  • Twitter

関連する特集