システム開発やWEB業界におけるプロジェクトは、高度な専門知識と技術を必要とする一方で、発注者と受注者の間での認識のズレから生じるトラブルが少なくありません。その中でも、カスタマーハラスメント（カスハラ）は特に厄介な問題として浮上しています。
本ブログでは、システム開発やWEB業界におけるカスハラの特徴、発生しやすいシチュエーション、そしてそれに対する効果的な対応策について詳しく解説します。
これからのプロジェクト運営において、カスハラを未然に防ぎ、円滑な業務遂行を目指すためのヒントをお届けします。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
目次
システム開発やウェブ業界のカスハラ・クレームの特徴
システム開発やWEB業界では、カスタマーハラスメント（カスハラ）が他の業界に比べて特有の形で現れることが多いです。これには以下のような特徴があります。
事業者間契約が多い
システム等開発契約では、発注者も受注者も事業者であることが一般的です。資本金の大小により、発注者側の力が強いことがよくあります。そのため、クレーム発生時にこれを跳ねのけて紛争リスクを回避するためには、クレームを予防するための事前対策が重要です。
契約内容の不確定および認識の相違による紛争が多い
システム等開発契約では、契約内容が不明瞭になりがちであり、発注者と受注者の間で契約内容に関する認識の相違が生まれやすいです。結果として、発注者が受注者に対して受託業務でない行為の履行を求めたり、納品物に対して抽象的なクレーム（「イメージと違う」、「何だか気に入らない」）を主張し、リテイクを要求するなどのカスハラを行うことがあります。
受注者は、契約書等による債務の内容確定が困難であるため、要求を飲まされる傾向にあります。契約内容が不確定になりやすい、または契約内容に関する認識の相違が生じやすい理由としては以下の点が挙げられます。
契約書等が作成されない、または内容が不十分
システム等開発契約は、開発契約という性質上、交渉の過程で多数の書面（提案書、要件定義書、設計書、検収仕様書、暫定稿など）がやり取りされます。また、納期を守るために先走って着手してしまうことも多いです。その結果、契約内容が不明瞭になることがあります。
当事者が契約内容を正確に理解していない
発注者はシステムに関する十分な知識を持ち合わせていないことが多いです。特に、単発的なシステム開発契約においては発注者が全くの素人であることも珍しくなく、目的物・品質・作業方法・作業量等について発注者が具体的なイメージを持ちにくいです。
例えば、簡単なWEBサイト開発契約ですら、契約内容を確定するためには、希望するWEBサイト全体のデザイン、ページ数、システム構造、納期、配置するテキスト・画像の作成分担、当該テキスト・画像の分量・内容、サイト表示速度の許容値、ドメインの取得・管理やサーバーの維持・管理分担、作成した著作物の帰属、素材等の費用負担など多岐にわたる事項に関して発注者の要望に基づく仕様決定が必要です。
受注者が各契約内容について十分説明した上で契約書等を作成したと思っていても、専門知識に乏しい発注者は契約内容について全く別の認識を持っていることがあります。こうなると、発注者の思い込みによって、発注者側の債務不履行（検収、資料提供などを行わない等）や、契約外債務の履行要求（作成予定の無いシステムが作成されていないことに対してクレームを言う等）といったトラブルが生じやすいです。
一方、受注者も、発注者の知識レベルに沿った説明が不十分になり発注者に誤解を生じさせてしまったり、法的知識の不足から契約書の内容を誤って理解してしまったりしていることもあります。
履行過程での契約内容の変更が多い
システム等開発契約においては契約の履行過程において当初想定されていなかった障害が生じ、これに対応しなければならないことがあります。この場合、当該障害への対応は、既存の契約に内包される無償の障害対応の場合もあれば、追加契約または仕様変更が必要な既存契約外の有償の追加業務の場合もあります。
システム等開発業界においては、契約の追加または変更の要否を見極めるべき事情が履行過程において度々発生します。しかし、実際の開発現場では、情報連携不足、契約内容への無理解、本体業務に忙殺されていることなどから、書面での適切な追加変更契約が締結されることなく、なし崩し的に追加要望に対応した結果、後になって報酬不払などのトラブルが生じることが多いです。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
損害賠償額が高額になるリスク
システム開発契約は、小規模なWEBサイトの開発から上場企業の基幹システム開発まで、多岐にわたる規模の契約があります。そのどの規模の契約においても、受注者は開発契約に対する報酬に比べて高額な損害賠償義務を負うリスクがあります。
これは、システム開発契約における納品物が発注者側のビジネスに利用されるためであり、その背後には膨大なユーザーが存在し、それによって膨大な発注者の損失が考えられるからです。そのため、逸失利益や間接損害に関する賠償責任を責任制限条項によって排除していない場合、これらに関する高額な損害賠償責任が認められる可能性があります。
例えば、東京高等裁判所の令和2年2月26日の判決（事件番号:令元ネ2423号）では、報酬合計約4430万円の宅配システムの開発契約に関して、わずか5人のユーザーが正常にサイトにアクセスできなかったことが瑕疵担保責任における瑕疵と認定されました。その結果、想定売上から経費を控除した上で過失相殺類推適用前において1254万7660円の逸失利益に対する損害賠償義務が認められました。
このように、システム開発業界においては、カスハラやクレームを適切に対応しないと、高額な損害賠償リスクを抱えることになります。ITやWEB関連のプロジェクトにおいても、このようなリスクを念頭に置き、事前に適切な対策を講じることが重要です。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
システム開発やウェブ業界におけるクレーム・カスハラ対策のポイント
それでは次に、システム開発やウェブ業界におけるクレーム・カスハラには、どのような対策を行なっていくべきかを解説していきます。
クレーム予防の対策ポイント
カスハラやクレーマーによるクレーム対応を効果的に行うためには、事前の対策が重要です。以下のポイントに注意して対応しましょう。
基本的な契約書の締結
自社に有利な条項や通常の契約条件を記載した基本的な契約書を早期に締結します。これにより、後々の紛争を防ぐことができます。
口頭合意の確認と保存
口頭での合意は速やかに合意書などの書面やメールで確認し、保存しておくことが重要です。これにより、証拠を確保しトラブルを防ぎます。
問題発生時の書面化
システム障害の発生、納期遅延の恐れ、追加発注・仕様変更・工数増加に伴う報酬額の増加見込みなどの事情が生じた場合は、放置せず説明・確認を得て、書面化しておきます。
契約書へのリスク回避条項の挿入
契約書には、「間接損害および逸失利益に関する免責条項」や「損害賠償額の上限条項」などの責任制限条項、「発注者都合の中途解約違約金条項」などを入れることが重要です。
システム開発等契約に関するクレームの多くは、契約内容が曖昧不明瞭であることが原因です。そのため、受注者としては口頭で説明した内容を覚書や議事録として残し、メールで確認する、契約書を作成するといった方法で契約内容が不明確になることを防ぐことが重要です。
できれば、受注者に有利な条項や自社での平素の契約条件を記載した基本的な契約書を早期に締結し、自社に有利なポジションを確立することが望ましいです。ただし、ひな形集やインターネット上の契約書をそのまま利用するのは非常にハイリスクですので絶対に避けるべきです。
標準的書式としては、経済産業省・独立行政法人情報処理推進機構の「情報システム・モデル取引・契約書〈第二版〉」があり、これは加除を前提とした中立的内容になっています。システム等開発契約の実態は千差万別であるため、経産省モデル契約書をそのまま利用するのも危険です。弁護士と相談の上、自社独自の基本となる契約書を準備することが望ましいです。
また、契約書などの客観資料を作成しても、契約履行過程で生じた障害や追加発注などによって既存の契約書が契約実態に沿わなくなることがあります。この場合、現状と異なる既存の契約書のみが存在している状態は、発注者に「追加発注までも既存の契約に内包されている」と主張される可能性があります。したがって、システム障害の発生、納期遅延の恐れ、追加発注・仕様変更・工数増加に伴う報酬額の増加見込みなどの事情が生じた場合は、放置せず説明・確認を得て書面化しておくことが重要です。
さらに、万一紛争が生じた場合に備えて、契約書には必ず「間接損害および逸失利益に関する免責条項」や「損害賠償額の上限条項」などの責任制限条項を入れることが重要です。確かに、受注者側に故意や重過失がある場合には責任制限条項が限定解釈される可能性もありますが、基本的には責任制限条項の有効性は認められる傾向にあります。
例えば、受注者の発注者に対するプロジェクトマネジメント義務違反を認め、約42億円の損害賠償義務を課しながらも責任制限条項の有効性を認めて逸失利益についての賠償請求を否定した例として、東京高等裁判所の判例（東京高判平25・9・26）があります。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
クレーム発生後の対策ポイント
システム等開発業界でカスハラやクレームが発生した場合、以下の対策ポイントに従って対応することが重要です。
法的責任の判断
法的責任の判断を行う際は、客観資料の有無や内容を確認します。
現場の対応
現場の従業員（顧客対応者）だけで場当たり的な対応をせず、早期に法的責任と判断権者の判断を踏まえて対応します。
客観資料の提示
クレームに対処する際は、適宜、客観資料を提示して対応します。
情報の記録と共有
クレームが発生した場合、担当者だけで情報を留めず、クレーム内容、回答内容、解決内容などを記録し、社内で共有します。
クレーム発生後の具体的な対応手順
クレーム予防の対策を尽くしてもクレームが発生することはあります。この場合、一般的なクレーム対応の流れ（【聴取】→【調査】→【判定】→【回答】）を遵守することに加えて、以下のポイントに特に注意します。
まず、【調査】においては、客観資料の有無や内容を確認することが重要です。クレーム予防の対策ポイントを守っていれば、この段階で自社に有利な客観資料が準備できることが多いです。仮に客観資料がない場合でも、資料がないという事実関係を明らかにすること自体が法的責任の有無の判断に役立ちます。
次に、【判定】および【回答】においては、現場の従業員（顧客対応者）だけで「なんとなく」の回答をすることは避けるべきです。判断権者（厚労省カスハラマニュアル24頁でいう現場監督者、相談担当者等）が、【調査】で収集した資料を確認した上で【回答】を行うべきです。クレーム発生初期段階できっちりとした回答ができていれば、大きなトラブルにならなかった案件について、現場限りで安易な回答をした結果として発注者の誤解を増大させ、後々大きなトラブルとなることがあります。
また、【回答】の際には、必要に応じて発注者に対して客観資料を見せながら説明を行うことも有益です。顧客が事業者である場合は、感情より利益を優先しやすいです。そのため、法的判断の根拠となる客観資料を提示しつつ回答することで、顧客側も訴訟になった際の敗訴リスクを認識して引き下がる可能性があります。ただし、中途半端な資料提示はかえって争点を増やすことにもなりかねないので、提示する客観資料の吟味が必要です。
最後に、【回答】の後には、クレーム内容、回答内容、解決内容などを記録して社内で共有することが重要です。システム開発等契約は、履行中および履行後も保守管理などで発注者との関係が継続する長期的取引となることが多いです。この場合、当該顧客への注意喚起、後任への申し送り、過去の紛争の振り返りを事後的に行えるように、クレームが生じた場合には都度記録を保管することが必要です。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
システム開発やウェブ業界におけるカスハラ・クレームのケーススタディ
このような状況で、V社としてはどのように対応すればよいでしょうか。
対応プロセス1：聴取
まず、発注者が具体的に何を主張し、どのような要求をしているのかを確定させることが重要です。
現段階では「イメージと違う」という抽象的で漠然とした理由に基づき、要件定義書などで確定したものとは別のデザインを求めています。これは、顧客自身が不満を十分に言語化できていない場合があるため、適切な聴取を行えば、契約内で対応可能な軽微な修正で済む可能性もあります。
「イメージと違う」という不満が、既存の受任業務の範囲内で対応可能なのか、別案の追加受注をすれば解決可能なのか、それともどうやっても解決しない漠然とした不満なのかを切り分ける必要があります。
質問と解答例のパターン1
質問
V社：「『イメージと違う』とおっしゃる点は、具体的にはどのような点でしょうか？」
パターン①既存の受任業務の範囲内の可能性あり
C社：「フォントがダサい。参考サイトとして挙げたサイトのフォントとは大分イメージが違うじゃないか」
この場合、既存の発注内容（参考サイト）に関する具体的な指摘であり、フォントの修正という要求内容も明確です。これに対応すれば良いことが分かります。
パターン②既存の受任業務外の追加受注の可能性あり
C社：「要件定義の時には、参考サイトとして挙げたサイトAみたいなのがいいと思ったけど、いざうちの商品で作ってみるとイメージと違った。むしろ、サイトBの方がイメージに近いと思うんだよね」
この場合、既存の発注内容（参考サイトA）とは異なる新規の内容（参考サイトB）に関する追加の要望と考えられます。
パターン③不当クレームの可能性が高い
C社：「何が違うかは、自分で考えろ！プロだろ！」
この場合、要求内容に具体性がなく、要求根拠も契約内容に基づくものではないことが分かります。質問の角度を変えて聴取を試みつつ、それでも同様の曖昧な回答を繰り返す場合、基本的には不当クレームとして対処することになります。
質問と解答例のパターン2
質問
V社：「弊社内で事実関係を確認させていただきます。『イメージと違ったらいつでも修正する』、『必ず商品の魅力を伝えられるサイトにする』という発言があったのは、いつ頃でしょうか。またどのような経緯でしょうか？」
パターン①法的責任に関して根拠資料の言及ありの場合
C社：「契約締結の少し前だから10月上旬だったかな？こっちはもっと安くしてくれる別の会社に頼もうと思って、一度V社に頼むのを断ったんだよ。そしたら、そっちの営業が『うちは、イメージと違ったら何回でも修正します！』、『だから結局のところお安くなりますよ！』って言ってきたんだよ。だから『本当に何度でも修正してくれるんですね』って念押ししてから、それなら契約するって言ったんだ。メールも残ってるよ」
この場合、具体的かつ合理的な経緯の叙述とともに、メールという証拠の提示もあります。まず、これらの日時を聴取し、存否および内容の確認調査が必要です。
パターン②法的責任に関して根拠資料の言及なしの場合
C社：「いつって聞かれてもね。契約するまでは調子のいいこと言って、契約したら『そんなことを言った証拠はない』とか言うつもり？社会人としてどうかと思うけどね」
この場合、具体的な経緯の叙述もなく、証拠資料の提示もできなさそうです。V社としては、関係者からの聴取と客観資料の確認の方法で調査すべきことが分かります。
なお、発注者側に担当者が複数いる場合は、その発言者のみでの主張・要望なのか、発注者全体としての主張なのかを判断するため、適宜、発注者のプロジェクト担当責任者への確認も必要です。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
対応プロセス2：調査
【聴取】のプロセスで、発注者の要求内容や主張する事実関係を確定・整理したら、次は社内で対応の責任者を決定し、その要求内容や主張に関連する客観的事実関係の確認を行います。
この段階で、発注者の主張内容と調査すべき事項を整理することが重要です。以下の事例を例に、具体的な調査手順を見てみましょう。
発注者主張
- 要件定義書作成時にはサイトAを参考にすると言った。
- しかし、サイトAを参考にしたデザインができ上がってみると、サイトAではなく別のサイトBの方がイメージに合っているように思った。
- したがって、サイトBを参考にしたサイトデザインに作り直してほしい。
- 作り直しは、無償で行うべきである。
- その理由は、受注者の営業担当者が発注者に対し、「イメージと違ったらいつでも修正する」、「必ず商品の魅力を伝えられるサイトにする」と述べ、これが契約の内容になったからである。
- 上記発言をした具体的な経緯の説明はないし，具体的証拠もない。
調査すべき事実関係
客観資料の確認
要件定義書、画面設計書、打ち合わせメモ、メールのやり取りなどの客観資料を確認します。
要件定義書に参考サイトがサイトAと明記されているかを確認し、メールやメモから「参考サイトの変更は大幅なデザイン変更となるためできない」ことや「要件定義書作成以降に要件定義書記載の事項を変更することはできない」といった説明の裏付け資料があるかを調べます。また、発注者の主張に沿った説明をしていないかも確認します。
各担当者からの聴取
以下の担当者から詳細な聴取を行います。
＜営業担当＞
「イメージと違ったらいつでも修正する」という説明があったかどうか、どのような媒体（口頭、電話、メール、書面）で行われたかを聴取します。
＜契約締結作業担当者＞
契約締結の経緯に関して、特に契約内容をどのように説明したか、説明したことの証拠があるかを聴取します。
＜要件定義書等作成・打合せ担当者＞
要件定義の際の打ち合わせ内容や、「要件定義書作成以降に要件定義書記載の事項を変更することはできない」といった要件定義書の意義に関する説明を行っているかを聴取します。
サイトAとサイトBの内容比較
参考サイトをサイトAからサイトBに変更した場合、要件定義書、画面設計書、デザイン案のどの内容を変更することになるのか、どの程度の追加発注が必要となるのかを整理します。
対応プロセス3：判定
【調査】で確定した事実に基づいて、発注者の主張する事実関係の有無と、発注者の要求に対する法的責任の有無を判定します。
発注者の主張する事実関係の有無
営業担当者から送付されたメールには、「弊社ではお客様のご要望を丁寧にお聴き取りさせていただきます。必ずや商品の魅力を伝えられるサイトになるはずです」といった一般的な営業文句が記載されていましたが、「何度も修正に対応する」旨の記載はありませんでした。このメール内容と営業担当者からの聴取内容を踏まえ、発注者が主張するような発言はなかったと判断されました。
法的責任の有無
要件定義書には参考サイトがサイトAと明記されており、さらに要件定義書を添付して送付されたメールには「※この定義内容で発注内容はご確定となります。要件定義の内容を変更する場合は追加発注になり追加料金が発生します。」と記載がありました。したがって、サイト開発契約の受注内容は、少なくとも要件定義書作成段階においては要件定義書の記載内容に限定されることが客観資料をもって立証できる可能性が高いと判断されました。
以上の点を整理し、判断権者に確認を求めた結果、「サイトBを参考にしたデザイン案を作成し直せ」という発注者の主張は既存の受託業務に含まれない追加発注であり、これを無償で行うことは不当であると判定されました。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
対応プロセス4：回答
【判定】で法的責任がないと判断された場合でも、受注者としては回答方法と回答内容を慎重に検討する必要があります。
システム開発等契約は、一定の期間にわたって相互協力の下で進行するため、発注者との関係を円滑に保つことが重要です。また、既存の成果物の権利帰属や報酬の計算が複雑になることが多く、オーダーメイドの契約であるため、中途解約リスクを軽減するのが難しいこともあります。
したがって、クレームに対して自社に法的責任がないと判断された場合でも、発注者側が今後の履行において敵対的になり作業が困難になるリスクや、中途解約による失注リスク、既存の成果物に関する別の紛争リスク、前払いを受けていない場合の報酬回収リスクを考慮する必要があります。
紛争リスクの評価
契約履行中に発注者都合で解約された場合の違約金条項や既履行部分の評価に関する条項がない場合、報酬金についても各作業工程ごとに割り付けられておらず「ホームページ作成一式○○円」と包括的に記載されていることがあります。前金として報酬金の3割しか受け取っていない場合、発注者との間でトラブルが拡大し、中途解約された場合には現在の作業進度が全体の8割程度であれば、報酬回収リスクが高いと分かります。
一方で、サイトBに沿った別案の提案を無償で行うことは、ほとんどの作業をやり直すことに等しいため、無償で対応することは難しいと判断されました。
回答内容の決定
以下の事項を含めた譲歩提案を行います。
- 発注者の主張する事実は確認できなかったこと。
- 要件定義書の内容を変更する際には追加料金が発生することが確認され、合意されていること（要件定義書のメール送信日時を客観資料として提示）。
- 参考サイトをサイトBに変更してデザインを修正する際に掛かる工数・作業時間は、実質的に複数案件の受任に等しいこと。
- 以上の理由から、参考サイトをサイトBに変更するデザイン変更を無償で行う義務はないこと。
- 法的責任はないが、契約上予定されていたデザイン修正確認の期限を過ぎているため、期限の点は譲歩して契約上予定されていた軽微修正に応じること（修正対応範囲に関する具体例を提示）。
回答方法の決定
書面や弁護士名義での連絡は、かえって事態を悪化させる可能性があると判断しました。そこで、受注者のプロジェクト担当責任者から発注者の担当責任者に対してメールを送付する方法を取ることにしました。
システム等開発業界においては、カスハラやクレーマーに対する対応が重要です。ITやWEB関連のプロジェクトでも同様の問題が発生することがあるため、適切な対応策を講じることが求められます。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
まとめ
システム開発やWEB業界におけるカスハラ（カスタマーハラスメント）は、他の業界と比べて特有の課題を含んでいます。専門的な知識や技術が関わるため、発注者と受注者の間で認識のズレが生じやすく、これがカスハラに繋がる原因となります。
発注者が「イメージと違う」といった主観的な理由で頻繁に修正を求めるケースや、進捗状況に対する不安から過度なプレッシャーをかけることは、受注者にとって大きな負担となります。こうした状況に対応するためには、契約段階での詳細な要件定義や進捗報告の徹底が不可欠です。
また、クレーム発生時には、適切な対応プロセスを踏むことが重要です。具体的には、【聴取】→【調査】→【判定】→【回答】の流れを遵守し、法的責任の有無を確認しながら対応することが求められます。場当たり的な対応は避けましょう。
システム等開発業界やIT、WEB関連のプロジェクトでは、カスハラを未然に防ぐための予防策と、発生した場合の適切な対応策をしっかりと講じることが重要です。これにより、プロジェクトの円滑な進行と良好な発注者・受注者関係を維持することができます。
総じて、システム開発やWEB業界におけるカスハラへの対策は、企業の信頼性を高め、業務の効率化を図る上で欠かせないものです。全従業員に対する適切な教育と対応マニュアルの整備を通じて、カスハラに対する備えを万全にしておきましょう。
香川総合法律事務所では、カスハラ顧客やクレーム顧客の対応をはじめ、企業向けのカスハラマニュアルの作成や、研修等も行なっております。カスハラやクレームにお困りの場合は、是非ご相談ください。
カスハラ・クレーム対応に
お悩みの方は
お気軽にご相談ください
経営者様・会社様専門の相談窓口となっております
システム開発会社であるV社は、C社から新ブランドPR用のWEBサイト開発の依頼を受けました。V社とC社は打ち合わせを行い、見積書、要件定義書、画面設計書を作成し、システム設計やサイトデザイン方針を決定しました。その後、これに従ったデザインの確認を経て、システム開発に着手しました。
しかし、C社から突然「やっぱりなんかイメージと違うんだよね。もう1回別のデザイン案を出してくれない？」というクレームがありました。これに対して、V社は複数案の提案には別途料金が発生することを説明しました。しかし、C社は「V社の営業は『イメージと違ったらいつでも修正する』、『必ず商品の魅力を伝えられるサイトにする』って言ってたぞ？無償で修正に応じるのは契約に含まれてるはずだろ！」と主張し、無償で別案を提案することを要求してきました。
確かに、V社では発注者のデザイン確認作業の際、1回に限り軽微なデザイン修正を受け付けていますが、画面設計書等に記載のレイアウトやカラーイメージの修正などを伴う大きな修正は、実質的に複数案件の受任と同等の労力がかかるため、別途料金が発生します。しかし、本件ではそのことを記載した契約書を作成していませんでした。