第1回 DX推進にむけたシステム開発の契約形態と責任分担

はじめに

　2018年9月に経済産業省が「DXレポート」¹ という報告書を発表するなど、ここ数年、デジタルトランスフォーメーション（DX）という言葉をよく見かけるようになりました。DXについて明確な定義があるわけではないようですが、「デジタル技術を活用して、新しい製品やサービス、ビジネスモデルを生み出し、新たな価値を創出すること」を意味する言葉です。

　従前より、各企業においてIT活用は進められていましたが、DXは、それがより一層進展・深化していくことを表すキーワードのようなものです。あらゆる業種において、ビジネスモデル自体がデジタル技術を前提としたものとなり、デジタル技術を使いこなせなければ競争力を失ってしまうのは不可避でしょう。DXを推進し、DXプロジェクトを成功させていくことが、企業の生き残りに不可欠となっていく、そんな時代が迫りつつあります。

DXとシステム開発契約

DXプロジェクトと従来のシステム開発プロジェクトの違い

　DXに取り組むDXプロジェクトと、いままでのシステム開発プロジェクトはどのように異なるのでしょうか。端的には、プロジェクトの開始時点で要件が決まっていないという点が大きな相違点であるといえます。

　もちろん、いままでのシステム開発も、プロジェクトの開始時点で何を作るかが明確ではなく、要件定義や基本設計といった工程を通じて、要件が明確化されました。しかし、いままでのシステム開発は、プロジェクトで実現すべき内容がある程度明らかとなっていることが多く、また、一度決まった仕様は原則として変更しないことが前提とされていました。これに対してDXプロジェクトは、新しい製品やサービスを作りだすことを目的とするものです。したがって、DXプロジェクトでは、プロジェクトで何を実現するかが決まっていないことが多く、試行錯誤を繰り返すことが当然であり、（もちろん程度にもよりますが）状況に応じて柔軟に方針転換をすることがよしとされます。

システム開発の契約論

　システム開発では、従来、請負契約と準委任契約の契約類型が用いられてきました。請負契約と準委任契約については、詳細な議論が積み重ねられていますが、ここでは受託者の責任という点に注目してみたいと思います。

　請負契約は「結果を実現すること（たとえば、成果物を作成して納品すること）」が債務であり、準委任契約は「一定の業務を行うこと」が債務となります。請負契約はこのような結果責任が求められることから、求められる結果（仕様）が明確になっていることが前提になります。

　システム開発契約では工程ごとに契約の性質を考えるという考え方が有力です。経済産業省のモデル契約では、各工程の契約類型を以下のように分類していますが、成果物の内容を具体的に特定できるか否かが分類の根拠とされています。

DXプロジェクトの契約形態

　それでは、DXプロジェクトの契約はどのように考えればよいのでしょうか。批判を恐れずに思い切って単純化をすると、「試行錯誤」、「柔軟性」といったDXの特徴から考えて、請負契約から準委任契約へのシフトが進んでいくのではないかと考えられます。

　もちろん、実際のプロジェクトは、プロジェクトごとにその中身が異なるはずです。DXプロジェクトの方法論を紹介する書籍などでは、反復的に開発を行い完成形に近づけていくアジャイル開発ありきではなく、アジャイルが難しければ、前工程の成果物に基づいて後工程を実施し、原則として前工程には戻らないウォーターフォール開発をベースとして部分的にアジャイルを取り入れる方法を考えるべきなどと論じているものもあります（下田幸祐、飯田哲也「企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書」日経BP、2020年・29〜34頁）。

　ただ、法律的な観点で見た場合、ウォーターフォールをベースにしてアジャイルを部分的に取り入れるという開発方式であったとしても、請負契約（＝結果債務）を前提としてきた、いままでの契約実務は大きく変わらざるを得ず、一見して請負契約のような形式ではあるが、準委任的な性格が入り込んだものとなるといった方向に変化していくのではないかと考えられます。

ベンダーとユーザーの責任分担

　上記のように、請負契約とは、仕事を完成させるという結果を約束するものです。準委任契約は、善管注意義務を尽くしたといえれば債務不履行責任を負わないのですから、一見すると、ベンダー（受託者）の責任が軽くなるように思えます。そして、ベンダーの責任が軽くなるのだとすると、ベンダーにモラルハザードの問題が生じてしまい、ユーザー（委託者、発注者）からすると問題であるようにも思えます。

　しかしながら、システム開発紛争に関する裁判例を見ると、いままでの請負契約を前提とした契約であっても、裁判所はベンダーに単純な結果責任を負わせていません。裁判所は、システム開発のプロセス（経緯）に注目し、プロジェクトの失敗がどちらの当事者によるものかを分析するという方法を採用しています ²。この分析のための道具としてプロジェクト・マネジメント義務と協力義務という概念が用いられ、一定の事例の蓄積も進んできました。

　DXプロジェクトについて考えるとき、このようなプロセスに着目する手法は、より一層有効であるように思われます。このように、DXという大きな変化に適切に対応するためには、プロジェクト・マネジメント義務に関する裁判例を分析して、ベンダーとユーザーのあるべき責任分担を考えていくことが重要であると考えられます。

プロジェクト・マネジメント義務と協力義務の分析方法

分析の難しさ

　先ほど、プロジェクト・マネジメント義務と協力義務を道具として用いると説明しましたが、システム開発プロジェクトというのは千差万別であり、プロジェクトの目的、期間・予算、採用された技術、ベンダーとユーザーの力量などはプロジェクトによって異なります。また、システム開発プロジェクトというのは、一般に非常に複雑なものであり、特に失敗したプロジェクトは、開発期間の延長などもあって数年程度の長さになることも珍しくありません。失敗したプロジェクトを分析して、その責任を明らかにせよといわれても、どこから手を付けたらよいのか困ってしまうのが正直なところでしょう。

システム開発のモデル

　そのような複雑な問題を考えなければならないときは、単純化をすることが有効です。
　具体的には、システム開発プロジェクトの場合、プロジェクトを「意思決定」と「意思決定に基づいた実行」という2つのレイヤー（層）にわけることがよいように思われます。モデルとして図式化すると以下のようになります。

責任分担の考え方

（1）意思決定はユーザーが分担

　システム開発プロジェクトというのは意思決定の連続です。予算や開発期間をどの程度にするかから始まって、どのようなシステム構成とするか、パッケージを使用するか、使用するとすればどのパッケージにするか、業務フローを現在のものから変えるか、変えるとすればどのように変えるか、現行システムにある機能を新システムでも採用するか、UI（ユーザーインターフェース）のデザインをどうするかなど、様々なレベルの意思決定をしなければいけません。これらの意思決定は、予算、開発リソースだけではなく保守性・拡張性などを考えて的確に行われなければなりませんし、意思決定が遅れることはプロジェクトの遅延の原因となるため、適時の判断が求められます。

　このような意思決定の多くはユーザーが分担すべきものとなります。システムというものは、社内の管理用であれ、顧客向けであれ、ユーザーの事業に利用されるものであり、ユーザーの事業自体を規定するものですから、外部の委託先であるベンダーにシステムのあり方を決定してもらうということは、自社の経営を外部の委託先に任せるのと同義だからです。このように、自己の事業のあり方を自ら描き出して、システムが自己の事業に適したものとなるように決定することはユーザーにしか行い得ない作業となります。

（2）実行と助言はベンダーが分担

　意思決定にしたがって実行することは、通常ベンダーの分担となります。ベンダーは、必要なスキルを持ったメンバーを集め、開発がスケジュールにしたがって行われるように進捗管理をすることなどが求められます。

　また、意思決定はユーザーが分担するとしても、システム開発というのは高度な知識や経験を有するものであり、ユーザーが適時・的確な判断をするのは、現実には難しいといえます。また、プロジェクトというのは流動的なものであり、開始時点で予想していなかった問題が発生するのはむしろ通常のことです。

　したがって、ベンダーは、システム開発の専門家として知識や経験に基づいた助言をすることが求められますし、プロジェクトの状況を常にモニタリングして、問題が発生したらユーザーに報告をして判断を求めることが必要になります。

（3）責任分担の考え方

　以上をまとめると、ベンダーとユーザーの責任範囲というものは以下のようになると考えられます。

　この分担は単純化したものであり、契約によってユーザーが実行の一部を分担することも可能です。また、プログラムの実装方法などは、ユーザーが関与せずにベンダー限りで判断するのが通常でしょう。
　それでもこのような枠組みを用いることで、当事者間の責任分担について一定の基準線を引くことができると考えられます。

小括

　今回はDXと契約の考え方について説明し、プロジェクトの責任分担のモデルについて解説しました。次回からは、実際にプロジェクト・マネジメント義務と協力義務の違反が争点となった裁判例を紹介して、当事者の責任分担の考え方についてさらに検討していきたいと思います。