システムの品質が低いと感じたときの伝え方

「なんとなく使いにくい」「バグが多い気がする」。納品されたシステムを日々触っているうちに、そんな違和感が積み重なっていくことがあります。しかし、いざ開発会社に伝えようとすると、「具体的にどこが悪いのか説明してほしい」と聞き返され、うまく言葉にできずに引き下がってしまう。あるいは、感覚的な不満をそのままぶつけてしまい、「主観的すぎる」「仕様通りに作っている」と押し返されて終わる。ひとりで情シスや総務のIT担当を兼任していると、社内に相談できる相手もおらず、「自分の感じ方がおかしいのだろうか」と自信を失ってしまうことも少なくありません。

結論から言うと、品質への不満を開発会社に正しく伝えるために必要なのは、感情や印象を排除することではありません。「何を」「どういう基準で」「どれくらいの頻度・影響で」問題だと感じているかを、相手が動ける形に翻訳することです。品質という言葉は曖昧に聞こえますが、実際には「バグの多さ」「使いやすさ」「動作の速さ」「安定性」という、性質の異なる4つの軸に分解できます。この記事では、その分解の仕方から、証拠の残し方、開発会社に送る報告文の型、契約上どこまでが無償対応の対象になるのかの目安、話がこじれたときの交渉の進め方までを、実務の順番に沿って解説します。

この記事で分かること

品質への不満を「伝わる形」に変換し、開発会社との交渉を前に進めるための一連の流れを解説します。

• 「品質が低い」という漠然とした不満を、具体的な4つの軸に分解する方法
• 主観的な印象論と受け取られないための、記録・証拠の残し方
• 開発会社に送る報告文の型（現象・再現手順・影響・期待する状態）
• 無償で直してもらえる範囲と、追加費用が発生する範囲の見極め方
• 「使いにくい」という設計・UXの不満を伝えるときの注意点
• 話が平行線になったときの交渉の進め方とエスカレーションの判断基準
• 同じ問題を再発させないために、契約・体制面でできる予防策

順番に見ていきましょう。

「品質が低い」を4つの軸に分解する

「品質が低い」という言葉は、話す人によって指している内容がまったく異なります。ここを揃えないまま開発会社に伝えると、双方が別々の問題について話しているのに気づかず、話が噛み合わなくなります。まず自分が感じている不満が、次の4つのうちどれに当てはまるのかを整理してください。

この4つは、開発会社側の受け止め方も、対応の性質もそれぞれ異なります。バグは「契約通りに作られていない」という契約不適合の話になりやすい一方、使いやすさやパフォーマンスは「仕様上は満たしているが、体感として困っている」という話になりやすく、無償修正の対象になるとは限りません。まず自分の不満がどの軸に属するのかを言語化するだけで、開発会社への伝え方も、この後の交渉の落としどころも大きく変わってきます。

バグ・不具合:再現性があるかどうかが最初の分かれ目

バグ・不具合の軸でもっとも重要なのは、「毎回同じ手順で発生するか」という再現性です。再現性のある不具合は、開発会社にとって原因調査がしやすく、対応の優先順位も上げやすい性質を持っています。一方、「たまに起きる」「特定の人だけ発生する」といった再現性の低い症状は、原因の特定に時間がかかり、開発会社側から「こちらでは再現しません」と返されがちです。

不満を感じた時点で、「今回はどちらのタイプか」を意識するだけで、この後の証拠集めの方針が変わります。再現性がある場合は手順を正確に記録すること、再現性が低い場合は発生日時・発生時の状況をできるだけ多く記録することが、それぞれの対応の第一歩になります。

使いやすさ・パフォーマンス:「困っている業務」とセットで語る

使いやすさやパフォーマンスへの不満は、「使いにくい」「遅い」という言葉だけで伝えると、感想の域を出ません。開発会社が動きやすくなるのは、「どの業務で」「どれくらいの頻度で」「どんな支障が出ているか」がセットになっているときです。

たとえば「一覧画面が遅い」という不満よりも、「毎朝の受注確認で1日あたり20回ほど開く一覧画面で、表示に5秒前後かかる。担当者3名の作業時間に影響している」という伝え方のほうが、開発会社は改善の必要性を判断しやすくなります。感覚的な不満を業務影響という具体的な言葉に置き換える作業が、この段階でもっとも重要な準備になります。

主観的な印象論と受け取られないための記録の残し方

「品質が低い」という指摘が開発会社に響かない最大の理由は、多くの場合、記録が「言った・言わない」で終わってしまう状態にあることです。ここでは、後から見返しても事実として通用する記録の残し方を整理します。

「なんとなく前より重い気がする」「バグが多い印象がある」——こうした表現は、開発会社にとっては「具体的にどの機能の、いつの話か教えてください」と聞き返さざるを得ない情報しか含んでいません。記録の目的は、開発会社に聞き返させないところまで具体性を持たせることです。

記録として残しておきたい項目は、次の5つです。

• 発生日時: いつ気づいたか、いつ発生したか(可能であれば分単位まで)
• 操作手順: 何をどの順番で操作したときに発生したか
• 期待していた結果: 本来こうなるはずだと考えていた挙動
• 実際に起きた結果: 画面に表示された内容、エラーメッセージの文言
• 影響範囲: 誰の、どの業務に、どの程度の支障が出たか

これらをその場でメモできない場合でも、画面のスクリーンショットを撮っておくだけで、後からの記録作成が格段に楽になります。エラーメッセージが表示された画面、意図しない結果が表示された一覧画面などは、気づいた時点でとりあえず撮影しておく習慣をつけておくと、後で「あの時の画面、どんな表示だったか」と悩まずに済みます。

「回数」を数えることの意味

単発の不具合であれば、1件ずつ丁寧に報告すれば十分です。しかし、「同じような症状が繰り返し起きている」という場合は、件数を数えておくことが交渉材料として大きな意味を持ちます。

たとえば、「先月は3件だった同種の不具合報告が、今月は11件に増えている」という記録があれば、それは印象論ではなく傾向を示す事実になります。件数の推移を示せると、開発会社側にも「一時的な当たり外れ」ではなく「品質の傾向として悪化している」という認識を共有しやすくなります。件数を数えるための特別なツールは必要なく、問い合わせフォームやメールの履歴、社内のチャットログを日付順に並べるだけでも十分な記録になります。

複数人からの声を1つにまとめる

自分ひとりの体感だけで訴えると、「あなたの感じ方の問題では」と受け取られるリスクが残ります。可能であれば、同じシステムを使う他の社員からも同様の不満が出ていないかを確認し、複数人の声として集約してから開発会社に伝えることをおすすめします。

• 部署内のチャットやミーティングで「システムについて困っていることはないか」と一度聞いてみる
• 個別に上がってきた声を、前述の5項目（発生日時・操作手順・期待結果・実際の結果・影響範囲）に整理し直す
• 誰が言ったかではなく、「何が」「何件」起きているかを主語にして開発会社に伝える

これは開発会社を責めるための材料集めではなく、「自分ひとりの感覚ではなく、業務全体として支障が出ている」ということを、事実として共有するための作業です。

開発会社に送る報告文の型

記録が揃ったら、それを開発会社に伝わる文章に変換します。ここでは、実務でそのまま使える報告文の型を紹介します。基本的な構成は、検収の場面で使う不具合報告の型と共通していますが、リリース後の品質不満では「単発の不具合」だけでなく「傾向」として伝える工夫が加わります。

単発の不具合を報告する場合の型

1. 件名: 一目で内容が分かるように（例:「受注一覧画面 表示エラーの件」）
2. 現象: 何が起きたかを簡潔に(1〜2文)
3. 再現手順: 番号付きで、誰が読んでも同じ手順を再現できるように
4. 期待する挙動: 本来どうあるべきだったか
5. 実際の挙動: 実際に何が表示・発生したか(スクリーンショット添付)
6. 発生頻度・影響範囲: 何回中何回発生するか、誰の業務に影響するか
7. 希望する対応と期限感: いつまでにどう対応してほしいか(緊急度も添える)

傾向として品質の不満を伝える場合の型

単発の不具合ではなく、「最近、全体的に品質が落ちている気がする」という不満を伝えるときは、単発の型に加えて次の要素を追加します。

• 直近の一定期間(たとえば3ヶ月)で発生した不具合・不満の件数一覧
• 件数の推移(増えているのか、特定の時期に集中しているのか)
• 症状の傾向(似たような箇所で繰り返し起きていないか)
• 業務への累積的な影響(1件あたりは小さくても、積み重なるとどれくらいの時間・コストになっているか)

この型に沿って報告文を作成すると、開発会社側も「感覚的なクレーム」ではなく「具体的な改善要望」として受け止めやすくなります。実際に、契約不適合責任に基づく無償修正の対象かどうかを開発会社側が判断する際にも、再現手順や発生条件が明記されている報告のほうが、社内での確認・対応の意思決定が速く進む傾向があります。

送る前に確認しておきたいチェックリスト

報告文を送信する前に、次の項目を確認しておくと、やり取りの往復を減らせます。

• 現象を説明する文章に、感情的な表現(「ひどい」「使えない」等)が混ざっていないか
• 再現手順は、開発会社の担当者が実際に手順通りに操作すれば再現できる粒度になっているか
• スクリーンショットや動画など、視覚的な証拠は添付できているか
• 希望する対応の期限や優先度を明記しているか
• 「無償で直してほしい」のか「見積もりがほしい」のか、意図を明確にしているか

品質不満を伝えるときにやってはいけないこと

報告文の型を知っていても、送り方を間違えると、せっかく整理した内容が正しく伝わらなくなります。ここでは、実務でありがちな失敗パターンを紹介します。

• 一度に大量の不満を箇条書きだけで送りつける: 「ついでにこれも、これも」と溜め込んだ不満を一気に送ると、開発会社側は何から着手すべきか優先順位をつけられず、結果として全体の対応が遅れます。まずは影響の大きいものから2〜3件に絞って送り、残りは別便として整理する方が、実際には早く解決に向かいます
• 担当者個人への不満と、システムへの不満を混同する: 「対応が遅い」「説明が分かりにくい」といった担当者個人への不満と、「システムの品質」への不満は、本来別の問題です。両方を1通のメールに混在させると、開発会社側も何に謝罪し、何を修正すればよいのか判断がつきにくくなります
• 社内の別の人がバラバラに同じ内容を伝えてしまう: 前述の「窓口の一本化」とも関係しますが、同じ不満を複数人が個別に開発会社へ伝えると、開発会社側は同じ問題を重複して受け取ることになり、対応の全体像を把握しづらくなります
• 改善案まで自分で決めつけて要求する: 「このボタンを右上に移動してほしい」のように、具体的な実装方法まで指定してしまうと、開発会社が持っている別の解決策(たとえばボタンの移動より効果的な導線変更)を検討する余地を狭めてしまいます。困っている「事実」を伝え、解決の「方法」は専門家である開発会社の提案を一度聞く姿勢のほうが、結果的によい改善につながることが多くあります

これらは、悪意があってやってしまうというより、忙しさや焦りの中で無意識にやりがちな失敗です。送信前に一呼吸置いて、報告文がこれらのパターンに当てはまっていないかを確認するだけでも、開発会社との関係を無用にこじらせずに済みます。

無償対応と追加費用、どちらの範囲になるのか

品質への不満を伝えたとき、開発会社からの反応が「無償で対応します」なのか「追加費用がかかります」なのかは、多くの場合ここで揉めます。すべてのケースに当てはまる一律の基準はありませんが、判断の目安となる考え方は整理できます。

一般的な整理として、契約書や仕様書で合意されていた内容と異なる動作をしている場合は、契約不適合責任の対象として無償修正を求めやすい領域です。一方、契約時点の仕様書には明記されていなかった「もっとこうしてほしい」という要望に近いものは、追加開発として扱われ、費用が発生する可能性が高くなります。

ここで注意したいのは、「仕様書に明記されていないから開発会社の落ち度ではない」と一方的に判断すべきではないという点です。仕様書に細かい挙動まですべて書き切ることは実務上難しく、明記されていない部分について、開発会社が業務上常識的な範囲でどう作るべきだったかという解釈の余地は残ります。ここは白黒はっきり分かれる話ではなく、双方の認識をすり合わせる交渉が必要な領域だと理解しておくことが大切です。

保守契約の範囲を確認しておく

保守契約を結んでいる場合、契約書に「対応範囲」が明記されているはずです。品質への不満を伝える前に、次の点を確認しておくと、開発会社との会話がスムーズになります。

• 保守契約でカバーされているのは「不具合修正」のみか、「軽微な改修」も含むか
• 月あたりの対応工数に上限があるか(超過分は追加費用になるか)
• 対応の優先度・目安時間(SLA（サービス品質保証）)が定められているか

保守契約の範囲があいまいなまま運用されているケースは珍しくありません。今回の件を機に、契約書を読み直し、範囲があいまいな場合は次の契約更新のタイミングで明確化を求めることも、長期的な品質改善につながります。

「使いにくい」という設計・UXの不満を伝えるときの注意点

バグとは異なり、「使いにくい」という不満は、そもそも何が正解かの基準が存在しないケースが多く、伝え方にも工夫が必要です。

「デザインが古い」「もっと使いやすくしてほしい」——このような抽象的な要望だけを伝えると、開発会社側も何から手をつければよいか分からず、結果として何も変わらないまま終わってしまうことがあります。

使いやすさの不満を伝える際は、次のように具体化することをおすすめします。

1. 困っている業務・場面を特定する: 「入力画面全般」ではなく「受注登録の際の商品選択の画面」のように絞る
2. 具体的な操作の手数を示す: 「登録までに8クリック必要で、うち3クリックは省略できそうに見える」など
3. 理想の状態(あれば)を提示する: 「他のシステムではこうなっている」という参考例があれば添える
4. 業務への影響を数値化できる範囲で示す: 「1件あたり2分多くかかっており、月間200件処理しているので約7時間の差になる」など

すべてを厳密に数値化する必要はありませんが、「感覚的に使いにくい」ではなく「この手順のここが手間になっている」という具体性を持たせるだけで、開発会社側の受け止め方は変わります。UXに関する要望は無償修正の対象になりにくい性質上、追加開発として見積もりを取ったうえで、費用対効果を社内で判断するという流れになることが多い点も理解しておいてください。

「好み」と「業務上の支障」を切り分ける

使いやすさの議論でもっとも避けたいのは、個人の好みの話と、業務上の支障の話が混同されることです。「私は前のシステムの方が好きだった」という感想は、開発会社にとって対応のしようがない情報です。一方、「この画面構成だと入力ミスが月に何件か発生している」という話は、業務上の支障として扱える情報です。

自分の中で不満が「好み」なのか「支障」なのかを一度整理してから伝えることで、開発会社との会話が「好みの押し付け合い」にならずに済みます。

開発会社側の事情も理解しておく

交渉を有利に進めるためというより、無用な摩擦を避けるために知っておきたいのが、開発会社側にも品質への対応を難しくする事情がある場合があるという視点です。すべてのケースに当てはまるわけではありませんが、代表的な事情を知っておくと、相手の反応の背景を理解しやすくなります。

• 契約範囲・工数の制約: 保守契約の月間対応工数が決まっている場合、他の顧客対応や新規開発と並行して人員を割り振る必要があり、こちらが期待するスピードで対応できないことがあります
• 担当者の異動・退職: 開発を担当した技術者が既に在籍していない場合、他の技術者が改めてコードを読み解く時間が必要になり、初動が遅く感じられることがあります
• 原因の切り分けに時間がかかる複合的な不具合: 複数の機能が絡み合って発生する不具合は、報告を受けてすぐに原因が分かるとは限らず、調査自体に日数を要することがあります

こうした事情があるからといって、開発会社側の対応が正当化されるわけではありません。しかし、「なぜすぐに直らないのか」の背景を一定程度理解したうえで交渉に臨むと、感情的な行き違いを避けやすくなります。気になる場合は、「今回の不具合は、原因の特定にどれくらいの時間がかかりそうか」を率直に尋ね、見通しを共有してもらうことも有効です。見通しが分かるだけで、待たされている側の不安は大きく軽減されます。

話が平行線になったときの交渉の進め方

こちらが具体的な記録と報告文を用意しても、開発会社側の反応が芳しくない、あるいは「仕様通りです」の一点張りで話が進まないことがあります。ここでは、そうした状況での進め方を整理します。

• 担当者レベルでまとまらない場合は、書面でのやり取りに切り替える: 口頭でのやり取りは記録が残らず、後から「言った・言わない」になりやすいため、メールなど記録の残る形式に切り替えることを提案する
• 仕様書・契約書を根拠として提示する: 感情論ではなく、合意していた文書のどの部分と食い違っているかを具体的に示す
• 第三者的な基準があれば添える: 業界の一般的な水準や、契約時に交わした要件定義書の記述など、双方が確認できる客観的な材料を用意する
• 相手の窓口担当者では判断できない場合は、上位者へのエスカレーションを依頼する: 担当者個人の裁量を超える判断が必要な場合は、責任者を交えた話し合いを申し入れる

交渉が長引くほど、双方の感情的な摩擦も大きくなりがちです。定期的なミーティングの場で状況を整理し直す、あるいは一度メールで論点を書面化して双方の認識を揃え直すといった「仕切り直し」のタイミングを意識的に作ることも、こじれた交渉を前に進める有効な手段です。

それでも解決しない場合の選択肢

誠実に交渉を尽くしても平行線が続く場合、次のような選択肢を検討することになります。

• 契約書に定められた紛争解決の手続き(協議・調停条項など)を確認する
• 社内の決裁者・法務担当(いれば)に状況を共有し、組織として対応する
• 今後の契約更新や追加発注の可否を、品質への対応状況を材料に判断する

これらは最終手段であり、多くの場合はここまで至る前に、具体的な記録に基づいた冷静な報告と交渉で解決に向かいます。ただし、「最悪の場合はこういう選択肢もある」と自分の中で把握しておくだけでも、交渉に臨む際の心理的な余裕につながります。

同じ問題を再発させないための予防策

今回の品質への不満をきっかけに、同じような問題が今後も繰り返されないよう、体制面での予防策も検討しておくとよいでしょう。

• 検収の基準を事前に明文化しておく: 次回の開発・改修では、検収時に何を確認するかのチェックリストをあらかじめ用意し、開発会社とも共有しておく
• 定例ミーティングで品質の状況を定点観測する: 不具合報告の件数や傾向を、月次などの定例で確認する運用に組み込む
• 保守契約の対応範囲・SLAを見直す: 曖昧なままだった対応範囲や優先度の基準を、契約更新のタイミングで明確化する
• 社内の窓口を一本化する: 複数人がバラバラに開発会社へ不満を伝えると、開発会社側も優先順位をつけづらくなるため、報告の窓口を担当者一人に集約する
• 不具合・要望の記録を蓄積する場所を決めておく: メールやチャットに埋もれさせず、表計算ソフトや専用のツールで一覧化しておくと、次回以降「今回はどれくらい増えているか」をすぐに振り返れる
• 定期的な品質レビューの機会を設ける: 半期に一度など、不具合の傾向・対応状況を振り返る場を開発会社との定例に組み込んでおくと、問題が大きくなる前に芽を摘みやすくなる

これらの予防策は、どれも一度に完璧を目指す必要はありません。まずは「不具合・要望を記録する場所を決める」ことから始め、次の契約更新のタイミングで保守契約の内容を見直す、というように、段階的に体制を整えていくことで十分です。ひとりで情シスを担っている場合、すべてを完璧に運用しようとすると長続きしません。最低限、「何が起きたかを後から振り返れる状態」を作っておくことが、次に同じような不満を感じたときの負担を大きく減らしてくれます。

品質への不満は、一度伝えて終わりにするのではなく、その後の運用の中でどう再発を防ぐかまで含めて考えることで、開発会社との関係を悪化させずに改善へつなげやすくなります。

まとめ:感覚を「伝わる言葉」に翻訳する

システムの品質への不満は、放置すると「なんとなく我慢する」か「感情的にぶつける」かの二択になりがちです。しかし、不満を4つの軸に分解し、記録を残し、報告文の型に沿って伝えるという手順を踏むことで、開発会社にとっても対応しやすい、建設的な要望として届けることができます。

• 「品質が低い」を「バグ」「使いやすさ」「パフォーマンス」「安定性」の4軸に分解する
• 感覚ではなく、発生日時・手順・影響範囲を記録する
• 単発の報告と、傾向としての報告を使い分ける
• 無償対応と追加費用の境界線を理解したうえで交渉に臨む
• 平行線が続く場合は、書面化とエスカレーションで局面を変える

一度この型を身につけておけば、次に似たような不満を感じたときも、感情に振り回されずに、開発会社との建設的な対話にたどり着きやすくなります。検収の段階で不具合をどう見つけ、どう報告するかについては「検収で見るべきポイントと不具合対応の依頼方法」と併せて確認しておくと、リリース前後を通した品質管理の全体像がつかめます。また、交渉が難航した場合の進め方をより詳しく知りたい方は「トラブル時の交渉術:感情的にならずに解決する」で、感情的にならずに解決へ向かう具体的な手順を解説しています。