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

RSS
Google+
Twitter
Facebook
HOME

豊富な判例分析から実務対応まで
システム開発の法務に必携の1冊

info_mmn_05_image05

出版記念インタビュー 桃尾・松尾・難波法律事務所

数々のシステム開発紛争を解決へと導いてきた、桃尾・松尾・難波法律事務所の4名の弁護士が著した『裁判例から考える システム開発紛争の法律実務』。出版を記念し、著者である難波修一弁護士、中谷浩一弁護士、松尾剛行弁護士、尾城亮輔弁護士に、増え続けるシステム開発紛争の典型例や予防策について伺った。

(制作/レクシスネクシス・ジャパン広告出版部)



システム開発の実情をいかに理解できるか


―本書を出版された背景や動機をお教えください。

info_mmn_05_image01

難波 修一 氏

難波 業務の効率化を図るためにシステム化は必須であり、多くの企業でシステム開発が行われています。そうした中で、近年はシステム開発に関わる紛争が増えており、当所でも多くの紛争解決をサポートしています。

 システム開発ではどのような事柄が紛争になりやすく、裁判になった場合に裁判所はどのような考え方をし、判断をくだすのか。我々がシステム開発紛争に関わる中で得た知見を活かし、そうしたポイントについて具体的な裁判例やケーススタディを交えて紹介することで、日々の紛争予防や紛争解決の見通しを立てる一助にしてもらいたい。それが本書の出版の大きな動機です。

中谷 システム開発紛争の質については、小職がIBMの法務に社内弁護士として勤務し始めた20年前と現在で大きな変わりはありません。開発現場の技術や管理手法は進歩しているものの、20年前と同じような紛争が今も日々起きています。

 目に見える製品を造る場合と違い、システム開発の場合は、完成した製品のイメージを共有しにくいという特性があるため、往々にして紛争に発展してしまいます。だからこそ、ユーザーとベンダーの双方が開発過程において協力し合わなければ、システム開発を成功裡に終えるのは難しいと言えます。そうしたシステム開発の実情については、これまでに蓄積された経験もあり、ベンダー側企業の法務部や裁判所では相当程度に理解が進んでいます。また、近年では「スルガ銀行事件」がメディアでも大きな注目を集め、多くの一般企業の方々にもIT法務の重要性が認識されるようになってきました。とはいえ、特にシステム開発に慣れていないユーザー側企業や多くの法律家の間では、システム開発の実情がまだまだ理解されていない部分があります。そうした方々が抱えている「よく分からない」部分を、分かりやすく解き明かすこと。それも本書の出版の目的の一つです。


― 松尾弁護士と尾城弁護士は、情報技術者を対象とする高度資格であるITストラテジストなどの資格もお持ちです。お二人から見て、典型的なシステム開発紛争とはどのようなものでしょうか。有効な予防策と併せて教えてください。

info_mmn_05_image03

尾城 亮輔 氏

尾城 やはり仕様変更が原因となるトラブルが典型的です。システム開発では、要件定義書や基本設計書というシステムの「設計書」をまず作るのですが、ユーザー側の担当者が、内容を十分に理解しないまま、これらの設計書にOKを出してしまうことがよくあります。結果、いざシステムが出来上がってくると、想定していたものと違うということになり、途中でユーザー側から多くの仕様変更が出てしまいます。そうするとベンダー側には大きな負担になってしまうため、追加料金の請求などでトラブルになりがちです。

 そのようなトラブルに至る理由はプロジェクトによってさまざまなのですが、その根底には、ユーザー側が設計の段階できちんと関与できていないという問題が挙げられます。ITストラテジストはまさにその「設計」の部分を体系的に理解するための資格ですが、システム開発に不慣れなユーザー側からすると、そもそも設計の部分を理解してプロジェクトをリードできる人材がいないというケースも少なくありません。

 技術的な観点から原因を見るとそうした設計の問題になりますが、仕様変更に関するトラブルについては、契約時に「ここまでの作業で、この価格ですよ」と、作業内容と金額を紐づけて書面化することによって、ある程度は予防することができます。

松尾 予防に関して二つほど補足すると、まず一つ目に「紛争になった後」についての意識、特に「証拠化」についての意識を高めていただきたいと思います。例えば、法務部門や弁護士が紛争に関与する場合、どこまで自社の主張が通りそうかを第三者の目で見ることになります。裁判にまで至った場合には、まったくの第三者である裁判官が証拠から法的な観点に基づき判断をすることになります。すると、例えば、「口頭で合意した」「電話で約束した」というだけで、そのような合意や約束を証明するための確たる証拠がない場合、いわば「言った言わない」の水掛け論になってしまうので、やはり主張は弱くなると言わざるを得ません。

 例えば、議事録を作成して判子をもらっておく、あるいは電話で重要事項を合意した際には、その内容を確認するメールを送付しておくといった方法で証拠を残しておけば、紛争の予防や早期解決につながります。

 そして二つ目には、自社の法務部門や弁護士に少しでも早く相談してもらうことが重要だと考えます。例えば、システム開発の現場では、契約書が締結されないまま作業の開始を指示されたり、仕様変更についての作業範囲や費用について双方の意見が一致しなかったりするケースがよくあります。

 その場合、法務部門や弁護士に相談しないまま、現場限りの判断で作業を進めてしまい、結果として紛争がこじれにこじれた後で法務部門や弁護士に持ち込まれても、十分な支援ができない可能性があります。本書でも詳しく触れたとおり、さまざまな場面に応じた法務的な「打ち手」は存在しますので、早め早めに法務部や弁護士に相談し、アドバイスを受けることが大切です。


150の判例分析と豊富なケーススタディ


―システム開発紛争の予防について、難波弁護士と中谷弁護士はどうお考えですか?

難波 システム開発には大きく分けて、ユーザーの現状の業務フローを省力化するための開発と、新しい業務のやり方を前提とした業務改革を伴う開発の2種類があります。後者の場合、システムの開発と同時に現場の業務改革を進める必要がありますが、そこでシステム部門と現場での乖離があれば、完成したシステムを実際に使う現場の人たちから「こんなシステムは使えない」という話が出てしまいます。結果、仕様変更の要求が繰り返されてゴールが遠ざかってしまい、プロジェクトが頓挫するというケースも多くあります。ですから、特に業務改革を伴うシステム開発の場合は、ユーザー側のシステム部門と現場がよく意思疎通を図っておく必要がありますし、ベンダー側としても、ユーザー側が現場の業務改革を推進する意識があるのかをきちんと確認してアドバイスしておくことが重要になります。

info_mmn_05_image02

中谷 浩一 氏

中谷 企業がシステム開発に投資する場合、どういったシステムを作るのかといった目標や予算をユーザー側が立て、それに合わせてベンダー側が提案を行うのが一般的です。その際に対象となるシステムの確固たるイメージを双方で持てないと、ユーザー側とベンダー側でさまざまなギャップが出てしまいます。

 加えて、システム開発紛争の原因の一つとして、多くの提案がコンペ形式で行われることも挙げられます。コンペでは、新規顧客獲得を目指すベンダー側が大風呂敷を広げてしまうこともあれば、ユーザー側が実際よりも良く見てしまうこともある。あるいは最終的には値段だけでベンダーを選定してしまうこともあり、提案の具体的な内容や、パッケージを使用する場合はそのパッケージが業務と本当にフィットしているのかといったことが、ベンダーのほうで精査できていないケースが少なくありません。

 そうしたケースでは、結果として大きなギャップが生まれ、紛争につながってしまうわけですが、解決策としては双方が膝を付き合わせて一つひとつ確認しながらプロジェクトを進めていくしかありません。システム開発においては、そうしたギャップを埋める作業が最も重要になるのではないかと思います。


―本書ではシステム開発における法律実務について、現場の実務に即して分かりやすく書かれています。本書の特徴を、類書との比較を交えて教えてください。

info_mmn_05_image04

松尾 剛行 氏

松尾 システム開発と法務については、既に相当数の書籍が出版されています。そうした類書と異なる本書の特徴としては、まず150という多数の裁判例を分析している点が挙げられます。

 システム開発を多く行う実務家の間では、典型的な問題の解決についての相場観のようなものが形成されてきました。もっとも、なぜその結論なのかを深く掘り下げた理論化についてはまだ不十分なところがあったように思われます。本書は、裁判例を手掛かりに、裁判所の判断の背景となる理論的な側面をも考察することで、いわば「射程」のような適用範囲の問題等も含めた多くの問題に対応できるようにすることを試みています。

 加えて、章立ては、一定程度の体系性を意識すると同時に、現場で生じる具体的な紛争の内容にも注目しました。実務で困っているテーマについて、各章が対応するような構成になっているのも本書の大きな特徴です。

 例えば、ベンダー側の立場でまさに今ユーザーから謝罪を求められているが、どう対応すればいいのか。そういう場面で本書にある「謝罪」の項目を読めば、謝罪にはこういうリスクがあり、どういう考え方で対応すればいいのかといったことを理解できます。なお、謝罪については本書出版後、当事務所ウェブサイトでフォローアップも行っています。


― 最後に、システム開発の現場で、本書をどのように活かしてもらいたいとお考えですか?

中谷 システム開発紛争では、特にユーザー側の法務や弁護士に経験や知識が乏しく、一方的な考えを持ってしまうことがよくあります。そうすると和解が進まず裁判に発展してしまい、結果として大きな労力がかかってしまいます。

 本書には、システム開発のプロジェクト自体を円滑に進め、紛争を予防するために参考になる点が多くありますが、私はむしろユーザー側でシステム開発に関わる方々に、実際の裁判ではどのような判断がくだされるのかといった点を、本書を読んでご理解いただければと思います。実際に紛争になった場合でも、ユーザー側とベンダー側双方の法務部が適切な実務感覚を持っていれば、妥当な和解が増えるはずです。現場で開発に関わる方々がそうした実務感覚を養うためにも、ぜひ本書を読んでいただければと思います。

難波 大きな紛争は誰にとっても不幸なことですから、ベンダー側、ユーザー側を問わず、現場の法務部や弁護士、さらにはエンジニアの方にも手に取っていただき、紛争の予防や早期解決に役立てていただければと思います。また、本書でカバーできていない最近の判例についてのテーマ別の解説等、関連情報のアップデートを随時ウェブサイトで行っていますので(※)、ぜひそちらもご参照ください。


※ 桃尾・松尾・難波法律事務所(https://www.mmn-law.gr.jp/
  トピックス内、フォローアップ連載:システム開発コラム(随時更新)



<読者プレゼント>


抽選で30名様に、『裁判例から考える システム開発紛争の法律実務』をプレゼントします。ご希望の方は以下のURLより応募ください。なお、当選者の発表は賞品の発送をもってかえさせていただきます。2017年6月30日お申し込みまで有効

応募ページ: http://www.lexis-seminar.jp/123-2/





Profile

難波 修一 氏 Shuichi Namba
[桃尾・松尾・難波法律事務所 マネージングパートナー 弁護士]

82年東京大学法学部卒業。84年弁護士登録(第一東京弁護士会)。87年アメリカ合衆国コロンビア大学ロースクール卒業。アメリカ合衆国ニューヨーク州Weil, Gotshal & Manges法律事務所、アメリカ合衆国ニューヨーク州バンカーズ・トラスト銀行勤務の後、88年アメリカ合衆国カリフォルニア州弁護士およびニューヨーク州弁護士登録。89年桃尾・松尾・難波法律事務所開設。

Profile

中谷 浩一 氏 Koichi Nakatani
[桃尾・松尾・難波法律事務所 パートナー 弁護士]

92年慶應義塾大学法学部卒業。97年弁護士登録(第二東京弁護士会)。97年日本IBM株式会社入 社。04年桃尾松尾難波法律事務所入所。07年ワシントン大学ロースクール卒業。07年よりイタリア・トリノ市のIP Boutique Firm,Studio Legale Jacobacci & Associati勤務を経て、10年1月より桃尾・松尾・難波法律事務所パートナー就任。

Profile

松尾 剛行 氏 Takayuki Matsuo
[桃尾・松尾・難波法律事務所 弁護士]

06年東京大学法学部卒業。07年弁護士登録(第一東京弁護士会)、桃尾・松尾・難波法律事務所入 所。13年アメリカ合衆国ハーバード大学ロースクール卒業。14年ニューヨーク州弁護士登録。16年桃尾・松尾・難波法律事務所(東京)での執務を再開。I Tストラテジスト、情報セキュリティスペシャリスト、プロジェクトマネージャー資格を保有。

Profile

尾城 亮輔 氏 Ryosuke Ojiro
[桃尾・松尾・難波法律事務所 弁護士]

04年東京大学法学部卒業。07年東京大学法科大学院卒業。08年弁護士登録(第一東京弁護士会)、桃尾・松尾・難波法律事務所入所。14年アメリカ合衆国カリフォルニア大学ロースクール卒業。14 年よりシンガポール共和国Colin Ng & Partners LLP勤務を経て、桃尾・松尾・難波法律事務所に復帰。基本情報技術者、ソフトウェア開発技術者、ITストラテジスト資格を保有。





ページトップ