「情報システム・モデル取引・契約書」第二版雑感

IPAから「情報システム・モデル取引・契約書」第二版が2020年12月22日に公開されましたので、一通り読んだ雑感を残しておこうと思います。

ますます重要度の増すセキュリティ

セキュリティに関する事項はIPAが実施する情報処理技術者試験などではどの試験にもウェイトがおかれている重要項目です。見直し論点においても、セキュリティに関するウェイトが非常に大きかったように思います。個別の条項への盛り込みとしては、これまで80文字しかなかった条項が1023文字（オプションを含めると1309文字）まで増強されています。

「乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、ソフトウェア開発業務を開始する前までにセキュリティ仕様を確定させ、書面により定めるものとする。（1項）
確定したセキュリティ仕様は、システム仕様書の一部を構成するものとし（3項）」
というのが契約締結後にコミュニケーションによって確定するプロセスを重視している表れに感じます。

またセキュリティ仕様作成のためのガイドラインも策定されています。
題材がActiveDirectoryを例に、重要インフラ・大企業基幹系システム開発を想定しているというものですが、後半の怒涛のポリシー（ADの設定項目）列記はシステム管理者時代にADの複雑多様なグループポリシーと格闘して結局数十個の設定が現実的と採用したことを思い出しました（読んで理解できるものじゃない）。

セキュリティ仕様は技術的な範囲ですが、そもそもどこに、どんなリスクがあり、どのような手当てを行うことが最も経済的かの判断をユーザー企業は行わなければなりません。身の丈に合わないセキュリティはユーザービリティを落としますし、ベンダーの言い値で多額のお金を使うことになります。

セキュリティリスクを選定し、（多くの場合ユーザービリティと引き換えに）技術で手当てするのか、運用（ユーザーの良心、教育）で手当てするのか、ベンダーは素人であるユーザーを導き、ユーザーは決定する、セキュリティ仕様策定プロセスが「セキュリティ仕様策定プロセス」には記載されています。

個人的に以下の記載が心に引っ掛かりました。

2020年4月から施行された改正民法では、請負契約における契約不適合に関する担保責任の規律が一新された。これに伴い、ベンダーは、開発当時のセキュリティ水準に沿ったセキュリティ対策を納入物に施していなければ、長期にわたる担保責任を負う場合も考えられる。改正民法のもとでは、ソフトウェアに存在する脆弱性が契約不適合に該当するような場合や、ベンダーの重大な過失により脆弱性があることを知らずにユーザーに引き渡した場合には、担保責任の期間制限が適用されないことなどにも留意が必要である。一方でユーザーはセキュリティ要件に必要な情報の提供とセキュリティ対策の実装ポリシーの判断において一定の責任を負うことが求められる状況となった。

社内で契約書レビュー時に仕様書のチェックも行うのですが、多くの場合「機能要件」まで書いてあっても「非機能要件、特にセキュリティ要件」は記載されません。書き始めるときりがないからではありますが、「書かないならばPMは現場で注意してプロジェクトを進めてくださいね。」と東京地判平成14年4月22 日（処理速度が遅いことからシステムは完成していないと主張したユーザーの事例。提案書に「迅速化」を目的として提示しているなど重大な不具合と認定し、瑕疵担保責任解除を認めた。）や、東京地判平成26年1月23日（開発当時のセキュリティレベルからベンダーが当然手当てべきセキュリティレベルを認定した事例。）を引き合いに出して警告しているのですが、PMに投げてしまっているので「未決定事項などで後々合意することを明確にするようにしてください。」と指導するようにしようと思います。

くしくも公表と同じ週25日に楽天がセールスフォースの設定ミスにより顧客情報流出を起こしていたことが報道されたのは何かのめぐりあわせか。

システム開発紛争は判例の蓄積頼み

近時の裁判例で多く登場し、なかば定着しているプロジェクトマネジメント義務や協力義務が盛り込まれないか検討はされましたが、判例の紹介にとどまっています。

ソフトウェアは民法のような一般法には特に考慮されないものの典型例です。そのため、各法令の当てはめや解釈は裁判での判断にゆだねられがちです。

請負契約における「完成」の意義1つとってもいくつもの裁判例があるほか、プロジェクトマネジメント義務やユーザーの協力義務という独特の判例上の義務が存在しています。

しかし裁判というのは「持ち込まれた問題を解決する場」であり、極論、汎用的、一般的な規範、ルールを示す場ではありません。またこれまでのソフトウェア開発は一品物の受託開発が多かったこともあり、その個別性の高さもあって汎用的なモデル契約への規定は見送られたようです。

クラウド全盛期の現在、果たしてこのようなウォーターフォールによる受託開発モデルを前提にした裁判例がどこまで通用するのかと思いましたが、セキュリティ仕様の策定、プロジェクトマネジメント義務や協力義務を通してすべてに共通しているのは「争いになる前に話し合い、理解を確認して進めるべし」ということです。
「請負型をとると、ユーザ側の心理として『丸投げ』『ベンダにすべてお任せ』という意識が強くなる点が議論となった」という記述からも、ベンダーの働きかけに加えユーザーへの意識変革を求めているメッセージを感じます。
この点は果たしてアジャイルソフトウェア宣言の「プロセスやツールよりも個人と対話を、…契約交渉よりも顧客との協調を、…価値とする。」に親和的なのでしょうか。

なお現状このモデルやガイドラインなどはユーザー企業でしっかり参照されることは少ないので、その辺は「お上はこう言っています」と積極的に使っていくことが果たして吉と出るか凶と出るか、といったところでしょうか。

「重過失」とは客観的注意（回避）義務違反とすべき

実務上あまり問題にならないけど契約上よくやりとりの対象になる「重過失」について、モデルは条項には盛り込みませんでしたが以下のように解説が追加され、客観的過失論を採用しています。

ここでいう重大な過失については、主観的な心理状態としての「ほとんど故意に近い注意欠如」というより、著しい客観的な注意義務違反を意味すると解すべきである。
（中略）
重過失については、必ずしもその意義について統一的な理解がされているわけではないものの、理解の分かれ方については一定のコンセンサスがあるところである 。
一つは重過失とは「ほとんど故意に等しい注意欠如の状態」であるという考え方である。最高裁の判例においても失火責任法における重大な過失について、「通常人に要求される程度の相当な注意をしないでも、わずかの注意さえすれば、たやすく違法有害な結果を予見することができた場合であるのに、漫然これを見過ごしたような、ほとんど故意に近い著しい注意欠如の状態を指す」としたものがある（最判昭和32年7月9日民集11巻7号1203頁）。これは重過失は故意と同様に心理状態として捉えられる。
もう一つは、重過失は「注意義務違反の程度が著しい場合」と捉える考え方である。ただ、こう考える場合であっても、そこには義務違反の結果が重大である（義務からの乖離が著しい）という類型と違反した義務自体が重大である（当該義務が基本的なものであり、それすら怠っていた）という類型の2つが含まれている。
裁判例においては、後者の考え方に準じて重過失について結果の予見が容易に可能でありかつ結果の回避も容易に可能であることを要件とした著しい注意義務違反であるとするものがあり（東京高判平成25年7月24日判例時報2198号27頁）、またシステム開発により即して「通常のベンダとしての裁量を逸脱して社会通念上明らかに講じてはならない不合理な対応策を取った」か、あるいは「ベンダとして社会通念上明らかに講じなければならない対応策を怠った」かを判断するものもある（東京地判平成31年3月20日公刊物未掲載（平成25年（ワ）第31378号・平成26年（ワ）第9591号））。また、システム開発に関連して実際に重過失が認定された例はまだ多くはないが、ベンダがSQLインジェクション対策を講じなかったことで個人情報が流出したという事案について、経済産業省及びIPAがウェブアプリケーションに対する代表的な攻撃手法としてSQLインジェクション攻撃を挙げ、対策するよう注意喚起していたことから結果の予見が容易であり、かつ、具体的な対策に多大な労力や費用はかからず、結果回避も容易であったとして、重過失を認定した例がある（東京地判平成26年1月23日判例時報2221号71頁）。

※文中引用される「みずほ証券誤発注事件（H17発生）高裁判決」（H25.7.24）では次の３つに該当する場合重過失が認められると判示
ア　結果の予見が可能かつ容易である
イ　結果の回避が可能かつ容易である
ウ　回避を怠った＝著しい注意義務違反である
この基準に基づいて事実認定した結果、イが容易ではないとして重過失を否定した事例

※文中引用される東京地判平26.1.23 は「重過失の意義」について「その結果についての予見が可能かつ容易であり，その結果の回避も可能かつ容易であるといった故意に準ずる場合」と示したうえで、 
・被告は専門的知見を持っており、原告もそれを信頼して発注したことから注意義務の程度は比較的高度
・被告は対策を行わなかった場合の本件サイバー攻撃の発生可能性は予見可能
・対策に多大な労力や費用が掛かるという証拠もなく、回避容易であった
を理由に重過失があったと認定した事例

ちなみに潮見佳男「民法 （全）」では、以下のように過失とは客観的過失（結果回避義務違反）であり、主観的過失 （意思の緊張を欠いた不注意）ではないと述べています。

過失とは,結果発生の予見可能性がありながら,結果の発生を回避するために必要とされる措置(行為)を講じなかったこと,つまり,結果回避義務に対する違反をいう。
かつては,過失とは意思の緊張を欠いた不注意な心理状態であるとされていたこともあったが,現在では,外部にあらわれた行為の不適切さをもって過失を判断する考え方(客観的過失)が支持を集めている(大判大5。12・22民録22-2474〔大阪アルカリ事件〕)。 

これについては近時の最高裁判決がないため、一応、客観的な注意義務違反説に立脚したようです。

これは裁判上の立証に影響を与えそうですが、実際どれほどの影響があるのでしょうね？
心理状態だとすると現場の担当者が「いかに言われたことしかやらず、漫然とリスクを見逃したか」を示せば結果の重大さを問わず重過失認定される、というのはハードル高そうです。
結果回避だとすると「緊張状態を問わず明らかなリスクを見逃した事実」を指摘すれば足りるのでハードルは低くなるのでしょうか。

マルチベンダの調整は公共発注で注意が必要かも

大規模な開発になると、要件定義はＡ社、設計～開発はＢ社、というように工程ごとに異なるベンダーが担当することがあります。

モデル契約13条としては用語の変更にとどまっていますが、ふと公共発注で、要件定義書の作成のみを委託する案件を思い出しました。

要綱には「次年度、開発工程は成果物である要件定義書をもとに入札にかける」と記載があり、社内のレビュー時に「成果物である要件定義書が当社でしか実施できない内容だった場合、次の工程に用いることができないとしてやり直しになるリスクがあるので注意」と指摘しました。

上流工程の成果物の不備から下流工程担当のベンダーとユーザーとの間で紛争になるケースがありますが、モデルでは全体東郷リスクはユーザーが負うものとしています。しかしこのような統括管理ができないからベンダーに委託するので、本当の意味でこのような管理を行うことができるユーザーは少ないのではないかと思います。

「変更協議の不調時にベンダーにも解約権を与えうる」のは現実的か？

この条項を提示できるのは少ないんじゃないかなと思いますが、仕様変更協議の結果、ベンダーからプロジェクト中止を提言した場合にユーザーが合理的理由を示さず応じない場合はベンダー側から解約できるとする条項が提案されています（38条B案）。

たしかに客観的に見ればお互いのコストばかりが増える変更の泥沼に陥った場合に、プロジェクト目的が達成できないことを理由に打ち切ることは合理的でしょう。
しかし当事者は「達成できない」かどうかの認識で争うものです。ユーザーがシステムの素人であれば、「なんでこんなこともできないんだ！？」と憤るようなことも、ベンダーにとっては「難しい処理なんだよ！」という認識の違いはよくあります。

ということは変更協議が整わなくて、中止を申し入れた時点で紛争に片足突っ込んでいるんじゃないでしょうか。この点は個人的には同条項の下敷きになった東京高判平成25年9月26日（スルガ銀行対日本IBM事件）の判旨がややキツイな、という感じです（IBMだからこそ中止と進言できる可能性があると判断されたのではないでしょうか）。

システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状ステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変度の修正を要すること、更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダとしては、そのような局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負うものというべきである。

しかもこの条項案は5項で解約時までの委託料請求権を認める一方で、解約までの過程に債務不履行などがあった場合の損害賠償権を認めています。
たしかにそうなんですけど、泥沼の状況しか目に浮かびません。

システム再構築は現状調査と再構築目的の整理が重要（わかっとるわい）

2025年の崖に指摘されるように、古いシステムを運用し続けている企業は多くあります。私も5年、10年運用されてきていたシステムの管理者をやっていましたが、まあ「導入時の資料がない！」「変更の記録がない！」は日常茶飯事でした（特にシステムに対する意識の低い会社だったので）。

そういったシステムのリプレイスに複数当たってしまったので、いろいろやりましたが、長くいる長老みたいな人にヒアリングしたり（こういう人の記憶と経験が重要）、ベンダーとの打ち合わせで可能な限りの考えられる不具合や影響度の提言について協議しました。あとドキュメントをなるべく残すことに注意しましたね（その分仕事は増えるのですが）。

それでも不具合は発生しました。システムの本来用途には影響はなかったのですが、結局解決せずでした。

これは契約で担保する問題ではありませんし、現実発生を完璧に防ぐのも不可能でしょう。

結局このときはリプレイスは完了したのでいったん検収し、可能な限り原因調査を行い（もちろん無償で）、「影響がないのでもういいです」と私で判断して打ち切りました。

これは影響度が低い不具合だったのと、リプレイス要件を明確にしていたので重要度の判定ができたのと、あとベンダーが真摯に対応していたからこのような判断ができたのであって、中々再現できるような対応ではないのかなと思います。

とりあえずこんなところで。