ＩＴコンサルタント出身の弁護士がＩＴ紛争を予防・解決します
開発工程管理支援は、要件定義からテスト・導入に至る情報システムの開発工程の全般にわたって（あるいは契約前の企画・提案、導入後の運用・保守も含めて）、ユーザ又はベンダの立場から工程管理をサポートします。例えば、次のような場合にご利用頂けます。
開発類型としては、新規開発、改良開発、パッケージ導入、開発手法としては、ウォーターフォール、スパイラル、プロトタイピング、アジャイル、開発体制としては、シングルベンダ、マルチベンダ、国内再委託やオフショアなど、多様な類型に対応しています。開発工程の一部だけ、プロジェクトが軌道に乗るまで、といった短期の応援も可能です。また、契約書やＲＦＰの他、実施計画書や仕様書などのドキュメント類の作成・リーガルチェックも承ります。
紛争化しつつある開発プロジェクトの立直しのために、開発工程管理支援を行った事例です。
事案 中堅商社であるＡ社は、３年後の上場をにらんで、基幹系システムの再構築をシステムベンダのＢ社に委託しました。しかし、外部設計の途中で、機能の漏れや齟齬が多数見つかりました。Ａ社はクレームを出したところ、逆にＢ社から、漏れや齟齬が出たのはＡ社が要件定義を無視した要望を多数出したからで、このままでは８５００万円の開発費用を２億円にしないと作業を継続できない、という通知を受けました。両社は何度か互いの意見をぶつけ合いましたが、結局、交渉は平行線のまま、開発は事実上中断となりました。Ａ社は、Ｂ社の対応に不満を持ったものの、要件定義までは満足のいく形で終わっており、また、この段階でベンダを代えて一から開発をやり直していては、上場準備に間に合わないため、開発再開を前提とする工程管理をＩＴＳに依頼しました。
解決 ＩＴＳは、Ａ社のメンバーと共にＢ社との交渉に臨み、共同検証による開発内容・規模の検証を提案しました。これに応じたＢ社から要件定義との差異の明細を提示してもらい、実務ベースの検証作業を経て、機能の追加・変更、工数評価の差異、当初の見積漏れに切り分け、双方合意しました。そして、最終的に、一部機能の将来フェーズへの先送りを前提に、見直し後の総開発費を９０００万円として開発を再開しました。また、検証作業の中で、Ａ社側には協力体制の薄さ、Ｂ社側にも今回初めて用いる開発手法のリスクなど、なお解消されないトラブルの種があることが判明したため、再開後も、リリースまでＩＴＳが継続的にプロジェクトに加わり、プロジェクト管理を支援しました。
ポイント ユーザから見ればベンダ側の要求仕様の誤解・無理解、ベンダから見ればユーザ側の要求仕様の混乱・変節、というのは典型的なトラブル状態の構図です。そして、これは品質の低下と共に、開発費用の上ブレという形で現れ、調整の限度を超えると、本件のような開発中断にまで至ります。上ブレの原因は、ベンダ側では見積の甘さ、ユーザ側では過度な機能の要求、といったことも挙げられますが、その根本には、要件定義レベルで合意したはずのシステムの範囲・内容についての、ユーザの理解とベンダの理解との間の大きなギャップがあります。本来は、プロジェクト内のコミュニケーションによりそのギャップの発生を抑え、あるいは埋めるべきですが、本件では、共同検証によってようやくそれが実現されたわけです。
紛争とは無関係に、新サービスの立上げプロジェクト対してコンサルティング的な開発工程管理支援を行った事例です。
事案 医療系出版社であるＡ社は、ポータル系サイトの構築・運用で実績のあるベンダＢ社と組んで、医療・健康の情報提供サービスの共同開発、運用へと乗り出しました。共同開発は大きなトラブルもなく進んでいましたが、サービスの中核である個人向け健康相談サイトに本格的に取り組み始めたころから、医療・健康情報の取扱い、これに対応するシステム実装について問題が生じてきました。サービスで取扱う情報の一部が要配慮情報や匿名加工情報に当たり得ること、関連会社との役割分担のための情報授受が個人情報の第三者提供に当たり得ること、それらを含めた情報管理を担うシステム実装が安全管理ガイドラインの水準に達しておらず、仕様レベルからの見直しを要するものであること、などが判明したのです。そこで、開発を一時中断してこれらの問題を検討するため、ＩＴＳに依頼しました。
解決 ＩＴＳはまず、個人情報の取扱いの法的側面について、一般的なデータマッピング図を作成しながら、情報の取得、保管、提供といったアクションごとに、情報の性質、法的な位置付け、必要な管理行為を整理しました。これにより、サービスの全体構造において関連会社や協力スタッフを含めて役割の過度の細分化がなされていたため、サービスのライフサイクルの中で情報が複雑に行き来し、第三者提供に伴う記録などの負担が無用に増えていることが分かりました。そこでＩＴＳは、関連会社間の役割の見直しにまで踏み込んで、情報の流れを簡素化するとともに、ログ取得の自動化や情報のアクセス制限など、運用を軽量化するための方策を提案しました。また、実装との関係では、安全管理ガイドラインへの対応と併せて、新規方策の実装に向けた仕様の見直し、プロジェクト管理の支援も行いました。
ポイント 新ビジネスを企画する場合、フィージビリティ・スタディの一環として適法性や規制対応の検討を行うことは常識と言えますが、企画段階だけで終わってしまい、実装段階で十分な考慮が払われないことが少なくありません。例えば、新サービスと資金決済法との関係はどうか、サービス内の取引が「賭博」に当たらないか、といった大きなレベルでは検討がなされるのですが、そこで検討が途切れてしまいます。情報系であれば本事案のような個人情報の取扱い、取引系であれば消費者法制への対応など、実務レベルでの具体的な問題も軽視できません。厄介なのは、こうした法的要件がシステム実装のレベルにまで入り込んでくることです。これらは、サービス主体にもシステムベンダにも十分な経験がなく、盲点になりやすいため、注意が必要なところです。
得意先との契約締結を機会に、ＩＴ関連の契約書類のひな形一式を整備した事例です。
事案 Ａ社は、独立系のシステムベンダで、従来はインフラ系中心で業績を伸ばしていましたが、ここ１～２年はアプリケーション開発にも力を入れる方針で来ています。しかし、経験の薄さもあって、不明確なＲＦＰがあるだけでの一括請負や、正式契約前の作業着手などの問題が毎回のように起こり、赤字プロジェクトを生んでいました。今回の案件は、得意先からの継続案件でしたが、従来からの「なあなあ」の関係が災いして、また同じことの繰り返しとなる危険がありました。そこで、これを機に、これまでの形ばかりの契約書に代えて、適正な契約プロセス、管理プロセスが組み込まれた契約書類・ドキュメントのひな型を整備するべく、ＩＴＳに依頼しました。
解決 まず、Ａ社の状況をベースに、今後最も受注の可能性が高い契約類型を整理してパタン化しました。そして、大きく受注型と再委託型に分けた上、それぞれについて開発契約書、保守契約書、ＡＳＰ契約書のひな型とその解説マニュアルを作成し、法務担当者とプロマネ担当者に対してセッションを行うところまでを１セットとした、「ＩＴ契約書コンサルティング」を実施しました。契約書本体では、再見積を前提とした多段階契約を採用すること、顧客との元請契約と再委託先との下請契約の条件の違いから生じるリスクをなくすこと、マニュアルでは、相手先から良く出る変更要求に対する対処と要求を受け入れる場合の変更案を示すこと、影響を受ける変更箇所が容易に分かるようにすることに留意しました。
ポイント 契約書に対するリーガルチェックが不十分なままであると、認識もしていない大きなリスクを背負い込むことがあります。損害賠償や免責の条項など、１個の条項でも大きな違いを生むものがあります。大手のシステムベンダであっても、弁護士によるリーガルチェックを経ていないのか、このようなものが放置されているケースがままあります。契約条件の有利／不利を含めて、最終的にどこまでのリスクを取るかは、相手方との交渉次第という面もありますが、まずリスクを認識しないことには話が始まりません。また、ＩＴ系の契約の場合、契約書本体だけでなく、添付の仕様書や契約書の前段階の見積書、提案書（ユーザの場合なら、ＲＦＰ）から注意が必要となります。