はじめに

2022年3月に、ついに『紛争解決のためのシステム開発法務―AI、アジャイル、パッケージ等にも対応』（法律文化社）（以下、「本書」という）を出版することができる。新型コロナウイルス禍もあり、当初予定から大幅に遅れてしまったものの、ベンダ、ユーザ、そしてシステム開発プロジェクトに関わる法務担当者や法律家にとってお役に立つことができれば幸いである。
本書には、主に以下のような三つの特徴がある。

• 裁判例・実務運用およびその理論的背景を探求したこと：大量の（約400の）裁判例を引用しているところ、単にこれらの結論を羅列するのではなく、どのような理論的な枠組みのもとに位置づけられる判断なのかを明示し、かつ、重要性に応じてその事案の内容を踏まえた射程に関する分析等も行っている。
• 「“失敗プロジェクト”を回避するための実務指針を示す」こと：「契約」「プロジェクト遂行」「紛争」という3段階に即して、システム開発法の内容や、実務でよくあるトラブルやその原因を踏まえたそれぞれの段階における当事者の行うべき対応を示すようにしている。
• AI、アジャイル等の新しい議論を正面から扱ったこと：これまでは、例えばAIを利用したシステム開発につき、モデル契約がどうなっているか等の解説にとどまっていたり、伝統的な「ウォーターフォール」といわれる開発手法以外の開発（例：アジャイル開発など）について言及が少なかったりするものもよく見られるところであった。その点、筆者は、AIを利用したシステム開発プロジェクトや、アジャイル型等のウォーターフォール以外の開発形態の案件に多数関与し、また、いわゆる「モデル契約」のアジャイル版策定委員を務める等の機会をいただいた経験から、これらの実務対応を正面から扱っている。

本書籍の出版にあたって企画したのが、以下のセミナーと本連載である。

セミナーは、2022年3月24日に収録・配信する（当日ライブ配信および3月下旬より録画配信）予定である。恐縮ながら有料ではあるものの、「書籍付き」であることから、ぜひ奮ってご参加いただきたい。企業の法務担当者はもちろん、法律事務所所属の弁護士および修習生の参加も歓迎している（書籍については、申し込みが早い方には出版され次第送付を予定）。

本連載については、本書の内容を踏まえつつ、わかりやすく「失敗プロジェクト回避」のためのポイントを説明することで、本書の読者にも、そうではないシステム開発実務に携わる人や、法務・法律家としてシステム開発に携わる人の役に立てればと考えている（第1回は契約締結の側面、第2回はプロジェクト推進・紛争の側面、第3回はAIやアジャイルについての解説を予定）。もちろん、本書は約500頁であるのに対し、本連載の紙幅は限られている。その意味で、本連載は必ずしも本書の「代わり」にはならないことについてはご理解いただきたい。

では、早速、第1回として、契約締結の場面における失敗回避のポイントについて説明しよう。

契約締結時の「失敗回避」ポイント

「当たり前」のことこそ明確にする

筆者の経験では、「失敗プロジェクト」では、相手方当事者が「とんでもないこと」を言い出す傾向にある。たとえば、筆者がベンダ側で担当した複数の案件において、数年以上To-Be型（現行の業務を必ずしも前提とせず、業務改革を前提として「あるべき業務の姿」を定義し、それに合わせたシステム導入をするというシステム開発プロジェクト）を一緒にしていたはずなのに、突然ユーザからAs-Is型（現行業務を前提にシステムを業務に合わせるシステム開発）をしていたと主張されたことがあった。
これは、ベンダにとっては「驚愕」であるが、これは必ずしも、特定のユーザが不合理だという話ではない（本書で同様の事態が発生した複数の案件を紹介している）。むしろ、「よくある」事柄とさえ評することができる。

たとえば、ベンダとユーザの情報システム部門の間では「To-Be型で行く」、つまり「業務改革を実施し、今から業務を変える」としっかり合意していたのかもしれない。しかし、実際にシステムができあがる過程で、ユーザの現場から「これでは業務に支障がある」という声が次々と上がることがある。現場にとって業務改革に抵抗感があるのは当然であり、少なくとも積極的に協力したいものではない。そして、その声が一定以上大きくなる場合において、事前にユーザ情報システム部門がユーザのマネジメントレベルとの間で「To-Be型でいくための業務改革の“痛み”を甘受する」ことについてしっかりと認識の一致ができていないと、ユーザのマネジメントが「（情報システム部門の認識はともかく）少なくとも会社としては業務に支障をきたすようなシステムを導入するとまで認めた覚えはない」と「ちゃぶ台返し」をしてしまうのである。

なお、このような事態が発生しても、裁判所は「ちゃぶ台返し」を認めない傾向にある（詳細は本書をご参照いただきたい）ものの、「“裁判に行けば勝てるから大丈夫”という話でない」ということは、システム開発とその法務に携わる方の多くが同意してくださるのではないだろうか。このような事態の予防として、そして、万が一このような事態が発生した場合の対策として、まさに「当たり前」のことだからこそ、書面など明確な形で記録しておくことが大事なのである。「あまりにも当たり前なので、記録に残すほどのこととは思いませんでした」というのはよく聞く言葉であるが、筆者は声を大きくして、そのようなことは「厳禁である！」と申し上げたい。

もし、そのようなプロジェクトの前提が、特にユーザのマネジメントレベルでも明確になっていれば、そもそも現場から業務改革反対の声が上がっても、マネジメントレベルにおいて決然と業務改革完遂を指示してくれるかもしれない。
また、ユーザのマネジメントレベルが「ちゃぶ台返し」を試みたとしても、明確な書面があれば、ユーザの情報システム部門が「ここをご覧ください、社長にもご出席いただいたこの会議の議事録の合意事項に、“業務改革を前提としたシステムであるところ、業務改革はユーザの役割である”と記載されています」等と、マネジメントに翻意を促してくれることが期待される。
さらに、実際にベンダ側に対する「ちゃぶ台返し」が起こったとしても、ベンダがそのような書面を示してユーザに説明すれば、ユーザとしてもその段階で翻意し、トラブルに至らないこともありうる。

必ずしも「契約書」という書面において明確にする必要はないものの、重要なことは必ず証拠に残る形で明確化すべきである。

契約書に抽象的に「PM義務／協力義務がある」と書いても意味がない

ベンダは「プロジェクトマネジメント義務（PM義務）」を負い、ユーザは「協力義務」を負うことは、比較的有名である。この連載では第2回で取り上げるが、PM義務／協力義務にしても、それ以外の点も、契約書に抽象的に何かを書いていてはほとんど意味がない。

結局、トラブルになると、

ユーザ：「我々は素人なのだから、我々に手落ちがあっても、素人である以上むしろやむを得ない。ベンダがきちんとやるべきだ」
ベンダ：「ユーザの業務に使うシステムなのだから、ユーザこそが業務の専門家である。きちんとユーザがやっていなければ、ベンダとしてもやりようがない」

と考える傾向にある。それぞれの主張はそれぞれ一定の合理性があるものの、そもそも法廷で「PM義務違反だ！」「協力義務違反だ！」と、論戦を戦わせる事態そのものを可及的に回避するべきである。

そのためには、具体的な役割分担、たとえば「ある作業はどちらの責任で行うのか」「その責任を負うべき当事者が当該作業を行う上で他方当事者にやってもらわないといけないことは何か」等を明確にすることが有効だ。抽象的な記載だけで満足してはならない。

都度都度の合意と、その書面化・証拠化の重要性

システム開発においては、契約時にすべてのことは決まらない。むしろ、プロジェクト遂行過程で、その都度その都度合意をしているものである。

たとえば、4.で述べる一括契約形態で最後まで請負契約を締結するとしよう。要件定義は契約締結後に行われるが、そのようなプロセスを経て初めて構築すべき機能が決まる。これは一例であるが、システム開発では「“仕事”として何を完成すべきか」すら、契約締結時点で決まっていないことがある。
また、システム開発には流動性があり、当初は想定していなかった事情が発生して予定を変更しなければならないケースは十分にある。その場合に、「契約添付のスケジュールをこのように修正しましょう」等と合意することもよく見られる。
このように、システム開発においては、契約締結後に重要事項が決まる性質が存在することを、両当事者は十分に理解すべきである。

そうすると、契約書と同じくらい、場合によってはそれ以上に、「契約締結後」のその都度その都度の合意が重要となる。しかし、その合意が書面化・証拠化されていないと、そのような合意をベースにプロジェクトを進めてきたにもかかわらず、紛争になってから突然、相手方がその合意に反する主張をしてくることがある。
上記1.の「“当たり前”のことこそ明確にする」こととも関連するが、相手方がそのような不合理な主張をすることを避けるためにも、都度都度の合意を書面化・証拠化し、相手と明確に確認し、かつ、いざ不合理な主張がされてもそれを示して翻意させるべきである。

一括契約・多段階契約

実務上、多く聞かれる質問に「一括契約と多段階契約のどちらがよいですか？」というものがある。筆者はよほど小さいシステムでなければ、「多段階契約がよいのではないか」と回答している。

その一番の理由は、機能・仕様が決まらなければ、信頼できる見積りが困難だからである。もちろん、「現行システムと同じくらいの機能数にしましょう」といった形で一定の前提を置くことで概算見積りができないわけではないだろうが、要件定義過程において機能数が膨れ上がり、大幅な工数増加が生じる等のトラブルは頻繁に見られる。だからこそ、少なくとも「機能・仕様が決まるまでの段階」と「それ以降の段階」の多段階契約にしないと、お互いにリスクが大きくなってしまう。
ユーザの中には、「一括契約にしないと、後々の“追加・追加”で、結局のところ当初の想定より大きな支払いを強いられる」と懸念されている方もいらっしゃるようである。とはいえ、一括契約にしたところで、特定の想定（特定の機能数など）を前提に見積もるわけであるから、プロジェクトの途中でその前提が崩れれば（要件定義過程でユーザの要望を確認した結果、機能数が大幅に増えるなどが生じれば）、機能を絞る（スコープを限定する）か、または予算を増やすかのいずれかになる。むしろ、（そのような発想を持つユーザは少数と信じたいものの）「一括契約にしたのだから、ベンダの責任で、その予算内でユーザの作りたいシステムを作るべきだ」といった発想の方に傾き、それによってベンダとの信頼関係が失われるおそれの方が懸念される。

関連する論点をいくつか補足しよう。

1点目は、多段階だったら何でもよいのではなく、合理的な「切り方」があるということである。たとえば、「要件定義」「基本設計」「詳細設計」「プログラミング」「テスト」の各段階でそれぞれ一つ、計5本の契約を締結するというのは筆者としては合理的だと考える。しかし、特に理由もなく、一つの段階の契約を細かく分割するのは合理性に疑問がある。
ベンダ側としては、責任制限条項で「責任の上限が問題となる個別契約の契約額となる」とされていることを前提に、できるだけ細かく分割することで賠償すべき金額を極小化したいという趣旨なのかもしれないが、そのためだけに不合理に細かく分割するのは、少なくとも個人的にはポジティブに捉えることはできない。
2点目は、多段階であっても、基本合意書等で予算を「握る」ことは可能だということである。たとえば、そのベンダとの取引が、当該プロジェクトでもそれ以外でも特定の基本契約に基づくとすれば、特定のプロジェクトの予算を基本契約に書くことはあまり適当ではないかもしれない。そうであれば、基本契約の外の「基本合意書」を作成し、そこに「総予算●億円を念頭に進める」との合意をするのである。たしかに、システムそのものの完成を約する契約が締結されるずっと前の段階の合意である以上、これをもって「完成を義務づける」ことは難しい。しかし、それでも、特定の予算が合意されていれば、ベンダが合理的な理由もなく増額を言い出すことはしにくくなり、また、ユーザとしてもおおよその総コストを掴むことができるので、一括契約でなくとも確保すべき予算額の把握という目的は達成できるだろう。

3点目は、一括契約でも多段階契約でも、合理的な理由がある予算やスコープの見直しの要望に対しては、柔軟に応じるべきことである。上記のとおり、要件定義過程でユーザの要望を確認した結果、機能数が大幅に増えれば機能を絞る（スコープを限定する）か、または予算を増やすかのいずれかになる。また、ユーザの仕様変更の要望で費用が増えることもあるだろう。そのような「合理的な理由」があるベンダからの予算やスコープの見直しの要望については、ユーザは誠意をもって対応すべきである（反面、ベンダの能力不足や杜撰さ等が原因であれば、それは「合理的な要望」とはいえない）。

準委任・請負

最後に、契約の法的性質、つまり「準委任」と「請負」について簡単に述べたい。
民法648条の2に「委任事務の履行により得られる成果に対して報酬を支払うことを約した場合」（いわゆる「成果完成型の準委任」）が導入された。その結果、「準委任」と「請負」の境界は、いわばグラデーション的になっていることは事実である。
しかし、両者の決定的な相違は「成果完成が“債務の本旨”であるか」である。

成果完成型準委任であっても、準委任である以上、「債務の本旨」は事務の履行であり、あくまでも報酬のトリガーが成果の完成・引渡しであるに過ぎない。このため、ここでいう「完成すべき“成果”」は、必ずしも請負において「完成すべき“仕事”」ほどの粒度である必要はないだろう。
つまり、請負においては、「完成すべき“仕事”」とは、すなわち請負人（ベンダ）の債務の内容を示しているのであって、その内容は（契約時に不明確であっても、少なくともプロジェクトの遂行過程の「都度都度の合意」を通して最終的には）明確にならなければならない。これに対し、成果完成型準委任は、あくまでも、報酬のトリガーとしての「成果」の完成なのだから、ユーザが報酬を払うべきか否かを判断できる程度の粒度のものを「成果」として約することで足りる。

こうした観点を踏まえ、準委任と請負のいずれの法的性質の契約とするのが適切か、また、準委任の場合でも成果完成型準委任を用いるかどうかについて検討していくべきである。

＊　　　　＊

以上、契約締結段階における「失敗回避」のポイントを紹介した。次回、第2回は、プロジェクト推進・紛争の側面における「失敗回避」のポイントを紹介する。

→この連載を「まとめて読む」