MENU
BIZLAW BIZLAW
Powerd by LexisNexis®
BIZLAW
BIZLAW Powerd by LexisNexis®

RSS
Google+
Twitter
Facebook
HOME

システム開発のリスクを
コントロールするために

弁護士 松島 淳也

main_matsushima_02

Author’s Voice 『システム開発紛争ハンドブック―発注から運用までの実務対応』(1)

昨今、システム開発をめぐる法的トラブルが大きな注目を集めるようになっています。その背景には何があるのでしょうか。『システム開発紛争ハンドブック―発注から運用までの実務対応』(弊社刊)の著者の1人である松島淳也弁護士に、同書の読み方と併せてお話しいただきました。


s

システム開発紛争ハンドブック – 発注から運用までの実務対応
Legal Handbook for Resolution of Disputes Over System Development

松島淳也 / 伊藤雅浩(著)

定価:¥4,000+税

出版社:レクシスネクシス・ジャパン(2015年6月9日)
ISBN-13: 978-4-908069-16-1


高度化・複雑化する
システム開発紛争


――システム開発紛争の最近の傾向について教えていただけますか。

 一時期、クラウドやパッケージソフトウェアの利用が進めば、システム開発紛争は減少するのではないかといった見方もありましたが、外部のベンダに開発を依頼するニーズは今も変わらず存在しているといえます。

 ユーザとしては、汎用品を導入するのではなく、ベンダと高額な契約を締結したうえで開発を委託しているわけですから、システムに求める機能がこれまでよりも高度化・複雑化しており、ベンダへの要求水準も高まっているように感じます。そのため、ユーザの思い描いたようなシステムとするのが困難なプロジェクトが増えているのではないでしょうか。

 一方、ベンダ側としても、従来は「いったん受託した以上は、赤字でも絶対に最後までやり抜く」という姿勢を示すことが多かったように思います。しかし、最近は1つひとつの案件で採算を判断する傾向が強まっており、不採算プロジェクトからは撤退するという経営判断をするケースも増えています。

 そうした変化が積み重なった結果、以前と比べて、複雑な大型案件の開発失敗が表面化して紛争化する事案が増えていると思います。


――裁判で争われる金額も増大しているのでしょうか。

 私が相談を受けている事案に限っても、契約金額が数億円規模の開発案件はよくあることですし、十億円を超える規模というものも珍しくありません。 そういった規模の契約でトラブルになってしまうと、和解をするにしても、社内の意思決定だけでは和解金額の適正性を担保できないことから、裁判所に持ち込まざるを得ないといった事案が増えています。

 裁判になると、数億円規模でも審理期間は2年~3年ほど、数十億円規模となれば3年以上の期間を要することも覚悟する必要があります。


困難なプロジェクトを
やり遂げてこそ一人前…?


――なぜシステム開発紛争はなくならないのでしょうか。

 プロジェクトマネージャーなど責任ある立場を任されている人は、これまでしっかり実績を上げてきた人が多いので、自分のプロジェクトがうまくいっていないことを、法務部や総務部に報告することに相当な心理的抵抗を感じるようです。

 私がシステムエンジニアとして働いていた頃も、先輩たちからよく聞いたのは「いかに自分は困難なプロジェクトを乗り越えてきたのか」という“武勇伝”でした。開発プロジェクトが失敗するかもしれないという局面を“リスク”として捉えるのではなく、「これをやり遂げてこそ一人前だ」と考えてしまう風潮が、これまで多くの会社で見られてきたと思います。

 だから問題が起きても、プロジェクトマネージャーは「これを乗り越えられないのは恥ずかしいことだ」と考えて、1人で頑張ってしまいがちです。それでうまくいけば、“武勇伝”になるのでしょうが、解決の糸口がつかめないままだと、2回、3回と納期の遅延を繰り返し、より大きな紛争に発展しかねません。

 必要なのは、プロジェクトマネージャーが1人で問題を抱え込むことなく、いつでも相談を受けられるように社内体制を整備して、プロジェクト失敗のリスクをコントロールすることです。


――紛争予防のために、ベンダ・ユーザは何をすべきでしょうか。

 プロジェクトマネージャーを集めて、法的問題に関する研修を行ったり、裁判例を取り込んだ行動指針を作成するといった取組みをしているベンダは増えています。ただ、本当に難しいのは、こうした研修等で得た知識をいかにして実践に移すのかという点です。ベンダは受注競争に勝たなくてはならないので、ユーザに対して積極的にリスクを説明しようというモチベーションは起きにくいかもしれませんが、紛争を防止するためには、不動産契約における重要事項説明のように、リスク情報も含めて丁寧に説明することが必要ですし、それが当たり前のプロセスになってほしいと思います。

 ユーザも、「リスクの説明を十分にしないベンダは信用ならない」という意識を持つべきといえます。提案書の検討やベンダの選定段階から、情報システム部門に加えて、自社の法務担当者やシステム開発に詳しい弁護士を関与させることで、リスク管理をしている企業もあります。


『システム開発紛争ハンドブック』の
読みどころ


――本書の特徴はどこにあるのでしょうか。

 システム開発紛争に関する過去の裁判例を豊富に盛り込んだのが一番の特徴です。だからといって、単に裁判例を紹介することを目的とした本というわけではありません。あくまでも、システム開発において発生しがちなトラブルを「もし裁判で徹底的に争ったらどうなるのか?」という観点から分析しました。ですから、ユーザ側・ベンダ側のいずれか一方の視点に偏ることなく、あくまでも中立に、裁判所から見たらどのように判断されるのかという点を重視して執筆しました。

 本書を読めば、紛争になった場合の結末について、事前にある程度見通しを立てることができますので、トラブルが発生したときの対応方針を決定するのに大いに役立つと思います。


――本書の読み方について教えてください。

 ユーザの法務担当者や情報システム担当者の方は、まずは紛争の全体像を示している第1章を読み、その後は、関わっている案件の進捗にあわせて、対応する章を読むのがよいと思います。第1章を読むだけでも最低限必要な知識が身につくように執筆しています。

 ベンダの法務担当者やプロジェクトマネージャーならば、トラブルの相談が持ち込まれたとき、すぐに対応できるよう、本書の全体を通読し、どのような紛争類型があるのか、事前に把握しておくのがよいと思います。特に緊急事態においては、初動のつまずきが後になって大きなダメージとして響いてくる可能性があります。突然、クライアントから「謝罪文を提出せよ」と要求されたとしても適切な一次対応ができる人材が社内にいることの意義は非常に大きいと思います。

 また、ベンダの営業担当者としては、契約をとってくるまでが自分の仕事と考えるかもしれませんが、最近の裁判例では、営業担当者が果たす役割も非常に重要になっていることに注意が必要です。というのは、東京高裁平成25年9月26日判決(スルガ銀行対日本IBM事件)において、企画提案段階からプロジェクトマネジメント義務(説明義務)が発生するとされたからです。企画提案段階のユーザとの交渉では、営業部門の方が交渉をリードしているベンダも多く、この時点で重大な義務違反が認められると、損害賠償額が高額になる可能性があります。

 システム開発紛争の原因は、突き詰めると、ユーザ・ベンダ間のリスク・コミュニケーションの問題といえます。コミュニケーションの改善は、ユーザ・ベンダの片方だけが実践できても意味がありません。両者ができていなければ全体として失敗してしまいます。システム開発に関わる方であれば、職種を問わず是非ともご一読いただきたいと思います。


取材、編集/Business Law Journal 編集部
撮影/田辺慎司


prof_matsushima

Profile

松島 淳也 [弁護士]

97年早稲田大学大学院理工学研究科修了。富士通株式会社にて、マイクロプロセッサーの開発、電子商取引システムの開発等に関わる。06年弁護士登録。
情報システムの開発に関する訴訟・契約事務・法律相談をベンダ・ユーザ双方から多数受任しており、関連する業務(知的財産、情報管理、インターネット取引、OSS、下請法、電子マネーなど)まで含めると、業務のおよそ8割をシステム開発に関わる分野が占める。




ページトップ