1.ベンダのプロジェクト管理義務
社内でシステム化要件をとりまとめ、必要な時期までに必要な時期までに凍結しないユーザの協力義務とユーザの要望を実現するための困難さや悪影響をユーザに説明し、双方が納得する提案（別費用での対応や先送り等）をしなかったベンダのプロジェクト管理責任が問われる。
時に無理ゲー
2.正式契約をしない開発
- 契約書に契約タイプ(請負、準委任)を明示していない
- 成果物やユーザとベンダの役割分担が明示されていない
- 成果物を「○○システム一式」とだけ記した注文書やメール、口頭で作業着手をしてしまう
素敵〜
参考
情報システム・モデル取引・契約書
http://www.meti.go.jp/policy/it_policy/keiyaku/
http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05
3.契約を期待しての作業着手
作業着手の契機となった書類等を慎重に検討し、「供給者（ベンダ）が、契約を期待しても致し方ない状況にあったか」を見極める。
納期との戦い
4.システムの完成と瑕疵
残存したバグの数や重大さ、当初要件に含まれていなかった業務範囲や仕様変更、要件追加等への対応、開発中に検証できない性能要件への対応の可否(中略)セキュリティ要件や排他制御(中略)ユーザ指定の(中略)ハードウェアにインストールされていること、テスト結果の判断基準やソフトウェア完成基準が曖昧なこと
(中略)
裁判所がこうした問題に対して技術論から責任を問うことは少ない(中略)問題になるのは「受給者は約束をした仕事をしたのか」(中略)であることが多い。
(中略)判断するのには、１つには予定した工程が全て終わっているのか、２つには完成したシステムが業務に寄与し、導入の目的を叶えているか、あるいは叶えることが確実であるかを判断するケースが多い
(中略)
裁判所は、まずシステムが通常よく使われる業務の正常系について問題なく動作するかを見ることが多い。
(中略)
あまり使われない業務や運用系等、直接ユーザの業務に大きな影響を与えない様な場合はシステムを完成していると見なす判例がある。
(中略)
場合によってはバグの修正を行う必要がないとする判決がある(中略)オペレータに対して、その対処を十分に説明し、理解を得られればシステムは完成していると見なすことがある
またの名を
「バグも仕様書に書けば仕様です」
素敵〜
