DX対応・民法改正で変わる情報システム取引に関する契約⑥

株式会社シナプスイノベーション法務室です。

本連載企画では、前回から、2020年12月に経産省・IPAが連名で公表した「情報システム・モデル取引・契約書」第2版（以下、「モデル契約第2版」といいます）の主な改訂ポイントを取り上げております。
前回は、モデル契約第2版の解説で触れられている「プロジェクトマネジメント義務／協力義務」の概要を説明させていただきました。
今回は、モデル契約第2版の解説や、そこで引用されている裁判例を手掛かりとして、この「プロジェクトマネジメント義務／協力義務」がシステム開発の工程の中でどのような場面で問題となってくるのかを、素描してまいります。

開発におけるスコープと費用・納期・品質の関係

システム開発においては、実際の開発に当たる際に、当該システム開発にかかるスコープ（開発対象・範囲）を確定し、それにかかる費用（コスト）・納期・品質を見積もることになります。
このスコープと費用・納期・品質の関係を図にして示すと、以下のようになります。¹

プロジェクトの開始段階では、上記のスコープ・費用・納期・品質のバランスが取れるよう、ベンダにて成果物や業務内容の見積を行った上、個別の開発プロセス毎の個別契約に合意するのが通常です。
しかし、プロジェクトの規模が大きくなると往々にして、当初の見積と比較して、上記の「QCDSの三角形」のバランスが崩れてしまうことが起こりがちです。
そこで、プロジェクトや契約の見直しが必要になってくるのですが、その際に「ベンダのプロジェクトマネジメント義務／ユーザの協力義務」というものが顕在化してくることになります。

本稿ではシステム開発のプロセスを、モデル契約第2版の解説を参考に、「要件定義を含む企画段階」「開発段階」に大きく分けた上で、「ベンダのプロジェクトマネジメント義務／ユーザの協力義務」がどのように位置づけられるのか、同解説引用の裁判例も踏まえつつ、検討してまいります。

要件定義を含む企画段階

システム開発のプロセスを大きく「要件定義を含む企画段階」「開発段階」に分けた場合、「要件定義を含む企画段階」は「開発段階」との関係の上で、開発における「QCDSの三角形」を作っていく段階、と位置付けることができます。²

この段階では、一般的には、どのような業務を開発対象となるシステムで実現したいのかについての知見（当該業務の専門知識や経験、意図）を持ち、かつ意思決定を行うのは、当該システムを企画し、システム開発後には当該システムを運用して業務を行っていくユーザ自身となります。 ³

したがってユーザには、自らの業務内容や開発を求める情報システムの具体的な仕様をベンダに説明する等の主体的な役割が求められることになります。

ベンダの基本的な位置づけは、上記のようなユーザの主体的な意思決定を支援する、というものになります。
もっとも、システム開発プロジェクトの目標の設定や、上記の「QCDSの三角形」にいう開発スコープや費用（コスト）、納期等、後続の開発段階についての重要な意思決定がなされるのが、この「要件定義を含む企画段階」ですから、ベンダとしても後続の「開発段階」で「QCDSの三角形」が適切に維持されるように支援を行う必要があります。

モデル契約第2版解説でも、ある裁判例をひいて「システム完成に向けた開発協力体制が構築される以前の企画・提案段階において、ベンダにシステム開発技術等に関する説明責任が存するとともに、ユーザにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ、システム開発について自らリスク分析をすることが求められると判示している」とされている³のは、上記のような観点から理解すべきかと思われます。

開発段階

後続の「開発段階」は、「要件定義を含む企画段階」で設定された「QCDSの三角形」に従い、実際にシステム開発を行っていく段階となります。
ただ、実際に開発を進めていくうちに、当初にバランスが取れていたつもりであった「QCDSの三角形」に何がしかの歪みが生じてしまっている、ということがどうしても起こりがちです。
そこでステアリングコミッティを行った上、変更管理を行ったり（場合によっては）変更契約を締結したりして、上記の歪みを是正していくことになってきます。
これがうまくいかず、残念ながらプロジェクトが頓挫してしまい、裁判所でその後始末に至った、というのが、システム開発における裁判例で取り上げられた事件のごく大まかな経過です。
「ベンダのプロジェクトマネジメント義務／ユーザの協力義務」は、プロジェクトが頓挫した事件において、ベンダとユーザのどちらに責任があったのか、ないしはより責任が大きかったのはどちらか、を分析していくための道具立て、といった側面がございます。

モデル契約第2版解説やそちらで引用されている6つの裁判例をザックリとまとめてしまうと、以下のように整理ができるものかと思われます。

ユーザとの関係では、ベンダはシステム開発の専門家、という位置づけとなりますが、専門家として第一にきちんとなすべきことは、「プロジェクトの進捗状況を適切に把握して、管理すること」となります。
モデル契約第2版解説でも、「開発段階においては、システム開発自体の専門性はベンダにあり、実際の開発プロジェクトを進めていく上で費用が当初想定していたものより増大してしまうおそれや開発スケジュールの遅延の兆候等を察知しやすい立場にあるので、それらの状況について適宜ユーザと共有しつつ、円滑にプロジェクトを進めていく役割がベンダに期待されている」⁴とされているのは、このような趣旨かと理解することができます。

その上で、ベンダとしてはシステム開発契約の目的が達成されるか、という観点から、ユーザに対し適切な働きかけを行うことが求められます。
このユーザへの適切な働きかけの内容としては、ユーザに対する説明義務が求められることが、裁判例上も多い、とされています。

たとえば、モデル契約第2版解説では、以下のような裁判例が紹介されています。

◆「ユーザからの変更の申入れに応じることが、開発対象のシステムにおける不具合・障害の発生の可能性を増加させ、そのために検収終了時期を大幅に遅延させ、開発契約の目的を達成できなくなる場合においては、ベンダがその専門的知見、経験に照らして、これを予見し、ユーザに対しこれを告知して説明すべき義務を負う」とした事案⁴

◆「ベンダは、解決すべき必要がある懸案事項等の発生の徴候が認められた場合に
は、それが本格的なものとなる前に、そのような予防や回避について具体的にユーザに対して注意喚起をすべきであるし、懸案事項等が発生した場合は、それに対する具体的な対応策及びその実行期限を示し、対応がされない場合に生ずる支障、複数の選択肢から一つを選択すべきには、対応策の容易性などそれらの利害得失等を示した上で、必要な時期までに原告において対応することができるように導く義務がある」とした事案。⁵

他方、ユーザ側の協力義務としては、プロジェクトへの積極的な関与や意思決定が求められることが多いです。
「開発段階」に入った後においても、ユーザ自身が行っていただくべきこととして、内部の意見調整や見解の統一、最終的な開発機能の決定、成果物が出来上がった後の検収など、様々なタスクが出てくることになります。

また、近時の裁判例では、「ベンダの開発行為をユーザが阻害しないこと」がユーザの責任として取り上げられることも散見されるようになっています。
モデル契約第2版解説で取り上げられている裁判例としては、以下のようなものがあります。

◆仕様凍結合意をしたにもかかわらずユーザが大量の追加開発要望を出し、ベンダがこれに対応せざるを得なかったことから、システム開発が遅延したという事案　において、「契約及び仕様凍結合意に反して大量の追加開発要望を出し、ベンダにその対応を強いることによってシステム開発を妨害しないという協力義務（不作為義務）に違反した」としてユーザに債務不履行に基づく損害賠償責任を認めた事案。⁶

◆システム間結合テストの段階において、ユーザが、ベンダが修正、対応すべき課題を具体的に示すことなく、業務要件が成果物にどのように反映されているかの資料の提出など、当初の契約等にも定めのない要求を繰り返し、最終成果物の納入期日までに最終検収に耐える品質レベルに到達できるものではないとの一方的な判断によってテスト実施に向けた協議を打ち切ったということで、ベンダのシステム開発債務の履行不能についてユーザに帰責性がある、とした事案。
これらの裁判例は、「開発段階」の終わりの方でなされたユーザからの要望につき、変更要望の具体的な内容やタイミング、そのボリュームも踏まえた上で、ベンダの開発行為に対する阻害がなされたものとして、ユーザの協力義務違反が認定されたものです。⁶

おわりに

本稿では、モデル契約第2版解説とその引用裁判例を参考に、「ベンダのプロジェクトマネジメント義務／ユーザの協力義務」の内容を、開発におけるスコープ・費用・納期・品質の関係と照らし合わせつつ、大まかに整理してみました。
次回は、変更の協議不調に伴う契約終了のオプション条項〔一定の事由がある場合にベンダの解約権を認めるB案〕につき、解説をしていければ、と考えております。

▼注釈

1. 原田 騎郎=吉羽 龍太郎「［要求の変化に柔軟に対応する］実践見積りスケジュール，スコープ，スキル」Web+DB PRESS Vol.93〔技術評論社〕2016 P27参照。
2. もちろん、「要件定義を含む企画段階」そのものについても、ベンダによる見積や「QCDSの三角形」を想定することは可能です。ここでは後続の「開発段階」でのプロセスとの関係を重視して説明しております点、ご留意ください。
   
3. モデル契約第2版解説P53参照。
4. モデル契約第2版解説P120参照。
5. モデル契約第2版解説P116参照。
6. モデル契約第2版解説P54注85参照。