システム開発におけるプロジェクトマネジメント義務とは

システム開発は、その業務を発注するユーザーと、受注するベンダーで、相互に協力しあうことではじめて進んでいくものです。

企業で用いるITシステムを開発するプロジェクトは、すべてが計画通り・想定通りに進むことは滅多にありません。むしろ大なり小なり多くのトラブルや課題に見舞われつつも、ひとつづつそれを乗り越えながら進んでいくということのほうが多いものです。そこでは、ユーザー側とベンダー側で歩調を合わせる努力ももちろん重要ですが、紛争場面を想定した危機管理も重要になります。

法律的な観点からは、互いにどのような義務を負い、そして相手に何を権利として主張できるのかを明確化することが、危機管理の第一歩だといえます。本記事では、ベンダー側が一連のプロジェクトに対してどのような法的義務を負っているのかについて、プロジェクトマネジメント義務を中心に解説していきます。

ベンダー側のプロジェクトマネジメント義務とは

はじめに、ベンダー側のプロジェクトマネジメント義務の内容をみてみましょう。

裁判例によると、プロジェクトマネジメント義務の内容は以下のとおりです。

-合意に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見　に努め、これに適切に対処する義務

-ユーザーの開発へのかかわりについても適切に管理し、システム開発について専門的知識を有しないユーザーによって開発作業を阻害する行為がなされることのないようにユーザーに働きかける義務

これは、ユーザーが意思決定をすることを求められる事項や解決すべき懸念事項について課題と期限を示すこと、ユーザーの意思決定が遅れた場合に生じる支障を示すこと、ユーザーの意思決定を促すようベンダーがアドバイスをすること、開発の進行具合により受け入れることのできない要望がある場合は、理由を十分に説明し、ユーザーの要望を拒否することを指します。

このように、ベンダー側には、開発作業を進めると同時に、ユーザーが意思決定をすることを促し、システム開発が成功するよう努力する義務があります。

ユーザー側の協力義務

もっとも、システム開発において、ベンダーだけがあらゆる義務を一方的に引き受けるわけではありません。もともとは、発注者側の企業で使うITシステムである以上、発注する側にとってもそのシステム開発プロジェクトは「他人事」でいいはずはありません。

システムを開発する技術力・組織力を頼って外部の専門家を活用するにしても、内部からのガバナンスは及んでいて然るべきです。外部の専門家の力を引き出すための努力なくして、すべて他人事で必要な作品を納品するなどということは不可能です。この意味では、ユーザー側にも、システム開発に協力する義務というものはあります。

ユーザー側が果たすべき協力義務には以下のようなものがあります。

　①ユーザーが主体的にリスク分析を行い、内部の意見調整を適切に行って見解を統一したうえで要望をベンダーに伝える

　②成果物を確認する

　③ベンダーからの協力要請に応じる

ユーザー側が、システムに求める機能を明確にベンダー側に伝え、積極的に開発に協力することが求められます。

プロジェクトマネジメントは容易ではない

ITシステムが、細かい部品の組み合わせで成り立つものであるという点は、画面のみをみているユーザー側からは自覚しにくい点かもしれません。しかし、システム開発のプロジェクトをマネジメントすることの難しさについて考えるうえでは非常に重要です。ITシステムがそういうものであるからこそ、ベンダー側には、細やかな注意力と同時に、全体像を簡潔に整理する構想力・俯瞰力も同時に求められるのです。

画面をみているだけでは想像もつかないところに業務の難しさがあり、またそれは視点を変えれば、プロジェクトが「炎上」する理由そのものでもあります。まずはこうした点を理解し、「ITシステムを開発するプロジェクトをマネジメントすることは、決して簡単なことではない」という点を知ることが、プロジェクトのリスク管理について学ぶ際の大前提となるでしょう。

プロジェクトマネジメント義務違反の場合に起こりうること

では、プロジェクトマネジメント義務の違反があった場合には、具体的にどのようなことが起こるのでしょうか。

これについては、なにか明確な条文があって、「プロジェクトマネジメント義務とは、このようなものである」という決まりごとが用意されているわけではありません。

しかし、過去の裁判例から、ベンダーに義務違反があった場合にユーザーがどのようなことができるかについては、ある程度一貫したスタンスのようなものを読み取ることが出来ます。

ベンダーに義務違反があった場合は、ユーザーはベンダーに対して損害賠償や契約解除を主張することになります。ただし、ユーザーにも問題があると、ベンダーに帰責性がないと判断されたり、過失相殺をすることになり損害賠償額が減額する可能性があります。

一方で、ユーザーに協力義務違反があった場合は、それにより仕事が完成しなかったとして危険負担（民法536条2項）、または債務不履行を根拠としてベンダーからユーザーに対し、報酬相当額を請求することが考えられます。

プロジェクトマネジメント義務を示した裁判例

プロジェクトマネジメント義務というものについて説明した代表的な裁判例として、以下のものがあります。

以下の事案は、システム開発において、納入期限に遅れが発生したことや、ベンダーが当初の見積りの増額を求めたことなどから裁判にまで争いが進展したものです。ユーザーとベンダーの責任の切り分けをどのようにして行うべきかをめぐり、争いが裁判にまでもつれるという、いわゆる「炎上案件」の最たる例とも言えるかもしれません。

被告は，システム開発の専門業者として，自らが有する高度の専門的知識と経験に基づき，本件電算システム開発契約の契約書及び本件電算システム提案書に従って，これらに記載されたシステムを構築し，段階的稼働の合意のとおりの納入期限までに，本件電算システムを完成させるべき債務を負っていたものである。
したがって，被告は，納入期限までに本件電算システムを完成させるように，本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は注文者と打合せを重ねて，その意向を踏まえながら行うものであるから，被告は，注文者である原告国保のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下，これらの義務を「プロジェクトマネージメント業務」という。）を負っていたというべきである。

東京地判平成16年3月10日

上記の判決文の要旨から、細かい文言や複雑な事案の経緯を読み解くことは重要ではありません。なによりも、「プロジェクトマネージメント義務」という文言がそのまま使われている点こそがポイントです。明文化された条文こそないものの、裁判所が主体となって、法的責任の切り分けを行うための指針を確立しようとする姿勢が見て取れます。

上記判決文の内容を平易にまとめ直したうえで、箇条書きにして整理しましょう。ここでいう「プロジェクトマネージメント義務」とは、

• 事前の計画（開発手順・手法・工程など）に沿って実作業を進めること
• 実作業が円滑に進んでいるかどうかの進捗管理を行うこと
• もし実作業が円滑に進まなくなるような「阻害要因」があるなら、その発見と対策を適宜講じていくこと

さらには、上記３点につき、

• ベンダー側の独りよがりな自助努力ではなく、必要な協力をユーザー側に適宜求めるなど、コミュニケーションの努力も同時に行うこと

などを総称したものであると整理することができます。

なお、システム開発は、法律的には準委任契約か請負契約の形で締結されるケースがほとんどです。そして準委任契約は、単純に言えば、「報酬を得て、その報酬に応じた精度等で仕事を行う」という契約なので、プロジェクトマネジメント義務も、その実現すべき「精度等」の中に吸収される概念、とも整理できます。

ただ、議論のあるテーマではありますが、「頼まれた通りのものを作る」という契約である請負契約の場合も、やはりプロジェクトマネジメント義務は発生し得ると考えられています。理由は既に述べたとおり、システム開発というものは、準委任契約であろうと請負契約であろうと、やはりプロジェクトのマネジメントが重要であることには変わりがなく、ベンダー側はそれを行うべきだと考えられているからです。

契約締結前にも課せられるプロジェクトマネジメント義務を示した裁判例

また、プロジェクトマネジメント義務は、契約が締結する前段階でも課せられる場合があると考えられています。以下に引用する裁判例は、契約する前段階、すなわち契約前の各種提案や企画を出している段階でも、ベンダー側にプロジェクトマネジメント義務がある旨を示したものです。

以下の事案は、プロジェクトが途中で頓挫した事案につき、契約締結前における企画や、提案段階における見積りやユーザー側への説明の不備を理由として、プロジェクトマネジメント義務を認めることができないかが争われたものです。一般的にも、企画や提案という業務が、契約が締結される前段階のものであることから、そうした義務を認めることが法律上可能であるかが問題となりましたが、裁判所はこれを認めました。

前掲の裁判例におけるプロジェクトマネジメント義務の考え方は、契約が成立する前段階の話にも及ぶことが、以下を読むとよくわかることでしょう。

企画・提案段階においては，プロジェクトの目標の設定，開発費用，開発スコープ及び開発期間の組立て・見込みなど，プロジェクト構想と実現可能性に関わる事項の大枠が定められ，また，それに従って，プロジェクトに伴うリスクも決定づけられるから，企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は，システム開発を遂行していくために欠かせないものである。そうすると，ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する義務があるというべきである。このようなベンダの検証，説明等に関する義務は，契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ，控訴人はベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。

東京高判平成25年9月26日

なお、IT系のプロジェクトの話題に限らず、あらゆる商取引・法律が関係する交渉事全般において、契約が締結される前段階においても、その相手方に対して一定の法律上の義務があるという考え方は元々あるものです。

得てして大きな取引ほど、契約というゴールに辿りつくまでの「歩み寄り」のプロセスは長いものとなりがちです。そのプロセスにおいても、相手方に対して誠実であるべきという話は、少なくとも道義的な話としてはよくわかるところでしょう。簡単に言ってしまえば、こういった話は、単なる心情的な道徳感情にとどまるものではなく、法律上も意味のあるものです。（以下に条文を引用。傍線は筆者が追記したものです。）

民法第1条2項
権利の行使及び義務の履行は、信義に従い誠実に行わなければならない。

上記の内容を端的にあらわしているのが、判決文における「信義則」というキーワードだともいえます。

なお、本記事で掲載してきた裁判例も、ある側面では、「ユーザー側の協力義務とベンダー側のプロジェクトマネジメント義務の境界を引くための指針」といった意味合いを持つものです。ITシステムの開発におけるユーザー側の協力義務に関しては、以下の記事をご参照ください。

まとめ：プロジェクトマネジメント義務違反に関するトラブルは弁護士に相談を

本記事では、システム開発におけるプロジェクトマネジメント義務というものについて、全般的な整理を試みました。システム開発には様々な課題・トラブルがつきものですが、いざそうした状況に見舞われたときに大切になるのは、どんな紛争場面にも通底する「基礎」であるようにも思われます。個々のイレギュラー事態のありかたには、たしかに無限のバリエーションがあるでしょう。

しかし、そうした事態を前に「そもそも法的な義務をどちらがどれだけ引き受けていたのか？」と問うてみることの重要性は、事案それ自体の個別性を超えた、ある種の普遍性を持っています。

場当たり的なトラブルシューティングに終始するのではなく、建設的な課題の切り分けによる解決を目指すにあたり、そのヒントもやはり、法と過去の裁判例のなかにあるもののように思われます。

プロジェクトマネジメント義務違反に関するトラブルが発生した場合は、すぐに弁護士に相談しましょう。