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>「あらゆる人を負の体験から解放し、可能性を引き出す」をミッションに、カスタマーサポート（CS）領域に特化したエンタープライズ企業向けSaaS事業を展開する株式会社RightTouchは、プレイドからスピンオフして始まったBtoB SaaSスタートアップです。</p>
<p>昨年、RightTouchでは、1つ目のプロダクトであるWebサポートプラットフォーム「<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>（以後、RightSupport）」をリリースした際の中心機能であったサポートウィジェットに蓄積していた技術的負債を解消するために、サポートアクションの開発プロジェクトを推進しました。</p>
<p>エンジニアたちが主体的に動き、現場主導で行われた開発の裏側について、取締役CTOの籔悠一（yabu）と、プロダクトエンジニアの追木 智明（ikki）の2人に話を聞きました。</p>
<h2>顧客の要望に応えるなかで蓄積していったプロダクトの負債</h2>
<p><strong>──最初にプロダクトをリリースした後のRightSupportが抱えていた課題について教えてください。</strong></p>
<p>yabu：<br>
RightSupportは、エンドユーザーによる自己解決を促進するために、困りごとが生じたタイミングでFAQを表示できれば、という考えのもと、ポップアップ形式で情報を表示する「サポートウィジェット」という機能を中心にリリースしました。<br>
この機能は、企業がノーコードで配信を設定でき、エンドユーザーがサポートウィジェットをクリックすると、お困りごとの自己解決ができるというものです。リリースからしばらくの期間はサポートウィジェットだけで問題なかったのですが、少しずつ課題が生まれていきました。</p>
<p><img src="https://ik.imagekit.io/righttouch/9c2d2b44-1898-4a75-a52a-21a3072b1115/suppurt_widget.png" alt="suppurt_widget.png"><span class="caption"><center>移行前のサポートウィジェットの画面</center></span></p>
<p>ikki：<br>
お客様からの要望が段々と多様になっていったんですよね。たとえば、サポートウィジェットに表示する文言をカスタマイズしたい、Webサイト内のボタンをクリックするとサポートウィジェットが表示されるようにしたい、表示する内容を分岐させたい、Webサイト内にFAQを埋め込みたい、など。<strong>お客様の要望にはできるだけ応えられるようにと、サポートウィジェットに仕様を追加して開発を進めていたのですが、徐々に限界が見えてきていました</strong>。</p>
<p>yabu：<br>
サポートウィジェットをWebサイトに埋め込むとなったときは、「はたして、それはウィジェットなのか？」という疑問が生まれて。その他の要望と合わせて、実現するためにサポートウィジェットを改良していきましたが、次第に技術的負債が溜まっていきました。</p>
<p><img src="https://ik.imagekit.io/righttouch/da1b4c2f-6d07-4294-b5a8-8e203f4d8db7/IMG_6375.jpg" alt="IMG_6375.jpg"><span class="caption"><center>取締役CTOの籔悠一（yabu）</center></span></p>
<p>ikki：<br>
技術的負債以外にも課題がありましたね。当時、エンドユーザー向けに配信するシステムのフレームワークは、コンパクトさを重視してプレイドでも使用していたものを踏襲していました。一方、管理画面では別のフレームワークを活用していたので、そこの同期が難しい状態でした。たとえば、なにか新しい機能を実装した際に、お客様の画面には反映されているけれど、プレビューの画面には反映されない、といったことが起きていたんです。</p>
<p>yabu：<br>
技術的負債や仕様の負債なども溜まっていって、このままではいけないと社内で話になることも増えました。サポートウィジェットを軸に体験をつくるのではなく、体験をつくるために必要なコンポーネントを用意し、組み合わせられるようにしたほうがいいのでは、といった議論を重ねて。サポートウィジェットのまま改善していくことは止めて、工数をかけてでも<strong>理想のWebサポートを実現するための開発に着手しました。</strong></p>
<p><img src="https://ik.imagekit.io/righttouch/56e4df07-7672-4a62-b261-a2c957773bf0/support_action.png" alt="support_action.png"><span class="caption"><center>新たに開発したサポートアクションの画面</center></span></p>
<h2>チームで進めたサポートアクションの設計と開発</h2>
<p><strong>──理想とするWebサポートの実現に向けて、まずどんなことから取り組んだんですか？</strong></p>
<p>yabu：<br>
サポートウィジェットと比較して、<strong>より汎用的で将来的な拡張性を持った機能を開発しようと思い、チームで仕様を描きました</strong>。ただ、最初は理想を描きがちなので、キャンパス上でコンポーネントとコンポーネントをつないでアクションを構築していくものをつくろう、とGUIがっつりな仕様を描いていました。そうしたら、社内のエンジニアから「もっとシンプルでもいいのでは？」と海外の事例と合わせて提案されてしまって（笑）</p>
<p>ikki：<br>
<strong>yabuさんがビジョナリーに理想を語りつつ、周りのメンバーが現実的な解を見つけていく</strong>のが、RightTouchのエンジニアリングの特徴でもありますね。自分はそのなかで「どうしたらバランスがとれるだろうか？」と考えながら、仕様の設計に参加していました。</p>
<p>タイプが異なるエンジニアの恊働についてはこちらの記事もどうぞ。</p>
<ul>
<li><a href="https://blog.righttouch.co.jp/interview1-rightsupport">コンセプトもデータも重視。タイプの異なるエンジニアたちが連携して事業成長に貢献するRightTouchの開発現場</a></li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/8df2347e-ea12-4b0c-b0ad-a8c7f8953286/IMG_6360.jpg" alt="IMG_6360.jpg"><span class="caption"><center>プロダクトエンジニアの追木 智明（ikki）</center></span></p>
<p>yabu：<br>
メンバーとの議論を経て、改めてタスクをひとつずつ設定していけば完了するような、<strong>お客様にとって使いやすいUIになるように</strong>仕様を検討。将来性も考慮して、コンポーネントを組み合わせて、さまざまなことを実現可能にしていけるモデルを設計しました。</p>
<p><strong>──仕様設計の次は何に着手を？</strong></p>
<p>yabu：<br>
まずは、プロトタイプをつくりましたね。サポートアクションの開発をするまではプロダクトの中での開発が中心でしたが、<strong>大型の開発をするために「サンドボックス」をつくって、実験をしていきました</strong>。実験と議論を繰り返しながら、モデルの型を固めていきました。<br>
モデルの形を定義する力を高めるために、TypeScriptの型をクイズ形式で勉強するサービスをチームみんなでやろう、という話になったんです。そしたら次の週には、nariさんが「自分がわからない姿を見せるのが嫌だから」ってひとりで全部解いてしまった、なんてこともありました（笑）結局、Devメンバーが集まるランチミーティングのときに、わいわいみんなで挑戦しました。</p>
<p><strong>──なんだか楽しそうな雰囲気ですね（笑）</strong></p>
<p>yabu：<br>
大変なプロジェクトではありますが、シリアスな雰囲気にはならなかったですね。実験を重ねたおかげで、仕様も決まり、柔軟なモデルもできたので、あとはチーム全員でサポートアクションを実装していきました。実際に形になった機能を触ったときは、純粋に楽しかったですね。<br>
ある程度、実装が進んだ後は、社内でお披露目をして、しっかりとドッグフーディングを実施。おかげで、<strong>開発チームだけでは気付けない問題点も見つけることができて、修正を進めて完成度を高めて</strong>いきました。</p>
<h2>顧客の協力のもと、サポートアクションへの移行を進める</h2>
<p><strong>──サポートアクションの開発が完了した後、移行をどのように進めていったのでしょうか？</strong></p>
<p>yabu：<br>
開発がおおよそ終わったのが2023年の年末、2024年1月にサポートアクションをリリース。このタイミングで、RightTouchでテックリードとして複数のプロダクトを横断的に見ているnariさんが異動のためチームから抜けて、サポートアクションへの移行をikkiさんがリードすることになったんですよね。</p>
<p>ikki：<br>
そうなんです。「やります！」って言ったはいいものの、内心は何からやればいいんだろうと不安でしたね（笑）まずは現状把握から進めて、設定されていたサポートウィジェットが全部でどれだけあるのか、どんなお客様がどのようにサポートウィジェットを使用中なのか、などを確認していきました。<br>
移行には、カスタマーサクセスの協力が必須だったので、4名のカスタマーサクセスメンバーと毎週定例会議を実施して、それぞれのお客様の移行状況を確認するようにしました。お客様は「そもそもサポートアクションとはなにか？」ということがわからないので、頭出しをしながら移行を進めていきました。</p>
<p>yabu：<br>
サポートアクションの開発を進めている際に、どうやって移行をしていくかについても練らないとな、とは考えていたんですよね。たとえば、サポートウィジェットをサポートアクションに変換するロジックを組んで、自動で切り替えるシステムをつくれないか、など。開発し始めたときには考えていたものの、開発自体にリソースがかかってなかなか移行については追いついていない状況だったんですよね。</p>
<p><img src="https://ik.imagekit.io/righttouch/ee947e4e-5591-4568-b74b-3ebe3252141e/IMG_6352.jpg" alt="IMG_6352.jpg"></p>
<p>ikki：結局、システマチックに一括で移行するのは、各お客様の状況に合わせて対応するのが難しかったため、見送りにしましたね。当時は、お客様の数もまだ60〜70社ほどだったので、人力での移行を進めることにしました。<br>
当時のサポートウィジェットの数は、全体で合計1500ほど。お客様ごとに偏りがあって、積極的に活用しているお客様であれば100種以上のサポートウィジェットを設定してました。このサポートウィジェットは将来的にコードをなくすことが目標なので、ひとつでもサポートウィジェットを残すわけにはいきません。すべてのサポートウィジェットを移行する必要がありました。</p>
<p><strong>──お客様への働きかけはどう進めていったのでしょうか？</strong></p>
<p>ikki：<br>
「これまでのサポートウィジェットよりも、サポートアクションのほうが圧倒的にいろんなことをできるんです！」、ということを丁寧に伝えていきました。たとえば、説明会を開催して、お客様のやりたいことはサポートアクションでさらに実現できると伝えました。<br>
「できることが広がるのなら」と、喜んで移行に対応してくれたお客様もいらっしゃいましたね。<strong>協力してくださるお客様が多くて、これはカスタマーサクセスのメンバーが日頃から関係を構築できていたから</strong>こそ実現できたことだと思います。<br>
移行されて減少したサポートウィジェットの個数を可視化して、サポートアクションのほうが個数が大きくなったタイミングでSlackに共有して「超えました！」と投稿したり、移行状況をグラフ化したりして、お祭り感を出すようにしました。</p>
<p><img src="https://ik.imagekit.io/righttouch/ab6453d7-a2b1-4a01-b7b8-7e9aac439e35/image6.png" alt="image6.png"><span class="caption"><center>移行状況のグラフを共有した際のリアクション</center></span></p>
<p>yabu：<br>
新しいメンバーにサポートアクションへの移行を担当してもらって、新機能のオンボーディングを兼ねるなど、メンバーの巻き込みはいろいろ工夫しながらしましたね。</p>
<p>ikki：<br>
ほかには、サポートアクションの機能をつかって、サポートウィジェットの機能がクローズするというお知らせを出すなどの活用もしました。思い浮かぶことを試しながら、お祭り的に進めていきました。<br>
移行は2024年2月からスタートし、ほとんどの移行は4月には完了。一部、動作確認が必要なお客様がいたため、そこから2ヶ月ほどかかって、6月ごろに移行完了。この移行は、RightTouchが経験した移行プロジェクトとしては相当に大きいものだったので、やりきれたことで自信につながりました。</p>
<h2>「全員プロダクト担当」だから素早く実現できた新機能への移行</h2>
<p><strong>──サポートアクションに移行してみて、感触はどうですか？</strong></p>
<p>yabu：<br>
サポートウィジェットのときに複雑になりすぎて実装できなかった機能を、サポートアクションに切り替えることで数多く追加できるようになりました。以前は、既存機能との兼ね合いを考えながら新機能を開発しなければなりませんでしたが、サポートアクションではコンポーネント間の結合度が低いため、新機能の開発に集中しやすくなりました。これからもさまざまなコンポーネントを追加していく予定なので、<strong>さらにサポートアクションを進化させられるのは楽しみ</strong>ですね。<br>
開発以外のことも含めると、今回のサポートアクションの開発と移行は、会社にとって大きな変更です。これを実行できたのは、自分以外の経営層も今回の件に対して「本質的に価値のある移行であり、コストをかける必要がある」と理解し、意思決定したことが良かった。Devチームに対する信頼もあり、<strong>「全員プロダクト担当」というMind（RightTouchのValue）のもと、部署をまたいでワンチームで動けた</strong>ことで、スピード感をもって話を進めることができました。</p>
<p><img src="https://ik.imagekit.io/righttouch/3c36c681-19ec-41b3-9438-9b7628890f42/IMG_6400.jpg" alt="IMG_6400.jpg"></p>
<p>ikki：<br>
新旧の機能が混在していると新機能の価値がすべてのお客様に届かず薄れてしまうので、この移行はなんとしてもやり切らなければならない、という強い意志があったことも、推進の後押しになったと思います。技術的負債や仕様の負債を、いつ解消するのかというタイミングは常に難しい問題です。今回はあえて工数を投じてでも<strong>思い切って作り直す決断をしたことで、RightSupportで実現できることの幅が大きく広がった</strong>と感じています。</p>
<p>共に「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションの実現に挑むプロダクトエンジニアを募集しています！</p>
<p>関心のある方は、下記の募集をぜひご覧ください<br>
<a href="https://righttouch.co.jp/jobs/engineer">https://righttouch.co.jp/jobs/engineer</a></p>
<p>RightTouchの採用情報はこちらから<br>
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a></p>


「全員プロダクト担当」で挑んだ技術的負債の解消。新機能への移行プロジェクトの裏側

<p>2025/3/4に弊社オフィスにて、「<a href="https://pesess.connpass.com/event/344220/">Product Engineer Session #1</a>」を開催いたしました。</p>
<p>Product Engineer Sessionは「技術力だけでなくユーザー価値を最も大切にし、プロダクト視点で日々の開発に向き合っているプロダクトエンジニアの交流の場」としてRightTouchのエンジアメンバーが立ち上げたコミュニティです。</p>
<p>第1回ながら、当日はエンジニアやPdMを中心にいろんな形でプロダクトに関わるたくさんの方にご参加いただきました！</p>
<p><img src="https://ik.imagekit.io/righttouch/1416f66f-cdea-4aea-a4ee-73c77b480493/250304-01.jpg" alt="イベント開始時の会場の様子"></p>
<h2>当日レポート</h2>
<p>当日は5人の方がプロダクト開発に関する知見をLTしてくれました！<br>
RightTouchからも2名のエンジニアが登壇しました！</p>
<h3>小規模組織のプロダクトエンジニアとしてアンラーニングしたこと（株式会社RightTouch Hedrallさん）</h3>
<ul>
<li>小規模組織におけるプロダクトエンジニアとして、従来のエンジニアが仕様以降を担当するだけでなく、要件、戦略にも入り込んでいく重要性について語っていました。</li>
<li>スライド: <a href="https://speakerdeck.com/righttouch/xiao-gui-mo-zu-zhi-nopurodakutoenziniatosite-anraningusitakoto">https://speakerdeck.com/righttouch/xiao-gui-mo-zu-zhi-nopurodakutoenziniatosite-anraningusitakoto</a></li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/0ca8d4ea-bc3f-4c7c-85c6-be7b5023bc61/250304-02.jpg" alt="小規模組織のプロダクトエンジニアとしてアンラーニングしたこと"></p>
<h3>プロダクトの価値を考えたらメイン機能を1から実装し直すことになった話（株式会社RightTouch toikiさん）</h3>
<ul>
<li>プロダクトを作っていると必ず遭遇する「作り直したい」というタイミングにおいて、ドラスティックな意思決定をした上で利用推進をプロダクトエンジニアがやることの重要性についてにお話しされていました。</li>
<li>スライド: 非公開</li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/bf15f0c8-61c3-4314-b102-ab9360c032e2/250304-03.jpg" alt="プロダクトの価値を考えたらメイン機能を1から実装し直すことになった話"></p>
<h3>AIスタートアップのCEOが求めるProduct Engineerの役割（nmatsumoto4さん）</h3>
<ul>
<li>AI時代のプロダクト開発において、どこにベットするのか？不確実性とどう戦うのか？など難しい意思決定が必要な状況の中でエンジニアに求められる立ち回りについてお話しされていました。</li>
<li>スライド: <a href="https://speakerdeck.com/nmatsumoto4/aisutatoatupunoceogaqiu-meruproduct-engineernoyi-ge">https://speakerdeck.com/nmatsumoto4/aisutatoatupunoceogaqiu-meruproduct-engineernoyi-ge</a></li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/8411271c-a4b5-49c6-b1aa-1396b60b1d2e/250304-04.jpg" alt="AIスタートアップのCEOが求めるProduct Engineerの役割"></p>
<h3>0→1フェーズで社内ツールを作ったら思ってた以上に使われるツールになった話（nusukeさん）</h3>
<ul>
<li>ふとしたきっかけで0→1フェーズにおいて高速で検証を回すための社内ツールの開発したことや、社内ツールであっても通常のプロダクト同様ユーザーヒアリングなどを行い、いかにユーザーに近い位置で開発するかの大切さについて共有してくださいました。</li>
<li>スライド: 非公開</li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/3b7feb6d-9657-4ec2-9dde-cf0ffc594c88/250304-05.jpg" alt="0→1フェーズで社内ツールを作ったら思ってた以上に使われるツールになった話"></p>
<h3>エンジニアがPdM領域に踏み込む挑戦——10%ルールの実践と学び（MasayaOkudaさん）</h3>
<ul>
<li>組織においてボトルネックになりがちなPdMを少しでも補うために取り組んでいた10%ルールの取り組みと、実際にやってみたことによるリアルな失敗談や気づきを話してくださいました。</li>
<li>スライド: <a href="https://speakerdeck.com/masayaokuda/enziniagapdmling-yu-nita-miip-mutiao-zhan-10-percent-rurunoshi-jian-toxue-bi-0980cc86-e6d0-440d-b8e0-162ee8775106">https://speakerdeck.com/masayaokuda/enziniagapdmling-yu-nita-miip-mutiao-zhan-10-percent-rurunoshi-jian-toxue-bi-0980cc86-e6d0-440d-b8e0-162ee8775106</a></li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/52c1ef5c-dc44-4bcd-9745-a1f9262986ef/250304-06.jpg" alt="エンジニアがPdM領域に踏み込む挑戦——10%ルールの実践と学び"></p>
<h2>懇親会</h2>
<p>懇親会までたくさんの方が残ってくださり、お互いに普段どんな形でプロダクト開発に携わっているかなどを語り合っていました。</p>
<p>実は当日は雪が降っており、公共交通機関がどうなるかもわからない中、解散時間が過ぎてもしばらく話しているくらいには盛り上がっていました！</p>
<p><img src="https://ik.imagekit.io/righttouch/ad5094ca-52dd-4d47-bbd9-5b95698c8c75/250304-07.jpg" alt="懇親会の様子"></p>
<h2>参加した方の声(一部抜粋)</h2>
<div style="margin-inline: auto; max-width: 550px;">
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">今日めちゃくちゃイベント楽しかったし勉強になりました！RightTouchの皆様、企画いただきありがとうございました✨🙌<br><br> <a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a></p>&mdash; okkun (@masaya_okuda) <a href="https://twitter.com/masaya_okuda/status/1896916984643858824?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">色々なプロダクト開発の話が聞けて楽しかった！<br>定期的に他社の事例を聞くのは大事だなと改めて感じました。<br><br>LTする機会もいただきありがとうございました🙇<a href="https://twitter.com/hashtag/PdESession?src=hash&amp;ref_src=twsrc%5Etfw">#PdESession</a></p>&mdash; nusuke (@nusuke_y) <a href="https://twitter.com/nusuke_y/status/1896945276038099261?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">各社、プロダクトの発展という軸でエンジニアリングができていて素晴らしい✨️<a href="https://twitter.com/hashtag/pdesession?src=hash&amp;ref_src=twsrc%5Etfw">#pdesession</a></p>&mdash; takuya CTO #GoogleCloud Next LV (@takuya_stmn) <a href="https://twitter.com/takuya_stmn/status/1896891200340472077?ref_src=twsrc%5Etfw">March 4, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<h2>Product Engineer Session #2やります！</h2>
<p><img src="https://ik.imagekit.io/righttouch/323945de-5d13-4e5e-841e-34cfd6ff38de/%E3%82%B5%E3%83%A0%E3%83%8D%E3%82%A4%E3%83%AB(2).png" alt="pes_2.png"></p>
<p>とても素敵な会となった第1回ですが、なんと第2回も開催することになりました 🎉</p>
<p>すでにLTの抽選枠は定員オーバーしており、今回も盛り上がること間違いなしです！</p>
<p>オフライン参加枠はまだまだ枠がありますので、ご興味のある方はぜひ<a href="https://pesess.connpass.com/event/346505/">こちら</a>からご参加ください！</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>


「Product Engineer Session #1」を開催しました

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


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

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

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


Blog

Recent Article