RightTouch Blog

Haruki Kawashita

Sanshiro Sakai

Nariyuki Saito

Aaron Madlon-Kay

Tomoaki Oiki

Yuma Takeuchi

RightTouch Blog 編集部

Daichi Kanke

Yuichi Yabu

RightTouchは、プレイドからスピンオフしたスタートアップで、カスタマーサポート領域向けのWebサポートプラットフォーム「<a href="https://rightsupport.karte.io/">RightSupport by KARTE</a>（以後、RightSupport）」「<a href="https://rightconnect.karte.io/">RightConnect by KARTE</a>（以後、RightConnect）」などを提供しています。
カスタマーサポート領域の抜本的変革に挑んでいるRightTouchは、複数プロダクトを提供するコンパウンドスタートアップとして、常に新たな事業、プロダクトの開発に向けて動いています。今回の記事では、α版がリリース済みであり、今後正式版のリリースを予定するフェーズのプロダクトに焦点を当てます。
約1ヶ月という超短期間で一つのプロダクト開発に携わったという新規事業開発の田中(akky)、エンジニアの齋藤(nari)、赤木(giinyo)の3人にインタビュー。“RightTouch流”コンパウンド戦略、そしてビジネスサイドと開発サイドとの圧倒的な信頼関係をもとに、高速でプロダクト開発をどのように実現したのか話を聞きました。
<blockquote>
＜プロフィール＞ 
田中 彬寛／akky（たなか あきひろ） 
九州大学工学部機械航空工学科卒業後、2017年にリクルートホールディングス入社。プロダクトグロースや事業戦略策定／実行、全社横断ナレッジ統括などに従事。 2022年にRightTouch入社、セールス及びカスタマーサクセスのリード／BizDevを担当。好きな言葉は「ロマンとそろばん」。趣味はサウナ、ポーカー、アニメ。
</blockquote>
<blockquote>
齋藤 成之／nari（さいとう なりゆき） 
東京大学大学院で博士課程修了後、2020年に日立製作所に入社。研究開発部門で業務システム開発に関する業務に従事。2021年10月プレイドに入社し、現在はRightTouchのテックリードとして開発に携わる。
</blockquote>
<blockquote>
赤木 勇統／giinyo (あかぎ ゆうと) 
大阪大学大学院を修了後はPhotosynthに新卒入社。主にAkerun入退室管理システムの開発に従事。新たな挑戦がしたいという想いがあり、2024年1月にRightTouchへ転職。RightTouchでは、RightSupportの開発担当を経て、新規プロダクトチームへジョイン。 
</blockquote>
<img src="https://ik.imagekit.io/righttouch/dfaffa20-3aab-4bd7-9f38-de0af07fdca8/DSC00850.jpg" alt="DSC00850.jpg"><center>左から田中（akky）、赤木（giinyo）、齋藤（nari）</center>
<h2>既存顧客との活動から新たなプロダクトの課題仮説と可能性を模索する</h2>
——「今回の新規プロダクトの詳細についてはまだ秘密…」と伺っていますが、どのようなアイディアがきっかけで開発に至ったのか教えていただけますか？
akky：今回の開発のきっかけに言及する前置きになりますが、アイディアを形にして、市場で仮説検証を行い、事業やプロダクトに還元する。このサイクルを高速で回していくことこそ、初期から複数プロダクトを並列で立ち上げていくコンパウンド型の事業成長においてもっとも大切だと思っています。だから、セールスやカスタマーサクセスの活動をしながらも常に新規事業の可能性を模索していました。
——今回の新規事業における「課題の特定や事業の方向性」はどのように決定していったのでしょうか？
akky：これまでRightTouchでカスタマーサクセス、事業開発を行ってきた知見から、カスタマーサポート領域で優位性を築くために“絶対に押さえなければいけないデータ”があることはわかっていました。
その上で、2023年秋ごろから10社ほどのクライアントのもとに足を運び、カスタマーサポートの業務全体を通じてどんな困りごとを抱えているのか、RightTouchとしてどんな打ち手があるかヒアリングし、新規事業の解像度を高めていきました。
ヒアリングを通して共通して出た課題意識を、新規事業の「What（何を解決するのか）」として設定することに決めました。 
<img src="https://ik.imagekit.io/righttouch/f7a99e1f-8366-4c0b-a559-0b67f3ed7732/DSC00834.jpg" alt="DSC00834.jpg"><center>BizDev 田中（akky）</center> 
——最初はチームではなく、一人で進めていたのですね。
akky：はい。「How（どのように解決するか）」を検討するため、パワーポイントに簡易的にアイディアを落とし込み、クライアントにプレゼンを行って仮説を当てていきました。このあたりから、エンジニアのnariくんにも協力してもらい、技術的な観点でフィードバックをもらっていきました。 
 nari：実は、当初は新規プロダクトという形ではなく、クライアントからデータをもらって加工する受託開発として進めていたんです。
その過程で、技術的な検証や提供価値の検証は、一定できました。しかし「本当に使いやすい形でプロダクトとして提供できるのか？」「継続して使ってもらえるのか？」といった、プロダクト化にあたって重要な論点は残っていました。もちろん、モノを作らずにこれらの論点を検証することもできたかもしれませんが、新規プロダクトとして開発に本腰を入れた方が良い、という経営判断もあり、2024年4月にエンジニアのgiinyoも含めたプロジェクトチームを組成しました。
——そこから、どのようなプロセスを経たのでしょうか？
nari：私はチームを組成直後から、まずは自分自身がこの新規プロダクトにフルコミットできるようリソース調整を行いました。akkyのおかげで大まかなアウトプットのイメージはできていたので、クライアントからもらった細かな要望や意見をもとに、MVP（Minimum Viable Product）を作ることに注力していきました。 
 akky：MVPを作るにあたって、「カスタマーサポートの現場で働く方々がきちんと活用できるもの」をゴールに設定しました。過去の経験から、コールセンターの皆さんは非常に膨大な量の問い合わせデータと向き合っていますが、ITツールに慣れていない方も多いと感じています。
プロダクトを作っても、日常的に活用してもらえなければ意味がない。そこで、実際の使用イメージが湧くように、<a href="https://note.righttouch.co.jp/n/n97bc415698b2?gs=53dcaaa6989f">デザイナーのkimさん</a>にも加わってもらい、MVPに沿ったデザインや、フロントエンド、バックエンドまで作り込みました。 
<img src="https://ik.imagekit.io/righttouch/5b7fe5a4-dcb4-4599-b645-9470a9da855c/DSC00809.jpg" alt="DSC00809.jpg"><center>テックリード 齋藤（nari）</center>
<h2>「共通開発基盤」と「リファレンスカスタマー」がコンパウンドの鍵</h2>
——チームを組んでから約1ヶ月という短期間でMVPを完成したと伺いました。そこまでのスピード感が出せたのはなぜですか？
akky：大きく3つ要因があると思っています。
一つは、コンパウンドスタートアップならではの強みだと思いますが、「共通開発基盤」と「リファレンスカスタマー」の存在です。
ゼロイチの開発といっても、すでにRightTouchで築き上げてきたフレームワークやリファレンスカスタマー（RightTouch既存プロダクトを導入・利用してくださっている代表的な企業）との信頼関係があるからこそ、ここまでのスピード感をもって開発に集中できたのだと思っていて。
特に大企業の部長・役員クラスともすぐにコミュニケーションがとれるのは、カスタマーサポートという非常に規模と影響範囲の大きな領域に向き合う上で大きな優位性となっていると感じます。 
 giinyo：私がこのチームにジョインした時には、「何を作るべきか」「クライアントにとってどんな価値を生むのか」がほぼ明確な状態でした。エンジニアにとって、プロダクトの価値を確かめながらものづくりができる環境はすごくありがたいんです。すぐに「早くこのプロダクトを世に出したい」という気持ちにまでなっていましたね。 
 akky：二つ目は、最初から「スケーラビリティ」を意識しなかった点かなと。
——コンパウンドスタートアップは、事業拡大、すなわちスケールを見越して仕様検討する場合が多いですよね。
akky：そうですよね。ただ、最初からスケールした先を意識して、細々としたところまで作り込んでしまうと、開発のスピード感は損なわれてしまう。だからまずは、PMF（プロダクト・マーケット・フィット）させることに主眼を置くことにしたんです。 
 nari：もちろん良し悪しはありますが、まずは市場に出し、顧客からフィードバックを受けながら仮説検証を行っていく姿勢も重要だと思っています。 
<img src="https://ik.imagekit.io/righttouch/fd77116c-ef5d-4f3d-af59-0279a8c939ad/DSC00885.jpg" alt="DSC00885.jpg"><center>エンジニア 赤木（giinyo）</center>
<h2>キーワードは「背中を預け合える信頼関係」。プロダクトづくりに集中できるRightTouchの環境とは？</h2>
——RightTouchが高速でプロダクト開発を進められる、最後の理由は何でしょうか？
akky：全員がプロフェッショナルであること、でしょうか。
「コンパウンドスタートアップの勝ち筋」として非常に重要なのが、「開発のスピード感」です。
その観点でいうと、メンバー一人ひとりがプロフェッショナルとしてミッションを果たす環境が当たり前にあるRightTouchだからこそ、実現するのではないかなと。 
<img src="https://ik.imagekit.io/righttouch/c20f7765-d142-4784-8c6b-cdd9ea22ff1b/DSC00893.jpg" alt="DSC00893.jpg"> 
——全員がプロフェッショナル、というのは具体的にどんな場面で実感しますか？
akky：RightTouchは、意思決定のトップダウンとボトムアップのバランスがとても良い組織です。大きな戦略や外してはいけないポイントは、経営陣が中長期からバックキャスト（逆算）してしっかり決めますが、その幅のなかでの現場の自由度はとても高い。 
今回も、冒頭に話した“（カスタマーサポート市場におけるコンパウンド戦略実現に不可欠な）絶対に押さえなければいけないデータ”を得ることができれば、どんなプロダクトとして実現するかは僕たちチームからのボトムアップで決められました。「データを押さえる」という観点で事業戦略との接合は作れていたということです。 
コンパウンドスタートアップも様々なスタイルがあると思いますが、感覚としては、すでに細かくプロダクトロードマップが引かれており、作るプロダクトの枠組みがおおよそ決まっている企業が多いように思います。 
スタートアップとして、限られたリソースをどのタイミングで何に配分するか、という経営判断は非常に重要ですが、全員が当事者意識を持って日々業務にコミットしているからこそ、こうした意思決定もスムーズに委ねてもらえたのではないかと思っています。 
 giinyo：手前味噌かもしれませんが、RightTouchにはakkyさんをはじめとしたクライアントと密な信頼関係を築き、プロダクトに対して深く率直なフィードバックを持ち帰ってきてくれるビジネス担当がいる。クライアントとのコミュニケーションは全面的に任せられるので、私たちエンジニアも開発に集中できるのだと思っています。 
 nari：チームとしてもバランスが良かったと思います。akkyは比較的楽観的にどんどん物事を前に進めていくタイプで、私はどちらかというとリスクを考えるタイプ。多様な視点を持ったチームかつ、各々をリスペクトしているからこそ、スムーズにゼロイチの開発ができたと感じます。
——ビジネス担当、エンジニア双方が強い信頼関係で結ばれているのがわかります。
nari：RightTouchでは「全員プロダクト担当、全員顧客担当」というバリューを大切にしています。役割に囚われず、事業成功にコミットしていくというマインドがあるんです。
だからこそ、クライアントへのプレゼンやミーティングには、私やgiinyoもできるだけ出席し、議論に参加するようにしました。
akky：ビジネス担当としても、クライアントとの打ち合わせにエンジニアも一緒に入ることで、要望や意見に対して「YES/NO」を即答できるのはすごく心強いんです。私が出したアイディアにも、すぐに仕様を書いて、技術的観点でフィードバックをくれますし。こうした環境で仕事ができるのはなかなか貴重ですし、とても嬉しいですね。
giinyo：回答や結論を持ち帰った場合でも、プロダクトへの実装は可能なのか、他にどのような選択肢があるのか、すぐにディスカッションを行いました。全員が同じ目的意識のもと、それぞれの役割に最大限コミットした結果、このようにスピード感を持った開発ができたのだと思います。
——RightTouchではビジネス担当、エンジニアが互いに背中を預けられる関係だからこそ、高速のプロダクト開発ができるのですね。貴重なお話、ありがとうございました！
<h2><img src="https://ik.imagekit.io/righttouch/7e3b0250-c21d-4a9c-9ee3-dba071f8837d/DSC00858.jpg" alt="DSC00858.jpg"></h2>
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>
カスタマーエンジニア求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/customer-engineer">https://recruit.righttouch.co.jp/customer-engineer</a>
デザイナー求人情報の詳細 
<a href="https://recruit.righttouch.co.jp/designer">https://recruit.righttouch.co.jp/designer</a>
（ライター／安心院 彩（フリーランス） 　取材・編集／緒方 祥子（フリーランス））

 高速でプロダクトの価値を検証せよ——RightTouch流コンパウンド事業立ち上げの勝ち筋

SlackのuserGroupメンションをアシストするアプリをCraft Functionsで作ってみた

SlackのユーザーグループメンションをアシストするアプリをCraft Functionsで作ってみた

※この記事は<a href="https://note.com/s346/n/n695816901938">RightTouch公式note</a>に掲載した内容を転載しています。
<h2>はじめに</h2>
RightTouchでエンジニアをしているsanshiroです。現在は主に<a href="https://rightconnect.karte.io/">RightConnect by KARTE</a> (以下RightConnect)の開発を担当しています。
RightConnectとは、昨年β版をリリースしたコンタクトセンターのオペレーター向けのプロダクトです。このプロダクトの目的は、Webサイトと電話の問い合わせ体験を統合し、電話の応対効率と顧客体験を最大化しすることです。
RightConnectの特徴の一つは、オペレーターが電話応対をしながらWeb上での行動や問い合わせ情報をリアルタイムで確認できる点です。この機能を実現するために、β版ではオペレーター向けのダッシュボードを作成しました。β版の運用・検証する中で明らかになった課題に対処するため、オペレーター向けのダッシュボードのリニューアルを4月に行いました。
本ブログでは、紆余曲折あったリニューアルのプロセスについてご紹介できたらと思います。
<h2>オペレーター向けのダッシュボードについて</h2>
<img src="https://ik.imagekit.io/righttouch/10f8c558-6a78-43af-b8be-2597e4f6476c/%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-05-2018.03.32.png" alt="スクリーンショット2024-05-2018.03.32.png">
LPより抜粋 <a href="https://rightconnect.karte.io/">こちら</a>
RIghtConnectは電話の応対効率と顧客体験を最大化を目的に開発され、顧客とオペレーターの 双方 の満足度を高めることに注力しています。
電話の応対で顧客が抱える不満で最も多いのは、待ち時間が長いことですが、説明の手間や話が噛み合わないといった情報伝達・コミュニケーションに関しても不満が上がることが多いです。
オペレーターが使いやすいプロダクトにすることで、顧客とオペレーターの情報伝達が円滑になり、顧客体験の向上に直結します。また、応対効率も向上するので、待ち時間の削減にも繋がります。
そのため、顧客の満足度のみを考えるのではなく、オペレーターが使いやすいプロダクトとしての満足度向上にも注力しています。
RightConnectの具体的な要素は大きく分けて3つで構成されています。
<ol>
<li>問い合わせ前行動を元に、顧客のお困りごとに合わせた最適なチャネルをご案内</li>
<li>顧客ごとの問い合わせ前行動の情報をオペレーターに還元し、ステータスや悩みを瞬時に把握</li>
<li>Webサイト上の行動や顧客属性、問い合わせきっかけなど、さまざまなデータをリアルタイムに解析・可視化</li>
</ol>
詳細は、RightConnectのβ版開発の裏側について書かれた<a href="https://blog.righttouch.co.jp/rightconnect-beta-release">こちらのブログ</a>をぜひご覧ください。
オペレーター向けのダッシュボードは、2.顧客ごとの問い合わせ前行動をオペレーターに還元し、ステータスや悩みを瞬時に把握 を実現するために、ユーザーの問い合わせ前行動を閲覧できることに加えて、ユーザーのWeb行動を動画でリアルタイムで再生しながらマウスポインタの共有も可能な画面として開発されました。
オペレーターは、問い合わせ応対時にオペレーター向けのダッシュボードを常に利用します。オペレーター向けのダッシュボードの使いやすさ = オペレーターにとってのプロダクト使いやすさ になります。
そのため、オペレーター向けのダッシュボードは、オペレーターにとって、見たい情報が見やすい形で表示され、必要な機能が使いやすい画面であることを追求して開発を行っています。
<h2>β版で明確になったオペレーター向けのダッシュボードへの課題</h2>
RightConnectはMVP(Minimum Viable Product)としてスピード重視で開発され、クライアントへ迅速な価値の提供を行いました。プロダクトを実際に運用・検証を行えたことが非常に重要で、特にRightConnectを利用しているコンタクトセンターの見学にチームメンバー全員で行かせていただことが以下の課題の発見につながりました。
<ul>
<li>オペレーターは多数のツールを使っており、そのそれぞれが高度にカスタマイズされている。その状態であっても、オペレーターがよく見る項目は限られており、無駄なスペースもある。</li>
<li>オペレーターにとってのダッシュボードの価値を最大化するためには、「そのセンター」「そのリーズン(顧客の困りごと・達成したいこと)」に最適化されたダッシュボードの項目や配置が実現できる必要がある。</li>
</ul>
β版のオペレーター向けのダッシュボードでは簡易的なカスタマイズは可能であったものの、これらの課題を解決するために求められる ダッシュボードの柔軟なカスタマイズ性は実現できない部分がありました。
4月から導入社数も増加予定だったこともあり、大規模な導入が進む前にオペレーターへのダッシュボードの価値を最大化できるようにリニューアルすることを決め、ダッシュボードが柔軟にカスタマイズできることという機能要件にフォーカスして設計を開始しました。
<h2>オペレーター向けのダッシュボードv2の設計</h2>
<img src="https://ik.imagekit.io/righttouch/b07ecaed-cb3d-4ffc-bb5b-159bcdccef73/%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-05-2019.40.30.png" alt="スクリーンショット2024-05-2019.40.30.png">
オペレーター向けのダッシュボードv2の初期デザイン(設定画面)
RightTouchでは、職種問わず担当者がPRD(製品要件文書)を作成し、それをもとに、議論し、方向性・仕様を固め、開発に着手します。 
オペレーター向けのダッシュボードのリニューアルを行う際にも、運用・検証で得られた課題を元にダッシュボードの柔軟なカスタマイズ性を重視したPRDが作成されました。
カスタマイズ性の例としては、以下のようなものになります。
<ul>
<li>情報を自由に追加削除できる</li>
<li>直感的な操作で要素を並び替えることができる</li>
<li>顧客のリーズンに合わせたダッシュボードの表示ができる</li>
<li>ダッシュボードへの新機能の追加がしやすい</li>
</ul>
それに伴いデザインも柔軟なカスタマイズと今後の機能追加がしやすい形を追求し、機能要件を満たすために管理者が利用する設定画面を重点的にデザインしました。
<h2>プロトタイプ作成、再検証</h2>
PRD・デザインを元に開発を進め、一連の機能が操作できる状態になった段階で、社内でフィードバック会を開催しました。この会はRightTouchメンバー全員が参加可能で、実際に機能を触ってもらいながら幅広い意見を集めることを目的としています。
その結果、ダッシュボードの柔軟なカスタマイズ性に関する機能要件は問題がないことが分かりました。
一方で、本来のプロダクトとしての オペレーターにとって見やすい・使いやすい 部分が少し犠牲になっているのではといったフィードバックがチーム外のメンバーからありました。
チーム内でカスタマイズの機能要件にフォーカスし、機能・デザインの修正を繰り返していく過程の中で、オペレーターにとって見やすい・使いやすいの観点が薄まっていることに、フィードバックの機会を持つことで気づくことができました。
本来の目的が失われては、今後、プロダクトとしての価値を提供できないと判断し、カスタマイズ性を保ちつつ、オペレーターが使いやすい・見やすい画面としての細かいUI/UXといった非機能要件に徹底的にこだわるという観点を補強し、デザインをやり直すことを決めました。
デザインを作り直すコストはありましたが、プロダクトとしての価値をフラットに見直してリリースを遅らす意思決定しました。その際、チームのBusiness、Customer Engineerメンバーがその価値をクライアントにも丁寧に説明することで、考え方に賛同していただけました。
<h2>デザイン案の再設計</h2>
まず、オペレーターが使いやすい・見やすい画面として、電話しながらでも対応がしやすい理想のダッシュボードとは何かというところに立ち返ってチームで再度議論し直しました。
今まで行ってきたコンタクトセンター見学の情報などを元に、デザイナーは具体的な形にし、他職種のメンバーはインスピレーションを得るためにネットからダッシュボードのデザイン案を探しました。その中で、どのような要素が、見やすい・使いやすい画面に必要なのか、現在の画面には何が足りていないのか、画面構造から詳細の細かい表現まで議論を行い、理想のイメージをチーム間で共有し、整理しました。
<h2>デザインの反映</h2>
<img src="https://ik.imagekit.io/righttouch/7c81238f-f77d-4b4c-bf7c-13ce1fd1c5e8/%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-05-2021.48.23.png" alt="スクリーンショット2024-05-2021.48.23.png">
デザイン案再設計後のデザイン(オペレーター向けの表示画面)
デザインの反映は、理想のイメージを今後実現できるように、主にデザインの構造の修正とオペレーターが見やすい・使いやすいUI/UXへの修正を行いました。
主な変更点としては、以下になります。
<ul>
<li>構造の修正
<ul>
<li>カラム → カード(見出しと白いエリア部分) → コンポーネント(各情報) の階層構造に変更
<ul>
<li>カード内でコンポーネントを複数列表示等に対応できるように</li>
</ul>
</li>
</ul>
</li>
<li>各コンポーネントの表現方法
<ul>
<li>見出し・内容のテキストの色・サイズの調整</li>
<li>影など、ノイズになる可能性のあるデザインを修正</li>
</ul>
</li>
<li>イベントの表現方法
<ul>
<li>ユーザーの行動が視覚的にわかりやすいようにタイムライン表示に</li>
</ul>
</li>
</ul>
特に裏側のデータ構造に影響のある、理想のデザイン構造とすでに開発したデザイン構造で齟齬がある部分、妨げになる可能性のある部分の修正に絞って対応することで、1〜2週間程度で修正が完了しました。
結果、想定していた初期のリリース日から大きく遅らせずにリニューアルを完了できました。 
最終的に本来の目的であるオペレーターの使いやすさとスピードの両面を取れた形でリニューアルを完了できたことにチームとして満足しています。
<h2>まとめ</h2>
一度β版でリリースしたものをその延長で考えて、一度考えた方向性で固執せずに、理想を再定義して作り直すことで、プロダクト本来の価値を最大化するリニューアルを行うことができました。
今回のケースから今後は、プロダクトの価値を高めるために以下をより意識して、開発を行っていきます。
<ul>
<li>プロダクト全体としての目的をチーム間で 常に 共有しながら機能開発をすすめること</li>
<li>(ユーザー・社内)フィードバックの機会を 早めに何度も 設けること</li>
</ul>
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でエンジニアをしているsanshiroです。現在は主にRightConnect by KARTE https://rightconnect.karte.io/ (以下RightConnect)の開発を担当しています。  RightConnectとは、昨年β版をリリースしたコンタクトセンターのオペレーター向けのプロダクトです。このプロダクトの目的は、Webサイトと電話の問い合わせ体験を統合し、電話の応対効率と顧客体験を最大化しすることです。  RightConnectの特徴の一つは、オペレーターが電話応対をしながらWeb上での行動や問い合わせ情報をリアルタイムで確認できる点です。この機能を実現するために、β版ではオペレーター向けのダッシュボードを作成しました。β版の運用・検証する中で明らかになった課題に対処するため、オペレーター向けのダッシュボードのリニューアルを4月に行いました。  本ブログでは、紆余曲折あったリニューアルのプロセスについてご紹介できたらと思います。

プロダクトの価値と課題に向き合ったら、ダッシュボードのUIを完全に再設計することになった

プロダクトの価値と課題に向き合ったら、ダッシュボードのUIを完全に再設計することになった話

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

Blog

Recent Article