委託料が返るのは、前の工程に問題があったとき

システムの開発を外部に委託します。見積もりが来て、あとは契約を交わすだけになります。一本で頼むか、工程で分けて頼むか。

分けるほうが安心に見えます。ただし、分けると手放すものがあります。

委託料の返還を求める例が、頻発している

頻発していると書いているのは、IPAと経済産業省が公開している「情報システム・モデル取引・契約書」の第二版です。2020年12月22日に公開され、最終更新は2025年6月17日です（IPA・経済産業省、情報システム・モデル取引・契約書 第二版）。工程を分けて順に契約する形を、原典は多段階契約と呼びます。

第二版で見直された論点は五つあります。セキュリティ、プロジェクトマネジメント義務及び協力義務、契約における「重大な過失」の明確化、システム開発における複数契約の関係、再構築対応（同第二版のページ）。四つ目が、この記事の話です。

その論点が立った理由が書かれています。多段階契約においては「下流工程でトラブルが生じた際にユーザが上流工程まで遡って解除に基づく代金返還請求をしたり、損害賠償責任を追及するという紛争が頻発している」（IPA、見直しのポイント、(4)）。

分けた前の工程まで戻って、払った委託料を返してもらう例が頻発している、と書かれています。求めているのは、発注する側です。

この論点について書かれているのは、第二版と同じページで公開されている二つの解説です。「第二版公表にあたって」のPDFと、「見直しのポイント」のページ（同第二版のページ、構成とダウンロード）。以下は、その二つに書かれていることです。

裁判例は、二つの型に分けられている

「第二版公表にあたって」の第5章が、この論点を扱っています（IPA・経済産業省、第二版公表にあたって、第5章）。

その整理の起点になっているのは、最高裁の判断です。同じ当事者間の契約が二つ以上あり、「それらの目的とするところが相互に密接に関連付けられていて」いずれかが履行されるだけでは目的が達成されない場合には、一方の債務不履行を理由に両方を解除できる、と判示したものです（同PDF、第5章。最判平成8年11月12日）。

そこで、システム開発の裁判例が二つに分けられています。「①同時並行的な履行によって達成されることが予定されていた複数の契約間で問題となるケース（「並列型」）」と、「②本モデル契約のような多段階契約における前工程の契約と後工程の契約との間で問題となるケース（「直列型」）」（同PDF、第5章）。

そして、その判断がどこまで当てはまるかが書かれています。上記の最高裁の判断は①を念頭に置いたもので、「①のケースには射程が及ぶ一方、②のケースには当然にはその射程は及ばないのではないかという共通認識を得た」（同PDF、第5章）。工程を分けた契約は、②のほうです。

②を扱った裁判例も挙がっています。東京地裁の平成31年3月20日の判決で、その事案の各契約について「各契約の締結と履行の終了の積み重ねを通じて、順次段階的に達成されていくことが予定されているものであって、数個の契約の同時並行的な履行によって達成されることが予定されていた上記最判の事案とは異なる」と判示している、と紹介されています（同PDF、第5章。東京地判平成31年3月20日）。

委託料が返ったのは、前の工程に問題があったとき

では、返還が認められた裁判例は何だったのか。同じ第5章が続けて整理しています。

「下流工程におけるトラブルで上流工程における個別契約を解除したり、当該個別契約に基づく委託料を損害として請求したものが認められているケースというのは、結局上流工程自体について債務不履行があると判断しているという、それが下流工程まで進んだあとに露見するということであって、下流工程の債務不履行で上流工程の契約に影響を及ぼしているといったものではないのではないか」（同PDF、第5章）。

後の工程でつまずいたこと自体では、前の契約の解除や委託料の返還には届きません。認められたのは、前の工程にもともと債務不履行があって、それが後で見つかった場合です。

条項は増やさず、解説に追記された

この整理を契約書にどう入れるかも書かれています。「複数の個別契約の処理がどうなるかは、結局当該個別契約の関係や問題となった債務不履行次第であることから、何か契約条項として手当をするのではなく、上記のような整理を解説で追記するのがよいのではないかということで一致した」（同PDF、第5章）。

そして、その整理をどこに書いたかも示されています。「第52条（解除）の逐条解説に、上記の整理に関する解説を追記して、利用者の理解に資することとした」（同PDF、第5章）。

条文を読んでも、この整理は出てきません。解説に書かれています。

そして第二版の配布物は、二種類あります。解説付きのファイルと、条文だけのファイルです。原典の注記に「（ひな型）とあるものは、解説文は無く、条文のみとしています」とあります（同第二版のページ、構成とダウンロード）。契約書の土台にするのは条文だけのファイルでよいとしても、読むのは解説付きのほうです。

作り直しでは、要件定義の前に別の契約が入る

同じPDFの第6章が、既存のシステムを作り直す場合を扱っています（同PDF、第6章）。

いまの機能をそのまま新しいシステムに持っていく場合について、原典はこう書いています。「要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要がある。この現行システム調査を十分に行わずにシステム再構築に着手し、後のシステム開発段階でトラブルに陥った事例が多数報告されている」（同PDF、第6章）。

その調査を別の契約にする形が書かれています。「必要に応じ、ベンダとの間で、現行システム調査・分析と再構築方法の検討、想定されるリスク対策等の支援業務を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになる」（同PDF、第6章）。

続けて、こうあります。「しかし、現在動作している通りのシステムを再構築するだけ（現行踏襲）、と考えるユーザにはこの意識が薄い」（同PDF、第6章）。

調査に手間がかかることも書かれています。「企画プロセスにおける現行システム調査には、専門的な技術も必要であり、コストと時間を要する」（同PDF、第6章）。いま動いているとおりに作り直すだけ、という見立てだと、その手間が見積もりに入りません。

明日からできること

決めるのは、区切りの置き方です。

いま出ている見積もりを工程で分けるなら、それぞれの工程の終わりに何を確かめてから次に進むかを決めます。あとから前の工程の分を取り戻せないので、確かめる場所は工程の終わりしかありません。

その工程の契約書に書くのは、何を受け取るのかと、それが揃っているかを誰が見るのかです。受け取ったものが揃っているかを見るのは、次の工程の契約を交わす前です。次の契約を交わしてしまうと、前の工程の話は済んだことになります。

一方で、いくつに分けるかを先に決める必要はありません。一度でも区切れば、そこで受け取ったものを確かめられます。

作り直しなら、これに加えて決めることがあります。要件定義の前に、いま動いているものを調べる工程を置くかどうかです。置くなら、そこは準委任契約になります。そして調べる手間を見積もりに入れます。

この整理は、条文には入っていません。委託先と話すときは、条文ではなく解説に書かれていることとして持ち出すほうが正確です。