ベンダに開発委託する自社システムについて、システムの性能確保やセキュリティリスク等について、どのような対策を行えばよいのでしょうか。
システムの性能や可用性、運用・保守性、脆弱性への対応といったセキュリティ要件、その他のいわゆる非機能要件については、要件定義段階でどこまで明確に合意できているかという点が重要となります。
１ 非機能要件、セキュリティ要件とは
要件定義工程（システム開発において、ユーザのシステムに組み込みたい要求をまとめる工程）において、システムに搭載すべき機能を書き出した項目が「機能要件」であるのに対し、ユーザが機能面以外の品質についてシステムに求める項目が、「非機能要件」といえます。
非機能要件には、例えば、「レスポンスが●秒以内に返ってくること」、「システムダウン時は●時間以内に復旧すること」、「●●に関する脆弱性に十分な対策を施すこと」というようなものがあります。そして、最後に例示したようなシステムのセキュリティに関する要件をここでは「セキュリティ要件」といいます。
２ 非機能要件の重要性
明確に「こういう機能がほしい」というイメージがつきやすい機能要件と異なり、非機能要件は、ユーザの立場からすると、専門性が高く、業務との関連も見えにくいため、関心を持ちにくいという問題があります。また、ベンダの立場からも、非機能要件及びその実現手段について、その必要性・理由の十分な説明ができず、提案が難しいという問題があります。
これらの理由から、システム開発においては、要件定義段階において非機能要件について十分に議論されず、また、明確に合意されないケースも見受けられます。
しかし、非機能要件を合意していない場合、ユーザ・ベンダ間でシステムがいかなる品質を備えるべきかという認識に食い違いが生じ、ひいては、対応漏れが生じる可能性があります。その結果、下流の開発工程において混乱が生じ、また、システムの運用フェーズにおいて、想定外に処理時間がかかってしまったり（想定していた業務に対し、使い物にならないシステムとなってしまう。）、セキュリティ上の脆弱性に起因して情報漏洩事故等が発生するおそれもあります。
さらに、上記のような事故等が発生してしまった場合の責任を、ユーザ又はベンダのいずれが負担するかという点も問題となります。
これらのようなリスクを回避するためにも、要件定義段階において非機能要件を明確に定義、合意しておくことが重要です。
３ 非機能要件に関する合意の有無、ベンダの責任が問われた裁判例
（１）セキュリティ要件への対応不備が問題となった裁判例
実際、非機能要件の合意の有無や、システムの品質・セキュリティが問題となり、当該品質等に関するベンダの責任が問われた裁判例が存在します。
例えば、東京地判H30.10.26平29年（ワ）40110号は、車・バイクの一括査定システムについて、いわゆるSQLインジェクションに対する脆弱性が存在し、当該脆弱性により、当該システムは4年以上にわたり不正アクセス、情報漏洩等のリスクに晒された状態で運用されていたという事案ですが、開発当時ユーザ・ベンダ間で取り交わされた「確認書」では、当該システムの制作に当たってはセキュリティを十分に確保し、インターネット上の様々な環境においてもエラーや投稿情報漏れをなくし、個人情報の流出に対して十分な対策を備えるよう努めることが定められ、その主な仕様を定めた仕様書にも、セキュリティに関して気を付ける点として「SQLインジェクション」が既知の脆弱性の一つとして明記されていました。
裁判所は、さらに、遅くとも当該システムの制作が発注された時点において既にSQLインジェクションによる不正アクセス等のセキュリティ上のリスクの存在及びその具体的な対策方法がシステム開発の業界内では周知されていたことや、ベンダがSQLインジェクションの対策不足を自認していたことなどから、ベンダにSQLインジェクションに対する対策を講ずべき注意義務を認め、また、当該対策を怠ったことによるベンダの不法行為を認めました。
（２）システムの処理時間に関するベンダの責任が問われた裁判例
次に、東京高判R4.10.5令4年（ワ）2390号は、開発された基幹システムの本番稼働後、夜間バッチ処理が夜間に終了せず、異常終了するとの障害が発生した事案であるところ、当該夜間バッチ処理の時間に関する性能要件（9時間以内に完了すること）が合意されていたか否かが争いとなりました。
この点、上記のような「9時間以内にバッチ処理を終えるシステムを完成させること」を明確に約する合意書等がない事案でしたが、裁判所は、一般にシステムにおいて定期実行されるバッチ処理が、想定されるデータ処理量の処理を所定時間内に完了する性能を有していなければシステム全体が機能しなくなる可能性があるため、その処理が完了するまでの時間というバッチ処理の性能要件に関する定義はシステムが正常に稼働するかどうかに関わる重要な問題であり、システムの開発作業前にそのような性能要件を定義しないことは通常考えにくいと述べたうえで、当該システム開発にあたり作成されたシステム方式設計書の「バッチ処理時間」項目において、定期実行されるバッチ処理の実行時間帯が記載され、また、バッチの完了予定時刻までに完了することを目標とする旨記載されていることなどから、当事者間で合意された当該システムの性能要件として、「定期実行されるバッチ処理の実行時間帯（筆者注：別途作成された「バッチジョブ運用スケジュール表」においては午前0時30分から午前9時30分までの9時間の間に割り当てられていました。）の終了予定時刻までに（筆者注：夜間9時間以内に）、通常想定されるデータ処理量のバッチ処理を正常に完了すること」が含まれていたと認定しました。
４ まとめ
以上のように、システム開発において非機能要件の合意内容が争われる紛争は多く見受けられ、この点に当事者間の明確な合意がなければ、ユーザとしては、開発されたシステムが使用に耐えないものとなってしまうことがあり得、また、ベンダにとっても、想定外の非機能要件が認定され、損害賠償義務が発生してしまうといったリスクに直面することになりますので、要件定義段階において十分な検討・議論が尽くされている必要があります。
なお、そのツールとして、例えば、独立行政法人情報処理推進機構（IPA）が、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示した「非機能要求グレード」を公開しており、ユーザ・ベンダ間で各要求レベルを設定していくなどすることにより、網羅的に非機能要件を検討することができます。
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
2024年9月9日
