Facebook x

ジャンル

エンジニアの実体験から学ぶ!理不尽なクレーム事例と対処方法【アンケート結果】
アンケート 更新日 2025.03.13
x hatenabookmark
3

エンジニアの実体験から学ぶ!理不尽なクレーム事例と対処方法【アンケート結果】

執筆: Qbook編集部

ライター

エンジニアという職業には、技術的な課題を解決する楽しさがあります。しかし、仕事をしている中で「これは一体どういうこと?」と言いたくなるような理不尽なクレームに直面することもあるのではないでしょうか。

今回、現役エンジニアの方々を対象にアンケートを実施し、実際に遭遇した「理不尽なクレーム」のエピソードを集めました。「あるある」と共感できるものから、思わず二度見するような驚きのエピソードまで、エンジニアを悩ませた体験談をぜひご覧ください。

また、その経験から学んだことや後輩・新人エンジニアに伝えたいアドバイスについてもご紹介します。

この先、エンジニアとしてのキャリアを積まれる方は、トラブル解消のヒントとして、先輩方の知見をぜひ参考にしてみてください。

もくじ
  1. 実際にあった理不尽なクレームエピソード
    1. 見積り・コストに関するクレーム
    2. 納期・スケジュールに関するクレーム
    3. 製品の品質・バグに関するクレーム
    4. コミュニケーション不足に関するクレーム
    5. 対応に関するクレーム
  2. 【タイプ別】クレームの対処方法
    1. パワハラ・傲慢タイプ
    2. 責任逃れ・押しつけタイプ
    3. 場当たり的・気分屋タイプ
  3. 後輩・新人エンジニアへのアドバイス
  4. まとめ

1.実際にあった理不尽なクレームエピソード

今回のアンケートでは、どういった内容のクレームに遭遇されたかを調査し、以下のような結果となりました。

claim2.png

最も多かった回答は「製品の品質(バグ・欠陥)のクレーム」という結果になりました。

続いて、「スケジュール・納期に関するクレーム」や「対応に関するクレーム」についても経験されている方が多いようです。

それぞれの事例をご紹介します。

1-1 見積り・コストに関するクレーム

事例①:追加作業や控除を迫ってくる(テストエンジニア・品質保証 30代)

こちらが生産性をあげて対応しているゆえに進捗プラスしているのに、一括契約のはずが、「工数余ってるでしょ?」と追加作業あるいは控除を迫ってくる。

1-1.png

事例②:追加作業の金額を値切られる(セールスエンジニア 50代)

追加作業が発生したため見積もり金額が変わってしまい再度見積もりをしたのだが、値切られた。

1-2 納期・スケジュールに関するクレーム

事例①:無理なスケジュールを押し付けられ、納期超過するとクレームに(Web・アプリケーションエンジニア ~20代)

3ヶ月の短期改修プロジェクトで納期の2週間前に追加機能の方針変更が行われた。

その際、改修箇所が多いため対応できない旨何度も掛け合ったが、「〇〇さんならできる」と根性論で納期の延伸は見送り。無事納期を超過しクレームをいただいた。

納期の延伸依頼は口頭だけでなくチャットにて送っていたので、何度も依頼し棄却されているエビデンスを残しておいたため、事なきを得た。

1-2.png

事例②:先方都合で進捗が遅れても納期変更は認められない(システムエンジニア 40代)

マスタスケジュールは決定していて変更不可という状況で、お客様都合により前工程のスケジュールが遅延したのに、後続のスケジュール変更は認められず、開発テスト期間が短縮され、その結果、品質が悪く不具合が続出したが、問題の責任は当社側に押し付けられた。

品質担保のためには十分なレビューやテスト期間が必要となるが、短期間で実施する場合、後になってバグが多く発生することになるとリスクの説明を行った。

1-3 製品の品質・バグに関するクレーム

事例①:先方システムの問題をこちらの責任と主張(システムエンジニア 50代)

プロジェクトで提供したシステムについて、「処理が遅く業務に支障が出る」とクレームを受けた。調査の結果、原因は客先のネットワーク環境にあると判明。しかし客先は「以前のシステムでは問題なかった」と主張し、改善を要求。データ量の増加が影響していると説明したが納得せず、「とにかく前より速くしろ」と要求。さらに「予算がないのでシステム側で対応しろ」と理不尽な対応を迫られた。

最終的に、不要なデータを削減するカスタマイズを特別対応として実施することに。しかし、本来であれば客先側の環境を見直すべき問題であり、エンジニア側の負担が増す結果となった。このように、システムの問題ではないにも関わらず「新しいシステムだから悪い」と決めつけられる理不尽なクレームは少なくないと痛感した。

1-3.png

事例②:仕様外操作のバグも一方的にこちらの責任(テストエンジニア・品質保証 50代)

仕様確定後の開発工程着手以降(詳細設計段階まで進捗)で、ユーザビリティに関わる大きな仕様変更を受けローンチは規定通りとされた為、工程プロセスを圧縮せざるを得ない状況となった。製造工程は詰められないので、評価工程を圧縮せざるを得ず、正常系・異常系共にテストケースのスコープを仕様上規定されている範囲として実施。

顧客確認も経てのリリースとなったが、仕様外操作でのバグが出て、一方的にこちらの手落ちとしてクレームをつけられた。

社内的には品質保証観点で顧客指示による開発着手後の重大仕様変更が要因と整理したが、対外的には今後の取引を考慮し、営業判断でクレームとして受付け、請求できない修正工数が発生。プロジェクトの利益を大きく毀損した。

1-4 コミュニケーション不足に関するクレーム

事例①:顧客と顧客上司の認識が合っておらずやり直しに(システムエンジニア 30代)

成果物を顧客とレビューし問題なしとなったため、顧客内(対顧客上司)のレビューを実施した。しかし、顧客上司から指摘を受けた際に、顧客から「私も思ってました。やりなおせ」と言われた。そもそも顧客内レビューに参加させられているのも意味が分からないし、お前がレビューしてOK出したんだろうと思った。

1-4.png

事例②:合意を得たはずなのに・・・(テストエンジニア・品質保証 30代)

認識合わせをしていたにも関わらず、聞いていないと言われた。

1-5 対応に関するクレーム

事例①:顧客のミスの責任を押し付けられた(システムエンジニア 50代)

顧客から提出された要望書が過去日付になっていた。指摘すると、単なる記入ミスだから気にしないでと言われたのでそのまま対応した。翌週に顧客の部長クラスの人に呼ばれ、大勢の前で納期を守っていないと叱咤され、謝罪文を書かされた。要望書を出した人は知らぬ存ぜぬで逃げた。

事情を知る上司からは顧客の要望通りに謝罪文を書くよう指示された。

1-5.png

事例②:契約終了理由を押し付けられた(テストエンジニア・品質保証 40代)

技術者に作業ミスがあり、すぐに原因分析と改善対応を実施したが、文書ではなくメール文での報告がありえないと言われ、契約終了となった。

早急な対応をしたにもかかわらず契約終了となり、釈然としない状況であったが、現場の技術者に確認したところ、実際は顧客の業務縮小による契約終了であり、契約終了の理由をこちらに押し付けられたかたちであった。

2.【タイプ別】クレームの対処方法

エンジニアとして経験を積まれてきた方々は、理不尽なクレームや要求には毅然とした対応することを推奨しています。

クレームのタイプ別に対処方法について、実際の調査結果をもとに考えていきましょう。

2-1 パワハラ・傲慢タイプ

パワハラ・傲慢タイプは以下のような特徴があります。

  • 感情的に怒鳴る、威圧的な態度を取る
  • 他人を見下し、人格を否定するような発言をする
  • 過度なノルマを課し、ときには長時間労働を強いる
事例

サービス提供内容を超えた要求を繰り返し「お客様は神様だ」の姿勢で高圧的にしてくる。

<対処方法>

繰り返し、サービス提供内容を説明した。軸をしっかりもって対応しつつ、組織で対応が良いです。頼れる人、組織に早く相談する。(監査 40代)

事例

3ケ月間音信不通だった理由を聞いた際に、3ケ月後に連絡するのが当然だと強い口調で説明を受けた。

<対処方法>

社内関係者へエスカレーションを行い、会社として対応を勧めた。

(セールスエンジニア 50代)


高圧的な態度や一方的に叱責してくる場合、対応する人は精神的な負担が大きくなることが考えられます。

そのため、できるだけ一人で抱え込まずに上司や関係者と共有し組織で対応するようにしましょう。

2-2 責任逃れ・押しつけタイプ

「責任逃れ・押しつけタイプ」は以下のような特徴があります。

・失敗や問題が起こるとこちらに責任を押し付ける

・指示が曖昧で、後から「そんなつもりじゃなかった」と言い訳をする

・重要な決断を避け、責任のある仕事を丸投げする

事例

テスト工程で想定よりも不具合を多く検出したことにより開発スケジュールが遅延。開発担当者は一生懸命実装しているとベンダから擁護され、遅延原因をテストチームの見積もりの甘さのせいにされる。

<対処方法>

品質の悪いシステムをリリースすることはできないという点で、遅延はやむを得ないという所をご理解いただいた。要件から認識が合っていなかったこともあり、以後はより上流の要件定義フェーズからテストチームとして参画させていただくきっかけになった。(テストエンジニア・品質保証 30代)

事例

お客様の PC がウィルスに感染し、PC が乗っ取られ不正操作されたインシデントに対して、「御社の製品を導入していたにも関わらわずインシデントが発生したのはなぜか?」と追及された。

(弊社製品はセキュリティ関連製品ではあったが、ウィルス対策ソフトではない。)

<対処方法>

弊社製品のスコープ、機能、アーキテクチャをお客様がご納得されるまで何度も説明した。(テストエンジニア・品質保証 50代)


先方の問題で起きたトラブルの責任を押し付けてくるなどの場合、感情的にならずに毅然とした態度で説明することが大切です。

丁寧な説明を行うことで、クレームをきっかけに信頼が構築され新たな契約につながることもあるようです。

2-3 場当たり的・気分屋タイプ

場当たり的・気分屋タイプには以下のような特徴があります。

  • 指示や方針がコロコロ変わり、一貫性がない
  • 気分や人によって態度が変わる
  • 思い付きの行動が多く計画性がない
事例

要件で決めた内容を当然のようにひっくり返された。

<対処方法>

過去のエビデンスをそろえて、相手の上層部に申し入れをして改善いただいた。(システムエンジニア 50代)

事例

特に言葉遣いや態度に問題ないはずだったのに、顧客の機嫌が悪かったのか、場当たり的なクレームを受けた。

<対処方法>

自分に非がないと思ったら、1人で抱え込まずに直ぐ上司や先輩に打ち上げる。

あと、新人の内の顧客対応は関係が築けるまでは、上司や先輩に必ず同行してもらう。(テストエンジニア・品質保証 30代)


先方の気分によって態度が変わったり、前と言っていることが違う、などのケースにおいても冷静な対応が重要となります。

過去のやり取りを提示する、関係者に共有するなど、これ以上のトラブルにならないように対処しましょう。

3.後輩・新人エンジニアへのアドバイス

エンジニアとしてのキャリアを始めたばかりの方は、クレームや顧客対応に直面することに不安や緊張を感じ、苦手だと感じる方も多いのではないでしょうか。

クレームに対してどう向き合っていくか、数多のピンチを乗り越えてきたエンジニアの方々からのアドバイスをご紹介します。

トラブルを防ぐために、先方とのやり取りは記録として残そう!

  • 顧客との合意事項は必ずエビデンスを残す(PMO 60代~)
  • 資本関係が無い相手との約定は、必ず確認をして文書化し、双方内容確認の上で記録として残すこと。曖昧な表現は勿論、口約束などもってのほかである。顧客や取引先はどんなに親しくなっても友達ではない。(テストエンジニア・品質保証 50代)
  • 「これくらい大丈夫だろう」はやめて、お客様に対してでも、しつこいくらいに確認する(システムエンジニア ~20代)

上司や他部署とも連携し、一人で抱え込まない!

23051558.png

  • 自社(自分、メンバー)を守るためにも、常に潜在的なリスクがある段階で対策を打つことが大事だと思います。上長やリスク部門がある場合にはすぐに相談して、契約面での対応も踏まえ、クレームが発生しても最小限の被害に抑えられるようにしたほうがよいです。(システムエンジニア 40代)
  • 契約段階で認識の齟齬が起きないように、営業と協力して要件を詰めておくことが必要、また、社外だけでなく社内にも変更プロセスを徹底し、変更があった場合の必要な手続きを周知し要件の拡大を防止する。(システムエンジニア 50代)
  • 自分自身の力ではどうしようもないことが多いので、上位者へ伝手がある先輩と関わっておくことが大切です。(組み込みエンジニア 40代)
  • その対応をすることで、客先からの信頼度は上がる一方、図々しくなるのもあるので、製品費用に上乗せするなどしてキャッシュバックするような対応を営業部門に働きかけるよう指導している。(プログラマー 50代)

冷静に対応・判断、主張すべきことはする!

  • 圧力に負けず、正しいことは理路整然と説明することが必要である(テストエンジニア・品質保証 50代)
  • まず原理原則に従ったことを表明しつつ、少しでも顧客の要望に沿える方法が無いかを確認し、最終的には筋を通すことが大事(社内SE 60代~)
  • 相手が感情的になったとしても、自分自身は感情的にはならず、データなどに基づく事実確認と説明を理路整然に行うことが重要と思います(システムエンジニア 50代)
  • 毅然とした対応で謝罪の必要性を十分検討する。否がある場合には、素直に謝罪し改善に努める(セキュリティエンジニア 30代)
  • 何か言われたり、された場合にも、感情的に反射的な発言や行動はせずに、冷静に状況を理解して必要な対応をする事が重要。売り言葉に買い言葉的な発言では何も解決しない。「事実」と「思う事」と「感情」を混同しないように切り分けして整理する事が必要。相手に非があったとしても、その場では言わず、上位者や会社を通じて対応する方が得策。(プロジェクトマネージャ 50代)

いろんな人間がいる、学びになったと考える!

  • 「いろいろな人がいて、いろいろなクレームがある」を経験するは、「その時はなんで?」にはなるが、人生の学びになると思う。(監査 40代)
  • 人間は感情の生き物なので、相手にも立場や事情をあることを鑑みて、実益を取ることを優先して欲しい(セールスエンジニア 50代)
  • 世の中にはいろいろなお客様がいるということを学んだ(システムエンジニア 40代)
  • ビジネスの場では、理屈が通っている方法が最良の選択とは限らないことを学びました。作るのが人間ならばお金を払うのも同じ感情を持った人間であり、なかなかシステマチックにはいきません。程度の問題ではありますが、理不尽なクレームにも対応が必要な場合があることを知りました。新人の間は理不尽に感じることが多いと思いますが、全体を見るようになると考えが変わるかもしれません。(組み込みエンジニア 30代)
  • どんなに時代が変わっても、仕事は人間がするもの。人間は感情の生き物なのでそれが正しいと分かっていてもなかなかそれを受け入れにくい事もある。自分の正義を振りかざさず、相手に応じた柔軟な対応をする事が仕事を上手く進めていくコツのひとつ。(システムエンジニア 50代)

気にしすぎないのがイチバン!

  • 気にしすぎないことです。理不尽なことはどこまで行っても理不尽です。上位役職に掛け合い、避難して行きましょう(テストエンジニア・品質保証 40代)
  • あまり深く考えすぎず、適当に受け流すこと(システムエンジニア 40代)

まとめ

エンジニアとして働く中で、クレームや顧客対応に直面することはあるかと思います。

まずは顧客の要望を聞き、真摯に対応することで顧客との信頼関係が築けるでしょう。

ただし、理不尽なクレームや、"とんでもクレーマー"からのカスハラ(カスタマーハラスメント)には、毅然とした態度で接することが大切です。

「エビデンスを提示する」「周囲を巻き込んで組織として対応する」など、今回のアンケート調査で回答してくださった方々のアドバイスをぜひ参考にしてみてください。

アンケート実施情報

調査方法 :「Qbook」でのWEBアンケート

調査対象者:エンジニアの方

調査機関 :バルテス・ホールディングス株式会社

有効回答数:60名

調査日  :2025年2月17日~2025年2月28日

回答者属性

claim1.png

アンケートにご回答いただきました皆様、ご協力いただき誠にありがとうございました。

アンケート
x hatenabookmark
3

執筆: Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。