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

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

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

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

システム開発はなぜ外注されるのか

ところで、なぜ企業のITシステムを開発するプロジェクトが往々にして、システム開発会社に外注されるのかを考えたことはあるでしょうか。システム開発という市場を支えるIT業界は、よく建設業界に似ていると言われることがあります。似ていると言われる所以について簡単に整理しておくと、

  1. 一朝一夕に新たな「作品」が出来上がるわけではなく、細かい作業の積み重ねで、はじめて大きな成果物が出来上がるという点
  2. 1.といった事情により、長期間にわたって多人数の人手を確保しながらプロジェクトを進めていく必要があるという点
  3. 2.といった事情がありつつも、どんな人でもいいからただ人手があればいいという話ではなく、その業界ごとの特殊スキル・専門的知識をもつ人材が必要とされるという点
  4. 3.といった事情があるものの、一度プロジェクトが終了すればそれ以降はあまり人手が必要でなく、企業からみて自社雇用で必要な人材を確保するのはコスト面で見ても割に合わず、外注するほうが結果的に安上がりですむ場合が多いという点
  5. 4.といった事情により、システム開発という仕事は、企業向けのサービス業として大規模な商取引につながりやすく、ベンダー側も下請業者などを巻き込んだ大掛かりな業態に転化しやすい

などを挙げることができます。

このように、IT業界と建設業界には多くの共通点があります。実際、ひとつのシステムはまさに、精巧な建造物などと同じように細かい部品同士を緻密に組み合わせて、作り上げていくものです。「直感的に操作法がわかる見やすい画面」、「処理がモタつくことなくサクサク動く」そういった「使い勝手のよいシステム」ほど、その実、細かい部品の積み重ね・積み上げによって成り立っていることが多いものです。

プロジェクトをマネジメントすることは簡単ではない

プロジェクトのリスク管理を前提として進めていく。

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

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

ベンダーが負うプロジェクトマネジメント義務とは

では、システム開発全般に対して、受注者たるベンダーはそのプロジェクトに対し、具体的にどのような義務を負っているのでしょうか。これについては、なにか明確な条文があって、「プロジェクトマネジメント義務とは、このようなものである」という決まりごとが用意されているわけではありません。しかし、過去の裁判例から、裁判所がユーザー側の責任とベンダー側の責任をどのように切り分けていこうとしているのかについては、ある程度一貫したスタンスのようなものを読み取ることができます。

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

プロジェクトマネジメント義務というものについて説明した裁判例として、代表的なものには以下のものがあります。以下の事案は、システム開発において、納入期限に遅れが発生したことや、ベンダー側が当初の見積りの増額を求めたことなどから裁判にまで争いが進展したものです。ユーザーとベンダーの責任の切り分けをどのようにして行えばよいかをめぐって、争いが裁判にまでもつれるという、いわゆる「炎上案件」の際たる例とも言えるかもしれません。

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

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

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

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

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

またさらには、上記三点につき、

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

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

なお、システム開発は、法律的には準委任契約か請負契約の形で締結されるケースがほとんどです。そして準委任契約は、単純に言えば、「報酬を得て、その報酬に応じた精度等で仕事を行う」という契約なので、プロジェクトマネジメント義務も、その実現すべき「精度等」の中に吸収される概念、とも整理できます。ただ、議論のあるテーマではありますが、「頼まれた通りのものを作る」という契約である請負契約の場合も、やはりプロジェクトマネジメント義務は発生し得ると考えられています。理由は既に述べたとおり、システム開発というものは、準委任契約であろうと請負契約であろうと、やはりプロジェクトのマネジメントが重要であることには変わりがなく、ベンダー側はそれを行うべきだと考えられているからです。

契約締結前にも課せられるプロジェクトマネジメント義務

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

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

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

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

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

なお、IT系のプロジェクトの話題に限らず、あらゆる商取引・法律が関係する交渉事全般において、契約が締結される前段階においても、その相手方に対して一定の法律上の義務があるという考え方は元々あるものです。得てして大きな取引ほど、契約というゴールに辿りつくまでの「歩み寄り」のプロセスは長いものとなりがちです。そのプロセスにおいても、相手方に対して誠実であるべきという話は、少なくとも道義的な話としてはよくわかるところでしょう。簡単に言ってしまえば、こういった話は、たんなる心情的な道徳感情にとどまるものではなく、法律上も意味のあるものです。(以下に条文を引用。傍線部は筆者が追記したものである。)

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

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

ユーザーだってシステム開発では一定の義務を負う

ユーザー側の協力を得てシステム開発を進めていきます。

もっとも、システム開発において、ベンダーだけがあらゆる義務を一方的に引き受けるわけではありません。もともとは、発注者側の企業で使うITシステムである以上、発注する側にとってもそのシステム開発プロジェクトは「他人事」でいいはずはありません。システムを開発する技術力・組織力を頼って外部の専門家を活用するにしても、内部からのガバナンスは及んでいて然るべきです。外部の専門家の力を引き出すための努力なくして、すべて他人事で必要な作品を納品するなどということは不可能です。この意味では、ユーザー側にも、システム開発に協力する義務というものはあります。

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

まとめ

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

しかしそうした事態を前に「そもそも法的な義務をどちらがどれだけ引き受けていたのか?」と問うてみることの重要性は、事案それ自体の個別性を超えた、ある種の普遍性を持っています。場当たり的なトラブルシューティングに終始するのではなく、建設的な課題の切り分けによる解決を目指すにあたり、そのヒントもやはり、法と過去の裁判例のなかにあるもののように思われます。

モノリス法律事務所

モノリス法律事務所は、元ITエンジニアで企業経営経験のある代表弁護士の下、約60社のIT・ベンチャー企業の顧問弁護士等を勤めております

Phone: 03-6262-3245 (平日10時-17時)
Email: kawase@monolith-law.jp

モノリス法律事務所

モノリス法律事務所

モノリス法律事務所は、IT・インターネット・ビジネスに強みを持つ、東京・大手町の法律事務所です。

シェアする