Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

RightTouchは、プレイドからスピンオフしたスタートアップで、カスタマーサポート領域向けのWebサポートプラットフォーム「<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>（以後、RightSupport）」「<a href="https://rightconnect.karte.io/">RightConnect by KARTE</a>（以後、RightConnect）」などを提供しています。
カスタマーサポート領域の抜本的変革に挑んでいるRightTouchは、複数プロダクトを提供するコンパウンドスタートアップとして、常に新たな事業、プロダクトの開発に向けて動いています。今回の記事では、α版がリリース済みであり、今後正式版のリリースを予定するフェーズのプロダクトに焦点を当てます。
約1ヶ月という超短期間で一つのプロダクト開発に携わったという新規事業開発の田中(akky)、エンジニアの齋藤(nari)、赤木(giinyo)の3人にインタビュー。“RightTouch流”コンパウンド戦略、そしてビジネスサイドと開発サイドとの圧倒的な信頼関係をもとに、高速でプロダクト開発をどのように実現したのか話を聞きました。
<blockquote>
＜プロフィール＞ 
田中 彬寛／akky（たなか あきひろ） 
九州大学工学部機械航空工学科卒業後、2017年にリクルートホールディングス入社。プロダクトグロースや事業戦略策定／実行、全社横断ナレッジ統括などに従事。 2022年にRightTouch入社、セールス及びカスタマーサクセスのリード／BizDevを担当。好きな言葉は「ロマンとそろばん」。趣味はサウナ、ポーカー、アニメ。
</blockquote>
<blockquote>
齋藤 成之／nari（さいとう なりゆき） 
東京大学大学院で博士課程修了後、2020年に日立製作所に入社。研究開発部門で業務システム開発に関する業務に従事。2021年10月プレイドに入社し、現在はRightTouchのテックリードとして開発に携わる。
</blockquote>
<blockquote>
赤木 勇統／giinyo (あかぎ ゆうと) 
大阪大学大学院を修了後はPhotosynthに新卒入社。主にAkerun入退室管理システムの開発に従事。新たな挑戦がしたいという想いがあり、2024年1月にRightTouchへ転職。RightTouchでは、RightSupportの開発担当を経て、新規プロダクトチームへジョイン。 
</blockquote>
<img src="https://ik.imagekit.io/righttouch/dfaffa20-3aab-4bd7-9f38-de0af07fdca8/DSC00850.jpg" alt="DSC00850.jpg"><center>左から田中（akky）、赤木（giinyo）、齋藤（nari）</center>
<h2>既存顧客との活動から新たなプロダクトの課題仮説と可能性を模索する</h2>
——「今回の新規プロダクトの詳細についてはまだ秘密…」と伺っていますが、どのようなアイディアがきっかけで開発に至ったのか教えていただけますか？
akky：今回の開発のきっかけに言及する前置きになりますが、アイディアを形にして、市場で仮説検証を行い、事業やプロダクトに還元する。このサイクルを高速で回していくことこそ、初期から複数プロダクトを並列で立ち上げていくコンパウンド型の事業成長においてもっとも大切だと思っています。だから、セールスやカスタマーサクセスの活動をしながらも常に新規事業の可能性を模索していました。
——今回の新規事業における「課題の特定や事業の方向性」はどのように決定していったのでしょうか？
akky：これまでRightTouchでカスタマーサクセス、事業開発を行ってきた知見から、カスタマーサポート領域で優位性を築くために“絶対に押さえなければいけないデータ”があることはわかっていました。
その上で、2023年秋ごろから10社ほどのクライアントのもとに足を運び、カスタマーサポートの業務全体を通じてどんな困りごとを抱えているのか、RightTouchとしてどんな打ち手があるかヒアリングし、新規事業の解像度を高めていきました。
ヒアリングを通して共通して出た課題意識を、新規事業の「What（何を解決するのか）」として設定することに決めました。 
<img src="https://ik.imagekit.io/righttouch/f7a99e1f-8366-4c0b-a559-0b67f3ed7732/DSC00834.jpg" alt="DSC00834.jpg"><center>BizDev 田中（akky）</center> 
——最初はチームではなく、一人で進めていたのですね。
akky：はい。「How（どのように解決するか）」を検討するため、パワーポイントに簡易的にアイディアを落とし込み、クライアントにプレゼンを行って仮説を当てていきました。このあたりから、エンジニアのnariくんにも協力してもらい、技術的な観点でフィードバックをもらっていきました。 
 nari：実は、当初は新規プロダクトという形ではなく、クライアントからデータをもらって加工する受託開発として進めていたんです。
その過程で、技術的な検証や提供価値の検証は、一定できました。しかし「本当に使いやすい形でプロダクトとして提供できるのか？」「継続して使ってもらえるのか？」といった、プロダクト化にあたって重要な論点は残っていました。もちろん、モノを作らずにこれらの論点を検証することもできたかもしれませんが、新規プロダクトとして開発に本腰を入れた方が良い、という経営判断もあり、2024年4月にエンジニアのgiinyoも含めたプロジェクトチームを組成しました。
——そこから、どのようなプロセスを経たのでしょうか？
nari：私はチームを組成直後から、まずは自分自身がこの新規プロダクトにフルコミットできるようリソース調整を行いました。akkyのおかげで大まかなアウトプットのイメージはできていたので、クライアントからもらった細かな要望や意見をもとに、MVP（Minimum Viable Product）を作ることに注力していきました。 
 akky：MVPを作るにあたって、「カスタマーサポートの現場で働く方々がきちんと活用できるもの」をゴールに設定しました。過去の経験から、コールセンターの皆さんは非常に膨大な量の問い合わせデータと向き合っていますが、ITツールに慣れていない方も多いと感じています。
プロダクトを作っても、日常的に活用してもらえなければ意味がない。そこで、実際の使用イメージが湧くように、<a href="https://note.righttouch.co.jp/n/n97bc415698b2?gs=53dcaaa6989f">デザイナーのkimさん</a>にも加わってもらい、MVPに沿ったデザインや、フロントエンド、バックエンドまで作り込みました。 
<img src="https://ik.imagekit.io/righttouch/5b7fe5a4-dcb4-4599-b645-9470a9da855c/DSC00809.jpg" alt="DSC00809.jpg"><center>テックリード 齋藤（nari）</center>
<h2>「共通開発基盤」と「リファレンスカスタマー」がコンパウンドの鍵</h2>
——チームを組んでから約1ヶ月という短期間でMVPを完成したと伺いました。そこまでのスピード感が出せたのはなぜですか？
akky：大きく3つ要因があると思っています。
一つは、コンパウンドスタートアップならではの強みだと思いますが、「共通開発基盤」と「リファレンスカスタマー」の存在です。
ゼロイチの開発といっても、すでにRightTouchで築き上げてきたフレームワークやリファレンスカスタマー（RightTouch既存プロダクトを導入・利用してくださっている代表的な企業）との信頼関係があるからこそ、ここまでのスピード感をもって開発に集中できたのだと思っていて。
特に大企業の部長・役員クラスともすぐにコミュニケーションがとれるのは、カスタマーサポートという非常に規模と影響範囲の大きな領域に向き合う上で大きな優位性となっていると感じます。 
 giinyo：私がこのチームにジョインした時には、「何を作るべきか」「クライアントにとってどんな価値を生むのか」がほぼ明確な状態でした。エンジニアにとって、プロダクトの価値を確かめながらものづくりができる環境はすごくありがたいんです。すぐに「早くこのプロダクトを世に出したい」という気持ちにまでなっていましたね。 
 akky：二つ目は、最初から「スケーラビリティ」を意識しなかった点かなと。
——コンパウンドスタートアップは、事業拡大、すなわちスケールを見越して仕様検討する場合が多いですよね。
akky：そうですよね。ただ、最初からスケールした先を意識して、細々としたところまで作り込んでしまうと、開発のスピード感は損なわれてしまう。だからまずは、PMF（プロダクト・マーケット・フィット）させることに主眼を置くことにしたんです。 
 nari：もちろん良し悪しはありますが、まずは市場に出し、顧客からフィードバックを受けながら仮説検証を行っていく姿勢も重要だと思っています。 
<img src="https://ik.imagekit.io/righttouch/fd77116c-ef5d-4f3d-af59-0279a8c939ad/DSC00885.jpg" alt="DSC00885.jpg"><center>エンジニア 赤木（giinyo）</center>
<h2>キーワードは「背中を預け合える信頼関係」。プロダクトづくりに集中できるRightTouchの環境とは？</h2>
——RightTouchが高速でプロダクト開発を進められる、最後の理由は何でしょうか？
akky：全員がプロフェッショナルであること、でしょうか。
「コンパウンドスタートアップの勝ち筋」として非常に重要なのが、「開発のスピード感」です。
その観点でいうと、メンバー一人ひとりがプロフェッショナルとしてミッションを果たす環境が当たり前にあるRightTouchだからこそ、実現するのではないかなと。 
<img src="https://ik.imagekit.io/righttouch/c20f7765-d142-4784-8c6b-cdd9ea22ff1b/DSC00893.jpg" alt="DSC00893.jpg"> 
——全員がプロフェッショナル、というのは具体的にどんな場面で実感しますか？
akky：RightTouchは、意思決定のトップダウンとボトムアップのバランスがとても良い組織です。大きな戦略や外してはいけないポイントは、経営陣が中長期からバックキャスト（逆算）してしっかり決めますが、その幅のなかでの現場の自由度はとても高い。 
今回も、冒頭に話した“（カスタマーサポート市場におけるコンパウンド戦略実現に不可欠な）絶対に押さえなければいけないデータ”を得ることができれば、どんなプロダクトとして実現するかは僕たちチームからのボトムアップで決められました。「データを押さえる」という観点で事業戦略との接合は作れていたということです。 
コンパウンドスタートアップも様々なスタイルがあると思いますが、感覚としては、すでに細かくプロダクトロードマップが引かれており、作るプロダクトの枠組みがおおよそ決まっている企業が多いように思います。 
スタートアップとして、限られたリソースをどのタイミングで何に配分するか、という経営判断は非常に重要ですが、全員が当事者意識を持って日々業務にコミットしているからこそ、こうした意思決定もスムーズに委ねてもらえたのではないかと思っています。 
 giinyo：手前味噌かもしれませんが、RightTouchにはakkyさんをはじめとしたクライアントと密な信頼関係を築き、プロダクトに対して深く率直なフィードバックを持ち帰ってきてくれるビジネス担当がいる。クライアントとのコミュニケーションは全面的に任せられるので、私たちエンジニアも開発に集中できるのだと思っています。 
 nari：チームとしてもバランスが良かったと思います。akkyは比較的楽観的にどんどん物事を前に進めていくタイプで、私はどちらかというとリスクを考えるタイプ。多様な視点を持ったチームかつ、各々をリスペクトしているからこそ、スムーズにゼロイチの開発ができたと感じます。
——ビジネス担当、エンジニア双方が強い信頼関係で結ばれているのがわかります。
nari：RightTouchでは「全員プロダクト担当、全員顧客担当」というバリューを大切にしています。役割に囚われず、事業成功にコミットしていくというマインドがあるんです。
だからこそ、クライアントへのプレゼンやミーティングには、私やgiinyoもできるだけ出席し、議論に参加するようにしました。
akky：ビジネス担当としても、クライアントとの打ち合わせにエンジニアも一緒に入ることで、要望や意見に対して「YES/NO」を即答できるのはすごく心強いんです。私が出したアイディアにも、すぐに仕様を書いて、技術的観点でフィードバックをくれますし。こうした環境で仕事ができるのはなかなか貴重ですし、とても嬉しいですね。
giinyo：回答や結論を持ち帰った場合でも、プロダクトへの実装は可能なのか、他にどのような選択肢があるのか、すぐにディスカッションを行いました。全員が同じ目的意識のもと、それぞれの役割に最大限コミットした結果、このようにスピード感を持った開発ができたのだと思います。
——RightTouchではビジネス担当、エンジニアが互いに背中を預けられる関係だからこそ、高速のプロダクト開発ができるのですね。貴重なお話、ありがとうございました！
<h2><img src="https://ik.imagekit.io/righttouch/7e3b0250-c21d-4a9c-9ee3-dba071f8837d/DSC00858.jpg" alt="DSC00858.jpg"></h2>
RightTouchの採用情報はこちらから 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>
カスタマーエンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/customer-engineer">https://recruit.righttouch.co.jp/customer-engineer</a>
デザイナー求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/designer">https://recruit.righttouch.co.jp/designer</a>
（ライター／安心院 彩（フリーランス） 　取材・編集／緒方 祥子（フリーランス））

 高速でプロダクトの価値を検証せよ——RightTouch流コンパウンド事業立ち上げの勝ち筋

SlackのuserGroupメンションをアシストするアプリをCraft Functionsで作ってみた

SlackのユーザーグループメンションをアシストするアプリをCraft Functionsで作ってみた

※この記事は<a href="https://note.com/s346/n/n695816901938">RightTouch公式note</a>に掲載した内容を転載しています。
<h2>はじめに</h2>
RightTouchでエンジニアをしているsanshiroです。現在は主に<a href="https://rightconnect.karte.io/">RightConnect by KARTE</a> (以下RightConnect)の開発を担当しています。
RightConnectとは、昨年β版をリリースしたコンタクトセンターのオペレーター向けのプロダクトです。このプロダクトの目的は、Webサイトと電話の問い合わせ体験を統合し、電話の応対効率と顧客体験を最大化しすることです。
RightConnectの特徴の一つは、オペレーターが電話応対をしながらWeb上での行動や問い合わせ情報をリアルタイムで確認できる点です。この機能を実現するために、β版ではオペレーター向けのダッシュボードを作成しました。β版の運用・検証する中で明らかになった課題に対処するため、オペレーター向けのダッシュボードのリニューアルを4月に行いました。
本ブログでは、紆余曲折あったリニューアルのプロセスについてご紹介できたらと思います。
<h2>オペレーター向けのダッシュボードについて</h2>
<img src="https://ik.imagekit.io/righttouch/10f8c558-6a78-43af-b8be-2597e4f6476c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-05-2018.03.32.png" alt="スクリーンショット2024-05-2018.03.32.png">
LPより抜粋 <a href="https://rightconnect.karte.io/">こちら</a>
RIghtConnectは電話の応対効率と顧客体験を最大化を目的に開発され、顧客とオペレーターの 双方 の満足度を高めることに注力しています。
電話の応対で顧客が抱える不満で最も多いのは、待ち時間が長いことですが、説明の手間や話が噛み合わないといった情報伝達・コミュニケーションに関しても不満が上がることが多いです。
オペレーターが使いやすいプロダクトにすることで、顧客とオペレーターの情報伝達が円滑になり、顧客体験の向上に直結します。また、応対効率も向上するので、待ち時間の削減にも繋がります。
そのため、顧客の満足度のみを考えるのではなく、オペレーターが使いやすいプロダクトとしての満足度向上にも注力しています。
RightConnectの具体的な要素は大きく分けて3つで構成されています。
<ol>
<li>問い合わせ前行動を元に、顧客のお困りごとに合わせた最適なチャネルをご案内</li>
<li>顧客ごとの問い合わせ前行動の情報をオペレーターに還元し、ステータスや悩みを瞬時に把握</li>
<li>Webサイト上の行動や顧客属性、問い合わせきっかけなど、さまざまなデータをリアルタイムに解析・可視化</li>
</ol>
詳細は、RightConnectのβ版開発の裏側について書かれた<a href="https://blog.righttouch.co.jp/rightconnect-beta-release">こちらのブログ</a>をぜひご覧ください。
オペレーター向けのダッシュボードは、2.顧客ごとの問い合わせ前行動をオペレーターに還元し、ステータスや悩みを瞬時に把握 を実現するために、ユーザーの問い合わせ前行動を閲覧できることに加えて、ユーザーのWeb行動を動画でリアルタイムで再生しながらマウスポインタの共有も可能な画面として開発されました。
オペレーターは、問い合わせ応対時にオペレーター向けのダッシュボードを常に利用します。オペレーター向けのダッシュボードの使いやすさ = オペレーターにとってのプロダクト使いやすさ になります。
そのため、オペレーター向けのダッシュボードは、オペレーターにとって、見たい情報が見やすい形で表示され、必要な機能が使いやすい画面であることを追求して開発を行っています。
<h2>β版で明確になったオペレーター向けのダッシュボードへの課題</h2>
RightConnectはMVP(Minimum Viable Product)としてスピード重視で開発され、クライアントへ迅速な価値の提供を行いました。プロダクトを実際に運用・検証を行えたことが非常に重要で、特にRightConnectを利用しているコンタクトセンターの見学にチームメンバー全員で行かせていただことが以下の課題の発見につながりました。
<ul>
<li>オペレーターは多数のツールを使っており、そのそれぞれが高度にカスタマイズされている。その状態であっても、オペレーターがよく見る項目は限られており、無駄なスペースもある。</li>
<li>オペレーターにとってのダッシュボードの価値を最大化するためには、「そのセンター」「そのリーズン(顧客の困りごと・達成したいこと)」に最適化されたダッシュボードの項目や配置が実現できる必要がある。</li>
</ul>
β版のオペレーター向けのダッシュボードでは簡易的なカスタマイズは可能であったものの、これらの課題を解決するために求められる ダッシュボードの柔軟なカスタマイズ性は実現できない部分がありました。
4月から導入社数も増加予定だったこともあり、大規模な導入が進む前にオペレーターへのダッシュボードの価値を最大化できるようにリニューアルすることを決め、ダッシュボードが柔軟にカスタマイズできることという機能要件にフォーカスして設計を開始しました。
<h2>オペレーター向けのダッシュボードv2の設計</h2>
<img src="https://ik.imagekit.io/righttouch/b07ecaed-cb3d-4ffc-bb5b-159bcdccef73/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-05-2019.40.30.png" alt="スクリーンショット2024-05-2019.40.30.png">
オペレーター向けのダッシュボードv2の初期デザイン(設定画面)
RightTouchでは、職種問わず担当者がPRD(製品要件文書)を作成し、それをもとに、議論し、方向性・仕様を固め、開発に着手します。 
オペレーター向けのダッシュボードのリニューアルを行う際にも、運用・検証で得られた課題を元にダッシュボードの柔軟なカスタマイズ性を重視したPRDが作成されました。
カスタマイズ性の例としては、以下のようなものになります。
<ul>
<li>情報を自由に追加削除できる</li>
<li>直感的な操作で要素を並び替えることができる</li>
<li>顧客のリーズンに合わせたダッシュボードの表示ができる</li>
<li>ダッシュボードへの新機能の追加がしやすい</li>
</ul>
それに伴いデザインも柔軟なカスタマイズと今後の機能追加がしやすい形を追求し、機能要件を満たすために管理者が利用する設定画面を重点的にデザインしました。
<h2>プロトタイプ作成、再検証</h2>
PRD・デザインを元に開発を進め、一連の機能が操作できる状態になった段階で、社内でフィードバック会を開催しました。この会はRightTouchメンバー全員が参加可能で、実際に機能を触ってもらいながら幅広い意見を集めることを目的としています。
その結果、ダッシュボードの柔軟なカスタマイズ性に関する機能要件は問題がないことが分かりました。
一方で、本来のプロダクトとしての オペレーターにとって見やすい・使いやすい 部分が少し犠牲になっているのではといったフィードバックがチーム外のメンバーからありました。
チーム内でカスタマイズの機能要件にフォーカスし、機能・デザインの修正を繰り返していく過程の中で、オペレーターにとって見やすい・使いやすいの観点が薄まっていることに、フィードバックの機会を持つことで気づくことができました。
本来の目的が失われては、今後、プロダクトとしての価値を提供できないと判断し、カスタマイズ性を保ちつつ、オペレーターが使いやすい・見やすい画面としての細かいUI/UXといった非機能要件に徹底的にこだわるという観点を補強し、デザインをやり直すことを決めました。
デザインを作り直すコストはありましたが、プロダクトとしての価値をフラットに見直してリリースを遅らす意思決定しました。その際、チームのBusiness、Customer Engineerメンバーがその価値をクライアントにも丁寧に説明することで、考え方に賛同していただけました。
<h2>デザイン案の再設計</h2>
まず、オペレーターが使いやすい・見やすい画面として、電話しながらでも対応がしやすい理想のダッシュボードとは何かというところに立ち返ってチームで再度議論し直しました。
今まで行ってきたコンタクトセンター見学の情報などを元に、デザイナーは具体的な形にし、他職種のメンバーはインスピレーションを得るためにネットからダッシュボードのデザイン案を探しました。その中で、どのような要素が、見やすい・使いやすい画面に必要なのか、現在の画面には何が足りていないのか、画面構造から詳細の細かい表現まで議論を行い、理想のイメージをチーム間で共有し、整理しました。
<h2>デザインの反映</h2>
<img src="https://ik.imagekit.io/righttouch/7c81238f-f77d-4b4c-bf7c-13ce1fd1c5e8/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-05-2021.48.23.png" alt="スクリーンショット2024-05-2021.48.23.png">
デザイン案再設計後のデザイン(オペレーター向けの表示画面)
デザインの反映は、理想のイメージを今後実現できるように、主にデザインの構造の修正とオペレーターが見やすい・使いやすいUI/UXへの修正を行いました。
主な変更点としては、以下になります。
<ul>
<li>構造の修正
<ul>
<li>カラム → カード(見出しと白いエリア部分) → コンポーネント(各情報) の階層構造に変更
<ul>
<li>カード内でコンポーネントを複数列表示等に対応できるように</li>
</ul>
</li>
</ul>
</li>
<li>各コンポーネントの表現方法
<ul>
<li>見出し・内容のテキストの色・サイズの調整</li>
<li>影など、ノイズになる可能性のあるデザインを修正</li>
</ul>
</li>
<li>イベントの表現方法
<ul>
<li>ユーザーの行動が視覚的にわかりやすいようにタイムライン表示に</li>
</ul>
</li>
</ul>
特に裏側のデータ構造に影響のある、理想のデザイン構造とすでに開発したデザイン構造で齟齬がある部分、妨げになる可能性のある部分の修正に絞って対応することで、1〜2週間程度で修正が完了しました。
結果、想定していた初期のリリース日から大きく遅らせずにリニューアルを完了できました。 
最終的に本来の目的であるオペレーターの使いやすさとスピードの両面を取れた形でリニューアルを完了できたことにチームとして満足しています。
<h2>まとめ</h2>
一度β版でリリースしたものをその延長で考えて、一度考えた方向性で固執せずに、理想を再定義して作り直すことで、プロダクト本来の価値を最大化するリニューアルを行うことができました。
今回のケースから今後は、プロダクトの価値を高めるために以下をより意識して、開発を行っていきます。
<ul>
<li>プロダクト全体としての目的をチーム間で 常に 共有しながら機能開発をすすめること</li>
<li>(ユーザー・社内)フィードバックの機会を 早めに何度も 設けること</li>
</ul>
RightTouchでは、職種問わず、目的を追求し、スピード感を持ってより良いものを作っていきます。興味がある方は、絶賛採用中ですので、ぜひ一緒に働きましょう。
採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>

RightTouchでエンジニアをしているsanshiroです。現在は主にRightConnect by KARTE https://rightconnect.karte.io/ (以下RightConnect)の開発を担当しています。  RightConnectとは、昨年β版をリリースしたコンタクトセンターのオペレーター向けのプロダクトです。このプロダクトの目的は、Webサイトと電話の問い合わせ体験を統合し、電話の応対効率と顧客体験を最大化しすることです。  RightConnectの特徴の一つは、オペレーターが電話応対をしながらWeb上での行動や問い合わせ情報をリアルタイムで確認できる点です。この機能を実現するために、β版ではオペレーター向けのダッシュボードを作成しました。β版の運用・検証する中で明らかになった課題に対処するため、オペレーター向けのダッシュボードのリニューアルを4月に行いました。  本ブログでは、紆余曲折あったリニューアルのプロセスについてご紹介できたらと思います。

プロダクトの価値と課題に向き合ったら、ダッシュボードのUIを完全に再設計することになった

プロダクトの価値と課題に向き合ったら、ダッシュボードのUIを完全に再設計することになった話

RightTouchでは、より大きなインパクトを生み出すための環境整備の施策のひとつとして、全社で「フルフレックスタイム制（コアタイムなし）」を導入しています。 
事業・プロダクトに対してより大きなインパクトが生み出せるように、7:00〜22:00のうち働く時間をフレキシブルに決めることができる制度ですが、実際にRightTouchメンバーはどのように利用しているのでしょうか？「ホントのところ」をエンジニア・デザイナーメンバー11人に聞いてみました！ブログを通して、RightTouchで働く際のイメージが深まれば嬉しいです。
<hr>
まず、フレックスタイム制についてですが、これは全員一致でメリットを感じているようでした！
<img src="https://ik.imagekit.io/righttouch/873d4c5b-889c-46bf-ac87-3990d3f4fed5/Righttouch%E7%94%BB%E5%83%8F(2).png" alt="Righttouch画像(2).png"> 
 
次に、メンバーの普段のワークタイムを聞きました。 
全てのメンバーが普段は9:00〜10:00の間に仕事を始めていますが、終業時間は人によって16:00〜21:00以降までばらつきがありました。その日の予定やパフォーマンスによって、柔軟にワークタイムを決められるのはインパクトの総量にも良い影響がありそうです。
<img src="https://ik.imagekit.io/righttouch/e5bfb8aa-3cbd-40bc-b12e-dede0b388868/Righttouch%E7%94%BB%E5%83%8F.png" alt="Righttouch画像.png"> 
続いて、どんな時に働く時間がフレキシブルにできるメリットを感じるか、聞いてみました。 
<img src="https://ik.imagekit.io/righttouch/b7cd8d49-32c1-40ee-a683-af48778cad9d/Righttouch%E7%94%BB%E5%83%8F(1).png" alt="Righttouch画像(1).png"> 
特にメリットを感じることとして「パフォーマンスが高くなりやすい時間を選べる」「日中しか出来ない私用の対応ができる」を、8割を超えるメンバーが挙げていました。
時間の融通が効くことのメリットが感じられた具体的なシーンやエピソードを、メンバーが答えてくれました！ 
※カッコ内は回答してくれたメンバー名
パフォーマンス向上
<blockquote>
・出社するときに、朝の混雑する時間帯を避けることができる（miso、ikki） 
・夜遅い時間など自分にとって仕事に集中しやすいタイミングで働くことができる（nari） 
・最近パーソナルトレーニングを始めたんですが、12-15時とかの昼の何処かに一度仕事を抜けて通ったりしています。リフレッシュにもなってその後の集中力も高まるので割と良いです。（ikki） 
・朝が弱いので、始業時間に追われる感覚がなくなった（saaa-san） 
・開発に集中したい時、連絡が少ない朝や夜の時間帯に作業できて捗ります (kanke)
</blockquote>
プライベート予定対応
<blockquote>
・通院対応や、コロナ禍ではワクチン接種などに気兼ねなく行けた（Aaron、koyo、takken） 
・昼過ぎまで出社してミーティングに参加して、その後荷物受け取りのために帰宅、そこからまた仕事をするみたいな動きもしやすいです（ikki） 
・役所の手続きなど、平日昼間にしか対応していないものに苦労しなくなった（takken、giinyo） 
・子供の送り迎えや習い事対応、運動会や授業参観など、数時間だけ抜けて参加できるのが良いです（yabu、kanke、Aaron） 
・週末に北海道へライブ遠征に行った時に、月曜に飛行機で帰ってくる調整ができてめちゃくちゃ助かった（saaa-san）
</blockquote>
 
コメントからも、モチベーションやパフォーマンスが高められるよう、各自が自身のニーズに合わせてフルフレックス制を活用していることがうかがえます。 
とはいえ、フレキシブルな働き方や時間の使い方は今がベストな姿なのでしょうか？最後に、改善点や難しさを感じる点を聞いてみました。
改善点・難しい点
<blockquote>
・全員オフィスにいる時と同じように気軽に話しかけられる雰囲気を作るためにいろんなツールの検討を重ねていて、まだ解決できていると言えない 
・朝弱いので、自分で強い意志を持たないとずるずる勤務時間が遅くなっていく 
・フレキシブルでありがたい反面、仕事が楽しくて働こうと思えばいつまでも働けてしまうことです。家族との時間がおざなりになってしまって子供にも寂しい思いをさせてしまったこともありました…。今はタイムスケジュールを切って、きっちり切り替えるように心がけています！
</blockquote>
<hr>
チームがどんどん拡大する中で、個人のフレキシビリティを保ちながらチーム全体の成果や生産性を高めていくには、コメントがあった点の改善だけでなく、継続的な取り組みが必要になってきます。RightTouchでは、こうした制度や働き方・カルチャーづくりにも、メンバーが主体的に意見を持って議論に参加し、未来のあるべきRightTouchの姿を決めていくカルチャーがあります。 
 
RightTouchの取り組みや雰囲気に興味を持ってくださった方がいたら、ぜひカジュアルからお話できたら嬉しいです。
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>

ホントのところ、どうなってる？〜RightTouchのフルフレックスタイム制度〜

※この記事は<a href="https://note.com/nakaakist/n/n146afd3fbff9">RightTouch公式note</a>に掲載した内容を転載しています。
<h1>はじめに</h1>
株式会社RightTouchテックリードの齋藤です。
ChatGPTのリリースから約1年半が経過し、LLMはモデル・アプリケーションの両面で大きな進化を遂げてきました。弊社でも、プロダクトのさまざまな部分でLLMの活用を進めてきました。本記事では、RightTouchにおけるこれまでのLLM活用について振り返るとともに、我々がLLMをどのように用いて、何を目指しているかについてご紹介します。
まず初めに、RightTouchについて簡単にご紹介します。RightTouchでは、「あらゆる人を負の体験から解放することで、人と企業の可能性を引き出す」というミッションで、下記3つのカスタマーサポート向けプロダクトを提供しています。
<ul>
<li>RightSupport by KARTE: webサイト上でのユーザー行動からユーザーのつまずきを検出し、最適なFAQや問い合わせチャネルへ誘導する</li>
<li>RightConnect by KARTE: webサイト経由で企業に電話をかけるユーザーの行動情報や事前ヒアリング情報を電話オペレータにリアルタイムに提示し、高品質・高効率な電話応対を実現する</li>
<li>KARTE Talk: webサイト上での有人チャットを行う</li>
</ul>
<img src="https://ik.imagekit.io/righttouch/2cfbb72a-0a6f-4981-a21c-0d75fbf81057/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-222.07.47.png" alt="RightTouchが提供するWebサポートプラットフォーム">
どのプロダクトも、お客様のWebサイトの拡張・強化を軸に、Web上/Web経由での最適なカスタマーサポートの実現を目指しています。これらのプロダクトは、個々で独立して使うことも可能ですが、Web行動データやナレッジデータなどに関しては、共通のデータ基盤の上に成り立っています。
<h1>RightTouchにおけるこれまでのLLM活用</h1>
RightTouchでは、これまで試行錯誤しつつ、LLMを活用した機能をいくつかリリースしてきました。
一例として、RightSupport by KARTEでは、<a href="https://speakerdeck.com/righttouch/llm-openai-devday">サポートシナリオの自動生成機能</a>を開発しました。これは、ユーザーのWeb行動から蓄積された統計情報をもとに、特定のページでユーザーに提示すべきFAQ選択肢や、そこに誘導するためのヒアリング項目をLLMを用いて自動生成するものです。
<img src="https://ik.imagekit.io/righttouch/941f0ab0-cf79-4015-8c6d-4f627e634ca4/%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E8%87%AA%E5%8B%95%E7%94%9F%E6%88%90%E7%B0%A1%E6%98%93%E7%89%88002.gif" alt="サポートシナリオの自動生成
">
また、KARTE Talkでは、有人チャットのオペレータ向けに、問い合わせ内容に合ったFAQの自動サジェスト機能や、これを利用した<a href="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1?talk=24-t1-session4">返信文の自動生成機能</a>をリリースしました。どちらの機能も、我々が持つデータアセットに対してLLMを適用し、業務効率化を実現するソリューションとなっています
<img src="https://ik.imagekit.io/righttouch/587b9c57-6ada-4ec5-b9aa-be5f9d89d164/LLM_note_01.png" alt="これまでのLLM活用の実例
">
これらの機能は、主に既存プロダクトの利用課題の分析や営業観点でのニーズ分析を行った上で、LLMの得意領域と交差する領域を探索的に見つけ出す形で開発してきました。結果として、リリース後は反響を頂くことができ、狙っていたプロダクト課題の解決にも貢献できました。開発を通じて、LLMの得手不得手や、我々のプロダクトドメインとの相性に関して知見をためられたことも非常に大きな収穫でした。
<h1>これからのLLM活用</h1>
これからも、短期的にLLMでユーザー課題を解きにいく活動は続けていきますが、中長期的には、我々の目指すビジョンの中でLLMがどう位置付けられるか？が重要であると考えています。
<a href="https://note.com/taito661/n/n23adce847fe0">代表の長崎の記事</a>でも述べられていますが、RightTouchはカスタマーサポート領域におけるコンパウンドスタートアップとして、業界のインフラとなることを目指しています。 
コンパウンドにプロダクトを展開していくにあたり、大きな軸の一つがデータです。あるデータを抑えると、そのデータを活用できる別のワークフローに進出でき、そこからまた新たなデータが抑えられ…という過程の繰り返しにより、プロダクトは拡大していきます。
しかし、現状、カスタマーサポートにおけるデータは、業界全体で見ても、整理・活用されているケースは多いとは言えません。RightTouchが得意とするweb領域は、比較的構造化されたデータが得られやすい領域ではありますが、それでも大半のデータは眠ったままです。web領域以外でも、コールセンターには、テキストデータを中心に未活用の構造化・非構造化データは大量に存在します。こういったデータにRightTouchがアプローチしていくにあたり、LLMはデータ取得/加工/活用の各プロセスにおいて強力な武器となります。
<h3>1.データの取得・加工</h3>
カスタマーサポートにおいて、データの活用が進みづらい一因が、取得・加工されたデータの質そのものにあるケースも多いと我々は考えています。例えば、エンドユーザーが問い合わせを行う際、自分の困りごとをうまく言語化できなければ、結果として得られる問い合わせデータの質は下がってしまいます。また、オペレータの応対においても、個々のオペレータが独自のポリシーで回答をしている場合や、ログ残しの基準にばらつきがある場合、その後のデータ分析はしづらくなります。LLMを用いれば、エンドユーザーに対する困りごとの特定の補助や、オペレータに対する同一基準でのログ残し補助ができます。これらは、主にUXや生産性向上の文脈で語られることが多いですが、うまく使えば、取得・加工されるデータの質の向上にも大きく寄与できます。
<h3>2.データの活用</h3>
大量に溜まったデータを業務に還元するのにもLLMは強力な武器となります。例えばLLMによるembeddingを利用すると、行動データ/問い合わせデータといった曖昧性のあるデータを、精度良く検索することができます。RAG等を組み込んだ検索により、オペレータやコンタクトセンターの管理者が、必要なナレッジや関連情報を瞬時に取得することができ、状況に応じた適切な応対の実現や、データの知見を生かした施策やナレッジの作成の自動化が行えます。
1と2は、車の両輪のようなものです。データの活用に目が行きがちですが、きちんと意味付けられ、整理されたデータがなければ、その活用は難しくなります。RightTouchとしては、両者をバランス意識していくことが重要だと考えています。まずはお客様の課題に合わせて、2でデータの直接的な利用価値を増やし、結果としてお客様との共創が増えて1が進み、それにより2の新しいチャンスが生まれる、という循環を回していければ理想です。
<img src="https://ik.imagekit.io/righttouch/58f40142-539b-46c5-8c5f-362dc368f6d7/LLM_note_02.png" alt="RightTouchが目指すLLM活用
">
ただ、当然LLMには、ハルシネーションのリスク、高いコストや厳しいレートリミットといった問題もあり、それだけでカバーできる範囲はまだ十分広くはありません。これらをクリアするためには、LLM・人・ルールをうまく組み合わせるUXの設計、適切なユースケース設定、キャッシュやデータストアの設計など、アプリケーションづくりの総力戦が必要となります。 
例えば、カスタマーサポート向けSaaSにおいてエンドユーザーに提供する機能では、正確性の観点から、LLMの生成結果をそのまま提示することは難しく、一定バリデーション等を挟み、型を絞った形でのアウトプットが求められるケースが多くなります。オペレータ向けの機能であっても、「LLMの出力に対してどこで人のチェックを挟むか？」をしっかり検討しなければ、業務効率化と蓄積されるデータの質の担保の両立は難しくなります。また、そもそもデータをセキュアに保存するインフラ基盤がなければ、良いプロダクトを作ったとしても結局お客様には使っていただけません。
データを軸としたプロダクト展開において、LLMは強力な武器ではありますが、UXを考え抜くこと、良いアプリ設計をすることなど、プロダクトづくりの基礎に徹底的にこだわるスタンスは変わらず重視していきます。
<h1>さいごに</h1>
ここまでお読みいただき、ありがとうございました。RightTouchでのLLM活用、エンジニアリングやプロダクトづくりに興味を持っていただけたら嬉しいです。もし、より詳細が気になる方がいらっしゃれば、<a href="https://www.wantedly.com/projects/1493065">ぜひカジュアルにお話ししましょう！</a>

「」の記事

Archives

Writers