RightTouch Blog

Yuto Akagi

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

<h2>はじめに</h2>
<p>RightSupport by KARTE(以下RightSupport)には簡単にサポートサイトを立ち上げる機能があり、<a href="https://help.rightsupport.karte.io/">RightSupportのサポートサイト</a>もその機能を利用して構築されています。</p>
<p><img src="https://ik.imagekit.io/righttouch/91547749-c532-44ad-8d35-4223aa7f72c5/250626-01.jpg" alt="RightSupportのサポートサイトのキャプチャ"></p>
<p><span class="caption">RightSupportのサポートサイトのキャプチャ</span></p>
<p>サポートサイト機能はNext.jsで静的生成したファイルを配信する仕組みで運用していたのですが、いろいろな課題が出てきてサーバーでSSRへと移行をしました。先日、無事にアーキテクチャの移行が完了したので、SSGでぶつかった課題やどうやってSSRに移行したのかその裏側を書こうと思います。</p>
<h2>サービス概要</h2>
<p>RightSupportは施策を実現するために「アンサー」と称してクライアントのFAQやナレッジなどの記事を管理する機能があります。外部から定期的に取り込むことはできますが、“正” のFAQデータを預けてもらうとユーザーにとっても運用が楽です。</p>
<p>せっかく“正”のデータを預かっているのだから、誰もが必要とするFAQサイトを簡単に立ち上げることができたら嬉しいはずです。これが出発点でした。</p>
<p>ホスティングする内容は割とシンプルで更新頻度が少ないので、静的生成にどんぴしゃなユースケースだと思い、初期版は次のようなアーキテクチャに決めました。</p>
<ul>
<li>更新がある都度、サイト全体をNext.jsで静的生成（SSG）する</li>
<li>生成されたサイトをAWS S3に上げて前にCloudFrontをかます</li>
<li>管理画面の操作に応じてRoute 53とACMのAPIをバックエンドから叩いて弊社ドメインのサブドメインをCloudFrontに向けたり証明書を発行したりする</li>
<li>独自ドメインを使う場合の証明書まわりを含む諸々のDNS設定を管理画面から提供する</li>
</ul>
<p>結果、サイトを簡単に立ち上げられ、<strong>デプロイ後は爆速でAWSそのものがコケなければ絶対落ちないFAQサイト機能</strong>ができました。</p>
<h2>課題続出でSSRへの移行を検討</h2>
<p>この構成でサービスを運用しているうちに次の欠点が見つかりました。</p>
<ol>
<li>完全SSGのため、ビルド時間がFAQ数に比例して増えてしまい、<strong>編集からサイトへの反映までの時間がだんだん伸びました。</strong></li>
<li><strong>バックエンドサーバがない手軽さの反面、認可・認証が実装しづらかった</strong>です。CloudFront関数やLambdaである程度がんばれたかもしれませんが、制限が厳しく、知見があまりない中で「サイトを本番運用する前に手軽に限定公開するためのBasic認証」がやっとのことでした。</li>
<li>サイトの数だけCloudFront distributionを立ててCloudFront関数を作るという、王道からだいぶ外れた仕組みのため、<strong>AWSの様々なリソース枯渇に悩まされる運命を辿りました</strong>。上限緩和を申請しても“裏上限”があり、そのまま進んだらAWSリソースの自前ロードバランシング的な仕組みを入れる必要が出てきたはずです。</li>
<li>ビルド処理はなんちゃって手作りジョブキューみたいな仕組みで管理していて、割とバグの温床となっただけでなく、<strong>サーバへの負荷が高かった</strong>です。ちゃんとしたジョブキューシステムに載っければよかったと反省しています。</li>
</ol>
<p>この中で3,4は運用者マターなので顧客には関係がないですが、顧客目線で1がかなり目立つ課題でした。<strong>コンテンツを編集したら即反映が当たり前の時代なのに、いけてないと反省しました。</strong></p>
<p>そこでSSGからSSR、つまりサーバを立てる形に舵を切りました。</p>
<p>サーバを運用するデメリットを呑めば、それ以外の欠点が全部吹っ飛びます。</p>
<h2>どうやって移行したか</h2>
<p>Next.jsはサーバ機能も備わっていて、SSGとSSRが両方できるので、「モードを切り替えればいいじゃん」と安易に妄想してしまうかもしれませんが、そう簡単にはいきません。なぜなら、前提が真逆だからです。</p>
<p>SSGしていた仕組みでは、「全データを集めておいて必要なものを取捨選択して生成しちゃう」という世界でした。今度SSRでは次のようになります。</p>
<p>例えば <code>https://hoge.example.com/faqs/my-faq/</code> というURLを踏んだらNext.jsサーバがリクエストを受けます。</p>
<p>このサーバはマルチテナントなので、まずどの顧客のデータを見ればいいのか特定できなければなりません。</p>
<p>Next.jsのmiddlewareの中でHostヘッダーを見て <code>/hoge.example.com/faqs/my-faq/</code> という形にパスを書き換えて <code>/pages/[domain]/faqs/[slug]</code> のNext.jsページに当てはめます。</p>
<p>これでdomainがhoge.example.comでmy-faqという名前のFAQであるという２点の情報から、必要最低限のリソースをピンポイントで効率よくとってくるという構図です。</p>
<p>難点をかいつまんで紹介すると、</p>
<ul>
<li>RightSupportのドメインオブジェクトは複雑なものもあって、このデータフローを実現するために<strong>利用中のリソースを特定するロジックの作り込みがやや大変</strong>でした。</li>
<li>Next.jsアプリケーションは3つのランタイムが動いていて、<strong>場所によってNode.jsの機能が使えなかったりで割と制限がシビア</strong>でした。相性のいいDBライブラリの特定（既存の仕組みが相性悪いとわかるまでの検証）も時間を要しました。特にmiddlewareでDBが叩けなかったのが全体のフローに大きく影響しました。</li>
<li>主な取得ロジックができた段階ではサイトは動いていましたが、<strong>パフォーマンスはSSGとは雲泥の差</strong>でした。調査したらDB接続に関する凡ミスと、DBネットワークとのVPC peeringで概ね解消しましたが、突き止めるまでのフットワークに時間がかかりました。</li>
<li>サーバを動かすクラウドの選定。サーバ自体はどこでも動かせますが、うまくいけば大量のドメインが向けられるので<strong>大量のTLS証明書を設定できるのはマスト</strong>です。幸いGoogle Certificate Managerの証明書マップエントリー、つまり1つのロードバランサーに紐付けられる証明書の数などが十分に多く、安心してサーバをGoogle Runに載せることにしました。</li>
</ul>
<p>上記を経てSSRサーバで動く新サポートサイトの誕生が迫りましたが、そこで2つの難関が現れました。</p>
<h3>SSGの同時運用</h3>
<p>SSR版の開発をゴリゴリ進めている中、SSG版の改修がある程度行われていました。</p>
<p>最初は両方でUIコンポーネントを共有する構想もあったのですが、実現が難しくて諦めました。</p>
<p>代わりにどうしたかというと、コード変更を検知して、なるべく差分を自動で適用する仕組みを作ってCIで運用しました。</p>
<ol>
<li>SSG版を触ったPRが上がると、<strong>前回同期したコミット以降の差分をCIが見る</strong></li>
<li><strong>差分があったら、エラーログを出して担当者を巻き込むよう指示する</strong>と同時に、ローカルsyncコマンドを案内する</li>
<li>ローカルで叩くsyncコマンドを用意しておいて、<strong>軽微な変更なら素早くSSR版にも適用できる</strong></li>
</ol>
<p>こんな半自動な形でSSR版の完成、SSG版のフィーチャーフリーズまでなんとか事故なく漕ぎつけました。</p>
<h3>悪魔のDNS</h3>
<p>SSR版が爆誕しても、SSG版のクライアントを勝手にマイグレーションできるわけではありません。</p>
<p>なぜなら独自ドメインを使っている場合はクライアント所有のDNSを変更してもらう必要があるからです。</p>
<p>DNSが厄介な理由はいくつもあります。</p>
<ul>
<li>比較的詳しい人でも滅多に触らないので思い出しながら作業したり案内したりせざるを得ません。</li>
<li>弊社としてDNS設定を代行できるわけではなく、必要な値を伝えることしかできません。顧客は内部でハンドリングできても詳しい担当者がいる確率が低く、外部に委託している場合は作業のリードタイムが長くなります。</li>
<li>操作方法は先方のDNSプロバイダによるので画面操作の案内ができません。</li>
<li>今時は変更はすぐ反映される印象を受けますが、「最大72時間かかる」と案内されることもよくあり、反映が遅いのか何かを間違えたのか判断しにくいことがしばしばあります。今回はDNSの新規設定ではなく、SSRへのマイグレーションなので設定変更であるという一捻りもありました。</li>
</ul>
<p>SSG版で案内したのは次の2つ：</p>
<ol>
<li>AWS Certificate Managerの証明書発行用のCNAMEレコード</li>
<li>ドメインをAWS CloudFrontに向けるCNAMEレコード</li>
</ol>
<p>ですが、今回は次の2つに変わります：</p>
<ol start="3">
<li>Google Certificate Managerの証明書発行用のCNAMEレコード</li>
<li>ドメインをGoogle CloudのLBに向けるAレコード</li>
</ol>
<p>ここで惜しくも予想できなかった落とし穴として、上記2と4は共存できないので、顧客のDNS管理画面の仕様によっては設定がしれっと失敗したり、エラーやガイダンスが表示されても気づけなかったりで、結果として4の設定に失敗するケースが続出しました。</p>
<p>弊社サポートサイトの記事やサクセスチームからの案内、移行フローの改善（DNS変更の自動検知）などで挽回して、<strong>SSR版の爆誕から8ヶ月かけて全てのクライアントのサイトの移行が無事に完了しました。</strong></p>
<h2>おわりに</h2>
<p><strong>なるべくSSGにしてサーバの負担を減らす世の中の流れとは逆方向に進めたのは少し意外性のある話かもしれません。</strong></p>
<p>ですが、現段階ではメリットが大きいと感じており、技術選定や方針策定を行う際はサービスの性質を見極める必要性を改めて実感させる案件でした。</p>
<h2>積極採用中！</h2>
<p>RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを採用中です！</p>
<p>もし興味があれば、ぜひお話ししましょう！</p>
<ul>
<li><a href="https://righttouch.co.jp/recruitment/engineer">エンジニア採用サイト</a></li>
<li><a href="https://righttouch.co.jp/jobs/engineer">エンジニア求人情報の詳細</a></li>
<li><a href="https://speakerdeck.com/righttouch/righttouch-company-deck-ver1-dot-0">Company Deck</a></li>
</ul>


Next.jsでマルチテナントのサイトホスティング -SSGからSSRへの移行の裏側-

<p>こんにちは、RightTouchでプロダクトエンジニアをしている赤木です。</p>
<p>5月23日・24日、ベルサール神田にて開催された TSKaigi 2025 に現地参加 &amp; 登壇してきました。</p>
<h2>TSKaigiとは</h2>
<p>TSKaigiは、TypeScriptに関する日本最大級のカンファレンスです。</p>
<p>TSKaigi 2025は、オフライン会場に加えオンラインでの同時配信もあり、2日間にわたるイベントでした。</p>
<p>会場には600人を超える人々が来場し、三つのセッションルームと数多くの企業ブースで大いに盛り上がっていました。</p>
<p><a href="https://2025.tskaigi.org/">https://2025.tskaigi.org/</a></p>
<h2>登壇への経緯</h2>
<p>私は今まで登壇経験がほとんどありません。</p>
<p>TSKaigiほどの規模になると「自分なんて」という気持ちがあり、登壇など考えたこともありませんでした。</p>
<p>しかし、社内の発信活動や「コンフォートゾーンを超え続ける」というRightTouchのカルチャー、社内メンバーの後押しもあって、TSKaigiでのLT登壇につながりました。</p>
<p>私が所属するRightTouchでは、基本的にフルTypeScriptで開発をしています。フロントエンドはReact、バックエンドはNode、インフラはCDK(TS)といった感じです。</p>
<p>そのため、TypeScriptに関する情報発信・共有や交流を目的として、TypeScriptの大規模なイベントであるTSKaigiにCFPを提出してみることになりました。</p>
<p>個人的に興味があったWasmやRustを絡めた内容での発表をしてみようと思い、Wasm x TypeScriptでCFPを提出し、見事採択されました。</p>
<h2>登壇当日</h2>
<p>私の登壇はDay 1の夕方、アセンドトラックで行いました。</p>
<div><div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 52.5%; padding-top: 120px; margin-bottom: 16px"><iframe title="Wasmを用いて他言語資産をTypeScriptで活用する | TSKaigi 2025" data-iframely-url="https://cdn.iframe.ly/api/iframe?app=1&url=https%3A%2F%2F2025.tskaigi.org%2Ftalks%2Fyutoak&key=878c5bef402f0b2911bf6d4ce6261abd" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>発表内容は、いろんな言語で書いたコードをWasmにコンパイルして、そのWasmからjcoというツールでTypeScript用のコードを生成し、TypeScriptからそのWasmを使う方法の解説と具体例の紹介です。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%; margin-bottom: 16px"><iframe title="TSKaigi2025_Wasmを用いて他言語資産をTypeScriptで活用する.pdf" src="https://speakerdeck.com/player/68e7a6c368c2406e8aef6813701049d0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>この登壇経験を通して、積極的に技術発信活動をしていきたいと強く感じました。自分の知識を整理し、アウトプットすることで自分自身の理解も深まることを実感しました。</p>
<p>学んだ技術を実際のプロダクト開発に活かしていくことで、より良いプロダクトを作っていきたいです。</p>
<h2>TSKaigiを満喫した2日間</h2>
<h3>企業ブースでの交流</h3>
<p>企業ブースエリアには20近くの企業がブースを出していて、各企業のブースでスタンプを集めて回るとくじが引けるというスタンプラリーもありました。</p>
<p>各企業のブースでは、TypeScriptに関するアンケートやクイズ、診断などがありました。</p>
<p>いろんな企業のエンジニアと話をしたり、各企業のプロダクトを知ることができました。</p>
<p><img src="https://ik.imagekit.io/righttouch/1d5a5d6d-3de3-4a2c-a477-1cf1658cddd5/250616-01.jpg" alt="TskaiGi2025のスポンサーラリースタンプカード。各マスにカラフルなシールやロゴが貼られており、すべて集めると抽選に参加可能"></p>
<h3>豪華な駅弁でエネルギー補給</h3>
<p>2日間とも豪華な駅弁とお茶が用意されていました。</p>
<p>お弁当の数に余裕があったのか、二つ目もどうぞ〜というアナウンスもあり、二日目は私も二ついただきました。おいしかったです。</p>
<p><img src="https://ik.imagekit.io/righttouch/288ea2e7-91ec-4cda-b92c-d2fea918ba2e/250616-02.jpg" alt="牛たん弁当と銀だら弁当"></p>
<h3>懇親会で広がるエンジニアの輪</h3>
<p>懇親会には数えきれないほど多くの参加者がいて、大いに盛り上がっていました。</p>
<blockquote class="twitter-tweet" data-dnt="true" align="center"><p lang="ja" dir="ltr">【<a href="https://twitter.com/hashtag/TSKaigi2025?src=hash&amp;ref_src=twsrc%5Etfw">#TSKaigi2025</a> 終了しました】<br><br>🎊無事すべてのコンテンツが終了いたしました🎊<br>様々な形で多くの方にご参加いただきました❗️<br>ありがとうございました‼️<a href="https://twitter.com/hashtag/TSKaigi?src=hash&amp;ref_src=twsrc%5Etfw">#TSKaigi</a> <a href="https://t.co/wEjCS7rhky">pic.twitter.com/wEjCS7rhky</a></p>&mdash; TSKaigi (@tskaigi) <a href="https://twitter.com/tskaigi/status/1926234689682939990?ref_src=twsrc%5Etfw">May 24, 2025</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>立食ビュッフェ形式で、たくさんの料理に加え、お寿司やケーキなども用意されており、どれもおいしかったです。</p>
<p>ドリンクもたくさん用意されていて、TSKaigi専用ビールも提供されていました。</p>
<p><img src="https://ik.imagekit.io/righttouch/91c065d6-b539-4805-9a80-232e640febd1/250616-03.jpg" alt="TskaiGi2025のロゴが入ったフルーツたっぷりの大型ケーキ。鮮やかなフルーツとホイップクリームが印象的"></p>
<p>他の登壇者や来場者の方々とも積極的に会話することができ、様々な技術的な話や経験談を聞くことができました。</p>
<p>普段なかなか会うことのできないエンジニアの方々と直接交流できる貴重な機会で、刺激的な時間を過ごすことができました。</p>
<h2>さいごに</h2>
<p>TSKaigi 2025は、私にとって忘れられない2日間となりました。この規模のカンファレンスでの登壇は初めての経験で、正直なところ緊張しましたが、それ以上に得るものが大きい貴重な体験でした。</p>
<p>登壇を通して、自分の知識を整理し、多くの方に伝える難しさと楽しさを実感しました。また、他の登壇者の方々の発表からも多くの学びを得ることができ、TypeScriptコミュニティの熱量と技術レベルの高さに改めて感動しました。</p>
<p>この経験を機に、今後はより積極的に技術発信活動に取り組んでいきたいと思います。学んだことをアウトプットし、コミュニティに貢献することで、自分自身の成長にもつなげていきたいです。</p>
<h2>積極採用中！</h2>
<p>RightTouchではコンフォートゾーンを超えてカスタマーサポート市場の改革に挑むプロダクトエンジニアを採用中です！</p>
<p>もし興味があれば、ぜひお話ししましょう！</p>
<ul>
<li><a href="https://righttouch.co.jp/recruitment/engineer">エンジニア採用サイト</a></li>
<li><a href="https://righttouch.co.jp/jobs/engineer">エンジニア求人情報の詳細</a></li>
<li><a href="https://speakerdeck.com/righttouch/righttouch-company-deck-ver1-dot-0">Company Deck</a></li>
</ul>


TSKaigi 2025 で登壇しました - Wasmを用いて他言語資産をTypeScriptで活用する -

<p>2025年5月15日、弊社オフィスにて「<a href="https://pesess.connpass.com/event/346505/">Product Engineer Session #2</a>」を開催しました。</p>
<p>Product Engineer Sessionは、単なる技術の共有にとどまらず、<strong>ユーザーに価値を届けるためのフルサイクルの活動</strong>の中で得られた知見や気づきを共有し合う場として設計されています。</p>
<p>今回は3名の登壇者による10分間のライトニングトークと、その後の懇親会を通じて、プロダクト開発に携わる様々な職種の方々が交流を深めました。</p>
<p>第1回に引き続き盛況で、当日は20人近くのプロダクト開発に関わる多様な職種の方々が集まってくれました！</p>
<p><img src="https://ik.imagekit.io/righttouch/2b970833-677b-4250-bb15-de4d865ff5b5/250609-01.jpg" alt="マイクを持つ登壇者がスライドを使ってイベントの案内をする様子。"></p>
<h2>当日レポート</h2>
<p>今回は10分の発表とその後に5分の質疑応答の時間を設ける形式で3人の方に発表していただきました。</p>
<p>質疑応答の時間を設けたのが良かったのか、参加者の方々から登壇者に対する質問がたくさん出ていろんな意見が交わされて非常に盛り上がりました！発表者も質問者も皆さんの熱量がすごかったです。</p>
<h3>LT1: 「事業KPIを基に価値の解像度を上げる」</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="事業KPIを基に価値の解像度を上げる" src="https://speakerdeck.com/player/04ad42b154454601845f3b34d8004acb" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p><strong>発表者</strong>: 株式会社ニーリー りんさん（<a href="https://x.com/TWBMT?t=rui1k2WwhrsALru5uWgesA&amp;s=09">@TWBMT</a>）</p>
<p>事業のKPIを軸にして、プロダクトが提供する価値の解像度を高めていく取り組みについてお話しいただきました！</p>
<p>開発チームもKPIを追うことで、日頃からKPIを意識するようになり、この機能は「開発するべき価値があるか」を定量・複眼で説明できるようになり、開発案件の価値を明確に捉えられるようになったとのこと。</p>
<p>りんさん自身は、事業KPIを意識することで自分自身の成長や仕事の楽しさにつながったと話してくれました！</p>
<h3>LT2: 「新規事業に特化した開発組織がPMFするまでに取り組んでいること」</h3>
<p><img src="https://ik.imagekit.io/righttouch/8f412be0-5406-4a44-8aa3-d4cb2787b0ec/250609-02.jpg" alt="スライドを指しながらエンジニア組織について説明する登壇者"></p>
<p><strong>発表者</strong>: 株式会社Relic ryoobさん（<a href="https://x.com/ryooob">@ryooob</a>）</p>
<p>新規事業の開発組織において、Product Market Fit（PMF）を達成するまでの道のりで実際に取り組んでいる施策や考え方について共有していただきました！</p>
<p>Relicさんでは「フィットジャーニー」に基づいて事業フェーズを定義して、それぞれの事業フェーズで目指すべき状態や、何を実現したら事業フェーズが上がってPMFに近づいていくのかなど、実際に使っている資料を見ながら紹介してくれました。</p>
<p>不確実性の高い新規事業開発における組織運営の工夫や、チーム作りのポイントなど、実践的な知見が多く、会場からもたくさんの質問が上がっていました！</p>
<h3>LT3: 「プロダクト感覚ってなんなんだろうね」</h3>
<p><img src="https://ik.imagekit.io/righttouch/0aa17d86-6d13-42b1-ae2b-44a127e777da/250609-03.jpg" alt="「プロダクト感覚ってなんなんだろうね」というスライドを背景に話す登壇者と、それを聞く参加者。"></p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="プロダクト感覚ってなんなんだろうね" src="https://speakerdeck.com/player/f3af3697193a4b1c8c77b25cad0015d5" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p><strong>発表者</strong>: 株式会社RightTouch yabuさん（<a href="https://x.com/yabuchin%5Fy">@yabuchin_y</a>）</p>
<p>RightTouchでは「プロダクト感覚」という言葉がよく使われるとのことでしたが、この正体を探る発表をしていただきました。</p>
<p>「プロダクト感覚」に含まれる要素を整理して、「課題から要件、要件から仕様を生み出すときのスキルの総称」がプロダクト感覚で、プロダクトエンジニアが価値あるプロダクトを作る上での判断基準になる非常に重要なものと話してくれました。</p>
<p>0→1の開発経験を積むことやいろんなプロダクトに触れることで「プロダクト感覚」は磨かれていき武器が増えていくということで、会場では共感の声が多かったです！</p>
<h2>懇親会での交流</h2>
<p>発表後の懇親会では、参加者同士が活発に交流を行いました。各社のプロダクト開発における課題や取り組み、エンジニアとしてのキャリアについてなど、様々なテーマで議論が交わされました。</p>
<p>前回同様、解散時間を過ぎてもしばらく盛り上がっていました！</p>
<h2><strong>参加した方の声(一部抜粋)</strong></h2>
<blockquote class="twitter-tweet" data-dnt="true" align="center"><p lang="ja" dir="ltr">大変おもしろいイベントでした！<br><br>登壇者の皆様、運営のRightTouchさん、<br>お話できた方、お話できてない参加者の皆さま<br><br>ありがとうございました！<br>第三回は予定調整してぜひ伺いたい！<br><br> <a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a></p>&mdash; みきてぃ / きたはら (mkitahara) | EM 中心にいろいろ (@mikity01985) <a href="https://twitter.com/mikity01985/status/1923013618834067672?ref_src=twsrc%5Etfw">May 15, 2025</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet" data-dnt="true" align="center"><p lang="ja" dir="ltr">プロダクトエンジニア、自分の作るものに圧倒的に納得感がありそうですごい、責任も伴うんだろうけど、そうあるべきだね<br> <a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a></p>&mdash; うにすけ (@uniuni__8282) <a href="https://twitter.com/uniuni__8282/status/1922980660983067018?ref_src=twsrc%5Etfw">May 15, 2025</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet" data-dnt="true" align="center"><p lang="ja" dir="ltr">PdM と PdE の差のひとつに時間を一次情報と実装のどちらに振るかのグラデーションがあると思ってるんだけど、カオス期だと求められるバランス感も違うかもだし、より振り切ったバランス感もいるのかも👀👀<a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a></p>&mdash; りん (@TWBMT) <a href="https://twitter.com/TWBMT/status/1922976735311667695?ref_src=twsrc%5Etfw">May 15, 2025</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<h2><strong>Product Engineer Session #3やります！</strong></h2>
<p><img src="https://ik.imagekit.io/righttouch/5ba657df-9811-47dc-bdd3-dd46940d0a26/5e69f9fed97eb36a90f2059a94574c13.png" alt="「PRODUCT ENGINEER SESSION #3 プロダクトエンジニア セッション」2025年6月26日（木）19時30分よりRightTouchオフィスで開催の告知画像"></p>
<p>Product Engineer Session #2は参加者から登壇者への質問が多く、登壇内容をより深く掘り下げたり、登壇者と参加者がインタラクティブに意見を交わしたり、より深い学びの場を作ることができたと感じています！</p>
<p>そしてそして、第3回の開催も決定！すでにLT枠、参加枠ともに多数申し込みいただいており今回も盛り上がること間違いなしです！</p>
<p>まだ枠に余裕があるので今のうちにぜひ申し込みください！</p>
<p><a href="https://pesess.connpass.com/event/355670/">https://pesess.connpass.com/event/355670/</a></p>
<h3>最後に</h3>
<p>RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを採用中です。</p>
<p>もし興味があれば、ぜひお話ししましょう！</p>
<ul>
<li><a href="https://righttouch.co.jp/recruitment/engineer">エンジニア採用サイト</a></li>
<li><a href="https://righttouch.co.jp/jobs/engineer">エンジニア求人情報の詳細</a></li>
<li><a href="https://speakerdeck.com/righttouch/righttouch-company-deck-ver1-dot-0">Company Deck</a></li>
</ul>


プロダクト開発に関する知見を共有「Product Engineer Session #2」を開催しました

<h2>はじめに</h2>
<p>ボイスボットはユーザーと音声で対話するAIシステムであり、カスタマーサポート分野を中心に幅広く活用されているソリューションのひとつです。特に24時間365日稼働する電話対応サービスでは、サービスの可用性と品質が非常に重要です。</p>
<p>RightTouchでも、<strong>RightVoicebot by KARTE（β版）</strong> を提供しており、顧客体験の向上に貢献する音声チャネルの自動化に取り組んでいます。</p>
<p><a href="https://righttouch.co.jp/news/UmmmSdRh">プレスリリースはこちら</a></p>
<p>しかし、音声インターフェースはWebなどの文字ベースのUIと比較して外部からの動作検証が難しく、特に電話においては以下のような音声固有の課題があります。</p>
<ol>
<li>入力の不確実性: ネットワーク品質が音声品質に影響を及ぼすため、常に同様の入力をボイスボットに与えることが困難です。</li>
<li>音声認識の不確実性: 音声認識エンジンは、分析された音声スペクトグラムから特徴量を抽出しそれを確率モデルを用いて判定を行うため出力が不安定になります。この問題は、ボイスボット本体とその音声を検証するテストランナーの両方に存在します。</li>
</ol>
<p>さらにボイスボットは、内部的には「正常に動作している」ように見えても、実際の通話においては音声が再生されない、認識がうまくいかないといった問題が発生していて検知できないケースがあります。</p>
<p>このように、ユーザーとの電話を通じた音声体験はブラックボックスに埋もれやすく、内部メトリクスだけではその品質を保証しきれません。</p>
<p>そこで私たちは実際の通話経路を通じてボイスボットの応答を確認する外形監視を構築し、ユーザー視点での品質の担保を行なっています。</p>
<p>本記事では、その外形監視システムの概要と、運用における工夫や課題への対応について紹介します。</p>
<h2>システム概要</h2>
<p>私たちが実装したボイスボット外形監視システムは定期的にプログラムから電話発信を行い、その応答を自動的に評価しています。</p>
<h3>発信</h3>
<p>実際の発信は、テレフォニーAPIを用いて行います。</p>
<p>テレフォニーAPIとは、プログラムから電話の発信・着信などの電話機能を制御できるようにするクラウド上のインターフェースのことで、代表的なものにTwilioが存在します。</p>
<p><img src="https://ik.imagekit.io/righttouch/c5d545ba-5e65-4297-b60d-622e8b237eb2/voicebot-monitoring-01.png" alt="外形監視用テストランナー、テレフォニーAPI、ボイスボットサーバーが矢印で接続されたシステム構成図。外形監視用テストランナーからテレフォニーAPIへ発信リクエストが送信され、音声パケットが双方向でやり取りされる。テレフォニーAPIはボイスボットサーバーとも同様に接続され、発信と音声パケットが矢印で表現されている"></p>
<p>※図では省略していますが、実際にはボイスボットサーバーもテレフォニーAPIを用いて電話を受けています。</p>
<h3>入力の不確実性に対するアプローチ</h3>
<p>通話の品質やラグなどにより、テストプログラムが送出した音声が正しくボイスボットに伝わらないケースがしばしばあります。</p>
<p>この「入力の不確実性」に対応するため、テストは複数回リトライする設計にしています。具体的には、初回の失敗後に数回再試行し、連続して失敗した場合のみ「テスト失敗」とみなします。</p>
<h3>応答の評価</h3>
<p>応答評価は以下のステップで行われます：</p>
<ol>
<li>音声認識：ボイスボットからの音声を音声認識エンジンにかけて文字起こし</li>
<li>編集距離の計算：認識結果と期待する結果との編集距離を求める</li>
<li>類似度の算出：編集距離を正規化し、一定の類似度以上なら成功と判定</li>
<li>リトライ評価：失敗した場合もリトライを実施し、連続失敗時に最終失敗と判断</li>
</ol>
<p>ここで使用している編集距離の算出方法は以下のようなコードになります。</p>
<pre><code class="language-tsx">// getEditDistanceは2つの文字列間の編集距離（挿入・削除・置換の最小操作回数）を計算する関数
const editDistance = getEditDistance(recognized, expected);

// 編集距離を最大文字列長で割ることで正規化し、1に近いほど期待通りの応答だったと判断できる
const similarity = 1 - editDistance / Math.max(recognized.length, expected.length);
</code></pre>
<p>この手法を用いることで、たとえ数文字の誤認識があっても過剰なな失敗判定を避けられます。</p>
<h3>テストケース</h3>
<p>テストケースとしては、以下のような主要なシナリオをカバーしています。</p>
<ul>
<li>ユーザーの発話をボイスボットがオウム返しする</li>
<li>ダイヤルパッド入力への応答を確認する</li>
<li>入力が無いまま一定時間経過する（タイムアウト）</li>
</ul>
<h3>外形監視失敗時のオペレーション</h3>
<p>テスト結果は Datadog に集約され、ダッシュボード上で可視化されます。</p>
<p>サービスの性質、障害の影響範囲は大きく、即時の検知が必要なので各チャネルに通知を行なっています。Slackをはじめとして、即時で気づくことが難しいためPagerDutyを用いて電話、SMSでも通知される形になっています。</p>
<p><img src="https://ik.imagekit.io/righttouch/d19942d8-6029-4996-bab0-1694e7b143ae/voicebot-monitoring-02.png" alt="外形監視用テストランナーがDatadogに失敗通知を送信し、DatadogがSlackとPagerDutyに通知を送信するシステム構成図。PagerDutyは電話やSMSを通じてエンジニアに通知を行う。各コンポーネントは矢印で接続され、システム内の通知の流れが示されている"></p>
<h2>おわりに</h2>
<p>RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを採用中です。<br>
もし興味があれば、ぜひお話ししましょう！</p>
<ul>
<li><a href="https://righttouch.co.jp/recruitment/engineer">エンジニア採用サイト</a></li>
<li><a href="https://righttouch.co.jp/jobs/engineer">エンジニア求人情報の詳細</a></li>
<li><a href="https://speakerdeck.com/righttouch/righttouch-company-deck-ver1-dot-0">Company Deck</a></li>
</ul>


24時間安定稼働のために：ボイスボット外形監視システムの構築と運用

<h2>はじめに</h2>
<p>こんにちは。<s>アニメでチ。を見てつい原作まで買ってしまった</s>RightTouchでCustomerEngineerをしている川下です。</p>
<p>早いもので、<a href="https://blog.righttouch.co.jp/slack-app-with-craft-functions">入社直後にブログ記事を書いて</a>から半年以上が経過しました。<br>
半年というと、漬け始めた梅酒がもう飲み頃になっているくらいの期間です。梅酒を漬けたことはないのでわかりませんが。</p>
<p>今回、テックブログを運営しているメンバーから「エンジニアがコンタクトセンター見学（以後、「センター見学」）をして感じたことについて書いてほしい」という依頼があり、久々に筆を取りました。</p>
<p>前回は試用期間中の執筆だったため下手なことはかけませんでしたが、無事試用期間を乗り越え自由を手にしたこの身は、自由な文体でこのブログという大空を飛び回りたいと疼いております。</p>
<p>ということで、旅を始めましょう。</p>
<h2>そもそもなぜセンター見学をしてるのか？</h2>
<p>飛び立つ前に、まずはビジネスマンらしく前提と目的の整理からです。</p>
<p>弊社では月~2回程度の頻度で、クライアントに依頼しコンタクトセンター見学をさせていただいています。</p>
<p>クライアントの電話応対やチャット応対のログを見せてもらったり、実際にオペレーターの方が応対をされているデスクやPCの画面を見せてもらったりと、内容はまちまちですが毎回<strong>顧客対応されている現場を見る</strong>ということをさせてもらっています。<br>
※もちろん、情報管理には十二分に気をつけた上で実施しています</p>
<p>１回の見学でお邪魔する人数は数人程度ですが、このセンター見学には職種関係なく参加しています。</p>
<p><strong>セールスもサクセスもエンジニアもアクセラレーター（管理部門の弊社での名称）も、全員等しく参加します。</strong> それも１回で終わりではなく、何度も異なるクライアントのセンター見学に行くのが通例です。</p>
<p>目的はいくつかありますが、やはり質と量に優れた一次情報を取るためという点は大きいです。<br>
端的に言うと、<strong>センター見学をするとクライアント（とマーケット）の解像度が爆上がりするから行く</strong>のです。</p>
<p>事業を進める上で、マーケットの解像度は極めて重要です。</p>
<p>プロダクトを作るにしても、「このプロダクトは誰が、どんな場面で、どんな思いで使うのか？」を具体的にイメージできなければ、使い道のないプロダクトができてしまいます。</p>
<p>プロダクトを届けるにしても、「クライアントのどの業務を代替/改善するのか？」を具体的にイメージできなければ、プロダクトを運用に乗せることはできません。</p>
<p>常に使う人がいる以上、その人が普段何をしていて、どんなことで困っているのかをとにかく知ることが、価値を提供するためには欠かせないのです。</p>
<p>そしてその「クライアントをとにかく知る」ために一番良いのは、現場を直接見に行って一次情報を得ることです。</p>
<p>現場の方にお時間を割いていただきリアルな声を聞くことで理解を深め、そして<strong>深めた理解をプロダクトを通して価値に変換しクライアントに還元する</strong>ために弊社はセンター見学を続けています。</p>
<p>助走が長くなりましたが、ようやく飛び立つ時が来ました。</p>
<h2>プロローグ</h2>
<p>某月某日、三田。<br>
ラーメン二郎 三田本店の吐き出す濃厚な香りが微かに届く小さなテナントビルの５階で、歓喜の声が響いた。</p>
<p>「え！？ようやく自分の番ですか！！？」</p>
<p>入社から数ヶ月、想いを募らせてきたセンター見学に、漸く参加できる時が来たのだ。</p>
<p>思えば、永かった。入社当初抱いていた「今時はノンボイス対応（チャット対応）もあるしコールセンターよりコンタクトセンターといった方が正しいのかな？」という些細な疑問が、時の流れの中で忘れ去られていくほどに—</p>
<p>今回の訪問先は某生命保険会社様のオフィス。</p>
<p>あの大手保険会社の現場を見せていただけるのか。筆者の心は昂った。</p>
<p>参加が決まってからの筆者の動きは、速かった。何の備えも無しに、その日を迎える訳にはいかない。貴重な時間を割いていただく以上、こちらも入念な準備は欠かせない。徹底的なリサーチをせねばなるまい。</p>
<p>センター見学の準備で抑えるべきは、クライアントの基本戦略・現在の進捗率・弊社プロダクトの導入/活用状況・抱えている課題など数多くある。<br>
また、失礼が無いようセンターの一般的な事情も把握しておく必要があるだろう。</p>
<p>社内にある過去の見学ログを読み漁りセンターの一般的な事情を把握し、さらに担当サクセスによるクライアントの現状共有により、必要な知識をインストールしていく。</p>
<p>これらの工程を経て、出来上がった質問リストは40個。どうしよう、こんなに質問する時間あるかな？知らないこと、知りたいことだらけだ・・・</p>
<h2>当日</h2>
<h3>センター概要についてのご説明</h3>
<p>モチベーションは最高潮に、いざ先方オフィスへ。時刻は14時を回った頃。<br>
エントランスでの簡単なご挨拶の後、早速会議室へ通していただく。<br>
名刺交換の後、30分程度でまずは先方コンタクトセンターの概要についてご教示いただく。</p>
<h4>【内容】</h4>
<p>センター全体として取り組んでいるテーマ、拠点（東京/地方エリア）ごとの差異、インバウンド/アウトバウンドそれぞれのコールフローや体制等についてのご説明。<br>
その後、Q&amp;A。</p>
<h4>【感じたこと】</h4>
<p>部署を跨いだ対応も少なくないため応対の後に引き継ぎ書を作成されているが、新人の方はこの作成に手間取ることがあったり、Voicebotの対応でも文字起こしミスがあるため人が起票していたりと、所々に「痒いところ」があることを実感。</p>
<p>フルスキルな人材が育つまでは１年以上はかかると言うお話もあり、改めてコンタクトセンターの業務の幅の広さと深さを痛感しました。</p>
<h3>応対ログの確認</h3>
<p>概要をお話しいただいたあとは、同じく30分ほどを使って（個人が特定できないよう十分なマスキングを施した）応対ログをもとに、どういった応対をされているかをご教示いただく。</p>
<h4>【内容】</h4>
<p>それぞれ異なるお問い合わせ内容での入電への対応。<br>
どちらも用件把握の後本人確認、手続き内容のご説明。<br>
その後、Q&amp;A。</p>
<h4>【感じたこと】</h4>
<p>お客様の問い合わせ内容や音声のトーンに合わせて話し方を変えているベテランオペレーターの手腕は流石と言う他ありませんでした。</p>
<p>今回紹介いただいた応対はどちらもVoicebotで代替可能な内容には感じましたが、音声トーンなどの「お客様に寄り添った応対」という点において人とボットとの圧倒的な差を感じました。</p>
<p>プロダクト開発の際はつい分かりやすい機能に目を向けてしまいますが、特に弊社がターゲットとしているカスタマーサポート市場においてはこういった「お客様の快さ」を重視する必要があると再認識できました。</p>
<h3>モニター、利用ツールを見せていただく</h3>
<p>その後場所を移し、実際に応対をしている執務エリアへ。<br>
入電音とオペレーターの方の話し声が微かに聞こえる中で、実際に使っているPCを元に操作方法をご説明していただく。</p>
<h4>【内容】</h4>
<p>普段使っているツールのご説明、入電時の操作の流れや応対中のツールの使い方などのレクチャー。<br>
その後、Q&amp;A。</p>
<h4>【感じたこと】</h4>
<p>自社構築のツールを使われているとのことでしたが、お客様との会話中に応対用画面とCRMと社内ナレッジを行ったり来たりと、業務難度が高いことが感じられました。<br>
逆に言えば、センターとしての教育レベルが相当に高いことが伺えました。</p>
<h3>ナレッジ管理についてご説明</h3>
<p>最後に、再度会議室に戻りナレッジ管理についてご教示いただく。</p>
<h4>【内容】</h4>
<p>業務項目ごとの対応スクリプトの概要や管理・更新方法、オペレーターの教育についてなどのインプット。<br>
その後、Q&amp;A。</p>
<h4>【感じたこと】</h4>
<p>「これが応対に必要な社内ナレッジの全てです」とお渡しいただいたマニュアルは、誇張抜きで広辞苑より大きかったです。そしてSVレベルになるとこの内容をほぼ全て記憶しているとのこと。凄すぎて若干の恐怖を感じました。</p>
<p>社内一般用・オペレーター用で同じ内容の記事を別々で管理していたりと、マニュアルの維持管理でもかなりの工数がかかっていることが伺えるため、これをITの力で楽にして本来充てるべきところにリソースを投下できるような貢献をしたいと思いました。</p>
<h2>エピローグ</h2>
<p>文体が変わるレベルで、驚きと学びの連続でした。<br>
確かに、デジタル化が進んでいない部分があったり、AIの導入でもっと楽にできる余地は大いにあるように感じます。</p>
<p>その反面、<strong>ただツールを統合したりSaaSを導入するだけでは解決できない問題がある</strong>ということも同時に実感しました。</p>
<p>例えば、社内ナレッジを統合すれば二重管理の手間が減るため大きな工数削減ができるかもしれません。<br>
しかし、そうするとオペレーターがナレッジを読み解くのに時間がかかるようになり、それはAHTの増加につながり、ひいては待ち呼の増加などの顧客体験の悪化につながります。</p>
<p>我々SaaS提供企業は、ただ表面的な課題に対して解決策としてのプロダクトを提示するのではなく、<strong>クライアントのその先のエンドユーザーにまで寄り添っていかなければ、本当の意味でサポートの負の体験をなくすことはできない</strong>のだと痛感しました。</p>
<p>今回の見学では実際の現場を知ることで、弊社プロダクトがどう活きているか、どう活かせるかを深く知るとても良い機会となりました。<br>
帰り道ではサクセスメンバーと「このプロダクトは入れてもらえたら絶対体験が良くなるから提案してほしい」「しかしそうするとこういったリスクが想定できるからどう乗り越えるべきか」など熱い話を繰り広げるまでに至りました。</p>
<h2>後日談。</h2>
<p>と言うか、今回のオチ─</p>
<p>年末から自分はカスタマーエンジニアとして、Voicebotのプロダクト立ち上げに関わっています。<br>
<a href="https://righttouch.co.jp/news/UmmmSdRh">Voicebotは新プロダクト</a>なので、方針の話などにも同席していますが、<strong>この見学の経験が確実に活きています</strong>。</p>
<p>例えば、応対の基本的な流れやVoicebotを組み込んだ際のクライアントの業務フロー検討・Voicebotで発生するACW※など。実際の応対の流れを知っていることで、そこから想像力を膨らませて運用に落とし込んだ際の体験もイメージすることができるようになりました。<br>
<span class="caption">※After Call Work（平均後処理時間）。顧客との通話後にオペレーターが行う作業にかかる時間の平均のこと</span></p>
<p>たった１回の見学で充分な解像度が確保できたとは考えていませんが、それでもこの経験に助けられることは多くあります。</p>
<p>これからも、ただ「クライアントのコスト削減に貢献できるVoicebot」ではなく、「クライアントにとってもエンドユーザーにとっても最高の体験を提供できるVoicebot」を作り、届けていきたいと思っています。</p>
<p>是非、この記事を読まれているあなたも、もしまだであればクライアントの現場に足を運んでみてください。豊富な一次情報を持っているのとそうでないのとでは、極めて大きな差があることをその身を以て体験できるでしょう。</p>
<h3>オマケ（これで本当に終わりです）</h3>
<p>クライアントのオフィスのある街はスイーツで有名だと聞き、早めに現地入りしてランチとティータイムを楽しんでからセンター見学に赴きました。<br>
この梯子のお陰で、最高のモチベーションと集中力によりセンター見学を120%のパフォーマンスで迎えることができました。</p>
<p>弊社の次のオフィス移転先はこんなオシャレなお店がある街だといいなぁ。</p>
<p>【内容】</p>
<p>ランチ：手作りボルシチとピロシキ（どっちも人生初）。どちらもアツアツ作りたて。最高。</p>
<p><img src="https://ik.imagekit.io/righttouch/3be258a2-7fcc-431c-8c34-c2d995d1b8a8/se-01.jpg" alt="手作りボルシチとピロシキ"></p>
<p>デザート：おしゃれなカフェで紅茶と一緒にショートケーキを。何だこのショートケーキは。おしゃれすぎんだろ・・・！</p>
<p><img src="https://ik.imagekit.io/righttouch/e5a7d6f5-11f9-4076-9d00-2fad7db84e71/se-02.jpg" alt="ショートケーキ"></p>
<p>【感じたこと】</p>
<p>とっても美味しかったです。流石スイーツとロシア料理の街。<br>
けどボルシチは熱々すぎて舌が火傷しました。痛かったです。</p>
<p>最後まで読んでくださりありがとうございました。</p>
<p>皆様も、どうかボルシチを食べる時は火傷にお気をつけて。</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>


セ。〜センター見学の学びについて〜

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


Blog

Recent Article