「あらゆる人を負の体験から解放し、可能性を引き出す」をミッションに、カスタマーサポート（CS）領域に特化したエンタープライズ企業向けSaaS事業を展開する株式会社RightTouchは、プレイドからスピンオフして始まったBtoB SaaSスタートアップです。
昨年、RightTouchでは、1つ目のプロダクトであるWebサポートプラットフォーム「RightSupport by KARTE（以後、RightSupport）」をリリースした際の中心機能であったサポートウィジェットに蓄積していた技術的負債を解消するために、サポートアクションの開発プロジェクトを推進しました。
エンジニアたちが主体的に動き、現場主導で行われた開発の裏側について、取締役CTOの籔悠一（yabu）と、プロダクトエンジニアの追木 智明（ikki）の2人に話を聞きました。
顧客の要望に応えるなかで蓄積していったプロダクトの負債
──最初にプロダクトをリリースした後のRightSupportが抱えていた課題について教えてください。
yabu：
RightSupportは、エンドユーザーによる自己解決を促進するために、困りごとが生じたタイミングでFAQを表示できれば、という考えのもと、ポップアップ形式で情報を表示する「サポートウィジェット」という機能を中心にリリースしました。
この機能は、企業がノーコードで配信を設定でき、エンドユーザーがサポートウィジェットをクリックすると、お困りごとの自己解決ができるというものです。リリースからしばらくの期間はサポートウィジェットだけで問題なかったのですが、少しずつ課題が生まれていきました。
ikki：
お客様からの要望が段々と多様になっていったんですよね。たとえば、サポートウィジェットに表示する文言をカスタマイズしたい、Webサイト内のボタンをクリックするとサポートウィジェットが表示されるようにしたい、表示する内容を分岐させたい、Webサイト内にFAQを埋め込みたい、など。お客様の要望にはできるだけ応えられるようにと、サポートウィジェットに仕様を追加して開発を進めていたのですが、徐々に限界が見えてきていました。
yabu：
サポートウィジェットをWebサイトに埋め込むとなったときは、「はたして、それはウィジェットなのか？」という疑問が生まれて。その他の要望と合わせて、実現するためにサポートウィジェットを改良していきましたが、次第に技術的負債が溜まっていきました。
ikki：
技術的負債以外にも課題がありましたね。当時、エンドユーザー向けに配信するシステムのフレームワークは、コンパクトさを重視してプレイドでも使用していたものを踏襲していました。一方、管理画面では別のフレームワークを活用していたので、そこの同期が難しい状態でした。たとえば、なにか新しい機能を実装した際に、お客様の画面には反映されているけれど、プレビューの画面には反映されない、といったことが起きていたんです。
yabu：
技術的負債や仕様の負債なども溜まっていって、このままではいけないと社内で話になることも増えました。サポートウィジェットを軸に体験をつくるのではなく、体験をつくるために必要なコンポーネントを用意し、組み合わせられるようにしたほうがいいのでは、といった議論を重ねて。サポートウィジェットのまま改善していくことは止めて、工数をかけてでも理想のWebサポートを実現するための開発に着手しました。
チームで進めたサポートアクションの設計と開発
──理想とするWebサポートの実現に向けて、まずどんなことから取り組んだんですか？
yabu：
サポートウィジェットと比較して、より汎用的で将来的な拡張性を持った機能を開発しようと思い、チームで仕様を描きました。ただ、最初は理想を描きがちなので、キャンパス上でコンポーネントとコンポーネントをつないでアクションを構築していくものをつくろう、とGUIがっつりな仕様を描いていました。そうしたら、社内のエンジニアから「もっとシンプルでもいいのでは？」と海外の事例と合わせて提案されてしまって（笑）
ikki：
yabuさんがビジョナリーに理想を語りつつ、周りのメンバーが現実的な解を見つけていくのが、RightTouchのエンジニアリングの特徴でもありますね。自分はそのなかで「どうしたらバランスがとれるだろうか？」と考えながら、仕様の設計に参加していました。
タイプが異なるエンジニアの恊働についてはこちらの記事もどうぞ。
yabu：
メンバーとの議論を経て、改めてタスクをひとつずつ設定していけば完了するような、お客様にとって使いやすいUIになるように仕様を検討。将来性も考慮して、コンポーネントを組み合わせて、さまざまなことを実現可能にしていけるモデルを設計しました。
──仕様設計の次は何に着手を？
yabu：
まずは、プロトタイプをつくりましたね。サポートアクションの開発をするまではプロダクトの中での開発が中心でしたが、大型の開発をするために「サンドボックス」をつくって、実験をしていきました。実験と議論を繰り返しながら、モデルの型を固めていきました。
モデルの形を定義する力を高めるために、TypeScriptの型をクイズ形式で勉強するサービスをチームみんなでやろう、という話になったんです。そしたら次の週には、nariさんが「自分がわからない姿を見せるのが嫌だから」ってひとりで全部解いてしまった、なんてこともありました（笑）結局、Devメンバーが集まるランチミーティングのときに、わいわいみんなで挑戦しました。
──なんだか楽しそうな雰囲気ですね（笑）
yabu：
大変なプロジェクトではありますが、シリアスな雰囲気にはならなかったですね。実験を重ねたおかげで、仕様も決まり、柔軟なモデルもできたので、あとはチーム全員でサポートアクションを実装していきました。実際に形になった機能を触ったときは、純粋に楽しかったですね。
ある程度、実装が進んだ後は、社内でお披露目をして、しっかりとドッグフーディングを実施。おかげで、開発チームだけでは気付けない問題点も見つけることができて、修正を進めて完成度を高めていきました。
顧客の協力のもと、サポートアクションへの移行を進める
──サポートアクションの開発が完了した後、移行をどのように進めていったのでしょうか？
yabu：
開発がおおよそ終わったのが2023年の年末、2024年1月にサポートアクションをリリース。このタイミングで、RightTouchでテックリードとして複数のプロダクトを横断的に見ているnariさんが異動のためチームから抜けて、サポートアクションへの移行をikkiさんがリードすることになったんですよね。
ikki：
そうなんです。「やります！」って言ったはいいものの、内心は何からやればいいんだろうと不安でしたね（笑）まずは現状把握から進めて、設定されていたサポートウィジェットが全部でどれだけあるのか、どんなお客様がどのようにサポートウィジェットを使用中なのか、などを確認していきました。
移行には、カスタマーサクセスの協力が必須だったので、4名のカスタマーサクセスメンバーと毎週定例会議を実施して、それぞれのお客様の移行状況を確認するようにしました。お客様は「そもそもサポートアクションとはなにか？」ということがわからないので、頭出しをしながら移行を進めていきました。
yabu：
サポートアクションの開発を進めている際に、どうやって移行をしていくかについても練らないとな、とは考えていたんですよね。たとえば、サポートウィジェットをサポートアクションに変換するロジックを組んで、自動で切り替えるシステムをつくれないか、など。開発し始めたときには考えていたものの、開発自体にリソースがかかってなかなか移行については追いついていない状況だったんですよね。
ikki：結局、システマチックに一括で移行するのは、各お客様の状況に合わせて対応するのが難しかったため、見送りにしましたね。当時は、お客様の数もまだ60〜70社ほどだったので、人力での移行を進めることにしました。
当時のサポートウィジェットの数は、全体で合計1500ほど。お客様ごとに偏りがあって、積極的に活用しているお客様であれば100種以上のサポートウィジェットを設定してました。このサポートウィジェットは将来的にコードをなくすことが目標なので、ひとつでもサポートウィジェットを残すわけにはいきません。すべてのサポートウィジェットを移行する必要がありました。
──お客様への働きかけはどう進めていったのでしょうか？
ikki：
「これまでのサポートウィジェットよりも、サポートアクションのほうが圧倒的にいろんなことをできるんです！」、ということを丁寧に伝えていきました。たとえば、説明会を開催して、お客様のやりたいことはサポートアクションでさらに実現できると伝えました。
「できることが広がるのなら」と、喜んで移行に対応してくれたお客様もいらっしゃいましたね。協力してくださるお客様が多くて、これはカスタマーサクセスのメンバーが日頃から関係を構築できていたからこそ実現できたことだと思います。
移行されて減少したサポートウィジェットの個数を可視化して、サポートアクションのほうが個数が大きくなったタイミングでSlackに共有して「超えました！」と投稿したり、移行状況をグラフ化したりして、お祭り感を出すようにしました。
yabu：
新しいメンバーにサポートアクションへの移行を担当してもらって、新機能のオンボーディングを兼ねるなど、メンバーの巻き込みはいろいろ工夫しながらしましたね。
ikki：
ほかには、サポートアクションの機能をつかって、サポートウィジェットの機能がクローズするというお知らせを出すなどの活用もしました。思い浮かぶことを試しながら、お祭り的に進めていきました。
移行は2024年2月からスタートし、ほとんどの移行は4月には完了。一部、動作確認が必要なお客様がいたため、そこから2ヶ月ほどかかって、6月ごろに移行完了。この移行は、RightTouchが経験した移行プロジェクトとしては相当に大きいものだったので、やりきれたことで自信につながりました。
「全員プロダクト担当」だから素早く実現できた新機能への移行
──サポートアクションに移行してみて、感触はどうですか？
yabu：
サポートウィジェットのときに複雑になりすぎて実装できなかった機能を、サポートアクションに切り替えることで数多く追加できるようになりました。以前は、既存機能との兼ね合いを考えながら新機能を開発しなければなりませんでしたが、サポートアクションではコンポーネント間の結合度が低いため、新機能の開発に集中しやすくなりました。これからもさまざまなコンポーネントを追加していく予定なので、さらにサポートアクションを進化させられるのは楽しみですね。
開発以外のことも含めると、今回のサポートアクションの開発と移行は、会社にとって大きな変更です。これを実行できたのは、自分以外の経営層も今回の件に対して「本質的に価値のある移行であり、コストをかける必要がある」と理解し、意思決定したことが良かった。Devチームに対する信頼もあり、「全員プロダクト担当」というMind（RightTouchのValue）のもと、部署をまたいでワンチームで動けたことで、スピード感をもって話を進めることができました。
ikki：
新旧の機能が混在していると新機能の価値がすべてのお客様に届かず薄れてしまうので、この移行はなんとしてもやり切らなければならない、という強い意志があったことも、推進の後押しになったと思います。技術的負債や仕様の負債を、いつ解消するのかというタイミングは常に難しい問題です。今回はあえて工数を投じてでも思い切って作り直す決断をしたことで、RightSupportで実現できることの幅が大きく広がったと感じています。
共に「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションの実現に挑むプロダクトエンジニアを募集しています！
関心のある方は、下記の募集をぜひご覧ください
https://righttouch.co.jp/jobs/engineer
RightTouchの採用情報はこちらから
https://righttouch.co.jp/recruitment
