IT業界の実態をもっと知ろうシステム開発トラブルはなぜ起きる
紛争予防のポイントは?
ふかざわ さとし IT法務(システム開発紛争、ネットトラブル・誹謗中傷、IT企業の一般法務)を中心に、労働事件や刑事弁護を取り扱っている。
トラブルの原因
一般的な法律トラブルでは、納期遅延のように、期限切れが争いの原因になることが多いです。しかし、システム開発の場合、少し事情が異なります。システム開発では受注したベンダー企業が、品質はともかく納期に合わせてシステムをとりあえず完成させることが可能です。そのため、トラブルになるのは、期限切れではなく、システムの完成度が低いとか、ほしい機能が備わっていないとか、発注側が要件定義どおりではないと訴えるケースが多いです。
そもそもシステム開発は、既製品では自分たちの要求を満たすことができないユーザー企業が、ベンダー企業に開発を発注することで始まります。そのため、作業はおのずとカスタムメイドで行われ、開発内容は、ユーザー企業の特殊なニーズを反映したものになります。それがトラブルが生じやすい原因になります。
システム開発のトラブルの背景には、ソフトウエアやシステムが目に見えないという特殊性が関係しています。例えば、建物の部屋をイメージした場合、多くの人は四方に壁があって、屋根があって、ドアがあるという空間をイメージします。ところが、ソフトウエアにはそのような共通したイメージがありません。また、建築物には、建築基準法という法律があって、鉄骨の数などの基準が細かく定められていますが、ソフトウエアにはそれがありません。
そのため、トラブルが生じた場合は、民法や裁判例が判断基準となります。そこで最も重要なポイントは、「ベンダーとユーザーは協力しなければいけない」ということです。
サービスを求める側と提供する側が互いにコミュニケーションを取って成果物をつくっていく。これがシステム開発のポイントです。ユーザーはベンダーに要望を具体的にきちんと伝え、ベンダー側も、ユーザーの要求を無条件に受け入れるだけではなく、できること・できないことを明確に伝える必要があります。
プロジェクトマネジメント義務
ベンダーの立場で気を付けてほしいのは、ユーザーの要望を無制限に受け入れるのが良いかというとそうではない、ということです。開発が暗礁に乗り上げそうな場合には、ベンダーにはユーザーに助言する義務があると裁判所は示しています。これはプロジェクトマネジメント義務と呼ばれます。
コミュニケーションとは、相手の言いなりになることではなく、ユーザーの要望についてレビュー、調査、評価をすることが含まれます。一方のユーザー側としても、ベンダー側に曖昧な要望を伝えるだけではサービスは提供されないと認識し、開発に協力することが求められます。
不要な紛争を避けるためには小さな会社でも最初の段階で契約書を結ぶことは大切です。その中で、ユーザーの協力義務について触れるか、少なくとも説明しておくと良いでしょう。
ユーザーの要望を固定する
紛争予防としてベンダーに大切なことは、ユーザーの要望をまず固定することです。ユーザーの不満が解消するまで要望を聞き続け、修正作業を繰り返すのは精神的に非常につらいものがあります。例えば、『美味しんぼ(作:雁屋哲、画:花咲アキラ、小学館)』というグルメ漫画で、海原雄山という美食家が、出された料理に満足せず何度も突き返すというシーンがあります。でも、海原雄山が何を望んでいるのかなど本人しかわかりません。本来であれば、「海原先生、何がお望みですか」と聞かなければいけません。それを聞かないで何度も料理を出して突き返されるのでは、物事はいつまでたっても前に進みません。
労働時間を短縮するためにも、ユーザーとのコミュニケーションには、一定のスキルがある人材をあてがうなど、企業としてのリソースを割くべきでしょう。認識の食い違いを避けるために、打ち合わせの内容を要約したメールを発信しておくことは有効です。裁判での証拠にもなります。
コミュニケーションが大切
ベンダーとしては、ユーザーの要望に対して「できない」とは言いづらいものです。しかし、「できない」ことを「できる」と言ってしまうのは、医者が「治せる」と言って「治せなかった」ようなものです。裁判でも言った側の責任が問われます。「できる」と言ってリスクを負うより、「できない」と最初から説明しておく方がリスクを避けられます。
また、ユーザーの要望を無理して引き受けることは、現場の負担を増加させることで、他の顧客の案件にまで悪影響を及ぼします。安易な「イエス」は、目の前のユーザーだけではなく、他の顧客まで不幸にすると念頭に置くべきです。
繰り返しになりますが、紛争を避けるためのポイントは、一にも二にもコミュニケーションです。コンピューターの仕事であっても、コミュニケーションが最重要課題になるというのが、私がシステム開発紛争の事件を担当して得た実感です。