はじめに

本連載は、『紛争解決のためのシステム開発法務―AI、アジャイル、パッケージ等にも対応』（法律文化社）の刊行と出版記念セミナーの開催を踏まえ、本書をもとに分かりやすく「失敗プロジェクト」回避のためのポイントを説明するものである。
第2回である今回は、プロジェクト遂行・紛争の過程での重要な問題を検討しよう。

プロジェクト遂行時・紛争発生時における「失敗回避」ポイント

「二重の専門性」とPM協力

「二重の専門性」という言葉をご存知だろうか。既に知っている方、あるいは見聞きしたことのある方もいるだろうが、その意味するところは、システム開発においては「ITの専門性」（ベンダが有する）も「業務の専門性」（ユーザが有する）も重要で、お互いの当事者がその専門性を持ち寄ることで、より良いシステムができる…ということである。

「PM義務」や「協力義務」は、このような二重の専門性を反映したものである。すなわち、ベンダがその「ITの専門性」を発揮して自社内を管理し、業務を遂行するとともに、ユーザにITの側面からの助力をするのがPM義務の主な内容であり、ユーザがその業務の専門性を活かして要件・仕様を提示し、社内意思を統一して適宜適切に意思決定し、さらに、少なくともプロジェクトに支障をきたすような大量の仕様変更をしないことが協力義務の主な内容である。

証拠化のための一工夫

このようなPM義務や協力義務の履行の有無を典型とするシステム開発に関する紛争の多くには、「水かけ論」が発生する。この点は第1回で紹介した「都度都度の合意」（Ⅱ3.）でも述べたが、重要な事項に関する証拠がないとすれば、最後はプロジェクトメンバーの陳述書や証人尋問に頼るしかなくなってしまう。やはり、そのような状況は可及的に回避すべきである。
もちろん、双方がサインした書面があれば1番明確ではあるものの、ここで言う「証拠化」はこのようものに限られない。たとえば、現場で会議を行うプロジェクトなら、会議室のホワイトボードの写真、オンライン会議なら確認した合意事項スクリーンショット等でよい。こうした少し証拠化の工夫が、後の紛争で大きな違いとなる。

なお、最近はチャットツールの利用が増えており、筆者も代理人としてその履歴（ログ）を読む機会が増えている。これらは、「“口頭で話していたら残らなかった”内容が記録として残っている」という点では、確かに「証拠」としての意味は大きい。ただし、分量が多い反面、文脈がわからない第三者にとっては「何が重要なのか」の判断がつきにくい。紛争時におけるスムーズな証拠の洗い出しのためにも、代理人弁護士の立場としては、依頼者において、各争点に関する基本的な依頼者の立場（たとえば、「A機能は途中で開発しないことに合意した」など）と、それを裏付けるチャットの該当部分を整理していただけると、大変ありがたい。

「合意できていない場合」の対応

繰り返し触れているように、「都度都度の合意」（第1回Ⅱ3.）は大事である。しかし、実際にはそのような合意に至らないこともある。
たとえば、ある「修正依頼」を、ユーザは「ベンダのミスの是正」と考え、ベンダは「仕様変更」と考えたとしよう。このような場合、時間的な余裕があれば、じっくり話し合い、それが仕様変更なのか、あるいは当初契約の範囲内の修正かを合意したい。しかし、その余裕がない場合もある。

その際に、この論点をひとまず「棚上げ」にして、とりあえず対応することがあるが、やはりその趣旨が不明確なままでは、後でごとになってしまう。
だからこそ、合意できない場合には、むやみに「見切り発射」をするのではなく、「その時点で何か前提となり、何に合意ができ、何には合意できていないのか」を明確にすべきである。

そのような場合、ベンダは、当該修正作業を開始する前に

といった連絡をユーザに行うとよい。ユーザからの異議がなければ、その作業が真の意味で仕様変更である限り、ベンダが作業後、●円を請求できる可能性は高まる。

早期の法務・弁護士の介入の重要性

弁護士として気になるのは、「“重要なこと”をしてしまった後」に初めて相談を受け、リカバリー対応を行うという案件が多いということである。

たとえば、「プロジェクトの延伸が必要となった。ベンダとしては、その延伸にはユーザ側にも相応の責任があると考えているものの、ユーザ社長がベンダに憤慨しており、謝罪を要求されている」という状況があったとする。ベンダがユーザへの謝罪文を出す前に弁護士に相談をいただければ、「“道義的責任”を認めたアポロジェティックなニュアンス（ユーザの信頼を得られるニュアンス）でありながらも、ベンダ側の“法的責任”は認めず、もしプロジェクトが中止等になった場合でも、“あの時、ベンダはその法的責任を認めた”と指摘されないような文言」を一緒に考えることができる。
これに対し、「既に事実と異なる謝罪文を出した後の相談」であった場合にどうなるか。ベンダの主張が事実であること（謝罪文が事実と異なること）を書証等の確固たる証拠で反論できるのであれば、「謝罪文はプロジェクト延伸のために事実と異なることが記載されており、実際の責任はユーザ側にある」と反駁することも可能であろう。とはいえ、ベンダの主張を裏付けるのがベンダの担当者の説明（証言）のみであれば、その謝罪文の内容や表現次第というところもあるが、ベンダのポジションが相対的に悪化することは間違いない。

上記はあくまでも1例であり、同様の「プロジェクト延伸」に関して、ユーザ側でも「ベンダからプロジェクト延伸を依頼されたものの、延伸の根拠や作業内容について特に明確に合意しないまま作業を黙認したところ、ベンダから追加費用の請求があった」といった事案がある。もちろん、そのプロジェクトが請負であった場合には、ユーザ側が「延伸期間の作業は、単なる当初契約に基づく業務だ」と反論する余地はあるものの、事後的な対応ではリカバリーが難しい場合もある。このような場合でも、ベンダからプロジェクト延伸を依頼された段階で弁護士に相談をいただければ、予定どおりの延伸で完了する場合とそうでない場合に応じて対応を明確化するといった適切な内容での延伸覚書等をベンダとの間で締結するなど、さまざまなやりようがあるのである。

要するに、トラブルの「芽」の段階で、早期に法務・弁護士が介入をすることが重要ということである。そうすることで、トラブルの「開花」を予防することができる。
最近では、契約締結～プロジェクト実施にかけて継続的なフォローの依頼をいただく機会も増えている。このように、「このプロジェクトについていつでも相談できる弁護士」が存在することは、ユーザ、ベンダどちらの立場であったとしても重要だと考える。

「損害」の考え方

プロジェクト遂行および紛争に関するトピックの最後に、「損害」について説明したい。

たとえば、プロジェクトが中止されて、ユーザが１億円の損害を被ったとしよう。このとき、ユーザが「裁判をすれば、最終的にはベンダから１億円を支払わせることはできる。ただ、裁判の労力を考えると、交渉でベンダに8,000万円の支払いを承諾させることができれば、そのほうが合理的だろう」といった目算を持つことは理解できる。
ところが、同じ事案でベンダも１億円の損害を被っているとしたらどうだろうか。ここで重要なのは、双方の損害が「なぜ発生したのか」ということである。

ユーザ・ベンダどちらの損害も、「100対0」でベンダのみに責任がある場合には、すべての責任をベンダが負うことから、ある意味では上記のユーザの目算は「正しい」ということになる。しかし、現実にはさまざまな事案が存在する。「5対5」の痛み分けであれば、互いに5,000万円ずつを請求できる（⇒相殺でゼロ）ことになるし、「7対3」でベンダが重い責任を負う場合であれば、ユーザは7,000万円をベンダに請求できるが、ベンダも3,000万円をユーザに請求できる（⇒相殺の結果、ユーザはベンダに4,000万円の請求しかできない）ことになる。また、後者の事案（「７対３」でベンダの責任が重い事案）での交渉で、ベンダが「5,000万円の支払いで同意いただけるなら和解しますが、それ以上の額を求めるなら裁判所の判断を仰ぎましょう」と言ってきた場合、この提案を拒絶して裁判に持ち込んだとしても、後になって「あの和解提案を受け入れていれば」と後悔する可能性もないわけではない。また、裁判で「ユーザが７割の責任を負う」と覆ってしまえば、逆にユーザは4,000万円をベンダに支払わなければならなくなる。
しかも、ユーザが1億円、ベンダが2億円の損害をそれぞれ被っている場合、仮に責任が「５対５」の痛み分けであっても、ベンダはユーザに１億円請求できるのに対し、ユーザは5,000万円しか請求できない（⇒相殺の結果、ユーザが5,000万円をベンダに支払わなければならない）ことになる。

これらはあくまでも模式的事例であるが、紛争となり、損害を計算して「着地点」を検討する際には、このような点も含めて検討をしなければならないのである。

＊　　　　＊

以上、今回はプロジェクト遂行時および紛争時における「失敗回避」のポイントを紹介した。連載を締めくくる次回・第3回は、AIを利用したシステム開発や、アジャイル開発などについて紹介する。

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