見出し画像

「システム開発でトラブル発生⁉」は事前の対策で防げる！

波戸岡光太

こんにちは。弁護士・ビジネスコーチの波戸岡光太です。

IT化が進むにつれ、システム開発を受託したIT企業の方からの相談が増えています。

システム開発に関する法律トラブルでは、クライアントが望むレベルに達していないとか、システムの完成度が低いという理由で、代金の支払いを拒絶されるケースが多いのが特徴です。

今回は、システム開発をめぐる法律トラブルのよくあるケースと、トラブルを回避するための事前防止策を解説します。

システム開発でトラブルが発生する理由

システム開発は、建築に例えられることがよくあります。

実際のところ、設計して建築して完成引き渡しという一連の流れは、システム開発と大変よく似ています。

しかし、①作りながら仕様や設計を検討していくパターンがあること（アジャイル型）、②完成引渡しの線引きが難しいことの2点において、建築とは大きく異なり、それがトラブルの原因になりがちです。

完成形が分かりにくいアジャイル型の開発フロー

建築の場合は、最初に完成した設計図があり、設計図通りに建築します。トラブルが起きた場合、その設計図通りに建築したのかが問われます。

しかし、アジャイル型開発の場合、設計→開発→設計→開発…と双方がキャッチボールしながらゴールに向かっていくため、途中で仕様変更や追加機能が発生することも少なくありません。そのため、「そもそも契約当初に何を作ることになっていたのか」と問われても、答えにくい側面が出てきてしまいます。つまり、ゴールがどこなのかがスタート時には必ずしも明確になっていないのです。 

どこを「完成」とするかが難しい

システム開発では、一定の完成レベルに達してもある程度のバグが発生するのは織り込み済みで、完成後も作業が発生するのは通常とも言えます。

そのため、完成後の作業が、はたして完成してないからまだ作業しているのか、完成したけれどもその後の修正作業をしているのか、判断が難しいです。クライアントに専門知識がなければ尚更、どこが完成なのか分かりにくい側面があるのです。

よくあるシステム開発のトラブル事例

システム開発でのトラブル例を紹介しましょう。

■遅々として進捗しないことにクライアントが不満

システム開発がスタートしたものの、設計→開発→設計→開発…と進むアジャイル型では、開発に時間がかかることがあります。システム開発に疎いクライアントはそのことを理解できず、イライラしてしまいます。

■返事がもらえず納期がずれ込む

システム開発者の「どんな機能を備えてほしいか」「どんなデザインがいいか」といったヒアリングに対し、クライアントからレスポンスがなく、納期がずれ込んでしまうこともあり、クレームの原因になります。

■担当者と上層部との情報共有不足によるトラブル

担当者と上層部の連絡不足によるトラブルも少なくありません。

 例えば、クライアント担当者の合意のもと開発を進めてきたにもかかわらず、その現場の状況がクライアント上層部に伝わっておらず、いざ完成引渡しとなった時に、「思っていたのと違う」「完成が遅すぎる」などとクレームを言われ、一方的にシステム開発者が非を問われてしまうことも。

■修正対応が続く

どこまでやったら完成なのかが分からず、代金が支払われないまま延々と修正対応をせざるを得ない状況に陥ることもあります。また、どこまでが正規の料金に含まれる作業なのかが不明確で、追加料金が支払われないケースも見られます。

結果、赤字になっても開発から離れられず、同時に多くの難案件を抱え込んでしまうシステム開発会社が数多く出てきてしまう問題が起きています。

■代金の未払い

最終的には「希望したレベルでない」「納期が遅れた」などといった理由で代金を払ってもらえない事態に陥ることが多いのも、システム開発でのトラブルの特徴です。

事前の対策でシステム開発のトラブルを回避しよう

システム開発に関するトラブルは、事前に対策をとっておくことで、かなりの部分で回避することができます。その対策をお伝えしましょう。

対策1：担当者とのやりとりを記録しておく

 トラブルが発生した際、事実をきちんと伝えられるように、担当者との合意事項や確認事項、話した内容などを記録に残しておきましょう。

 通常作業の一環として記録を残していることはあると思いますが、ぜひ、トラブルが発生した際に有効な証拠となるようにということを意識して記録を残すようにしましょう。具体的には、以下のことに意識して記録を残しておくとよいです。

■何を依頼されたのか

デザインの確認や機能のチェックなど、依頼された内容を明確にしておきましょう。

■期限はいつまでなのか

必ず期限を決め、しかもその期限が現実的かどうか確認しておきます。

■繰り返しお願いした記録

クライアントからの返答がなく、ヒアリング事項などの返答を複数回催促した場合、「こちらは何度も催促していた」という記録を残しておきましょう。記録に残っていないと、後日会社間での話し合いになった際に不利になってしまいます。 

対策2：前金もしくは段階的な代金支払いの契約を結ぶ

契約締結段階で、予算や開発期間で区切っての前金システムを提案したり、実装フェーズを何段階かに設定して段階別に開発費を支払ってもらうよう取り決めておくことは、トラブルを回避する上で有効な対策です。

 受託する立場としては、なかなか切り出しづらいかもしれませんが、長期化するケースも多いシステム開発においては、すべてを出来高払いにするのはリスクが大きいと言えます。

対策3：システム完成の定義を明確にしておく

いつまでも修正が続き、赤字になる、手離れできないなどを防ぐためには、予め提出しておく仕様書に実装する機能一覧を明記し、システム完成の定義を明確化しておくことが有効です。

 アジャイル型ではどこまで盛り込めるかという課題もありますが、それでも可能な限り仕様を洗い出しておくことで、後にトラブルが起きそうになったときに優位に立つことが可能です。

論理的な開発者と情緒的な発注者

システム開発に限らず、WEBサイト制作のときにもあるのですが、受注するIT企業と発注者との間にトラブルが発生する原因として、実は双方の認識の違いだったり、イメージしていたものが相違だったというケースも多いです。

というのも、クライアント側は、いわばイメージ先行で、抽象的・情緒的な世界観で案件を発注しがちですが、システム開発側はそれを具体的・理論的な実装へと落とし込まなくてはなりません。そこに思考のギャップや溝が生じるリスクがあるのです。

例えば、システムの機能について発注者は「使いやすくて素敵なシステムが作りたい」といったようなイメージから入る人が多く見られます。ですが、システム開発側は限りある予算内で具体的な機能に落とし込むため、何かを捨てさせる作業も必要となってきます。いわばクライアントに“夢から醒めてもらう”という説得が必要となるのです。

それがなされないまま、あるいはできないまま進めてしまうと、なかなかクライアントの承認が取れず、工期も延び延びになってしまい、そうしたコミュニケーション不足がそのままトラブルへと発展するのです。

 先日、こんなエピソードがありました。

システム開発で揉めに揉めて訴訟に発展したケースでしたが、現実の開発状況を検証しようということで、法廷で画面を共有しながらシステムを操作し、互いに意見を主張する機会がありました。

クライアント：こうしてほしかったんですよ。それなのに…

システム開発者：え、そうだったんですか？ それなら、こうすればできますよ

同じようなやり取りが何度も続き、そのたびにクライアントの疑問は解消。双方の溝が埋まっていき、やがて法廷は会議のようになってしまい、結局システム開発が再開しました。

このように、多くの場合はコミュニケーション不足で、クライアントの望むものとシステム開発者が実現可能なこととのすり合わせができていなかっただけ、というケースも多いのです。 

まとめ

システム開発でトラブルにならないため、開発費が回収できない状況に陥らないためにも、事前に対策を講じておきましょう。ぜひ、紹介した対策を実行していただければと思います。

また、クライアントの情緒的な希望を具現化するために、十分にコミュニケーションを取ることも必要です。

私が顧問をさせていただいている企業には、トラブルになる前 のタイミングでご相談いただくようにしています。早い段階からどんな情報を取っておけばよいかというアドバイスや、クライアント担当者のタイプに応じたかかわり方など交渉学の見地からもアドバイスを行っています。プロジェクト担当者の方にも直接アドバイスし、現場の方の不安を無くす役割も担えたらと思っています。

受託案件を複数抱え、売掛け金の回収に不安を感じていらっしゃる企業の方は、ぜひご相談ください。業務委託契約書に見直しや、前金のルール設定などアドバイスさせていただきます。

 https://hatooka.jp//index.html


いいなと思ったら応援しよう！