RightTouch Blog

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

<p>RightTouch Blog編集部です！</p>
<p>2025/1/29に株式会社estie、ASCEND株式会社、株式会社RightTouchの3社合同で「<a href="https://estie.connpass.com/event/340354/">プロダクトエンジニア〜ユーザー価値を支える技術〜</a>」というイベントを開催しました。</p>
<p>各社からフェーズや成り立ちが異なるプロダクトエンジニアが集い、ユーザー価値の向上やプロダクト開発における新たなアプローチを紹介しました。</p>
<h2>小規模組織のプロダクトエンジニアとして、アンラーニングしたこと</h2>
<p>RightTouchからは<a href="https://x.com/_hedrall">小室(com)</a>が「小規模組織のプロダクトエンジニアとして、アンラーニングしたこと」という題目で登壇しました。</p>
<p><img src="https://ik.imagekit.io/righttouch/ff937a42-4899-4767-89db-29c92ac17764/250129-01.jpg" alt="登壇風景"></p>
<p>当日の発表スライドを公開しているので、ぜひご覧ください。</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/ebf23dd9f53746fc8a30087f94f3a33a" title="小規模組織のプロダクトエンジニアとして、アンラーニングしたこと" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<h2>PdMがいないチームにおけるエンジニアの役割とは？</h2>
<p>PdMがいないチーム体制においては、これまで<strong>仕様</strong>と<strong>設計</strong>にフォーカスしてきたエンジニアも<strong>戦略</strong>や<strong>要件</strong>に入り込んでいくことが非常に重要になります。</p>
<p><img src="https://ik.imagekit.io/righttouch/559fc6cc-57ae-4266-94ae-96d94c56e704/250129-02.jpg" alt="プロダクトエンジニアは要件・仕様・設計のプロダクト全体に責任を持つ"></p>
<p>特に新規プロダクトの初期には代表が直接コミットするケースがあります。この場合、視座の違いから従来のフレームワーク等では議論の粒度が揃わないケースが多く、議論から落とし込まれたタスクも状況の変化によってすぐに無意味なものになりがちです。</p>
<p>さらに、<a href="https://www.amazon.co.jp/INSPIRED-%E7%86%B1%E7%8B%82%E3%81%95%E3%81%9B%E3%82%8B%E8%A3%BD%E5%93%81%E3%82%92%E7%94%9F%E3%81%BF%E5%87%BA%E3%81%99%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88-%E3%83%9E%E3%83%BC%E3%83%86%E3%82%A3%E3%83%BB%E3%82%B1%E3%83%BC%E3%82%AC%E3%83%B3/dp/4820727508">INSPIRED</a>で定義されているような理想的なPdMは実質スーパーマンであり、RightTouchのような様々なプロダクトを並行して立ち上げるような組織においてはボトルネックになる可能性が非常に高いです。</p>
<p>PdMというチーム機能を補う上で、意識的にエンジニアが戦略や要件のすり合わせに入っていくことで限られたリソースの中でも効果的が議論がしやすくなるということを語っています。</p>
<h2>プロセスは変わっても、開発の基礎は変わらない</h2>
<p>日々流動的に状況が変わっていく中でエンジニアとしての立ち振る舞いも都度変化していきます。とはいえ、開発の基礎は常に変わらない部分としてエンジニアとして制御しやすい部分です。</p>
<p><img src="https://ik.imagekit.io/righttouch/1286772f-2b44-4450-a285-bdec25de0516/250129-03.jpg" alt="Clean ArchitectureやDDDなどを取り入れる効果"></p>
<p>Clean ArchitectureやDDDなどを積極的に取り入れることで</p>
<ul>
<li>プロダクトの雛形を作ることによる横展開のしやすさ</li>
<li>PdMがいない環境での思考をモデリングという形で残し、不確実性の高い状況においても一貫した思考と説明をするためのメンタルモデルを構築しておくこと</li>
</ul>
<p>など、新規プロダクト開発においてこれまで培ってきた知見をこだわりを持って実行していくことも大切であるという話で全体を締め括りました。</p>
<h2>プロダクトエンジニアのコミュニティ始めます</h2>
<p>RightTouchでプロダクトエンジニアとして活躍するメンバーが主体となって「Product Engineer Session」というコミュニティを立ち上げました！</p>
<p>「Product Engineer Session」は、技術力だけでなくユーザ価値を最も大切にしてプロダクト視点で日々の開発に向き合っているプロダクトエンジニアの、ユーザーに価値を届けるためのフルサイクルの活動の中で得られた知見や気づきを共有し合う交流の場です。</p>
<p><a href="https://pesess.connpass.com/event/344220/">初回のイベント</a>を3/4(火)にRightTouchのオフィスで行います！</p>
<p><a href="https://pesess.connpass.com/event/344220/"><img src="https://ik.imagekit.io/righttouch/72159e16-9a62-4eff-8455-23d39d1d8006/pdesession.png" alt="Product Engineer Session #1"><br>
</a></p>
<p>エンジニアに限らず、PdM、Engineering Manager、Designerなど、価値を生むプロダクト開発について日々考え実践されている方の、より深い学びの場になると信じていますので、興味がある方はぜひご参加ください！</p>
<h2>最後に</h2>
<p>RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを絶賛採用中です。<br>
少しでも興味を持った方がいればぜひお話ししましょう！</p>
<p>エンジニア求人情報の詳細<br>
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a></p>
<p>採用サイト<br>
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a></p>


「プロダクトエンジニア〜ユーザー価値を支える技術〜」をテーマにしたLTイベントを開催しました

コンセプトもデータも重視。タイプの異なるエンジニアたちが連携して事業成長に貢献するRightTouchの開発現場

<p>12/12 に開催されたレバテックさんの「<a href="https://levtechcareer.connpass.com/event/337755/">～Tech-Front Meetup～ 一歩先のフロントエンドへ</a>」で React Hook Form を用いたフォーム開発について登壇しました。</p>
<p>本記事では、発表のサマリーとスライドの補足を簡単に行います。資料についてはこちらをご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計" src="https://speakerdeck.com/player/21629e102a784cfcba40cb9309c88789" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>複雑性の高いフォーム設計の背景</h2>
<p>RightTouch では、Web サポートプラットフォーム「<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>」の一部として、クライアントの Web サイト上にパーソナライズされたコンテンツを埋め込む「サポートアクション」機能を提供しています。</p>
<p>このサポートアクションは、ネストや配列を含む複雑なオブジェクト構造を持ち、クライアントの要望に応じて柔軟にカスタマイズ可能な設計が求められています。</p>
<p><img src="https://ik.imagekit.io/righttouch/fa177cda-3608-4150-9de4-ac76245c28ea/241212-rhf-01.png" alt="241212-rhf-01.png"></p>
<p>上記背景から、サポートアクションのエディタには以下のような課題がありました。</p>
<ul>
<li>編集対象オブジェクトの深いネスト</li>
<li>項目数の増加</li>
<li>動的に変化する編集項目</li>
<li>項目間のバリデーション</li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/87e226eb-965f-4b69-8f35-fc9103f304a1/241212-rhf-02.png" alt="241212-rhf-02.png"></p>
<p>これらの課題をクリアするために、フォーム設計には特に工夫を凝らしました。</p>
<h2>React Hook Form の採用</h2>
<p>まず、複雑なオブジェクト編集に対応するため、ベースのフレームワークとして React Hook Form（以下RHF）を採用しました。その理由は以下の通りです。</p>
<h3>ステート管理とバリデーションの一元化</h3>
<p>フォーム全体のステート管理とバリデーションをRHFに任せることで、コード量の削減や開発の効率化が可能と考えました。</p>
<p><img src="https://ik.imagekit.io/righttouch/ddaaa01a-2ecb-480d-9673-2febb89f8c0c/241212-rhf-03.png" alt="241212-rhf-03.png"></p>
<p>類似のフォームライブラリもありますが、今後の安定性、複雑な型に対する適応力、学習コスト等から今回はReact Hook Formを採用しました。</p>
<p>参考：<a href="https://zenn.dev/manalink_dev/articles/winter-react-form-mokumoku-meetup-report">打倒React Hook Formを掲げてもくもく会を主催したが、結局Rhf強ぇ〜ってなった話</a></p>
<h3>ネスト/配列を持つデータ構造への対応力</h3>
<p>ドットでプロパティ名を繋ぐことで深いネストを持つオブジェクトにも対応可能な点も、複雑なオブジェクトのサポートアクションと相性が良かったです。</p>
<p><img src="https://ik.imagekit.io/righttouch/61860f9c-ef8d-4c77-976c-56cfa966a750/241212-rhf-04.png" alt="241212-rhf-04.png"></p>
<h2>フォームの設計方針と課題解決</h2>
<h3>ステート管理の粒度</h3>
<p>開発当初は、関心事を分離しステートをシンプルに保つため、パーツごとに <code>useForm</code> を分割していました。</p>
<p><img src="https://ik.imagekit.io/righttouch/8c0eedf7-cb35-4ec6-8d34-f99aac5d989e/241212-rhf-05.png" alt="241212-rhf-05.png"></p>
<p>しかし、運用して行く中で、異なるパーツ間でデータやバリデーション結果を参照する必要が増えコードの複雑化を招いてしまいました。</p>
<p>これを解決するため、フォーム全体を 1 つの <code>useForm</code> で管理する方針に変更しました。</p>
<p><img src="https://ik.imagekit.io/righttouch/bd43cf0b-ac42-4456-bac0-7c2e5c5201b2/241212-rhf-06.png" alt="241212-rhf-06.png"></p>
<p>これにより、データの同期やバリデーションの一元化が可能となり、保守性と開発効率が向上しました。</p>
<p>ステートの管理を1つにまとめる一方で、Reactコンポーネントはなるべく粒度を小さく保つため、<code>useFormContext</code> を用いたモジュール分割を行っています。</p>
<h3>型安全性の課題と工夫</h3>
<p>React Hook Form に巨大なオブジェクトを扱わせる場合、ユニオン型をうまく型安全に扱えないことや、型計算が複雑化し、TypeScript のコンパイル限界に達することもありました。この問題を以下の方法で解決しました。</p>
<h4>サブタイプの導入</h4>
<p>各パーツ専用の軽量な型を定義し、<code>useFormContext</code> にはその型を渡すことで型計算の負担を軽減することで <strong>スケール可能かつ型安全</strong>な開発を行うことが可能になりました。</p>
<p><img src="https://ik.imagekit.io/righttouch/588131f4-6c6e-4ce0-bcba-d146f9cc4881/241212-rhf-07.png" alt="241212-rhf-07.png"></p>
<h4>型計算のボトルネックを特定しパフォーマンス改善</h4>
<p><code>tsc --generateTrace</code> コマンドでtsコンパイル処理のトレースを取得することができます。</p>
<p>この結果から<strong>型計算のボトルネックを特定</strong>し、パフォーマンスを改善しました。</p>
<p><img src="https://ik.imagekit.io/righttouch/5e03398a-04e0-43ad-a385-41ddd00a9815/241212-rhf-08.png" alt="241212-rhf-08.png"></p>
<h2>運用実績と成果</h2>
<p>RightTouch では、サポートアクションをリリースして、この設計方針で約 8 か月運用してきました。</p>
<p>その間もパーツの追加や変更は行われていますが、初期設計時の目論見通りスムーズにできています。課題はあるものの、全体としては順調に運用されていると言えます。</p>
<h2>最後に</h2>
<p>RightTouchでは、クライアントの課題を解決するために複雑性の高いフォーム開発に自信のあるプロダクトエンジニアを絶賛採用中です。</p>
<p>少しでも興味を持った方がいればぜひお話ししましょう！</p>
<p>エンジニア求人情報の詳細<br>
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a></p>
<p>採用サイト<br>
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a></p>


React Hook Formを用いた複雑性の高いエディタ開発の設計

<p>先日行われた<a href="https://isucon.net/archives/58848927.html">ISUCON14</a>にRightTouchのエンジニアメンバーikki, nari, takkenの3名で、チームnarinariとして参加しました。</p>
<p><strong>結果は12728点で831チーム中97位</strong> となりました。<br>
<a href="https://isucon.net/archives/58847106.html">利用言語別のNode.jsでは9位</a>にくいこむことが出来ました。</p>
<p>当日の点数遷移としてはこんな感じです。</p>
<p><img src="https://ik.imagekit.io/righttouch/9f8e10f6-b9fb-4479-ad87-8439c2bce827/isucon01.webp" alt="isucon01.webp"></p>
<h2>0次予選</h2>
<p>ISUCON14は予選がなく、何回かに分けて先着順での参加申し込みでした。</p>
<p>最初の申し込み回は結果的に秒殺でしたが、秒単位で時間を確認しつつ、チーム名は一旦適当につけることでなんとか滑り込むことができました。冒頭にもあるように結局名前はこのままで行きました（笑）</p>
<p><img src="https://ik.imagekit.io/righttouch/6459be3d-18ad-4133-83d7-52b8d02c98b0/isucon03.webp" alt="isucon03.webp"></p>
<h2>練習</h2>
<p>全員が初参加ということで、当日ぶっつけ本番というわけにも行かないので、本番前に2回ほど練習会を行いました。</p>
<p>練習ではmatsuuさんの<a href="https://github.com/matsuu/aws-isucon?tab=readme-ov-file">こちら</a>やISUCON本の<a href="https://github.com/catatsuy/private-isu">private-isu</a>使って練習しました。また、traPさんの<a href="https://isucon-workshop.trap.show/">こちら</a>も非常に参考になりました。</p>
<p>主に行ったのは下記です。</p>
<ul>
<li>基本的なインスタンスのセットアップ手順</li>
<li>以降の練習 or 本番に向けた作業メモを残す</li>
<li>競技中によく叩くコマンドをMakefileにまとめる</li>
</ul>
<p>セットアップをする中でつまづいたポイントや、回ごとに異なりそうな部分は当日に焦らないようにコメントを残しておくことで再利用しやすくしました。</p>
<h2>ISUCON14の出題概要</h2>
<p>ISURIDEという椅子のマッチングサービスが題材でした。いわゆるタクシー配車アプリの椅子版で、ユーザーが椅子をリクエストすると周りにいる椅子とマッチングし、座ることができるというものです。</p>
<p>詳しくは動画をご覧ください</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="ISUCON14 出題動画" src="https://www.youtube.com/embed/UFlcAUvWvrY?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>
<p>ikkiがインスタンスのセットアップを担当し、nari,takkenでドキュメントやコード読みとAPMのセットアップなどを行いました。</p>
<p>2台目のインスタンスセットアップ時にコマンドのコピペをミスり、環境を壊してしまい、インスタンスを作り直すなどのトラブルはありましたが、12時ごろにそれぞれのインスタンスのセットアップを終えて、ベンチを回して点数が出ることを確認しました。</p>
<p>また、当初はgolangで参加する予定でしたが、やはり慣れている言語にしようということでnodeにすることにしました。結果的に今回はアプリケーションロジックの改善がメインだった（はず）ので慣れている言語にしておいて良かったです。</p>
<h3>12時-14時</h3>
<p>APMにたまったデータをもとに一旦遅いSQLたちにINDEXを貼る儀式を行い、数百点アップしました。</p>
<p>そこから、各自コードを読み進めたり、実際にアプリを触ってみたりして、やたらとリクエスト数が多いエンドポイントやN+1になっているところを発見し次第、改善を試みるという形で進めていましたが、なかなかうまく改善が進まない時間が続きました。</p>
<p>流石にこのままだと厳しいと思い、一旦集合してモブプロ的に大きな課題を潰そうという方針に変えました。</p>
<h3>15時</h3>
<p>見つけた大きな課題を全員で取り組むスタイルに変え下記を改善しました。</p>
<ul>
<li>都度計算している重い処理をカラムとして保存するようにスキーマ変更</li>
<li>DBとAppのインスタンスを分ける</li>
<li>Honoのリクエストログを止める</li>
</ul>
<p>この辺の取り組みをして大体8000点くらいまで上昇しました。</p>
<p>ほぼ初期スコアの時間が長かったのでちょっとホッとしました。</p>
<h3>16時-17時50分</h3>
<p>もう一つくらい改善できるかなと思い、次にライドの不満度に目をつけました。</p>
<p>初期だとランダムに椅子をマッチングさせていたところを現在地から近く、スピードが速い椅子をマッチングさせるようにロジックを変更しました。</p>
<p>追加でいくつかINDEXを貼ったりして、17時くらいに12000点強位まで上がりました。</p>
<h3>ラスト10分</h3>
<p>なんやかんやでギリギリまで改善をしていて、再起動試験などをしないととなり、大急ぎで行いました。</p>
<p>幸い特に問題は起こらず、不要なサービスの停止まで完了して18時を迎えました。</p>
<h2>感想</h2>
<p>下記はISUCON14に初参加して感じたポイントです。</p>
<ul>
<li>事前練習は必須
<ul>
<li>練習なしだったら諸々のセットアップで大半の時間を消費していた可能性があります</li>
</ul>
</li>
<li>何事もイテレーションサイクルが短いことが重要だと感じた
<ul>
<li>VSCodeのmysql拡張がSSH時にもいい感じに使えて、コードからクエリをコピペするとどんなデータが返ってくるかわかったり、書いたクエリが動くのか都度確認できて良かったです</li>
</ul>
</li>
<li>分担にはかなり慣れが必要そう
<ul>
<li>私たちのチームは結果的にモブプロ的な形で進めた方が早かったです</li>
</ul>
</li>
</ul>
<p>ほぼ初期スコアの時間が結構長く、内心焦りつつ最終的にはいくつか改善できたので初参加としては良かったと思います。</p>
<p>弊社から出ていた別チームと打ち上げに行き、感想戦をしていたところ、コスパ良く改善できるポイントを取り逃がしていたことを知り、若干の悔しさを残して初めてのISUCONは終了という感じです。</p>
<h2>最後に</h2>
<p>RightTouchでは、プロダクトのパフォーマンスにこだわるプロダクトエンジニアを絶賛採用中です。<br>
少しでも興味を持った方がいればぜひお話ししましょう！</p>
<p>エンジニア求人情報の詳細<br>
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a></p>
<p>採用サイト<br>
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a></p>


RightTouchのエンジニアでISUCON14に初挑戦してきました

<p>11/6に開催された「<a href="https://increments.connpass.com/event/328720/">Qiitaさんのフロントエンドイベント</a>」で弊社のPreact活用について登壇しました。本記事では、発表のサマリーと、スライドの補足を簡単に行います。</p>
<p>資料についてはこちらをご覧ください。</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/7af71b37f2634b0bbe78038507dde201" title="3rd party scriptでもReactを使いたい！ Preact + Reactのハイブリッド開発" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<h2>Preactとは</h2>
<p>PreactはReactの軽量版であり、Reactとほぼ同じAPIを持ちながらも、サイズが小さく、パフォーマンスが高いことが特徴です。React比較で10分の1以下という非常に小さいバンドルサイズになっています。</p>
<p><img src="https://ik.imagekit.io/righttouch/4bd819a5-02cd-4241-9460-06fed8dc4e3a/%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-11-2818.33.40.png" alt="Preact"></p>
<h2>RightTouchでのPreactの活用</h2>
<p>RightTouchでは、<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>というWebサポートプラットフォームを提供しています。</p>
<p>本プロダクトには「サポートアクション」と呼ばれる機能があります。これは、RightSupportをご活用いただいているクライアントのWebサイトにJavaScriptのタグを1行埋め込むだけで、ノーコードでサイトの自由な書き換えが行えたり、FAQやシナリオを組み込んだポップアップを表示することができる機能です。</p>
<p>この機能の実現のため、RightTouchのCDNからWebサイトにスクリプト(=3rd party script)を配信しています。このスクリプトは、クライアントのサイトのパフォーマンスを損なわないよう、軽量で高速なものであることが求められます。</p>
<p><img src="https://ik.imagekit.io/righttouch/eee5381d-3677-41e9-906a-ca7b04d5101f/preact-use.png" alt="RightTouchでの利用例"></p>
<p>Preactは、この軽量性の要求にピッタリな技術でした。さらに、RightTouchでは3rd party script以外の管理画面(例えばサポートアクションのノーコードエディタ)ではReactを採用しており、その点で技術キャッチアップの最小化や、コードの共通化といったメリットもありました。管理画面との技術親和性に関しては、React製のノーコードエディタにPreact製のサポートアクションを埋め込むことで、サポートアクションのリアルタイムプレビューを実現するという少しユニークな活用も行っています。</p>
<p><img src="https://ik.imagekit.io/righttouch/59a5f008-560f-4ee2-85dc-327cd8e67abe/%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-11-2818.34.05.png" alt="サポートアクションエディタ"></p>
<p>運用の工夫としては、上述のノーコードエディタでのPreact + Reactの併用に伴う互換性の確保や、バンドルサイズのチェックなどが挙げられます。2024/11月時点で、Preactの運用実績は約1年となりますが、Preact起因の障害は今のところ起きておらず、順調に運用されています。</p>
<h2>最後に</h2>
<p>RightTouchでは、今回のPreact活用のように、プロダクトの価値向上のためには現状にとらわれすぎずに新たな技術を模索・採用していく文化があります。</p>
<p>カスタマーサポート市場の改革に挑むプロダクトエンジニアを絶賛採用中です。少しでも興味を持った方がいればぜひお話ししましょう！</p>
<p>エンジニア求人情報の詳細<br>
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a></p>
<p>採用サイト<br>
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a></p>


RightTouchでのPreactの活用について発表してきました

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


RightConnect by KARTEの裏側

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


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

<h1>Rollup + Svelte + Typescriptの環境構成[2023/9版]</h1>
<p>RightTouchのプロダクトは様々な技術を用いて開発されています。特にフロントエンドに関しては既存の技術スタックにとらわれず必要に応じて新しい技術を取り入れているため、同じプロダクトの中でも機能によって複数のフレームワークが使い分けられたりしています。</p>
<p>この記事ではSvelteとTypescriptのコードをRollupでバンドルしてるプロジェクトの環境構成について紹介をしていきたいと思います。</p>
<h2>はじめに</h2>
<p>まずはRollup + Svelete + Typescriptの環境で基本的に必須になる以下のパッケージをインストールします。</p>
<ul>
<li>rollup</li>
<li>rollup-plugin-svelte</li>
<li>svelte</li>
<li>svelte-preprocess</li>
<li>typescript</li>
</ul>
<h2>rollupプラグインの選定</h2>
<p>次は環境や必要な機能に応じてrollupのプラグインをインストールしていくのですが、かなり数が多いです。しかも<a href="https://github.com/rollup/awesome?tab=readme-ov-file#awesome-rollup-">公式のプラグイン紹介ページ</a>にあるものに絞っても同じようなのが複数あったりしてどれを使えばいいのかぱっと見だとわかりません。例えばTypescriptに関するプラグインだけでも4つ(typescript, ts-paths, ts, typescript2)存在してます。</p>
<p>とりあえず今回はプラグインの数をできるだけ減らしつつ<a href="https://github.com/rollup/plugins/tree/master?tab=readme-ov-file#rollup-plugins">公式が提供しているプラグイン</a>のみを採用する方針にしました。サードパーティ製は公式プラグインの改良版的なものだったりして高機能でダウンロード数が多いケースもあるのですが、マイグレーションによる不具合対応等のメンテナンスがされなくなってくることも多いので長期的な保守性を優先しました。</p>
<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>
<p>以下がrollupの設定ファイルです。</p>
<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>
<p>最近rollupのエラー対応してる時に幾つかのプラグインがdeprecatedになっていて別のプラグインを推奨されたことがきっかけでマイグレーションを行い現在の構成になりました。初めは最小限の対応で済まそうと思いましたが、パッケージバージョンの相互依存が複雑だったり古いバージョンの仕様やドキュメントを確認するのが大変だったので全部最新までマイグレーションすることにしました。</p>
<p><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時にエラーが出ず、一部の挙動がおかしくなる程度の症状なので意外とはまりポイントかもしれません。</p>
<p>期間が空いてしまうとすべてを一気にマイグレーションする羽目になり、結果的に工数も膨れ上がったり不具合のリスクも高くなってくるので、これを機にこまめにchange logをチェックして対応していこうと思います。</p>
<p>コードの規模がそこまで大きくなく開発時の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の方が良いかもしれません。</p>
<h2>最後に</h2>
<p>今回はとりあえず動く程度のsvelte+TS+rollupの構成の紹介になりましたが、より良いパフォーマンスや型安全性等を目指してeslint, tsconfig, swcconfigの設定周りも紹介できればと思います。</p>
<h2>一緒に働くメンバーを募集中</h2>
<p>RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！</p>
<p>${RECRUIT_LINK}</p>
<p>また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。<br>
${WANTEDLY_LINK}</p>


Rollup + Svelte + Typescriptの環境構成

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


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

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

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


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

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

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

Blog

Recent Article

RightConnect by KARTEの裏側

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

Rollup + Svelte + Typescriptの環境構成

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

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

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

Archives

Writers