アホヲタ元法学部生の日常

連絡はTwitter ( @ahowota )でお願いします。アニメを見て法律を思い、法律を見てアニメを思う法アニクラスタ、ronnorのブログ。メールはronnor1あっとgmail.comへ。BLJにて「企業法務系ブロガー」として書評連載中。 #新人法務パーソンへ #オタク流勉強法 #明認方法 「アホヲタ元法学部生の日常」(ブログ)、「これからの契約の話をしよう」(同人誌)、『アニメキャラが行列を作る法律相談所』(総合科学出版)等。

システム開発契約研究の最良文献ー最新号の判例タイムズは買い!

判例タイムズ 2008年 12/1号 [雑誌]

判例タイムズ 2008年 12/1号 [雑誌]

*参考画像*1
1.システム開発契約27判例を分析した最新文献が出た
 システム開発契約については、若干の本があるが、古いものや一般人向けのものが多く、判例の到達点を探る文献はなかった。


 例えば、システム開発契約書の条文についての名著である

ソフトウェア取引の契約ハンドブック

ソフトウェア取引の契約ハンドブック

「ソフトウェア取引の契約ハンドブック」は、各条項の意義等をわかりやすくかつ的確に説明しており、優れた著作であるが、平成元年の本で改訂されていないため、その後の20年の判例の展開は同書には掲載されていない。


また、ケースを取り上げて研究した本として、コンピューター訴訟研究会の本

コンピュータ紛争事件のケース研究―争点の技術的な見方

コンピュータ紛争事件のケース研究―争点の技術的な見方

コンピュータ紛争 (2)

コンピュータ紛争 (2)

があり、ケースについての研究会の分析は参考になるが、これらは、あまり判例を引いていないし、約10年前の本ということもあって、いかんせん古い事例が多い。


やや趣向が変わるが、松島淳也弁護士の「システム開発をめぐる法律問題」は、数少ない判例の分析を提供するものとして興味深い。もっとも、一般向けに約10回と比較的短期間連載したものであり、かつ1回につき約1個の判例の紹介であり、「すべてのシステム関係判例を網羅的に検討する」というよりも、一般のSE等に、法律・判例の観点から注意事項を教えるといった側面に重点がおかれている。


そこで、判例を網羅的に研究し、その到達点を探す研究が求められていた。
判例タイムズ1317号(2010年4月15日号)のトップ記事である瀧澤孝臣裁判官の「システム開発契約の裁判実務からみた問題点」は、まさにこのような、求められていた判例実務の状況を踏まえた詳細な検討を行ったものである


2.瀧澤孝臣裁判官の分析
(1)三種類の視座の提供
 瀧澤孝臣裁判官は、27の判例を分析し、一応契約に基づく義務の履行が完了したことを前提に報酬額・損害賠償等を争う類型(契約完了後紛争型)、契約関係継続中に行うべき義務が果たされていたかが問題となる類型(契約継続中紛争型)、契約の効力や契約当事者等、契約締結当初の問題が争われる類型(契約締結時紛争型)の3類型に分類する。この類型化は、多数の判例を分析する際の有用な視座を提供している。
 また、このような視座は、「紛争を回避するためには何をすればよかったか」という観点からも有効に活用できるだろう。つまり、契約継続中紛争型を例にとれば、判例がどこまで委託者側の協力義務を認めているかを知っていれば、いくら「現業が忙しくてなかなかシステムに時間が避けない」としても、後で問題となったときに委託者側の責任が問われない程度まで、きちんと協力する必要があること等の教訓を導き、紛争化を避けられる*2。契約締結時紛争型の判例*3でも同様と解され、「紛争を回避するためには、契約の内容をできるだけ詳しく記載するのが望ましい*4」といった予防策についての示唆が可能であろう。具体的には、契約当初に仕様が固まっていない案件については、出来る限り仕様確定のプロセス及び費用の負担について契約上明確に記載し、運用においても、「仕様確定は儀式だった*5」といわれないように、実質的に委託者側が仕様を確認し確定させるプロセスを経るようにしてその記録をとることが望ましいといったことを示唆するとも言えよう。これは、契約完了後紛争型でも同様である*6


(2)システム開発の契約が確定的なものと捉えがたいという指摘
 27の判例の分析の結果、瀧澤孝臣裁判官は、

(システム開発契約の問題点については)契約の内容が確定的なもの、完結的なものとして捉えがたいものであることに根本的な原因があるのではないかと思われる。
判例タイムズ1317号27頁

と分析される。


つまり、*7双方の協同的作業によって徐々に「作るべきシステム」というのが具体化していくのであり、最初の段階では何を作るかが*8あまりはっきりしていない。そのために、「仕事は完成したのか」「瑕疵はあるのか」という判断が困難であるし*9、契約継続中は両当事者がそれぞれ協力する義務を負う(受託者のプロジェクトマネジメント義務と委託者の協力義務)ことにある*10、そして、契約締結時紛争型ではこれが契約の効力等として問題となってくるのである。

その意味で、裁判官にとっても、システム開発契約を十分に理解し、適切な判断を下すことは必ずしも容易ではなく、契約が徐々に具体化するという、契約締結の段階性を踏まえて、問題となる時点における契約内容を明らかにし、争点への判断をする必要があるのである。

まとめ
 上記で紹介した以外にも、同論文は、27判例を仔細に分析し、各判例の示唆するところ*11をまとめている。
 まさに、システム開発契約の締結や、システム開発紛争の解決に携わる法曹にとっての必読文献である。

*1:判例タイムズはアマゾンでは買えないので

*2:4月の繁忙期にプログラム作成の打ち合わせを依頼されてそれを拒んだ委託者について、信義則上協力すべき義務があったと判示され、結論として委託者側の契約解除の主張が否定された東京地判平成9年9月24日判タ967号168頁、同論文の(19)判決。

*3:例えば、契約において完成させるべき「仕事」の内容が曖昧なままだったので、受託者側が「仕事を完了した」といったのに、委託者側がこれを争い、裁判所が経緯の全体を踏まえて仕事の完成を否定した東京地判平成18年10月6日、同論文の(2)判決

*4:といっても現実には限界があり、この限界については、同論文でも言及している

*5:現実にこういう主張がされることはままある。

*6:なお、厳密には、契約完了後紛争型についても、契約の解釈が争われることもあるので、オール・オア・ナッシングではなくあくまでも「視座」として参考にするのがよいだろう。

*7:仮に請負でも

*8:多かれ少なかれ

*9:契約完了後紛争型

*10:契約継続中紛争型

*11:重要な点としては、例えば「バグがあるだけでは瑕疵にはならない。簡単に取れない等システム稼動に支障が生じる場合でなければ瑕疵ないし欠陥には該当しない」とした東京地判平成9年2月18日、同論文(20)事件等