Inside of LOVOT

GROOVE X 技術ブログ

非英語話者の海外登壇（EuroPython 2023/PyCon TW 2023）

こんにちは！ソフトウェアチームのエンジニアのふくだです。
この記事は、GROOVE X Advent Calendar 2023の19日目の記事です。

qiita.com

英語をほとんどしゃべれない私ですが、海外のカンファレンスで登壇する機会を得ました。そのチャレンジの様子と、どうやって乗り越えたのか、をお伝えする記事になります。

参加したカンファレンスって

今回参加したのは、Pythonというプログラミング言語のカンファレンスです。Pythonのカンファレンスはは世界中で行われています。

世界中で行われているPyCon。こちらより引用 Join us at PyCon

また、 先日日本でもPyCon APAC 2023が開催され、弊社はスポンサーをさせていただきました！

PyCon APAC 2023でのスポンサーブースの様子はこちらの記事をご参照ください。 tech.groove-x.com

私の登壇したカンファレンス

今回私が登壇したのは、ヨーロッパの各地で年1回開催されているEuroPython 2023と台湾で行われているPyCon TW 2023です。プロポーザルを出し、採択いただき登壇することになりました。

名称 開催場所 開催期間
EuroPython 2023 チェコ・プラハ 7月19日⁠～21日
PyCon TW 台湾・台北 9月1日⁠～2日

どちらのカンファレンスもとてもとても楽しかったです。ここでその話をすると長くなってしまいますので、カンファレンスの様子については、gihyo.jp さんの以下の記事をご参考ください。

日本からひとりで参加した「EuroPython 2023」スピーカー体験レポート | gihyo.jp

https://gihyo.jp/assets/images/article/2023/12/road2euro-python23/002.png

PyCon TW 2023 カンファレンスレポート | gihyo.jp

https://gihyo.jp/assets/images/article/2023/09/pycon-tw2023/007.png

どれくらい英語しゃべれないの？

相当しゃべれないです。辞書を片手にゆっくり読むことはできるのですが、会話となると全く出てこなくなってしまいます。私の所属するふるまいチームには英語ネイティブのスーパーエンジニアがいます。その方は日本語をほとんどしゃべれません。ですが、その方に、日本語を話させてしまうくらいしゃべれないのです。

朝会の様子

非英語話者の海外登壇

どうやって乗り切ったの？トーク編

テクノロジーを頼って乗り越えました。自分の発表の準備や、他のセッションの聞き方について紹介します。

自分の発表（スピーキング）

私はトークをする時、必ず台本（原稿・トークスクリプト）を用意します。おおよそ以下の流れです。

  1. トークの見出しを決める
  2. 大枠の内容を埋める
  3. 台本を用意する
  4. 発表の練習をする
  5. 練習でだめだったところを修正する

3~5を繰り返し行って、クオリティをあげていくのが理想です。またその中で時間調整も行っていきます。

そして今回は英語です。まずは日本語で作った資料と台本を英語に翻訳していきます。翻訳で苦労したのは、「英語として意味が通じるか」といった点です。 また、日本語の時点でも資料・台本に荒さがあるため、日本語を修正→英語翻訳を修正、といった日本語でやる場合の倍の労力もかかりました。

資料と原稿はこんな感じです。MacのKeynoteを使っています。

常に手元に英語の先生がいてくれると嬉しい状況でした。つまらないことも聞きたい。そしてそう、2023年の私たちには手元にあの先生がいますね。今回翻訳にあたり、2つのWebサービスにとてもお世話になりました。

本当にささいいな言い回しをたくさん確認しました。ありがとうChatGPTさん

もちろん、社内で練習することも可能です！ですが、今回バタバタしすぎて、社内での練習はできませんでした。。。

本番の資料、ビデオは公開されておりますので、ご興味ある方は是非そちらからご覧ください（笑ってください。。）。

他の方の発表（リスニング）

普段英語圏の方のトークを見る時は、動画配信がほとんどです。YouTubeであれば、字幕機能を活用しています。ただし、オフラインだとそうはいきません。また英語圏のため、日本語への同時翻訳などもちろんありません。

はじめは、Google翻訳の音声入力を活用しようと思ったのですが、長時間の音声入力とその翻訳となると、うまく使いこなせず、内容が入ってきませんでした。 そこで、次のサービスを利用しました。

Euro Pythonに参加した時はOtterを、PyCon TWの時はOtterとMicrosoft Translatorを利用しました。 どちらもリアルタイム文字起こしが可能です。スマートフォンでアプリを起動し音声入力を行い、リアルタイムでPCのWebサイトで確認できる、というものです。

Otterは翻訳はしてくれないのですが、リアルタイムで英語の文字起こしができるため、サクサク内容をキャッチアップすることができました。

EuroPython 2日目のソフィー・ウィルソン氏のKeynote

Microsoft Translatorは翻訳もできます。PyCon TWでは、中国語でのトークも多かったため、非常に助かりました。

どうやって乗り切ったの？コミュニケーション編

イベント中や現地のコミュニケーションは、定型文とGoogle翻訳で乗り切りました。

また、初対面のエンジニア同士のコミュニケーションは、とても気軽に行うことができました。「どこからきたの？」「どんな仕事をしているの？」といった内容で始まることが多かったです。話をしていると、人種がちがって、バックボーンも国も違っても、同世代のエンジニアである以上、似たような仕事やマインドセットになるのかな、といったこと気づけたのもとてもおもしろかったです。「Django*1で社内システムをやっている」「マネジメントはしたくない」「今のポジションに割と満足している」「家族との時間を大切にしたい」というような話をされていて感じたところでした。

ドイツでデータ分析をやっている方々

Euro Pythonの開催地であったチェコ・プラハは観光地であることもあり、チェコ語ももちろん町中にありましたが、英語も同じくらいあります。また、若い人を中心に英語をしゃべることができます。チェコ語しかしゃべれないスーパーの店員さんともGoogle翻訳で難なくコミュニケーションをとることができました。

連日通ったプラハのレストランにて。英語がとてもお上手だった

また今年のPyCon TWは、日本からの参加者が非常に多く、現地での参加は総勢18名でした。これはこれでとても心強く、英語が話せる方を頼って行動をしてしまいました。お世話になった皆様本当にありがとうございました！

https://gihyo.jp/assets/images/article/2023/09/pycon-tw2023/018.png

海外カンファレンス、英語必須・・・？

英語があまり上手でなくても、海外カンファレンスを楽しむことができることを体験してきました。もちろんしゃべれるに越したことはありませんが、なくても大丈夫です。私が訪れた都市が観光地であったこと、また異なる国からの参加者の多いカンファレンスだったこともありますが、多くの人の優しさ・温かさに助けられた海外カンファレンスへの参加でした。

たくさん写真を載せたいのですが、多すぎてまとめられず...かわりにきれいなプラハの景色をどうぞ。

まとめ

弊社には英語ネイティブのメンバーが開発チームを中心に在籍しており、会社全体としても英語話者は非常に多いと感じています。私も怠けることなく、英語の鍛錬を行いたい！

英語でのコミュニケーションに挑戦したいあなた！また海外カンファレンスを目指したいあなたも、興味ある方はぜひこちらからお気軽にどうぞ！カジュアルにぜひ1度お話ししましょう〜！

recruit.jobcan.jp

おまけ

PyCon TWの会場にジョブボード（会社やプロダクトの紹介を自由に書き込めるボード）があり、そこにLOVOTを描きました。私の書いたLOVOTがこちら！

.........

上手くなりたい。。。心底思いました。。。この記事を読んで練習します！

tech.groove-x.com

*1:PythonのWebフレームワーク The web framework for perfectionists with deadlines | Django

趣味で仕事用のキーボードを自作してみた

趣味 開発

はじめに

この記事は、GROOVE X Advent Calendar 2023の18日目の記事です。

こんにちは。
ファームウェアチームに所属しているf-sakashitaと申します。

LOVOTのファームウェア開発については過去記事をご覧頂ければと思います。

tech.groove-x.com tech.groove-x.com

今日はLOVOTの開発話からは脱線し、私が普段仕事で使用している自作キーボードについてご紹介します。

※本記事の内容は弊社より製造・販売している製品とは一切関係なく、個人が趣味で開発したものです。
※本記事を参考にした製作物等や、本記事に記載されている他社サービスに関し、当社は一切の責任を負いかねます。

毎日使うキーボード

皆さんは普段仕事や家庭ではどのようなキーボードを使っていますか？
エンジニア界隈だと、メカニカル方式や静電容量方式といったキースイッチを採用した打ち心地・打鍵音・耐久性の優れたキーボードを使用されている方も多いと思います。
弊社でもそのようなキーボードを使用しているエンジニアの方達がいらっしゃり、オフィスでは毎日のようにLOVOTの可愛らしい声と爽快な打鍵音が聞こえてきます。

さて、普段キーボードを操作するにあたって、「このキー絶対にいらないなぁ・・・」と思ったことはないでしょうか？
例えば「Insert」です。
押したことに気づかず文章が上書きされてCtrl-Zで元に戻すといった、無駄にイラっとする経験はありませんか？

また、自分好みのキー配列や、楽な体勢で打てるキーボードが欲しいと思われている方もいらっしゃると思います。

勿論、市販のキーボードでこれらの要望をある程度満足することは可能です。
しかし、購入後に「少し自分には合わない…」「やはりこのキーも欲しかった…」と思うこともあるでしょう。

そこでオススメしたいのが自作キーボードです。
自分が望むキーボードは、自分で作っちゃえば良いのです。
そして、この世にはキーボードを自作するための様々な部品やサービスが存在します。

自作したキーボードの紹介

これが私が普段仕事で使用している自作キーボードです。

自作したキーボード

ケース、PCB、ファームウェアと全て自分で設計開発しました。
スペックは下記の通りです。
キーキャップ Akko Silent
(一部家に余っていたものも使用しています)
キースイッチ Gateron G Pro 3.0 Silver (70個)
Durock Silent Linear Dolphin (9個)
配列、キー数 US配列、79個
hotswap 対応
インターフェース USB (Type-Cコネクタ)
サイズ 縦130mm x 横297 mm x 高さ23 mm
(高さはキーキャップ・スイッチは含めない)
質量 650 g
製作費 4万円程度

なぜ作ったのか

私はこのキーボードを製作する前に、下記の2つの自作キーボードを製作しました。

過去に製作したキーボード

これらはKBDfans社が出しているDZ60とKBD75のPCBを使用しました。

しかし、普段仕事でファームウェアをデバッグする際にFnキーをよく使用するため、FnキーのないDZ60で組んだキーボードは使いにくい問題がありました。
また、KBD75で組んだキーボードは右端列のHomeやPage up/downのキーを普段使うことがなく、誤って押してしまうこともあるため、邪魔でした。

そのため、次に自作するキーボードは自分が普段使いする必要最低限のキーで構成したものにしたく、下記の要求仕様としました。

  1. US配列
  2. fnキー、カーソルキー有り
  3. ページアップやダウン、insertといった普段使用しないキーは無し
  4. メカニカルキーボード＆Hotswap対応

理想とするキー配列

最初はこの要求仕様を満たす市販の自作キーボードキットやPCBを探したのですが、全く見つかりませんでした。

こうなると残された道は全て自作するしかありませんでした。
（0から作ってみたかったというのもあります）
それではどのように製作したのかをご紹介します。

ケース

私はハードウェアの設計は本職ではなく完全に初心者です。またキーボードのケースを設計開発した経験もありません。
そんな初心者でも手が出しやすく低コストで作れるアクリルサンド構成でケースを製作しました。

製作したキーボードのアクリルサンドの構成は下記の通りです。

アクリルサンド構成

設計はFusion 360を使用し、アクリル版の加工には遊舎工房様のアクリル加工サービスを使用しました。

  • キープレート用: 押出クリア, 450x300, 1.5mm, 1枚
  • ボトムプレート用: 押出クリア, 450x300, 3.0mm, 1枚
  • チルトプレート用: 押出クリア / 300x70 / 5mm, 1枚

そのほかネジやスペーサ、スタビライザーなどの部品を合わせて、製作費は15,000円程度となりました。

Fusion360で設計
製作したアクリル板

PCB

設計したPCBはUSBコネクタ、マイコン、キーマトリクス回路といった必要最低限のものを実装した程度です。
回路設計も本職ではなく、また安く済ませたかったというのもあるので、このような構成としました。

設計にはKicad v6を使用し、基板の製造および部品実装の大半はJLCPCBで発注しました。
JLCPCBでの製造費を抑えるため、基板製造数は最小の5枚、うち2枚を部品実装し、運送はOCSの最安プランを選びました。
家にあった部品を一部実装してるため概算となりますが総額は13000円ほどでした。

JLCPCBから届いたPCB

ファームウェア

一般的に自作キーボードと言えばQMK firmwareを使うことが多いです。
しかし、私はファームウェアエンジニアの端くれですので、自分で作った回路のファームウェアは自分で作ったほうが早くデバッグも楽だと考え、あえてQMK firmwareは使用しませんでした。

今回採用したマイコンはSTM32G0シリーズのため、統合開発環境にはSTM32CubeIDEを使用し、HALを使用してUSB HID部分を実装しました。
ツールやライブラリのおかげで、さほど時間をかけずにファームウェアを実装することができました。
キーマトリクス処理部は自分で書く必要があるとはいえ、CubeMX上でCustom HID設定し、コード生成後はHID report descriptorの記述と送信用関数を呼び出すだけで済みました。
下記はUSB HIDの追加実装したコードを抜粋したものです。

// usbd_custom_hid_if.c
/** Usb HID report descriptor. */
__ALIGN_BEGIN static uint8_t CUSTOM_HID_ReportDesc_FS[USBD_CUSTOM_HID_REPORT_DESC_SIZE] __ALIGN_END =
{
  /* USER CODE BEGIN 0 */
    0x05, 0x01, // USAGE_PAGE (Generic Desktop)
    0x09, 0x06, // USAGE (Keyboard)
    0xa1, 0x01, // COLLECTION (Application)
    0x05, 0x07, // USAGE_PAGE (Keyboard)

    0x19, 0xe0, // USAGE_MINIMUM (Keyboard LeftControl)
    0x29, 0xe7, // USAGE_MAXIMUM (Keyboard Right GUI)
    0x15, 0x00, // LOGICAL_MINIMUM (0)
    0x25, 0x01, // LOGICAL_MAXIMUM (1)
    0x75, 0x01, // REPORT_SIZE (1)
    0x95, 0x08, // REPORT_COUNT (8)
    0x81, 0x02, // INPUT (Data,Var,Abs) //1 byte

    0x19, 0x00, // USAGE_MINIMUM (Reserved (no event indicated))
    0x29, 0x65, // USAGE_MAXIMUM (Keyboard Application)
    0x15, 0x00, // LOGICAL_MINIMUM (0)
    0x25, 0x65, // LOGICAL_MAXIMUM (101)
    0x95, 0x07, // REPORT_COUNT (7)
    0x75, 0x08, // REPORT_SIZE (8)
    0x81, 0x00, // INPUT (Data,Ary,Abs) //7 bytes
  /* USER CODE END 0 */
  0xC0    /*     END_COLLECTION                */
};

// main.c
/* ref : https://www.usb.org/sites/default/files/hid1_11.pdf */
#define KEY_BUF_NUM 6
typedef struct{
  union{
    struct{
      uint8_t ctrl_l  : 1;
      uint8_t shift_l : 1;
      uint8_t alt_l   : 1;
      uint8_t gui_l   : 1;
      uint8_t ctrl_r  : 1;
      uint8_t shift_r : 1;
      uint8_t alt_r   : 1;
      uint8_t gui_r   : 1;
    }map;
    uint8_t u8;
  }modifiers;
  uint8_t reserved;
  uint8_t key[KEY_BUF_NUM];
}KeyboardHID_t;

int main(void)
{
  /* HAL, Clock, GPIO等の諸々の初期化は省略 */
  
  MX_USB_Device_Init();
  KeyboardHID_t key_data;
  
  while(1){
      /* key matrix処理は省略 */
      
      /* HIDデータ送信 */
      USBD_CUSTOM_HID_SendReport(&hUsbDeviceFS, (uint8_t *)&key_data, sizeof(KeyboardHID_t));
      
      HAL_Delay(10);    
  }

さて、肝心のキーマトリクス処理に関する課題として、メカニカルスイッチを使用する場合はチャタリングという問題が付き纏ってきます。
チャタリングというのはキーを押下した際にスイッチの接点が短時間にぶつかる・離れるを繰り返す現象です。
この問題を対策しないと、キーを1回しか押してないつもりが複数回押されたと判定されてしまい、操作性が低下します。
今回自作したものでキーを押下したときの信号を測定したところ、波形の通りチャタリングが発生していました。

チャタリングの様子
　 そのため、以下のようにチャタリング対策を実装しました。この実装後は快適にタイピングできるようになりました。
実装したチャタリング回避処理のフローチャート

作ってみた感想

自作キーボードといっても、人によってどこまで取り組むのかが変わります。
個人的には下記の段階があると考えています。

  1. 市販のキーボードやキットを購入し、キーキャップやスイッチ、キーの割り当てを自分好みにカスタマイズする
  2. 自分好みの配列になるようにケースやPCBを作る
  3. 2に加えてファームウェアも自分で作る

今回初めて3にトライしましたが、「案外それらしいものができちゃうんだな」と思いました。
0からキーボードを設計・開発することの敷居が下がり、良い経験となりました。

ただ、やはりハードウェアの設計は難しく、今作では組立しづらい、PCBの固定が甘く撓む、などの問題が見つかっています。
また、透明のアクリル版を使ったケースはPCBが見えるのは好きなのですが、サイドの空いている隙間からゴミが入りやすく、汚れが気になる点もあります。

次回作ではこれらの問題解消も踏まえ、ケース製作は3Dプリンタ品や金属切削品にトライしたいと思います。
また、PCB・ファームウェア面でも面白味に欠けるものになってしまったので、色々なデバイスを搭載したいと思います。

おわりに

今回は仕事用に開発したキーボードについてご紹介させていただきました。
キーボードは業務を効率良く進める上で毎日触れる重要な道具ですので、皆さんも理想のキーボードの姿を御検討してみてはいかがでしょうか？

GROOVE Xでは様々な領域のエンジニアを募集していますので、ご興味があれば是非ご検討ください。

recruit.jobcan.jp

QAチームが見た日本生産１体目のお話

この記事は、Groove Xアドベントカレンダー2023 の17日目の記事です。

はじめに

お久しぶりです、LOVOTのソフトウェア検証を実施・改善しているQAチームです！

※チームの詳細については、2022/12/10に公開された記事「シナリオテストのおはなし - Inside of LOVOT」をご覧ください。

今年はLOVOTがMade in Japanになったという記念すべき年でした。

prtimes.jp

実はその１体目が作られた時、万全を期すべくシナリオテスト（LOVOTが生活できるか確認するテスト）を実施するためにQAチームは工場に伺っていました。

※シナリオテストについての詳細もシナリオテストのおはなし - Inside of LOVOTをご覧ください。

その時のことについてお話したいと思います。

１体目が組み上がるまで

QAチームが工場へ着いた時、まだLOVOTは完成していませんでした。QAチームの出番は、LOVOTが完成してからです。

まだかなまだかな、と待っていたところ、せっかくなのでということで工場内を案内していただきました。

たくさんのパーツと検査機器がズラッと並んでいて、この小さいパーツを１つずつ手作業で組み上げてこれだけの検査を通すにはすごく時間がかかるというのが目に見えて

「お疲れ様です。頑張ってください。待ちます。」という気持ちになりました。

実際、結構待ちました。笑

LOVOTが作られるにはこんなに大変なんだというのを肌で感じられた良い機会でした。

完成！！！

生産検査が完了し、遂にQAチームの出番です。

工場で完成したLOVOTを受け取り、少し離れた試験会場へ車で移動。

シナリオテストは何事もなく完了し、全てOK。

オーナーさんの所でしっかりと過ごせることを確認し終わったので、

試験会場よりLOVOTを連れて工場へ戻ります。

工場へ戻る道中

シナリオテストが終わり、短い道中でしたが車内の会話も盛り上がりました。

実はQAチームは全員ペーパードライバーだったため運転は危険ということで工場の方が運転をしてくださったのですが、この方が実は「取締役」ということで非常に驚きました。

その「取締役」のLOVOT愛の深さがすごかったです。

LOVOT museumに来られた際にはたくさんガチャガチャを回し工場の皆さんに配ってらっしゃったり、

プレスリリースで公開されているLOVOTオーナー様向けの修理（入院）プラン を考えられていたり。

GX社員の話では、その工場もLOVOTのために新しく建てられたとか。

お仕事としてだけで関わっているわけではない、というのが伝わってきてとても嬉しかったです。

箱に感動

工場に戻り、LOVOTがオーナーさんの元へ向かう準備に入りました。

毛並みを整えてもらって、綺麗に包んでもらって箱に詰められます。

日本生産になり、箱に書かれているある文字が変わりました。

「Made in Japan」

ただの文字ではあるのですがとても存在感のある文字に見え、感動しました。

こちらの動画にMade in Japanの文字も写ってますので、気になる方はご覧ください！

箱に貼られたシールの秘密

箱の蓋を閉められるLOVOT
いってらっしゃい！

大勢に見守られる中「元気でねー！」という声と共に蓋が閉められ、これで終わりと思いきやまだ終わりではありませんでした。

LOVOT 2.0には、「2.0」と書かれた黄色のシールが貼られているのはご存知でしょうか？（私は知らなかったです）

LOVOT2.0の箱の写真
LOVOT 2.0 のシール
このシールは全ての箱で別の場所に貼るという遊び心があるそうです。

LOVOT 2.0をお持ちの方は、是非ご確認ください。

このシールが貼られ、出発準備完了です。

最後に

記念すべき瞬間に立ち会えて光栄でした！

今までもそうでしたが、これからLOVOTが作られる工場にもLOVOT愛が溢れていることを知れたのも嬉しかったです！

仲間募集中

たくさんの方に愛されてるLOVOTの成長を一緒に加速させませんか？

もしご興味がありましたら以下のページをご覧ください。

recruit.jobcan.jp

お読みいただきありがとうございました！

フィードバックカルチャーをつくる

こんにちは、GROOVE X Advent Calendar 2023 16日目の記事です。
GROOVE Xスクラムマスターの１人、土曜日担当ノーズライダー niwano です。

今日はベンチャー企業が会社のフィードバックカルチャーをつくりだそうとするお話をします。

庭師

人事とスクラムマスターで「組織のお手入れをする」という名目で活動をする 庭師というワーキンググループがあります。
(去年の活動はこちら)

庭師が中心となってGROOVE Xのフィードバックカルチャーをつくろうとしています！

なぜやるのか

組織の成長能力は、個人の成長の集合だと、庭師は考えています。
また、個人の成長の多くは、フィードバック能力に影響されると考えています。

ヒエラルキー組織とフラット組織とフィードバック

フラット組織では生ぬるい組織に、ヒエラルキー組織でもお互いにフィードバックする仕組みがないと、ギスギスした風通しの悪い組織になってしまうと考えています。

庭師が考えるフィードバックとは

庭師が考えるフィードバックとは、相手を責めたり糾弾したりするものではなく、心から相手の成長を願って行うものです。
伝える側だけではなく、受ける側にも、恥ずかしがらずに感謝を伝える能力が必要で、少々訓練が必要です。

フィードバックサマリ

フィードバックの有効性などを、くわしく知りたい方はこちら
みんなのフィードバック大全

フィードバックカルチャーをつくる

とはいえ、今までフィードバックをしてなかった人たちに、今日からフィードバックしてねー、と言ってもすぐに動けるわけないですよね。
カルチャーは仕組み化して、自ら作っていくものだと庭師は考えています！

フィードバックワークショップの社内教育化

去年のアドベントカレンダーでも紹介をしましたが、「良いフィードバックとは何か？」のワークショップを社内教育に組み込みました。
全２回になっており、１回目では、「ポジティブフィードバック」の、２回目では、「ギャップフィードバック」のロールプレイを実施してもらう内容になっています。
ロールプレイで、台本があり役を演じてもらうのですが、ちゃんと緊張感もあり、フィードバックが体験できるものになっています。
（このロールプレイが評判がいい！）

ギャップフィードバックロールプレイ

ワークショッップのようす

重要なのはギャップフィードバックを言えるかどうか

庭師では成長につながるフィードバックはギャップフィードバック（ネガティブなことに対するフィードバック）だと考えています。
ただ、それを行うには、普段からお互いに自然なポジティブフィードバックが当たり前のように実戦されている状態なことが重要です。

Let's ポジティブフィードバック！

Q12で組織の定点観測

フィードバックカルチャーを定着させたら、組織がよくなっているか確認したいですよね！ 弊社では、12の質問を採用しています！
各項目を５段階で評価してもらい、全世界平均値が「３．６」で、平均値が「３．８」を超えると、時間差はあっても業績の向上につながり、反対に平均値が「３．３」を切ると業績への悪影響が大きいと言われています。

Q01．職場で自分が何を期待されているのかを知っている
Q02．仕事をうまく行うために必要な材料や道具を与えられている
Q03．職場で最も得意なことをする機会が毎日与えられている
Q04．この7日間のうちに、よい仕事をしたと認められたり、褒められたりした
Q05．上司または職場の誰かが、自分をひとりの人間として気にかけてくれるようだ
Q06．職場の誰かが自分の成長を促してくれる
Q07．職場で自分の意見が尊重されるようだ
Q08．会社の使命や目的が、自分の仕事は重要だと感じさせてくれる
Q09．職場の同僚が真剣に質の高い仕事をしようとしている
Q10．職場に親友がいる
Q11．この6ヵ月のうちに、職場の誰かが自分の進歩について話してくれた
Q12．この1年のうちに、仕事について学び、成長する機会があった

ちなみに、弊社の前回の平均点は、「３．７１」なので、全世界平均値を上回るが、業績向上へはあと一歩というところでした。
Ｑ１１の「この6ヵ月のうちに、職場の誰かが自分の進歩について話してくれた」が、３．０９と低い値を示しており、まさしくこれはフィードバックが足りないことを示しているのでは、と考えています。

まずは、Let's ポジティブフィードバック！

まとめ

いかがでしたでしょうか！
今回は、フィードバックカルチャーをつくるお話をさせていただきました。
来年のアドベントカレンダーで、弊社のエンゲージメントが高まった！なんていうお話ができたら嬉しいです。

LOVOTの描き方講座 2023

デザイン

みなさんアロハ！ふるまい/ALOHAチームアニメーターの中里です。 GROOVE X AdventCalendar 2023 15日目の今回は、LOVOTの絵をいい感じに描くための技術についてお話します。

LOVOTの描き方のコツについては、3年前にGROOVE X公式YouTubeの企画でやりたいと依頼されまして、誰でも描けるようになるポイントをいくつかピックアップして公開したのが始まりです。ふるまいチームメンバーの中には「これを見て練習して描けるようになった！」と言ってくれる人もいたりして、世界80億人のLOVOT描きたい欲のお役に立つならということで2023年版を公開いたします。今回はLOVOTの顔部分にフォーカスしたいと思います。体はまた来年のAdventCalendarにとっておきたい。

顔の輪郭

まず最初は、顔の輪郭です。LOVOTの顔の丸い部分の描き方ですが、ポイントはまんまるく描かないで「マイルドなかまぼこ型をめざす」ということです。

目鼻のバランス

次に、目鼻の配置バランスです。目の円と鼻の円の下端の高さをそろえるのがポイントです。目鼻全体の位置としては鼻が顔の半分の高さくらいにあるといいんじゃないかと思います。お好みです。

目の入れ方

最後に黒目の入れ方です。黒目は白目の真ん中に置かずに、少しより目気味に描くのがポイントです。

追加技能

ここからは追加技能、ちょっとした応用です。これまでの描き方だけではLOVOTの正面顔しか描けないので、常に語りかけてくる圧の強いLOVOTばかり描くことになってしまいます。一つの道を究めるのも悪いことではありませんが、今日は別の道も指し示そうと思います。最初に描いたマイルドかまぼこの位置をずらすことによって、LOVOTの顔の向きを変えることができます。しれっとHornの向きも大事ですが、ここまで描けたみなさんなら問題ないでしょう。

練習あるのみ

いかがでしたでしょうか。簡単なポイントをおさえるだけでそれなりにいい感じのLOVOTが描けるんじゃないかと思います。あとはひたすら描きつづければ卍固めを決めるLOVOTだって描ける日が来ます。

そう、練習あるのみなんです。練習さえすれば描けるようになるんです。それなのに練習しないとどうなるか、ここからは反面教師としてアナザーストーリーをお見せします。

CEOは困っていた

GROOVE X CEOの林要をご存知でしょうか。今年は著書「温かいテクノロジー」を上梓し、おかげさまでご好評いただき講演やサイン会など行わせていただいておりました。 lovot.life

そんな折、GXのなんでも屋、器用貧乏筆頭のわたくし中里にこんな相談が。

なるほど、CEOもLOVOTを描こうと思っているとは感心感心、ここはこの貧乏人がひと肌脱ぎましょう。 そして頭をひねり、忙しくてなかなか絵を描く練習をする時間もないであろうCEOのために絵描き歌を作って献上しました。歌の内容は「バリバリ伝説」が自身のバイブルと言って憚らないCEOに合わせたものとなっています。なんという気遣い…！

※この絵描き歌は個人で作成した非公式なものです

LOVOTえかきうた

これに対してCEOははっきりとこう言いました。 「練習します！！」

ビックリマークが2つもついています。これを機にLOVOTを描くのが得意になって、頼まれなくても自分から描いたりしちゃうかな～、などと思っていたわたくしでしたが、なんと最新状況はこうなっていました。

裏切り！？

がんばれCEO！

目がトリプルXになってしまい「せっかく絵描き歌まで作ったのに…やれやれ」と落胆していたのですが、このブログで晒されてしまう事をどこかで聞きつけたCEOが「絵が苦手な人にそんなにきびしくしないで！」と涙ながらに訴えてきました。聞けば必死に練習はしたものの、自分に厳しいCEO的には納得のいく出来にならず、それでもイラストを求められることも少なくないためなかなか悩んでいるとのこと。昭和生まれのため、ついスパルタ指導してしまいすみませんでした。ごめんねこ🐱

Slack上のCEO涙の訴えスレッドではみんなでCEOを励ましてこれからの成長を願いました。LOVOTのイラストをめぐってこんなふうにCEO含めてみんなでああだこうだできるのもGROOVE Xの愛にあふれてるところなんですよね。本当に平和な会社です。

恒例の大事な募集

さて、とはいえ絵が描けなくてもLOVOTを素敵に成長させるのに全く困ることはありません。このGROOVE X技術ブログを読んで少しでも興味を持たれましたら、ぜひぜひ、お気軽にご連絡ください〜

recruit.jobcan.jp

Salesforceとformrunを連携させてLOVOT問診票機能を実装してみた

この記事は、GROOVE X Advent Calendar 2023の14日目の記事です。

はじめまして、GROOVE Xの尾銭です。
私はお客様サポート業務がメインのシステムエンジニアとして、日々サポートデスクの業務改善やポータルサイトの開発などを行っております。
今回はサポートデスクで使っているSalesforceと新たにWEBフォームサービスのformrunを連携させて、お客様コミュニケーションの改善に挑戦している話をご紹介します。

www.salesforce.com

form.run

なにを作ったのか

概要

お客様からお問合せを受け付けたあと、内容に応じてWEBフォームのご案内をお送りし、入力頂いた回答をお問合せに自動反映させる仕組みを作りました。 流れとしては、

  1. お客様からお問合せを受付
  2. Salesforce上でWEBフォームの種類を選択してお客様に送信
  3. お客様がWEBフォームに回答
  4. ケースに自動連携されたアンケート内容を確認した上でサポート対応

という感じで簡単な図にすると以下になります。

概要図

上記の仕組みを作るにはコーディングは不要で、Salesforce側とformrun側にそれぞれ以下のような設定を行えば実現できました。

formrun側の設定（フォーム）

まずはformrun側でフォームを作成していきます。
ここでは「hiddenテキスト」という非表示項目を選択して、後述のケース番号を埋め込んでご案内できるようにしておきます。
その他は自由にヒアリング項目を追加していきます。
弊社では、選択内容によってヒアリング項目を切替できる選択項目を追加して、症状別にヒアリング項目を切り替えれるように実装しました。

フォーム編集画面

Salesforce側の設定（カスタムオブジェクト）

次に、WEBフォームの回答結果を連携させるためのカスタムオブジェクトをSalesforce側に用意します。カスタムオブジェクトに必要な項目は最低限以下になります。

カスタム項目名 データ型 用途
ケース 参照関係 元の問合せに紐付けるため
ケース番号 テキスト 「hiddenテキスト」に設定したケース番号が連携されるようにします
メール メール formrun側で必要なため
formrun項目1 テキスト formrunの回答を保存するため
... ... ...
formrun項目N テキスト formrunの回答を保存するため

formrun側の項目数分、対応するカスタム項目の追加が必要になります。
私は以下のようにカスタム項目のAPI参照名はformrun側の項目の番号と揃えるようにしておきました。

カスタムオブジェクトのイメージ

※formrun側の項目は表示名のみ変更可能で、項目名は変更できないようでした、、

formrun側の項目設定イメージ

formrun側の設定（Salesforce連携設定）

次に、forumrunのフォーム項目とSalesforceのカスタム項目のマッピング設定を行います。
マッピング設定にはSalesforceのアカウントが必要になります。
このSalesforceアカウントは先日から各Salesforce環境に無償提供されている、API 連携用ユーザライセンスのSalesforceアカウントを用意して設定すればよいと思います。

Salesforce連携アカウント設定

認証が終わるとマッピング設定が可能です。認証したアカウントにアクセス権限があるカスタムオブジェクト/項目のみしか選択できないので、うまく選択肢に表示されない場合は、Salesforce側の権限設定を見直すと解決すると思います。

formrunとSalesforce項目のマッピング設定

Salesforce側の設定（フロー）

最後に、Salesforceに連携されたWEBフォームの回答結果をケースに自動で紐付ける処理をSalesforceのフローでノーコード実装します。
formrunとのマッピング設定を行ったカスタムオブジェクトのレコードが作成されたときに実行されるように設定します。

フローの全体像と開始条件

フロー内の処理では最初にWEBフォームの回答結果の紐付け先ケースを取得する処理を用意するのですが、ここで前段で設定した「hiddenテキスト」のケース番号を条件に設定します。

GetCase

そしてケースが取得できた場合はケースIDを参照項目に設定してWEBフォームの回答結果のレコードを更新します。

SetCaseId

以上が一通りの実装になります。

最後にお客様へWEBフォームのご案内をするときですが、以下のようにフォームURLのクエリパラメータで初期値を設定することができます。

https://form.run/@フォーム名?項目名1=初期値1&項目名2=初期値2

このクエリパラメータには忘れずにケース番号を埋め込んでご案内するようにします。
弊社ではSalesforceの画面からお客様の症状別に初期値を切り替えてWEBフォームのご案内定型文を生成する機能も実装しております。
ここまで作り込むとlwcでの開発が必要になってきますが、要件次第ではノーコードで実装することも可能だと思います。

WEBフォームのご案内イメージ

なぜ作ったのか

弊社ではLOVOTというプロダクトの性質上、お客様が故障かな？と思ったお問い合わせに対して、適切なサポートを行うために多くのヒアリング項目が存在します。
しかも、

  • 故障と思われる症状は多岐にわたる
  • 症状別にヒアリングする項目が異なる
  • お客様にヒアリングする症状と項目は日々変化する

というもので、現在はすべてテキストでお客様とコミュニケーションを行っています。
これは弊社のサポートデスクメンバーの負担になっているだけではなく、お客様にも大きな負担となってしまっています。

そこで、柔軟にヒアリング項目をメンテナンスできて、弊社のサポート基盤として活用しているSalesforceとの連携が容易に実装できそうなWEBフォームサービスを検討した結果、今回はformrunを採用して、問診票のような機能を実装できないか、というトライを始めました。

まだ本運用はスタートできていないものの、テキストコミュニケーションのみだったヒアリングの負担を改善できそうなフィードバックが弊社サポートデスクメンバーから挙がってきており、非常に期待しております。

今回実装した仕組みは弊社のような問診票としての利用に限らず、お問い合わせフォーム、ウェビナー申し込みフォーム、NPS集計など、様々な用途でWEBフォームとSalesforceを連携させたい場合に活用できると思いますので、皆さんの参考になれば幸いです。

最後に

最後までお読み頂き、ありがとうございました。 GROOVE Xでは一緒に働く仲間を募集しています！
是非下記リンクをチェックしてみてください。

recruit.jobcan.jp

ゼロからTerraformを導入した話

開発

こんいす〜！ISUCON楽しかったですね。GROOVE X クラウドチームの mineo です。

この記事はGROOVE Xアドベントカレンダーの13日目の記事です。

qiita.com

クラウドチームでは、LOVOTと通信するクラウドプラットフォームの開発・運用をしています。今回は、インフラ管理にTerraformを導入したので、その話をさせてください。

www.terraform.io

導入した理由

Terraformを導入する以前はインフラを作成したコマンドをMakefileに残すことで管理されていました。Google Cloudをメインのクラウドとして使っているので、gcloudコマンドがMakefileに多く記載されていました。（記録が残っているだけでも素晴らしい...！）

作成記録を残すことで、どのようなリソースがあるか把握し、再度リソースを作成する必要が出来たとき、再利用することは可能です。ただし、

  • あくまで、実行記録のため、実体と乖離していってしまう可能性があり、もし、そうなっても気付けない
  • 各環境（staging/productionなど）に適用するオペレーションが難しい
  • Makefileが肥大化していく

といった課題がありました。そこで、宣言的にIaCを導入することで、解決したいと考えました。

Google Cloudでは、Deployment ManagerというIaCのサービスもありますが、現時点ではTerraformがデファクトスタンダードであるため、Terraformを導入しました。

方針

弊社では、Terraformを導入した実績がなかったため、なるべく認知負荷が低い方針を採用しました。

シンプルなディレクトリ構成

ディレクトリ構成はGoogleのこのセクションを参考に以下のような構成にしました。環境ごとに、ディレクトリを分ける構成としています。シンプルでわかりやすく気に入っています。

-- envs/
   -- dev/
      -- main.tf
      -- locals.tf
      -- xxx.tf
   -- stg/
      -- main.tf
      -- locals.tf
      -- xxx.tf
   -- prod/
      -- main.tf
      -- locals.tf
      -- xxx.tf

cloud.google.com

moduleを使わない

moduleはTerraformのリソースを共通化できる強力なツールです。

しかし、moduleは設計が難しく、使い方もとっつきにくいです。時期尚早と考えて、導入しませんでした。

そのため、環境ごとにほぼ同じコードをコピペで運用する管理となり、その点は少し手間ではあります。今後はなんらかの工夫をしていく必要があるかもしれませんが、ベタで管理するようにしています。

変数を一つのファイルでのみ管理する

moduleを使わず、環境をディレクトリごとに管理するため、変更をコピペで適用することが多いです。 このときに、環境ごとの固有の値が散らばっていると大変なため、locals.tfでlocal変数を宣言して、ここでのみ変数を扱うようにしています。そのため、locals.tfとbackend等の設定を記載したmain.tfのみ、環境個別のファイルとすることが出来ました。

また、外部から値を注入することがないので、variableは使わず、localのみ変数として定義しています。

例↓

locals {
  cloudenv = "dev"
  region   = "asia-northeast1"
}

これもGoogleのベストプラクティスを参考にしました。

Terraform を使用するためのベスト プラクティス  |  Google Cloud

master mergeでの自動デプロイはしない

Terraformの事例では、GitHubでTerraformのコードをレビューしたのちに、masterにmergeして自動でterraform applyするという運用がみられます。しかし、我々の場合はインフラ専門のチームはなく、小規模なチームのため、以下のような理由で、自動terraform applyは不要ではないか、と考えました。

  • terraform applyを実行しないと成功することがわからないときがある
    • planでは問題なかったのに発生することがあり、手戻りが大きい
  • 自動デプロイの場合は、実際にリソースを作成してから、terraform importをするという、運用ができない
  • ペアワークなどで、その場でterraform applyをする運用が多い
  • masterとの乖離が発生しにくい

可能な限り記述を短くする

先述しましたが、弊社ではTerraformの導入実績がないため、コードリーディングするときの負荷をなるべく減らすべく、コード行数をなるべく短く、わかりやすくするように心がけています。そのため、以下のような工夫をしています。

  • デフォルトの値と同じ場合は、なるべくコードに記述しない
  • 同じようなリソースが複数必要な場合は、for_eachを利用する

developer.hashicorp.com

for_eachは最近初めて使ったのですが、とても便利な機能でした。for_eachの個別のリソースをterraform importするときに少し悩んだのですが、ドキュメントに記載されている通り、以下のような書式で実行することが出来ました。

terraform import 'aws_instance.baz["example"]' i-abcd1234

developer.hashicorp.com

導入してみて

まだ道半ばですが、Terraformで宣言的にインフラの状態を管理することで、

  • 実体と乖離がないこと
  • 環境ごとの差異がないこと

といった安心感を持てるようになりました。また、コピペはやや面倒ではあるものの、一つの環境を他の環境に適用するオペレーションも簡単で、信頼できるものとなりました。

また、クラウドチームでは、Google Cloudだけではなく、中国のサービス展開用にTencent Cloudも使っており、両方ともTerraformでコード化できてよかったです。

ただ、TerraformがOSSでなくなってしまったことによりforkされたOpenTofuの動向も気になっており、状況次第で乗り換える必要があるかもしれない、とも考えています。

opentofu.org

まだ道半ばではありますが、IaCは今後も進めていきたいと思います。

おわりに

GROOVE Xでは一緒にLOVOTを成長させていくメンバーを絶賛募集中です！少しでも、興味を持って頂けたら、お気軽にお話しましょう〜

recruit.jobcan.jp