AI契約書レビューツールを導入しました
AIを用いた契約書レビューツール「LegalForce」を導入しました。
ありがたいことに、今年に入ってからも、システム開発を手がけているITベンダー企業様との顧問契約が増えています。
また、出社をして法務部員、企業内弁護士(インハウスロイヤー、インハウスローヤー)のように稼働する外注法務部サービスについても、ご利用いただいている企業様が増えています。
顧問契約においても、外注法務部サービスにおいても、契約書等のドキュメントレビューの業務が多く、法律相談と並ぶメイン業務となっています。
なるべく速くレビューの結果をお返しすることは当然のことだと考えていますが、他方、速度が上がったことによって品質が下がってしまっては元も子もありません。
そこで、今回LegalForceを導入することにより、各ドキュメントのレビューの品質を保ちつつ(あるいは今まで以上に品質を高めつつ)、素早くレビュー結果をお返しすることを実現させています。
起業予定の企業様、起業したばかりの企業様、システム開発訴訟のセカンドオピニオンを検討している企業様をはじめとして、特にITに詳しい顧問弁護士をお探しの企業様は、顧問契約締結後、AIを用いた契約書レビューをご体験いただけます。
ご興味のある方は、お問い合わせください。
NTTデータ編『システム開発を成功させるIT契約の実務』
発行日からしばらく経って発行されていることに気づき、急いで注文して読みました。
読んだ感想としては「法務としてはこれだけでは足りないものの、大いに参考になる非常によい本」というところでしょうか。
そもそもシステム開発契約に関する書籍があまり多くない中、弁護士が著者ではない書籍となります。
少なくとも私が購入した書籍で言えば、日本のシステム開発契約実務に関する書籍で、かつ、弁護士が執筆していない初の書籍です。
「わかりやすさを最優先して極力かみ砕いた表現で契約書雛形も用いながらシステム開発について解説しています。」との説明もなされているとおり、とにかくわかりやすいです。
NTTデータなりのポジショントークも相当に見受けられます。こちらは読んでいておもしろい部分だと思います。
他方、わかりやすさのためか、裁判例やシステム開発紛争に関する事項の説明に物足りなさを感じることも否めません。
こちらは、そもそもすべてを正確に説明するというコンセプトの書籍ではないとのことですから、やむを得ない点でしょう。
システム開発契約の実務に関する書籍としても、NTTデータがどのようにシステム開発契約について考えているかがわかる書籍としても、非常に読みやすい本ですので、おすすめする次第です。
個人情報保護委員会の新着情報もSlackに投げる
経産省ニュースリリースと同じように、個人情報保護委員会の新着情報も、個人情報保護法に関する業務を扱っている私にとっては常に追っていなければならないものです。
robots.txtは次のとおり。新着情報をアップしているURLは"https://www.ppc.go.jp/information/"なので、今回の目的を達成しようとするにあたり、robots.txtの記載は障害とはなりません。
また、利用規約においても特にスクレイピングが禁止されているということはありません。
User-agent: * Disallow: /common/* Disallow: /hardcore/* Disallow: /hc_config/ Disallow: /image/ Disallow: /webadmin/* User-agent: ndl-japan Disallow: /hardcore/ Disallow: /hc_config/ Disallow: /webadmin/
ところで、PPCのサイトをスクレイピングしようとすると、次のようにDH鍵が短いと怒られてしまいます。
dh key too small
そのため、Net::HTTPのciphers設定でDHを除外する必要があります。
require 'faraday' require 'faraday_middleware' require 'nokogiri' require './lib/hoge' uri = %(https://www.ppc.go.jp/information/) connect = Faraday.new(uri) do |builder| builder.adapter :net_http do |http| http.ciphers = %(DEFAULT:!DH) end end Nokogiri::HTML(connect.get.body).xpath('//ul[@class="news-list"]//a').each_with_index do |node, i| post_feed_to_slack( PPC, %(https://www.ppc.go.jp#{node[:href]}), node.text, %(個人情報保護委員会新着情報) ) break if i == 19 end delete_unnecessary_data(PPC, 40)
続･経産省ニュースリリースをSlackに投げる
昨日の続き。
他にも使い回せるようにするとこんな感じですかね。
./lib/hoge.rb
require './config/active_record' require './config/slack' def post_feed_to_slack(table, title_link, title, slack_username) hash = { uri: title_link, title: title } unless table.where(uri: hash[:uri]).reload.exists? Slack.chat_postMessage( channel: %(rss), username: slack_username, text: %(<#{hash[:uri]}|#{hash[:title]}>), unfurl_links: 'true' ) table.create( uri: %(#{hash[:uri]}) ) end end def delete_unnecessary_data(table, count) if table.all.reload.size > count min_id = table.where(id: table.minimum(:id)).map(&:id)[0] max_id = table.where(id: table.maximum(:id)).map(&:id)[0] table.where(id: min_id..max_id-count).delete_all end end
./meti.rb
require 'faraday' require 'nokogiri' require './lib/hoge' uri = %(https://www.meti.go.jp/press/index.html) Nokogiri::HTML(Faraday.get(uri).body).xpath('//a[@class="cut_txt"]').reverse_each do |node| post_feed_to_slack( Meti, %(https://www.meti.go.jp#{node[:href]}), node.text, %(経済産業省ニュースリリース) ) end delete_unnecessary_data(Meti, 20)
経産省ニュースリリースをSlackに投げる
グレーゾーン解消制度における照会への回答を閲覧するため等、経済産業省のニュースリリースは重宝しているのですが、RSSフィードが用意されておらず、いちいち見に行かないといけないというのは結構面倒です。
というわけで、スクレイピングしてSlackのRSSチャンネルにニュースリリースを流すことにしました。なお、利用規約にもスクレイピングに関しては記載がなく、robots.txtも設置されていないので、(節度ある)スクレイピングは禁止されていません。
Gemfile
source "https://rubygems.org" git_source(:github) {|repo_name| "https://github.com/#{repo_name}" } gem "slack-api" gem "dotenv" gem 'activerecord' gem 'pg' gem 'faraday' gem "nokogiri"
config/env.rb
require 'dotenv' Dotenv.load
config/active_record.rb
require 'active_record' require_relative './env' ActiveRecord::Base.establish_connection( adapter: 'postgresql', host: '', username: ENV['DB_USERNAME'], password: ENV['DB_PASSWORD'], database: ENV['DB_NAME'] ) class Meti < ActiveRecord::Base end
config/slack.rb
require 'slack' require_relative './env' TOKEN = ENV['SLACK_RSS_TOKEN'] Slack.configure {|config| config.token = TOKEN}
./meti.rb
require 'faraday' require 'nokogiri' require './config/active_record' require './config/slack' uri = %(https://www.meti.go.jp/press/index.html) Nokogiri::HTML(Faraday.get(uri).body).xpath('//a[@class="cut_txt"]').reverse_each do |node| hash = { uri: %(https://www.meti.go.jp#{node[:href]}), title: node.text } unless Meti.where(uri: hash[:uri]).reload.exists? Slack.chat_postMessage( channel: "rss", username: "経済産業省ニュースリリース", text: "<#{hash[:uri]}|#{hash[:title]}>", unfurl_links: 'true' ) Meti.create( uri: %(#{hash[:uri]}) ) end end if Meti.all.reload.size > 20 min_id = Meti.where(id: Meti.minimum(:id)).map(&:id)[0] max_id = Meti.where(id: Meti.maximum(:id)).map(&:id)[0] Meti.where(id: min_id..max_id-20).delete_all end
システム開発における「完成」
仕事の「完成」による効果
請負類型におけるシステム開発契約では、仕事の目的物たるシステムが完成することによって初めて、ベンダーがユーザーに対して報酬を請求できる権利(報酬請求権)を行使できます。
報酬は前払いとする旨が当事者間の契約の内容となっていた場合であっても、システムが完成しなかったのであれば、既払金を返還しなければなりません。
ただし、その場合であっても、ベンダーの仕事の提供によってユーザーが利益を受ける場合、提供された仕事の限度で当該仕事は完成したとみなされるのが原則です(民法634条各号)。その場合、ベンダーは、ユーザーが受ける利益の割合を差し引いてユーザーに既払金を返還することとなります。ベンダーは、既払金のみでは当該仕事の割合に応じた報酬として不足する場合、ユーザーに対し、追加で不足分を請求することも可能です。
なお、ベンダーは、システム未完成の原因がユーザーにある場合、ユーザーに対し、報酬の全額を請求できます(民法536条2項)。
(請負)
民法632条 請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
(報酬の支払時期)
同法633条 報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。ただし、物の引渡しを要しないときは、第624条第1項の規定を準用する。(報酬の支払時期)
同法624条 労働者は、その約した労働を終わった後でなければ、報酬を請求することができない。
2 (略)
(注文者が受ける利益の割合に応じた報酬)
同法634条 次に掲げる場合において、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。
一 注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。
二 請負が仕事の完成前に解除されたとき。
(債務者の危険負担等)
同法536条 当事者双方の責めに帰することができない事由によって債務を履行することができなくなったときは、債権者は、反対給付の履行を拒むことができる。
2 債権者の責めに帰すべき事由によって債務を履行することができなくなったときは、債権者は、反対給付の履行を拒むことができない。この場合において、債務者は、自己の債務を免れたことによって利益を得たときは、これを債権者に償還しなければならない。
また、旧法が適用される場合、すなわち、瑕疵担保責任に関する規定が依然適用される場合、システムが完成したことをもって、ユーザーはベンダーに対して(仕事の完成に関する)債務不履行責任を追及できず、瑕疵担保責任を追及できるにとどまります。
瑕疵担保責任しか追及できないとなると、契約を解除できる場合は、契約目的を達成できない程度の重大な瑕疵があった場合に限られます。
以上のとおり、システムの完成の有無は、新民法適用下においても報酬請求権の行使との関係で重要ですし、旧民法適用下においては瑕疵担保責任の適用場面か否かという問題との関係でも重要です。
システム開発における仕事の「完成」
ところで、システム開発契約は建築請負契約と類似していると考えられています。
もちろん、主たる成果物が有形物か無形物か、完成後の成果物のイメージが事前につきやすいかつきにくいかなど、システム開発契約と建築請負契約とでは大きく違う点が多数あることは事実です。しかし、抽象的に完成までの流れを見れば、やはりシステム開発契約は建築請負契約と類似していると言い得るでしょう。
なぜシステム開発契約は建築請負契約と類似しているという話を持ち出したかと言うと、システム開発契約におけるシステムの完成の有無は、裁判例上、建築請負契約における建築物の完成の有無と同様の判断基準が採用されていることによります。
具体的には、システムの完成の有無は、ベンダーの仕事が当初のシステム開発契約で予定された最終工程までを終えたか否かを基準に判断すべき、と考えられており、多くの裁判例がこの判断基準を採用しています。
「検収」と「完成」の関係
多くのシステム開発契約では、ベンダーがシステムを引渡した後、ユーザーが検収をすることが契約内容になっているかと思います。
検収は、一般的には当初のシステム開発契約で予定された最終工程でしょう。ですから、検収が完了したのであれば、原則として、システムの完成が認められると考えられます。
また、ユーザーがシステムを稼働させている場合も、稼働段階まで至ったわけですから、同様にして、システムの完成が認められると考えられます。裁判例も、稼働したシステムにつき、当該システム稼働時には遅くとも当該システムは完成していた旨を認めています。
個々の事案によるところではありますが、検収や稼働の事実は、「ユーザーがシステムの完成を確認した」という意味を含んでいると通常は考えられています。
他方、検収や稼働の事実がなかった場合はどうでしょうか。
システムの完成の判断基準を振り返ってみると、それは「ベンダーの仕事が当初のシステム開発契約で予定された最終工程までを一応終えたか否か」です。
もちろん、検収や稼働の事実は、積極的に完成を肯定する要素と言い得ます。しかし、検収や稼働の事実がないからといって「最終工程まで終えていない」ことにはならないはずです。
システム開発は、ユーザーとベンダーがシステムの完成に向けて協同して行うものです。検収や稼働も、ベンダー単体でできるものではなく、ユーザーの協力が必要です。
ベンダーが単独で実施できる作業を終えず、またユーザーの作業へ協力する態度を示していないのであれば話は別です。
しかし、そうでないにもかかわらず、ユーザーが検収を行わなかったり、稼働に必要な作業を行わなかったりした場合にも完成を認めず、ベンダーがユーザーに対して報酬を請求できないのでは酷です。
このような価値判断に立つと、ベンダーが単独で実施できる作業を終え、ユーザーの作業に協力する態度を示したにもかかわらず、ユーザーが検収等ユーザー作業を完了させなかったような場合には、システムの完成を認めてもよいと考えられます。裁判例にも、そのような判断を行ったものが見受けられます。
ところで、以上を踏まえ、システムの完成に関し、システム開発契約でどのようなことを合意しておけばよいでしょうか？
契約書チェックや契約内容の検討では、すべての条項の検討にあてはまるわけではありませんが、紛争で問題となる点から逆算して考えるという方法が有用です。
この点についてはまた別途触れることとしますが、本エントリを読まれた方は、是非一度考えてみていただきたいと思います。
「バグ」と「完成」の関係
システム開発において、バグが生じることは不可避です。そこで、バグが生じた場合の法律関係は常に問題となります。
前述のとおり、「完成」は、旧民法適用下において瑕疵担保責任の適否を決する基準として機能していました。ですから、旧民法適用下では特に大きな問題となります。
さて、繰り返しになりますが、システムの完成の判断基準は「ベンダーの仕事が当初のシステム開発契約で予定された最終工程までを終えたか否か」にあります。
また、ユーザーは債務不履行責任による保護を受けることができ、バグがあった場合にシステムの完成を認めても、ユーザーに一方的に不利益が生じるわけではありません。例えば、システムの稼働に支障をきたす重大なバグがあった場合には、債務の不履行が軽微とは言いがたく(新民法)、又は契約目的が達成できないと言いやすい(旧民法)でしょうから、完成が認められたとしても、契約解除が認められる可能性は高いでしょう。
とすれば、バグが生じていた場合であっても、システムは完成したものと扱うべきと考えられます。
(催告による解除)
民法541条 当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。ただし、その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。
(催告によらない解除)
同法542条 次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の解除をすることができる。
一 債務の全部の履行が不能であるとき。
二 債務者がその債務の全部の履行を拒絶する意思を明確に表示したとき。
三 債務の一部の履行が不能である場合又は債務者がその債務の一部の履行を拒絶する意思を明確に表示した場合において、残存する部分のみでは契約をした目的を達することができないとき。
四 契約の性質又は当事者の意思表示により、特定の日時又は一定の期間内に履行をしなければ契約をした目的を達することができない場合において、債務者が履行をしないでその時期を経過したとき。
五 前各号に掲げる場合のほか、債務者がその債務の履行をせず、債権者が前条の催告をしても契約をした目的を達するのに足りる履行がされる見込みがないことが明らかであるとき。
2 次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の一部の解除をすることができる。
一 債務の一部の履行が不能であるとき。
二 債務者がその債務の一部の履行を拒絶する意思を明確に表示したとき。
バグが生じていた場合であってもシステムは完成するとなると、報酬請求権との関係が問題となりそうですが、それはまた次の機会(「バグ」と「契約不適合(瑕疵)」に関するエントリ)で触れようと思います。
