外部設計書とは、要件定義で決めた機能や性能をもとに、これをどのように実装するのかを設計する書面であり、「具体的には、サブシステム構成や各サブシステムの機能仕様、画面/ウィンドウ入出力や帳票等の利用部門ごとのインターフェース仕様、サブシステム間や他サブシステムとのインターフェース仕様、データベース仕様、移行仕様、運用・障害対策仕様、セキュリティに関する仕様等」(司法研修所編「民事訴訟における事実認定-契約分野別研究(製作及び開発に関する契約)-」法曹会・平成27年・105頁)とされています。
システム開発において、要件定義書とともに、外部設計書(基本設計書)を作成することは共通認識となっていますが、現実には、ユーザーの確認を得ていないケースもあるようです。また、ベンダーの中には、ユーザーの無知に乗じて、いい加減な外部設計書を作成するケースもあります。
外部設計書は、ユーザーの希望をどのように実装するのかという設計書ですし、システムを構築しテストや検収を行う際に参考とされるものです。そのため、しっかりとしたものを作成し、ユーザーの承認を得ておく必要があります。
司法研修所の書籍でも、
「基本設計とは、一般に、ユーザーが日常の業務において使用する画面や帳票などのインターフェースを設計し、決定する工程とされ、ユーザーの視点から、どのようなソフトウェアを開発するのかを決める工程であるとされる。インターフェースは、ユーザーが日常業務の中で使用しているものであるから、企業文化や使い勝手、企業ノウハウなどが反映される内容が多く含まれている。ベンダーは、要件定義書を基にユーザーからこうした点について更にヒアリングを行い、その成果物として基本設計書(外部設計書)を作成し、これについてもユーザー企業の了解を得る。」(司法研修所編「民事訴訟における事実認定-契約分野別研究(製作及び開発に関する契約)-」法曹会・平成27年・104頁以下)
とされていますし、システム開発に精通している弁護士の書籍でも、
「外部設計についても、要件定義同様に、最終的にはユーザーが決定しなければならない事柄である。」(難波修一他著「裁判例から考えるシステム開発紛争の法律事務」商事法務・2017年・18頁)
とされています。
ところが、外部設計書の意義を理解していないと思われる裁判がありました。
ベンダーが、一部の外部設計書を作成しユーザーに提示したが、その外部設計書には、帳票レイアウトやデータベース仕様など多くの書面がなかったというケースがありました。
ユーザーは、システム開発が完成していないと主張するとともに、外部設計書すら不十分であると主張したところ、ベンダーは、キックオフミーティングでベンダーが指摘したもののみを作ったのであり、他の書面を作成する合意はなかった、また、そもそもこのシステム上では何でも作れるのであり、帳票レイアウトは不要であるなどと主張しました。
これについて、裁判所は、ベンダーの意見をそのまま鵜呑みにして、何でも作れるのであるから、帳票レイアウト等外部設計書の一部が欠けていても構わないと判断しました。
そもそも多くのユーザーはシステム開発の素人であり、どのような書面が必要であるのか、システム開発が始まった段階では知らないことの方が多いでしょう。このようにベンダーとユーザーとの間の情報の非対称性がある状況で、合意がないので作らなくてよいと言えるのでしょうか。これでは、狡猾なベンダーにより、必要な書面が作成されず、また作成されてもずさんな内容の外部設計書がまかり通ってしまいます。
また、前述の通り、外部設計書はユーザーの希望をどのように実装するのかという設計書であるとともに、システムを構築しテストや検収を行う際に参考とされるものです。テストには、ユーザーによる受入テストも含みます。不十分な外部設計書で、どのようにテストや検収を行うのでしょうか。また、これでは、テスト段階になってはじめて、ベンダーとユーザーとの間で認識に齟齬があったことが判明することにもなりかねません。こうなったら、もう後の祭りです。
さらに、プロジェクトには、QCD(Quality=品質、Cost=費用、Delivery=納期)という制約条件があります。費用はいくらでもかけられる、納期がないというのであれば別ですが、通常のプロジェクトでは、決まった費用内で、決まった期限までに、相当程度の品質を備えたものを作らなければなりません。ですので、「何でも作れる」というのは、これら制約条件を無視したものであり、合理的な理由とはなっていません。
この裁判では、そもそもシステム上何でも作れるという証拠もなく、どうしてこのような判断がなされたのか全く疑問ですが、これからシステム開発を進めようとしている企業としては、このような裁判もあるということを念頭に、どうすればトラブルを回避できるか考えることが必要です。
以上のことから、外部設計書をしっかりと作るのは当然として、システム開発を進める段階から、外部の専門家を入れて、逐一チェックすることが必要でしょう。ウォーターフォール方式の開発の場合は、各工程ごとに、必要な作業が完了しているのか、必要なドキュメントはそろっているのかなどを確認することが重要です。また、アジャイル開発であっても、ドキュメントが必要なのは同じであり、必要なドキュメントがそろっているのか確認しなければならないのです。