まあ、とにかく、私の場合どこに行っても、まずはこの話から始めるんですが、IT開発プロジェクトにおける「ベンダのプロジェクト管理義務」って、ご存知でしょうか？
例えば、あるIT開発案件において、要件を凍結することで合意した後も、ユーザが次から次から新しい要件を追加してきたり、変更したりを辞めなかったとします。当然、プロジェクトは混乱して、スケジュールは遅れるは、コストはオーバするはで、ついにプロジェクトが破綻してしまった場合、さて、悪いのは要件追加変更を止めなかったベンダなんでしょうか？それとも、それを受け続けて、開発を完了できなかったベンダなんでしょうか？
実は、こうして破綻したプロジェクトの損害賠償を巡って訴訟になることもあって、というか、枚挙にいとまがなくて、裁判所では、これについてある程度統一した考えを整理しています。IBMとスルガ銀行の訴訟なんかも、そうした問題を孕んだ裁判でした。
で、こうした争いにおいて、裁判所の判決を見てみると、これはベンダ側が悪いとするものが多いわけです。
「えっ？要件凍結後もワガママ言って、プロジェクトを壊したのはユーザの方なんじゃないの？」そう考える方も多いですよね。きっと。私は講演なんかで、これを二択の問題にしてお客さんに答えてもらうんですが、やはり圧倒的にユーザが悪いとする人が多いんです。
何故か。裁判所には、ある統一した考え方があるように思います。つまり「餅は餅屋」という考え。つまり、ユーザがワガママを言ってプロジェクトを壊しても、ユーザ自身はITのプロで、自分のワガママがプロジェクトにどれだけの悪影響を及ぼしてしまうのかが分からない。そういうところはプロであるベンダの方が、コントロールしなければならないという考え方です。
具体的にベンダは、ユーザがワガママを言い始めたとき、どうすればよいのか。もちろんケースバイケースですが、次のような対応が求められるようです。
・要件の追加を断る。(そんなことやったらプロジェクトが壊れますという説明をする。)
・代替提案をする。(じゃあ代わりにこの要件を落としてくれとか、その要件の代わりになる別の提案をするとか。)
・スケジュールや費用の変更を見積もる
このようなことをするベンダの義務(権利ではない！) のことをプロジェクト管理義務と言って、これを怠ると、ベンダは債務不履行という不法行為に問われてしまいます。
相手はお客さんのことですから、なかなか言いにくいのも分かるのですが、やはり言うべきことを言わないと、結局、ベンダ側が多大な損失を被ることになるので、ここはひとつ、勇気をもって頑張っていただきたいところです。
コメントを残す