代金を支払わないからシステムを引き上げるなんて、どういう了見だ!

4

2020年09月30日 07:12  @IT

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

@IT

写真写真

●付き合っても良い客か悪い客か



【その他の画像】



 システム開発に限ったことではないが、顧客を選ぶことは大切である。



 競争の激しい中そうそうぜいたくを言ってはいられないが、「ハズレ」の顧客に当たってしまうと、開発に非協力的なことが原因で進捗(しんちょく)が遅延し、プロジェクトが破綻したり、ベンダーのメンバーが無理を重ねて体を壊したり、それが遠因となって経営が危うくなったりすることがあるのだ。そんな事例は、私も幾つも見てきた。



 しかし、最も「筋の悪い」のは、お金を払ってくれない顧客だ。受注したシステムは完成し、曲がりなりにも動いているのに、いろいろな理屈を付けては代金を払ってくれない。



 特にソフトウェアの場合、納品してもどこかに不具合が残る場合がほとんどだが、それを理由に全く支払いをしない顧客がいる。不具合の影響が小さく、業務に大きな影響を与えなくても、「債務不履行だ」と言って支払いを拒む。そんな顧客の数は決して少なくはない。



 だが、そうした顧客も最初から払わないつもりだったわけではなく、開発中に経営が危うくなるなどの事情で「払いたくても払えない」状態に陥り、態度を豹変させることが多い。



 ベンダーの、特に営業担当者は、商談中にその辺りを見抜かなければならない。なかなか困難な作業ではあるが、特に初めての顧客の場合は、さまざまな方向にアンテナを張り、顧客企業の様子を把握することが、契約の前提条件となるといってもいい。



 IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載。今回は、ベンダーがユーザーに見切りを付けるべきポイントなどを紹介しながら、プロジェクトの壊れていくさまを紹介する。人ごとと考えず、今後の注意喚起として読んでほしい。



●トップセールスの落とし穴



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



---



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



学習塾の経営などを行うユーザー企業の代表者が、インターネットを使ったPC勉強プログラムの作成、およびそのプログラムを学習塾に対して利用させるサービスを構想し、以前から面識のあったベンダーの代表者にその開発を依頼した。



ただし、開発に合意した時点では、システムの機能などについて具体的な構想がまだなかったため、費用の支払いについては、ベンダーの作業に応じて払うこととなった。請求は毎月の工数に基づいて行われ、翌月払いとすることが取り決められた。



---



 まず、この部分。お気付きの方もいらっしゃると思うが、トップの個人的な関係で成立した契約は意外と破綻することが多い。



 相手の会社の体質や経営状態などの調査が不十分で、後々お互いに苦労したり、プロジェクトに問題があっても、途中でやめたとは言ったりしにくいのが、トップセールス特有のリスクだ。



 今回の例はさらに、「とにかく開発する」ことだけ決めて、「何を」「幾らで」行うのかがしっかりと決まらないまま作業をスタートしたのも問題だった。技術的なリスク、コストや工数のリスクの算定を後回しにして、とにかく仕事だけ始めてしまうのだから、何かと不確定要素の多いソフトウェア開発においては危険この上ない。



 しかし、実際には、トップが簡単に話をつけ、何も見えないままプロジェクトがスタートする例はかなりある。その結果、裁判所にまで持ち込まれたトラブルプロジェクトを、私も幾つか知っている。トップセールスというのは、それだけでリスクの一つなのだ。



 仕事を受けるにしても、調べるべきは調べ、リスクが高いとみれば、仕事の範囲を狭めたり、何かあったときには仕事を打ち切る準備(契約書に解除条項を設けるなど)をしたりはできたかもしれない。



 最悪でも社長に対して危険であることを告げて、いざというときには損切覚悟で仕事を中断させてほしい旨は告げておくべきだった……。



●支払い遅延! 相次ぐ退職!



 次の不穏なポイントは、すぐにやってきた。しかしベンダーの対応は、このときにも緩かった。



---



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



ベンダーは、システムの初期リリース分を一応、完成させた。しかし、ユーザー企業はその代金を最初の数カ月こそ支払ったものの、数カ月後には支払わなくなった。ユーザー側の資金繰りが苦しいことが理由だった。



そこでユーザー企業とベンダーは、ユーザー企業の支払額を軽減させるため、支払期日を遅らせることを趣旨とした確認書を取り交わした。この間もユーザー企業はベンダーの制作したシステムを使い続けた。



---



 これまでに付き合いがあり、それなりに信頼のおける企業ならともかく、初めての、しかも中小企業を相手にする場合、支払いの延期は果たして妥当だっただろうか。今月払えないものが来月払える道理などなかったのではあるまいか。



 支払いがなされないことを機に契約の打ち切りを考える必要はあった、と私は思う。ユーザー企業はシステムを使ってサービスを開始している。それにもかかわらず支払いがないのは、そもそもビジネスモデルが成り立っていないということだ。このまま続けても、支払いを復活できる可能性は低い。



 しかもこの時期、ユーザー企業の講師でベンダーと会話をしていたと思われる人間が3人、ほぼ同時に辞めている。



 給料の遅配もあったらしい。それらを総合して考えれば、ここはやはり、損を覚悟でプロジェクトを中止すべきだった。「結果論だ」と言われるかもしれないが、そう決断をする材料は幾つもあった。これまで支払った費用を取り戻したいとの考えもあったかもしれないが、そこは損切りするのが、ベンダーの経営上、妥当な判断ではなかったか。



 しかしベンダーは取り交わした確認書を信じ、プログラムの提供を続けた……。



●ユーザー企業の居直り



 その結果が以下である。



---



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



しかし結局、ユーザー企業は確認書で約束した金額すら支払うことができなかった。このためベンダーは、プログラムの提供をいったん中止した。



ところが、これに対しユーザー企業代表者は、ベンダー代表者に電話をかけ、脅迫的な言辞を述べた(「なぜ、ソフトを止めるのか」「子どもたちの夢を壊すようなことはしないでほしい」「気を付けた方がいいよ」「どうなっても知らないよ」など)。このためベンダーは、代金の支払いがない中、やむを得ず本件プログラムの提供を続けた。



---



 ドラマのような話だが実話である。ベンダーはその後も数カ月間、プログラムの提供を続けた。その間、開発に関わるコストだけがかさみ、ベンダーも経営的に大きな打撃を受けた。



 ベンダーは数カ月後にようやくプログラムの提供を中止したが、もっと早い段階で決断ができたはずである。使った費用の回収をどうしても諦めきれなかったのか、脅しに屈したのか。いずれにしても賢明な判断とはいえない。



 このように脅迫まがいのことを言うユーザー企業は、さすがに珍しいかもしれない。しかし、経営的に逼迫(ひっぱく)してきたユーザー企業は、よく居直ったような発言をする。「ここでやめたら御社も丸損じゃないですか」「ウチはいつでもやめていいんだ」――こうしたせりふは、私もIT紛争の事例で何度か見聞きした。



 経験上、ユーザーからこんなせりふが出るときには、プロジェクトもユーザー企業の経営自体も、かなり逼迫している場合が多い。



 プロジェクトをとにかく完遂しなければ商売が立ちゆかなくなる。さりとてベンダーに支払うお金もない。ならば、とにかく最後までやってもらって、支払いは利益が出た後にしたい――そんな都合のいいことを考えるユーザーは、こうした居直りを見せる。もちろん、全てがそうではないが、このようないきさつで破綻していったプロジェクトやユーザー企業が複数あることも事実だ。



●ポイントは幾つもあった



 裁判所の判断はどうだったのだろうか。



---



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



原告は、仕事を完成させて被告に利用させている以上、本件確認書で確認された内容に基づき、被告に請負代金の支払いを求めることができるというべきである。



なお、被告は、原告が本件プログラムが停止したりすることがないよう、エンジンをメンテナンスすべき義務があり、原告の同義務の不履行をも主張するが、本件確認書の文言上、原告の請求する400万円は、本件プログラムの製作費であり、その後の提供に対する利用料とは無関係であることが明らかであるから、この主張も理由がない。



---



 判決はベンダーの勝利となり、ユーザーには費用の支払いが命じられた。



 しかし、本件はベンダーの受注活動にとっても課題を残すものであったことには変わりない。結果論となるが、ベンダーの現場は初動から間違えていた。



 非上場のユーザー企業だったので財務諸表を公表していなかったが、契約に当たり、財務諸表の開示を求めることはできたはずだ。ユーザー企業の業界内のウワサを拾ったり、他にシステムを納入した会社があれば、そこから情報を取ったりすることもできたはずだ。



 いきなりトップが仕事を持ってきた付き合いのない会社に対しては、それくらいのことをやった方が安全だ。財務諸表の提示を一方的に求めると失礼だったら、「新規のお取引としてお互いに交換しましょう」と言えば、自然に持っていける(筆者もやったことがある)。



 もし、その時点で相手が拒むようなら、付き合いはそれまでだということでいい。厳しいようだが、初めての相手が非上場企業で、その様子がよく分からないなら、それくらいの慎重さは必要だ。



 注意すべきは、ユーザー企業は最初から支払いを拒もうと思っていたわけではないということだ(そう考えていたなら、刑事事件になってしまう)。



 本件のユーザー企業も、新サービスが予定通り軌道に乗ってくれれば、支払いを続けるつもりだったのだろう。しかし、その見込みは甘かった。そして経営の苦しさからベンダーへの対応が変わった。



 無断で支払いを遅延し、確認書で相手の譲歩を引き出しても、その約束を守らない。揚げ句、脅しまがいの言葉でベンダーの作業中断を許さない。明らかに誠実さを欠く態度だ。念のために書いておくが、このユーザー企業は反社会団体と関係のある企業ではない。それがこのように変わってしまったのだ。



 社長が持ってきた案件だからといって安心してはいけない。むしろ、そうした案件だからこそ、初めての商売相手の身辺調査は慎重に行うべきだったし、プロジェクト開始後も相手の様子をよく見ておかなければならなかった。



 そして、一度でも費用の支払いがなければ、付き合いをやめるべきだっただろう。これまでに取引実績があるならば、相手を信用することもできるが、初めての相手をそこまで信用するのは危険だ。一度でも支払いが滞れば、契約を解除してプログラムの提供も打ち切る。できれば契約書に、そのことを記しておきたいし、議事録にも記録したい。途中で脅しのような態度をとるなら、それも当然に記録しておく。



 本件は、単にベンダーの運が悪かったと言って片付けるべきものではない。途中に幾つもあった注意ポイントを甘く見て、仕事を続けた対応は、問題が大きかったし、今後の教訓としても生かすべきと考える。そうでなければ、また別のユーザー企業と同じようなことが起きるかもしれない。



●細川義洋



政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる


このニュースに関するつぶやき

  • 仕様を決め、承認を取っても、あとで使い勝手が悪いと仕様変更を不具合として無償で直させる奴の多い事。営業は顧客の味方だし。そんなんだから利益が出ないんだよ。もうそんな顧客とは二度と仕事したくない。
    • イイネ!1
    • コメント 0件

つぶやき一覧へ(1件)

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

前日のランキングへ

ニュース設定