ホーム > mixiニュース > IT・インターネット > IT総合 > 繁忙期に打ち合わせを設定するなんて非常識じゃないですか!(IT訴訟解説)

繁忙期に打ち合わせを設定するなんて非常識じゃないですか!(IT訴訟解説)

0

2019年06月05日 07:02  @IT

  • チェックする
  • つぶやく
  • 日記を書く

@IT

写真写真

 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、私がこの連載を始めようと考えた動機ともいうべき、「ベンダーとユーザー双方の責任感の欠如が招いた紛争」を取り上げる。



【その他の画像】



 システム開発はベンダーとユーザーの協業であり、双方にはそれぞれ果たさなければならない義務がある。



 ベンダーには「プロジェクトを円滑に進めて、約束した納期までに提示された要件を満たすシステムを稼働させる」という「プロジェクト管理義務」がある。この義務の中には、「ユーザーの行動や態度がプロジェクトに対して悪影響を及ぼすと思われるときには、それを説明し、是正する義務」も含まれる。



 ユーザーには「開発に必要な情報をベンダーに提供したり、必要な時期までに必要な判断をしたり、社内の意見を集約したり、これをベンダーに伝えたり」する「協力義務」がある。



 今回取り上げる紛争は、ベンダーとユーザー双方の「責任」とその裏にある「心の甘さ」が如実に現れたものといえる。おのおのがどれくらい相手の立場に立ってモノを考え、行動しているのかを考えさせられる紛争でもあったので、多少古い判例ではあるが、あえて取り上げることとした。



 民法改正まで1年を切ったこの時期、システム開発の契約書を見直さなければならないベンダー、ユーザーは多いと思う。こうした分かりやすい判決などを参考に、双方の責任を明確に表現したものを作ってもらいたいと考える。



●ベンダーとユーザーが「共に」義務を果たさなかった事例



 事件の概要から見ていこう。



---



東京地方裁判所 平成9年9月24日判決から



平成2年12月、あるシステム開発ベンダー(以下、ベンダー)と図書教材販売会社(以下、ユーザー企業)が入金照合処理のシステムを売り渡す契約を結んだ。納期は平成3年3月とされた。



しかしベンダーは平成3年3月までにユーザー企業とプログラム開発の打ち合わせをせず、当初スケジュールを変えて平成3年4月に打ち合わせを行い6月末までに開発する旨の提案をしたが、ユーザー企業はこれを拒絶した。



---



 結果として、納品は8月末までずれ込んでしまった。遅延の原因は幾つかあるが、4月に打ち合わせを行えなかったことも大きな原因だった。



 ベンダーが提案したスケジュールを、なぜユーザー企業は受け入れなかったのだろうか。3月までの遅延は仕方ないにしても、なぜ次善の策として提案された4月の打ち合わせをユーザー企業は断ったのだろうか。



●債務不履行vs.非協力的態度



 ここで、ユーザー企業の業種に注目してほしい。教材販売会社は4月が繁忙期である。



 「本業の忙しい中、システムに関する打ち合わせになど出ていられない」というのが本音だ。だからこそ当初スケジュールでは「3月をベンダーの開発期間に充て、同月末にリリースしてもらおう」という考えだった。



 「3月の納期が守れず、自分達の都合も考慮してくれずに4月に打ち合わせを入れたスケジュールを提示し、最終的にはそれすら守れず納期が8月まで遅れたのは、ベンダーの債務不履行だ」とするユーザー企業。



 それに対し、「4月の打ち合わせを実施しないというユーザー企業の非協力的な態度こそが大幅な遅延につながった」とするベンダー。



 少し補足すると、裁判所の判断は「ベンダーが3月の納期を守れなかったこと」については論点としていない。その理由は定かではないが、双方にそれなりに責任があってのことと判断したと推察される。



 問題は、ベンダーがユーザー企業と合意のないまま4月以降も作業を続け、にもかかわらず、6月の納期すら守れなかった点だ。



 判決の続きを見てみよう。



---



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



おもうに、ベンダーはコンピュータ関係の専門企業として顧客であるユーザー企業から提供された資料および聴取などの結果に基づき、本件システムの導入目的に適合したプログラムを作成すべき信義則上の義務を負担するものといえる。



ところが(中略)4月が教材会社であるユーザー企業にとって最も多忙な時期であるため、プログラム作成のための打ち合わせをそれまでに終了させておくべき必要性があったにもかかわらず、これを行わなかったベンダーには非があるものといえる。



---



 裁判所はベンダーの身勝手なスケジュール設定に苦言を呈している。



 ここで注目したいのは、「専門家であるベンダーはユーザー企業の業種、業態などを考慮して、スケジュールなどを策定する義務がある」という点だ。



 示された要件に従ってただモノを作ればよいのではなく、「プロジェクトを成功させる」という管理義務を全うするためには、ユーザー側の事情もよく考慮して、プロジェクト計画を立てたり見直したりすべきであり、ユーザーの繁忙期に打ち合わせを設定することは、そうしたプロジェクト管理義務を果たしてはいないという判断をしている。



 平たく言えば、ベンダーの身勝手で自己中心的な考えが紛争の一因となっていると述べている。



 では、ユーザー企業の責任はどうなのか。



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



---



東京地方裁判所 平成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補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる


    あなたにおすすめ

    ランキングIT・インターネット

    前日のランキングへ

    ニュース設定