読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

IT訴訟 徹底解説を読んだ(続き)

Project Management

以前に書いた記事の続き。自発的罰ゲーム。以前に記事を書いてから、2編の連載記事が公開されたので引続き胸の痛みに耐えながら読んだ感想など。なお、残念ながらこういった訴訟に関わる経験はなし。

http://www.flickr.com/photos/83352053@N00/8584710263
photo by loker

ベンダーが確実に支払いを受けるためにすべきこと

前の記事ではこう書いたけれども、この「やるべきこと」について具体的に解説されている。以前にこう感想を書いたのだけど、だいたいあっているようだ。

これは納得、というか「検収書」なるものは所詮紙切れにしかすぎず、やることはやらないといけない、ということだ。
元ネタの訴訟を見ると、「不具合を認めると大変なことになるから、一切認めない」という初動が問題あったように見える。どちらかというと「費用措置は別途調整するが、まずは止血する」という動きをとればよいんじゃないかと思う。

  • 計画され、ベンダーが担当するとされていた工程を、全て完了していること
    • これは論点は内容な気がする。というか、これが出来ない状況がイメージできない。
  • 完成したシステムが業務に使用でき、導入の目的に照らして妥当であること
    • これは少しひっかけ問題のような気がする。導入の目的があいまいであった場合、ユーザが最後にゴネることができるからだ。
    • 最後にちゃぶだいを返されないためには、いろいろな段階で合意形成を行いつつ、しっかりと記録をとっておくことが大事。
  • 残存した不具合についてのベンダーの補修が確実であること
    • 保守の契約が合意できないなどの大人の事情があったとしても、発生した不具合に対してはタイムリーにリアクションを取る必要があるということ。

ちゃんと仕事をすれば訴訟に勝てるけれども、それだけじゃないでしょう、という話

今度はシステム完成後に、ユーザが作業内容について最終合意に至っていないという理由で「契約書で定めた委託範囲の作業を完遂していない」と主張するケースである。さすがにこれはベンダー有利な判断が下っている。しかし、これについてそれだけで良かったのかという点について問題提起する、という記事である。

裁判所の判断は確かにベンダー有利のものだった。ベンダーは、裁判で要求した費用の支払いを受けられた。しかし、これは本当にベンダーの勝利だったのだろうか。

このあたりは、書かれていることも含めてわりともやもやしている。

結局は、顧客との関係性をどのように構築し維持するのかという事になるのかもしれないけれども、すっきりしないなぁと思う今日この頃。