RightTouch Blog

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

RightTouchでは、より大きなインパクトを生み出すための環境整備の施策のひとつとして、全社で「フルフレックスタイム制（コアタイムなし）」を導入しています。 
事業・プロダクトに対してより大きなインパクトが生み出せるように、7:00〜22:00のうち働く時間をフレキシブルに決めることができる制度ですが、実際にRightTouchメンバーはどのように利用しているのでしょうか？「ホントのところ」をエンジニア・デザイナーメンバー11人に聞いてみました！ブログを通して、RightTouchで働く際のイメージが深まれば嬉しいです。
<hr>
まず、フレックスタイム制についてですが、これは全員一致でメリットを感じているようでした！
<img src="https://ik.imagekit.io/righttouch/873d4c5b-889c-46bf-ac87-3990d3f4fed5/Righttouch%E7%94%BB%E5%83%8F(2).png" alt="Righttouch画像(2).png"> 
 
次に、メンバーの普段のワークタイムを聞きました。 
全てのメンバーが普段は9:00〜10:00の間に仕事を始めていますが、終業時間は人によって16:00〜21:00以降までばらつきがありました。その日の予定やパフォーマンスによって、柔軟にワークタイムを決められるのはインパクトの総量にも良い影響がありそうです。
<img src="https://ik.imagekit.io/righttouch/e5bfb8aa-3cbd-40bc-b12e-dede0b388868/Righttouch%E7%94%BB%E5%83%8F.png" alt="Righttouch画像.png"> 
続いて、どんな時に働く時間がフレキシブルにできるメリットを感じるか、聞いてみました。 
<img src="https://ik.imagekit.io/righttouch/b7cd8d49-32c1-40ee-a683-af48778cad9d/Righttouch%E7%94%BB%E5%83%8F(1).png" alt="Righttouch画像(1).png"> 
特にメリットを感じることとして「パフォーマンスが高くなりやすい時間を選べる」「日中しか出来ない私用の対応ができる」を、8割を超えるメンバーが挙げていました。
時間の融通が効くことのメリットが感じられた具体的なシーンやエピソードを、メンバーが答えてくれました！ 
※カッコ内は回答してくれたメンバー名
パフォーマンス向上
<blockquote>
・出社するときに、朝の混雑する時間帯を避けることができる（miso、ikki） 
・夜遅い時間など自分にとって仕事に集中しやすいタイミングで働くことができる（nari） 
・最近パーソナルトレーニングを始めたんですが、12-15時とかの昼の何処かに一度仕事を抜けて通ったりしています。リフレッシュにもなってその後の集中力も高まるので割と良いです。（ikki） 
・朝が弱いので、始業時間に追われる感覚がなくなった（saaa-san） 
・開発に集中したい時、連絡が少ない朝や夜の時間帯に作業できて捗ります (kanke)
</blockquote>
プライベート予定対応
<blockquote>
・通院対応や、コロナ禍ではワクチン接種などに気兼ねなく行けた（Aaron、koyo、takken） 
・昼過ぎまで出社してミーティングに参加して、その後荷物受け取りのために帰宅、そこからまた仕事をするみたいな動きもしやすいです（ikki） 
・役所の手続きなど、平日昼間にしか対応していないものに苦労しなくなった（takken、giinyo） 
・子供の送り迎えや習い事対応、運動会や授業参観など、数時間だけ抜けて参加できるのが良いです（yabu、kanke、Aaron） 
・週末に北海道へライブ遠征に行った時に、月曜に飛行機で帰ってくる調整ができてめちゃくちゃ助かった（saaa-san）
</blockquote>
 
コメントからも、モチベーションやパフォーマンスが高められるよう、各自が自身のニーズに合わせてフルフレックス制を活用していることがうかがえます。 
とはいえ、フレキシブルな働き方や時間の使い方は今がベストな姿なのでしょうか？最後に、改善点や難しさを感じる点を聞いてみました。
改善点・難しい点
<blockquote>
・全員オフィスにいる時と同じように気軽に話しかけられる雰囲気を作るためにいろんなツールの検討を重ねていて、まだ解決できていると言えない 
・朝弱いので、自分で強い意志を持たないとずるずる勤務時間が遅くなっていく 
・フレキシブルでありがたい反面、仕事が楽しくて働こうと思えばいつまでも働けてしまうことです。家族との時間がおざなりになってしまって子供にも寂しい思いをさせてしまったこともありました…。今はタイムスケジュールを切って、きっちり切り替えるように心がけています！
</blockquote>
<hr>
チームがどんどん拡大する中で、個人のフレキシビリティを保ちながらチーム全体の成果や生産性を高めていくには、コメントがあった点の改善だけでなく、継続的な取り組みが必要になってきます。RightTouchでは、こうした制度や働き方・カルチャーづくりにも、メンバーが主体的に意見を持って議論に参加し、未来のあるべきRightTouchの姿を決めていくカルチャーがあります。 
 
RightTouchの取り組みや雰囲気に興味を持ってくださった方がいたら、ぜひカジュアルからお話できたら嬉しいです。
<a href="https://righttouch.co.jp/recruitment">https://righttouch.co.jp/recruitment</a>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>

ホントのところ、どうなってる？〜RightTouchのフルフレックスタイム制度〜

※この記事は<a href="https://note.com/nakaakist/n/n146afd3fbff9">RightTouch公式note</a>に掲載した内容を転載しています。
<h1>はじめに</h1>
株式会社RightTouchテックリードの齋藤です。
ChatGPTのリリースから約1年半が経過し、LLMはモデル・アプリケーションの両面で大きな進化を遂げてきました。弊社でも、プロダクトのさまざまな部分でLLMの活用を進めてきました。本記事では、RightTouchにおけるこれまでのLLM活用について振り返るとともに、我々がLLMをどのように用いて、何を目指しているかについてご紹介します。
まず初めに、RightTouchについて簡単にご紹介します。RightTouchでは、「あらゆる人を負の体験から解放することで、人と企業の可能性を引き出す」というミッションで、下記3つのカスタマーサポート向けプロダクトを提供しています。
<ul>
<li>RightSupport by KARTE: webサイト上でのユーザー行動からユーザーのつまずきを検出し、最適なFAQや問い合わせチャネルへ誘導する</li>
<li>RightConnect by KARTE: webサイト経由で企業に電話をかけるユーザーの行動情報や事前ヒアリング情報を電話オペレータにリアルタイムに提示し、高品質・高効率な電話応対を実現する</li>
<li>KARTE Talk: webサイト上での有人チャットを行う</li>
</ul>
<img src="https://ik.imagekit.io/righttouch/2cfbb72a-0a6f-4981-a21c-0d75fbf81057/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-222.07.47.png" alt="RightTouchが提供するWebサポートプラットフォーム">
どのプロダクトも、お客様のWebサイトの拡張・強化を軸に、Web上/Web経由での最適なカスタマーサポートの実現を目指しています。これらのプロダクトは、個々で独立して使うことも可能ですが、Web行動データやナレッジデータなどに関しては、共通のデータ基盤の上に成り立っています。
<h1>RightTouchにおけるこれまでのLLM活用</h1>
RightTouchでは、これまで試行錯誤しつつ、LLMを活用した機能をいくつかリリースしてきました。
一例として、RightSupport by KARTEでは、<a href="https://speakerdeck.com/righttouch/llm-openai-devday">サポートシナリオの自動生成機能</a>を開発しました。これは、ユーザーのWeb行動から蓄積された統計情報をもとに、特定のページでユーザーに提示すべきFAQ選択肢や、そこに誘導するためのヒアリング項目をLLMを用いて自動生成するものです。
<img src="https://ik.imagekit.io/righttouch/941f0ab0-cf79-4015-8c6d-4f627e634ca4/%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E8%87%AA%E5%8B%95%E7%94%9F%E6%88%90%E7%B0%A1%E6%98%93%E7%89%88002.gif" alt="サポートシナリオの自動生成
">
また、KARTE Talkでは、有人チャットのオペレータ向けに、問い合わせ内容に合ったFAQの自動サジェスト機能や、これを利用した<a href="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1?talk=24-t1-session4">返信文の自動生成機能</a>をリリースしました。どちらの機能も、我々が持つデータアセットに対してLLMを適用し、業務効率化を実現するソリューションとなっています
<img src="https://ik.imagekit.io/righttouch/587b9c57-6ada-4ec5-b9aa-be5f9d89d164/LLM_note_01.png" alt="これまでのLLM活用の実例
">
これらの機能は、主に既存プロダクトの利用課題の分析や営業観点でのニーズ分析を行った上で、LLMの得意領域と交差する領域を探索的に見つけ出す形で開発してきました。結果として、リリース後は反響を頂くことができ、狙っていたプロダクト課題の解決にも貢献できました。開発を通じて、LLMの得手不得手や、我々のプロダクトドメインとの相性に関して知見をためられたことも非常に大きな収穫でした。
<h1>これからのLLM活用</h1>
これからも、短期的にLLMでユーザー課題を解きにいく活動は続けていきますが、中長期的には、我々の目指すビジョンの中でLLMがどう位置付けられるか？が重要であると考えています。
<a href="https://note.com/taito661/n/n23adce847fe0">代表の長崎の記事</a>でも述べられていますが、RightTouchはカスタマーサポート領域におけるコンパウンドスタートアップとして、業界のインフラとなることを目指しています。 
コンパウンドにプロダクトを展開していくにあたり、大きな軸の一つがデータです。あるデータを抑えると、そのデータを活用できる別のワークフローに進出でき、そこからまた新たなデータが抑えられ…という過程の繰り返しにより、プロダクトは拡大していきます。
しかし、現状、カスタマーサポートにおけるデータは、業界全体で見ても、整理・活用されているケースは多いとは言えません。RightTouchが得意とするweb領域は、比較的構造化されたデータが得られやすい領域ではありますが、それでも大半のデータは眠ったままです。web領域以外でも、コールセンターには、テキストデータを中心に未活用の構造化・非構造化データは大量に存在します。こういったデータにRightTouchがアプローチしていくにあたり、LLMはデータ取得/加工/活用の各プロセスにおいて強力な武器となります。
<h3>1.データの取得・加工</h3>
カスタマーサポートにおいて、データの活用が進みづらい一因が、取得・加工されたデータの質そのものにあるケースも多いと我々は考えています。例えば、エンドユーザーが問い合わせを行う際、自分の困りごとをうまく言語化できなければ、結果として得られる問い合わせデータの質は下がってしまいます。また、オペレータの応対においても、個々のオペレータが独自のポリシーで回答をしている場合や、ログ残しの基準にばらつきがある場合、その後のデータ分析はしづらくなります。LLMを用いれば、エンドユーザーに対する困りごとの特定の補助や、オペレータに対する同一基準でのログ残し補助ができます。これらは、主にUXや生産性向上の文脈で語られることが多いですが、うまく使えば、取得・加工されるデータの質の向上にも大きく寄与できます。
<h3>2.データの活用</h3>
大量に溜まったデータを業務に還元するのにもLLMは強力な武器となります。例えばLLMによるembeddingを利用すると、行動データ/問い合わせデータといった曖昧性のあるデータを、精度良く検索することができます。RAG等を組み込んだ検索により、オペレータやコンタクトセンターの管理者が、必要なナレッジや関連情報を瞬時に取得することができ、状況に応じた適切な応対の実現や、データの知見を生かした施策やナレッジの作成の自動化が行えます。
1と2は、車の両輪のようなものです。データの活用に目が行きがちですが、きちんと意味付けられ、整理されたデータがなければ、その活用は難しくなります。RightTouchとしては、両者をバランス意識していくことが重要だと考えています。まずはお客様の課題に合わせて、2でデータの直接的な利用価値を増やし、結果としてお客様との共創が増えて1が進み、それにより2の新しいチャンスが生まれる、という循環を回していければ理想です。
<img src="https://ik.imagekit.io/righttouch/58f40142-539b-46c5-8c5f-362dc368f6d7/LLM_note_02.png" alt="RightTouchが目指すLLM活用
">
ただ、当然LLMには、ハルシネーションのリスク、高いコストや厳しいレートリミットといった問題もあり、それだけでカバーできる範囲はまだ十分広くはありません。これらをクリアするためには、LLM・人・ルールをうまく組み合わせるUXの設計、適切なユースケース設定、キャッシュやデータストアの設計など、アプリケーションづくりの総力戦が必要となります。 
例えば、カスタマーサポート向けSaaSにおいてエンドユーザーに提供する機能では、正確性の観点から、LLMの生成結果をそのまま提示することは難しく、一定バリデーション等を挟み、型を絞った形でのアウトプットが求められるケースが多くなります。オペレータ向けの機能であっても、「LLMの出力に対してどこで人のチェックを挟むか？」をしっかり検討しなければ、業務効率化と蓄積されるデータの質の担保の両立は難しくなります。また、そもそもデータをセキュアに保存するインフラ基盤がなければ、良いプロダクトを作ったとしても結局お客様には使っていただけません。
データを軸としたプロダクト展開において、LLMは強力な武器ではありますが、UXを考え抜くこと、良いアプリ設計をすることなど、プロダクトづくりの基礎に徹底的にこだわるスタンスは変わらず重視していきます。
<h1>さいごに</h1>
ここまでお読みいただき、ありがとうございました。RightTouchでのLLM活用、エンジニアリングやプロダクトづくりに興味を持っていただけたら嬉しいです。もし、より詳細が気になる方がいらっしゃれば、<a href="https://www.wantedly.com/projects/1493065">ぜひカジュアルにお話ししましょう！</a>

RightTouchのLLM活用のこれまでとこれから

<h2>カスタマーサポートにおける自己解決とFAQ検索</h2>
Webでのカスタマーサポートにおいて、エンドユーザーにいかに自己解決してもらうかは重要な課題です。自己解決とは、例えば「サポートサイト・FAQ・チャットボット・マニュアル」などの手段を用いて、有人サポートに頼らず、ユーザーが自分自身で困っている内容を解決することです。自己解決率を高くすることで、簡易な問い合わせが減り、人が応対して解決すべき複雑な問題にリソースを割くことができるからです。
上記の理由から、企業のWebサイトにおけるFAQの検索は非常に重要です。適切なFAQにすぐに辿り着くことが出来れば、自己解決に繋がり、ユーザーの満足度も応対側の効率も高められるからです。しかし、実際のFAQ検索では、欲しい情報が見つからない、うまく検索ができないといったことがよく起こります。
なぜこういったことが生じるのかというと、自分の課題をFAQに存在している言葉で引っ掛けなければいけないという、なかなかに難しい問題を含んでいるからです。最近の検索システムでは、一般的な類義語登録や各企業が提供しているサービスのドメイン固有の単語を登録するなどして、検索がうまくいくよう工夫しています。ですが、それでも実際のFAQサイトでは、検索がうまくいかず、欲しい情報にたどり着けないため、結局エンドユーザーが電話やメールで問い合わせするということが頻繁に起こっています。
この問題を解決するための一つの方法として、自然言語をクエリとした検索があります。検索といえば、n個の単語をスペースで区切って検索するものが一般的ですが、自然言語による検索では、人に会話で質問をするように、検索することができます。
例えば、Webサービスでログインパスワードを忘れた場合のFAQを検索したい場合:
単語検索: 「ログイン パスワード 忘れた」
自然言語検索: 「ログインパスワードを忘れたんだけどどうしたらいい？」
のような違いがあります。上記の例では、単語検索も簡単ですが、より複雑な問題になったときは、自然言語で検索したほうが問題を表現しやすいことは多々あると思います。
では、このような自然言語による検索システムを構築するにはどうしたらいいでしょうか。そのためには、Embeddingという技術を利用します。EmbeddingはChatGPTなどのLLMで利用されており、文章を入力すると、浮動小数点のベクトルが出力されます。ベクトルで出力されるということは、ベクトル間の距離を測れるということになり、つまり文章間の距離（関連性）を計算することができます。そのため、先程の自然言語検索の例では、予めFAQ記事をEmbeddingでベクトル化しておき、入力された文章もベクトルで表現し、各FAQ記事との距離を計算し、距離の近いものから表示することで、検索機能を実現できるのです。
<img src="https://ik.imagekit.io/righttouch/22522506-1cbb-439c-9182-6ca1d059eda4/Untitled(1).png" alt="Untitled(1).png">
弊社の<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a> (以下、RightSupport) でも上記のような仕組みで検索機能を実装しており、自然文による検索を提供しています。RightSupportでは、AzureのOpenAI ServiceのEmbeddingsを利用しています。
<a href="https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/models#embeddings-models">https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/models#embeddings-models</a>
RightSupportではEmbeddings APIを直接利用し、検索機能自体は独自に実装していますが、最近ではLLMを利用した自然言語クエリによる検索機能自体がPaaSとして提供されています。今回は、それらの検索機能がどんなものか使ってみます。試してみるサービスは、Google Cloud Platform (GCP) の<a href="https://cloud.google.com/vertex-ai-search-and-conversation?hl=ja">Vertex AI Search and Conversation</a>です。
<h2>Embeddings APIを利用した検索システム</h2>
Vertex AI Searchを使う前に、現状のRightSupportで行っている検索について簡単に説明しておきます。RightSupportでは、クライアント企業のFAQ記事をインポートし、FAQ検索ウィジェットとしてサイトのあらゆる場所に提供できるといった機能があります。このFAQ記事検索にOpen AIのEmbeddingsを利用しています。
機能としては以下のようになっています。
<ol>
<li>各FAQ記事をEmbeddings APIに投げて、ベクトル化し、CacheとDBに保存しておく</li>
<li>エンドユーザーが検索すると、その文言をEmbeddings APIに投げてベクトル化する</li>
<li>検索文言と各FAQ記事のコサイン類似度を計算し、1に近いものから順にFAQ一覧を表示する</li>
</ol>
Open AIのEmbeddingsはnormalizeされており、難しいことを考えず内積を取れば簡単に類似度を計ることができます。
実際の検索結果は下図のようになっており、自然文の検索文言に対してそれっぽい記事が引っかかっていることがわかります。検索文言のサポートウィジェットというのは、RightSupport内の機能の一つであり、サイト内にサポート用のウィジェットを出すための機能です。実際中身まで見てみると、1件目はその強調表示の設定方法そのものズバリであり、2件目はサポートウィジェットにおいて効果的な使い方の一つとして強調表示を設定する方法を案内しています。これらの結果から検索結果としては妥当な感じがします（定性評価になってはしまいますが…）。
<img src="https://ik.imagekit.io/righttouch/9707e39d-53f8-434b-a095-8c16cf25581a/Untitled(2).png" alt="Untitled(2).png">
<h2>Vertex AI Search</h2>
次にVertex AI Seachを利用して、同じFAQで検索アプリケーションを作ってみます。Vertex AI Search and Conversationは、LLMを利用し検索やチャットボットなどを簡単に構築できるGCPのプロダクトです。今回は検索なので、Vertex AI Searchを利用します。設定方法に関しては公式のドキュメントやブログなどで色々と記事が出てるので割愛します。
Vertex AI SearchはGCP上では <code>検索と会話</code> という名前になっており、開くと以下のように作成した検索アプリなどが一覧として表示されます。
<img src="https://ik.imagekit.io/righttouch/d7a1cfc2-e382-4c9c-b590-d6a8e17af67d/Untitled(3).png" alt="Untitled(3).png">
<h3>自然言語クエリ処理の利用</h3>
Vertex AI Searchで自然言語クエリを利用するためには<a href="https://cloud.google.com/generative-ai-app-builder/docs/multi-turn-search">フォローアップ検索</a>をオンにする必要があります。フォローアップ検索を利用するにはデータストアと検索アプリの作成時に以下の設定をする必要があります。
<ul>
<li>データストアは非構造化データかウェブサイト
<ul>
<li>ウェブサイトの場合は <code>高度なインデックス登録</code> をオンにする</li>
</ul>
</li>
<li>検索アプリを作成するときに <code>高度なLLM機能</code> をオンにする</li>
</ul>
これらの設定を行い、検索アプリを作成することで自然言語クエリによる検索機能を作ることができます。実際に、弊社のプロダクトであるRightSupportのヘルプページ (<a href="https://help.rightsupport.karte.io/">https://help.rightsupport.karte.io</a>) のデータを元に検索アプリを作ってみました。
実際に検索してみます。RightSupportにはサポートウィジェットというWebサイト上にウィジェットを出す機能があり、またそのウィジェットをエンドユーザーが起こしたイベントに応じて強調表示する機能があります。その機能について調べてみます。
<img src="https://ik.imagekit.io/righttouch/90dfb4d5-506c-4509-a433-6ec4de48c0ff/Group38.png" alt="Group38.png"> 
左図は構造化データを利用しフォローアップ検索をオフにした検索アプリで、右は非構造化データを利用しフォローアップ検索をオンにした検索アプリです。「サポートウィジェット　強調表示」のように単語を並べて検索した場合は、検索結果は違いますが、どちらもいずれかのFAQがヒットしており、また1つ目の結果は同じページでした（データの入れ方が違うため結果のUIが違いますが）。
次に「サポートウィジェットの強調表示設定について知りたい」という自然文による検索をしてみます。 
<img src="https://ik.imagekit.io/righttouch/ccd40469-9514-47aa-9f6b-811b29a28cb7/Group41.png" alt="Group41.png">
このように、フォローアップ検索がオフの場合は、検索になにもヒットしませんが、フォローアップ検索がオンの方ではそれっぽい検索結果が返ってきています。定性評価になってしまいますが、2件目以降（1件目の検索結果は同じなので）の結果は自然文による検索の方が欲しい情報が返ってきている感じがします。
これらのアプリは、さくっと1, 2時間くらいで出来ました。このように、Vertex AI Searchを使えば、LLMを利用した自然言語クエリによる検索を手軽に作ることができます。
Vertex AI Searchを使ったトライアルは、今回はここで終わりますが、次はAzureの <a href="https://azure.microsoft.com/ja-jp/products/ai-services/ai-search">Azure AI Search</a> も試してみたいと思います。また、これらのサービスはただ自然言語クエリによる検索が出来るだけではなく、GoogleやBingの検索技術を色々と盛り込んだ高機能な検索やチャットボットのようなものになっています。自然言語処理の専門家がいなくても、高度な検索機能が手軽に作れるように技術が進化しているのは、小さなチームでトライを重ねている僕たちのようなスタートアップにとって、とても良い環境になったのを感じています。
またRightTouchには、こうしたLLMの活用をはじめ、最新の技術に積極的に触れて、プロダクトに活用できないかを考える環境・カルチャーがあります。RightTouchの取り組みや雰囲気に興味を持ってくださった方がいたら、ぜひカジュアルからお話できたら嬉しいです。
<div class="iframely-embed" data-embedded-url="https://righttouch.co.jp/recruitment"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://righttouch.co.jp/recruitment" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frighttouch.co.jp%2Frecruitment&key=878c5bef402f0b2911bf6d4ce6261abd">採用情報 | 株式会社RightTouch</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
エンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/engineer">https://recruit.righttouch.co.jp/engineer</a>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Blog

Recent Article