プロダクトを改善したり、新機能をリリースした後に、ユーザーからの問い合わせで発覚した、
「これ、テスト環境で触った時にサポートチームで事前に発見できたのでは？」と思ったことを明文化したいなと思った今日この頃。

SaaS系のビジネスでは、100点に近いプロダクトを作り上げるのではなく、まずは根幹となる部分ができたらひとまずリリースして、そこからユーザー（市場）に合わせて適宜改善をしていく手法を採るのが一般的かと思います。

なので、リリース後に「そっちの方がいいか」とか「やっぱりそこは欲しい機能だよね」みたいなことが、問い合わせ起因でわかることもあります。

ですが「ちょっとした考慮漏れ」だったり「リリース前の社内チェックで修正できたよね」と思うような軽微な不具合や動作不良があるのも事実。

こういったちょっとしたところでユーザーさんは離れていってしまうのだと思います。
「ちょっとしたこと」ができているのが当たり前（プラス評価にはなりづらい）で、それができていないと「このサービスはちょいちょい抜けてるんだよな・・」とマイナス評価になりがちです。

開発時点でそこまで見れていればいいのですが、開発の進め方やリソースによっては全てを網羅するのが難しいこともあると思います（実際に開発をしたことがないので想像でしかないのですが）。
だからこそ、社内でユーザーに一番近い立場にいる「CS（カスタマーサポート）」が、ユーザー目線でリリース前のプロダクトを触って、
ユーザーが使いづらくないか、想定外の動作をしないか、考慮が漏れていることはないか、をくまなくチェックできるべきだと考えます。

本来は、リリース直前のテストの段階よりも前、仕様の策定時点からサポート部隊が絡む（開発により深く関わる）ことが理想だと思うのですが、
サポート側のリソースや、開発側の知識、そして何より「ユーザー目線に立ったテストを行える環境構築」が必要になります。

で、ぼくのチームはどうかというと、残念ながらまだまだそのステージには到達していないのが現状です。
テスト段階で見る際も、メンバーによって見るポイントが全然違くて（それはそれで良いことだと思いますが）、
見落としがあることも多く、リリース後の問い合わせで「仕様の考慮漏れ」が発覚することもあったりします。

ですから、まずはサポートチームに足りてない視点、
「うちにユーザーさんだとこういう使い方をすると思うけど、ちゃんと動作するかな」とか「直接的には関係しないけど、あの機能を使ったときに新機能はうまくハマるかな」といった『チェックポイント』を見つけるところから始めてみようと思います。

まずは、実際にリリースした機能で考慮漏れや、想定外の動作をした時の問い合わせをまとめておいて、
自分達にどういった視点が足りなかったのか、ユーザーさんはどういう使い方をしたのかを体系化していけば、次に繋がると思ってます。