以上までのコラムでみてきたように、システム開発における紛争は多岐にわたっています。これまでのコラムの最後として、システム開発紛争の解決の際に有用と思われる、最近の裁判所の印象や特徴（東京地裁）についてお伝えしたいと思います。

最近では、同種事件の多数発生や提起があり、専門委員の積極的採用や調停の活用が行われています。専門委員は技術的争点がある場合に参画することが多いです。多くはベンダー出身者で、裁判所のアドバイザーであり、鑑定等をするものではありません。そのため、鑑定と比べて簡易・迅速な判断や柔軟な対応が期待でき、現場を知っていることにより当事者も和解しやすいことです。

ADR（裁判外紛争解決）の一つである調停も最近では盛んに行われ、実績も出始めています。弁護士、専門家等により執り行われます。
最近では、ソフトウェア紛争に特化したADR機関であるSOFTIC（財）ソフトウェア情報センター等も活躍しています。ADRの特徴としては、専門家第三者の関与も可能で、簡易迅速で非公開であり、和解による終了の確率も高いことから早期・合理的解決を図るには適しています。

ただし、調停が成立しない場合には、より長期化したり、調停部での争点整理・心証が裁判になった際に引き継がれない可能性があります。

調停を利用しない場合や調停がまとまらなかった場合には裁判となります。その際に裁判所が考える「争点を解明する上での重要事実」としては、①開発に関与した各社の関係、②開発対象に係る情報（ユーザーの事業、開発対象業務の概要、システムの概要、パッケージソフトの利用、現在の状況）、③開発態勢（ベンダーの経験値、重要な担当者の経験・スキル）、④時系列情報（動機、契約締結時期、仕様確定経緯、支払状況）となりますので、このような事実について確認しておくことや書面と証拠について準備しておくことが有用でしょう。
そして、証拠整理としての注意点として、書証は整理されないまま大量に裁判所等に提出されたり、証拠価値との関係を度外視してプログラムのソースコードや保有するメールすべてを提出される等して、記録が膨大となる傾向にあります。

そのようになると審理が長期化してしまいますが、その対応策としては、①証拠説明書で個々の立証趣旨を明らかにし、計画的に提出する、②立証に用いる部分をラインマーカーで示す、③期日直前に書面や証拠を提出すると期日が空転するので、期日直前に書面・証拠を提出しない、ことが重要であるといえます。

また、書面作成の際、できるだけ一般的な用語、一般的な意味で使用し、プロジェクト・業務固有の用語については用語集を作成する等するのがよいかと思います。当該事案での用語の使い方が一般的な意味と乖離していることがあると、誤解を生み、審理が複雑長期化する恐れがありますので、それについても注意が必要です。具体的な主張の問題を挙げると、瑕疵の立証では、ユーザーが主張する瑕疵の対象となる成果物のバージョン、環境、データについて特定しないとベンダーとの間で議論がかみ合わないので、瑕疵一覧表を作成するのが有用であると思われます。その際、「瑕疵の内容」、「あるべき仕様」、「補修費用」等の項目を設け、それぞれの欄について、ユーザーとベンダーのそれぞれが主張するようにすると、グルーピングや整理で注意することができ、無用に件数が増えないようになるかと思います。