第1回 システム開発の流れと作成される書面の種類

契約だけでトラブルは防げるか

　システム開発におけるトラブルを未然に防ぐためには、単に、契約を適切に取り交わせばよいというものではなく、システム開発の全体の流れを頭に入れた上で、局面ごとに適切な対応をしていく必要があります。

　なぜならば、システム開発においては、その規模が大きくなればなるほど、当初の見込みから外れることも大きくなるからです。

　この分野の判決としては著名な、IBM・スルガ銀行事件の控訴審判決においても、

というような認定がなされているほどです。

　今回は、システム開発の流れ・全体像を概観したうえで、次回以降に、システム開発における特有の問題点や、開発局面に応じた対応などを見ていきたいと思います。

システム開発の全体像

　システム開発の種類は様々な切り分け方があり、スクラッチ型の開発なのか、パッケージ・ソフトをもとに、パッケージ・ソフトをユーザ向けにカスタマイズするのか、という切り分け方や、開発手法において、ウォーターフォール型、アジャイル型などがありますが、本稿では、ごく一般的な、パッケージ・ソフトを前提としたシステム開発について説明をしていきます。

　まず、経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」報告書－モデル取引・契約書＜第一版＞－概要（6頁）においては、以下のように、システム開発の流れが示されています。

　これを非常に簡略化してまとめると以下の流れになります。

　この流れにおいて、特に問題になるのが、業務分析とシステム化する範囲を確定するという作業です。問題となるには様々な理由があげられますが、1つには、情報の非対称性というものがあげられます。
　ユーザ側は、ソフトウェア開発の専門的知識を有していませんし、逆に、ベンダ側は、ユーザの業務についてその業務の専門性・特殊性が高ければ高いほど、ベンダもユーザの業務に対する知見が乏しいからです（司法研修所編「民事訴訟における事実認定－契約分野別研究（製作及び開発に関する契約）－ 」121頁以下（法曹界、2014））。

　この点に関しては、役割分担の明示など契約によって対応できる部分もありますが、契約のみでは対応しきれない部分もあり、その場合には、システム開発に特有な書面の存在が紛争においても重要な書証になるのです。

システム開発において作成される書面の内容

　それでは、システム開発においてどのような書面が作成されるのか時系列に沿って見ていきましょう。
　ただし、契約書の取り交わしについては、必ずしも、下記の時系列のタイミングで取り交わされるわけではなく、一括して取り交わされる場合も見受けられます。

　なお、モデルとすべき事例については、先述の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」の「モデル取引・契約書＜追補版＞」に詳しく掲載されていますが、以下では、理解のために簡略化して、紛争になった場合に重要となる書面について簡単に解説します。

RFP（Request For Proposal）

　RFPは、「提案依頼書」とも呼ばれるもので、ユーザが、システム開発をする際に、必要な構成要件や保証条件などが記載されているもので、複数のベンダに対して提案されることも多くあります。
　ところが、RFPに基づいて、複数のベンダをコンペに掛けて選定した場合でも、選定されたベンダがRFPに記載された通りに開発してくれるとは限りません。契約書や基本設計書に到達する経過で、RFPに記載された要件が曖昧になってしまうことも充分あり得るのです。
　したがって、法務的な観点からは、RFPとの整合性に留意しつつ、粘り強くベンダと交渉することが必要不可欠となります。

提案書

　提案書は、RFPに対する回答書であって、ベンダからユーザに対して、提案依頼事項に対する回答や、作業スケジュールや費用の概要を示した書面です。
　ユーザは、提案書を評価したうえで、発注するベンダを決定します。

契約書

　契約書、とひとくくりにしてしまいましたが、先にあげた経済産業省の研究会においては、分割して契約することを推奨しています。ここでは、概要を説明するにとどめ、深く立ち入らないこととします。
　契約書においては、システム化の範囲の概要、費用や、各当事者の役割分担等が決められます。

要件定義書

　システム開発特有の用語ですが、必ずしも統一された意味で使われていないようです。
　非常に端的に言えば、システム化すべき範囲をまとめた文書ということになります。 （司法研修所編：「民事訴訟における事実認定－契約分野別研究（製作及び開発に関する契約）－」103頁注18（法曹界、2014））。

　なお、このシステム化すべき範囲をまとめる作業を、要件定義といい、この点がシステム開発のポイントとなります。
　これは、以下の作業になります。

　なお、要件定義は、一般的に本来ユーザの責任で行うべきとされることが多いようですが、専門的知見が必要であることから、ベンダが要件定義支援を業務として行う場合が多く見られます。この点も、その責任が不明確になりがちな原因と言えるでしょう。

　そして、要件定義が不十分でありながら、納期との関係で次の工程に進み、トラブルが生じることが少なくありません。

基本設計書

　基本設計書は、外部設計書とも呼ばれ、これも統一した定義はありませんが、端的に言えば、インターフェースやシステムの入出力に関する仕様を定めた設計書です。

　要件定義では、システム化の範囲を機能ベースで確定していくものですが、基本設計書の作成にあたっては、その機能をどのようなインターフェースによって実現するかを定めます。インターフェースは、実際の使い勝手に直接影響するものですから、要件定義書をもとに、ベンダがヒアリングを行い、基本設計を確定していきます。

　そして、基本設計書の作成をもって、開発対象の仕様が確定するということになります。
　なお、基本設計書を前提として、ベンダはプログラミングの指針としての詳細設計書（内部設計書）を作成しますが、ここでは割愛しています。

次回の予定

　今回は、簡略化したシステム開発の流れと、システム開発において作成される書面の概略を示しましたが、次回は、システム開発における特有の問題点や、それに対する事前の備えについて解説する予定です。