ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

サポートの経験が、開発者・QA・プロダクトマネージャーとしての自分に与えた影響

先日、JaSST’21 Tokyoの「カスタマーサポートエンジニアの品質貢献」というパネルディスカッションに登壇したのですが、この準備の過程で、他のパネラーの方々とお話をしたり、話す内容を考える中で、今の自分自身、サポートの経験がものすごく役に立っているなと感じたので、その辺の話を書きたいと思います。


自分のサポート経験

boardという見積書・請求書などの書類を中心とした、中小企業向けの受発注管理のSaaSをやっていて、そのサポートの話です。

僕自身は、会社の経営者ですが、開発系のエンジニアで、boardのメイン開発者でもあります。

boardは、元々僕の1人プロジェクトからスタートして、有料契約社数が1300社くらいまで(数年前まで)は僕1人でサポートまでやっていたので、開発をしつつ、3〜4年はがっつりサポートまでやったという状況です。

現在は、CSチームが3人いて、基本的には手が離れていますが、APIやSAMLなどの技術寄りのお問い合わせは今でも僕が対応していたり、CSメンバーで対応できないような内容の場合はエスカレーションとして僕に上がってくるので、今でも、日常的にサポートには関わっています。

また、基本的には、毎日その日の問い合わせはすべて目を通していて、それをもとに、CSチームに改善のフィードバックをしたり、要望は、社内で管理しているリストに振り分けたりしています。

このように、開発系の仕事をメインとしつつ、がっつりサポートをやっていて、かつ、プロダクトオーナーでもあるので、このサポートの経験が、仕様・画面・テストケースを考える際などに非常に役に立っているので、その辺の話を書きたいと思います。


サポートが持っている引き出し・視点

同じ機能・画面に対して、こちらが想像をしていなかったような捉え方・解釈・意見などがたくさんあって、サポートは、それらの多様な視点・意見を目にすることになります。

普段、仕様や画面を考えるとき、様々な利用シーンを想像して考えていくと思うのですが、それでも、どうしても自分の視点が中心になるし、この幅を広げていくというのは、とても大変だなと思っています。

テストケースを考えるときも同様で、「こういう使われ方しそうだな」という感じで、自分の視点以外をたくさん持っていると、かなり役に立ちます。

サポートの経験は、この引き出しをとても増やしてくれました。

もちろん、仕様としてそれらを全部考慮することはできないし、最終的には、自分が良いと思うものを選択していくわけですが、それ以外の視点・意見を想定した上での選択と、そもそも想定できていない状況での選択では、1つ1つの判断の精度・品質が変わってくるかなと思っています。


ユーザさんの躓きポイント

多くの場合、何かしら困ってサポートに問い合わせをしてくるので、サポートをやっていると、躓きやすいポイントが見えてくるようになります。

パネルディスカッションの中で、「新機能の画面を見た瞬間、”これは問い合わせ増えそう”と思ったことありますよね」という話をしたんですけど、この感覚です。

開発をする時、僕はUIだけ先に完成度を上げていくことが多いのですが、その過程の中で、過去の問い合わせなどを踏まえて、実際のユーザさんを想像しながら操作をしてみて、躓きそうなポイントを探していきます。

がっつりサポートをやっていると、この時に、具体的なイメージをもってシミュレーションすることができて、その結果、開発の早い段階から、それに対する改善をしていくことができます。

個人的には、このアプローチはとても役に立っていて、欠かせないものになっています。

開発とサポートが分かれていることが一般的だと思うので、企画や開発初期段階で、一度サポートにレビューしてもらって、意見をもらうというのは結構有益なんじゃないかなと思っています。


問い合わせを減らすための改善

これはかなり意識的にやっています。

うちの会社は、自分を入れて10人の会社で、会社の規模をどんどん大きくしていくつもりはないので、問い合わせの増加ペースはなるべく抑えたいと思っています。

ただ、当然ながら困っていることは問い合わせしやすい必要があるので、簡単な問い合わせを減らしていきたいという感じです。

日々の問い合わせを見てる中で、「この問い合わせ、まあまあ多いけど、一言説明したりヘルプを見てもらえれば解決する内容で、CSチームのリソースを使うのはもったいないよなあ」と感じるようなものを、システム側の改善で減らして行くような取り組みをしています。

たとえば、画面上の項目名などの文言を少し変更しただけで、問い合わせがほとんどなくなったというケースがあったりします。

また、ハマりそうなシチュエーションで特定の操作を行った直後だけ、ガイドやヘルプへの誘導のメッセージを表示したところ、それに関連する問い合わせが激減したりしました。

ちょっとしたことが多いんですけど、サポートをやっていなければ、対応していなかったであろうこと、気づかなかったことなども結構多いです。

 

こういう改善は、ユーザさん側のメリットはもちろん、経営者かつCSチームの責任者として、CSチームがより本質的なサポートに注力して欲しいなという思いもあって、継続的に続けています。


業務理解を深める

boardは、受発注業務を扱うSaaSなのですが、この領域は、業種・業界・会社規模によって、商習慣や業務のやり方などが非常に多様で、僕自身、boardを6年半やっていますが、今でも、「へー」って思うような話があったりします。

boardは、マスをターゲットにはしていなくて、どちらかというと、ターゲットを絞って、「フィットする会社に90点以上のサービスを」というスタンスでやっています。

それでも、自分の会社だけ、自分の経験だけで仕様を考えていくと非常に狭くなってしまうので、業務知識・業務のやり方などの引き出しを増やしていくことは、とても大事だと思っています。

サポートは、そういった情報の宝庫なんですよね。

一般的に、サポートから開発側へのフィードバックは、バグや要望などが多いと思うんですけど、そういうわかりやすいフィードバックだけだと本当にもったいなくて、業務理解を深めたり、引き出しを増やすことで、想像・共感できる範囲も広がるので、アウトプットの品質に、とてもプラスになるんじゃないかなと思っています。


開発する内容のバランス

これは、パネルディスカッションの後の質問でも似たような質問を頂いたのですが、企画・開発側とサポート側だと、「開発したいもの」の視点が異なるのかなと思っています。

すごくざっくり言うと、サポートの場合、まったく新しい新機能よりも、小さな地味な改善、困っているユーザさんが減るような機能追加を期待するような気がします。

プロダクトの成長にはどちらも必要なことだと思うので、そのバランスをうまく取っていくのが、プロダクトマネージャーの仕事なのかなと思っていて、自分自身、サポート側の気持ちもとてもよくわかるので、うまくバランスを取るように判断しています。


“ソフトウェアテスト”に対する貢献

最初にJaSSTの登壇の依頼を頂いた際、JaSSTというソフトウェアテストのイベントだったので、「サポートの品質貢献」というテーマで話ができるか、実はちょっと悩んだんですよね。

「品質」が指すものは立場によって様々だと思っていて、エンジニアやQA視点では、バグとか、そういうシステム的な要素が強いかなと思います。

一方、ユーザさんから見ると、そのシステムの使い勝手・わかりやすさ・パフォーマンスなどを含め、もうちょっと広義の意味になるかなと思います。

僕がこれまで書いた内容は、どちらかというと、後者の視点での品質になります。

前者の視点の場合、サポートが、単体レベルの品質に貢献するということはあまりなさそうな気はします。一方、「イレギュラーな使われ方をした時にどうなるか」というのは確認しておきたいので、こういうテストケースの作成には、サポートはすごく貢献できそうな気がします。


まとめ

個人的には、サポートの経験は、企画・開発・QAにおいて、ものすごくプラスになっていて、もはや、サポートをやったことがなかった時に、どうやって考えていたのかわからないくらい、非常に重要な情報源になっています。

たまに「え、今でもサポート全部目を通しているの!?」って聞かれるんですけど、むしろ、それ無しで良いものを作れるイメージが湧かないくらい重要なんですよね。あと、直接問い合わせを見ることで、その「温度感」を感じることもとても重要だと思っています。

うちの場合、非常に小さな会社だし、僕が全部を見ているという特殊な状況もあって、結果的にこうなっているというかたちですが、普通は、チームは分かれているだろうし、開発・QA側が、がっつりサポートに入るということはなかなか難しいのかなとは思っています。

ただ、サポートの中には有益な情報も多いので、ぜひこれをうまく活用してプロダクトを改善していくような取り組みが増えてくると良いなと思います。

 

うちの会社は、基本的に「10人までを目安」と考えていて、現在10人なので採用の募集は出していないのですが、いずれ、良い縁があれば、QA専任メンバーは1人欲しいなと思っているので、QAエンジニアの方で、こんなスタンスでやっていくのに興味がある方がいましたら、ぜひTwitterや会社のお問い合わせの方にご連絡ください。