「ソフトウェア紛争とADRの利用」と題するセミナーに参加してきた。
これは，ソフトウェア紛争（いわゆるシステム開発トラブル）の解決プロセスとして，ADRも検討しましょう，という趣旨で，SOFTIC（財団法人ソフトウェア情報センター）の運営するADR機関のソフトウェア紛争解決センターの宣伝も兼ねたものだといえる。
内容は，主に過去のシステム紛争事例紹介（８件）をするとともに，本件でADRを導入できたか，どんな効果が期待できたか，といった考察を加え，後半では，各事例紹介者によるパネルディスカッションが行われた。
紹介された事例のいくつかは，すでに知っているものだったが，知らない事案もあり，なかなか興味深い事例もあった。
後半のパネルディスカッションで登壇したのは，10名の弁護士だったが，ここには，実務側（SIerとか，ユーザのシステム部門とか，コンサルタントとか）も加わるとよかったのではないかと思われる。10名の弁護士は，IT紛争処理の経験もあることから，法的観点からの分析においては申し分ないというところだが，事実の部分，特に紛争の原因に関する話題となると，「ユーザとベンダとの間のミスコミュニケーション」といった表面的かつ実務の世界では昔から言われているようなところにとどまったのが惜しいところ。
話を聞いてみて，ADRを訴訟の代替プロセスとしてとらえるのではなく，ADRを紛争処理プロセスのより上流で活用することができ得ると感じた。つまり，訴訟は，トラブルが煮詰まって両者の関係が最悪となって，少しでも金を取りたい，といった場面で利用されるわけだが，その一歩，二歩手前でADRが使えるかもしれない。すなわち，プロジェクトマネジャーがユーザと協議して，納期や追加費用のことで交渉が進まなくなったが，まだ再開の余地があるような状態で「第三者によるプロジェクト再建」を目指す場合などに一考の余地がある。
現在，私もシステム開発トラブルの案件を担当しているが，かなり上流（納期が遅れたり，テスト結果がボロボロなのが露見し，プロジェクトがおかしいぞ，という時期）から遠巻きに関与していた。ただ，この案件でADRを利用できたかどうかは，「？」がつく。抽象論として利用価値がありそうでも，個別具体の事情を考えると，なかなか難しい問題ではある。
最近では，契約書に「契約内容変更は書面による」とするだけでなく，仕様変更プロセスについても書くようにしているが，もう一歩進めて，紛争処理に関しても，単なる「誠実交渉」「裁判管轄」を書くのみならず，もっと具体的な紛争解決プロセスを規定すべきかなあ，と考えさせられる。
