RPA・ノーコード導入ベンダーのカスハラ対策— 成果未達クレーム

1. 成果未達が炎上しやすい理由

1-1. ROI約束の曖昧さ

営業トークの「効果イメージ」が、契約上の保証だと誤解されることがあります。
スコープ・前提条件・測定方法を契約とキックオフで固定しないと、後から「聞いていた話と違う」が爆発します。

1-2. 要件追加が「当然の無償」扱いされる

「ちょっとした分岐追加」が積み上がり、プロジェクト全体が肥大化します。
変更管理を拒否すると「対応が悪い」、受けると「いつまでも終わらない」と両面で攻撃されます。

1-3. ITサポート特有の夜間連絡

本番障害やロボット停止時に、個人携帯へ連投されるケースがあります。
IT・SaaSサポートの型はIT・SaaSサポートのカスハラ、BtoB圧力は取引先ハラスメントを参照してください。

2. 対応の型

2-1. 成果定義を数字と境界で示す

「何を・どの期間で・どのデータで測るか」を文書化し、未達時の原因切り分け表を先に合意します。
顧客側の運用変更・データ品質・権限付与遅延も評価軸に含めます。

2-2. 会話例：無償やり直しの強要

顧客「効果が出ない。全部作り直せ。追加費用は払わない」。
ベンダー「効果指標と前提条件を契約書の○○に基づき確認します。スコープ外の再構築は見積もりが必要です」。
ベンダー「威圧的な発言は記録し、プロジェクト責任者会議に切り替えます」。
初動は初動対応を参照してください。

2-3. 損害賠償・返金要求

現場エンジニアが金額交渉しないよう、営業・法務へ即移管します。
損害賠償請求への向き合い方と返金境界の考え方を社内共有します。

3. 予防：提案・契約・運用

3-1. 提案書の書き方

「必ず削減できる」断定を避け、前提・除外・パイロット範囲を明示します。
成功事例の数字は条件付きであることを注記します。

3-2. 変更管理ボード

追加要望はチケット化し、影響工数と納期を毎週レビューします。
マニュアル整備はマニュアル作成、方針は方針ひな型を流用できます。

3-3. 記録

要件合意、変更依頼、障害、威圧発言をプロジェクトIDで残します。
記録様式を導入案件に合わせて使います。

4. 成果未達クレームの切り分け表

中小向けの現実的な体制は中小企業のカスハラ対応も参考になります。

4-補. 成果未達クレームのシナリオ

シナリオA：ROI未達で全面無償やり直し

「人件費が半分にならなかった、最初から作れ」と来る場合、 契約の効果指標・前提条件・測定期間を並べ、顧客側の運用変更やデータ遅延も事実で示します。
スコープ外の再構築は見積もりへ切り、威圧発言は記録して責任者会議に移します。

シナリオB：現場がロボットを止めたまま催促

ユーザーが使わないのに「効果が出ない」と責められる場合、利用ログと権限付与状況を提示し、 スポンサー会議で運用ルールを再合意します。
エンジニア個人が現場と泥仕合しないことが重要です。

導入プロジェクトチェックリスト

• ROI表現が前提付きになっているか
• 変更管理ボードと超過単価があるか
• オンコールと個人携帯直通の禁止があるか
• 成果切り分け表がキックオフで合意されているか
• 返金・賠償交渉の窓口が営業／法務か

案件終了時に「無償で受けた追加」を棚卸しし、次の提案書テンプレを更新します。
提案の言い切りを減らすことが、最大の予防になります。

5. よくある質問

Q. 現場ユーザーがロボットを止め続ける場合は？

利用拒否の事実を記録し、スポンサー（発注責任者）会議で運用ルールを再合意します。
ベンダー個人が現場と泥仕合しない設計にします。

Q. 「他社ならできる」と比較圧をかけられたら？

スコープと前提が同じかを確認し、異なる場合は比較不能である旨を短く返します。
感情的な反論は避けます。

Q. エンジニアが夜間対応で疲弊しています

オンコール体制と時間外の窓口を契約化し、二次被害防止・メンタルヘルスケアを適用します。

Q. 契約解除とデータの扱いでもめます

成果物の権利・移行支援の費用を契約条項で処理し、現場で口約束しません。

Q. 本番障害のたびに「導入が失敗」と言われる場合は？

障害の原因切り分け（基盤・権限・運用・ロボット本体）を報告書で示し、感情的な総括に引きずられません。
再発防止はチケットと変更管理に載せ、個人への責任転嫁は記録して上長対応へ移します。
障害対応の時間外費用が契約外なら、保守プランの見直しも同時に提案します。
「全部失敗」という言い方自体が威圧なら、会議の進行役を責任者に交代します。

5-補. 提案・実装・保守の一貫教育

営業・実装・保守が同じ前提文書を使う研修を四半期ごとに行います。
営業だけが強いROI表現を使うと、実装がカスハラの受け皿になります。
変更管理のデモを顧客キックオフで見せ、「追加は見積もり」を最初に合意します。
障害時の連絡はチケット必須にし、個人チャットでの確約を禁止します。
成果未達の切り分け表は、顧客と一緒に記入するワークにすると納得感が上がります。
返金要求が出た案件は、必ず営業・法務・PMの三者で振り返り、提案テンプレを更新します。
夜間対応の実績が多い顧客は、保守プランの見直しを提案し、善意のサービス残業を止めます。
エンジニア評価に「無理を聞いた回数」を入れないことが、文化の核心です。

小さく始めて効果を測るパイロットを標準化し、一括導入の過大期待を減らします。
期待値の設計が、技術品質と同じくらい重要です。
成果は約束ではなく、前提つきの共同作業だと伝え続けます。

6. まとめ

• ROIは前提付きで書き、保証とイメージを混同させない
• 追加要件は変更管理で可視化する
• 成果未達は切り分け表で事実議論に戻す
• 返金・賠償は営業・法務へ移管する
• 夜間個人連絡を止め、オンコールを組織化する
• 提案・実装・保守で同じ前提文書を使い、口頭の上乗せ保証を禁止する

RPA・ノーコード導入の摩擦は、技術不足より期待値設計の失敗から始まることが多いです。
提案書の断定表現を控え、前提・除外・測定方法を顧客と共有することが最大の予防です。
追加要望は変更管理で可視化し、無償の積み上げを止めます。
成果未達時は切り分け表で事実に戻し、エンジニア個人への人格攻撃は記録して責任者へ移します。
夜間の個人連絡を禁止し、オンコールを組織の仕組みにします。
返金・賠償は現場で約束せず、契約条項で処理します。
小さく測るパイロットを標準化すれば、過大なROI神話を減らせます。

7. 注意

本記事は一般的な対応の考え方の例示であり、法的助言ではありません。
契約・知財・損害賠償の判断は専門家にご確認ください。