RightTouch Blog

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

RightTouch Blog編集部です！
2025/1/29に株式会社estie、ASCEND株式会社、株式会社RightTouchの3社合同で「<a href="https://estie.connpass.com/event/340354/">プロダクトエンジニア〜ユーザー価値を支える技術〜</a>」というイベントを開催しました。
各社からフェーズや成り立ちが異なるプロダクトエンジニアが集い、ユーザー価値の向上やプロダクト開発における新たなアプローチを紹介しました。
<h2>小規模組織のプロダクトエンジニアとして、アンラーニングしたこと</h2>
RightTouchからは<a href="https://x.com/_hedrall">小室(com)</a>が「小規模組織のプロダクトエンジニアとして、アンラーニングしたこと」という題目で登壇しました。
<img src="https://ik.imagekit.io/righttouch/ff937a42-4899-4767-89db-29c92ac17764/250129-01.jpg" alt="登壇風景">
当日の発表スライドを公開しているので、ぜひご覧ください。
<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>
PdMがいないチーム体制においては、これまで仕様と設計にフォーカスしてきたエンジニアも戦略や要件に入り込んでいくことが非常に重要になります。
<img src="https://ik.imagekit.io/righttouch/559fc6cc-57ae-4266-94ae-96d94c56e704/250129-02.jpg" alt="プロダクトエンジニアは要件・仕様・設計のプロダクト全体に責任を持つ">
特に新規プロダクトの初期には代表が直接コミットするケースがあります。この場合、視座の違いから従来のフレームワーク等では議論の粒度が揃わないケースが多く、議論から落とし込まれたタスクも状況の変化によってすぐに無意味なものになりがちです。
さらに、<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のような様々なプロダクトを並行して立ち上げるような組織においてはボトルネックになる可能性が非常に高いです。
PdMというチーム機能を補う上で、意識的にエンジニアが戦略や要件のすり合わせに入っていくことで限られたリソースの中でも効果的が議論がしやすくなるということを語っています。
<h2>プロセスは変わっても、開発の基礎は変わらない</h2>
日々流動的に状況が変わっていく中でエンジニアとしての立ち振る舞いも都度変化していきます。とはいえ、開発の基礎は常に変わらない部分としてエンジニアとして制御しやすい部分です。
<img src="https://ik.imagekit.io/righttouch/1286772f-2b44-4450-a285-bdec25de0516/250129-03.jpg" alt="Clean ArchitectureやDDDなどを取り入れる効果">
Clean ArchitectureやDDDなどを積極的に取り入れることで
<ul>
<li>プロダクトの雛形を作ることによる横展開のしやすさ</li>
<li>PdMがいない環境での思考をモデリングという形で残し、不確実性の高い状況においても一貫した思考と説明をするためのメンタルモデルを構築しておくこと</li>
</ul>
など、新規プロダクト開発においてこれまで培ってきた知見をこだわりを持って実行していくことも大切であるという話で全体を締め括りました。
<h2>プロダクトエンジニアのコミュニティ始めます</h2>
RightTouchでプロダクトエンジニアとして活躍するメンバーが主体となって「Product Engineer Session」というコミュニティを立ち上げました！
「Product Engineer Session」は、技術力だけでなくユーザ価値を最も大切にしてプロダクト視点で日々の開発に向き合っているプロダクトエンジニアの、ユーザーに価値を届けるためのフルサイクルの活動の中で得られた知見や気づきを共有し合う交流の場です。
<a href="https://pesess.connpass.com/event/344220/">初回のイベント</a>を3/4(火)にRightTouchのオフィスで行います！
<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"> 
</a>
エンジニアに限らず、PdM、Engineering Manager、Designerなど、価値を生むプロダクト開発について日々考え実践されている方の、より深い学びの場になると信じていますので、興味がある方はぜひご参加ください！
<h2>最後に</h2>
RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを絶賛採用中です。 
少しでも興味を持った方がいればぜひお話ししましょう！
エンジニア求人情報の詳細 
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a>
採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>

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

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

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

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

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

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

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

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

※この記事は<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>

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

こんにちは！RightTouchエンジニアのikkiです。
本記事は、RigjtTouchのエンジニアメンバーに「プロダクト志向」について聞いてみたシリーズ、第3弾のカスタマーエンジニア編です。
▼第1弾はこちら 
<a href="https://blog.righttouch.co.jp/product-thinking-interview-product-engineer">あなたにとっての「プロダクト志向」教えてください！〜プロダクトエンジニア編〜</a>
▼第2弾はこちら 
<a href="https://blog.righttouch.co.jp/product-thinking-interview-design-engineer">あなたにとっての「プロダクト志向」教えてください！～デザインエンジニア編～</a>
RightTouchでは「全てはプロダクトのために /全員プロダクト担当」をバリューに掲げ、日々プロダクトに向き合っています。
ですが、それぞれのメンバーがプロダクトに対し、どんな思考プロセスやスタンスで向き合っているのかを、僕自身があまり深く知らないなと思い立ち、複数のメンバーへインタビューしてみました。
シリーズ最終回となる第3弾は、カスタマーエンジニアのkossyさんに話を聞きました！
<h2>カスタマーエンジニアkossyさんが考える「プロダクト志向」とは</h2>
――まずはkossyさんの経歴を教えてください。
kossy:RightTouchは二社目の企業になります。大学院を卒業した後、ワークスアプリケーションズにエンジニアとして入社し、初期配属はこれまでオンプレ環境向けにプロダクトが提供されていたところをSaaS型に移行していくという動きに伴って必要な検証やバージョンアップを行うチームにアサインされました。
その後、エンジニアのリーダーやマネージャーを任せてもらうようになり、ビジネスのメンバーと関わったり、クライアントと直接やり取りしたりといった機会が増えました。プロダクトをどう改善していくべきかや、課題の解決に向けてどういうプロダクトを作れば良いのかといった、プロダクトの上流に関わるようになったんです。
そういった経験から、「プロダクトを通じた本質的な価値提供」ができる環境でさらに挑戦したい気持ちが芽生え、2022年4月にプレイドに転職、その後RightTouchに転籍しました。入社経緯はこちらの記事でも詳しく話しているので、ぜひ読んでいただけると嬉しいです！
<div class="iframely-embed" data-embedded-url="https://note.righttouch.co.jp/n/n7e98ab915784"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://note.righttouch.co.jp/n/n7e98ab915784" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fnote.righttouch.co.jp%2Fn%2Fn7e98ab915784&key=878c5bef402f0b2911bf6d4ce6261abd">カスタマーエンジニアとしてプロダクト開発にジョイン。RightTouchで見つけた理想の仕事環境とは｜RightTouch</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
――カスタマーエンジニアという職種も、どの会社にもあるわけではないので珍しいですよね。普段はどういう役割や思考で、プロダクトづくりに向き合っているんですか？
kossy:まずカスタマーエンジニアは、プロダクトのスペシャリストとしてプロダクトと顧客をつなぐエンジニアで、顧客とのコミュニケーションからコンセプトレベルの機能のデモ開発まで幅広い役割を担っています。機能を開発するというより、プロダクトを深く理解しているエンジニアかつビジネスメンバーとイメージしてもらえるとわかりやすいと思います。
思考のフローとしては、まず理想としてのTo Beを考えるところから入りますね。当たり前だと思うことを当たり前にできるシステムが良いシステムだと思っているので「なんでこれはこうなっていないんだろう」「こうしてくれればいいのに」というストレスを感じない、理想のあるべき姿を想像しています。To Beを考えたあとに、As Isとのギャップを見比べて、そのギャップを見て、埋めていくというのが基礎になっています。
――To Beには正解がないですし、クライアントごとにTo Beも変わってくると思います。どのようにTo Beを設定していますか？
kossy:これはその通りですね。To Beを考えるというのはある種当たり前の話で、ある人にとってのTo Beはある人にとってはそうではない、というところが難しいところだと思います。一つのプロダクトで提供される同一の機能による価値の総和を、いかに大きくするかという観点において、具体と抽象を行き来する思考プロセスがプロダクトにおけるTo Beを立てるのには不可欠だと思います。
ステークホルダーごとに理想は異なりますし、言葉にしていることが真の課題ではないこともあります。極端な例を挙げると「レポートをある指標で簡単に絞り込みたい」といったフィードバックをしたクライアントのTo Beは、「ワンクリックで特定の指標で絞り込むことができる」と受け取ることもできます。ですが、その具体的な要望に対し「なぜそれを実現したいのか？」と一段深掘ると、「社内テスト用のデータを除いたレポートを見たい」といった業務課題が見えてきます。そこからさらに、社内のテストデータは他社では違うやり方で区別するケースもあるよね→そしたら区別する方法は柔軟に設定できた方がいいよね→指標を柔軟に設定できるようになれば、他社からフィードバックを受けたこの課題も解決できるよね、というように課題要素を抽象的なものに昇華できるようになると、よりインパクトのあるTo Beを見つけることに繋がります。
ただ、あまりにも抽象化しすぎると、今度はクライアントにとって直感的に利用しづらく、使いづらい機能になってしまうので、そのバランスが難しいですね。抽象化しすぎたなと思ったら、少し具体のユースケースに沿った機能に寄せてみて、また抽象化してという作業を頭の中で繰り返したり、メンバーと壁打ちしたりしながら一番しっくりくるポイントを探しています。
また、クライアント側だけでなく、エンドユーザーの目線でもTo Beを考えるようにもしています。私達が提供しているのはBtoBtoCのプロダクトなので、クライアントの先のエンドユーザーにとっても価値のあるプロダクトであるのかは重要なポイントです。自分自身がエンドユーザーとしてサービスに接するときに、素直にいいなと思えるプロダクトであってほしいですしね。
具体・抽象のレイヤーや、複数のステークホルダー視点を俯瞰的に行き来しながらTo Beを探すことは、普段から自然とやっているかもしれません。カスタマーエンジニアという職種の特性上、クライアントと接する機会は多いので、どうしても具体的なクライアントの要望に目が行きやすいんですよね。エンジニアとしてのバックグラウンドから、特定のクライアントの声に寄りすぎると良いプロダクトにならないという経験則があるので、そういった思考をしやすいのかもしれないです。
――最後にkossyさんはどんな特徴のあるプロダクト・サービスが好きか教えてほしいです！
kossy:、自社・クライアント・エンドユーザーのそれぞれに対して、三方良しになるサービスが好きですね。利益に見合った貢献ができているプロダクトと思ってもらえているかどうかは、大事にしている価値観です。特に業務をより良く改善していくサービスは、実益も出るし、貢献も実感できるので、特に好きかもしれません。それが満たされるサービスであれば、事業内容にこだわりはないですね。
カスタマサポートは、そういう点では自分の「好き」を満たしている良い事業領域だと思っています。エンドユーザーとして誰もが生きている間に何度も関わるものだし、オペレーターの皆さんの業務イメージも何となく想像できている。その中で、エンドユーザーやカスタマーサポート業務に従事する人の目線に立って、To Beを描けるのが心地よいし、自分の性格にあっているんだと思います。
<h2>RightTouchでは一緒に働くメンバーを募集しています！</h2>
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今の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> 
カスタマーエンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/customer-engineer">https://recruit.righttouch.co.jp/customer-engineer</a>

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

普段のRightTouchメンバーに迫ろう！ということで企画した今回の記事。メンバーにアンケートを取ったところ、デスクワークが快適・便利になるガジェットから、生活ライフハックなツールまで様々な情報が集まりました。（メンバー同士でも共有されていない有益な情報があるはず…！）
どんなところがおすすめなのか＆普段使っている様子なども添えながら、ご紹介していければと思います。
<hr>
<h2>デスクガジェット編</h2>
<h3>トラックボール付き分割型キーボード<a href="https://shirogane-lab.net/">「Keyball」シリーズ</a></h3>
おすすめ by giinyo &amp; たっけん（二人から推薦がありました！）
giinyo：キーボードから手を動かさなくてよくなります！キーボードとマウスの行き来がなくなり、作業は捗るし肩こりは減るしで、とても良いです。ただし、自分ではんだ付けする必要があるのと、40%キーボードに慣れる必要があるのでハードルは高めです。
たっけん：キーボードのホームポジションから手を動かさずに全ての操作ができるところがすごい。 
ただキー数が極端に少ないため新しいキーマップに慣れるまでが必須で、普段のコーディングで使用できるほどは使いこなせていないです。
<img src="https://ik.imagekit.io/righttouch/0467c31b-95d2-4189-b747-0d43edb606a6/image6.jpg" alt="image6.jpg">
<center>たっけんさん自作の<a href="https://shirogane-lab.net/items/64b8f8693ee3fd0045280190">Keyball39</a> 
giinyoさんが<a href="https://shirogane-lab.net/items/64b7a006eb6dbe00346cd0c5">44シリーズ</a>を使っているそう</center>
<h3>キーボード<a href="https://satechi.net/products/slim-x1-bluetooth-backlit-keyboard">「Satechi スリム X1 Bluetooth バックライトキーボード」</a></h3>
おすすめ by mashu
見た目がシンプルで薄く、Macのキーボードに打感が近いのが気に入ってます。Appleのトラックパッドと見た目の相性がGood(写真参照)。あとは、Bluetoothの接続も比較的簡単で、スイッチを入れるだけで自動で繋がる便利なキーボードです。
<img src="https://ik.imagekit.io/righttouch/9c253bd3-b221-4834-8831-7acb77c2db13/image12.jpg" alt="image12.jpg"> 
<center>トラックパッドとのセット感がいい感じ！</center>
<h3>キーボード<a href="https://kinesis-ergo.com/keyboards/advantage360/">「Kinesis Advantage360 Keyboard」</a></h3>
おすすめ by sanshiro
人間工学に基づいて製作されている分割キーボード。手、指の形に合わせて、打ちやすいように配置されたキーで、親指を駆使することで手の移動も最小限に抑えられる。 
また、分割キーボードなので、巻き肩になりにくく、肩こりが解消した気がする。 
気になるポイントとしては、約8万円と比較的高額なことと、配置が特殊なので通常のキーボードと並行して使っていると打ち間違いが発生しやすいことです。 
<img src="https://ik.imagekit.io/righttouch/79a165b7-2c56-4490-ad91-cc013d8b689b/image13.jpg" alt="image13.jpg"> 
<center>流線的なフォルムが素敵</center>
<h3>骨伝導ヘッドセット<a href="https://jp.shokz.com/products/opencomm2uc">「Shokz OpenComm2」</a></h3>
おすすめ by 川口
骨伝導なので周りの音を聞きつつ仕事ができ、オフィス・在宅ともに活用できるものです。在宅で子守をしながら仕事しているときに、泣き声に気づくことができたりするので、安心して仕事に取り組むことができます。あとはちゃんとノイズキャンセリングもついていて、周りの音が相手に聞こえないようになっているので、環境音があっても使えます。 
<img src="https://ik.imagekit.io/righttouch/40b28bbf-eca0-4137-b778-fc791bdd7f44/image8.jpg" alt="image8.jpg"> 
<center>一日中使っても疲れない快適なデザインとのこと</center>
<h3>モニターライト<a href="https://www.benq.com/ja-jp/lighting/monitor-light/screenbar-halo.html">「BenQ ScreenBar Halo」</a></h3>
おすすめ by sanshiro
部屋を暗めにするとモニター以外の情報が入って来づらくなって集中しやすい気がするのですが、ただ部屋を暗くしてしまうと、モニターの明かりが直で届いて眩しい。 
このモニターライトを使うことで、モニターの周辺のみ光量を確保でき、バックライトもあるので目への疲労も負担できて良い感じです！ 
<img src="https://ik.imagekit.io/righttouch/45c7707e-37b4-4fcc-af41-46cfae79b0d7/image9.jpg" alt="image9.jpg"> 
<center>モニターへの向き合い方が真剣すぎてすごい</center>
<h3>VRヘッドセット<a href="https://www.meta.com/jp/quest/quest-3/">「Meta Quest 3」</a></h3>
おすすめ by sanshiro
Virtual Desktopで最大5画面まで利用でき、かつリラックスした姿勢で仕事ができます。 
2と比較して、解像度がかなり向上して使いやすくなり、またパススルーがあることで、周辺の状況もカラーで見えるようになったので、いちいち外さなくてもトイレに行ったり、飲み物を取ってきたりがしやすくなりました。リモートワークの運動不足解消にも効果的！ 
<img src="https://ik.imagekit.io/righttouch/2500fe4a-38d5-43d7-bf88-c290088fc8e7/image2.jpg" alt="image2.jpg"> 
<center>Meta Questを日常使いできる＆しているとは知りませんでした！</center>
<h2>ライフハック編</h2>
<h3>充電アダプター<a href="https://www.ankerjapan.com/pages/anker-nano-2">「Anker Nano II 65W」</a></h3>
おすすめ by kanke
USB-Cタイプの充電器で最大65W出力なのでMacBook Proの充電に使用しています。 
標準の充電アダプターに比べてだいぶコンパクトなのが気に入っています！普段から使用していますが、特に出張のようなPCを持ち運ぶ時にとても重宝します。 
<img src="https://ik.imagekit.io/righttouch/a401cfd7-a08f-45d2-9143-8ce27f6eb702/image7.jpg" alt="image7.jpg"> 
<center>左がMac標準の充電アダプターで、右がAnker Nano II。比較すると歴然とするサイズの違い</center>
<h3>スマートリモコン<a href="https://shop.nature.global/collections/nature-remo">「Nature Remo」</a></h3>
おすすめ by yabu
家電コントロールに便利。特にエアコンみたいな家電にはおすすめ。 
<img src="https://ik.imagekit.io/righttouch/f9176141-c2d0-4c3d-a363-aad57fc244f6/image5.png" alt="image5.png"> 
<center>画像元；<a href="https://shop.nature.global/collections/nature-remo">Nature Remo公式サイト</a></center>
<h3>スマートロック<a href="https://qrio.me/smartlock/">「Qrio Lock」</a></h3>
おすすめ by 木村
家を出る時に振り返って鍵を閉めなくていい。帰ってきた時にカバンから鍵を探し出さなくていい。ただそれだけなんですが、毎日繰り返すことはこのちょっとした変化でもかなり快適に感じます。本当に買ってよかった…！ 
<img src="https://ik.imagekit.io/righttouch/956dc258-f05e-48a4-8689-c48603711155/image1.png" alt="image1.png">
<center>画像元；<a href="https://qrio.me/smartlock/">Qrio Lock公式サイト</a></center>
<h3>ポータブルゲーム機<a href="https://rog.asus.com/jp/gaming-handhelds/rog-ally/rog-ally-2023/">「ROG ALLY」</a></h3>
おすすめ by yabu
夜寝る前にベッドでPCゲームができるようになって快適です。 
<img src="https://ik.imagekit.io/righttouch/a563dd82-db7b-4a19-a4bf-ae391929df04/image10.jpg" alt="image10.jpg"> 
<center>画像元；<a href="https://rog.asus.com/jp/gaming-handhelds/rog-ally/rog-ally-2023/">ROG ALLY公式サイト</a></center>
<h3>タイマー<a href="https://amzn.asia/d/7SQ2PAZ">「Time Timer」</a></h3>
おすすめ by yabu
こどもに時間制限を与えることが必要なときに便利。 
<img src="https://ik.imagekit.io/righttouch/578a0c3b-5c9c-47c4-acb2-65ae3c439e87/image11.png" alt="image11.png"> 
<center>画像元；<a href="https://amzn.asia/d/7SQ2PAZ">TIME TIMER公式サイト</a></center>
<h3>カメラ付き耳かき<a href="https://www.bebirdmall.com/">「Bebird」</a></h3>
おすすめ by yabu
カメラ付き耳かきでスマホとBluetooth接続できるから便利。
<img src="https://ik.imagekit.io/righttouch/3b70a81c-348d-4f3c-ac8b-06e1703b7c85/image3.png" alt="image3.png">
<center>画像元；<a href="https://www.bebirdmall.com/">Bebird公式サイト</a></center>
<hr>
RightTouchメンバーおすすめのガジェットを紹介させていただきました。すでに持っているものや、買ってみたいなと思ったお気に入りが見つかったでしょうか？ 
普段のRightTouchメンバーの様子が少しでも伝わっていれば嬉しいです。 
より細かいチームの情報は、カジュアル面談などでお話したいと思いますので、少しでも興味を持ってくださったら、採用サイトやWantedlyからぜひ気軽にエントリーください。 
▼採用サイト 
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a> 
▼Wantedly 
<a href="https://www.wantedly.com/companies/righttouch/projects">https://www.wantedly.com/companies/righttouch/projects</a>

RightTouchメンバーのおすすめガジェット12選

こんにちは！RightTouchエンジニアのikkiです。
本記事は、RightTouchでのエンジニアメンバーに「プロダクト志向」について聞いてみたシリーズ、第2弾のデザインエンジニア編となります。
RightTouchでは普段の会話やメンバーを採用するときの基準など、さまざまな場面で「プロダクト志向」が登場します。普段からよく飛び交う言葉だからこそ、その真意を深く知ることができればより相手のことを理解でき、より良いプロダクトづくりに活かせるのでは？と思い、複数のエンジニアメンバーのプロダクト志向について掘り下げるシリーズを始めています。
▼第1弾はこちら 
<a href="https://blog.righttouch.co.jp/product-thinking-interview-product-engineer">あなたにとっての「プロダクト志向」教えてください！〜プロダクトエンジニア編〜 </a>
シリーズ第2弾となる今回は、デザインエンジニアのkankeさんにインタビューしました！
<h2>デザインエンジニアkankeさんにとっての「プロダクト志向」とは？</h2>
――kankeさんの経歴について、簡単に教えてください。
kanke:デザインの専門学校を出たあと、看板などの紙ものを扱うデザイナーとして就職しました。ファーストキャリアは、Webとは無縁の分野でしたね。そこで3年半ほど経験を積んだ後に「Webをやってみたい！」と思うようになり、Webコンサルの会社にデザイナーとして転職しました。いわゆる受託ビジネスだったので、中小企業を中心としたクライアントのためにWebサイトをひたすら制作する日々でした。当時はデザイナーもコーディングをする時代でしたが、クライアントの規模的に予算や納期の制約もかなりあり、じっくりコーディング技術を身につけられる環境ではなかったんです。「コーディングは好きだし、やるならもっとじっくり丁寧に、そして技術にもきちんと向き合いたい」と感じ、思い切ってエンジニアに転向することにしました。
転向後は、フロントエンドエンジニアとして、ナショナルクライアントのWebサイト制作を受託していました。大手のお客さまが増えたので、Webサイトとしても大規模なプロジェクトが多く、技術にじっくり向き合うことができるようになりました。その後、Webアプリケーション制作の仕事にも関わるようになり、徐々にプロダクト開発に携わるようになりました。予約管理システムやミュージアムで利用する音声ガイドアプリなどの開発もしました。
ですが、やはり受託という立場の壁はありました。基本的にはクライアントから依頼されたプロダクトを作り終わった後は、プロダクトとの関わりが薄くなってしまいます。もちろん保守運用や、新機能を追加する依頼がたまにはあったりするんですが、自分が開発したプロダクトに継続的に関わるということは難しかったです。そこで、もっときちんと自分でプロダクトやシステムに関わりたいと思ってプレイドに転職しました。それが2年前くらいですね！
その頃はちょうどRightTouchが立ち上がって間もない時期で、エンジニアリソースが必要とされていたのでRightTouchに配属されました。そして、そのまま今に至ります。RightTouchではデザインエンジニアとして、管理画面やエンドユーザーが触れる部分のUIなど、見た目や使いやすさに関わる部分の実装に関わることが多いです。
――受託会社から事業会社に転職したことで、プロダクトに向き合う姿勢や志向で変わった点はありますか？
kanke:クライアントからの依頼に対し、受託会社では基本的にディレクター職のメンバーが、クライアントとのすり合わせからアウトプットのイメージまで深いところは全て決める体制でした。なので、エンジニアには大枠が決まった状態でタスクとして降りてくるので、色々アイディアは出すものの、そもそもの機能の目的などに触れたり提案したりという経験はなかったですね。
RightTouchではバリューとして「全員プロダクト担当」が浸透しているので、PdMしか機能を考えられない、エンジニアだから顧客の声を聞けないといった垣根はなく、全員でより良いプロダクトになるよう議論し開発するというプロセスは、今までの経験ではなかったものです。
正直なところ、機能をゼロベースで考えるのが得意かと聞かれれば、回答に詰まってしまいます。経歴的には、ある程度決まったものをガシガシ作ったり、どうやったらもっと使いやすくなるか考えたりする方が得意だし、好きですね。
デザインをしていた時も、与えられた情報を、どのように組み立てて分かりやすく伝えるかという情報設計のスキルが肝になっていたので、自分はベースに何かある状態の方が取り組みやすいタイプなんだと思います。
――kankeさんにとって「プロダクト志向」はどういうものだと捉えていますか？
kanke:解決したい課題や実現したい世界に対して、僕らは何ができるのかというところをプロダクトを中心に考えるということですかね。 
課題に対してどんなプロダクトや機能が必要か、今足りないものは何か、逆に不要なものは何かなどを考え抜いて、良いプロダクトを作っていきたい気持ちがあります。
――プロダクト作りは、どんなプロセスで進めていますか？
kanke:仕様をある程度考えてから作り始めていて、特に特殊なやり方をしているわけではないですね。
個人的な理想としては、最初にざっくりと作って磨き込んでいけたら良いですね。話したように、自分はたたき台がある方が開発を前に進めやすいタイプです。雑なアウトプットで良いので、全体を何となく見えるようにしてから、「難しそうと思ってたけど、こうやればできるよね」「その目的のためにはこういう機能の方が必要じゃない？」といったチームでのやり取りを通じて、細部を作り込んでいけたらベストだなと。
もちろんRightTouchで、その理想が全て実現できているわけではありませんが、頑張って取り組んでいます。進めていくうちに必要なことが見えてきて仕様が変わることも多いので、変わるという前提で最初はざっくり小さく作っていきたいというスタンスです。
ーーRightTouchはいわゆるBtoBtoCで、クライアントだけでなく、その先にカスタマーサポートを受けるエンドユーザーがいます。開発にあたって両者のバランスをどのように考慮していますか？
kanke:クライアントとエンドユーザー、どちらも大事なので、両者のバランスを取るようにしています。理想はエンドユーザーに寄り添うことですが、エンドユーザーの目線に寄り過ぎては、逆にクライアント側で使いづらくなってしまい、結局思ったように使ってもらえずエンドユーザーに届かない可能性も出てくるので。それを避けるためにも、両者のことを考慮に入れて、最終的にはエンドユーザーの目線に立ちたいとは思っています。
――kankeさんはどんな特性をもつプロダクトに惹かれるんですか？
kanke:「これなんか便利そう！」と感じられるものですね。今まで面倒くさいと思っていたことを一瞬でラクに解決してくれるプロダクト、それこそ身近な例だと確定申告や給与明細のWebサービスがあると思います。これを入力するだけでOKという、今まで面倒で負担に感じていた部分を減らし便利にしてくれていて、RightTouchらしく言えば「負の体験を減らしている」プロダクトには魅力を感じやすいです。
あとは、デザインの経験があるからか、UIなどの見た目が綺麗なプロダクトにも惹かれますね。触ってみたいなとかいじってみたいなとか、こういう見せ方をしているんだとか、つい考えてしまいます。
――最後に、作ってみたいプロダクトがあれば、現実性を問わず教えてください！
kanke:「どこでもドア」を作りたいですね。仙台からリモートで働いていることもあり、自分で作って、自分で使いたいですね（笑）。RightTouchはバーチャルオフィスなどオンライン環境も活発ではありますが、直接オフィスで会ったり喋ったりしている様子を見ると、羨ましいなと感じることもあるので。
――どこでもドアは確かにほしい！（笑）コミュニケーションを大事にしているkankeさんらしい回答かもしれないですね。今日はありがとうございました。
<h2>RightTouchでは一緒に働くメンバーを募集中</h2>
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！
▼株式会社RightTouch採用サイト 
<a href="https://righttouch.studio.site/recruitment">https://righttouch.studio.site/recruitment</a> 
▼募集中のポジション 
<a href="https://righttouch.studio.site/#jobs">https://righttouch.studio.site/#jobs</a>

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

RightTouchはコミュニケーションツールのひとつとして、バーチャルオフィスの<a href="https://www.around.co/">「Around（アラウンド）」</a>を使用しています。出社頻度がメンバーによって異なることもあり、Aroundがコミュニケーションを円滑に進める手助けにもなっています。
バーチャルオフィスになじみがない方、Aroundを使用したことがない方にも、バーチャルオフィスを通じた社内コミュニケーションの雰囲気を掴んでもらえたらと思い、エンジニアのKankeさんにAroundを導入した背景やその魅力、実際にどのように使っているのかを聞いてみました！
<hr>
――いつから導入を開始されましたか？
1年前くらいにメンバーが増えてきて、オフィスに行っても席がないことが増えてきたことでバーチャルオフィスの検討をし始めました。その中で話題だったAroundの他にも<a href="https://ja.gather.town/">「Gather」</a><a href="https://discord.com/">「Discord」</a>を試してみて、弊社にはAroundが合っているなと感じ、今も使用しているのはAroundです。ただ、強いこだわりがあるわけではないので今後も良いツールがあれば乗り換える可能性はあります。
最近、以前より広いオフィスに引っ越したものの、席数が足りていてもリモートがメインのメンバーもいますし、メンバー間のコミュニケーションを担保する意味でもAroundを変わらず使っています。 
<img src="https://ik.imagekit.io/righttouch/01b3c9c8-b435-474f-95a6-1731fc40027a/image1.png" alt="image1.png"> 
Around ホームページでの説明（引用元：<a href="https://www.around.co/">Around</a>）
――実際どのようにAroundを使っているんですか？
実際の様子はこんな感じです！Aroundは、GatherやDiscordと比べて、アプリケーションのサイズを小さくできてスペースを取らないので、作業をしていても邪魔にならず、良い意味で存在感が薄いです。
<img src="https://ik.imagekit.io/righttouch/5cb407ec-e998-4499-a5a4-d1585e82b275/image5.png" alt="image5.png"> 
Kankeさんは緑色のフィルターを設定
普段は画面の端の方に置いておいて、しゃべりたいときはミュートをオフにして話しかけます。例えばGatherだと、その人がいる場所までアバターを動かし近くに行く必要がありますが、Aroundはそもそも「ビデオ会議ツール」として設計されているものなので体験が異なります。話しかけた声や内容は同じルームにいる全員に聞こえますが、その体験は実際のオフィスで話しかける感覚に近いですね。
カメラは基本オンにしていますが、顔の表示サイズも小さくできますし、フィルターをかけられるので見られていると感じにくく、意識せずに使えるところが気に入っています。フィルターは各自が自由に設定しています。
――確かにオフィスで話しかけるのに近いというのは想像しやすいですね！とはいえ、個別に話したい場面もあるように思うのですが・・？
個別で話したいニーズにも対応できるようになっています！みんなで集まる場所とは別に、個別にミーティングが可能なルームを作っています。例えば1on1やペアプログラミングをする際には、個別ルームに移動して、他の人の作業や会話を邪魔しないように配慮しています。また、他のツールと同じように画面共有も可能なので、会話の延長でプロダクトのことを相談したい時などに便利ですね。 
<img src="https://ik.imagekit.io/righttouch/32c4d8d1-8519-45e1-a84c-db621740b1f4/image2.png" alt="image2.png"> 
画面を共有しながらプロダクトに関する議論ができる
――オフィスで集まるときと、バーチャルオフィスを使用するときの違いはありますか？
月に1回全体で集まって行う会議があるので、その日は基本的に現地参加を推奨しています。エンジニアメンバーでの会議も対面で行った方がやりやすいものもあるとは思うんですが、全員が頻繁に出社できるわけではないので、四半期のはじめなどの節目には対面で集まってオフサイトを行っています。普段はオンラインでも問題なく仕事ができる体制ですね。
<img src="https://ik.imagekit.io/righttouch/3ef26fae-56e2-47b5-8973-2091807277b3/image3.jpg" alt="image3.jpg"> 
月次の全体会議でオフィスに集まる様子
まだまだ発展途上のプロダクト・チームですが、エンジニア全員の生産性とコミュニケーション促進のどちらにもこだわり、日々開発により向き合いやすくなるよう模索しています。これからもAroundに限らず、色々な新しいツールや施策を推進し、よりよいプロダクトづくりにみんなで取り組んでいきたいですね！
<hr>
今回の記事では、RightTouchでは、バーチャルオフィスAroundをどのように使用しているのかまとめてみました。出社スタイルがバラバラでも、バーチャルオフィスを使うことで出社・リモートに関わらず円滑にコミュニケーションを行って、日々開発を進めています！
RightTouchのブログでは、他にも社内の勉強会の様子やチームについて詳しくご紹介していますので、ぜひご覧ください。 
▼RightTouchブログ 
<a href="https://blog.righttouch.co.jp/">https://blog.righttouch.co.jp/</a>
より細かいチームの情報は、カジュアル面談などでお話したいと思いますので、少しでも興味を持ってくださったら、採用サイトやWantedlyからぜひ気軽にエントリーください。 
▼採用サイト 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a> 
▼Wantedly 
https://www.wantedly.com/projects/1493065

バーチャルオフィスAround、RightTouchではどう使っている？

RightTouch Blog編集部です！ 
今回の記事では、この12月に社外イベントにRightTouchメンバー2人が登壇したので、その発表内容を簡単に共有したいと思います。
<hr>
<h2>年末の大掃除〜リファクタリング・コード断捨離勉強会〜</h2>
取締役 兼 開発責任者の籔は、12月12日に開催された「<a href="https://plaidtech.connpass.com/event/303281/">年末の大掃除〜リファクタリング・コード断捨離勉強会〜</a>」イベントに参加・登壇させていただき、「機能リプレースで進化する: SvelteからPreactへのフロントエンド刷新と柔軟なサーバーモデルへのリファクタリング」という内容で発表しました。
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="機能リプレースで進化する: フロントエンドの刷新とサーバーモデルのリファクタリング" src="https://speakerdeck.com/player/9c66dbf83b8642b289d02f47152b50af" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h3>補足</h3>
今回の発表では、エンドユーザースクリプトとサーバーモデルのリファクタリングについて話しましたが、他にもさまざまな改善を行っています。
例えば、施策間のデザインを共通で定義できる機能の追加や、汎用的な機能になったことで1から作り直した設定画面なども行いました。それらについても、いずれ記事としてこのテックブログに載せたいと思っています。
<h3>感想</h3>
内容が単純なリファクタリングというよりも機能のリプレースがメインであったため、どれくらい興味を持ってもらえるか少し不安ではありました。ですが、発表後の懇親会では、大規模なリファクタリングをする上での意思決定という上段の話から、実際の技術的な話までいろんな質問をもらうことができ安心しました。
単なるリファクタリングとしての話もそうですが、リファクタリングという一見すると生産性が低いと思われがちなタスクにリソースを投入することがなぜ大事なのかということを、どうやって組織全体に伝えるかという問題を抱えている場合もあるのだなと感じました。
一方で、RightTouchでは全体としてプロダクトや開発への理解が深く、そういった改善活動への投資の理解も得やすい環境なので、恵まれているなとも思いました。
<hr>
<h2>Production目線で振り返る OpenAI DevDay</h2>
テックリードの齋藤は、12月18日に開催された「<a href="https://llm-in-production.connpass.com/event/303685/">LLMProd#3 Production目線で振り返る OpenAI DevDay</a>」イベントに参加・登壇させていただき、「Webカスタマーサポート向けSaaSにおけるLLMの活用」という内容で発表しました。
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Webカスタマーサポート向けSaaSにおけるLLMの活用" src="https://speakerdeck.com/player/179b2f12ef334937b991b31fcbcb074a" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h3>補足</h3>
今回は、「サポートシナリオの自動生成」というLLM機能の開発と、<a href="https://devday.openai.com/">OpenAI DevDay</a>での発表を踏まえた今後の展望をメインに発表を行いました。
公開した資料では省いていますが、当日は機能デモを交えて、開発で工夫した点や、どのような観点で機能コンセプトを作っていったかをお話ししました。
<h3>感想</h3>
各社、今後のLLM活用に関して共通して認識している部分(データの大切さ、エージェントの難しさ、UXの大切さ)はありつつ、会社ごとに異なる課題や視点もあり、とても刺激になりました。
また、登壇者の方々が、いち早くLLMで色々な実験をされているお話を聞いて、LLMに関しては、「とにかく興味を持って手を動かす」が大事だなと改めて認識しました。
RightTouchには、より良いプロダクトづくりのために、LLMを様々に実験できる環境が整っており、また、LLMの活用先として、豊富なデータアセットもあります。こういった環境をフル活用して、積極的にLLMの可能性を探索していきたいと思いました。
<hr>
<h2>最後に</h2>
RightTouchでは、エンジニアをはじめメンバーを募集しています！エンジニアリングだけでなく、プロダクトのコアやコンセプト創り、そして事業拡大における戦略・戦術検討まで、幅広く関われる今のRightTouchに興味を持っていただけたら、ぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！ 
${RECRUIT_LINK}
また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。 
${WANTEDLY_LINK}

イベント登壇しました！（リファクタリング・コード断捨離勉強会&Production目線で振り返る OpenAI DevDay）

<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>

Blog

Recent Article