以上のとおり、システムが「完成」したとすれば、一応は報酬の請求権が発生するのに対し、システムが「完成」していないとすれば、報酬は発生しません。このように、システムが「完成」しているか否かは、報酬請求権が発生しているか否かの判断に直接的な影響があるので、システムが「完成」しているか否かは、ソフトウェア開発の解決をする上では非常に重要なターニングポイントとなるのです。

開発されたソフトウェアが「完成」しているか否かが争点となった裁判例として、東京地裁平成14年4月22日判決を紹介したいと思います。

ソフトウェア開発契約に限らず、建築紛争などの請負契約においても仕事の「完成」が問題となった事案が少なくありませんでしたが、裁判所は「最終工程基準」に基づき、請負契約の「完成」か否かが判断されました。すなわち、裁判所は、請負人が仕事を完成させたか否かについて、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであるとしました。

そんな中、東京地裁は、ソフトウェア開発でも、建築紛争と同様の基準である「最終工程基準」に基づいて完成未完成を判断しています。すなわち、裁判所は、ベンダーが開発を完成させたか否かについても、開発行為が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであるとしたのです。

その上で、東京地裁は、予定されていた工程のうち、ベンダーが要件定義・概要設計に始まり、最後のデータ移行までの各工程を終了し、順次納品を行い、ユーザーが本件システムを本格稼働させ、使用を継続していることが認められることなどを理由、本件システムを完成させたと判断しました。

「完成」の成否が問題となったその他の事案としては、東京高裁平成26年1月15日判決があます。ここでも、裁判所は納品日には本件ソフトウェア開発個別契約で予定された最後の工程まで終えて納品がされるとの認識を有していたものと認められることを理由に、「最終工程基準」に基づいて完成未完成を判断しました。

これらの裁判例からいえることは、ソフトウェア開発が「完成」しているかどうかの判断にあたっては、①当初予定している工程の内容と実際の工程の経過に異同があるか（とりわけ、実際の納品がなされているか）、②検収がなされているか、③ユーザーが実際にシステムを使用しているか否か、④納品からどのくらいの期間経過してからバグが問題となったのか、が重要な判断要素となります。その他にも、⑤システムが本番稼動していなくとも、本番稼動のための準備行為が行われているか、⑥運用・保守契約が締結されているか、⑦導入研修が実施されたか、⑧操作マニュアルが作られたか、⑨不具合に関するユーザーからの指摘の数・程度等が、システムの「完成」の有無を判断する上での副次的な要素となるでしょう。

上記の図にそって考えていくと、そもそもシステムが部分で完成していないと判断された場合、未完成の責任は、原則としてベンダーが負います（東京地裁八王子支部平成15年11月5日判決）。

未完成の場合にベンダーが問われるべき責任の内容としては、プロジェクトマネージメント義務（PM義務）またはプロジェクトマネージメント責任（PM責任）です。PM義務の内容について、東京地裁平成16年3月10日判決は、「ベンダーは、期限までに完成させるよう、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負う（これを「プロジェクトマネージメント義務」という。）」と判示されています。

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

すなわち、スケジュール遅滞やスコープ変更をする必要が生じた場合、ベンダーはユーザーと積極的に情報共有しプロジェクトに及ぼす影響を十分に説明したり、ユーザーから変更を求められた場合には、それらの情報を十分に説明することが重要であるといえます。

他方で、ユーザーが責任を負う場合もあります。東京地裁平成16年3月10日判決によれば、「オーダーメイドの開発では、ベンダーのみではシステムを完成させることはできないので、ユーザーが開発過程において、内部の意見調整を行う等役割を分担することが必要であって、ユーザーは、ベンダーから必要な協力を求められた場合、これに応じて必要な協力を行うべき義務（これを「協力義務」という。）を負っていると」述べています。

また、東京地裁平成22年7月22日判決によれば、「要件定義工程では、要件を決める責任も原則としてユーザーにある」と判示されています。さらに、「要件を拡大させた場合、当初の契約金額で開発せよと要求することはできない」とまで示されています。

ユーザーは、PM義務を尽くしたことの立証責任を負いますが、PM義務を尽くしたことの立証は、そもそも義務内容が不明確かつ広範囲に及んで立証命題が特定しづらい上、開発プロジェクトのときから2～3年たった後に義務履行の立証を求められることも多いことから、困難を極めます。

とはいえ、PM責任を果たしたことを示す証拠を適切に提出できれば、ベンダーは責任を負わないとの結論に達しやすくなります。

そのような証拠の種類としては、契約書、提案書、記名・押印等のあるレター、紛争発生後の内容証明郵便、用語辞典、技術辞典などの公刊物、議事録、課題管理票、仕様変更一覧等の管理票、メール（内部・相手方に提示されたもの）、設計書、仕様書、証言、陳述書等があります。

特に、この中でも、議事録作成・保存が判決との関係でプロジェクト中の義務履行（懈怠）を示す最重要ツールであると言えます。また、打合せ議事録やメールは、仕様変更がされた経緯や開発工程の遅延原因を探る証拠としても重要です。議事録の作成・保存上の注意としては、①会議体の位置づけを明確にする（契約書に定められた「連絡協議会」なのか等）こと、②相手方の確認・閲覧の記録があるかを示すこと、③プロジェクト固有の方言ばかりでは、第三者が読んで理解できないので、第三者（裁判官）が読んでわかるかどうか必要に応じて補足説明すること、④議事録は何度も修正されていることがあるので、内容の有利不利を問わずに履歴を確認しておくこと、⑤依頼・要望なのか、合意なのか、事実の確認なのかを明確にすること、⑥録音されているときは、録音内容との齟齬がないか確認すること、が挙げられます。

また、課題管理・仕様変更管理票については、PM義務、協力義務履行（懈怠）の実態を立証する有効なツールです。件数や工数など定量的に評価しやすいために全体をつかみやすく、決定・対応を促したことや事情により期限までに対応できないことは議事録よりも客観的に示しやすい場合があるので、起票、期限、終了日、責任者などを記録する等しておくと良いかと思われます。また、文書の位置づけを、契約書あるいは下位文書としての「プロジェクト管理規程」等に照らして確認することも必要であると思われます。

さらに、ユーザーからベンダーに対し「遅延（あるいは悪品質）の程度、原因（責任の所在）と改善策」を示した書面の提出を求められることがあります。気をつけたいこととして、責任者名義で自己に不利益な事実を認める内容を含む書面は、重要な証拠となるので、不利益な書面が残ってしまったときは、提出を求められた経緯をメール等で確認することも必要になってくるかと思います。

システムが完成していない場合、ベンダーは一切の報酬が請求できないかが、問題となります。

この点を判断した東京地裁平成25年7月19日は、原告がウェブサイト構築業務を委託した被告に対し、被告の債務不履行に基づき契約を解除したとして既払金の返還及び損害賠償を求めた事案です。裁判所は、「契約が可分でかつ分割された給付につき、相手方が利益を得ていると認められる場合には，未履行部分についての一部解除しかすることができないと解するのが相当である」としながらも、「構築業務を3段階に分けて進捗管理されている本件契約において、被告には第2段階及び第3段階の構築期限で履行遅滞がある」とした上で本件契約の解除を認めました。そして、「本件契約が各段階ごとに可分なものであるとしても、作業状況に照らすと、当該可分な段階に対応する独立した給付が完了していたとはいえない」として、全部解除及び既払金の返還を認めました。つまり、業務を分割することは出来るとしつつ、その分割した業務に対応する義務を果たしていないと判断したのです。

いずれにしても、契約が可分であり，かつ，分割された給付につき相手方が利益を得ていると認められる場合には，未履行部分についての一部解除しかすることができないが、それ以外の部分については請求ができるということになります。

また、東京地裁平成25年7月18日判決の請負契約では、各工程であらかじめ定められた納品物の検収の翌月末日までに、各工程に応じた報酬を支払うものと定められていました。裁判所は、「その各工程の納品物が完成して検収を受けて引き渡されている以上は，その工程に関しては，原則として，本件解除の効力は及ばず，そうでなくても，解除時点で既に完成し引き渡された部分に関しては，解除の効力は及ばないと解するのが相当である」としています。そして、解除時点において，本件請負契約における仕事の完成の度合いがどの程度であったかを検討した結果、報酬残額のうち，3割相当については本件解除の効力が及ばないが，その余は解除されたと認められると示しました。

つまり、システムが未完成でも、1つの契約について、分割検収とそれぞれの対価を定め、各工程における目的物が完成し、検収を受けて引渡しを終えているときは、当該工程について、原則として解除の効力が及ばないので、報酬の一部請求が可能であるということです。

以上、システム開発作業中におけるトラブルについて見てきました。以下、ベンダー側とユーザー側の双方からの注意点をまとめます。

まず、ベンダー側としては、システムが完成していないと判断された場合、未完成の責任は、原則としてベンダーが負います。責任の内容は、期限までに完成させるよう、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うというPM義務（またはPM責任）です。PM責任の履行が紛争の帰趨を決することになりますので、PM義務の内容を上記判例等で具体的に理解し、ユーザーとの役割分担は契約書などで明確にしたり、具体的な作業項目を規程等で定めることが必要であるといえます。

また、PM義務を尽くしたことの立証は、困難を極めます。そこで、効率的な証拠収集や選別が求められることとなります。義務を履行したことの記録を残すことが肝要です。

そして、システムが完成していない場合でも、契約が可分であり、かつ、分割された給付につき相手方が利益を得ていると認められる場合には、報酬の請求は部分的に可能になりますので、それらの請求ができるように契約を締結する等準備をしておくことも重要と思われます。