RightTouch Blog

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

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>

RightTouchのLLM活用のこれまでとこれから

<h2>カスタマーサポートにおける自己解決とFAQ検索</h2>
Webでのカスタマーサポートにおいて、エンドユーザーにいかに自己解決してもらうかは重要な課題です。自己解決とは、例えば「サポートサイト・FAQ・チャットボット・マニュアル」などの手段を用いて、有人サポートに頼らず、ユーザーが自分自身で困っている内容を解決することです。自己解決率を高くすることで、簡易な問い合わせが減り、人が応対して解決すべき複雑な問題にリソースを割くことができるからです。
上記の理由から、企業のWebサイトにおけるFAQの検索は非常に重要です。適切なFAQにすぐに辿り着くことが出来れば、自己解決に繋がり、ユーザーの満足度も応対側の効率も高められるからです。しかし、実際のFAQ検索では、欲しい情報が見つからない、うまく検索ができないといったことがよく起こります。
なぜこういったことが生じるのかというと、自分の課題をFAQに存在している言葉で引っ掛けなければいけないという、なかなかに難しい問題を含んでいるからです。最近の検索システムでは、一般的な類義語登録や各企業が提供しているサービスのドメイン固有の単語を登録するなどして、検索がうまくいくよう工夫しています。ですが、それでも実際のFAQサイトでは、検索がうまくいかず、欲しい情報にたどり着けないため、結局エンドユーザーが電話やメールで問い合わせするということが頻繁に起こっています。
この問題を解決するための一つの方法として、自然言語をクエリとした検索があります。検索といえば、n個の単語をスペースで区切って検索するものが一般的ですが、自然言語による検索では、人に会話で質問をするように、検索することができます。
例えば、Webサービスでログインパスワードを忘れた場合のFAQを検索したい場合:
単語検索: 「ログイン パスワード 忘れた」
自然言語検索: 「ログインパスワードを忘れたんだけどどうしたらいい？」
のような違いがあります。上記の例では、単語検索も簡単ですが、より複雑な問題になったときは、自然言語で検索したほうが問題を表現しやすいことは多々あると思います。
では、このような自然言語による検索システムを構築するにはどうしたらいいでしょうか。そのためには、Embeddingという技術を利用します。EmbeddingはChatGPTなどのLLMで利用されており、文章を入力すると、浮動小数点のベクトルが出力されます。ベクトルで出力されるということは、ベクトル間の距離を測れるということになり、つまり文章間の距離（関連性）を計算することができます。そのため、先程の自然言語検索の例では、予めFAQ記事をEmbeddingでベクトル化しておき、入力された文章もベクトルで表現し、各FAQ記事との距離を計算し、距離の近いものから表示することで、検索機能を実現できるのです。
<img src="https://ik.imagekit.io/righttouch/22522506-1cbb-439c-9182-6ca1d059eda4/Untitled(1).png" alt="Untitled(1).png">
弊社の<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a> (以下、RightSupport) でも上記のような仕組みで検索機能を実装しており、自然文による検索を提供しています。RightSupportでは、AzureのOpenAI ServiceのEmbeddingsを利用しています。
<a href="https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/models#embeddings-models">https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/models#embeddings-models</a>
RightSupportではEmbeddings APIを直接利用し、検索機能自体は独自に実装していますが、最近ではLLMを利用した自然言語クエリによる検索機能自体がPaaSとして提供されています。今回は、それらの検索機能がどんなものか使ってみます。試してみるサービスは、Google Cloud Platform (GCP) の<a href="https://cloud.google.com/vertex-ai-search-and-conversation?hl=ja">Vertex AI Search and Conversation</a>です。
<h2>Embeddings APIを利用した検索システム</h2>
Vertex AI Searchを使う前に、現状のRightSupportで行っている検索について簡単に説明しておきます。RightSupportでは、クライアント企業のFAQ記事をインポートし、FAQ検索ウィジェットとしてサイトのあらゆる場所に提供できるといった機能があります。このFAQ記事検索にOpen AIのEmbeddingsを利用しています。
機能としては以下のようになっています。
<ol>
<li>各FAQ記事をEmbeddings APIに投げて、ベクトル化し、CacheとDBに保存しておく</li>
<li>エンドユーザーが検索すると、その文言をEmbeddings APIに投げてベクトル化する</li>
<li>検索文言と各FAQ記事のコサイン類似度を計算し、1に近いものから順にFAQ一覧を表示する</li>
</ol>
Open AIのEmbeddingsはnormalizeされており、難しいことを考えず内積を取れば簡単に類似度を計ることができます。
実際の検索結果は下図のようになっており、自然文の検索文言に対してそれっぽい記事が引っかかっていることがわかります。検索文言のサポートウィジェットというのは、RightSupport内の機能の一つであり、サイト内にサポート用のウィジェットを出すための機能です。実際中身まで見てみると、1件目はその強調表示の設定方法そのものズバリであり、2件目はサポートウィジェットにおいて効果的な使い方の一つとして強調表示を設定する方法を案内しています。これらの結果から検索結果としては妥当な感じがします（定性評価になってはしまいますが…）。
<img src="https://ik.imagekit.io/righttouch/9707e39d-53f8-434b-a095-8c16cf25581a/Untitled(2).png" alt="Untitled(2).png">
<h2>Vertex AI Search</h2>
次にVertex AI Seachを利用して、同じFAQで検索アプリケーションを作ってみます。Vertex AI Search and Conversationは、LLMを利用し検索やチャットボットなどを簡単に構築できるGCPのプロダクトです。今回は検索なので、Vertex AI Searchを利用します。設定方法に関しては公式のドキュメントやブログなどで色々と記事が出てるので割愛します。
Vertex AI SearchはGCP上では <code>検索と会話</code> という名前になっており、開くと以下のように作成した検索アプリなどが一覧として表示されます。
<img src="https://ik.imagekit.io/righttouch/d7a1cfc2-e382-4c9c-b590-d6a8e17af67d/Untitled(3).png" alt="Untitled(3).png">
<h3>自然言語クエリ処理の利用</h3>
Vertex AI Searchで自然言語クエリを利用するためには<a href="https://cloud.google.com/generative-ai-app-builder/docs/multi-turn-search">フォローアップ検索</a>をオンにする必要があります。フォローアップ検索を利用するにはデータストアと検索アプリの作成時に以下の設定をする必要があります。
<ul>
<li>データストアは非構造化データかウェブサイト
<ul>
<li>ウェブサイトの場合は <code>高度なインデックス登録</code> をオンにする</li>
</ul>
</li>
<li>検索アプリを作成するときに <code>高度なLLM機能</code> をオンにする</li>
</ul>
これらの設定を行い、検索アプリを作成することで自然言語クエリによる検索機能を作ることができます。実際に、弊社のプロダクトであるRightSupportのヘルプページ (<a href="https://help.rightsupport.karte.io/">https://help.rightsupport.karte.io</a>) のデータを元に検索アプリを作ってみました。
実際に検索してみます。RightSupportにはサポートウィジェットというWebサイト上にウィジェットを出す機能があり、またそのウィジェットをエンドユーザーが起こしたイベントに応じて強調表示する機能があります。その機能について調べてみます。
<img src="https://ik.imagekit.io/righttouch/90dfb4d5-506c-4509-a433-6ec4de48c0ff/Group38.png" alt="Group38.png"> 
左図は構造化データを利用しフォローアップ検索をオフにした検索アプリで、右は非構造化データを利用しフォローアップ検索をオンにした検索アプリです。「サポートウィジェット　強調表示」のように単語を並べて検索した場合は、検索結果は違いますが、どちらもいずれかのFAQがヒットしており、また1つ目の結果は同じページでした（データの入れ方が違うため結果のUIが違いますが）。
次に「サポートウィジェットの強調表示設定について知りたい」という自然文による検索をしてみます。 
<img src="https://ik.imagekit.io/righttouch/ccd40469-9514-47aa-9f6b-811b29a28cb7/Group41.png" alt="Group41.png">
このように、フォローアップ検索がオフの場合は、検索になにもヒットしませんが、フォローアップ検索がオンの方ではそれっぽい検索結果が返ってきています。定性評価になってしまいますが、2件目以降（1件目の検索結果は同じなので）の結果は自然文による検索の方が欲しい情報が返ってきている感じがします。
これらのアプリは、さくっと1, 2時間くらいで出来ました。このように、Vertex AI Searchを使えば、LLMを利用した自然言語クエリによる検索を手軽に作ることができます。
Vertex AI Searchを使ったトライアルは、今回はここで終わりますが、次はAzureの <a href="https://azure.microsoft.com/ja-jp/products/ai-services/ai-search">Azure AI Search</a> も試してみたいと思います。また、これらのサービスはただ自然言語クエリによる検索が出来るだけではなく、GoogleやBingの検索技術を色々と盛り込んだ高機能な検索やチャットボットのようなものになっています。自然言語処理の専門家がいなくても、高度な検索機能が手軽に作れるように技術が進化しているのは、小さなチームでトライを重ねている僕たちのようなスタートアップにとって、とても良い環境になったのを感じています。
またRightTouchには、こうしたLLMの活用をはじめ、最新の技術に積極的に触れて、プロダクトに活用できないかを考える環境・カルチャーがあります。RightTouchの取り組みや雰囲気に興味を持ってくださった方がいたら、ぜひカジュアルからお話できたら嬉しいです。
<div class="iframely-embed" data-embedded-url="https://righttouch.co.jp/recruitment"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://righttouch.co.jp/recruitment" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frighttouch.co.jp%2Frecruitment&key=878c5bef402f0b2911bf6d4ce6261abd">採用情報 | 株式会社RightTouch</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>

文脈で検索するシステムを簡単に構築する

<h3>VSCodeの台頭によりエディタ戦争が幕を閉じつつある中で、時代に取り残されたEmacserはどう生きるのか――</h3>
<img src="https://ik.imagekit.io/righttouch/98f45443-7c9c-483a-9898-f456dc449db5/emacs-about-screenshot.jpg" alt="emacs-about-screenshot.jpg">
この画面を見てホッとする人は確実に絶滅危惧種
そうなんです、皆様は驚かれるかもしれませんが、いまだにEmacsをメインエディタ（IDE）に使っている頑固な人間が世の中にいるのです。拙者はその一人、生粋なconfig職人、Emacsの道を8年以上進んでいる者でございます。
Emacserの中では8年はまだまだピチピチの赤ん坊のようなもんで、拙者を超える熟練の猛者がわんさかいらっしゃる中でここでEmacsを語るのは厚かましいのですが、一応知見レベルをざっくり説明すると、
<ul>
<li>Emacsの<a href="https://github.com/amake/.emacs.d/">config</a>をgitで管理していて育成履歴は8年以上（configは相棒みたいなもので転職などを経て自分と共に成長するもの）</li>
<li>いくつかの<a href="https://github.com/amake?tab=repositories&amp;q=&amp;type=source&amp;language=emacs+lisp&amp;sort=stargazers">Emacsパッケージ</a>を執筆し継続的にメンテしている</li>
<li><a href="https://www.macports.org/">MacPorts</a>の<a href="https://ports.macports.org/port/emacs-mac-app/">Emacsポート</a>をメンテしている</li>
<li>Emacs本体（C言語のコア）への貢献はまだしていないが、周辺パッケージはバグ修正を提供したりしている</li>
</ul>
ということで中級の上といったところでしょうか。
<h3>でも…なんで？</h3>
「一体なぜEmacsなんだ」という疑問が自然と湧いてきますが、はじめて触ったのはLISPの勉強がきっかけでした。当時駆け出しの独学プログラマーとして、<a href="http://www.paulgraham.com/lisp.html">Paul Graham氏</a>や<a href="http://norvig.com/Lisp-retro.html">Peter Norvig氏</a>が提唱しているLISP神話に魅了され、LISPの書籍や、Schemeを使った有名なマサチューセッツ工科大学のCSカリキュラム「<a href="https://ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E6%A9%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AE%E6%A7%8B%E9%80%A0%E3%81%A8%E8%A7%A3%E9%87%88">SICP</a>」を勉強するための推奨環境がEmacsをベースとしています。
LISPをかじった多くの方はおそらく「この言語はおもしろいけどあまり現実的ではない」という結論に至ると思いますが、自分もまさにそうでした。ではどうしてEmacsを継続したかというと、神アプリがあるからです。
Magitという、gitインターフェースです。
突然ですが、話を大きく巻き戻します。Emacsとは何なんでしょうか？「エディタ」と答えた方は間違ってはいませんが、少々表面的な理解といえます。Emacsとは、テキストという形のUIでアプリケーションを作る基盤です。Emacsに標準搭載のメインアプリケーションとしてたまたまみなさんが一番馴染んでいるのがエディタというだけなんです。
さて、Magitという神アプリとは、Emacsの中で動くgitインターフェースであって、思考のスピードでキー1つや2つでgitのあらゆる操作ができます。慣れてしまえばGUIやCLIに戻れません。
<h3>IDEとのギャップ</h3>
でも開発までもEmacsの中でやろうというのはあまりにも自虐ではないでしょうか？いやそうでもない、意外と快適であるのは実はVSCodeのおかげでなのです。MicrosoftがVSCodeにあらゆる言語の“ノウハウ”を組み込む代わりに<a href="https://microsoft.github.io/language-server-protocol/">Language Server Protocol</a> (LSP)という形でエディタと言語固有のロジックを分割しましたが、EmacsもLSPに対応することによってVSCodeと同等のIDE機能を持つことができて、不自由なく開発ができます。
弊社で開発しているのは簡単にいうとウェブアプリであり、フロントエンドはサブシステムによってはReactやVue、Svelteなどが使われ、バックエンドはNode.jsで全体を通してTypeScriptを採用しています。ローカル開発の時はDocker Composeでコンテナを立ち上げたりMakefileを叩いたりします。これをすべてEmacsの中で快適にこなせるパッケージを以下にテーマ別で紹介します。
<h4>頑固Emacserのおすすめパッケージ</h4>
<ul>
<li>バージョン管理
<ul>
<li><a href="https://magit.vc/">Magit</a>: 先ほど紹介した、神gitインターフェース。基本操作はもちろん、複雑なinteractive rebaseや行単位のstagingへの追加、blame、reflogなど何でも快適にサクサクできる。</li>
<li><a href="https://github.com/sshaw/git-link">git-link</a>: カーソル位置の行をピンポイントで指すURLを素早くコピー</li>
</ul>
</li>
<li>IDE
<ul>
<li><a href="https://emacs-lsp.github.io/lsp-mode/">lsp-mode</a>: 単なるテキストエディタをIDEにしてくれるパッケージ。様々な言語のLSPサーバを自動インストールできる。</li>
<li><a href="https://www.flycheck.org/en/latest/">Flycheck</a>: コンパイラーやリンターのエラー・警告をインラインで表示する</li>
<li><a href="https://company-mode.github.io/">company-mode</a>: 入力補完。lsp-modeと自動連携する</li>
<li><a href="https://github.com/jscheid/prettier.el">prettier.el</a>: コードフォーマッターを自動的にかけてくれる</li>
<li><a href="https://github.com/zerolfx/copilot.el">copilot.el</a>: 最近話題のAIアシスタントだってEmacsで使える</li>
<li>各言語のモード: yaml-mode, json-mode, web-mode, typescript-modeなどは必要に応じて。ただしEmacs 29からはTree-sitterベースの*-ts-modeが色々ついてくるのでわざわざ追加しないで済むことも</li>
</ul>
</li>
<li>プロジェクト操作
<ul>
<li><a href="https://docs.projectile.mx/projectile/index.html">Projectile</a>: プロジェクト管理パッケージ。.gitフォルダやMakefileでプロジェクトを自動検知する。単体というより次と組み合わせると本領を発揮する</li>
<li><a href="https://github.com/ericdanan/counsel-projectile">counsel-projectile</a>: 現在のプロジェクトの全ファイルをrgで爆速で検索したり、正規表現でファイルを開いたりする</li>
<li><a href="https://github.com/Silex/docker.el">docker.el</a>: Dockerコンテナやイメージを便利に操作・管理できる。Emacsの中の<a href="https://github.com/jesseduffield/lazygit">lazygit</a>のイメージ</li>
<li><a href="https://github.com/akermu/emacs-libvterm">vterm</a>: ターミナルもEmacsでやるならこれに一択</li>
</ul>
</li>
<li>その他
<ul>
<li><a href="https://orgmode.org/">Org</a>: 標準搭載のタスク管理・カレンダー・情報整理・Jupyterノートブック的な何でも屋パッケージ。機能が豊富すぎて10人に聞けば10とおりの使い方が返ってくるけれど、拙者の場合はコードスニペットとその実行結果を簡単に文章と混ぜることで作業メモや調査ログを残すのに使っている。（この記事はOrgで書いてMarkdownに変換してCMSに貼り付けた）</li>
<li><a href="https://ja.wikipedia.org/wiki/ELIZA">ELIZA</a>: 標準搭載の元祖AI相談役。心が病んだときなどはM-x doctorで0割負担の治療を受けられる（効果に個人差あり。改善が見られない方はM-x tetrisをお試しください）</li>
</ul>
</li>
</ul>
関わる案件ごとに多少の調整はするものの、以上の基本構成は8年に渡り数回の転職を経て、仕事も趣味も上手く支えてくれました。やや大きめのモノレポの時代でも、Emacsそのものの高速化（Emacs 28から追加されたnative compilationなど）やワークフローの工夫で難なく対応できてしまいます。
<img src="https://ik.imagekit.io/righttouch/6d9485c6-30d4-4c5c-92ed-7c5e138c1395/emacs-demo.gif" alt="emacs-demo.gif"> 
①ProjectileでプロジェクトのMagitステータス画面を開いて②InterruptCallbackをプロジェクト全体で検索して③LSPで使用箇所から定義に飛んで④ExecutionCallbackにリネームして⑤git fixupで元のコミットを修正するデモ。コードは趣味プロジェクト。
<h3>そこまでしてEmacsにこだわるのか</h3>
前述のリストを見て「いろんなパッケージを入れてconfigをチューニングしないと使えないのか」と、Emacsの価値をあまり感じない方も多いと思いますが、そういう方には“Emacsスターターキット”と呼ばれる、チューニング済みの非公式ディストリビューションをお勧めします。<a href="https://www.spacemacs.org/">Spacemacs</a>や<a href="https://github.com/doomemacs/doomemacs">Doom Emacs</a>がその代表的な例です。
しかし、拙者は公式Emacsのconfig職人の道を選んだのにはわけがあるのです。そのわけとは、次のとおりになります。
<ul>
<li>（4割くらい）キャラ作り。「オフィスの唯一のEmacser」キャラだと勝手に玄人認定されるしなんだかんだネタにできる</li>
<li>（残り6割）真面目な理由
<ul>
<li>プロフェショナルとして、日々使っているツールを徹底的にマスターしたいのでconfigのチューニングは苦ではない。むしろ自分の好みに完全に合わせた、究極のツールに仕上げるのが楽しい。</li>
<li>ほかのツールやシステムがややブラックボックスであるのに対して、Emacsは抽象化レイヤーとして割と薄くて、中の仕組みが見えやすい。開発環境においてEmacsが操作する他パーツの理解が進みやすい。</li>
<li>提供している会社や団体の都合によって使い方を制限されたり、はたや提供を止められて使えなくなるのはもってのほか。GNUの「自由ソフトウェア」理念の賜物であるEmacsは未来永劫なくなることはなく、昨今は不人気なイメージを持たれているが、開発は史上最高レベルに盛んに行われている（成長スピードが周りに比べて遅いだけ）。安心して投資できるのがEmacs。</li>
</ul>
</li>
</ul>
<h3>Emacsのすすめ(or非すすめ)</h3>
ここまでEmacsを散々褒め称えてきましたが、拙者は自由ソフトウェア以外を認めない絶対主義者ではありません。仕事もプライベートも好みでmacOSを使うし、何が何でもすべてをEmacsで行うわけではありません。特に以下はやりようがあっても割に合わないと考え違うソフトウェアを使っています。
<ul>
<li>ブラウザ: 特にmacOSではEmacsの中にウェブブラウザを埋め込む良い方法がないのでメインはFirefoxを使う</li>
<li>メール: あまりメールヘビーなワークフローではないのでmacOSの標準Mail.appで事足りる</li>
<li>文書の共同作業: 同僚に共有したり共同編集したりするような文書やスライドはやはりウェブベースのソリューションを使わざるを得ない</li>
</ul>
Emacsをみなさんに売り込むつもりは特になく、一人で細々とEmacs道を進む拙者は、「Emacser、まだいるぞ」ということを世に示すのが今回の目的でございます。が、もし、この道を共に歩むのに少しでも興味がある（orない）方がいらっしゃったならば、その方に朗報がございます。
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。
${WANTEDLY_LINK}

絶滅危惧種Emacser、TypeScript/Node.js/Reactモノレポ時代を生き抜く

はじめまして、RightTouchでエンジニアをしているikkiです。
RightTouchでは普段の会話や、メンバーを採用するときの基準など、様々な場面で「プロダクト志向」という言葉が登場します。実際、RightTouchのエンジニアメンバーを見ても、プロダクトのことを考えるのが好きで、クライアントやユーザーが抱える課題を解決する手段として技術を用いるといった考えの人が多いです。
ですが、メンバーそれぞれがどういった経緯で「プロダクト志向」を持つようになったのか、また日常のどういったシーンでプロダクト志向を発揮しているのかを実は全然知らないなということに気づきました。普段からよく飛び交う言葉だからこそ、その真意を深く知ることができればより相手のことを理解でき、より良いプロダクトづくりに活かせるのでは？と思い、複数のメンバーに「プロダクト志向」について聞いてみることにしたのが本シリーズです。
シリーズは3回に分け、RightTouchのエンジニア3職種それぞれに1人ずつ話を聞いていきます。
<ul>
<li>プロダクトエンジニア: 
仕様検討や設計、開発をメインに行うエンジニア 
領域を絞らず基本的に開発に関わることは何でもやります</li>
<li>デザインエンジニア: 
HTML/CSSなどデザインよりの技術に長けたエンジニア 
主にフロントエンドをメインに開発を行います(HTML/CSSの周りの啓蒙活動も)</li>
<li>カスタマーエンジニア: 
プロダクトのスペシャリストとしてプロダクトと顧客をつなぐエンジニア 
顧客とのコミュニケーションからコンセプトレベルの機能のデモ開発まで幅広くやります</li>
</ul>
シリーズ第1弾は、プロダクトエンジニアであり開発責任者でもあるyabuさんにインタビューしてみました。
<h2>プロダクトエンジニアyabuさんの考える「プロダクト志向」</h2>
ーーまずyabuさんの経歴を教えてください！ 
yabu: 新卒でSIer系の会社に入りました。受託メインではありつつも、なかなか珍しいシステム案件だったのを覚えています。 
その後、知人と起業してtoCプロダクトを開発しました。起業が一段落したタイミングでiPhoneが流行したことをきっかけに、これからはモバイルアプリの時代だと感じてアプリ開発をメインに行う事業会社に移り、主に写真アプリを開発していました。その後プレイドに転職し、現在はRightTouchで開発責任者兼エンジニアとしてプロダクト全体を見ています。
ーーyabuさんにとって「プロダクト志向」はどういうものだと捉えていますか？ 
yabu：自分たちが作っているプロダクトが社会もしくは個々人にとって良いものだと信じ、そのプロダクトが実現する世界に向かって突き進んでいくエンジンとなる考え方、ですかね。
ーー「プロダクト志向」を抽象度高く捉えているんですね！その価値観は、いつ頃から形作られてきたと思いますか？ 
yabu：起業していた頃は、まだ比較的技術志向だったと思います。尖った技術を使うのがかっこいいと思っていたと思います。当時作っていたサービスは、今でいうNewsPicksのようなもので世の中に散らばったニュースを集約して、その集約した情報をもとに人々の議論が活性化されることを期待していました。その観点では「このプロダクトがあれば、もっと良い社会になる」と思うものにはずっと強く心が惹かれてきたので、本質的にはずっとプロダクト志向なのだと思います。
ーー開発してきたサービスはかなり幅広いと思います。これまでの経験から好むサービスの傾向はありますか？ 
yabu：「理想を実現できる生活に根差したインフラ」は好きですね。 
原体験の一つとしては、写真サービスをやっていた時のコンセプトが、散らばっている写真データを集約してインフラ化するというものがあります。当時はGoogleフォトもなかったので「そんな新しい生活様式を実現できたら良いよね！」という理想からの逆算で考えていました。 
最近だとGenerative AI のような、みんながこうなったら良いと思っている理想を叶えるブレイクスルー、パラダイム・シフト感のある技術・サービスはやはり面白いと思っています。あと、レバレッジが効くプロダクトは魅力的に見えますね。
ーーRightTouchでも、技術的なブレイクスルーをつくっていきたいと思いますか？ 
yabu：もちろん世の中に今までにない新しいアイディアを思いついたり、最新の技術を用いて作ったりしたい気持ちがないわけではありません。ただ、人生は有限で短いので、技術的な新しさを追い求める以外の方法でも、ブレイクスルーは生み出せると思っています。 
自分が社会にブレイクスルーをもたらすための方法としては、理想の姿は見えているけど、それを解決する技術や人との接続がうまくできていなかったために、長年放置されてきてしまった課題に取り組むアプローチを選択したいと思っています。まさに、RightTouchがカスタマーサポート業界に向けて行っているものですね。 
業界規模やステークホルダーも多く、それでいてデジタル・技術で解決できる余白がある。つまりシンプルにインパクトを与えられる範囲が大きいので、面白さもやりがいもあり、かつカスタマーサポート業界にブレイクスルーを生み出せる機会だなと思っています。
ーープロダクト開発では、既存機能を改善するいわゆる連続的な部分と、ゴールから逆算して今ないものをつくる非連続的な部分の両方を考える必要があると思います。yabuさんは普段どんなフローでプロダクト作りを考えていますか？ 
yabu：開発のフロー的にはそこまで変わった部分はないですね。デザイナーなどと協力しながらUIと仕様を作りつつ、実装しながら微妙なところを手戻りを恐れず直していくという感じです。 
フローというかチームでのプロダクトづくりの考え方としては、普段の何気ない会話から生まれるアイデアや、チーム内に何かを面白がっている人がいたらそれを信じてみる、といったことは大切にしていますね。 
前提として、プロダクト開発は長い時間をかけて、その中で積み重ねてきた思考から生まれるものだと思っています。過去に話題に上がった機能で、そのタイミングではそこまで深められなかったものだとしても、時期が変われば「これいいじゃん！」と見方が変わるものはたくさんあります。 その上で、今のプロダクトに本当に必要なものの優先順位をつけて作っていくことが多いですね。
ーー素敵な考え方ですね。計画的に作られる機能だけでなく、日常の何気ない会話から生まれる機能があるということですね。 
yabu：そうですね。メンバーがプロダクトのことを考えやすい、あるいは考えたことを発信しやすい環境や文化づくりは意識していると思います。自分の働きかけとしても、意識的に雑談を増やしたりするようにしています。 
リアルタイムで「このチームってプロダクト志向！」なんて話すことはないですが、日々プロダクトのことを考えて機能のアイディアが出てきたり、オフサイトでもプロダクトはどうしたらもっと良くなるかを延々と議論し続けられたりする様子を思えば、みんなプロダクト志向なんだなと感じます。
ーー最後に、もしあらゆる制約をなくして何か作れるとしたらどんなものを作りたいですか？ 
yabu： 難しい質問ですね…。前から思っているところでいうと「娯楽としての食事と栄養的な食事を分離したい」というのはありますね。脳に直接刺激を与えるのか、VRで五感を再現するのか、手段は色々あると思いますが、人間がカロリーを気にせず食事をできる世界が来てほしいです！
ーーyabuさんらしさ全開のめちゃくちゃ面白いアイデアですね(笑) 今日はありがとうございました！
<h2>一緒に働くメンバーを募集中</h2>
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}

あなたにとっての「プロダクト志向」教えてください！〜プロダクトエンジニア編〜

カスタマーサポート領域事業を複数展開する、私たちRightTouch。10月には、β版として提供してきたWebサポートプラットフォーム<a href="https://prtimes.jp/main/html/rd/p/000000008.000098678.html">「RightSupport by KARTE」</a>が正式リリースとなり、また新プロダクトの<a href="https://prtimes.jp/main/html/rd/p/000000007.000098678.html">「RightConnect by KARTE」</a>の提供も開始されるなど、プロダクト・チーム共に日々進化しています。
ですが、開発を担うRightTouchのエンジニアは、まだ約10名ほど。2023年11月現在、エンジニアメンバーはRightSupportチーム・RightConnectチーム・Talkチームとプロダクト機能ごとに3つのチームに分かれています。エンジニアチームは、どのような取り組みやコミュニケーションを行い、立て続けのリリースを、着実に前進させてきたのでしょうか？ 
チームそれぞれの特徴や仕事の進め方、今後の課題など、各チームのリーダーに座談会形式で話を伺いました！
<h3>座談会参加メンバー</h3>
RightSupportチームリーダー・yabuさん 
RightConnectチームリーダー・ikkiさん 
Talkチームリーダー・Aaronさん 
<img src="https://ik.imagekit.io/righttouch/bdd26b43-057a-4691-9322-ec2bd97c2592/Group21.png" alt="Group21.png">
<h3>――それぞれのチームのメンバーや役割など、特徴について教えてください。</h3>
yabu：RightSupportチームは、RightTouchの主プロダクトであるWebプラットフォーム「RightSupport by KARTE」を担当しているチームです。体制としてはエンジニア5人、デザイナー1人の計6人で、PdMは僕自身がエンジニア兼務で担当しています。
RightSupport自体が、RightTouchが提供するプロダクト全ての開発基盤でもあるため、他の2つのチームが担当していないものは全て見ているような位置付けです。また、新しく入社した人にはまず、RightSupportチームに加わってもらうようにしています。RightSupportの基盤やコードを見ることで、プロダクト全体を把握しやすいこともあり、オンボーディングを兼ねたOJTが行いやすいからです。
ikki：2023年10月17日から提供を開始した<a href="https://prtimes.jp/main/html/rd/p/000000007.000098678.html">「RightConnect by KARTE（β）」</a>の開発をしているチームです。yabuさんのRightSupportが、問い合わせ「前」の顧客体験を扱っているのに対し、RightConnectはその後のプロセス、つまり電話での問い合わせ体験と問い合わせオペレータの対応プロセスを変革することを目的にしたプロダクトです。
現在のメンバー構成はPdMが1人、カスタマーエンジニアが1人、エンジニアが3人の計5人です。新プロダクトを担当しているチームなので、顧客の生の声を集め、それを元に設計・開発・改善を重ねていくことが特に強く求められるフェーズなのが特徴だと思います。複数の職種で構成されたチームなので、様々な視点からプロダクトの議論ができるのは面白いですね。特に今は、リリース前でタスクも多いことから、エンジニアメンバーは、やるべきことを黙々と着実に進められる人が多い印象です。
aaron：Talkチームは、グループ会社のプレイドがもともと開発・運営していたプロダクトを、RightTouch設立時にRightSupport内の一つの機能として引き継いだチームになります。チームメンバーはエンジニアが2人、外部委託のエンジニアが1人、そしてPdMのチームです。
他2つのチームは、ゼロスクラッチで新しいプロダクトを開発していますが、Talkはその前提が異なります。KARTE内での歴史・顧客がすでにあるプロダクトなので、その引き継ぎをRightTouchの方に行いながら、並行して障害や問い合わせなどの顧客対応をしてきました。そのため、つい最近まで新しい開発に時間を割くことができていませんでした。移行作業がようやく落ち着いてきたので、新規開発の余裕が生まれ始めてきたところです。顧客やプレイド側との調整も多いため、総合的な技術力が求められるだけでなく、ハードシングスにも臆せず対応することが必要とされるチームかもしれません。 
<img src="https://ik.imagekit.io/righttouch/3fb2fa4a-1d11-4c95-9ade-c51c6416af85/s-RightTouch_231499.jpg" alt="s-RightTouch_231499.jpg">
<h3>――RightTouchのような創業期だと、どのタスクも緊急度が高く、やりたいことが溢れている印象があります。どのように目標や優先すべきタスクを決め、組織・プロダクトとしての前進を図っているのですか。</h3>
yabu：エンジニアチーム全体で、3ヶ月単位の目標を立てています。これは全社の四半期目標から紐づいて設計されています。Q期初のキックオフでチームごとに目標を発表しています。
半年ほど前までは、目標共有後に細かな進捗を確認することはあえてしていませんでした。というのも、メンバー人数がそう多くなく、開発プロダクトもRightSupport一つだけだったので、言ってしまえば“阿吽の呼吸”で進捗できていたからです。
ですが新しい仲間も増え、プロダクトも複数になる中、チームとして各自が何をやっているかが見えない状況はまずいと思い、半年ほど前からやり方を変えました。今は、Q初めにチームで集まり、全社目標を達成するために何をやるのかといったタスク整理だけでなく、何のためにやるのか、どういう状態だと達成したと言えるのか、誰がやるのがベストか、といったことをみっちり話し合い、Notionにタスクボードとしてデータベース化しています。取り組むべきアクションや開発項目が一覧化され、進捗状況をいつでも誰でも確認できるようになったので、チーム間での可視化が進みました。 
<img src="https://ik.imagekit.io/righttouch/a0947185-1d21-404f-aee0-e9925377ae78/Group22.png" alt="Group22.png">
<center>タスクボードNotionの一部</center>
ikki：RightConnectチームはやるべきことが明確＝プロダクトリリースだったこともあり、タスクの管理らしいことはしていませんでした。ですが、yabuさんが始めたタスクボードのやり方が良いなと感じ、今Qから取り入れています。リリースもひと段落したところですが、今後はタスクや改善事項も増えてくると思います。ボードを参考に、優先度やアサイン状況を可視化していきながら開発計画を立てていきたいと考えています。
aaron：Talkチームは、業務内容と人数の制約から、今までは顧客要望や社内フィードバックをベースにやることを決定し、管理していました。今後はそのフィードバックも落ち着いてくるので、自分たちのタスク管理が重要になってくると考えています。
yabu：もちろん常に開発スケジュールに余裕があるわけではなく、全社で決まったリリース日や、緊急度の高い顧客要望など、期限にヒリヒリしながら対応することもあります。ですが、RightTouchが大事にするのはバリューでもある「インパクト志向」。リリース日が迫ってもクオリティが低ければ、大胆にスケジュールを引き直しますし、より大きなインパクトが出せる機能が提案されれば、現状のタスクを止めてそちらに舵を切ることも厭いません。
タスクやフィードバックはもちろん重要ですが、それを鵜呑みにしすぎず、「もっとインパクトが出せる方法はないんだっけ？」という対話をチームでも増やして、効果的な目標設計やタスク管理を継続して模索したいと思っています。 
<img src="https://ik.imagekit.io/righttouch/19e5eec8-fea6-4731-a30b-00f9344dfc46/s-RightTouch_231267.jpg" alt="s-RightTouch_231267.jpg">
<h3>――チーム内では、どのようにコミュニケーションを取っているんですか？</h3>
yabu：RightSupportチームでは、完全リモートや半分出社など出社体制がバラバラなので、オフラインで気が向いたときに話す時間を設けています。また、バーチャルオフィス「Around」に入って話すこともあります。
aaron：Talkチームは随時コミュニケーションをとっているわけではありませんが、困ったことが出てきたときはSlackやZoomで話し合いや議論を重ねるようにしています。
ikki：RightConnectチームも、出社スタイルはバラバラなので、コミュニケーションの選択肢を活用してメリハリをつけています。特にプロダクトリリース前は、細かい調整や議論など対面で行った方がスムーズに進むものもあったので、その類のものは意識してオフィスで行うようにしていました。オフィスも広くなって、エンジニアにとっても快適な環境になりましたからね！
yabu：また、RightTouch全社の取り組みとしては、四半期に1回のオフサイトと月1回の全社振り返り会を行っています。エンジニアチーム横断では、隔週に1回Demo Dayを開催しています。チームごとに担当プロダクトが異なっているので、細かい仕様や設計の裏側まで把握することは正直難しいです。そこで、開発担当者がデモを見せながら詳細を発表することで、その情報格差を埋めることを目的にしています。Demo Dayが形式化しないように、慢心することなく改善し続けたいと思っています。 
<img src="https://ik.imagekit.io/righttouch/90df7049-12bd-4fd1-a6e9-9a2e9f997461/Group23.png" alt="Group23.png">
<center>Demo Dayの様子</center>
<h3>――各チームそれぞれが考える今後の課題は何ですか？</h3>
aaron：今までのTalkチームは、チームとしての品質担保よりも、とにかくスピード重視で顧客リクエストに対処することを最優先にしてきました。ですが、ここからは人数も増えていくフェーズです。より「チーム」を意識したレビュー・実装体制に変えていかなくてはいけないと思っています。スピーディーかつタイムリーにレビューできるような方法・体制を考えるのがこれからの課題ですね。
yabu：RightSupportチームの課題は、開発スピードを落とさないようにしながらも技術負債を減らしていくバランスを取ることですね。プロダクトフィードバックは、チケット化して貯めていますが、最近はチケットが増える一方で（苦笑）クリティカルな問題はすぐに解消していますが、手が回り切っていない段階です。プロダクトの立ち上げ期だと、どうしても新規の開発にリソースが割かれてしまいますが、中長期的なインパクトを担保するためにも、負債へ対応できる余裕を仕組みを作ってうまく生み出していけたらと考えています。
ikki：チームとしての進捗している実感をもっと醸成していきたいです。直近はリリース作業に追われていたので、それぞれがタスクをこなすことに必死でした。プロダクトのフェーズが変わったので、属人化を脱し、細かいゴールを設定・共有しながらチームで前に進んでいることを実感できるよう、タスクボードの運用など一歩一歩積み重ねていきたいです。 
<img src="https://ik.imagekit.io/righttouch/576e5102-9f61-4487-87ce-87c2d34fe923/IMG_0840.JPG" alt="IMG_0840.JPG">
<hr>
今回の記事では、RightTouchエンジニアメンバーが属する3つのチームの特徴を紹介しました。組織・プロダクトフェーズにとって最適な体制をとっているので、今後変わっていく可能性はもちろんありますが、今のRightTouchを少しでも知っていただけたなら嬉しいです！
より細かいチームの情報は、カジュアル面談などでお話したいと思いますので、少しでも興味を持ってくださったら、採用サイトやWantedlyからぜひ気軽にエントリーください。
▼採用サイト 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a> 
▼Wantedly 
<a href="https://www.wantedly.com/projects/1493065">https://www.wantedly.com/projects/1493065</a>

RightTouchエンジニア３チームそれぞれの特徴と課題をチームリーダーに聞いてみた！【2023年11月ver.】

<h1>はじめに</h1>
先日、RightTouchの新プロダクト「<a href="https://rightconnect.karte.io/">RightConnect by KARTE</a>」のβ版がリリースされました。
このプロダクトは問い合わせ体験における、Webサイトと電話の分断をなくし、顧客とオペレーターの両方の満足度を高めることを目指しています。
従来の電話問い合わせは下図の様なフローで表現できます。
<img src="https://ik.imagekit.io/righttouch/2bdca1f3-e594-49f4-930a-94fe9638bf14/connect_1.png" alt="connect_1.png">
図にもある通り、このフローにはいくつか課題があります。
<ol>
<li>
顧客の要件把握問題
電話問い合わせの際、IVR（Interactive Voice Response）を用いて顧客の要件を事前に把握することが多いです。しかし、選択肢の限定性により、実際の顧客のニーズとの間にギャップが生じることがあります。その結果、オペレーターへの通電後も追加の情報収集が必要となり、通話時間の延長や顧客の不満につながることがあります。
</li>
<li>
オペレーターのミスマッチ課題
顧客の問い合わせ内容とオペレーターの専門性のミスマッチは、サービスの質に影響を与える重要な課題です。この問題は、Webサービスの日々の変化と、CTI（Computer Telephony Integration）システムを手動で更新する必要があることに起因します。最新のサービス情報に基づいてCTIが設定されていない場合、顧客と繋がるオペレーターが適切な対応ができないことがあります。このミスマッチを減らすには、CTIシステムの定期的な更新と、オペレーターのスキルに合わせた問い合わせの割り当てが必要です。
</li>
<li>
Webサイトと電話の間での顧客情報・顧客体験分断の課題
顧客対応における大きな課題の一つは、Webサイト上での顧客の行動データと電話システムとの間で情報が共有されないことによる分断です。顧客がサイト上で行ったページ閲覧履歴、ウィジェット操作、ポップアップの利用、Webフォームへの入力などの行動データは、貴重な情報源です。これらのデータはCRMなどのシステムを通じて一部オペレーターに共有されますが、多くの場合、電話という異なるインタフェースに切り替わる際に失われてしまいます。
</li>
</ol>
これらの課題は、顧客の満足度やコールセンターの業績指標に直接影響を与える重要な要素です。
この記事ではRightConnectでどのように上記の課題を解決するのかと一部システムの裏側で行われている工夫を紹介します。
<h1>RightConnectの概要</h1>
まずはじめに、RightConnectは４つの要素で構成されています。
<ul>
<li>ウィジェットによるリーズンの絞り込みと問い合わせ導線ごとのチャネル切り替え</li>
<li>問い合わせ前のアンケートによる共通項目の聴取</li>
<li>問い合わせ番号ベースのオペレーターへの情報還元</li>
<li>オペレーター向け画面による応対の効率化</li>
</ul>
これらの要素を使って実際に応対を始めるまでのデモがこちらです。
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe src="https://www.youtube.com/embed/DYdeEgKluoA?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share;"></iframe></div>
<h2>全体の流れ</h2>
顧客とオペレーターそれぞれの視点でどのような操作を行うかをまとめると、下記のような感じになります。
<h3>顧客視点</h3>
<ol>
<li>Webサイト上のウィジェットから問い合わせ番号を発行</li>
<li>ウィジェットに表示された電話番号に架電し、発行した問い合わせ番号を入力</li>
<li>CTIを通じて適切なオペレーターへのルーティングがされたうえで通電</li>
</ol>
<h3>オペレーター視点</h3>
<ol>
<li>受電履歴ページを開いておく</li>
<li>CTIからルーティングされた問い合わせ電話を受電</li>
<li>問い合わせに紐づくユーザーのダッシュボードが自動で開かれる</li>
<li>ダッシュボードを見ながら応対を行う</li>
</ol>
さらにシステム含めて流れを図にすると下記のようになります。
<img src="https://ik.imagekit.io/righttouch/278f9509-773f-4881-ba37-90976ad63460/connect_2.png" alt="connect_2.png">
ウィジェットから問い合わせ番号を発行することで架電時のIVRのステップを大幅に削減しつつ、ウィジェット内の窓口ごとにルーティングを行うことによってオペレーターとのミスマッチを減らすことができます。また、問い合わせ直前に事前アンケートを行うことで通電後に共通で聞いている内容などもWeb上で回答し、オペレーターに共有された状態で会話を開始することができます。
<h2>ダッシュボード</h2>
次にRightConnectにおいて肝となるダッシュボードを紹介します。
ダッシュボードは下図のような画面であり、大きく4つの機能を持ちます。
<img src="https://ik.imagekit.io/righttouch/52095f9b-4459-49da-a43f-72fb52d6a965/connect_3.png" alt="connect_3.png">
<h3>①問い合わせ基本情報</h3>
ユーザーの一時ID、オンライン・オフライン、ウィジェット上での行動データや事前アンケート項目への回答、問い合わせリーズンなど問い合わせユーザーのこれまでと現状を把握するための情報が表示されます。
<h3>②ユーザーセグメント</h3>
KARTEのセグメント機能を利用しています。エンドユーザーの属性（ログイン・未ログイン、契約済み、など）から応対に必要なものを選択して表示することができます。
<h3>③KARTE イベント</h3>
BigQueryに溜まっているWeb上での行動データ（KARTEイベント）から今回のセッションやそのユーザーに紐づくものを集計し、表示します。応対に必要なイベント、カラムに絞って表示することができます。
<h3>④Liveストリーミング</h3>
KARTEのLiveストリーミング機能を利用しています。リアルタイムにお客さんの画面を見ることができるため、特にWeb上での操作が必要になるお問い合わせなどでスムーズな応対が可能になります。また、マウスポインタ共有機能(α機能)を用いて、オペレーターが実際に問い合わせユーザーの画面上にポインタを表示しながらの応対をすることもできます。
オペレーターはダッシュボードを使うことで、Web上でのこれまでの顧客の様々なデータと現時点のステータスを把握しながらの応対をすることが可能になります。（課題③）
<h1>技術的制約と工夫</h1>
このプロダクトの特徴的な要件として、上述の通りダッシュボードをオペレーターが電話応対しながらリアルタイムで利用することがあげられます。
そのため、オペレーターが受電してから素早くダッシュボードが表示され、見たい情報を変更しながら確認できる即時性が重要になります。
しかし、技術的に以下の課題がありました。
<ul>
<li>問い合わせユーザーの行動データが BigQuery に大量に保存されており、取得に時間がかかる</li>
</ul>
クエリの速度とデータ量の問題により、 BigQuery へのクエリを最適化しても何秒もかかる状態でした。
シンプルに大きく以下の2つで対策をとりました。
<ul>
<li>事前キャッシュ</li>
<li>情報の表示優先度を決めてキャッシュ</li>
</ul>
<h2>事前キャッシュ</h2>
取得にどうしても時間がかかるのであれば、事前にキャッシュすれば、解決します。
大事なのは、どのタイミングでキャッシュ処理を実行するかになります。
そこで、ユーザー問い合わせの流れの <code>お問い合わせ番号発行 ~ オペレーター通電</code> までのラグがあることを利用しました。
ユーザーのお問い合わせ番号発行のタイミングで、ダッシュボードに必要な情報キャッシュするジョブを PubSub に Publish して、ジョブを実行して BigQuery から取得して Redis にキャッシュしています。
これにより、ダッシュボードに必要なデータをすべてキャッシュから取得できるようになり、表示速度を劇的に改善できました。
<h2>情報の表示優先度を決めてキャッシュ</h2>
<code>お問い合わせ番号発行 ~ オペレーター通電</code> までのラグを利用して事前にキャッシュしていましたが、そのラグが短い場合、キャッシュが間に合わないケースがありました。
キャッシュが間に合わないと、表示に何秒もかかってしまうため、オペレーターがプロダクトを有効活用することができません。
そこで、カスタマーサポートのオペレーターの対応の流れに合わせて、ダッシュボードで何のデータを先に表示すべきかそれぞれの情報の優先度を決めてキャッシュの仕組みを変更しました。
カスタマーサポートのオペレーターの対応の流れを簡略化すると以下のようなものになります。カッコ内は上記システムの流れ、ダッシュボード内の該当機能。
(受電)
<ol>
<li><code>問い合わせ内容確認</code> (①問い合わせ基本情報)</li>
<li>詳細要件確認 (②ユーザーセグメント, ③KARTE イベント)</li>
<li>対応 (④Liveストリーミング)</li>
</ol>
(終電)
このオペレーターが最初に行う、 <code>問い合わせ内容確認</code>に着目し、 ユーザー行動の<code>問い合わせ内容確認</code> に必要なデータを抽出し、BigQueryを介さずにそのままキャッシュできる機構を用意しました。
これにより、ラグが極端に短い場合でも、 <code>問い合わせ内容確認</code> に必要なキャッシュを間に合わせることができました。対応時にダッシュボードの他のデータがキャッシュが間に合っていなくても、オペレーターが <code>問い合わせ内容確認</code> をしている間に、すべてのデータも表示されます。
<h1>おわりに</h1>
この記事では電話問い合わせにおける課題とそれを解決するプロダクト「RightConnect by KARTE」の概要、技術的な制約について紹介しました。
RightConnect by KARTEはまだβリリースであり、今後も顧客と企業双方に価値を提供できるようにどんどん進化していきます。
カスタマーサポートという領域は長い歴史を持ち、多くの課題を抱えています。実際の現場に入り込みながら技術で課題を解いていく、そんなプロダクト開発に興味がある方はぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}

RightConnect by KARTEの裏側

RightTouchには、現在10名のエンジニアが在籍しています。まだまだ小規模なチームではありますが、母体となるプレイドから移籍したメンバーだけでなく、RightTouchにダイレクトに中途入社したメンバーなどバックグラウンドは様々。また、研究開発からエンジニアに転向した人など、開発歴や作ってきたプロダクトの種類も多様です。
この記事では、そんな個性豊かなRightTouchエンジニアチームの雰囲気や環境を、エンジニアチームへのアンケートと、テックリード齋藤のインタビューを交えながらお伝えしたいと思います！
<h2>所属経緯を教えてください！</h2>
プレイドの新規事業からスピンアウトしてできたRightTouch。創業初期フェーズにあるため、プレイドと兼務する人もいるものの、RightTouchに直接転職した人も4割を占め、独自のカルチャーや志向も育まれています。 
<img src="https://ik.imagekit.io/righttouch/47f1722d-b9cd-4ec2-8abf-4b68fe5f8f57/PurpleRectanglePitchDeckMarketingPresentation.png" alt="PurpleRectanglePitchDeckMarketingPresentation.png"> 
ーーRightTouchらしいと思うカルチャーや志向の特徴はありますか？ 
齋藤：「インパクト志向」というのは、特徴だと思います！技術に溺れるのではなく、プロダクトを通じて、顧客・社会にどれほど大きなインパクトが与えられるか、という発想で日々開発に向き合っています。エンジニアに限らず「全員プロダクト担当」という意識が根付いているので、「安定していて確実だけどインパクトが低いモノより、爆発的なインパクトを生み出せる可能性があるモノを選択する」という点にバリューを見出していますね。
<h2>全員スタートアップで働いた経験があるんですか？</h2>
この回答は「NO」。スタートアップでの経験が「ない・初めて」の人がわずかに多いという結果でした。過去のスタートアップ経験を活かし貢献してくれるメンバーと、期待と野心をもって初めての環境に飛び込んできたメンバーが半々いる環境なので、スタートアップ経験の有無を壁だと感じる必要はありません！ 
<img src="https://ik.imagekit.io/righttouch/e1d51b5a-b536-45c8-99c9-6c5a6e5452d0/PurpleRectanglePitchDeckMarketingPresentation(1).png" alt="PurpleRectanglePitchDeckMarketingPresentation(1).png"> 
ーー齋藤さんも前職は日立製作所と大企業です。スタートアップへの転職に不安はありませんでしたか？また、今「スタートアップ・創業期らしいな」と感じる日常シーンはありますか？ 
齋藤： 
「組織のフラットさ」と「スピード感」から、スタートアップらしさを感じています。 
大企業だと、隣の部署は分からない・社長と話す機会なんてない、というのが当たり前。RightTouchは規模がまだ小さいこともありますが、人柄としても全員がフラットです。フラットな関係が保たれているのも、意思決定に「ロジック」や「データ」を重視しているからだと思います。実際、雑談やSlack上での発言から、プロダクト開発につながったこともあります。また、組織全員がプロダクト志向なので、顧客に価値を届けることを最優先に考えています。社内調整や煩雑な手続きがないので、プロダクトを世に出すスピードが圧倒的に早いのも大企業とのちがいだなと感じています。
<h2>RightTouchの技術スタックは？</h2>
プロダクト志向の強いRightTouchでは、言語やフレームワークに縛られすぎず、プロダクト価値を最大化する方法を模索し続け、より良い環境の整備・構築に投資しています。ですので、今後変更する可能性はありますが、現時点での技術スタック一覧を公開します！
<ul>
<li>プログラミング言語 / Library
<ul>
<li>Web Frontend
<ul>
<li>HTML, CSS, JavaScript, TypeScript, React, Preact, Next.js, Svelte, Jest, Vite</li>
</ul>
</li>
<li>Backend
<ul>
<li>TypeScript, Python, Node.js, express</li>
</ul>
</li>
</ul>
</li>
<li>Infrastructure
<ul>
<li>Google Cloud, Amazon Web Service, Fastly, Elastic Cloud</li>
</ul>
</li>
<li>Middleware
<ul>
<li>nginx, Cloud Pub/Sub, Redis,</li>
</ul>
</li>
<li>Database
<ul>
<li>MongoDB, Cloud Spanner</li>
</ul>
</li>
<li>Storage
<ul>
<li>Cloud Storage, Amazon S3</li>
</ul>
</li>
<li>Monitoring
<ul>
<li>Datadog, Sentry</li>
</ul>
</li>
<li>Data analytics
<ul>
<li>BigQuery, Vertex AI</li>
</ul>
</li>
<li>Environment setup
<ul>
<li>Docker, Terraform</li>
</ul>
</li>
<li>Container Orchestration
<ul>
<li>Kubernetes</li>
</ul>
</li>
<li>CI
<ul>
<li>CircleCI, GitHub Actions, Cloud Build</li>
</ul>
</li>
<li>Search Engine
<ul>
<li>Elasticsearch</li>
</ul>
</li>
<li>Code Management
<ul>
<li>GitHub</li>
</ul>
</li>
<li>Test automation tools
<ul>
<li>CircleCI, MagicPod</li>
</ul>
</li>
<li>AI Service
<ul>
<li>Azure OpenAI Service</li>
</ul>
</li>
</ul>
<h2>エンジニアとしてどんな経験をしてきた人が多いですか？</h2>
エンジニアとして経験領域が幅広いことは、RightTouchエンジニアの特徴です。 
<img src="https://ik.imagekit.io/righttouch/f4565126-6ede-45f4-a684-c2620e46ee7c/PurpleRectanglePitchDeckMarketingPresentation(4).png" alt="PurpleRectanglePitchDeckMarketingPresentation(4).png"> 
ーーなぜRightTouchには、幅広い経験を持つエンジニアが多いんですか？また入社時点で、いわゆる“フルスタック”エンジニアであることは必須ですか？ 
齋藤：入社時点では、フルスタックである必要は必ずしもありません。僕自身、入社時点ではSQLなどバックエンドの経験がなく、とにかく聞く・勉強するを繰り返していました。経験や知識が足りないことで立ち止まるのではなく、「なんでも良いからアウトプットを出せるか」「自分が貢献できるところを探しに行けるか」という積極性と自走力は、エンジニアとして活躍しつづけるためにも大事な姿勢だと思います。
RightTouchのメンバーは、聞けばポジティブな反応やリアクションを必ずくれる、そんな安心感があるチームです。最初から完璧である必要はないので、まずは手を動かして、何かをアウトプットしてみる。そうすれば、メンバーが反応をくれたり、こういうことができる人なんだという認知が得られ、できることや任されることが増えていく「正のフィードバックループ」が回りやすい環境です。自分の働きかけ次第で、知識・経験、そして裁量が広げられることに魅力を感じるエンジニアにはフィットすると思います！
<h2>オンボーディングには、どんなものが提供されますか？</h2>
ーー明確なオンボーディングプログラムはまだない状況かもしれません。今は、どのようなオンボーディング期間になっていますか？ 
齋藤：そうですね。まだ発展途上のチームなので、明確なオンボーディングプログラムはありません。ドキュメントを見たり、すでにいるメンバーとコミュニケーションしたりしながら、具体的な機能開発を通じて、オンボーディングしていただく状況です。求めたら期待以上にサポートの手を差し伸べてくれるメンバーばかりなので、先ほど伝えたような自走力・積極性をもってチームや開発に入っていってほしいなと思っています！
また、職種を超えた制度としては、Newcomerを囲むランチ会が始まっています。
<h2>エンジニア経験が長くないと、活躍は難しいですか？</h2>
RightTouchエンジニアメンバーは、なんと約半数が「エンジニア以外の職種経験もあり」との回答で、Webデザイナー・研究開発・塾講師・翻訳者といった経験があります。そして、経験年数を問わず多様なバックグラウンドを持つメンバーが活躍しています。 
<img src="https://ik.imagekit.io/righttouch/cc994acf-ca4d-416a-b963-8b8391b76eb9/PurpleRectanglePitchDeckMarketingPresentation(2).png" alt="PurpleRectanglePitchDeckMarketingPresentation(2).png"> 
ーー齋藤さんは、前職で研究開発に携わっていたとのこと。当時の経験が今につながっていると思うことはありますか？ 
齋藤：研究開発は、仕事そのものというより考え方の部分でつながりを感じます。角度は異なりますが、研究に新規性がないと採用されないので、ある意味「インパクト志向」で物事を考えていたとは思います。 
実務でも役立っている例だと、デザイナー出身のエンジニアの人は、社内デザインチームのリソースが逼迫しているときは自分でデザインをして開発を前に進めてくれたり、デザイン観点を含めた実装やコードの書き方などのアイディアを共有してくれたりしています。
<h2>エンジニアチームは、普段どんな感じですか？</h2>
ーーエンジニアチームの構成はどうなっていますか？また、エンジニアの会議頻度や内容はどういったものですか？ 
齋藤：エンジニアは、今プロダクトごとに3つのチームに分かれています。基本的には、チームごとにプロダクトマネージャーがいて、それぞれのチームで定例やコミュニケーションを行っています。バーチャルオフィス「Around」のほか、Slack・対面など組み合わせながらコミュニケーションしています。
チーム横断でのキャッチアップのために、二週間に一度は「Demo Day」を開催しています。これは直近リリースしたプロダクトや機能を、開発したメンバー自身が他チームにデモするものです。普段、技術的に細かな点まで把握できない他チームの開発の詳細を把握できるので、勉強にもなりますし、実務にも役立ちます。
また毎月一回は全社会もあり、カジュアルのものだと隔週に一回「Devランチ」という技術談義をしながらゆるく話をする場や、メンバー持ち回りでの技術勉強会もあります。
<h2>エンジニアチーム以外はどんな雰囲気ですか？</h2>
ーー今までエンジニアチームを中心に話を聞いてきましたが、エンジニアから見て他チームはどのような特徴があると感じますか？ 
齋藤：冒頭に話した「インパクト志向」「プロダクト志向」は全員共通して持っていますね。エンジニアも含めたチーム全体に共通することを、他に2つ紹介させてください。ひとつは、プロダクト開発の議論に透明性があること。議論の過程を、各プロダクトマネージャー中心にSlackやNotionに残しており、それを誰でも閲覧できます。思考や意思決定の過程に透明性が保証されている安心感があります。もうひとつは、データドリブンな意思決定が当たり前なこと。「その機能がどんなインパクトを提供できるか？」を決めるにあたり、「Who」ではなく「What」つまりデータを起点にしています。入社時期や経験によらない提案やコミュニケーションができるのは、エンジニアチームに限らない特徴だと思います。
<h2>リモート？オフィス？出社頻度の実態はどのくらい？</h2>
<img src="https://ik.imagekit.io/righttouch/6b953b3a-ee0f-43dc-a6eb-25e6681de42a/PurpleRectanglePitchDeckMarketingPresentation(3).png" alt="PurpleRectanglePitchDeckMarketingPresentation(3).png"> 
RightTouchは、2023年9月にオフィスを三田に移転し、今後の組織拡大の基盤を整えています。（エンジニア用のデスクが幅広だったり、オフィス環境も良好です！）PMFフェーズで、対面で議論する中で生まれるアイディアや気づきも多くあるため、現在はリモートワークと出社を組み合わせたハイブリッド型の勤務スタイルを取り入れています。また、コアタイムなしのフルフレックスタイム制です。
生産性を最大化できる環境は人それぞれなので、出社頻度もグラフの通り、まんべんなく散らばっている結果になりました。
<h2>RightTouchのエンジニアは、どんな人たちが多いと思いますか？</h2>
最後の質問になりました。この回答は、エンジニアメンバーからの生声をまとめる形でお届けします！
<blockquote>
・冒険者 
・技術力が高くて手が早い！技術力だけじゃなく人間的にもバランスが良い人が多いので一緒に仕事をしやすいです。 
・皆プロダクトに真剣に向き合っています！ 
・プロダクト志向強め 
・バランスの取れた人が多い、みんな優しい、フルスタックになんでもこなす人が多い 
・自分を意見を持って発信できる人、やろうと思ったことをちゃんと実行できる人 
・個人というよりチームでワークするタイプの人（バランス感がいい人）が多い 
・謙虚 
・地頭がよく、頭の回転が早い。ロジカル。開発スピードがとても早い。人を批判しない 
・クライアント視点（実際のユースケース、業務の課題）に興味があるエンジニアが多く、そこに寄り添った開発をしようという姿勢を感じる点がとても良いと思う。
</blockquote>
<hr>
エンジニアチームの10問10答、どうでしたか？少しでもRightTouchエンジニアチームの様子が伝われば嬉しいです！
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}

RightTouchエンジニアチームを知る10問10答

<h1>Rollup + Svelte + Typescriptの環境構成[2023/9版]</h1>
RightTouchのプロダクトは様々な技術を用いて開発されています。特にフロントエンドに関しては既存の技術スタックにとらわれず必要に応じて新しい技術を取り入れているため、同じプロダクトの中でも機能によって複数のフレームワークが使い分けられたりしています。
この記事ではSvelteとTypescriptのコードをRollupでバンドルしてるプロジェクトの環境構成について紹介をしていきたいと思います。
<h2>はじめに</h2>
まずはRollup + Svelete + Typescriptの環境で基本的に必須になる以下のパッケージをインストールします。
<ul>
<li>rollup</li>
<li>rollup-plugin-svelte</li>
<li>svelte</li>
<li>svelte-preprocess</li>
<li>typescript</li>
</ul>
<h2>rollupプラグインの選定</h2>
次は環境や必要な機能に応じてrollupのプラグインをインストールしていくのですが、かなり数が多いです。しかも<a href="https://github.com/rollup/awesome?tab=readme-ov-file#awesome-rollup-">公式のプラグイン紹介ページ</a>にあるものに絞っても同じようなのが複数あったりしてどれを使えばいいのかぱっと見だとわかりません。例えばTypescriptに関するプラグインだけでも4つ(typescript, ts-paths, ts, typescript2)存在してます。
とりあえず今回はプラグインの数をできるだけ減らしつつ<a href="https://github.com/rollup/plugins/tree/master?tab=readme-ov-file#rollup-plugins">公式が提供しているプラグイン</a>のみを採用する方針にしました。サードパーティ製は公式プラグインの改良版的なものだったりして高機能でダウンロード数が多いケースもあるのですが、マイグレーションによる不具合対応等のメンテナンスがされなくなってくることも多いので長期的な保守性を優先しました。
<h2>採用したパッケージ</h2>
<ul>
<li>@rollup/plugin-alias
<ul>
<li>tsconfigのbaseUrlとpathsに相当するpathの変換に使用</li>
<li>swcのconfigにもbaseUrlとpathsはあるがrollup.config.jsで指定した時の仕様がtsconfigの時と変わるのでこのプラグインで対応</li>
</ul>
</li>
<li>@rollup/plugin-commonjs &amp; @rollup/plugin-node-resolve
<ul>
<li>すべてのmoduleがESM対応でない限りおそらく必須</li>
</ul>
</li>
<li>@rollup/plugin-replace
<ul>
<li><code>process.env.NODE_ENV</code> のreplaceに使用</li>
</ul>
</li>
<li>@rollup/plugin-swc
<ul>
<li>swcはrust製のビルドツールで、babelの代わりにswcを用いてトランスパイルを行う</li>
<li>おそらく開発版(version 0.2.0)だがviteがswcを一部のプラグインで採用していたりbabelからの移行が進みそうなので採用</li>
<li>(10/10追記) <a href="https://github.com/rollup/rollup/blob/master/CHANGELOG.md#features">rollup 4でswcが採用された</a>のでrollup 4にマイグレーションする際は不要になりそう</li>
</ul>
</li>
<li>@rollup/plugin-terser
<ul>
<li>swc標準のminifyより有意に圧縮できていたので採用</li>
</ul>
</li>
<li>autoprefixer &amp; postcss
<ul>
<li>CSSのベンダープレフィックスをいい感じにしてくれる</li>
<li>今回CSSはsvelteのコード内にしかないのでsvelteのpluginとして設定</li>
</ul>
</li>
<li>svelte-check
<ul>
<li>svelteだけでなくCSSやTSの型チェックもやってくれる</li>
<li>CLI用なのでrollupのpluginとして組み込んでバンドル時に実行するようにしてる</li>
<li>自分でプラグインを開発できる</li>
</ul>
</li>
</ul>
<h2>rollup.config.js</h2>
以下がrollupの設定ファイルです。
<pre><code class="language-jsx">import { readFileSync } from 'node:fs';
import { spawn } from 'node:child_process';
import path from 'node:path';
import alias from '@rollup/plugin-alias';
import replace from '@rollup/plugin-replace';
import commonjs from '@rollup/plugin-commonjs';
import resolve from '@rollup/plugin-node-resolve';
import swc from '@rollup/plugin-swc';
import terser from '@rollup/plugin-terser';
import svelte from 'rollup-plugin-svelte';
import sveltePreprocess from 'svelte-preprocess';
import autoprefixer from 'autoprefixer';

// バンドル時にsvelte-checkを実行させるplugin
// プラグインの作り方はここ https://rollupjs.org/plugin-development/
function typeCheck() {
 const args = ['--compiler-warnings', 'css-unused-selector:ignore'];
 const options = {
 stdio: ['ignore', 'inherit', 'inherit'],
 shell: true,
 };
 return {
 name: 'type-check',
 writeBundle() {
 spawn('svelte-check', args, options);
 },
 };
}

export default {
 input: {
 main: 'src/main.ts',
 },
 output: {
 dir: 'dist',
 format: 'esm',
 },
 plugins: [
 alias({
 entries: { '~': path.resolve('src') },
 }),
 replace({
 'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
 preventAssignment: true,
 }),
 resolve({
 extensions: ['.ts', '.svelte'],
 browser: true,
 }),
 commonjs(),
 svelte({
 preprocess: sveltePreprocess({
 postcss: {
 // ここは勝手に.browserslistrcを参照してくれる
 plugins: [autoprefixer()],
 },
 }),
 emitCss: false,
 // svelte-checkのwarnと重複するのでこっちを非表示にする
 onwarn: () =&gt; {},
 }),
 swc({
 swc: {
 env: {
 // .browserslistrcを自動参照してくれないようなのでファイル読む
 // https://github.com/swc-project/swc/issues/3365
 targets: readFileSync('./.browserslistrc', 'utf-8').replace('\n', ','),
 },
 jsc: {
 parser: {
 syntax: 'typescript',
 },
 // browserslistによるtargetとdefaultのes5が競合してしまうのでnullを入れる
 target: null,
 },
 },
 }),
 terser(),
 typeCheck(),
 ],
};
</code></pre>
<h2>マイグレーション</h2>
最近rollupのエラー対応してる時に幾つかのプラグインがdeprecatedになっていて別のプラグインを推奨されたことがきっかけでマイグレーションを行い現在の構成になりました。初めは最小限の対応で済まそうと思いましたが、パッケージバージョンの相互依存が複雑だったり古いバージョンの仕様やドキュメントを確認するのが大変だったので全部最新までマイグレーションすることにしました。
<a href="https://rollupjs.org/migration/">rollup 2 → 3</a>, <a href="https://svelte.jp/docs/v4-migration-guide">svelte 3 → 4</a>が対応した主なメジャーアップデートになります。基本的にはそれぞれのドキュメント通り進めていけば大丈夫たと思いますが、<a href="https://svelte.jp/docs/v4-migration-guide#:~:text=module%20resolution%20configuration.-,For%20Rollup%20this%20is%20done%20within%20the%20%40rollup/plugin%2Dnode%2Dresolve%20plugin%20by%20setting%20browser%3A%20true%20in%20its%20options.%20See%20the%20rollup%2Dplugin%2Dsvelte%20documentation%20for%20more%20details,-For%20wepback%20this">svelte 4へのマイグレーションに伴う@rollup/plugin-node-resolveの設定の変更</a>はbuild時にエラーが出ず、一部の挙動がおかしくなる程度の症状なので意外とはまりポイントかもしれません。
期間が空いてしまうとすべてを一気にマイグレーションする羽目になり、結果的に工数も膨れ上がったり不具合のリスクも高くなってくるので、これを機にこまめにchange logをチェックして対応していこうと思います。
コードの規模がそこまで大きくなく開発時のHMRのパフォーマンスもさほど重要ではなかったためRollupのままでマイグレーションを行いましたが、<a href="https://svelte.jp/docs/svelte-compiler#:~:text=Svelte%20%E3%83%81%E3%83%BC%E3%83%A0%E3%81%8C%E6%9C%80%E3%82%82%E6%8E%A8%E5%A5%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%80%81%E3%81%BE%E3%81%9F%E6%B3%A8%E5%8A%9B%E3%82%82%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%90%E3%83%B3%E3%83%89%E3%83%A9%E3%83%BC%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%81%AF%20vite%2Dplugin%2Dsvelte%20%E3%81%A7%E3%81%99%E3%80%82">svelteの開発チームは現在viteのプラグインの方を推奨している</a>ので、特に新規開発や大規模なアプリケーションにおいてはViteの方が良いかもしれません。
<h2>最後に</h2>
今回はとりあえず動く程度のsvelte+TS+rollupの構成の紹介になりましたが、より良いパフォーマンスや型安全性等を目指してeslint, tsconfig, swcconfigの設定周りも紹介できればと思います。
<h2>一緒に働くメンバーを募集中</h2>
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}

Rollup + Svelte + Typescriptの環境構成

RightTouchでは、隔週木曜日に開催している「Dev勉強会」をはじめ、プロダクト・ユーザー理解の促進や、最新の技術情報をキャッチアップするために、様々な勉強会を開催しています。
今回のブログでは、2023年9月時点でRightTouchで開催している勉強会を、一挙にまとめて紹介していきたいと思います！RightTouchメンバーの雰囲気や興味関心が、少しでも伝われば嬉しいです。
<hr>
<h2>Dev勉強会</h2>
Dev勉強会は、今年の5月から始めました。エンジニアチームが全員参加し、隔週木曜30分の頻度で開催しています。持ち回り制で発表担当を決め、形式やトピックは発表者が自由に決められるようになっています。急遽参加できなくなってもフォローアップできるように、勉強会内容は録画・保管しています。
テックリードのnari（齋藤）が発起人となって、「まずはやってみようよ！」という雰囲気で始まりましたが、すでに9回ほど開催され、毎回トピックや形式も変わるので、密度の高い時間になっています。
<img src="https://ik.imagekit.io/righttouch/89d2d6a5-da4c-49cb-afe3-9d56f36eef1e/study-group-1.png" alt="study-group-1.png"> 
エンジニアそれぞれの好みやおすすめで盛り上がった「僕が考えた最強のターミナル」会
実際に、Dev勉強会で取り上げたトピックから、DBをプロダクトに導入できないかの検討が始まるなどもしています。また、RightTouchは新しいプロダクトの開発を複数並行して行っているので、新プロダクトの技術に関して担当エンジニアから細かく共有があったりと、実務に活きるナレッジ共有も行われています。
<img src="https://ik.imagekit.io/righttouch/b0d1954d-8f00-4bcc-9615-a62e2f7176f7/study-group-2.png" alt="study-group-2.png"> 
実施済みのDev勉強会のネタ一部
<h2>SaaS調査ランチ</h2>
これは、プロダクトチーム全体で実施している勉強会です。 
勉強会の名前の通り、毎週火曜のランチ時間に開催しており、調査したいカスタマーサポート領域SaaS（海外・国内問わず）概要・UI/UX・触ってみての感想といった要約を発表者が用意してくる以外は、他の参加者は準備不要で、ご飯を食べながら気軽に参加できる会となっています。
カスタマーサポート領域のSaaSプロダクトは、国内以上に海外には豊富にあります。ですが、国内外にある様々なプロダクトを一人で全て把握するには負荷が大きく、チームとして知見を共有しておく方が、プロダクト開発においてもメリットになるので、このような形式を採用して継続的なインプットを心がけています。
実際のサービス画面を見ながらワイワイとした雰囲気で話すので、「このUI分かりやすいね！」「これはイマイチかも」「できそうでできない動きだけど、これってどうなってるの？」といった会話や気づきで溢れており、あっという間に時間が過ぎていきます。
エンジニアだけでなく、デザイナーなどプロダクトチームで開催しているので、「SaaS調査ランチ」で取り上げたものを参考に、機能UIの開発がすぐ進むといった事例も出てき始め、プロダクト改善につながる良いサイクルが生まれています。
<img src="https://ik.imagekit.io/righttouch/71ebe624-bd28-4314-9423-0b468f70994e/study-group-3.png" alt="study-group-3.png"> 
各社サービスの画面を見ながら、あれこれ話しています
<h2>LLM探索会</h2>
ChatGPTの登場とともに、急速にWebサービスに広まるLLMについて、最新技術・知見のキャッチアップと並行し、プロダクトへの実用化を模索する勉強会を開催しています。
RightTouchが扱うカスタマーサポート領域は、FAQなどのナレッジの自動生成・作成補助、問い合わせ内容の簡易分析など、LLMと相性が良いこともあり、勉強会は濃密かつ実践的なものになっています。
週1回1時間程度、任意のエンジニアメンバーが参加し、事前に提示したお題に沿ってそれぞれが内容を持参、またはその場でお題に対して手を動かすような形式をとっています。
今までに扱った内容としては、RightSupport内のテストデータをGPTに投げて、顧客の困りごとが捉えられているかどうかや、テストデータから問い合わせ理由の自動分類をGPTが正しくできるかどうかを実験・議論したりしました。
実は、すでにこのLLM探索会から成果が生まれています！ 
この6月に「課題予測による回答最適化機能（ライブアシスト）」「カスタマーデータを踏まえたWebサポート施策の自動生成機能」という、LLMを用いた<a href="">2つのプロダクトアップデートのリリース</a>につなげることができました。
LLMは、事業親和性の高い強力なテクノロジーだと捉えているので、今後も探索会を起点に試験的な開発や検討を進めていきたいと思っています。
<div style="max-width: 1082px;"><div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 62.306%;"><iframe src="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fprtimes.jp%2Fapi%2Ffile.php%3Fc_id%3D98678%26t%3DanimationGifImage%26f%3D91f6720a5dd118264a6e0de01f10728f.gif&key=878c5bef402f0b2911bf6d4ce6261abd" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div></div>
LLMを活用してリリースした「ライブアシスト機能」のデモ画面
<h2>KARTE RightSupport利用状況調査（ユーザーモニタリング）</h2>
この会は、私たちが提供しているKARTE RightSupportを、利用されている企業様、そしてその先にいるエンドユーザー様の実データを元に、プロダクトの使われ方について理解を深め、仮説や知見・改善点を得るという目的で、不定期で開催しています。
この勉強会内での調査・分析には、KARTEを使っています。 
どんなシナリオを作成しているのか、どのウィジェットが特に閲覧されているのか、どんなセグメントで設定されているのかなどを、ダッシュボード上のデータやユーザーの動き（KARTE Live機能の活用）をエンジニア全員で見て、その場での気づきやアイディアを共有していきます。
「なぜこのウィジェットの閲覧数が、ものすごく大きいんだろう？」とデータだけでは不思議に思うことも、実際の画面と比較しながら見ることで、例えば「AI・チャットボットという文字があると気軽にクリックしていそうだ」といったインサイトが見えてきたりします。
現在は不定期に実施していますが、プロダクト・ユーザー理解にとても効果的なので、今後は新しいメンバーが入ってくれたオンボーディングプログラムの一環として実施できないかなども検討しています。
<img src="https://ik.imagekit.io/righttouch/1b0c2632-90ea-4580-9b40-0bf746c1ae07/study-group-5.png" alt="study-group-5.png"> 
KARTE画面を見ながら、インサイトや改善点を探していきます
<hr>
RightTouchエンジニアチームの雰囲気が、勉強会の様子から少しでも伝わったでしょうか？勉強会に限らず、RightTouchのメンバーはプロダクトの提供価値を最大化するための目的思考が強く、必要な技術やインプットを自律的に行うメンバーばかりです。
また、上場企業の戦略子会社として、スタートアップ的なチャレンジと、探索的なR&amp;Dやプロダクトへの投資を両立できる環境があります。エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持ってくださった方と、まずは気軽にお話できれば嬉しいです！
カスタマーデータを活用してインパクトのあるプロダクトを作りたい方や、妥協しないチームの一員として挑戦してみたい方は、ぜひご応募ください。 
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}
新しい仲間に出会えることを楽しみにしています。

RightTouchで開催されている社内勉強会を、一挙にまとめてご紹介します。

RightTouchの社内勉強会をライトに紹介します！

RightTouchでは、カスタマーデータをもとにプロダクトや機能の開発・改善を行っています。当社の「カスタマーデータドリブンなプロダクト開発」とはどういったもので、どんなやりがいがあるのか、RightTouch テックリードの齋藤に話を聞きました。
「<a href="https://karte.io/">KARTE</a>に豊富なカスタマーデータが蓄積されているからこそ、スムーズに精度の高い分析ができる」と語った齋藤。具体的にどのようなデータをどう開発に活かしているのかまで詳しく迫ります。
<h2>カスタマーデータドリブンな開発とは</h2>
──まずはカスタマーデータドリブンな開発とはどういったものかを教えてください。
齋藤：
カスタマーデータドリブンな開発は、ユーザーの利用状況などの「カスタマーデータ」を活用してプロダクトや機能を開発する手法のことです。たとえば、新しいマーケティングツールを作るとしたら、「どの機能がどんな人に使われているか」をデータで分析しながら開発するイメージです。
データを用いない開発だと、自分の感覚や経験しか頼りになりません。「ユーザーはこんな機能を求めているだろう」という自分の考えと、ユーザーが実際に必要とする機能とがいつも一致するとは限らないので、感覚や経験だけではズレてしまう可能性がありますよね。そうなれば、できあがったプロダクトや機能が役に立たないなんてことも考えられます。 
もちろん、お客様にインタビューさせていただき、お声をいただくことも多くありますが、それだけでは本当の利用実態は十分に把握できません。
カスタマーデータドリブンなら、自分の考えや仮説が正しいかをカスタマーデータで検証しながら開発できるため、大きく外す可能性を低くすることができます。開発の途中で「この考えは違うかもしれない」と思ったときには、すぐにデータで確かめられるんです。
<h2>RightTouchにはカスタマーデータドリブンな開発を行ううえで、これ以上ない環境が整っている</h2>
──RightTouchでは、どのようにカスタマーデータドリブンな開発を実施しているのでしょうか？
齋藤：
グループの母体である<a href="https://plaid.co.jp/">プレイド</a>が提供している、「<a href="https://karte.io/">KARTE</a>」の分析機能を使っています。
KARTEには「クライアントの担当者が弊社のプロダクトや機能をどれくらい使っているか」というデータが豊富に蓄積されていて、このデータを分析しているんです。
既存プロダクトの機能改善はもちろん、新規機能の検討にも活用しています。
──プロダクト開発にデータ分析を取り入れることは、さまざまな企業が実施していると思います。そんななかで、RightTouchのカスタマーデータドリブンな開発ならではの良さにはどんなものがありますか？
齋藤：
KARTEという強力なデータ基盤をプロダクト分析に活用しているおかげで、すぐに分析して開発提案ができるところです。
たとえば、自分が作りたいプロダクトや機能があったとして、一般的な開発環境だと、データドリブンにしたくても、すぐに着手ができないケースが多いと思います。例えば、分析したいデータが手元になくて、まず取得から始めないといけないとか、時間をかけて集めたデータの質がイマイチで取り直しになるとか、あるあるじゃないでしょうか。
ですが、RightTouchで利用するKARTEはデータの収集力と分析力が高くて、仮説検証を高速に進められますし、精度もかなり高いです。なので、すぐにプロダクトの仕様検討にデータを取り入れることができます。
<h3>データにもとづくから、ローンチ後に悲しい思いをしなくて済む</h3>
──齋藤さんが考える「カスタマーデータドリブンな開発」の良さを教えてください。
齋藤：
「手探りではなく、精度の高い試行錯誤を繰り返しながらプロダクト作りを進められるところ」です。
カスタマーデータを踏まえた開発なら、ユーザーの反応と行動を、数字やログで把握しながらプロダクト作りを進められます。どうすればもっと使ってもらえるのか、データをもとに仮説を立て、その結果をまたデータで検証する、という試行錯誤が可能です。
結果として、「頑張って作ったが価値が生まれず無意味」などのつらい思いをすることが少なくなりますし、数字を見ることで「ユーザーの役に立っている」「貢献できている」という実感を持てています。 
また、データ分析するたびに「こういうインサイトがあったんだ」と新しい発見があるのも楽しいです。
データドリブンな開発が「超楽しいか」は人それぞれだと思いますが、個人的にはデータを見ながら一歩ずつ進められるので、進んでいる実感から「モチベーションの維持」につながっています。
<h2>カスタマーデータを分析して開発した2つの実例</h2>
──齋藤さんは普段、どのようなプロダクト開発をしているのでしょうか。具体的に教えてください。
<h3>【例1】RightSupportの利用状況を分析して機能を追加・改善</h3>
齋藤：
私たちのメインのプロダクトである<a href="https://rightsupport.karte.io/">RightSupport</a>で、まさにカスタマーデータドリブンな機能開発・改善をしています。
Web上のユーザー行動を解析できるKARTEの計測タグをRightSupportの管理画面に埋め込んで、「ユーザーがどの機能を、どのくらい、どのように活用しているのか」といった利用状況を精緻に分析し、それをもとに開発をしています。
例えばRightSupportユーザーが管理画面で何をしているかを、KARTEのダッシュボードで集計する分析です。（下図）
<img src="https://ik.imagekit.io/righttouch/9b6e997e-ca16-4790-8fc9-8921af58fb70/qddash.png" alt="qddash.png">
この分析では、機能ごとに「何が使われて、何が使われていないか」がわかるので、作った機能の定量的な振り返りができます。機能追加・改修の際には、エンジニアとビジネスメンバーが一緒にダッシュボードのデータを見て、「どんな機能にすれば使われやすいのか」を話しあうこともよくあります。
ちなみに裏側の仕組みとして、ダッシュボードに自然にデータが溜まっていく構造にするため、エンジニアが誰でも気軽にイベント（※分析対象の行動のこと）を追加できるよう工夫しています。具体的には、管理画面のコードを数行調整するだけです。ダッシュボード側の集計操作をいじらなくても、自動で新しいカテゴリごとのイベントを集計・可視化できます。
<h3>【例2】KARTE Liveで有事では現れにくいユーザーの行動を分析</h3>
──既存機能ごとの利用状況をデータで見れるのは便利ですね。
齋藤：
はい。とはいえ、定量的なデータだけでは、ざっくりした利用状況はわかっても、細かいUIの使いづらさなど、数字に現れにくい部分の把握は難しいです。
そこで私たちは、不定期で「クライアントのKARTE Liveを見る会」を実施しています。
<a href="https://karte.io/product/live/">KARTE Live</a>とは、ユーザーのWebサイト上での行動を、マウスの動きまで含めて動画再生できるプロダクトのことです。Liveを見る会では、エンジニアとプロダクトマネージャの各メンバーを中心に、RightSupportの特定の機能を使っているクライアントのLive動画をひたすら見ていきます。 
※Liveのマスキング機能を用いて必要以上の管理画面行動データは取得せずに行っています
<img src="https://ik.imagekit.io/righttouch/33892a23-633e-4c3a-a568-0357d23564fa/live.png" alt="live.png">
その後、機能ごとに気になるクライアントの行動をピックアップして、気づきをまとめて議論します。
<img src="https://ik.imagekit.io/righttouch/2c013f6a-16d7-48f3-9808-62644e927dce/live%E3%82%92%E8%A6%8B%E3%82%8B%E4%BC%9A.png" alt="liveを見る会.png">
実際に上の図でお見せしているKARTE Liveを見る会では、「レポート・分析画面にデータが入っていないと、クライアントがすぐに離脱してしまう」という、定量データでは気づかなかった課題を発見できました。
この発見をもとに、レポート・分析画面にデータが入りやすくするよう集計やUIの見せ方を工夫するプロダクト改善を行えました。
<h2>評価が数字で表れるのが魅力</h2>
──RightTouchでプロダクト開発をしていて良かったと思うことはありますか？
齋藤：
プロダクトとともにエンジニアとしても成長して行けるところです。
数字を見ながら開発を進めるので、入社したときに比べて、データを見る力や分析力、仮説を立てる精度ともに上がったと実感しています。もちろん、開発のスキルも向上しました。開発者として必要な力が身についてきていると思います。
──カスタマーデータドリブンな開発の&quot;やりがい&quot;は何ですか？
齋藤：
先ほどもふれましたが「ユーザーの反応がわかる」ところです。
私たちが取得しているデータのなかには、「自分が開発した機能が利用してもらえているか」も含まれています。そのデータを見れば、ユーザー使ってもらえていることが数字でわかるので、作ったかいがあったなと実感できます。「自分が作った機能が誰にも使われていないのでは？」と確認できないままの疑心暗鬼状態では、作りがいを感じにくいですよね。
設計からデプロイまで各社員の裁量にゆだねられる部分が大きいチームであるからこそ、ユーザーの役に立ったときには、その評価が明確に数字として表れるのがRightTouchでのカスタマーデータドリブンな開発の魅力です。
<h2>プロダクトの「おもしろさの確度」をぐっと高められる開発環境</h2>
──齋藤さんから見て、RightTouchの開発はどんな人に向いていると思いますか？
齋藤：
一言で表すと「プロダクト志向」の人に合っていると思います。
RightTouchは作りたいプロダクトや機能があったときに、すぐにデータ分析やヒアリングなどを通じて仮説検証をしつつ、現場のエンジニア主導で開発を進められる環境が整っています。そのため、「おもしろいプロダクトを作りたい」人にとっては、理想の会社ではないでしょうか。本当に「おもしろさの確度」を高めやすい開発環境です。
「どうやったらお客様が喜んでくれるプロダクトに成長させられるか」を考えながら試行錯誤することを楽しめる人がいたら、ぜひ一緒に開発を進めていきたいですね。
<h2>一緒に働くメンバーを募集中</h2>
RightTouchでは、開発を一緒に進める新たなメンバーを募集しています。
顧客と企業の接点として貴重な場であるカスタマーサポートにおいて、顧客体験の向上、そして従業員体験の向上を目指して事業とプロダクトを展開しています。
カスタマーデータを活用してインパクトのあるプロダクトを作りたい方や、妥協しないチームの一員として挑戦してみたい方は、ぜひご応募ください。
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}
新しい仲間に出会えることを楽しみにしています。

RightTouchの「カスタマーデータドリブンな開発」についてテックリードへ話を聞きました

プロダクトとともに自分も成長する。RightTouchのテックリードが語る「カスタマーデータドリブンな開発」とは

RightTouchの社内技術勉強会で話した「良いHTML、CSSの書き方」について紹介します。

Blog

Recent Article