判例（システム稼働日の予定については、これを守らないからといって、直ちにITベンダーに責任があるといえないとした判例）

判例（システム稼働日の予定については、これを守らないからといって、直ちにITベンダーに責任があるといえないとした判例）

（１）システムの発注において、システム稼働日のスケジュールが決まっていることが多いです。
（２）ITベンダーは発注者の要望を聞いて、システムの仕様を決め、システムの開発、テスト、進捗の管理、適切な変更の提案等をすることが業務内容に含まれます。
（３）システムの開発は、ITベンダーだけでできるものではありません。例えば、発注者からの追加の要望があれば、開発計画は遅延します。
（４）本判決は、開発業務の後半になっても開発側が追加要求を繰り返すこと等が原因でシステム稼働日を遅延することにつながった（もやは、システム開発を、システム稼働日に間に合わすことが不可能になった）と認定しました。
（５）本判決では、そもそも、「システムの稼働日」は、システム発注契約において、期限として合意されていない、と判断しました。

東京高裁令和3年4月21日　
判例タイムズ１４９１号20頁

解説

１　システム発注は難しいこと
（１） システムの発注ですが、システム会社だけでは作ることはできません。
（２）まず、発注者側で、どのような機能がいるのか明確にしてもらないと作るものが決まりません。
（３）次に、システム会社としては、当初、予算も、工期も、正確に分かりません。例えば、パッケージソフトを基本として、追加開発がどれだけいるかも、発注者との打ち合わせをしてみないと分かりません。
（４）例えば、開発が進んだ段階で追加で要望が出た場合、開発を最初からやり直すこともあります。
（５）発注会社側で当初に必要な機能を明確にしてもらう、テスト等の時点で、追加機能を全て洗い出してもらうことができなければ、システム発注は失敗します。

２　発注会社の本音
（１）発注会社側の本音は、以下のとおりでしょう。
（２）予算は伝えてあるので守って頂きたい。
（３）システムは素人であるので、必要な機能は、ヒアリングで聞き出して欲しい。
（４）予算、システムを作る目的を伝えてあるので、細かい仕様はシステム業者が提案してほしい。
（５）発注会社の担当者は本業の兼任で、システム開発に関わっています。本業も忙しく、システム開発への関与は後回しになりがちです。

３　ポイント
（１）システム開発の失敗については、失敗の原因がどちらにあるのか明確でないことが多いといえます。
（２）発注会社としては、システム契約の本質をしっかりと理解すること、経営層が正面からシステム開発に関与すること、経営層がシステム契約の進捗を直接管理する体制が必要です。
（３）発注会社は、システム発注のノウハウがありません。しかし、IT化は経営課題であり、失敗を恐れずに、小さな案件から進めて、システム会社との相互理解を深めていくのがよいでしょう。
（３）システム会社と発注会社は、すれ違いを防ぐうえでも双方の意思連絡について、適宜記録することが必要になります。

３　期限の性質
（１）システム契約の特殊性を考えれば、システムの稼働日（予定日）について、これを過ぎれば法的責任が発生するという「法律上の期限」であると認定されなかったのは当然です。もちろん、難易度の低い開発であれば、「法律上の期限」と認定されるケースもあるのかもしれません。
（２）システム契約においては、ITベンダーとしては、システムの稼働日に合わせて、合理的な開発計画を立てること、予見不可能が事情があれば合理的な対応策を提案する義務があります。本件では、ITベンダーとしてはこれらの義務を果たしていたと認定されたと思われます。