「アプリが遅い」と書かれる前に──声にならない違和感にどう気づくか

はじめに：たったひとことに、ドキッとする

ある日、ふと目にしたSNSの投稿。
「最近このアプリ、ちょっと重いよね」──ただそれだけの、短いひとこと。

誰かを強く非難しているわけでもないし、明確なクレームというわけでもない。
でも、その投稿を見た瞬間、どこか胸の奥がザワッとするような、妙な焦りを感じることがあります。

「もっと早く気づけていれば」
「今この人が感じている不満、どこかで拾えなかっただろうか」
そんな思いが後からじわじわと湧いてくるんです。

---

実は私たち自身も、これまでに何度も同じような経験をしてきました。

たとえばあるとき、CSチームが
「問い合わせの中で、“最近少し動きが重く感じる”って言われたことがあります」と共有してくれたことがありました。

そのとき、開発チームではモニタリングも正常。再現もできず、「うーん、気のせいかもね」とそのまま流れてしまいました。
ところが、後になって特定の旧端末やネットワーク条件下でアニメーションの処理がボトルネックになっていたことがわかり、ようやく重さの原因に辿り着いたのです。

---

「もっと早く手を打てたかもしれない」──
でも、なぜそのとき私たちは“気づけなかった”のでしょうか。

今回は、そんなモヤモヤを出発点に、
声になる前の“不満の兆し”に、どうすれば気づけるのかというテーマを一緒に探ってみたいと思います。

不満は“突然”ではなく、“じわじわと”積もるもの

「アプリが遅い」と言われたとき、私たちはつい「いつから？」と聞きたくなります。
でも実際には、“ある日を境に突然遅くなった”わけではないケースがほとんどです。

不満は、ユーザーの中でじわじわと積もっていきます。

最初は「まぁ、ちょっと遅いかも？」くらいの感覚かもしれません。
でも、それが何度か続くと「前より重くなった気がするな」となり、やがて「ちょっとイライラする」に変わっていきます。
そして最後に、SNSやレビューなど、“表に出る形”で不満が現れるわけです。

ここで難しいのは、多くの人が声を上げないまま離脱してしまうことです。

• 「別に致命的じゃないし、わざわざ言うほどでもない」
• 「たまたまだろう」
• 「他に選択肢があるから、そっちを使おう」

こうして、ユーザーの中で“静かな違和感”が続き、ある日ふっと離れていってしまう。
声に出してくれた人は、むしろ貴重な存在かもしれません。

---

だからこそ、表に出る前の“兆し”をどう拾えるかが大切なんだと思います。
「最近ちょっと重いかも…」と、誰かが思った瞬間に、その違和感を誰かが拾えるか。
あるいは、拾っても、ちゃんと伝わる土壌があるか。

そこには、単なる技術の話だけでなく、組織やチームの関係性も深く関わっている気がしています。

それぞれの立場で、何が見えていて、何が見えていなかったか

「もっと早く気づけなかったのか」──そう思ったとき、つい“誰が見落としたのか”を探したくなります。
でも実際には、多くの場合で誰かが何かしらの違和感には気づいていたりします。
それがチームや組織の中で、届かなかった・拾われなかった・優先されなかっただけだったりするんです。

ここでは、それぞれの立場がどんな役割で、どういう視点を持っていて、どういうすれ違いが起きがちなのかを整理してみます。

🧑‍💼 カスタマーサポート（CS）

お客様からのお問い合わせや不満を最前線で受け取るチームです。
一人ひとりの声に丁寧に対応しているからこそ、「最近ちょっと動作が重いみたいです」というような“軽めの違和感”にもいち早く気づくことがあります。

でも、こうした情報は「定量的に根拠があるわけではない」ために、
開発チームや他部門には軽く流されてしまうことも少なくありません。

🗯 心の声：

「うまく伝えられなかったかもな…でも、言ったよね？ちゃんと。」
「こういう感覚的な声って、どこまで拾ってもらえるんだろう…」

🤝 営業・カスタマーサクセス

日常的にクライアントとコミュニケーションをとる立場です。
定例MTGや提案の場で、直接ユーザーの肌感や小さな不満を拾うことができます。

ただし、「正式な要望」ではなく「世間話で出た不満」のようなニュアンスの場合、
それがプロダクト側に届かずに終わってしまうことがよくあります。

🗯 心の声：

「これ、報告した方がいいかな…いや、ただの雑談っぽかったしな」
「どうせ“もっと詳しく”って言われるやつだよね、きっと」

🧑‍💻 開発者（エンジニア）

アプリの開発・保守を担う技術者です。
不具合やパフォーマンスの問題があれば、調査・修正も行います。
ただ、基本的には数値（モニタリング結果）や再現性のある事象に基づいて動くことが多いため、「体感が遅い気がする」といった曖昧なフィードバックは、扱いづらいというのが本音だったりもします。

🗯 心の声：

「いや、データ見ても正常なんだよな……」
「“気がする”って、どう対処したらいいの……こっちは再現しないし……」
「これより優先度高いタスク、他にも山積みなんだけど……」

🧑‍💼 エンジニアリングマネージャー（EM）

開発チームの進行をマネジメントする役割です。
スプリントの進捗管理や、技術的な意思決定、人員のリソース配分を担います。

PdMやCS、経営層から寄せられる「違和感」情報をどう扱うかは、EMにとって判断の分かれどころです。
現場の開発者から「再現できません」と言われれば優先度は下がりやすい。
一方で、後から問題が表面化すれば「なぜ対応しなかったのか」と問われる立場でもあります。

🗯 心の声：

「“体感が遅い”って、どこまで本気で向き合うべきなんだろう？」
「チームも余裕ないし、もっと明確な根拠がほしい……」
「でも、あとで経営層から言われたら“なんで動かなかった”って言われるよな……」

📈 プロダクトマネージャー（PdM）

プロダクトの方向性や優先順位を決める立場です。
どの機能を作るか・改善するかを決めるために、CS、開発、営業、マーケなど複数の声を調整します。
「ちょっと遅いみたい」という曖昧なフィードバックをどう扱うかは、判断が難しいところです。

• 定量的なデータがない
• KPIに直結しない
• 影響範囲が不明

そうなると、「いったん様子を見ようか」と見送られやすい領域でもあります。

🗯 心の声：

「“ちょっと重いかも”って、どのくらいの問題なんだろう……？」
「数値がないと経営にも説明しにくいし、今は別の改善が詰まってるし……」
「でも、あとで取り返しのつかない感じになったらどうしよう……」

🧑‍💼 経営者

会社全体の方針と責任を担う立場です。
直接ユーザーと接することは少なくても、SNSでの声やネガティブなレビューには敏感です。
社外で話題になってから「これ、うち大丈夫なの？」と気づくこともあります。

🗯 心の声：

「“遅い”って言われてるの、何で誰も気づかなかったの？」
「表に出る前に気づけなかったのか……いや、でも誰か違和感持ってたんじゃないの？」

実は“気づけなかった”問題、他にもありませんか？

「アプリが遅い」と書かれる前に気づけなかった──
そういう出来事って、思い返すと他にも似た構造のまま見過ごしていたケースがいくつかあるな、と私たちは感じています。

たとえば、こんなシーンに心当たりはありませんか？

---

📋 お問い合わせフォームの完了率が低い

「送信ボタンが押されていない」だけなので、表面上は問題が見えにくい。
でも実際は、フォームが長すぎる・入力が面倒・途中で離脱──
声にならない“不満”が、静かに蓄積している状態です。

🗯 見逃しがちな兆し：
CVRはそれほど変わらない。でもよく見ると、途中まで入力して離脱してる人が多い。
「何か言いたそうだったけど、結局送られてこなかった」お問い合わせが増えている。

🛠 社内ツールの“微妙な使いづらさ”

誰も文句は言っていない。でも、なんとなく操作が複雑だったり、読み込みが重かったり。
ユーザー（＝社内の人）が“我慢して使っている”ことで、表面化しない問題も多くあります。

🗯 見逃しがちな兆し：
定例MTGで「ちょっと使いづらいですね…」という声が出ても、その場で終わってしまう。
新人のオンボーディング時に、操作でつまずく場面が増えている。

こうして並べてみると、どれも「機能はしているけど、体験がじわじわ劣化している」という構造が共通しています。

• 不満は声に出されにくい
• でも積もると、いつか“離脱”や“ネガティブな反応”という形で現れる
• 気づいたときには、すでに手遅れになりかけていることもある

私たちも、こういった兆しに気づけなかったことが何度もあります。
「言ってくれたら対応したのに…」と思う一方で、

“言ってもらえる仕組みや関係性があったか？”と立ち返ることも大事なんじゃないか、と感じるようになりました。

私たちがやってみた、“前兆”に気づくための工夫

「どうすれば、もっと早く気づけたんだろう？」
私たちもそんな問いを何度も繰り返してきました。

その中で、あくまで一例ではありますが、「完全ではないけれど、兆しに気づきやすくなった」工夫をご紹介します。
どれもまだ試行錯誤の途中ですが、「こんなアプローチもあるかも」と思っていただけたらうれしいです。

📊 パフォーマンス指標を“数値化して可視化する”

ユーザーの「ちょっと遅い」という感覚は、数値で捉えにくい…とはいえ、まったく測れないわけではありません。

たとえば：

• LCP（Largest Contentful Paint）：画面の主な内容が表示されるまでの時間
• FID（First Input Delay）：ユーザーの操作に対する応答の早さ
• TTFB（Time to First Byte）：最初のレスポンスが返るまでの時間

これらを継続的にウォッチし、「あれ、なんか最近悪化してない？」という変化を拾いやすくしていきました。

補足： こうした指標をGraphで追っておくだけでも、“感覚”から“共有できる事実”に近づけます。

🔄 リリース前後での自動パフォーマンス比較

ある時期、「特定のUIコンポーネントを変更したら“重くなった”と言われた」という出来事がありました。
そこで導入したのが、リリースビルドを Lighthouse 等で自動計測し、前回と比較する仕組み。

• 定期的にスコアを保存
• 大きな劣化があればSlackで通知

という運用に変えたことで、「気づいたときにはもう遅かった」を減らせるようになりました。

💬 違和感だけでも拾えるチャネルをつくる

社内Slackに「#ux-feedback」というチャンネルを作ったことがあります。
そこでは、

• 「この画面、地味に毎回読み込みに時間かかる気がする」
• 「なんか最近クリックしたときの反応が遅く感じる」

といった定量化されていないなんとなくの違和感も投稿してOKという運用に。

最初は投稿もまばらでしたが、次第に文化が根づき、「実はこのフィードバック、○○社からも似たこと言われてました」と他部門でつながることも増えていきました。

🧭 “ちゃんと声にしてもいいんだ”と思える空気をつくる

最後に大事なのは、仕組み以上に空気感かもしれません。

• 「こんなこと言っても意味ないかも」と思われないこと
• 「ふわっとした違和感」でも受け止めてもらえること
• 「たしかに！」と誰かが拾ってくれる安心感

こうした文化があることで、兆しはようやく言葉として現れてくるように思います。

---

もちろん、これらはあくまで一例です。
すべてをいきなり取り入れるのは難しいと思いますし、最適解とは限りません。
ただ、「声になる前の不満」に対してアンテナを立てる仕掛けを持っておくことは、どんなチームにもきっと役立つと感じています。

まとめ：技術と組織で「兆し」に気づけるチームへ

SNSで「このアプリ、最近ちょっと重いよね」と書かれる。
その前に、どこかで誰かが違和感を抱いていたはずなのに、それが届かなかった。
そんな経験、私たちも何度もしてきました。

---

この問題を考えるとき、よく「関係性」や「組織文化」の話になります。
たしかにそれはとても大事です。
でも、それだけでは足りない場面もあります。

体感的な「遅さ」や「使いにくさ」は、そもそも気づきにくい。
気づいたとしても、共有しづらく、判断しづらい。

この3つの“づらい”をどう減らしていけるか。
そこに向き合うためには、文化的な土壌づくりと、技術的な仕組みの両輪が必要だと感じています。

技術的な仕組みとしてできることの例

• パフォーマンス指標（LCP, FID など）の継続的モニタリングと可視化
• リリースごとの自動パフォーマンステスト（Lighthouse等）によるデグレ検知
• 分析ツールでのユーザー行動ログ可視化（離脱率、途中操作の偏りなど）
• “軽い違和感”でも記録できるフィードバックチャネルの整備（Slack, GitHub など）

こうした仕組みがあることで、「なんとなく」の違和感を可視化・蓄積・共有しやすくなります。

組織的な側面として意識したいこと

• 曖昧な違和感でも「発信していい空気」があること
• 拾った声を“なかったことにしない”信頼感
• 技術チームとCS/営業など非エンジニアとの間の翻訳を意識したやり取り

つまり、仕組みで兆しを拾い、関係性で兆しを育てる。この両方が揃って初めて、言われる前に気づける組織が少しずつ形になるのかもしれません。

私たちもまだ、試行錯誤の途中です。
でも、「気づけなかったこと」をただ後悔するのではなく、「どうすれば気づけるようになるか？」を問い続けることが、何よりも大事だと思っています。

💡補足：こんな取り組み、私たちもご支援しています

この記事では「声になる前の違和感にどう気づくか？」というテーマを、現場目線で掘り下げてきました。
こうした課題は、プロダクトの成長に伴って誰もが直面するものだと感じています。

弊社では、こうした「兆しを拾えるチーム・しくみ・文化」づくりを、技術面・組織面の両側からご支援しています。

🛠 技術的なサポートの例

• パフォーマンス劣化の自動検知・可視化の仕組み構築
• ユーザー行動ログの収集・分析設計
• Slack・Notion・BIツール等とのフィードバック連携基盤づくり

👥 組織面でのご支援

• チーム内の“違和感”を拾えるSlack運用・仕掛け作り
• CS/開発/営業をつなぐ定例の設計支援
• PdM/EM向けの「兆し判断フレーム」の設計や壁打ち

技術と組織のあいだをつなぎながら、「気づけなかった」を減らし、「気づけるようにする」ための実践支援をしています。

ご興味があれば、お気軽にお問い合わせください。
話してみて「まだ早いかも」と思ったら、それでも全然大丈夫です。お互いに健やかなプロダクトを育てていけるよう、一緒に考えるところからご一緒できたら嬉しいです。