法的リスクから見たＩＴプロジェクト推進上の注意点

 

雪化粧の山口瑠璃光寺　五重の塔

近年，民法改正をはじめ，ユーザ保護の観点からＩＴ開発ベンダーの法的リスクが高まっています。

私は４０年間に亘り，ＩＴ開発プロジェクトにユーザ側・ベンダー側の両面から携わってきました。

今回，その体験を基にＩＴプロジェクト開発が訴訟に至らないためにはどうしたらいいか，ユーザとＩＴベンダー企業が考慮すべき注意点を取り纏めましたのでご紹介します。

  １．ＩＴ訴訟の動向

ＩＴ訴訟が非常に増えている。その原因は，パッケージソフトの導入増加やユーザ企業のＩＴ構築能力の低下などがその一因と考えられます。

また，ＩＴ訴訟の帰責判断基準が裁判所により明確になったことが大きく影響しています。

ＩＴプロジェクト推進時の帰責判断基準には二つの義務があります。

☆ひとつはプロジェクトマネジメント義務（ベンダー側）です。

ＩＴベンダーは，「進捗状況を管理し，開発作業を阻害する要因の発見に努め，適切に対処する義務」および「注文者であるユーザのシステム開発への関わりも適切に管理し，専門知識を有しないユーザによって開発作業を阻害されることのないようユーザに働きかける義務を負う」（以下，ＰＭ義務という）を有します。

これにより，仮に回避し得ない問題が発生した場合にはプロジェクトの中止をも提言する義務が発生します。

☆もうひとつはプロジェクト協力義務（ユーザ側）です。

ユーザは協力義務として，「適時に仕様の決定等を行うとともに，資料等の提供など必要な協力を行う義務を負う」ということです。

日本の裁判は過去の判例を重視する傾向があります。ＳＥとしてもＩＴ訴訟の動向を把握しておくことが望ましいです。

  ２．ＩＴプロジェクト推進時の帰責判断の訴訟例を以下に示します。

事　件	内　容			判決内容
Ｈ16年3月10日 判決_東京地裁	プロジェクト失敗の原因がＩＴベンダー側にあるとして，某保険組合が訴えた際，保険組合側が訴状にＰＭ義務という言葉を使った裁判			双方に過失を認めた。
Ｈ24年3月29日 判決_東京地裁	ＩＴベンダ－某銀行（地裁）　プロジェクト失敗の帰責理由がＩＴベンダーにあるとして，某銀行が支払った金額の返還を求めた裁判			ＰＭ義務違反がＩＴベンダー側にあったとして，ＩＴベンダーに支払済費用について約74億円の支払を命じた。
Ｈ25年9月26日 判決_東京地裁	ＩＴベンダ－某銀行（高裁）　地裁判決を不服として，ＩＴベンダーが控訴した裁判			両社が交わした最終合意後に，ＰＭ義務違反があるとして，支払額を約４２億円に減額した。
Ｈ28年9月28日 判決_東京地裁	海外ＥＲＰパッケージ導入が失敗したのは導入ベンダーの債務不履行にあるとして，契約上賠償限度額18億円（実質40億円）の支払を求めた裁判			失敗の主因がユーザにあるとの認識を示しつつも，ベンダーに３割（5億円）の支払を命じた。
Ｈ29年8月31日 判決_札幌高裁	某医大－某通信会社（高裁）　病院システム導入失敗はＩＴベンダー責任として契約解除したため，ＩＴベンダーが損害賠償請求した裁判			ＩＴベンダー過失８割とした一審判決をユーザ過失１０割と逆転し，ユーザに１４億円の賠償命令。

これらの訴訟例をみると，ＩＴ開発プロジェクトが如何に難しく，プロジェクトが頓挫して訴訟に至っていることが分かります。

しかも債務不履行による損害賠償金額は億を超えるものばかりです。

日本のシステム開発は如何に生産性の低い仕事をしているかがよくわかります。

このようなことにならないためには一体どうすれば良いのでしょうか。

  ３．法的リスクから見たプロジェクト推進上の注意点

日本のＩＴベンダーはプロとして極めて厳しい立場にありますが，そのような中でも，お客さまに喜ばれるような高い品質のシステムを完成・納品することが第一義になります。

  （１）ＩＴ訴訟が起こる要因

最初に，何故，IT訴訟が起こってしまうのか，その根本要因を考えてみます。

これには，ユーザとＩＴベンダーとの成果物に対する思惑の違いが根本にあると考えられます。

この合意が最も重要な最初の前提条件になります。

　

①ＩＴ訴訟が起こる一番の原因は，ユーザ及びＩＴベンダー双方の完成物への思惑の違い。  （例：設計までは仲良くやっていても，次第に思いと現実（成果物）とのギャップが拡がり，最終的にユーザとＩＴベンダーとの意見対立が修復しがたい処に至る）

②ユーザ側は，ＲＦＰ（提案依頼書）に「出来ない事でも出来ればいい」という理想論的な要望を書く。（例：現行システム以上の操作性，レスポンス１秒以内）

③ＩＴベンダー側は案件を獲得したいから，曖昧な表現で入札を図る。 （例：ほぼ希望にお応えできますが，一部には対応をお願いすることもあります）

④ＩＴベンダーは「出来ない事は出来ない」或は「現状で分からない事は，どの時点で明らかにする」と返答していない。 （例：「基本設計でレスポンス目標を作成」,「詳細設計で仕様を最終合意する」）

⑤取決めを曖昧にしてプロジェクトを進めてしまうところに問題があり，日頃から発生した問題は，相互に調整する場を作るなど課題を明らかにして解決・推進する姿勢がない。

ＩＴ訴訟で一番問題になるのはレスポンスです。

そもそも，ＲＦＰ（提案依頼書）に1秒以内のレスポンスを要求するなど常識では考えられません。

スパコンや超高速ストレージを導入するのなら実現出来ますが，運用コストでペイしないのは明らかです。そういう提案条件に対して曖昧に入札するからＩＴ訴訟に発展するのです。

ＩＴベンダーは仕事が欲しいので，まあ最初の提案に対する回答だし，あとの設計時点で修正すればいいかと考えるのでしょうが，ＩＴ訴訟になった場合，裁判所は契約が準委任契約だとか，請負契約だとかは考慮しません。

全てにおいて裁判官の心象形成ですから，ＲＦＰであっても，その条件はプロジェクト全体での約束事項として見られますので，ＩＴベンダーは特に注意する必要があります。

  （２）プロジェクトを成功させるための留意点

それでは，最初の提案条件が妥当であった場合，その後のプロジェクトを成功させるには，ＩＴベンダーはどのような事に留意すべきなのでしょうか。

ＩＴベンダーはＩＴ開発の専門家であるため，プロジェクトを上手く進めるための考え方やスキルを身に着けているはずと考えられています。

一般的には，以下の事項を推進する能力が求められます。

①プロジェクト推進はＩＴベンダーの段取り次第である。企画・計画段階等の上位段階で開発方針を立て，十分リスクを検討準備する。 （設計手法，ツール，パッケージソフト，ハード，要員，開発支援体制（特に遠隔地），ＦＩＴ＆ＧＡＰ，開発期間，第三者的専門家の利用など）

②ユーザ側にも協力義務があるが，ユーザが必ずしも良い仕様を作れる訳ではない。基本的にベンダーの責任施工だというユーザも多い。良いユーザ案件の見極めと，如何に我儘なユーザをコントロールするかを考えなければならない。

③プロジェクトは最終のテスト段階で頓挫することが多い。最終段階で相互の意見に乖離が発生した場合，修復するのは極めて難しい。（手遅れである。） 従って，設計段階で品質を織り込むのが良く，ユーザとの合意が大切となる。仕様凍結も検討すべきである。ユーザ・ベンダー相互によく報告・相談することが求められる。

④基本的にはＩＴベンダーのスキルを高めなければならない。特にレスポンスで揉めることが多いので十分注意する必要がある。

私の経験上，これらのことがちゃんと出来ている人が担当するプロジェクトはほぼ完結できます。

プロジェクトの推進者（アーキテクト）は，上記の基本的な考えのもと，いろいろな仕組みや仕掛けを作っていくのです。（出来る人は本当に少ないけど。）

   （３）ＩＴ訴訟を考慮したプロジェクト推進上の注意点

そうは言っても，お客さまとの関係は良好であっても，プロジェクトはいつ破綻するか分かりません。

そのため，万一訴訟になった場合に備えて，リスク対応策をあらかじめ講じておくことも大切です。

以下に，ＩＴ訴訟を考慮したプロジェクト推進上の注意点を示します。

【基本的認識事項】 ■ＩＴベンダーはプロである。ＰＭ義務はプロジェクト全体で責任追及される。 　（経産省モデル契約書のとおり分割契約し，検収を受けても合意にならない） ■契約自由の原則から契約書が最優先。制限条項を契約書に明記する。 　（合意条項や損害賠償責任の上限等） ■進捗会議では，ユーザに対しプロジェクト上のリスクをはっきり述べる。 　（日時と名前などをはっきり残す。メールも可（証憑行為）） ■仕様追加・変更は検討し，できるだけ柔軟に推進上問題ない範囲で努力する。 　（ＰＭ義務行使証憑）

【ＲＦＰ・企画計画段階】 ■提案依頼書（ＲＦＰ）は理想的要望だが，出来ない事は否定しておかないと合意になる。 　（例：レスポンス1秒以内，現行以上などの要望に注意） ■わからない事項は，どの段階で明らかにするかを明確化する。 　（例：非機能用件であるシステムレスポンスの目標値等） ■プロジェクト成功への段取りや受注条件・成功の見込みを十分検討する。 　（例：万一の支援体制，ＦＩＴ＆ＧＡＰ，ユーザの能力，第三者の協力等）

【基本（外部）設計段階】 ■仕事の流れ等を検討する段階なので準委任契約とすべきだが，プロジェクトの場合は完成責任となるので責任回避の法的効果は薄い。検収は合意とならないので，進捗会議等で合意を得られるよう努力する。 　（第一合意の可能性）

【詳細設計（内部）設計段階】 ■仕様を具体的にＤＢ構造などに落とし込むことになるので，性能への影響度が高い。そのため最終合意を得ることが望ましい。  　(最終合意（仕様凍結））   また，仕様を確認する意味で，ユーザの現場の意見聴取をお勧めする。

【プロジェクト設計・作成・単体テスト段階】 ■プログラム構築段階なので，バグの発生とユーザの干渉（仕様変更）が発生する。 バグと仕様変更・仕様追加は別扱いとし，各々別のファイルで管理する。 　（ユーザの身勝手な要求がバグでないことを立証するため）

【連結テスト・総合テスト段階】 ■具体的に生成物のイメージが見えてくるので，ユーザの干渉が激しくなる。仕様追加・変更が激しい場合は，設計段階の仕様合意を梃子に最小限の手直しでおさめる。 ■ 総合テスト段階で思惑の違いが表面化し，突然利害対立する事が多い。ユーザ側の力量を考慮して，プロジェクトの早い段階で働きかけることが大切である。

  （４）プロジェクト推進上，常日頃から心掛けておくこと

ＳＥには，プロジェクト推進スキルの他に心掛けておくべき事が数多くあります。

今回は，法的リスク面から一部をご紹介します。

　

■然るべき法務部門やＩＴ訴訟の専門家など，法的リスクを相談できる処を用意する。 　（ＩＴ訴訟においては契約書が優先されるため，法務精通者のアドバイスが有効）   ■定期的に法務研修を受講する。 　（「著作権法」「不正競争防止法」「景品表示法」「下請法」「労働派遣法」「独禁法」などに精通しておくことが大切。）

  （５）万一訴訟に発展した場合の注意点

万一，訴訟になった場合，知っておくべき基礎知識は以下のとおりです。

■訴訟は双方の過失割合を争う場ですが，勝者はおらず損失は必ず発生する。 ■ＩＴ訴訟は専門性が高いので，有能な弁護人を代理人に選定する。  ■ＩＴ訴訟は因果関係が複雑なため，弁論準備期間が長く，訴訟期間は1審（地裁）で2~3年程度，2審（高裁）で約１年程度かかる。 ■法定利率は旧民法で６％，改正民法で３％と高めで，判決金額に大きく影響する。  ■判決内容は公開されるため，信用棄損の恐れもある。 ■ＩＴ訴訟以外の解決手段として，ＡＤＲ（裁判外紛争解決手続）などもある。

  ４．まとめ

このように，法的リスクから見るとＩＴベンダーが置かれた現状は，極めて厳しいと言わざるを得ません。

このような中でも，ＩＴベンダーはプロジェクトを成功させるための技術やスキルを磨いて行かなければなりませんが，常に以下のことを念頭に取り組む姿勢が求められます。

■ＩＴベンダーは 　ユーザの信頼を獲得するため，技術・スキル・マネジメント力などを高める。 （第一義）

■ユーザ・ITベンダー相互に 　システム受託で，互いに信頼し価値を分かち合えるパートナーを開拓する。

■ITベンダーサービスは    システム受託では，高いパフォーマンス。（新技術や新サービスで価値を高める） 　それ以外の分野では，高価値を有する製品・サービスを開発する。

■加えてITベンダーは    ユーザが抱える問題を解決するため，人的ネットワーク，技術的ネットワークを広範囲に構築する。

長くなりましたが，以上です。

私は弁護士ではありませんので，法律専門家の意見が聞きたい場合は頼りになるIT専門の弁護士をお探しになることをお勧めします。

こういった専門的な訴訟は経験が必要ですから，大都市圏の大きな法律事務所でないとなかなか出会えないというのも事実です。

ITに関わる方たちの参考になれば幸いです。

（注意）情報の正確性を期してはいますが，実施される場合には自己責任でお願いします。