連載
» 2019年06月03日 05時00分 公開

繁忙期に打ち合わせを設定するなんて非常識じゃないですか!「訴えてやる!」の前に読む IT訴訟 徹底解説(66)(3/3 ページ)

[ITプロセスコンサルタント 細川義洋,@IT]
前のページへ 1|2|3       

ユーザー企業は「協力義務」を果たしたのか

東京地方裁判所 平成9年9月24日判決から(つづき)

しかしながら、(中略)ユーザー企業も1つの企業体として事業を行い、その事業のために本件システムを導入する以上、自らも、積極的にベンダーとの打ち合わせに応じ、(中略)ベンダーに協力すべき信義則上の義務を負担しているものといえる。

 情報の後出しで申し訳ないが、実はユーザー企業は、「翌年にシステムの切り替えを行う」ことを経営方針として決めていた。そのため、本件システムの開発は一刻の猶予もない状態であり、「4月は忙しいから打ち合わせなどできない」とベンダーの要求をはねつけるのは、あまりに非協力的であった。

 自分たちの経営方針を守るためには「ベンダーの協力要請に応え、何とかして4月の打ち合わせに出席する」か、そうでないならば「明確なスケジュールの変更をすべき」ところを、そのどちらもしないでベンダーにばかり責任を押し付けるのはどうなのか、これはユーザーの協力義務違反ではないか、と裁判所はいっている。

 結果、裁判所はベンダーの費用請求を全て認容した。

 どちらにも非はあるが、「ユーザーが協力しなかったことが、納期の大幅な延長につながった」のであり、「ベンダーのある意味身勝手な要求は、遅延自体の原因とはならない」という判断だ。

 考えてみれば当然のことで、ベンダーは遅れていくスケジュールに対処するために「何とか4月に打ち合わせを」と頼んでいたにすぎない。その態度に問題はあるものの、それが遅延の原因になったわけではない。

ユーザー企業の関わりを管理する会議体計画

 裁判では「ベンダー有利」の判決が出た。しかし、判決文の中にもある通り、ベンダーにも反省すべき点はある。@ITの読者はベンダー側の方が多いと思うので、あえて「こうした状況においてベンダーは何をすべき」か、私なりの考えを補足しておきたい。

 まず、ユーザーが会議に出てくれないときは、その危険性を説明して出席を要望しなければならないのは当然である。そして、それでもユーザーの協力が得られないようなら、プロジェクトのスケジュールなど、計画の見直しをすべきである。

 ここでベンダーの、特にプロジェクトマネジャーに考えていただきたいのは、プロジェクトの「会議体計画」だ。

 会議体計画はプロジェクト計画の一部分で、プロジェクトで実施されるユーザーとベンダーの会議について計画を記すものだ。私の見る限り、会議体計画をきちんと書けているプロジェクトは少ない。

 多くの場合ここに記載されるのは、「キックオフミーティング」「要件凍結会議」「工程完了会議」など定型的なものと週次で行う「定例報告会」、後は「随時」といった具合だ。しかし、これでは不足している。

 要件ならば、凍結時だけでなく、各機能についてさまざまな論点があるし、システムの実現方式についても合意が必要だ。ユーザーからの情報提供や判断をしてもらいたい部分、ユーザーテストの方法など、ユーザーとベンダーが解決し、合意しなければならないことはたくさんある。これらはプロジェクト計画初期のスケジュールやWBSを作る時点で、ある程度分かっているはずである。

 ならば会議体計画は、「それらについて話し合う時期」「アジェンダ」「ゴール」「出席者」を具体的に書いておかなければならない。

 「最初の段階でそんな細かいことまでは分からない」と思う読者がいるかもしれないが、それは考えが足りないし、浅い。本当にプロジェクトの推移を真剣に検討すれば、かなりの精度でこれらの会議を想定できるはずである。

 これらの会議で、「ユーザーが決定すべきことを決めない」「出席すべき人間(欠席の場合は代理権限者でもいい)が出てこない」などがあれば、それは即「プロジェクト計画を見直すべきリスク、あるいは課題」になることを、最初の段階で、ユーザーと合意しておくべきだ。

 こうして作った会議体計画は、それを見ているだけでシステムが出来上がっていく様を想像できて、逆にリスクも想定できるものになる。多少面倒な作業にはなるが、プロジェクト計画策定時点で、ユーザーと相談しながら取り組んでいただきたい。

 今回取り上げた事件であれば、プロジェクトスタート時点で会議体計画を立て、3月のリリースが難しいとなった時点で見直す、4月にユーザー会議に参加できないと分かった時点でそれをどうするか話し合う、などができたはずだし、それらをやっておけば、そもそも裁判になるような事件でもなかったと考えられる。

細川義洋

細川義洋

政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる

書籍紹介

本連載が書籍になりました!

成功するシステム開発は裁判に学べ!契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

成功するシステム開発は裁判に学べ!〜契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

細川義洋著 技術評論社 2138円(税込み)

本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。


システムを「外注」するときに読む本

細川義洋著 ダイヤモンド社 2138円(税込み)

システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。


プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿

細川義洋著 技術評論社 1814円(税込み)

紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?


「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

細川義洋著 日本実業出版社 2160円(税込み)

提案見積もり、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。


なぜ、システム開発は必ずモメるのか?

細川義洋著 日本実業出版社 2160円(税込み)

約7割が失敗するといわれるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。