取扱業務

ネットワーク敷設に関する調停で顧問弁護士の代理人をサポートした、セカンドオピニオンの事例です。

 事案  　放送事業者であるＡ社は、放送現場でのネットワーク敷設を元グループ会社のＢ社に依頼していました。今回は、大規模イベントの放送現場でしたが、急な計画変更が原因で放送スケジュールにまで影響する遅延を来してしまいました。その事後処理のため、互いに顧問弁護士が間に立ち、（元グループ会社であることもあって）「是々非々」による交渉が進められました。ただ、損害額が大きかったため、中立の「ジャッジ」を入れるという意味で、間もなく裁判所の調停に場を移しました。このような中、Ａ社の顧問弁護士はこれまでシステム紛争の経験がなく、調停での審理のベースとなる技術論でＢ社の主張に十分に対抗できないのではないかという不安を抱えていました。そこで、ＩＴＳにセカンドオピニオンとしての支援を求めました。

 解決 　調停では、前提となるネットワーク要件と作業結果、現場での双方の作業及び管理などについて争点表が作成され、おおよその責任関係をはっきりさせてから、負担関係を協議するという手順で進められていました。ＩＴＳは最初に、争点のうちネットワークやプロジェクトマネジメントに係わる部分について、Ａ社から資料の提供を受けて責任に結び付く事象を抽出・分析し、審理での主張のベースになるレポートを作成しました。調停は８か月ほどかかりましたが、ＩＴＳはその間継続してＡ社の代理人をサポートし、Ｂ社からの主張の評価や、対抗案の作成などを行いました。その結果、当初希望した満額には及ばなかったものの、その８割ほどの補償を得ることができました。

 ポイント 　以前はグループ関係にあり、現在も相当な取引関係が残っていたことから、双方の了解済みで調停に移ったという、かなり珍しい事案です。そのため、調停に場を移してからも、裁判所外での交渉からの引き続きで、事実を解きほぐし、原因を明らかにするような形で行われました。その意味で、補償額が幾らになるかという結論だけでなく、内容的な話し合いの過程に重点が置かれていたと言えます。そのような中では、事案の振り返りとして、真摯な技術的分析・検討が重要になります。このような課題に対処するため、Ｂ社側では、代理人のほか親会社の技術者や外部のコンサルが関与していたようでしたが、ＩＴＳはＡ社側でＡ社担当者と共にその立場に立ったわけです。

ＩＴ訴訟の弁護団に加わり、ＩＴ技術者と共同でプログラム・ロジックに関する技術立証を行った事例です。

 事案  　総合ＩＴ商社であったＡ社は、自社ポイントの発行、他社ポイントとの交換サービスの運営、電子マネーやゲーム内通貨の取扱いなどを足掛かりに、クレジットカードや仮想通貨とも連携するフィンテック・サービスへの進出を企画していました。そのような中、電子マネー交換システムのダウンが原因で、交換手続中であった電子マネーが全て消失するという事故が発生しました。消失した電子マネーは総額で３億円程度と見積もられましたが、直ちにその全額を賠償する方針を利用者に示しました。ところが、システムの不備で対象金額に関する確実な記録が存在しなかったことから、利用者から疑念の声が上がり、大口の利用者から提訴されてしまいました。訴訟自体は、敗訴額の上限がおおむね想定できるものであったため、当初は粛々と進んでいましたが、訴訟の追行中に別の重大な問題が生じたため、ＩＴＳが弁護団の一員に加わることになりました。

 解決 　重大な問題とは、訴訟の中で証拠として提出した交換残高把握のためのプログラム・モジュールに、不正ロジックが組み込まれているのではないかと疑われたことです。相手方は、これを交換残高を意図的に縮小するための詐欺ロジックであると攻撃し、請求額を大幅に拡張したうえ外部の報道にも流しました。このような主張が認められてしまうと、高額の敗訴金を負担するばかりでなく、フィンテック事業者としての信用が著しく傷つけられ、将来のサービス拡張に大きな支障が生てしまいます。そこでＩＴＳは、弁護団の一員として訴訟の進行に携わると同時に、ＩＴ技術者と共同で不正ロジックが存在しないことの立証活動に取り組みました。結果、例外的な条件でロジックに不具合のあることは判明したものの、開発資料との突合により意図的なものではなくバグに過ぎないものであることを立証できました。その過程で、ほぼ正確な交換残高を算出する方法も見つかり、当初見積り程度の敗訴額で訴訟を終えることができました。

 ポイント 　それなりのビジネスを展開していれば、何がしかのトラブルに見舞われるのは避けがたいことです。これが請求する側に立つ場合であれば、十分な立証手段があるかどうかを判断したうえで事を起こすことができますが、請求される側に立つ場合は、否応なしに訴訟等に巻き込まれてしまいます。降りかかる火の粉は振り払わなければならないわけですが、訴訟となれば、（たとえ不当な請求であっても）立証手段を欠くとそれも叶いません。本事案では、ＩＴＳは弁護団の一員として、通常の訴訟追行を担当するメンバーと立証の鍵を握るＩＴ技術者の連節点として機能したわけですが、何より、（相当の解読作業を要したとはいえ）開発当時の資料を掘り出したことが訴訟の重大なターニングポイントとなりました。ＩＴ系の事業者には、往々にして記録化やドキュメント化の意識に欠ける傾向が見られますが、事業の拡大に伴い意識の変革が望まれるところです。

紛争化しつつある開発プロジェクトの立直しのために、開発工程管理支援を行った事例です。

 事案  　中堅商社であるＡ社は、３年後の上場をにらんで、基幹系システムの再構築をシステムベンダのＢ社に委託しました。しかし、外部設計の途中で、機能の漏れや齟齬が多数見つかりました。Ａ社はクレームを出したところ、逆にＢ社から、漏れや齟齬が出たのはＡ社が要件定義を無視した要望を多数出したからで、このままでは８５００万円の開発費用を２億円にしないと作業を継続できない、という通知を受けました。両社は何度か互いの意見をぶつけ合いましたが、結局、交渉は平行線のまま、開発は事実上中断となりました。Ａ社は、Ｂ社の対応に不満を持ったものの、要件定義までは満足のいく形で終わっており、また、この段階でベンダを代えて一から開発をやり直していては、上場準備に間に合わないため、開発再開を前提とする工程管理をＩＴＳに依頼しました。

 解決 　ＩＴＳは、Ａ社のメンバーと共にＢ社との交渉に臨み、共同検証による開発内容・規模の検証を提案しました。これに応じたＢ社から要件定義との差異の明細を提示してもらい、実務ベースの検証作業を経て、機能の追加・変更、工数評価の差異、当初の見積漏れに切り分け、双方合意しました。そして、最終的に、一部機能の将来フェーズへの先送りを前提に、見直し後の総開発費を９０００万円として開発を再開しました。また、検証作業の中で、Ａ社側には協力体制の薄さ、Ｂ社側にも今回初めて用いる開発手法のリスクなど、なお解消されないトラブルの種があることが判明したため、再開後も、リリースまでＩＴＳが継続的にプロジェクトに加わり、プロジェクト管理を支援しました。

 ポイント 　ユーザから見ればベンダ側の要求仕様の誤解・無理解、ベンダから見ればユーザ側の要求仕様の混乱・変節、というのは典型的なトラブル状態の構図です。そして、これは品質の低下と共に、開発費用の上ブレという形で現れ、調整の限度を超えると、本件のような開発中断にまで至ります。上ブレの原因は、ベンダ側では見積の甘さ、ユーザ側では過度な機能の要求、といったことも挙げられますが、その根本には、要件定義レベルで合意したはずのシステムの範囲・内容についての、ユーザの理解とベンダの理解との間の大きなギャップがあります。本来は、プロジェクト内のコミュニケーションによりそのギャップの発生を抑え、あるいは埋めるべきですが、本件では、共同検証によってようやくそれが実現されたわけです。

紛争とは無関係に、新サービスの立上げプロジェクト対してコンサルティング的な開発工程管理支援を行った事例です。

 事案  　医療系出版社であるＡ社は、ポータル系サイトの構築・運用で実績のあるベンダＢ社と組んで、医療・健康の情報提供サービスの共同開発、運用へと乗り出しました。共同開発は大きなトラブルもなく進んでいましたが、サービスの中核である個人向け健康相談サイトに本格的に取り組み始めたころから、医療・健康情報の取扱い、これに対応するシステム実装について問題が生じてきました。サービスで取扱う情報の一部が要配慮情報や匿名加工情報に当たり得ること、関連会社との役割分担のための情報授受が個人情報の第三者提供に当たり得ること、それらを含めた情報管理を担うシステム実装が安全管理ガイドラインの水準に達しておらず、仕様レベルからの見直しを要するものであること、などが判明したのです。そこで、開発を一時中断してこれらの問題を検討するため、ＩＴＳに依頼しました。

 解決 　ＩＴＳはまず、個人情報の取扱いの法的側面について、一般的なデータマッピング図を作成しながら、情報の取得、保管、提供といったアクションごとに、情報の性質、法的な位置付け、必要な管理行為を整理しました。これにより、サービスの全体構造において関連会社や協力スタッフを含めて役割の過度の細分化がなされていたため、サービスのライフサイクルの中で情報が複雑に行き来し、第三者提供に伴う記録などの負担が無用に増えていることが分かりました。そこでＩＴＳは、関連会社間の役割の見直しにまで踏み込んで、情報の流れを簡素化するとともに、ログ取得の自動化や情報のアクセス制限など、運用を軽量化するための方策を提案しました。また、実装との関係では、安全管理ガイドラインへの対応と併せて、新規方策の実装に向けた仕様の見直し、プロジェクト管理の支援も行いました。

 ポイント 　新ビジネスを企画する場合、フィージビリティ・スタディの一環として適法性や規制対応の検討を行うことは常識と言えますが、企画段階だけで終わってしまい、実装段階で十分な考慮が払われないことが少なくありません。例えば、新サービスと資金決済法との関係はどうか、サービス内の取引が「賭博」に当たらないか、といった大きなレベルでは検討がなされるのですが、そこで検討が途切れてしまいます。情報系であれば本事案のような個人情報の取扱い、取引系であれば消費者法制への対応など、実務レベルでの具体的な問題も軽視できません。厄介なのは、こうした法的要件がシステム実装のレベルにまで入り込んでくることです。これらは、サービス主体にもシステムベンダにも十分な経験がなく、盲点になりやすいため、注意が必要なところです。

得意先との契約締結を機会に、ＩＴ関連の契約書類のひな形一式を整備した事例です。

 事案  　Ａ社は、独立系のシステムベンダで、従来はインフラ系中心で業績を伸ばしていましたが、ここ１～２年はアプリケーション開発にも力を入れる方針で来ています。しかし、経験の薄さもあって、不明確なＲＦＰがあるだけでの一括請負や、正式契約前の作業着手などの問題が毎回のように起こり、赤字プロジェクトを生んでいました。今回の案件は、得意先からの継続案件でしたが、従来からの「なあなあ」の関係が災いして、また同じことの繰り返しとなる危険がありました。そこで、これを機に、これまでの形ばかりの契約書に代えて、適正な契約プロセス、管理プロセスが組み込まれた契約書類・ドキュメントのひな型を整備するべく、ＩＴＳに依頼しました。

 解決 　まず、Ａ社の状況をベースに、今後最も受注の可能性が高い契約類型を整理してパタン化しました。そして、大きく受注型と再委託型に分けた上、それぞれについて開発契約書、保守契約書、ＡＳＰ契約書のひな型とその解説マニュアルを作成し、法務担当者とプロマネ担当者に対してセッションを行うところまでを１セットとした、「ＩＴ契約書コンサルティング」を実施しました。契約書本体では、再見積を前提とした多段階契約を採用すること、顧客との元請契約と再委託先との下請契約の条件の違いから生じるリスクをなくすこと、マニュアルでは、相手先から良く出る変更要求に対する対処と要求を受け入れる場合の変更案を示すこと、影響を受ける変更箇所が容易に分かるようにすることに留意しました。

 ポイント 　契約書に対するリーガルチェックが不十分なままであると、認識もしていない大きなリスクを背負い込むことがあります。損害賠償や免責の条項など、１個の条項でも大きな違いを生むものがあります。大手のシステムベンダであっても、弁護士によるリーガルチェックを経ていないのか、このようなものが放置されているケースがままあります。契約条件の有利／不利を含めて、最終的にどこまでのリスクを取るかは、相手方との交渉次第という面もありますが、まずリスクを認識しないことには話が始まりません。また、ＩＴ系の契約の場合、契約書本体だけでなく、添付の仕様書や契約書の前段階の見積書、提案書（ユーザの場合なら、ＲＦＰ）から注意が必要となります。

smart_displayシステム開発委託基本契約書のリーガルチェック例