判例詳解シリーズ第１段のスルガ銀行vs日本IBM事件。前回に続いて第３部は「プロジェクトマネジメント義務総論」。
目次
第１ 事案の概要
第２ 一審の判断
第３ プロジェクトマネジメント義務総論 （本エントリ）
第４ 企画・提案段階におけるプロジェクトマネジメント義務
第５ プロジェクト推進中におけるプロジェクトマネジメント義務
第６ 基本合意書・最終合意書の意義
第７ 議事録等に基づく事実認定
第８ 損害の額と，責任限定条項の解釈
第９ 過失相殺と損益相殺
プロジェクトマネジメントとは
この裁判例では，一審，控訴審を通じて「プロジェクトマネジメント義務」の内容及び範囲が注目された。「プロジェクトマネジメント」自体は，法的概念でもなく，特に真新しいものでもない。私も前職自体は「プロジェクトマネジャー」として仕事をしていたし，90年代でも一定規模のシステム開発プロジェクトでは，「プロ管」と呼ばれるチームがあった（現在は「PMO(Project Management Office)」と呼ばれることが多い）。プロジェクトマネジメントとは，「チームに与えられた目標を達成するために、人材・資金・設備・物資・スケジュールなどをバランスよく調整し、全体の進捗状況を管理する手法」だとされる*1。どんなシステム開発プロジェクトにおいても必要な作業だといえる。
プロジェクトマネジメント義務とは
システム開発は，ユーザがベンダにソフトウェア（プログラム）の作成を委託することを要素とする請負契約だとされることがあるが，典型的な請負契約と異なるのは，目的物であるシステムの開発にはベンダの作業のみならず，ユーザからの要件提示，情報提供，意思決定などの協力が不可欠であるという点であり，「共同作業」という側面があるという点である*2。共同作業であるということは，仮にシステム開発の作業が頓挫した場合（完成しなかった場合）に，直ちにそれがベンダに帰責すべきものであるかは明らかではないことを意味する（下図の争点２に関する箇所）。
システムが完成しなかった場合における責任がいずれにあるのかということを検討する際に用いられる概念が「プロジェクトマネジメント義務」であるといえる。
そして，裁判例にて登場したのが，前掲注の東京地判平16.3.10である。
ベンダは、システム開発の専門業者として、自らが有する高度の専門的知識と経験に基づき、本件電算システム開発契約の契約書及び本件電算システム提案書に従って、これらに記載されたシステムを構築し、段階的稼働の合意のとおりの納入期限までに、本件電算システムを完成させるべき債務を負っていたものである。
したがって、ベンダは、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、ベンダは、注文者であるユーザのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務（以下、これらの義務を「プロジェクトマネージメント義務」という。）を負っていたというべきである。
本件では，ユーザ・ベンダ間の契約において，ベンダがプロジェクトマネジメントを負うことが定められていたわけではない*3。そのほかにも，具体的に「プロジェクトマネジメント義務」という用語を用いていないまでも，ベンダがユーザに対して働きかける，説明する，提言するなどの義務があるとした裁判例があるが*4，いずれもそのような義務内容が契約書にて明記されていない。このように，裁判実務においては，ベンダは，ユーザに対し，明示的な合意がない場合でも，「プロジェクトマネジメント義務」を負うと考えられているのが一般的である。具体的なプロジェクトマネジメント義務の内容，範囲，程度は，個々のプロジェクトによって異なる。スルガIBM事件控訴審でも次のように「契約文言等から一義的に定まるものではな」いと述べている。
XとYとは，本件システム開発において，Yが，事業・業務要件定義，要件定義，外部設計工程，内部設計工程，プログラミング工程（実装工程），総合テスト，システムテスト，運用テストの全てを担当し，本件システム開発の完成まで受任することとして，３つの基本合意と１６個の個別契約を締結した。Yは，前記各契約に基づき，本件システム開発を担うベンダとして，Xに対し，本件システム開発過程において，適宜得られた情報を集約・分析して，ベンダとして通常求められる専門的知見を用いてシステム構築を進め，ユーザーであるXに必要な説明を行い，その了解を得ながら，適宜必要とされる修正，調整等を行いつつ，本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。
また，前記義務の具体的な内容は，契約文言等から一義的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すなわち，システム開発は必ずしも当初の想定どおり進むとは限らず，当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり，想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面に応じて，ユーザーのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。
プロジェクトマネジメント義務が生じる根拠として，「ベンダ＝専門家」，「ユーザ＝素人」という情報や能力の格差があると考えられる。裁判例でも，しばしば，「ベンダは情報技術の専門家として」などといった表現が登場するからである。
そうすると，典型的な「専門家対素人」という構図が当てはまらない場合には，プロジェクトマネジメント義務の主体や範囲は変わってくることもあり得るだろう。例えば，ユーザが，自らの業務をサポートする専門家としてコンサルティング会社を起用していたり（ユーザ＝素人という構図が崩れる），元請ベンダと下請ベンダ間の紛争だったり（どちらも専門家）する場合である。
本件では，ベンダが業界トップクラスのベンダであるということから，上記の構図（ベンダ＝専門家，ユーザ＝素人）という構図に基づいて，結果的にベンダであるYが重い責任を負うこととなった。
次回以降は，開発プロジェクトの各フェーズにおけるベンダのプロジェクトマネジメントの内容について詳しく見ていく。
*1:この定義は，http://e-words.jp/w/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88.htmlに拠った
*2:例えば東京地裁平16.3.10では，ベンダとユーザの共同作業というべき側面があるということを明示的に述べている。
*3:これと対をなすユーザの「協力義務」については，契約書に言及されていた。
*4:例えば，東京地判平9.9.24 http://d.hatena.ne.jp/redips+law/20130503/1367593289 や，東京地八王子支判平15.11.5 http://d.hatena.ne.jp/redips+law/20120112/1327155178 など
