法律を知らないとシステム開発で損害賠償を請求されることも

不利な条件での契約書にサインしてしまったために、システム開発の受託で貰えるはずだった数百万円の報酬の支払を受けられず、かえって数千万円の損害賠償請求を受けてしまった、という個人エンジニアからの相談を受けたことがあります。

エンジニアにとって法律は、なかなか「身近」に感じられるものではないかもしれません。

しかし、会社に所属している場合でも、自分が関わるシステム開発は、契約や要件定義の段階から開発途中、納品や検収といったプロセスまでが「請負」「⁠準委任」といった法律によって規律されているものです。そして、「⁠副業」といった形で個人として案件を受託する場合、会社から独立してフリーランスのエンジニアとして活動する場合は、全ての責任を自分が負う状態で、上述のように「法律」によって規律されたシステム開発と向き合わなければなりません。

そこで以下では、エンジニアが最低限抑えておくべき法的知識をいくつかピックアップして簡単にご紹介します。

システム開発では多段階契約を結ぶことが多い

システム開発というのは、いくつもの工程を経て進んでいくものであり、複雑な内容のプロジェクトになりがちです。そのため、特に大規模なシステム開発においては、工程ごとに逐一契約を締結し直すという多段階契約が好まれます。

各工程を一つの契約で規律する一括請負契約との大きな違いは、一括請負契約が「請負契約」のみであるのに対し、多段階契約では「請負契約」と「準委任契約」を工程ごとに使い分けできるという点にあります。具体的には、発注者が主体となる要件定義においては準委任契約を結び、受注者が主体となる外部設計やプログラミングにおいては請負契約を結ぶ、というような形です。請負契約の場合、受注者は仕事の完成義務を負うことになりますが、発注者が主体となって行う工程についてまで完成義務を負うのでは、受注者にとって酷です。そういった事情もあり、大規模なシステム開発においては、工程ごとに請負契約と準委任契約を使い分ける多段階契約が採用されているのです。

それ以外の点でも、多段階契約というのは、開発プロジェクトの流動性への対処が比較的容易であるなど、発注者と受注者の双方にメリットがあります。まず、発注者にとっては、見積もりが容易かつ正確であり、費用が想定していない高額なものとなることを防ぐことができるだけでなく、各工程が終了するごとに納入品を検査することになるため、システム開発プロジェクトの進捗状況を確認できるという利点があります。また、受注者にとっては、工程ごとに委任料を請求し資金を早期に回収することができるという点がメリットとなります。

契約締結の回数が多く、煩わしく感じるかもしれませんが、正確かつ変更に強い多段階契約という手法を取り、発注者と受注者で役割や責任を分担することは、後々のトラブルの防止にも繋がります。

発注者と受注者、それぞれが負う義務

勿論、トラブルを避けられればそれがベストですが、工程の多い複雑なシステム開発プロジェクトほどトラブルは発生しやすく、実際にトラブルになってしまった際に、誰が責任を取ることになるのかというのは発注者にとっても受注者にとっても非常に重要な問題です。こういった責任の所在については、それぞれが追う義務をどこまで果たしているのかという点が判断の際のポイントとなります。

プロジェクトマネジメント義務

まず、受注者は「プロジェクトマネジメント義務」を負っていると考えられています。プロジェクトマネジメント義務とは、プロジェクトを円滑的に進めるために受注者が果たすべき義務であり、具体的に過去の裁判例が挙げているのは次のようなものです。

受注者がこのプロジェクトマネジメント義務を果たさなかった場合には、債務不履行責任が問われ、損害賠償を求められたり、契約を解除されたりする可能性があります。そういった事態を避けるためには、受注者がプロジェクトの進捗を常に把握し、管理するということが大切です。

協力義務

これに対し、発注者は、「⁠協力義務」を負います。システム開発は発注者と受注者の共同作業であり、発注側にも積極的に協力する義務があるのです。具体的には、以下のような点において発注者の協力義務が課されていると裁判例で挙げられています。

• どのような機能を備えたシステムを作りたいかの明確化
• 画面や帳票など、システム操作者の観点からみたシステムの外観の設計
• 仕様通りのものが仕上がっているかを検証し、DBダンプなどのエビデンス資料とともに確認し、納品を受け付ける

これらはいずれも、発注者の協力なしに受注者が単独でなしうるものではありません。

たとえば、システム開発において仕様の変更や追加はつきものですが、仕様確定後に合理的な理由もなく度重なる仕様変更を要求することは、納期を遅らせることに繋がります。確かに、仕様変更があったとしても、発注者に対し納期の延期を求める、納期を動かせない場合には追加の要求そのものを取り下げるよう提案する、といった形で、納期に間に合うようにプロジェクトの進捗を管理する義務が受注者にはあります。

しかし、仕様が一度確定した後に行った仕様変更についてまで、納期に遅れた責任を全て受注者側に負わせるのは現実的ではなく、協力義務を果たさなかったとして発注者の側にも責任があると考えるべきです。そして、発注者が協力義務を果たさず、プロジェクトが頓挫したような場合には、プロジェクトマネジメント義務違反の場合とは逆に、発注者側が被害賠償請求をされる可能性があります。

つまり、受注者はプロジェクトの進行を管理し、発注者はその管理がしやすいよう協力する、といった形で、システム開発においては、発注者と受注者の両者が義務を果たし、協力してプロジェクトを進めていくことが大切なのです。法律的な観点からは、発注者と受注者の双方がどのような義務を負い、相手に何を権利として主張できるのかを明確にしておくことが、危機管理の第一歩と言えるでしょう。

エンジニアが知っておくべき法律知識

『ITエンジニアのやさしい法律Q&A』では、こういったエンジニアにかかわる法律問題について、わかりやすく解説しています。法律に関する知識がないないまま仕事を進めていると、そうとは知らず法律違反をしていたり、冒頭で述べたような不利な契約を結んでしまったりと、思わぬトラブルに見舞われる可能性があります。そうしたトラブルを避けるには、何よりもまず、ITエンジニアにとって身近なトラブルや起こり得る法律問題について知るということが必要です。

もう一点、ここで付け加えておきたいことがあります。私は、「⁠エンジニアには法律を理解するための素養を持っている方が多い」と考えている、ということです。

なぜかというと、法律は現実世界で発生する様々な事象について、「⁠こうした場合はこのような効果が発生する」というようなアルゴリズムを規律するものであり、例えば契約書とは自然言語で記載されたプログラムに他ならないからです。アルゴリズムを理解し、ソースコードを読み解き、想定外動作の発生し得る行を書き換える、という作業は、正にエンジニアが日々行っている業務でしょう。法律も、一度基本的な考え方や言語仕様を理解すれば、例えば「この契約書のこの条項は非常に危ないかもしれない」といった勘所が分かるようになってくるはずです。

その第一歩となるよう、法律トラブルを回避するためにエンジニアが最低限知っておくべき法律知識について、まとめた本となっています。法律についてよく知らないというエンジニアの方にこそ、お手に取っていただきたい一冊です。