RightTouch Blog

Ryo Harada

Yuto Akagi

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

<p>2025年6月26日、<a href="https://pesess.connpass.com/event/355670/">Product Engineer Sessionの第3回</a>が開催されました！</p>
<p>今回も4名の素晴らしい発表者の皆様にお越しいただき、プロダクトエンジニアリングに関する貴重な知見や経験を共有していただきました。</p>
<h2>イベント概要</h2>
<p><img src="https://ik.imagekit.io/righttouch/c79bb92e-066c-4bce-93f8-1c5bbb432066/250804-01.jpg" alt="会場の様子"></p>
<p>Product Engineer Sessionは、<strong>技術的なテーマにとどまらず、ユーザーに価値を届けるためのフルサイクルの活動の中で得られた知見や気づきを共有し合う場です。</strong></p>
<p>#1, #2に引き続き#3も盛況で、当日は20人近くのプロダクト開発に関わる、エンジニア、CTO、EMなど多様な職種の方々が集まってくれました！</p>
<p>また、裏メインコンテンツとして懇親会も毎回大変盛り上がります。狭いオフィスならではのアットホームな雰囲気を気に入ってくれる参加者の声を多く聞くことができました。</p>
<h2>当日レポート</h2>
<p>今回は10分の発表とその後に5分の質疑応答の時間を設ける形式で4人の方に発表していただきました。</p>
<p>質疑の時間では、参加者の皆さんからたくさんの質問もいただきました。</p>
<h3>LT1: 「とりあえず作るがすべてを加速させる」</h3>
<p><img src="https://ik.imagekit.io/righttouch/73b773f2-2b46-45c8-81ee-4405e0155bd8/250804-02.jpg" alt="「とりあえず作るがすべてを加速させる」の発表の様子"></p>
<p>発表者: <a href="https://x.com/ta1m1kam">mikamitaigaさん</a> (LayerX )</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/bf2a79325bb24199b121484fbe581387" 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>
<p>mikamitaigaさんからは、プロトタイピングとスピード重視の開発アプローチについてお話しいただきました。</p>
<ul>
<li><strong>動くものこそ正義。完璧を求めすぎるよりも、まず作って検証することの価値</strong></li>
<li>「とりあえず作る」ことで見えてくる課題や改善点</li>
<li>実践のためのTIPS</li>
</ul>
<p>mikamitaiga氏の発表は、動くものを作りながらプロダクトの最終的な完成度を上げていく方針について、プロダクトエンジニアならではの視点でその意義や実践方法を紹介してくれました。</p>
<p>不確実性の高いプロダクト開発において、本質的な考え方を実践に即して整理されているのが印象的で、特にスタートアップや新規プロダクト開発に携わる方々にとって非常に参考になるのではないでしょうか。</p>
<h3>LT2:「プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと」</h3>
<p>発表者: <a href="https://x.com/kazu_real20">kazuさん</a> (株式会社ニーリー)</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/f7786776039345979859d817353bb1fe" 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>
<p>プロダクト開発リードのKazuさんからは、単にプロダクト志向が強いエンジニアというだけではなく、真にプロダクトして重要な点を一歩踏み込んで整理されていました。</p>
<ul>
<li>プロダクト志向で価値を出すために</li>
<li>顧客が本当に求めていることや、そうなっている背景の理解</li>
<li>プロダクト志向を意識したことで得られたこと</li>
</ul>
<p>顧客のことをよく理解し、顧客が本当に求めていることや、そうなっている背景を深く理解することでプロダクトがよりよくできることや、自分自身のオーナーシップを高めていくことにもつながることがよく理解できました。</p>
<p>また、冒頭の評価面談で率直なフィードバックを受けたエピソードはインパクトがありました。FBをきっかけに受け止めて、取り組み方を改善された点が非常に共感しました。</p>
<p>懇親会でもお話ししましたが、 <strong>「FBがない方が怖くないですか？」</strong> というお話は、非常に身につまされる部分がありました。</p>
<h3>LT3: 「プロダクト志向って何なんだろうね」</h3>
<p><img src="https://ik.imagekit.io/righttouch/895d0bae-0264-4111-b67f-df4f54fb6d12/250804-03.jpg" alt="「プロダクト志向って何なんだろうね」の発表の様子"></p>
<p>発表者: <a href="https://x.com/nakaakist">齋藤成之さん</a> (株式会社RightTouch)</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/1fdf2023bf4946609e643c71e7faebcb" 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>
<p>RightTouchでテックリードを務める齋藤氏からは、プロダクト開発におけるプロダクト志向を再定義し、プロダクト思考を高めるための方針を共有してくれました。</p>
<ul>
<li>「価値ファースト」と「オーナーシップ」</li>
<li>技術力とプロダクト思考の関係性の整理</li>
<li>プロダクト志向の高め方</li>
</ul>
<p>齋藤氏の発表では、まず、プロダクト思考を再定義し、価値ファーストとオーナーシップの2点に着目した整理を行いました。また、プロダクトエンジニアを考える上で気になる、「技術力」との関係性についても、4象限グラフでわかりやすく整理されていました。</p>
<p>最後に、<strong>プロダクト思考を高めていくために、作る、知る、考えるのステップで解説</strong> し、具体的な実体験を聞くことができました。</p>
<h3>LT4: 「Our Journey to Becoming a Product Engineering Organization」</h3>
<p><img src="https://ik.imagekit.io/righttouch/bba35732-8182-4074-bf6a-c1d3d96ec25e/250804-04.jpg" alt="「Our Journey to Becoming a Product Engineering Organization」の発表の様子"></p>
<p>発表者: <a href="https://x.com/hirot_san">とりいさん</a>（Grooves)</p>
<p>GroovesでEMを務めるとりいさんからは、同社がプロダクトエンジニア構想について、これまでの道のりをご講演いただきました。</p>
<ul>
<li>目指すべき組織像にフォーカス</li>
<li>提供価値の質を高めていくために</li>
<li>プロダクトエンジニアリングにチームで取り組む</li>
</ul>
<p>とりいさんの発表では、目指すべき組織像を最初に定義してから、特に顧客提供価値の向上に向けて、現状の分析や、そこに向かうためのTry/Errorを理解することができました。</p>
<p>中でも、<strong>プロダクトエンジニアリングは「個人やエンジニア」にとどまらずチーム全体として高めていくものでは？</strong> という仮説は新たな視点を感じました。PdMやデザイナーも巻き込んだ取り組みについて、今後の実践経験もぜひまたお伺いしたいと思いました。</p>
<h2>懇親会の様子</h2>
<p><img src="https://ik.imagekit.io/righttouch/2101d3e2-d47f-43d1-9182-d4d3e574fa8c/250804-05.jpg" alt="懇親会の様子"></p>
<p>裏メインコンテンツの懇親会です。小規模会場ならではのアットホームな雰囲気の中、ビールサーバーで注いだビールを片手に、今回もかなり賑わいました！</p>
<p>発表者だけでなく参加者の皆さんも、経験豊富かつプロダクトエンジニアリングに思いを持った方に多く参加していただいており、どなたと話しても有意義で熱い情報交換をすることができました。</p>
<p>より多くの方に繋がりを作ってほしいという観点から、今回は立食形式にして、なるべくグループが流動的になるように工夫をしてみました。</p>
<p>より実りのあるコミュニティにしていくため、今後も改善を重ねていきたいと考えています。</p>
<h2>おわりに</h2>
<p>Product Engineer Session #3も、前回に引き続き非常に充実した内容となりました。プロダクトエンジニアリングという分野がますます注目を集める中で、このようなコミュニティイベントの価値はさらに高まっていくと感じています。</p>
<p>そして、<a href="https://pesess.connpass.com/event/360685/">Product Engineer Session #4</a> の開催は8/21(木)に決定いたしました！</p>
<p><a href="https://pesess.connpass.com/event/360685/"><img src="https://ik.imagekit.io/righttouch/864955f7-4534-40f2-bbbb-b4f05eec9618/pes4.png" alt=""></a></p>
<p>本記事公開 (8/7) 時点では定員が埋まっておりますが、当日キャンセルなどもありますので、興味がある方は諦めず参加申し込みをお願いいたします！</p>
<p>改めまして、発表者の皆様、参加者の皆様、本当にありがとうございました。</p>
<p>次回のProduct Engineer Session #4も、より多くの学びと気づきを共有できるイベントにしていきたいと思います。</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>


プロダクトエンジニアのコミュニティ「Product Engineer Session #3」開催レポート

<h1><strong>はじめに</strong></h1>
<p>こんにちは。RightTouch のAIエンジニアの原田です。</p>
<p>今回は、弊社の取り組みについてお話しする機会をいただき、ファインディ株式会社様が主催する「<a href="https://ai-engineering-summit.findy-tools.io/">AI Engineering Summit 2025</a>」に、弊社の CTO である 籔 と共に登壇させていただきました。</p>
<p>弊社は組織の規模としては決して大きくはなく、限られたリソースの中で価値となるロジックを着実に作っていくにはどうすればいいか、日々試行錯誤を繰り返しています。</p>
<p>特にプロダクトのロジック開発を担当するいわゆるAIエンジニアやデータサイエンティストとしての役割を持つメンバーは私を含めて2人しかいませんが、日々色々な物事と向き合ってロジックの開発をしています。</p>
<p>今回の登壇では、こうした環境下で私たちが大切にしているロジックの開発思想を、同じくプロダクト開発に従事されているみなさんに共有したいという思いからお伝えしました。</p>
<p>本 note では、この登壇の模様を振り返りながら、当日の様子や発表内容、そしてイベント全体を通じて感じたことを自身の視点からレポートしたいと思います。</p>
<h1><strong>AI Engineering Summit とは</strong></h1>
<h3><strong>AI/LLM プロダクト開発の実践者たちの集う場所</strong></h3>
<p>「AI Engineering Summit」は、その名の通り AI を研究対象としてだけでなくプロダクトに実装し価値を届けるための「エンジニアリング」に焦点を当てた、国内でも屈指の技術カンファレンスです。</p>
<p>今年のテーマは「LLM・AI エージェントの活用と開発の最前線」でした。</p>
<p>Siri の共同創業者であるアダム・チェイヤー氏による基調講演をはじめ、名だたる企業の CTO や第一線のエンジニアたちが集結し、まさに技術の最先端がぶつかり合う場でした。</p>
<p>本イベントはオンラインで開催されましたが、事前エントリーは 2300 人を超えていたと伺っており、当日は 2700 人を超える参加者がいたと聞いています。AI という技術が単なるバズワードから、いかにしてビジネス価値に繋げるかという実践的な「How」のフェーズへと業界全体の関心が移行していることを肌で感じました。</p>
<p>登壇したセッションは 13:00~13:40 分の枠で、その枠では 3 つの Room に分かれたオンライン配信だったので、弊社の登壇枠もおそらく 300 ~ 500 名以上の方にご覧いただけていたのではと思います。</p>
<h1><strong>当日の登壇の雰囲気</strong></h1>
<h3><strong>配信の雰囲気</strong></h3>
<p><img src="https://ik.imagekit.io/righttouch/0577a737-209a-46e8-b62b-1f020d2811ab/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-07-2417.36.56.png" alt="スクリーンショット2025-07-2417.36.56.png"></p>
<p>当日は Vimeo を使ったオンライン配信でした。オフィスでは、チームのメンバーが会議室に集まって「鑑賞会」を開いてくれていました。</p>
<p>社内 Slack にはリアルタイムで応援の絵文字やコメントが飛び交っており、私自身は自宅から参加しましたが皆さんのサポートを強く感じることができました。</p>
<p>当日のスライドやアーカイブは下記をご覧ください。<br>
<a href="https://findy-tools.io/events/338cda12e34be8dde254">https://findy-tools.io/events/338cda12e34be8dde254</a></p>
<h1><strong>登壇内容</strong></h1>
<p>ここからは、当日お話しした内容の核心部分をより深く掘り下げていきたいと思います。</p>
<p>セッションタイトルは「生成 AI はカスタマーサポートをどう変えるか？ - 顧客価値に繋げる非構造データとの向き合い方-」というタイトルで、技術先行ではなくあくまで顧客価値を起点とした AI ロジック開発の思想と実践についてお話ししました。</p>
<p><img src="https://ik.imagekit.io/righttouch/2d50201a-b2fb-44bc-bccf-861234e5c761/ai_engineering_summit_yabu_pdf1.png" alt="ai_engineering_summit_yabu_pdf1.png"></p>
<h3><strong>カスタマーサポートの課題と非構造化データ</strong></h3>
<p>まず、弊社が事業を展開するカスタマーサポート領域の特性について説明しました。この領域では、顧客との応対履歴、オペレーターが参照する業務ドキュメント（マニュアルや FAQ）、さらには通話音声といった多種多様な「非構造化データ」が日々大量に生まれています。</p>
<p>そして、顧客が抱える本質的な課題は単一のデータソースに存在するわけではありません。例えば、「ある製品の特定機能に関する問い合わせが増えている」という事実は応対履歴データだけを見ていてもわかりません。その問い合わせに対して、オペレーターがどのマニュアルのどの部分を参照して苦労しているのかという業務ドキュメントの利用状況や、電話応対の時の音声データを組み合わせることで、初めて課題の全体像が浮かび上がってきます。</p>
<p><img src="https://ik.imagekit.io/righttouch/581de60e-7a73-4bed-bae3-34b2585fa60d/ai_engineering_summit_yabu_pdf2.png" alt="ai_engineering_summit_yabu_pdf2.png"></p>
<p>このように、複数の非構造化データが複雑に絡み合った中からいかにして顧客課題を正確に捉えプロダクトの価値へと昇華させるかを考える必要があり、これはロジックを考える上での重要な前提です。</p>
<h3><strong>弊社の 2 つの事例に見るロジック開発の思想</strong></h3>
<p>あらゆるロジックを考える上でLLMの存在は当然無視できません。また、非構造化データの扱いはLLM の登場により劇的に容易になりました。</p>
<p>しかし、弊社では「LLM に丸投げすれば全てが解決する」という安易な考え方を採用しません。その思想を体現する 2 つの具体的な開発事例を紹介しました。</p>
<h3><strong>事例 1：業務ドキュメントの検索</strong></h3>
<p><img src="https://ik.imagekit.io/righttouch/e79cba31-753b-417d-a57c-c699b4ce1298/ai_engineering_summit_yabu_pdf3.png" alt="ai_engineering_summit_yabu_pdf3.png"></p>
<p>顧客の業務によっては、オペレーターが参照するドキュメント検索において 1 秒以下の応答速度と高い検索精度が求められます。このような要件下で、一般的に用いられる RAG（Retrieval-Augmented Generation）のような LLM が検索結果を解釈・生成するアーキテクチャはレイテンシの観点から最適とは言えません。</p>
<p>そこで、RAG や Reranker といった技術に頼らずベクトル検索そのものの性能を極限まで高めるアプローチを選択しました。ここで最も重要かつ困難なのが、巨大なドキュメントを検索クエリと適切にマッチするように分割する「チャンキング」の戦略を立てることであり、既存のライブラリをただ適用すれば済む話ではありません。</p>
<p>クエリと検索対象の関係性を深く洞察しどう分割すれば意味的にもっともヒットしやすくなるかを、実際のドキュメントデータを一つ一つ目で見て以下を自分の頭で考え抜く必要があります。</p>
<p>この着実な戦略設計こそが、技術選定以上にロジックの価値を決定づける核心部分であると考えています。</p>
<h3><strong>事例 2：堅牢なドキュメント構造化</strong></h3>
<p>もう一つの事例は、顧客が作成した多種多様なフォーマットの業務ドキュメント（Office ファイルなど）を、プロダクトで活用可能な構造化データに変換する課題です。</p>
<p><img src="https://ik.imagekit.io/righttouch/0baef8b7-e087-4fa8-89a5-bc8467f84a23/ai_engineering_summit_yabu_pdf4.png" alt="ai_engineering_summit_yabu_pdf4.png"></p>
<p>当初、マルチモーダルな LLM の能力に期待しその活用を試みました。確かにその性能には目を見張るものがありましたが、複雑なレイアウトのドキュメントに対して安定した結果を得ることや、なぜ特定の抽出に失敗したのかをデバッグすることの難しさに直面しました。プロダクトとして提供するには、この「ブラックボックス性」は致命的です。</p>
<p>そこでロジックの方針を転換しました。まず、基本的な要素（テキストブロック、表、画像など）の抽出には LLM を使わず、従来の画像処理やレイアウト解析といった、確実でデバッグ可能なデータ解析技術を組み合わせたロジックを構築しました。その上で、確実に抽出できた要素間の意味的・位置的な関係性を解釈しグルーピングして構造化する部分に限定して LLM を活用したのです。</p>
<p>この 2 つの事例は、偶然選ばれたものではありません。前者は特定の業務要件（速度）を満たすために LLM 的なアプローチを意図的に回避した例であり、後者は別の業務要件（堅牢性・デバッグ容易性）を満たすために一度は試した LLM から戦略的に後退した例です。</p>
<p>これらは表裏一体であり、「最新技術に飛びつくのではなく、制御可能性を最優先に考え課題解決のために最適な手段を主体的に選択する」という私たちのロジック開発に対する姿勢を示しています。</p>
<p><img src="https://ik.imagekit.io/righttouch/9de83711-6b3a-49bf-9b08-594c70d174da/ai_engineering_summit_yabu_pdf5.png" alt="ai_engineering_summit_yabu_pdf5.png"></p>
<h3><strong>顧客価値の絶対的優先</strong></h3>
<p>では、なぜこういった一見大変に見えるアプローチを積極的に実行するのかですが、その理由はロジック開発における優先順位にあります。</p>
<p>ロジック開発においては、理解すべき要素を「① 顧客の業務」「② 課題・データ」「③ 技術」の 3 つに分類し、① を最優先事項としています。</p>
<p>顧客がプロダクトにお金を払うのは、その裏側でどんなに高度な AI 技術が使われているかに対してではありません。自分たちの業務がどれだけ効率化・高度化されるかという「価値」に対してです。したがって、ロジック開発は常に「この機能は顧客の業務をどう変えるのか？」という問いからスタートします。</p>
<p><img src="https://ik.imagekit.io/righttouch/4f1171ea-6964-44a1-8099-2a2a3e99567f/ai_engineering_summit_yabu_pdf6.png" alt="ai_engineering_summit_yabu_pdf6.png"></p>
<p>この視点に立つと、業務における具体的なアプローチと目標も以下のように自ずと明確になります。</p>
<ul>
<li>顧客へのデモでは、技術の凄さではなく価値が確実に伝わること。</li>
<li>そこから得られるフィードバックを最速でロジックに反映し、業務解像度を上げ続けること。</li>
<li>データを直接見て、データにないエッジケースまで想像を巡らせること。</li>
<li>そして、「万能な技術」という幻想を捨て、実用性を第一に考えたロジックを構築すること。</li>
</ul>
<p><img src="https://ik.imagekit.io/righttouch/01f6e817-c797-458e-b732-d077b6d7f5bc/ai_engineering_summit_yabu_pdf7.png" alt="ai_engineering_summit_yabu_pdf7.png"></p>
<p>そして、このアプローチこそが顧客課題をプロダクトの本質的な価値へと確実に繋げる唯一の道だと信じています。</p>
<h3><strong>LLM との規律ある向き合い方</strong></h3>
<p>最後に、こうした思想に基づいた上での LLM との向き合い方についてフレームワークを提示しました。</p>
<p>まず、LLM を採用するか否かを常に意識的に判断します。LLM が真価を発揮するのは、従来のルールベースや統計的モデリングでは扱いきれなかった複雑な「構造化」の課題です。一方で、生成結果に数学的な根拠が求められる課題や品質が厳格に問われる領域では、依然として古典的なアプローチが重要です。</p>
<p><img src="https://ik.imagekit.io/righttouch/dc1b5afd-4c85-482b-aaa6-e55695ee4a65/Cursor_%E3%81%A8_ai_engineering_summit_yabu_pdf8.png" alt="Cursor_と_ai_engineering_summit_yabu_pdf8.png"></p>
<p>そして、LLM を使うと決めた場合でも「課題分解アプローチ」を徹底します。登壇の中ではロジックの複雑度を 3 つのレベルで定義しました。</p>
<p><img src="https://ik.imagekit.io/righttouch/f35e7590-bb7f-4784-a992-d64557fb6b31/ai_engineering_summit_yabu_pdf9.png" alt="ai_engineering_summit_yabu_pdf9.png"></p>
<ul>
<li>Level 1: 単一ツール（例：要約、翻訳）</li>
<li>Level 2: ワークフロー（例：抽出 → 分類 → 要約といった一連の処理）</li>
<li>Level 3: エージェント（状況に応じてツールやワークフローを自律的に選択・実行）</li>
</ul>
<p>昨今話題の自律型エージェント（Level 3）も、決して魔法ではありません。</p>
<p>それは Level 1、Level 2 で一つ一つ精度を担保して作り上げた信頼性の高い「ツール」を LLM が適切に選択・オーケストレーションすることで初めて成立するものです。</p>
<p>複雑な課題を LLM に丸投げしうまくいかなかった時に「技術の限界」と結論づけるのは顧客に対する不誠実です。課題を粘り強く分解し確実な部品を一つ一つ丁寧に作り上げそれらを組み上げていく、この地道なプロセスこそが本質的な価値を生み出すというメッセージで発表を締め括りました。</p>
<p><img src="https://ik.imagekit.io/righttouch/70b1e69c-2938-44cf-bb81-a957616409e6/ai_engineering_summit_yabu_pdf10.png" alt="ai_engineering_summit_yabu_pdf10.png"></p>
<h1><strong>質疑応答で感じた世の中のエンジニアの直面している課題感</strong></h1>
<p>発表の後、質疑応答の時間で想定よりも多くの質問をいただきました。</p>
<p>寄せられた質問は 15 件近くに及びましたが、質疑応答に応える中で世の中のエンジニアがロジック開発で直面している課題感についてリアルな声を聞くことができました。</p>
<p><img src="https://ik.imagekit.io/righttouch/374dbbaa-47ab-450c-b421-3b99bc7662e7/image12.png" alt="image12.png"></p>
<p>以下は実際に質疑応答で実際に来た質問とそれに対する私たちの回答です。</p>
<h3><strong>「ハルシネーションリスクをどう回避しているか」</strong></h3>
<p>モデルのチューニングだけでなく、システム設計で解決する。出力の「出口」（FAQ や有人窓口への誘導など）を制御し、誤りの影響範囲を限定する。</p>
<p>LLM の思考過程での誤りは、ワークフローの中で個別に解決する。(籔)</p>
<h3><strong>「このマインドをどう社内に浸透させたか」</strong></h3>
<p>目に見える成果を通じて伝播する。ロジック開発者がこの思想を実務で体現し、その成果物を通じて組織に影響を与えていく。（原田）</p>
<h3><strong>「LLM からルールベースに戻した事例は何か」</strong></h3>
<p>まさに今回のドキュメント構造化の事例。複雑な実データに対するデバッグ容易性、信頼性、制御性を確保するため、純粋なマルチモーダル LLM からハイブリッドアプローチに移行した。特定の技術に固執せず、課題解決という目的に対して常に最適なツールを選択する。（原田）</p>
<h3><strong>「ロジックのアーキテクチャ設計はどうしているか」</strong></h3>
<p>「基盤化」を意識する。プロダクト戦略に基づき、プロダクト横断で汎用的に使いまわせるロジック部品を構築する。スケール、持続可能性、再利用性を見越して設計する。堅実なソフトウェア工学の規律こそが、高度な AI システムの土台となる。（籔）</p>
<p>これらの問いは、まさに私たちが日々向き合い、今回のプレゼンテーションで問題提起しようとしたテーマそのものでした。抽象的な技術論ではなく、実装の泥臭さや組織論にまで踏み込んだ質問の数々は、視聴者の多くが私たちと同じように AI をプロダクトに組み込む現場で格闘しているエンジニアであることを示唆していました。</p>
<p>自分たちの思想が決して独りよがりなものではなかったのだと深い手応えを感じました。</p>
<h1><strong>終わりに</strong></h1>
<p>今回の登壇は、 RightTouch で私たちが日々実践している顧客価値の実現を最優先する AI ロジック開発のスタンスと、その重要性を言語化し社外に発信する絶好の機会となりました。そして、質疑応答での対話はこのアプローチが間違っていなかったという確信を与えてくれました。</p>
<p>技術の流行り廃りに惑わされることなく、目の前の顧客、目の前のデータ、そして解くべき課題に真摯に向き合うという、「当たり前」を愚直にやり続けることの価値を改めて認識することができました。</p>
<p>これからも、この信念を持ち続けながら非構造化データという価値の源から顧客にとって本当に価値のあるロジックを掘り出し続けていきたいと思います。</p>
<p>最後になりましたが、このような貴重な機会をくださった ファインディ株式会社様、そして発表に最後まで耳を傾けてくださった全ての視聴者の皆様に、心より感謝申し上げます。</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>


「生成 AI はカスタマーサポートをどう変えるか？ - 顧客価値に繋げる非構造データとの向き合い方-」AI Engineering Summit 2025 登壇レポート

<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」を開催しました

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


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

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

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

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


Rollup + Svelte + Typescriptの環境構成

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


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

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

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


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

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

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

Blog

Recent Article

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

Rollup + Svelte + Typescriptの環境構成

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

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

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

Archives

Writers