シンクロ・フード エンジニアブログ

飲食店ドットコムを運営する、株式会社シンクロ・フードの技術ブログです

飲食店ドットコムの中で一番負荷の大きかった検索機能にOpenSearchを導入した話

はじめまして。開発部の深野です。
今回は飲食店ドットコムの中のスカウト対象者検索という、サービス内でも一番DB負荷の高かった機能にOpenSearchを導入したので、導入時に検討したことと導入結果を紹介します。

シンクロ・フードのエンジニアブログでは、以前にも求人飲食店ドットコムの求人検索という機能にOpenSearchという全文検索エンジンを導入したことを紹介したことがあります。そのため、OpenSearchについて詳しく知りたい方は是非こちらの記事を先にお読みください。

はじめに

以前、弊社で最も頻繁に利用される機能である求人サイトの求人検索機能に全文検索エンジンであるOpenSearchを導入し、その高速化を図りました。 その結果として求人検索機能の高速化とDB負荷の低減という結果を得られたので、今回は新たな課題に取り組むことにしました。
具体的には、弊社のサービスでMySQLへの負荷が一番大きかったスカウト対象者検索機能にOpenSearchを導入することで、データベースの負担を軽減し、検索処理のさらなる改善を目指しました。
多くの求人サービスにはスカウトという仕組みがあり、求職者の方から会社へ応募するだけではなく、会社の方から求職者の方へ向けて自社を受けてみないかどうか勧誘することができると思います。飲食店ドットコムのスカウト対象者検索機能もこのようなことを実現するための機能であり、求職者の方の職務経歴や希望する勤務地を検索して求人飲食店ドットコム会員をスカウトすることが可能です。

導入の背景

元々のスカウト対象者検索機能は、以下のような問題を抱えた実装になっていました。

  • 複数のテーブルにまたがる複雑な検索処理:一度のSQLクエリではなく、複数のSQL実行というステップを踏んで徐々に対象のスカウト対象者を絞り込む方式で実装されていた
  • ページング機能のためのフルスキャン:検索条件に合致する件数を取得するCOUNT(*)がフルスキャンしており、実行時間が大きくかかっていた
  • 正規化されていないテーブルとカンマ区切りのカラム:一部のテーブルでは歴史的経緯によりカンマ区切りのカラムが使用されていることから、FIND_IN_SET関数を用いた検索が行われており、パフォーマンス面の問題を起こしていた
  • フリーワード検索機能:部分一致のフリーワードが機能的に必要になったことで、LIKEによる部分一致の検索というパフォーマンス的にはあまり良くない実装が必要になっていた

これらから、アクセス量が増加するとすぐにデータベースのリソースを圧迫し、レスポンスタイムが著しく低下することがあり、最悪の場合システム障害につながることもありました。また、レスポンスタイムのさらなる劣化を避けるため、新機能の追加が一部制限されるという問題も抱えていました。過去にはOpenSearchを導入せずに高速化しようと試みたこともあったようなのですが、そのアプローチには限界がありそうなのでどうせこの問題に向き合う(=検索機能の再実装を行う)なら全文検索エンジンを利用したいという考えがあり、今回のOpenSearch導入に至りました。

MySQLからOpenSearchへのデータ同期方法

データ同期のためのシステム構成は以下の通りです:

システム構成図
システム構成図

検索のために必要なテーブルはスカウト対象者のテーブルやその関連テーブルを含めて11個ほど存在したので、それぞれにTRIGGERを設定しました。設定したテーブルにINSERT, DELETE, UPDATEがあると、キューテーブルにスカウト対象者テーブルの主キーをインサートします。rakeタスクは30秒に一度の間隔でキューテーブルをポーリングし、更新の必要のあるスカウト対象者をMySQLから取得した上でOpenSearchへの更新を行うためのJSONを作成し、OpenSearchに更新を行います。

更新待ちキューに関して、以前は各アプリケーションからAWSのSQSを経由してデータを送信し、rakeタスクでポーリングする方式を採用していました。しかし、今回はSQSは利用せず上で述べたような方法を選択しました。この方法を採用した理由は以下の通りです:

  • データ更新経路の多様性:弊社ではデータ更新経路が複数のRailsアプリケーション、複数のJavaアプリケーション、そしてトラブル発生時のデータメンテナンスのための生SQLに分かれており、各アプリケーションにキュー送信処理を組み込むのは実装のコストが大きい
  • 「枯れた」技術の利用:既存の確立された技術の使用により、新たなリスクを回避できる
  • ある程度のリアルタイム性:データ変更があった場合、即座にキューテーブルへの挿入が行われる
  • トランザクション制御:データの更新とキューテーブルへのインサート処理がトランザクション内で完結するため、整合性が保たれる

この方法を採用するにあたって受容したデメリットは以下の通りです:

  • DBシステムの複雑性の増加:トリガやコールバックを大量に導入することはDBシステムの複雑性を増加させるが、今回のトリガは変更があった時にログをインサートするだけなのでそこまで大きな問題はないと判断した
  • スケーラビリティ:トリガを利用する方法は更新が多くなるとスケールが難しいが、大量にレコードを更新するような処理が連続することは現在の弊社のサービスではあまりないので問題は起きないと判断した。
  • トランザクションによるロック:キューテーブルはINSERTとDELETEしか行わないテーブルではあるが、場合によってはテーブルにロックがかかりキューテーブルからのレコードの削除まで時間がかかることがあった(トリガによるキューのテーブルへのインサートを特定のバッチでのみ一時的に無効化することで対応できた)

今回は、他にもAWS Glueのような方法からAWS DMSやdebezeimなどのCDCまで、マネージドサービスを中心に色々な方法を検討していました。
特に注目していたのがMySQLのテーブルをキューとするのではなく、キューはAWSのSQSを利用して、Aurora MySQLの機能を利用してトリガからAWSのlambda functionをコールしてlambda functionからSQSにエンキューする方法でした。元々弊社ではキュー的なものを実装する時にはSQSを利用することが多く、この方法は有力な候補でしたが、lambda functionをコールしたトランザクションがCOMMITされた後にエンキューされるのではないことから本要件での利用は断念しました。一つのトランザクションの実行時間が長くlambda functionが実行される時に該当のトランザクションがまだCOMMITされていない場合や、該当のトランザクションが途中でロールバックした場合などに対応するのが難しいと思ったためです。

OpenSearchによる検索

スカウト対象者検索では、様々な検索条件に基づいて組み立てられたJSONを用いて、OpenSearchのsearch APIを通じて検索を行っています。具体的には、まずスカウト対象者の主キーをOpenSearchから取得し、その後、Auroraデータベースから表示に必要なデータを取得します。

元々の実装では、複数のSQLクエリを順番に実行して主キーを絞り込む実装になっていましたが、OpenSearchの導入により、検索プロセスが大幅に簡素化されました。具体的には、一回のOpenSearch検索で必要な全ての主キーを絞り込み、その結果を使用して迅速に検索対象のスカウト対象者のリストを取得できるようになりました。

今回は、既存のMySQLベースの検索機能をOpenSearchに移植し、その高速化に重点を置いています。OpenSearchの機能を最大限に活用すれば、これまで不可能だったより高度な検索機能も実現可能ですが、今回は元の機能の移植とパフォーマンスの向上に注力しました。

テスト中に発生した問題

テスト中に遭遇しましたいくつかの問題のうち、主な2つが以下になります。

1つ目はcompressionというオプションの適用問題です。
OpenSearchではデータ更新や検索リクエスト時にcompressionというオプションを使ってリクエストをg-zipで圧縮することが可能です。 今回はこれを有効にしようと思って開発を進めており、ローカル環境ではこの設定を有効にしても問題なく通信できましたが、設定の問題か何かでAWS上のテスト環境ではエラーが発生しました。
リリースの優先度を考慮し、今回はcompressionオプションの使用を諦め、圧縮なしでの通信を行うことにしましたが、将来的にはこの問題を改めて調査し、圧縮設定をオンにする予定です。

2つ目は、高負荷時の検索レスポンスタイムの劣化です。
前回のブログ記事「OpenSearch の導入による検索システム改善のための認証・認可設計と負荷検証結果」でも書いたのですが、OpenSearchではrefresh_intervalという更新内容を検索結果に反映するまでの時間を短くするほどパフォーマンスが劣化することは元々認識していました。
ただし前回の求人一覧のOpenSearch利用の際は、refresh_intervalをデフォルトの1秒のままでインスタンスサイズを増加させることでパフォーマンス問題を解決しました。 しかし、今回OpenSearchに新たなインデックスを追加し、再度負荷検証を行った結果、refresh_interval=1sで短時間に更新リクエストが大量に来る場合には一時的に検索のレスポンスタイムが著しく劣化することが分かりました。
そのため、今回新たにインデックスの更新リクエストが増えることや、今後さらに検索機能をOpenSearchに置き換えることまで考えて、既存のものも含めてrefresh_intervalを30秒以上に設定することにしました。

導入した結果

OpenSearch導入前後のスカウト対象者一覧のレスポンスタイムの日ごとの中央値の推移について紹介します。
まずは、検索条件を何も指定しなかった場合のレスポンスタイムの推移が以下になります。

レスポンスタイム
レスポンスタイム

10/18のリリース前は3秒強だったレスポンスタイムが0.5秒前後まで縮まりました。
検索条件を何も指定しなかった場合でも大きく改善しているのは、元々はページングのために検索結果にマッチする件数を取得するために数十万件のレコードがあるテーブルを複数JOINした上でCOUNT(*)を実行しており、そこがかなり負担になっていたのですがそこがOpenSearchに任せたことで数msで済むようになったのが大きいと思っています。飲食店ドットコムは20年ほど続いているサービスなので、実装時はパフォーマンスが問題にならなかったもののユーザー数の増加と共にパフォーマンス面で問題になるというケースが度々あり、今回もその一つでした。

次が、全文検索エンジンの本領発揮である、フリーワード検索を検索条件に含む検索の時のレスポンスタイムになります。

レスポンスタイム(フリーワード検索含む)
レスポンスタイム(フリーワード検索含む)

以前は1日ごとの中央値で6秒~12秒というレスポンスタイムでしたが、OpenSearch導入後は、検索条件がないときと同じ0.5秒ほどで推移しています。これはやはり元々が遅かったインデックスの効かないキーワードのLIKE検索を大きく高速化できたためだと思われます。また、フリーワード以外の検索条件を含んだものもここには入っているため、他にもFIND_IN_SETなどを利用したインデックスの効かない検索を高速化できたのも理由として大きいはずです。

導入した結論としては、以下のようになります。

  • 検索条件が何もない時でも実行時間の大きかった件数表示のためのCOUNT(*)をMySQL上で実行しなくて済むようになったことでレスポンスタイムが改善した
  • フリーワード検索を含むような複雑なリクエストは検索条件がない時に比べても大きくレスポンスタイムが改善した

まとめ

負荷軽減と高速化を目的に、スカウト対象者検索機能にもOpenSearchを導入しました。
更新方法についてはMySQLのトリガを利用して変更された内容をセミリアルタイムにOpenSearchに反映する形を取りました。
OpenSearchを導入した結果、検索クエリが単純な場合と複雑な場合で共にレスポンスタイムが大きく改善しました。
今回のスカウト対象者検索機能はMySQLでも改善が不可能ではないと思うのですが面倒な、COUNT(*)LIKEFIND_IN_SETをそれなりのレコード数のあるテーブルで利用しているページということもあり、OpenSearchの導入の効果は大きかったです。

シンクロフード新卒エンジニア研修の内容を大公開!基礎を固め、複数のサービスを支える一人前のエンジニアに!

まえがき

 こんにちは!シンクロフード開発部の23新卒宮城です。今年の7月末まで研修を受け、現在は、飲食店ドットコムの開発を行う「会員企画開発チーム」に配属され日々奮闘中です!

 本記事では、IT業界に興味のある学生さんやシンクロフードに興味のある学生さんに向けて、入社して3.5ヶ月間の開発部新卒研修の中から特に印象深かった研修内容をお届けします!ぜひ、最後まで読んでいただけると幸いです。

はじめに

 シンクロフードでは、主に事業部、開発部、管理部の三つの部署があり、新卒研修ではまずはじめに、2週間程度の全体研修を行い、その後、開発部だけ+3.5ヶ月の開発部研修を行います。開発部の研修では、フルリモートで行われるため、Slackを通してのやりとりや、毎日の振り返り会で進捗や不明点の相談を共有し合い、進めていきます。

 その中で、研修内容の豊富さはもちろんのこと、その一つ一つの内容が濃くとても勉強になったので、今回その魅力をお伝えしたいと思い、この記事を執筆させていただく運びとなりました。

 イメージしやすいように、ざっくりとしたエンジニア研修の流れをここで記しておきます。Web開発に必要な基礎的なGitの操作からシステム設計まで網羅的に組み込まれているためとても充実しています。

  • Git研修(1日)
    • Schooによる講義の受講
  • webの仕組み研修 (2日)
    • 社員の方による講義
      • リソースの設計について
    • 「webを支える技術」
  • SQL + DB研修 (5日)
    • 「SQL書き方ドリル 」 + 課題
    • 「楽々ERDレッスン」
    • 社員の方による講義
      • indexを張ることやexplainコマンドなど実践的な開発手法について
  • コンピュータの仕組み研修 (0.1日)
    • 社員の方による講義
      • OS講義(CPU, メモリについて)
  • プログラミング基本研修 (2日)
    • 「リーダブルコード」
  • マークアップ入門 (6日)
    • 「これだけで基本がしっかり身につく HTML / CSS / & Webデザイン1冊目の本」
    • 社員の方による講義
      • flexやgridの深掘り
  • Rails tutorial 研修 (5日)
  • インフラ入門 (8日)
    • 社内資料によるハンズオン形式
  • ソフトウェアテスト入門 (1日)
    • Schooによる講習の受講「ソフトウェアテスト入門 -1 ~ 4回目:テストの基礎-」 60分×4
  • RSpec入門研修 (4日)
    • 「Everyday Rails - RSpecによるRailsテスト入門」
    • 課題と社員の方によるレビュー
  • JavaScript入門 (2日)
  • セキュリティ技術研修 (2日)
    • SST(セキュアスカイ・テクノロジー)さんによるオンライン研修(動画と7月末に「はせがわようすけ」さんによるセミナー)
  • Github研修 (0.5日)
    • 社員の方による講義
      • 健康的なコードレビューができるPR(Pull Request)の作成方法
  • システム設計研修 (30日)
    • 内部システムを構築

研修内容に驚き

 私自身、入社してからの研修が1ヶ月程度で配属された後に、実践をこなしながら学んでいくものと思っていたので、ここまでがっつり網羅的に設計された研修内容を見た時は、驚きと共に、本当ありがたく感じました。これまで、ほとんど独学で学んできた私にとって、一緒に勉強できる仲間や頼れる人など周りにいなかったため、この研修は不安よりも早くやりたいなという気持ちで臨むことができました。

 実際に、研修全体を通して、私は楽しみながら、これまであやふやにしていた細かい知識などを再度学び、新たな技術や知識も理解することができました。エンジニアを目指す方にとっては、とても充実した研修内容になっているので、まえがきはここらへんにして、さっそく紹介していきます!

SQL + DB研修

 まず、初めに紹介するのはSQL + DB研修です!

内容 / 感想

 この研修では、書籍「SQL書き方ドリル」と「楽々ERDレッスン」を各々自分のペースで読み進めて行き、最後に社員の方による講義を受け、クエリやDB設計について理解を深めることができました

私自身、元々独学で勉強していたこともあり、簡単なクエリやある程度のテーブル設計などは理解しているつもりでした。しかし、いざ研修を受けてみると相関副問い合わせなどの複雑なクエリにつまづいたり、初見の関数に出会したりと、毎日新しく学ぶことが出てきて、キャッチアップが大変でした。 ですが、同期の新卒メンバーに相談したり、毎日の振り返り会でわからないところを社員の方に聞いたりすることで、詳しく教えてもらうことができ、しっかり理解し、またどういう場面で生かされるのか学べました!

この研修で、楽しかったのは、楽々ERDレッスンの内容で、日常的に我々が目にするメニュー表やレシートなどから、テーブル構造を考える訓練でした。どんなテーブルがあって、どんなカラムがあって、どのように結合しているのかを時間をかけて考えることで、答えを照らし合わせ、他のメンバーの解答と比較したときに、この人はこうやって考えるのかといったことや、DB設計って結構ビジネスの流れと密接に関係しているんだなというような考えや感想を得られました!

この研修を通して、主に身についたことは、複雑なクエリの書き方や読み方、テーブル構造を考察することや実際に作成すること、また、社員の方の講義による実践的なインデックスやexplainコマンドの使い方など多くのことを学ぶことができ、確実にレベルアップすることができる研修となってます!!

マークアップ研修

 続いて、紹介するのは、私が苦手意識のあるマークアップの研修です〜!私が単に、苦手意識があって、難しかったと印象に残っていたので取り上げさせていただきました!

内容 / 感想

  研修内容として、書籍「これだけで基本がしっかり身につく HTML/CSS&Webデザイン1冊」をまず始めに進めていき、その次に社員の方による講義を受け、Bootstrapの動画を視聴し、最後に実践的なマークアップの課題に取り掛かっていきました。

これまでに、何度か個人開発で、HTMLやCSSを書いてきたものの、あまり理解せずに、色々試して、うまくいったスタイルを採用してきたような私には、学ぶことが多く、毎日が奮闘でした!  しかし、書籍を通して、細かい部分を理解できたのと振り返り会や新卒メンバーとの雑談を通して、書籍では理解できなかったことや記載がなかったことなどを教えてもらい、なんとか着々と知識をつけていくことができました!

その他、CSS設計のBEMやSCSSなどの講義は初めて学ぶもので、馴染みがなく、新鮮な状態で学習に取り組むことがでました。理解していくにつれて、CSSもしっかり設計することで、保守しやすく、また初見の人が見ても、理解しやすくなるものなんだなと感動しました。

最後のマークアップの課題は、実際に業務で使用されたFigmaのデザインを実際にBEMとSCSSで記述するというもので、手を動かすことで、自分が書いたコードでサイトがどのように動くのか確認しながら進め、試行錯誤しながらデザイン通りに作成していくのは楽しく感じました!

この研修で大きく身についたと感じたのは、BEMとBootstrapとSCSSです!マークアップに、苦手の意識のあった私でも今では、配属されたチームでしっかりマークアップの要件をこなしていけているので、苦手な人もしっかり知識と技術を身につけることができるし、ある程度理解している人も、社員の方の講義や課題をこなすことで確実にマークアップスキルを伸ばせる研修になってると思います!

インフラ入門

 はい、やっときました!インフラ研修です!この新卒研修で一番楽しみにしていました!私自身、AWSの知識をつけたいと前々から思っており、今回実際に学んだり、手を動かしたりできるのと、社員の方のサポート付きなので、最初からやる気に満ち溢れて臨むことができました。

内容 / 感想

 研修の内容としては、Dockerの学習から始め、事前用意されたロードマップに従って、アプリケーションをAWS上に公開するというものでした。

Dockerは個人開発などでも使ったことがある人もいるのではないでしょうか?私も学生時代に個人開発でDockerを使用し、開発したりしていて、この最初のDockerの学習は割とすらすら学ぶことができました。

続いて、AWSの作業に入っていきます!AWSに関しては、ロードマップに従えば、うまくいくようにはなっていたのですが、途中で出てくるVPCやサブネット、EC2インスタンス、セキュリティグループ、インターネットゲートウェイなどの理解を私は以前触った時に全くしていなかったため、キャッチアップが少し大変でした…

その他にも実際に、AWS上で作業していくと、やはりよくわかっていない箇所で詰まってしまうもので、頭を抱える時間がロードマップの進捗と比例していきました。 しかし、ここでもやはり新卒メンバーの協力プレーが功を奏します。これまでの研修とは比にならないくらい頻繁にやり取りをしたり、リアルタイムで画面共有しながら、教えあったりしたことで、全員ロードマップ通りに実行できました。

今回の研修では、Dockerについて、細かいところを理解でき、アプリを簡単なインフラ構成でAWS上で公開することができるようになります!また、AWS上で公開するだけでなく、実はドメインの設定やロードバランサーまでロードマップに含まれているため、本当に内容の濃い研修でした。実際に、この研修の後、個人開発のアプリをAWS上で公開することができ、しっかり力をつけられたなと実感しています!

システム設計研修

 今回ご紹介するシンクロフードの新卒研修の内容も最後の1つとなってしまいました。最後に、紹介するのは、これまでの新卒研修で学んだことを十分に発揮でき、集大成となるシステム設計研修です!

内容 / 感想

 システム設計研修では、色々と手間がかかっている手続きや作業をシステム化して、使いやすくしようというもので、1人1つシステムを1から作る研修となっています!

今回、僕が担当したものは、GoogleGroup管理システムというものです。内容としては、これまでスプレッドシートとSlackを使用して、手続きを行なっていたメーリングリストへのメンバーの追加依頼、削除依頼、変更依頼などをシステム化して、もっと使いやすくするというものです。

使用するフレームワークはRuby on Railsで、仕様書/要望書をもらって、設計から開発まで行いました。始めは仕様書/要望書を熟読し、どのようなシステムかを把握することから進めていきました。そして、DB設計や画面設計、機能設計、工数見積もりなどをメンターの方からアドバイスをもらいながら進めて行きました!ちなみに、システム設計研修では、新卒1人に対して、社員の方が1人メンターとして付くので、マンツーマンで進めていく形になります!

ある程度、設計が終わると各自いよいよ開発に進みます。開発自体は、工数見積もりなどで順番を決めているのでそれに沿って、進めて行きます!ただ、実装方法までは設計段階では決めないので、詰まる箇所がいくつか出てきました。その際には、メンターの社員の方とのペアプロを実施したり、他の新卒メンバーと相談したりして、楽しく進められたし、実践的でRailsチュートリアルよりも理解が深まりました!

このシステム設計研修は、約1ヶ月の日程が確保されているため、本当に毎日開発をしながら、新しいことを理解していき、どんどん知識が増えていく感覚で、楽しくもありますが、大変でもありました。でも、実際に設計段階からレビューをもらいながら進めていき、システムの開発・テストなどを行い、本番環境にあげてしっかり人に使ってもらうものを1から作るということで、すごくいい経験になりました。

結び

この研修を通して、もちろん勉強面で満足感も十分にありましたが、他にも開発部の同期メンバーと活発にやり取りして、仲良くなれたのが大きかったかなと思います。実際に、開発部で飲み会をしたり、業務に関係ない雑談などしたり、プライベートでも関わるくらい仲良くなれたのは良かったです。

また、シンクロフードに興味のある方で、フルリモートということもあり、あまり同期と仲良くなれる機会がないのではと心配することもあると思いますが、シンクロフードの開発部研修では、先輩社員含め、同期のメンバーとは常に関わるので、そのような心配はなく、楽しく取り組めると思います。

実際に、この研修で培った知識は、配属後にしっかり使うことになります。私も配属された今、マークアップの要件でBEMやSCSSを使用してマークアップしたり、RSpecでのテストなど書いています。また、研修で扱わないことも配属後は触っていくので、日々新しい技術が学べる場となっています。

以上で、本記事の結びとさせていただきます。ご清覧ありがとうございました。

リモートワークで働くエンジニアの自宅デスク環境を公開!

こんにちは。
開発部の四之宮です。

突然ですが、弊社開発部ではフルリモート制度が導入されており、日本国内であればどこからでもリモートワークで勤務可能となっています。
元々はコロナ禍で居住制限付きで開始した制度でしたが、今年度に入り居住制限がなくなりました。在宅勤務手当もあります。
(リモート勤務が絶対ではないため出社することも可能です)

これに伴い、これまで以上に自宅のデスク環境を自分好みにする社員も多くなっています。
そこで、本記事では一部社員ではありますが、自宅のデスク環境を紹介していきたいと思います。

開発環境の紹介

ここからは、各々に書いていただいた内容を元に紹介していきます。
王道な人、工夫が見られる人、特殊な人、など様々なスタイルが集まりました。
また、リモートワークの頻度に関しても、100%リモート勤務、リモート勤務中心、たまにリモート勤務、など様々になっています。

大久保

こんにちは、CTOの大久保です。
僕は普段はオフィスに出て仕事をしていて、あまり自宅作業をすることは無いのですが、一応自宅の作業環境を紹介します。

デスクの横はこんな感じになっていて…

いつでもサウナに入れます。
仕事をして、気分転換にサウナ…みたいなことができます。(普段は家にいないですが…)
サウナ好きの人は、「水風呂は?」と思うかもしれませんが、一応、水風呂も冷やすことができています。

サウナや水風呂を構築するまでの顛末は、別途エンジニアブログに記載しようと思います。

周辺機器

キーボード

  • Iris キーボードを使っています。初期の Iris は ProMicro がもげたため、これは2台目です。
  • Iris にはいくつか rev があるのですが、これがどの rev か覚えていません…。Type-C で接続するところがちょっと新しい。

マウス

  • Rival 100 です。これは手が小さい人におすすめのゲーミングマウスだと思います。

マウスパッド

  • ARTISAN の飛燕を使っています。硬質な感じの素材感と滑りがお気に入りです。

ディスプレイ

  • 15年以上前に購入した EIZO のディスプレイを未だに使っています。
  • 当時で 11万円くらいしたのですが、縦にもできる高性能モニターでした。
  • 壊れない限り使い続ける予定。

越森

Mリーグの2023-24シーズンが開幕して麻雀をする時間よりも観る時間が増えてきた越森です。
雀魂で雀聖2に昇段してからもうすぐ1年で、昇段まであと少しのところまではいくので早く抜け出したいです。

ほぼリモートですが、仕事のための部屋がなくリビングの机で仕事をしているため、背景に生活感が出てしまっています。 また、家で唯一のPCデスクと言うこともあり、仕事が終わったら遊べるようにUSB切替器とディスプレイの入力切り替えを利用して、私物のMacbookとSwitchもつなげています。

周辺機器

キーボード

キーボードは REALFORCE のテンキーレスモデルをかれこれ10年以上使っています。
打鍵感が素晴らしく気持ちよくタイピングできるところが良いです。

マウス

マイクロソフトのエルゴノミクスマウスを利用しています。
本当に真ん丸なマウスで初めて使ったときは上手くクリックすることができなかったのですが、慣れてしまうとこれ以外は考えられないくらいに手にフィットして使いやすいです。
故障してもすぐに交換できるように常に1個は予備を持っているのですが、マイクロソフトの製品サイトに行っても掲載されていないので次の予備で最後になってしまうかもしれません...

マイク

少し音に拘ってしまうところがあり、マイクは SHURE の MV7 を利用しています。 高音質なダイナミックマイクになるとオーディオインターフェースが必要となってしまうことがあるのですが、 USB で接続できたりスピーカー出力端子を備えていたりと音質以外にも良いところがたくさんで満足しています。

大前

増え続ける積みゲーのリストとどう向き合うか答えが出せていない開発部の大前です。
最近はゲームを買う前に推定プレイ時間を考えて諦めることが増えたように思います。

周辺機器

昇降式デスク、キーボードトレー

最近、会社の方に要らなくなった昇降デスクを頂いたのと併せてキーボードスライダーも導入しました。
昇降デスクとキーボードスライダーがあると高さや前後の調整がしやすいので、椅子の肘置きや背もたれにしっかり体重を預けた姿勢が取れます。
またキーボードスライダーのおかげで天板上の物が減ってしたので掃除がしやすくなりました。
天板の上に物が無いので、iPadをさっと取り出してメモを取ったりできるのも快適ですね。

デスク配線

私物のゲーミングPCと仕事用のMakbook Proの2台を使っているのですが、マウスやディスプレイの切り替えのためにケーブルを抜き差ししたくないので配線には結構気を使っています。
直接PCに接続はせず、全てKVMスイッチを経由することでボタンひとつで使うPCを切り替えられるようにしています。

スピーカー系

YAMAHA THR10ii Wireless

デスク周りは実用性重視で選んでいるものが多いですが、スピーカーだけは見た目がかなり気に入っています。(アンプですが)
ギターを弾くときに使っているアンプをそのままPC用のスピーカーとしても使っています。
正直音質は並かちょっと悪いくらいですが見た目が気に入っているので使いつづけています。

イヤホン類は用途によって使い分けています。
左のイヤホンは耳を塞がず長時間つけていても疲れないので、通話用に使っています。
中央のAirPods Proは集中するときに耳栓代わりにしています。
右のヘッドホンは仕事ではほとんど使わないですが、プライベートでゲームしたりちゃんと音を聞きたいときに使っています。

(左)ambie サウンドイヤカフ
(中央)AirPods Pro(第1世代)
(右)Sony WH-1000XM4

四之宮

サーバーサイドの開発よりもマークアップや css 設計の方が好きなエンジニアの四之宮です。
リモート勤務になってから、少しずつ自宅の開発環境に投資しています。
エンボディチェアが欲しいですが高すぎて手が出ません。

デスクは120センチだと生活スペース的に厳しかったので、100センチの電動昇降デスクを使っています。
また、普段は右側のスペースにねんどろいどが並んでいますが、いろいろな権利が怖いので撮影のためにどけました。
めっちゃシンプルというよりも、多少ごちゃついているくらいの方が落ち着くので好きです。

周辺機器

キーボード

  • Helix
    • 自作キーボードはいくつか試しましたが、Helix のキーの数と配置が気に入ってずっと使っています
    • ただ、これによって通常配列のキーボードが全然打てなくなっています

マウス

  • MX Master 3 for Mac(MX2200sSG)
    • Mac の必要な機能が割りあて切れるので気に入っています
    • 仕事で操作するくらいになるとトラックパッドよりマウスがいい派です

リストレスト

  • HyperX Wrist Rest
    • さらっとしている質感がいい感じで、固さもちょうどいいのでおすすめです
    • 薄型のキーボードだと合わないと思います
    • ロゴの印字がなければ更によかったです(印字は別にいいけど凹んでいるため)

ディスプレイ

  • 34WL75C-B
    • 34インチの 曲面型ウルトラワイドモニター です
    • ちょっと古いので今は新しいモデルがでていると思います
    • 最初は画面端に違和感を感じましたが慣れるととても快適です

マイク

  • AT2020USB-XP + RODE PSA1
    • 少し前にマイクとアームの両方が壊れたので、ちょっと奮発して新調しました
    • マイクアームは外装不良のアウトレット品があり、定価の半額程度で購入できてラッキーでした
    • いいマイクアームは動作がスムーズでびっくりしました

スピーカー

  • YAMAHA SR-C20A
    • モニター下におけるサイズ感、3.5mm オーディオケーブルで接続可能、ある程度音質が担保できる、というものを選んだつもりです
    • 仕事中に音楽を流したり、PCからの通知音を流しています
      • Maker hart Just Mixer S を使って、スマホからの音楽とPCの音を同時にスピーカーから出力しています
      • 切り替えではなく同時に 2in1out みたいな状態にできるので地味に便利です

イヤホン

  • AfterShokz(現 Shokz)
    • 骨伝統イヤホンで音質はよくないですが、通話用なので別にいいか…という感じです
    • 周囲が静かでないならノイキャン付きのイヤホンがいいと思います
    • ヘッドホンや普通のイヤホンと比べると格段に疲れないのでいいです

椿

引越しをしたことで常連だった飲み屋に行けずアルコールの量が減ってきている開発部の椿です。

椅子に座った時に姿勢がものすごく悪く、腰とお尻が痛くなるのでハンモックで業務を行っています。
体全体に負荷が分散されるので腰とお尻も痛くならずに快適です。
※体感には個人差があります。

難点は周辺機器を置くスペースが全くないことです。
マウスもキーボードも置けないのでノートPCで作業をするしかないです。

ディスプレイとマイクは隣に置いている棚に固定してぶら下げています。

周辺機器

ハンモック

すさびハンモックを使用しています。
https://susabi.jp/
吊り下げることはできないので自立型のハンモックです。
全長が330cmあるので結構幅をとります…
https://susabi-shop.jp/SHOP/sbco-hmdb-set.html

ディスプレイ

ARZOPAの15.6インチモバイルモニターを使用しています。
棚から吊り下げられるものということで軽いモニターを選んだだけで特にこだわりはありません。

マイク

HyperX QuadCast S を使用しています。
こちらもそこまでこだわりはありません…
マイク上部(逆向きにしているので下部になりますが)をタップすることでミュートにできるのがとても楽です。

ヘッドホン

Philps の骨伝導ヘッドホンを使用しています。
長時間つけることが多く、ヘッドホンやイヤホンだと耳が痛くなったり、周りの音が聞こえなかったりしたので骨伝導ヘッドホンを使うようにしています。
こちらもこだわりは特にないです。

PC置き場

足の上にノートPCを置くので Yogibo の Traybo を使っています。
https://yogibo.jp/products/detail/trb2
ビーズがへたってきているのでそろそろ買い換えようかと悩んでいます。

番外編

ここからは番外編になります。
デスクワークにより肩こりに悩まされている方も多いのではないでしょうか?
そんな方に向けたグッズ紹介になります。

大津

今年新卒で入社した開発部の大津です。大学からずっと肩こりに悩まされて解消方法を模索しています。

1日中デスクで作業をする以上、肩こりに悩まされているエンジニアは多いと思います。
一応、昇降式デスクやオフィスチェア、モニターアームを使うことで肩こりをある程度避けることは可能ですが、完全には難しいです。(そして何より高価です)
そこで、今回は肩こりを解消するグッズをジャンルごとに紹介します。

グッズ紹介

塗る系

塗る系のグッズの売りとしては取り出してさっと塗るだけという手軽さです。効果はあんまりですが、忙しいけれど痛みが辛い時用に1個常備しておくことをおすすめします。

タイガーバーム

  • 100年前から使われているらしい
  • 香りや塗った感じはヴェポラッブに近いです
  • ちょっと塗るだけで結構スースーするので塗りすぎには注意

Arnicater GEL

  • ほんのりアロエのような香り
  • ジェルだが塗ったあとすぐ馴染むのでベタつかない
  • メンソール系が苦手な人に

貼る系

貼る系の特徴は効果が高く持続も長いこと。ただ一回あたりの値段はちょっと高め。

パスタイム温感プラス

  • 肌はひんやり、深部はじんわり温かい不思議な湿布
  • シンクロ・フードには日報という、その日行った業務を全体に共有するシステムがあるのですが、そこで肩こりの相談をしたところ先輩に教えていただきました。
  • 夏の日中に使うとさすがに暑いですが、寝る前に貼るといい感じにポカポカするので寝付きが良いというオマケ付き

押す系

押す系の特徴はただでさえ安いのにずっと使い続けられるコスパの良さと、辛いところにピンポイントで使えること。ただ腕がちょっと疲れるのと作業しながら使うのは難しい。

cocorave マッサージ 棒 2個セット

オカリナ型

  • 個人的に最強の肩こり解消グッズ
  • 多少重さもあり、手首の力でテコのように押せるので、指よりも圧倒的に強く押せる。
  • 先端の形状が違うので、平べったい面で撫でるように使ったり突起の部分で押したりできる

棒型

  • よりピンポイントに押したいときに。
  • ペン立てに入れておけばすぐに取り出しやすい

乗せる系

乗せる系は充電が必要だったり電子レンジで温める必要があったり準備が面倒ですが、しっかりリラックスしたい時におすすめ

La Luna ネックケア

  • 首のパッドから微弱な電流が流れるタイプのマッサージ機
  • パッドの温度調節や電流の強さ、リズムをリモコンで調節可能。さらにタイマー機能と音声ガイド付きの高性能(その代わりちょっと高い)
  • 週1ぐらいで使っていましたが半年ほど充電なしで使えました
  • ただ軽く電極を濡らさないとピリピリして痛いので、濡らすのが面倒な人は別売りのジェルパッドも購入することをおすすめします

あずきのチカラ 首肩用

  • 電子レンジで温めて繰り返し使えるネックピロー
  • パスタイム温感プラスと比べると持続時間は短いですがコスパは良いです。ただ肩用という感じなので首筋を温めようとすると安定しません
  • 温めるとあずきというかお汁粉の香りがします

まとめ

いかがだったでしょうか?
一部ではありますが、実際にリモート勤務しているエンジニアの自宅デスク環境をご紹介しました。
他では余り見ることのできない、変わっている事例も紹介できたのではないかと思っています。

最後に、シンクロ・フードではエンジニアを募集しています。
興味を持たれた方は、是非下記の採用サイトを御覧ください。

recruit.synchro-food.co.jp

ブランドリニューアルで行ったアプリアイコンの刷新

こんにちは。
モバイルアプリチームの小関です。

弊社が運営する「求人飲食店ドットコム」が行ったサービスブランドリニューアルの一環として、同サービスのモバイルアプリ版のアイコンをリニューアルしました。
本記事では、新しいアイコンデザインの選定過程と、iOSとAndroidのアイコン仕様の一部に触れ、開発者の立場でどのように関わってアイコンが生まれ変わったのかを紹介します。

サービス名とロゴの変更

まず、弊社が設立20周年を迎えるにあたり、コーポレートブランドとサービスブランドをリニューアルすることとなりました。
それに伴い、弊社が運営するサービスの一つ「求人@飲食店.COM」は、「求人飲食店ドットコム」へと名称を変更しました。
このブランドリニューアルについての詳細はこちらのプレスリリースでご覧いただくとして、そのサービス名の変更とともに、ロゴも新たにデザインされました。

<旧ロゴ>
旧ロゴ

<新ロゴ>
新ロゴ

アプリアイコンのリニューアル

求人飲食店ドットコムは、メインのWeb版に加えて、iOSとAndroidのモバイルアプリ版も提供しています。
私が所属するモバイルアプリチームは自分を含めて現在4人の構成で、その求人飲食店ドットコムのモバイルアプリをメインに開発しています。
このチームでは、開発・保守以外にも施策の発案なども行っており、ディレクターやデザイナーと積極的に連携して業務を行っています。

そして、このモバイルアプリのアイコンには、旧サービス名が使われていたため、アプリアイコンのリニューアルも進めることになりました。

旧アイコン
旧アイコン

まず、デザインを検討するにあたり、改めて世の中の様々なアプリアイコンを見比べるところから行いました。

求人飲食店ドットコムにジャンルとして近い飲食系サービスや求人サービスはもちろん、世間一般で多くインストールされているアプリのアイコンが、どういった構成なのかをディレクターやデザイナーと確認した結果、大枠として以下の3つの分類から検討することにしました。

① 旧アイコンと同様のテキストのみのパターン
② 新ロゴに使われているシンボルのみのパターン
③ 1と2を組み合わせた、テキスト+シンボルのパターン

アイコン候補

他社アプリにおいて②のようなシンボルのみのパターンは、ブランドアイコンとしてそのシンボルの認知が十分にあるか、単体でもはっきりと意味が伝わる場合において、多く見受けられました。

また、求人系サービスではとくに、シンボルやサービスが持つキャラクターなどとサービス名などのテキストが混ざった③のパターンが多かったこともあり、方向性としてはサービス名は最低限入れた①か③のパターンで進めることになりました。

その後、iOS・Androidのそれぞれのアイコンデザインに関する仕様やガイドラインも考慮した上で、デザイナーがいくつかのバリエーションのデザインを作成して、最終的にはそこから最適なものを選ぶというが今回の全体の流れでした。

様々なバリエーションアイコン

(実際に作成した様々なバリエーション)

その流れでアプリアイコンを作成・選定するにあたって、公式のガイドラインや出力時の仕様などは開発側からデザイナーへと共有しつつ進めていたのですが、デザインを選定する上で、それらが制約になる部分が出てきました。

例えば、iOSでは1024px × 1024px の正方形のアイコン画像を用意する必要がありますが、ストアやホーム画面では自動的に丸角加工で切り取られるようになっています。
また、Androidにおいてもアイコン画像のガイドラインで外側に余白を作ることが推奨されています。
それらを考慮しつつ文字を詰め込もうとすると、字数によっては視認性が悪くなってしまう課題などが出てきます。

Google Play アイコンのデザイン仕様  |  Android Developers

さらに、Androidには多くのデバイスモデルが存在するため、デバイスモデルごとで異なる様々なアイコンの形を表現可能にする仕組みとして、「アダプティブアイコン」と呼ばれるものがあります。
アダプティブアイコンは、フォアグラウンドとバックグラウンドの2つのレイヤを用意することで、視差効果や縁取りのマスクをOS側に任せることができ、アプリアイコンの縁取りの仕様が四角型であっても丸型であっても正しく表示することができます。

※引用元: アダプティブ アイコン  |  Android デベロッパー  |  Android Developers

デバイスモデルによっては、非線対称の縁取りによってアンバランスなデザインになってしまうのですが、デザインの検討の中で「なるべくそれは避けたい」といった意見も挙がっていました。

(これだけのバリエーションがデバイスモデルによってある)

これらの仕様を考慮しつつ、既存ユーザーが混乱せず、どのようなデバイスモデルやOSであっても視認性が悪くならないようなデザインを採用するという方針で進め、最終的には新ロゴの白地をベースにはしながらもサービスカラーのアクセントが入った以下のシンプルなアイコンへと決まったのでした。

新アプリアイコン

最後に

このように、アプリアイコンを作成するにあたっては、開発者が意識的に情報を共有すべき部分もあり、アプリ開発の関係者同士の連携がより重要だと感じました。
今後の開発においても、ディレクターやデザイナーとの連携を取りながら、多くの人が使いやすいアプリを作っていきたいと思います。


最後に、エンジニア募集のお知らせです!
シンクロ・フードでは、まだまだ技術的な課題やチャレンジが残っています。 ぜひ、一緒に改善していきましょう!

また、飲食店ドットコム、求人飲食店ドットコムを始めとしたサービスの開発・改善も、どんどん進めております。
ご興味のある方は、以下の採用サイトからご連絡ください!

recruit.synchro-food.co.jp

RubyKaigi 2023振り返り。僕が学んだ「初対面な人に恐れず話しかける大切さ」。【後編】

こんにちは。シンクロ・フード開発部の横山朋玖です。

twitter.com

今日の記事は、RubyKaigi 2023に参加した横山のRubyKaigi 2023の参加レポートになります。
なお、こちらの記事は後編になります。後編では、前編には書ききれなかったRubyKaigi 2023での多くの出会い、出会いを通して学んだこと、得られた経験、そしてRubyKaigiの素晴らしさなどをありのままに書き記したレポートになります。

一方前編では、RubyKaigiとは何か、RubyKaigiに参加した動機、RubyKaigi 2023で印象に残ったセッションや、技術的に刺激を受けたことなどを書きました。
よければそちらもご覧ください。

一日目: 多様性の実感

前編でも触れたように、RubyKaigi 2023には多くの開発者が世界中の様々な場所から参加されました。
一日目で最初に感動したことは、会場に到着し、耳をすませば外国語が聞こえることです
しかし、私は東京に住んでいるので、原宿や新宿で多くの外国人を見ることはよくありますし、外国人自体に不慣れというわけではないので、外国人が英語を喋っていることに感動した訳ではありません(笑)。
また、私が参加している英会話スクールにて今まで外国人とは沢山話した経験がありますので、外国人がそこに居ることも特に違和感はありませんでした。

なぜ私が感動したのかというと、「このRubyKaigiの会場にいる全ての人がRubyを知っていて、Rubyを使って日々何かしらの課題に取り組んでいる開発者」であるということを知っていたからです。
Rubyという言語は世界中の壁をまさに壊している力、Rubyのインパクトを実に感じましたし、このカンファレンスで繋がれる『開発者』は日本人に限定されないということを知り、とても感動しました。

そして、参加者の出身国に多様性を感じると同時に、「RubyKaigiの楽しみ方」にも多様性を感じました。

私がRubyKaigi 2023にてお話しした日本人開発者の方の中には、人事の方や広報の方(直接的にRubyを使ってはいないが、開発者の採用のために、広報のためには知っておくべき、という風に考え参加されている方など)も多くいらっしゃいました。
また、フロントエンド専門のエンジニア*1も居ました。元Rubyエンジニアであったり、何らかの形でRubyを実際に使っている方を除き、そういった方はセッションに参加しても内容を理解するのは難しかったかもしれません。

しかし、セッションに参加することだけが、RubyKaigiの楽しみ方ではありません。
ブースに滞在したり、多くのスポンサーが開催していた飲み会に参加したりと、参加者と様々な形で交流することでRubyKaigiを楽しむこともできます。

rubykaigi.org

他にも、私が出会った方の中には例えば元教員で現在エンジニアになって働いている方、元天文学者で、現在エンジニアになるために勉強中の方などがいらっしゃいました。
色々な方がいるものの、RubyKaigiには十人十色な参加者全員が楽しめる手段があると感じました。 実際、私の出会った参加者の全員はRubyKaigiを思う存分楽しまれている方しかいませんでしたし、私ももちろん楽しむことができました。

そして、私は実はRubyKaigi 2023が初めて参加した技術系イベントでした。
そのため、前編でもあげたように「RubyKaigiで刺激を得て何かしらのモチベーションにしたい」という気持ちもありつつ、
「他社に従事する、私とは違う世界で活躍中の開発者の友達が欲しい(人脈を広げたい)」とも思っておりました。そのためセッションも、ブースの催し物も、スポンサー企業が主催する飲み会も思う存分参加させていただき、三日間を通し多くの出会いを楽しみました

開発者Jeremy Evans氏との出会い

ところで2023年春、Kakutani Shintaroさんにより、Jeremy Evans氏によって著された「Polished Ruby Programming」の日本語訳版である、「研鑽Rubyプログラミング」と呼ばれる書籍が販売されました。執筆時点、ラムダノートを初め、AmazonなどのECサイトにて入手可能です!

研鑽Rubyプログラミング ― 実践的なコードのための原則とトレードオフwww.lambdanote.com

書籍の発売日がRubyKaigi開催日に近かったということもあり、RubyKaigi一日目のお昼頃、Kakutani Shintaroさんにより「研鑽Rubyプログラミング」が会場で販売されていました。そして同時に、Jeremy Evans氏によるサイン会も開かれました!

私は、原著の「Polished Ruby Programming」は未履修なのですが、Kakutani Shintaroさんによって翻訳された日本語訳版は、β版*2の頃から読ませていただいてました。
研磨Rubyプログラミングを読み、日本語訳を通じてではありますがJeremy Evans氏のRubyへの熱いこだわりを知り、「いつかお会いしたいな」と思っていた矢先のこと、まさか参加したRubyKaigiでご本人にお会いできるとは思ってはいませんでした。
(サインもいただきました。本当にありがとうございます!)

Jeremy Evans氏にサインをいただいた本
Jeremy Evans氏にサインをいただいた本

このサイン会ではJeremy Evans氏とはあまり長時間お話はできませんでしたが(サイン会には長蛇の列ができていた)、自分が一方的に知っている開発者に直接お話しできる機会はとても素敵な経験だなと思いました。参加しなかった、お会いしなかったら絶対に得れなかったような開発のモチベーションにつながりましたし、(実際には何も変わってなくても)心理的にRubyコミュニティと自分の距離はグンと縮まりました*3

一日目終了: オフィシャルパーティーでの出会い

RubyKaigiの一日目が終了したと思いきや、まだまだ実は本当のRubyKaigiは終わりません。
一日目のRubyKaigiが終わった後は、RubyKaigi運営主催のOfficial Partyイベントに参加しました!参加者総人数は約500人ほどでした。
とても多くの方が参加されているイベントでしたので、自分の強みの英語を活かし、多くの海外Ruby開発者と交流させていただきました。
例えば交流させていただいた方の中には、三日目にセッションを開かれたSelena Small氏、Rubyコミッタの方、オーストラリアにて開発を行っている開発者、日本に住みながらも海外の会社でリモートワークしている開発者の方などがいましたが、みなさん様々な場所で活躍されているRubyistでした。なので、会場での会話の多くは自己紹介、Rubyに関するものがほとんどでした。

ところで、私は全くOSS貢献の経験がないのですが、理由は何となく「OSS貢献している開発者は自分よりもレベルが数段上で、自分のコードなんてpushしたらコントリビュータの気を悪くしてしまう。」と思っているからでした。(笑)
また、仮にpushするにしても、私の脳内で、レビューしてくださるOSSコントリビュータが「こんなコードは受け取れねえ。10年修行して出直してこい」と言っているかのようなことを想像してしまいます。OSSの世界は足を踏み入れるには怖すぎる世界であると想像していました。

しかし、私はOSS貢献をずっとしたいと思ってはいましたので、この機会に会場でお会いしたRubyコミッタに、
「あなたも最初は同じ気持ちを感じていましたか?その恐怖にどのように打ち勝ちましたか?」ということをお尋ねしてみました。
お尋ねした彼は、「自分はたくさんのミスをしてきたし、最初は同じように恐怖を感じていたけど気付いたら無くなってた。その恐怖に打ち勝つには失敗を沢山するしかないと思う」という風にアドバイスをしてくださりました。

今までずっとRubyコミッタはどれだけ努力しても手の届かない開発者、まさに「神」のように感じていたし、私はそんな存在になれるのかと思っていましたが、こんなに言われるとOSS貢献できるかできないかは、最初の恐怖を拭い切る力を持っている自分次第だと思い、十分に可能性がある世界だと感じました。

そして、「OSSへの貢献の始め方」も教えていただきました。
例えば彼には、闇雲にOSSに貢献するのは難しいので、最初は自分が見つけたバグ、こんな機能があったら良いなという願望をモチベーションにしてPR/Issueを作ってみること、RubyよりもRailsの方が貢献しやすいと思うといったアドバイスをいただきました。本当に参考になり、OSSへのモチベーションがグンと上がったことを覚えています。
この言葉は再三にはなりますが、このような、普段生きている中では起こり得ない出会いがある、アドバイスをいただけるRubyKaigiはやはり素敵なカンファレンスだと思います。

そして、オフィシャルパーティは二時間半にもわたる長時間のイベントでしたので、会場にいる多くの方と交流する十分な時間があり、目に入った全ての海外出身者らしき方にお声がけする勢いで会場を回っておりました。(笑)
その中でも特に良き出会いだったのが、Akhil, Victoria, Jaredという開発者との出会いでした。彼らとは二日目、三日目に渡って行動を共にするRubyKaigi一番の友達になり、彼らは私のRubyKaigiを華やかに、素敵な時間へとしてくれた開発者でした。話をする中で皆が良き開発者であると同時に、よき聴き手であることに気付き、彼らにはとても魅力を感じました。

オフィシャルパーティにて出会ったAkhil(男性), Victoria(女性)との写真
オフィシャルパーティにて出会ったAkhil(男性), Victoria(女性)との写真

ここでは語りきれない濃い時間を会場で出会ったたくさんの友達と過ごしましたが、やはり文章にすると文章量が膨らみ過ぎてしまうので、こちらで一日目のレポートは以上にしたいと思います。

二日目: 日本人のRubyKaigi参加者の中で一番楽しんだ日

day2がやってきました。この日は、僕が日本人の中で最もRubyKaigiを楽しんだと思っています。それぐらい濃密な一日でした。一体何が起きたのでしょうか?

Samuel Williams氏との出会い

二日目は、Samuel Williams氏という方にお会いしました。彼とは一日目に会場内で少し会話させていただき、名前は覚えていたものの、どのようなことをされているのか、どのような開発者であるか、といったことは聞けていませんでした。
しかし、ひょんなことからホテルにて、彼が私の尊敬していた開発者の一人であることに気づきました。
実は彼のGithubは前からフォローしていましたが、Githubのアイコンが本人の写真ではなかったので顔と名前が一致していませんでした。
一日目の夜にその事実が判明したため、私の興奮は加速し、一日目はそれで全く眠れなかったことを覚えています。

一日目の夜から二日目に彼と話すべく脳内シミュレーションを繰り返し、二日目。会場に到着してから彼を見つけ、お話しさせていただきました。
もちろん顔はわからなかったので、私の尊敬している開発者と同姓同名の可能性もありましたが、結果的にそんなことはありませんでした。

「人違いだったら申し訳ありませんが、もしかして〇〇という機能を作った開発者ですか...?」と聞いた私に、彼は「俺だよ!」と答えてくださいました!
そして実は、私が話しかけたタイミングはちょうどお昼時だったので、少しの会話の後、彼の方からお昼ご飯に誘ってくださいました!!憧れの開発者と隣でご飯を食べれるなんて、これ以上に素敵なことはないです。先日オフィシャルパーティーでお会いしたJaredとAkhilも誘って松本名産のお蕎麦を食べに行き、色々な会話をしました。

Samuel Williams氏、Jared、Akhilとのランチの様子
Samuel Williams氏、Jared、Akhilとのランチの様子

お蕎麦屋さんでは、プライベートなお話も沢山しましたが、覚えているのは、三日目に控えている彼のセッションに関する話です。実は、彼は三日目のセッションの発表者なのです。前編の記事には彼の発表のレポートも書きましたので、是非そちらもご覧ください。

rubykaigi.org

お蕎麦屋さんでは、彼が「発表練習は全くしていない」と言っていたことをよく覚えています。(笑)
しかし三日目、わかりやすい速度での説明、端的な説明、十分な情報量を全て兼ね備えた、完璧なプレゼンを披露していました。すごすぎる。

この貴重な経験を通して彼のことがもっと好きになりましたし、話の中で、彼の人柄を知ることもできました。当然この経験もまた、RubyKaigiに参加してなければ絶対に経験することのできなかった経験です。本当に心から、このイベントに参加して良かったと改めて思いました。

二日目終了: ビールを楽しみにビアバーへ!

二日目が終了しました。前のセクションとこのセクションの行間には語りきれない思い出があったのですが、全てを書けないことはとても残念です...。 しかし、二日目終了後の話はなるべく多くを書いていこうと思います。
二日目終了後、JaredとAkhil、新しく出来た友達数人とともにビアバーに向かうことになりました。
実は、一日目のアフターパーティーにて、JaredとAkhil、Victoriaに、二日目の終了後カラオケに行くことを誘っていただき、今日の夜はカラオケに行くことになっておりました。そのため、ビアバーにはカラオケ予約時間までの時間潰しのために向かうことになったのです。

現地では、二日目に発表されていたスピーカーの方をはじめ、この地でも多くの海外開発者に出会いました。
そして、私の人生に光を照らしてくれたある開発者にお会いしました。Stan氏との出会いです。

ビアバーにて出会ったRubyistにいただいたたくさんのアドバイス

Stan氏は、Shopifyに従事されている台湾出身、現在はイギリス在住の開発者です。
彼は、アジア圏出身という点で私とは同じですが、言語や国籍に捉われない多くの経験をされ、現在は海外でのキャリアを積まれている開発者という点で私が手を伸ばしても全然つま先にも届かない彼に、多くの魅力を感じました。
実は、私の将来の夢もまた、海外で従事する開発者になることなのです。そこで、たくさんのアドバイスを求めました。
「自分も貴方のようになりたい。貴方は素晴らしいし、いつかあなたのようになりたい。」すると彼は、自分がどのように国籍の関係ない「great developer」になるために開発に向き合ったのかをお話ししてくださりました。

世界が求めるのは、英語力などの言語の力だけではなく、自分が行った開発について「なぜその開発をしたのか?なぜ機能を作成したのか?」「他に考えられるアプローチはなんだったのか?」「その中で、なぜそのアプローチを選んだのか?」を考えられる開発者だと思う

国籍の関係ない素晴らしい開発者になるためには、たくさん経験を積んで、そして、自分が興味を持てる領域を見つけることに取り組んでほしい。

英語コミュニティに参加して、バグについてたくさん議論してみてほしい。自分の母国語のコミュニティの方が居心地はもちろん良いけど、もし英語コミュニティで議論をし続ければ、いつかそれは、言語の壁を超えた君のコミュニケーション能力を証明する材料になる。母国語コミュニティは英語コミュニティで解決できなかったりした場合だけ頼ってみてほしい。

そして、OSSにたくさん貢献する。もしくは自分がOSSを作る。それを何年も続ければ、必ず君は良い開発者になれる

今の私にとって、このStan氏のアドバイスは「今後数年もらうアドバイス全ての中でも一番価値のあるアドバイス」であると言っても過言ではないと言える、とても価値のある言葉でした。そして彼自身もまた、そのように開発に向き合ったのだと言葉に重みを感じた私は思いました。
素晴らしいアドバイスをいただいたものの、私には先の見えない戦いです。でももし彼を信じ、自分を信じ、開発に向き合い続けたら、必ず彼のようになれるということも私には解りました。

Stan氏のアドバイスによって文字通り、今まで見えなかった世界が一気に見えました。 そして、自分の目指すべき道がもっと明確になりました。
今後努力を続けて彼のような、国籍を問わない素晴らしい開発者になり、いつか彼と一緒にお仕事ができるぐらいの力が身についている自分の未来を今はただ信じ、邁進し続けます。Stan氏、本当にありがとうございました。

幹事をあまりしたことのない私が総勢25人以上のカラオケパーティーの幹事になった話

カラオケの予約時間がやってきたので、カラオケ会場に向かいます。
二日目終了後、実はカラオケの予約は日本人である私がしたのですが、その時点で参加者は約17人ほどであることは分かっていました。特に幹事になる意識はなかった(予約だけ私がやって、あとは任せるつもり)でしたが、カラオケ会場に二日目終了後到着した際にその場にいた人は9割5分は外国人だったこと(店員さんとのやりとり担当も自分が適任)、結局予約者が幹事になることはよくある流れだとは思います。最終的には私が幹事をすることになりました。

しかし、日本人だけのパーティーでもそれだけ多くの方をまとめる幹事をしたことは無かったですし(精々10人程度のパーティーを仕切った経験しかなかった)、自分の英語力がやや高いとはいえ、お金や諸々の業務連絡を適切に行えるかはとても不安でした。例えば、カラオケの料金体系・カラオケ自体の仕組みの説明なども必要でしたが、日本語でも正しく説明できるか怪しい理解度でしたので当然英語で...となるとかなり大変になりそうなことは容易に想像できました。

さて、カラオケ会場に着いたら前述したように、まずは周りにいる参加者の方全員に声を張って料金や仕組み(特に、アルコール飲み放題やソフトドリンク飲み放題)の伝達を始めます。自分もあまり詳しくないので、適宜日本語で店員さんに詳細の仕様を尋ねては、それを英語に即翻訳し参加者に伝達する、まさにあの日、自分は翻訳機でした。(笑)
ここの伝達、相談などを諸々合わせ10 ~ 15分ほどフロントでバタバタしてしまいましたが、なんとか部屋をゲットすることができました!しかし、仕事も一段落したと思いきや、まだまだやるべきことは山積みでした。
実は、日本のカラオケでは一部のカラオケを除き、基本的に、部屋についているフロント直通の電話で飲み物や食べ物の注文をすることになっています。
勿論、飲み放題を頼みたい方はたくさんいますので、日本語ができる私がオーダーを聞きまわり、電話をかけ、オーダーを聞きまわり、...という対応をして、歌う暇が全くなかったことを覚えています。

30分ほど入室してから時間が経つと、ようやく飲み物もまわり、色々と落ち着いてきました。ホッとしたのも束の間、実は新しい参加者がどんどんと入室し始めてきました。新しい参加者というのも、カラオケ参加者によってシェアされたカラオケの様子が、SNSの力によって瞬く間に広がり「自分も行きたい」と感じた他のRubyistはどんどんと集い始め、最終的には25 ~ 30人ほどの大きなパーティーになったのです。

ところで、実はカラオケの参加者の中には、名前は伏せますが、とあるスピーカー、とあるRubyコミッタ、Twitterもフォロワーがとても多い方など、著名開発者が確か半分以上は居たのです。幹事で精一杯で一人一人とお話はできませんでした(カラオケ会場も盛り上がっていて話せる雰囲気ではなかった)し、その時はカラオケの幹事をやることで精一杯だったため、あまり状況を飲み込めていませんでしたが、今考えるとすごい経験でした。(笑)
読者の皆さんは、SNSによって、ある程度同じタイミングで彼らの多くがカラオケの様子を公開し出したら、SNSで情報が瞬く間に広がる状況は容易に想像できると思います。その結果、新たな参加者はどんどんと集い始めました。

参加者が増え、20人で予約をしていた部屋に25人 ~ 30人程度がぎゅうぎゅうに入り、部屋はもう熱気に満ち溢れ、私含めた参加者の何人かは冷房の風の向かう先に立って涼んでいたことを覚えています。そして、私の仕事はまだまだ終わりませんでした
参加者が増えるたびに、新たな参加者に料金体系の説明、オーダーの方法、カラオケの終了時間などを英語で伝達し、カラオケスタッフに「新しく一人参加者が増えました。プランは・・・、最初のオーダーは・・・」という連絡をする仕事が発生します。当然参加者は別々に到着するので、説明は参加者が到着するたびに新たに行いました。
一説明終えようやく一息つけそう...となったところにまた新たな参加者がやってきて新たに一から説明をするのは、かなり大変ではありましたが、それと同時にとても有意義で楽しい時間でした。
なぜなら、新しく入室してくる方とは説明ついでに自己紹介や軽い会話もできますし、それがきっかけでSNSアカウントや名刺交換に発展することもあったからです。

さて、新たな参加者の波が一旦落ち着いたところで、私も一曲披露しました。恥ずかしいので曲名は隠しますが(笑)、とある有名な洋楽です。
外国人が集うカラオケで、洋楽を歌う経験なんて私は当然したことはありませんでしたので、とても貴重な経験でしたし、友達の前で洋楽を歌うのとは全然違い、本当に緊張しました。
そして、参加者の方はカラオケを精一杯、3時間に渡って楽しんでくださっていました。動画で様子をシェアしたいところですが、多くの方の顔が写ってしまっているためこちらも私の心の中に大切に閉まっておく思い出の一つにさせてください。

カラオケの様子(右下が私)
カラオケの様子(右下が私)

時間はあっという間に過ぎ、カラオケは終了しました。午前0時半、今思い出すとこの時の私は疲れ果て、おそらく全く目が開いていなかったと思いますが、達成感と興奮が勝り眠気などは微塵も感じませんでした。若くてよかった、と思いました。(笑)

さて、この日は朝は7時頃に起きてから9時頃には会場には着いていたので、15時間ぶっ通しで出会った方と喋り、笑い、そして多くの学びができました。学びだけではなく、松本の名産を食して松本を感じたり、カラオケなどのイベントの(まさか)幹事をして多くの海外Rubyistと交流することができました。
改めて、RubyKaigiは本当に素晴らしいカンファレンスだと思いました。素敵なセッション、ブースだけではなく、こんなにも素敵な出会いを経験できるイベントで、自分が頑張れば頑張るほど、たくさんの出会いに恵まれます。
RubyKaigiのセッションに参加するだけでも十分に楽しいですが、そこから無限の可能性を秘めたRubyKaigiをどれだけ楽しめるかは自分次第だと思いました。

三日目: 楽しい瞬間は一瞬 ー 近付く別れ

最終日のレポートです。最終日分の量は少なめです。二日目は午前1時頃ホテル着だったものの、カラオケにて参加者にTwitterアカウントを教えていただいたので、DMでメッセージのやり取りをしていたり、興奮で寝るのに苦労していました。最終的に眠りにつけたのは、深夜4時頃?(笑)だったと思います。

しかし、ちゃんと寝てもないし、二日目で十分疲れたはずなのに、三日目は疲れる暇もありませんでした。そのぐらい三日目もまた、充実していた一日でした。ここでは一日目、二日目のように詳細は振り返らず、撮った写真をいくつかを共有します。

Selena Small氏の三日目のスピーチ後に会場で撮った写真
Selena Small氏の三日目のスピーチ後に会場で撮った写真

Pixivさん主催のクラブイベントでの写真
Pixivさん主催のクラブイベントでの写真

振り返り

三日間のどこを切り抜いても、そこには「興奮」があった初カンファレンスでした。三日間のどこを切り抜いても近くには素敵な開発者がいらっしゃいましたし、自分の開発に対する悩みを打ち明けて色々な著名な開発者から自分が今まさに求めていたアドバイスをたくさんいただきました。

そして、最も嬉しかったことは、自分の英語力で海外の方とコミュニケーションが取れたことでした。普段実際に対面で海外の方とお話しすることもほとんどないため、自分の英語力を活用して海外の方に自分の意思を伝えられたことも、その力を活かしカラオケを主催できたことも、何もかもとにかく嬉しかったです。特に、日本の開発者はともかく普通に生きていたら絶対お会いできない、英語を自分が学んでいなかったら交流できなかったであろう海外で活躍されている開発者と沢山お話できたことがとても嬉しかったです。その中で、世に出回っていない「リアルな」多くの学びを得ることができました。

そして、これを読んでいる皆さんに私から伝えたいのは、 初対面な人に恐れず話しかける大切さ です。
私は前述したように、このRubyKaigiが人生で初参加した技術イベントでした。この記事には書いていない0日目(前乗り日)には友達は誰もおらず夜は寂しく一人、ホテルの前の飲み屋でハイボールを飲んでベロベロになってホテルで寝ました。(笑)本当に友達は誰もいなかったのです。

でも、会場で初対面の人に臆さず話しかけられたから、この記事で私が語ったように多くの出会いがあり、多くの学びがありました。特に私の場合は、自分の英語力を活かして多くの海外Rubyistと交流し、貴重な経験をさせていただきました。

もし会場で私が誰にも話しかけなかったら、自分の能力に不安を感じ日本人とだけ話していたら、初対面な人に恐れて話しかけなかったら、私のRubyKaigiはここに綴ったものと大きく変わっていたと思います。 そして、この三日間の素敵な出会い、学び、揺れうごいた感情を経験できなかったと思います。

私の初RubyKaigiがこれほどまでに充実したものになったのは、間違いなく自分のおかげだと思っています。

一方で、三日間で最も残念だったことは私の英語のレベルがまだまだネイティブスピーカーの前では歯が立たなかったという事実でした。
自分が伝えたいことは伝えられる一方で、相手の言っていることは早すぎたり単語が分からなかったり、何らかが原因で私がRubyKaigiで聞いた英語の半分程度は何を言っているのかわからなく、とても辛かったです。

もし自分の英語がもっとできたなら、会場で出会った多くの方ともっと打ち明けられたかもしれないし、三日間で出会った人が教えてくれた多くのことをもっと理解できたかもしれない。もっと有益な情報を知れたかもしれない。

私の英語はまだまだ改善の余地があることに気付きましたし、これからも本当に頑張り続けないとな、というモチベーションを得ることもできました。これを受け、RubyKaigiが終わった後、まだ決めきれていなかった今年の目標を決めました。

【今年の目標】

今日できた友達とRubyConf、またはRubyKaigiで再会できたら、まるで日本語を話しているかのように英語を伝えられるようになること。 次会った時にはRubyKaigi 2023で出会った彼らのことをもっと知ること。

RubyKaigi 2023で出会った彼らが自慢できるような友達であり、開発者になること。そのために努力し続けること。

RubyKaigi 2023で出会った彼らのように、自分に自信のある素晴らしい人間になること。

以上で、私のRubyKaigi 2023 訪問レポートは終了です。この記事を読んでくださった皆様。ありがとうございました!

最後に

弊社ではRubyエンジニアを募集中です!詳しくは下記のサイトをご覧ください!

www.synchro-food.co.jp

*1:表側の表示を開発するエンジニアのことです。一般的にRubyを使って開発は行いません。

*2:ラムダノートにて発売日以前に公開されていた版

*3:なお、余談ですが弊社では書籍購入補助制度と呼ばれる福利厚生があります。下記のブログでも触れていますが、2022年度、研鑽Rubyプログラミングのβ版は書籍購入制度にて6名の社員が購入しています! 書籍購入補助制度の詳細について、その他弊社の社員がどんな本を書籍購入補助制度により購入されたのか気になった方は、以下の記事も是非ご覧ください。

tech.synchro-food.co.jp

RubyKaigi 2023 に参加してきました(@t___yokoyama) 【前編】

初めまして。シンクロ・フード開発部の横山朋玖です。

twitter.com

今日の記事は、RubyKaigi 2023に参加した横山のRubyKaigi 2023の参加レポートになります。
なお、こちらの記事は前編になります。前編では、RubyKaigiとは何か、RubyKaigiに参加した動機、RubyKaigi 2023で印象に残ったセッションや、技術的に刺激を受けたことなどをまとめられればと思っております。
そして後編は、前編には書ききれなかったRubyKaigi 2023での多くの出会い、出会いを通して学んだこと、得られた経験、そしてRubyKaigiの素晴らしさなどをありのままに書き記したレポートになります。よろしければ後編もご覧ください。

自己紹介

Ruby(Rails)を使って弊社のWebサービスを開発して一年半目の横山朋玖です。 弊社のサービスである求人飲食店ドットコムの開発を行っています。

また、趣味で英会話レッスンにも一年ほど通っております。

RubyKaigiとは?

RubyKaigi 2023の入り口から見た景色。Matsumoto! RubyKaigi 2023という文字とともに我々を素敵な三日間の旅へと誘う

RubyKaigiとは日本で毎年開催されている、Rubyに関する技術イベントのことです。ここ数年はパンデミックの影響でオンライン開催が続いていたようですが、RubyKaigi 2022からは現地での開催が再開しました。

そしてRubyKaigi 2023には、Rubyを利用している開発者をはじめ、三日間で約1500人ほどにものぼる多くの方が世界中から日本に集まりました。

RubyKaigiは、Ruby開発者同士の繋がりをより強め、コミュニティを活性化させるために年次で開催されるイベントです。
そのため、会場にはRuby開発者が馴染みのあるRubyネタがあちらこちらに散りばめられており、ネタには思わず笑ってしまうこともありました。

なお、これを読んでくださっている方の中の多くは、RubyKaigiをあまり知らない方がほとんどかと思います(実際私も去年まで知りませんでした)。
そこで、会場の雰囲気はこんな感じ!というのをいくつかの写真を通じ、簡単に共有できればと思います!

まずはこのイベントの醍醐味である、有名開発者によるセッションのスケジュールになります。
RubyKaigiでは、Rubyというプログラミング言語自体*1の開発者(この開発者のことを、Rubyコミッタと呼びます)や、Rubyコミュニティに大きく貢献している開発者などによるセッションが多く開かれます。
なんと今回のRubyKaigiでは同時に三つのセッションが並列で開催されていました

RubyKaigi 2023 スケジュール

以下の画像は、私の尊敬する開発者の一人であるSamuel Williams氏による発表の雰囲気になります。
彼は、HTTPというWebプロトコルにまつわる問題提起、そしてその問題を解消するためにご自身が作成されたプログラムをセッションで発表されていました(詳しい内容については、本記事中のセッションについての紹介セクションをご覧ください)。

Samuel Williamsによる発表

さらに、会場では多くのスポンサーがブースを開いていました。
ブースにて、スポンサーによるRubyKaigiオリジナルグッズの配布や、二日目にはブースを巡ってスタンプを集める「スタンプラリー」も開催されていたりと、スポンサー企業と関わることのできる機会が沢山ありました!
セッションが開催中の時間帯でもブースにはいつも人がいましたので、セッションが開催している時に敢えてブースに遊びに行ったり(もちろんガラガラ)、朝早くから会場に出向きブースに遊びに行ったりということもできました。
混んでない時間にブースに立ち寄ると、もちろんブースの運営開発者とより長い時間会話ができる嬉しさもありますが、それ以上に「(スタンプラリーやグッズを求める)1RubyKaigiの参加者」としてではなく「技術に興味のある1開発者」としてより深く交流できる嬉しさがありました。
私の場合、スポンサー企業に勤める開発者の方と技術的なお話をさせていただき、交流させていただきました。
例えば、弊社のリモートワーク上の課題を他社さんに共有してみたのですが、他社さんも同じ悩みを抱えていることがわかったり、逆に「こういうふうに弊社は取り組んでいます」という風なアドバイスをしてくださったりしました。
弊社にとって、また、私個人にとっても有益な情報をブースの交流を通してたくさん知ることができました。

スポンサー一覧

さて。前述したように、スポンサー企業が当日配布されているRubyKaigiオリジナルグッズも紹介できればと思います。
私の一番のお気に入りグッズは、Findyさんにいただいた「なんもわからん付箋」でした(笑)。この付箋は裏表別の言葉が書かれており、表側には「完全に理解した」という言葉が書かれています。 ところで、実はこれらの言葉はエンジニア界隈の語録的なものです。「完全に理解した」という言葉はエンジニアがある分野について勉強を進め、少しその分野に詳しくなってきた時に良く口にします。分野全体の理解度が20% ~ 30%程度の時にこのように口にしている傾向が強いです。ソースは私です。

そして、分野の勉強を進めていくにつれ、当然理解できないこともまた増えていきます。壁にぶつかる度に、着実に理解度は「完全に理解した」時よりも増えているのに、自分の自信度は急降下していきます。そんな時エンジニアは「なんもわからん」と口に出し、自分の辛さを言葉で表現するのです。

この付箋はまさに、そういった「エンジニアあるある」を付箋として表現しています。私にとってとてもキャッチーな言葉に魅了され、愛用しています。

なんもわからん付箋

このように、三日間を通じて多くの開発者や企業からRubyコミュニティを盛り上げる催し物がたくさん行われました。
楽しすぎたあまり、ブースの様子を撮り忘れてしまいありのままの様子をお伝えできないのが少し残念ですが、これで少しでもRubyKaigiの雰囲気が読者の皆様に伝われば嬉しいです。

そして、なんとこのイベントには2018年、弊社から二人もの方が参加されたこともあります!
よければそちらの記事もご覧ください。

RubyKaigi 2018 に参加してきました (@fohte) - シンクロ・フード エンジニアブログ RubyKaigi 2018 に参加してきました (@n0_h0) - シンクロ・フード エンジニアブログ

なぜRubyKaigiに参加したのか?

Rubyは現在、多くの企業によってWebアプリケーションを作成するのに使われています。
そして、弊社も例外ではありません。弊社では、私の開発担当している求人飲食店ドットコムをはじめとする提供サービスの多くがRubyによって開発されています!

そしてRubyKaigi 2023では、前述したように世界中から約1500人ほどのRuby開発者が集まります。その中には日本の企業で働いている方、海外の企業で働いている方、プログラミング言語「Ruby」の生みの親である「まつもと ゆきひろ」さんをはじめとしたRubyの言語自体を作成している方、著名なRuby開発者なども参加されました。

会場の規模感や雰囲気は弊社エンジニアブログの過去の記事を見たりRubyKaigiの概要を調べたものの、正直あまりわかっていませんでした。
しかし、少なくとも私は「世界中から素晴らしい技術者が大勢集うKaigiである」ことは理解しておりました。そのため、私がRubyKaigiに参加した理由は、

RubyKaigi 2023に参加し、世界中の多くの人からできるだけ多くの、色々な種類のインスピレーション(モチベーション)を受けたい

からでした。

技術的なモチベーション、インスピレーションだけではなく、勉強に対するモチベーション、海外の人とお会いし英語に対するモチベーションなど、私が今の人生に必要だと思う全ての種類のモチベーション、インスピレーションが得れると信じ、私はRubyKaigiに参加しました。

そして結果的に、今回RubyKaigiに初めて参加し、私は日本人の中で最もRubyKaigiを楽しみ、一番多くの刺激を得られたと思えるほど、多くの経験や出会いをさせていただきました。そして、私の人生に今必要な全てのインスピーレーションをRubyKaigiにて得られたと心から感じています。

この記事では人との出会い、学んだ教訓、そして、どんな素敵な経験をRubyKaigiでしたのか?といったことは紹介しません
そのような内容は【後編】の記事にてありのままを書きました。気になった方は、ぜひそちらの記事をご覧ください。

セッションの紹介

Make Regexp#match Much Faster

speakerdeck.com

この発表は、正規表現のRubyコミッタであるHiroya Fujinamiさんによる発表です。

正規表現にはとても強い力があります。 例えば「"01 + 01 = 10"という文字列が二進数の足し算であるか?」を判定できたり、brainf**kインタプリタをRubyの正規表現で開発された方もいるように、とても強力です。

shinh.hatenablog.com

正規表現は強力な機能である一方で、大いなる力には大いなる責任が伴う(Fujinamiさんの発表中の言葉をお借りします)という言葉が示すように、正規表現には「弱点」があります。
この弱点は「ReDoS脆弱性」と呼ばれており、このReDoS脆弱性は現実世界でも問題になっています。例えば、あるサービスがReDoSが原因で27分間も使用不可能になってしまったり、RubyのGems(ライブラリ)で使われている正規表現にもReDoS脆弱性が存在していたりします。

この発表者のHiroya Fujinamiさんは、このReDoS脆弱性を引き起こしにくくするために、正規表現の性能を大幅に引き上げる修正をRuby 3.2.0で実装した方です。
彼は「正規表現の現状実装をどのように変えたらReDoS脆弱性を引き起こさないようにできるのか?」という問題に、「メモ化」と呼ばれる最適化手法を使い、正規表現の仕組みの最適化を行いました。
この発表では、開発時にどのようなことを考えていたのか、今後どんなことを実装していきたいか、という点についても発表をされていました。

bugs.ruby-lang.org

感動したこと

一番感動したことは、Rubyの全ての機能は、誰かが作っているということを実感したことです。
今まではRubyという仕組み・言語を「便利だから」使っていたに過ぎなかった私ですが、RubyKaigiに参加し彼の発表を聞いた後、Rubyの全ての機能は世界中の開発者が試行錯誤の末に成し遂げた「成果物」であることを実感せざるを得ませんでした。
実感すると同時に、正直、今まではRubyを「神から贈られたギフト」のように捉えていました。この発表を聞いた後意識はガラッと変わり、「Rubyは人が、人のために作るもの」であると捉え直すことができました。
私も近い将来、Rubyに新たな機能を実装できるような開発者になれたら嬉しいなと思いました。

そして次に、彼のスピーカーとしての講演での話し方です。
ReDoSについても全く知らない、そして当然正規表現についての実装の詳細が何も分からない私でもわかるように、丁寧な説明をしていただきました。

その中で私は、彼の「全ての聴衆に自分の気持ち、開発に対する向き合い方、そして、正規表現の面白さを伝えたい」という気持ちが伝わりましたし、私はその思いに至極感銘を覚えました。
彼の発表をお聞きし、彼が日々向き合っている「正規表現」のように、「自分が強く開発したい、貢献したい」と思える、私の技術的な適所を見つけたいと思いました。

Hiroya Fujinamiさん、素敵な発表をしていただき、本当にありがとうございました!

Fix SQL N+1 queries with RuboCop

speakerdeck.com

このセッションでは、ISUCONと呼ばれる「お題として与えられたWebシステムをどれだけ高速化できたかを競うコンテスト」に参加されているGo Sueyoshiさんが、「ISUCONで出題されるWebシステムの中の『長文SQL』からすぐにN+1問題が起きている箇所を見つけられるRuboCopを作りたい」という思いをきっかけに作成された、RuboCopルールについての紹介がされていました。

ISUCONにて出題されるSQLの例(スライドからの引用)
ISUCONにて出題されるSQLの例(スライドからの引用)

ISUCON本番時、上記のようなSQLからN+1問題を早く摘出するのは、急いでいるならなおさらとても難しいと私は思いますし、通常業務の中でも、SQLからN+1のような問題を見つけるのはとても時間がかかるものだと感じています。
その点、このリンターを使えば生SQL限定ですが、N+1問題を摘出することができるため、ISUCONにおいては勝率を伸ばすことに十分コミットするはずです。
そして、N+1問題を解消するRuboCopルール以外にも、いくつかのルールが紹介されていました(詳しくはスライドを参照してください)。

感動したこと

一番感動したことは、「Rubyでは、やろうと思えばなんでもできるんだな」 ということでした。
やりたいと思ったことを自分で開発できること以上に、開発者が嬉しいこと、誇れることはないと思います。私はそのように思っています。

そして実は、私が開発を始めたきっかけは「作りたいと思ったものが作れる人になりたい」からでした。 (最初に作成したツールは、まさに自分の欲望を満たすためだけに作ったプログラムでした。)

しかし、最近は「仕事のためのツール」としてプログラミングを使っているだけであり、自分の夢を叶えるために、自分が本当に作りたいと思ったものを実現するために、開発をできていませんでした。

そして、そんなことを考えることすらも忘れてしまっていました。

彼の発表を聞き、ずっと忘れていた、心の奥に閉じ込められていた開発者にとって一番大事な気持ちを思い出しました。
そして、発表を聞き続ければ続けるほど、どんどんとインスピレーションを感じ、まるでその気持ちを加速させるかのようにエネルギーが自分の周りからどんどんと集まってきました。
実はこの記事の執筆時点では実はもう気持ちがだんだんと失われはじめているのですが、やはり自分が感じた問題を自分の力でより良くできることはとても尊いことだと思いますし、今年何かを成し遂げたいと奮起できたので、忘れないうちにSlackのチャンネルは作成しました。

業務改善のアイデアをまとめるチャンネルを作成。暇な時に開発できそうな、深夜テンションで思いついたアイデアを投稿中

私もこれからRuby開発者としてのキャリアを積んでいくと思うのですが、その中で自分が少しでも感じた問題に敏感になり続け、直近で「Rubyを使い、自分が直面している問題の解決をしたい」と思いました。
Go Sueyoshiさん、本当に素敵な発表をありがとうございました!

Unleashing the Power of Asynchronous HTTP with Ruby

こちらのセッションの発表資料は以下のURLから入手可能ですので、皆さんも是非見てみてください!

github.com

このセッションでは、HTTPの30年の歴史の紹介、現状のRuby環境において、HTTP 2+をサポートするHTTPアダプター(HTTP ⇄ Rubyをサポートする機能)が少ないという問題の提起、その問題点を解決するためにHTTP/2をサポートするHTTPアダプター「Async::HTTP」の作成したことが発表されました。

そして将来的に(今年中に)Async::HTTPでHTTP/3のサポートも行うことが発表されました。

皆さんご存知のように、WebとHTTPは現在切り離すことができない関係になっています。そして、HTTPの初回リリースからは、今年約30年になります。
HTTPは最初こそはシンプルなものでしたが、時間が経つにつれどんどんと機能追加、改善がされていき、現在ではHTTP/3までバージョンアップがされております。

しかし、RubyではHTTP/2以上をサポートするHTTPアダプタ(HTTPを解釈できるプログラム)があまりないのです。つまり、バージョンアップしてパワーアップしたHTTPをRubyは十分に使いこなせていない ということになります。
それを解決しようとしているのが、本セッションの発表者であるSamuel Williams氏です。

一番感動したこと

彼のスライドには、素晴らしいアニメーションが多数埋め込まれています。そして、そのアニメーションはとても素晴らしく作用していました。特に、英語のネイティブではない私でも、彼のスライドを見るだけで伝えたいことが十分に理解できました。

彼の発表スライドのアニメーションの様子
彼の発表スライドのアニメーションの様子

アニメーションの素晴らしさ、そして、クリアで聞き取りやすい英語での発表にも感動しましたが、最も感動したのは、
彼の自信に満ち溢れた発表でした。

私はこの講演を聞く前、素晴らしい開発者とは単に「開発という領域において能力を発揮できる人」だと思っていましたが、この発表を聞き、
本当の素晴らしい開発者は、開発能力に長けているだけでなく、「自信に満ち溢れた、人としても素晴らしい人」であることを本当に感じました。

そしてセッションが終わった後、彼に質問をさせていただきました。彼は私一人に対して10分程にも渡って質問に真摯に回答してくださいました。
彼に回答をしていただいていた際、気付いたことがあります。
それは、素晴らしいライブラリ開発の裏には、私には想像できないほどの努力があるということです。

彼は発表の中で、「Async(彼の作ったライブラリ)はHTTP三十年の歴史の複雑さを10行のシンプルなコードで隠せるライブラリである」とおっしゃっていました。
ですが、ということはAsyncの開発の際、当然Samuel自身はHTTP三十年の歴史を知り、その複雑性に向き合う必要があります。さらに、他にもたくさんの課題があったはずなのです。
彼の発表では苦労話は一切出てきませんでしたが、私とマンツーマンで話してくださった時は開発時に辛かったことも教えてくださいました。

私もいつか彼のようになりたい。 本当にそう心から思わせてくれた、素敵な時間でした。本当に素敵な発表・素敵な時間をありがとうございました。

Samuelから講演後いただいたAsyncロゴのTシャツ
Samuelから講演後いただいたAsyncロゴのTシャツ

最後に

以上で【前編】は終了です。最後までお読みいただきありがとうございました! よければ【後編】も是非ご覧ください!

また、弊社ではRubyエンジニアを募集中です!詳しくは下記のサイトをご覧ください! www.synchro-food.co.jp

そして、今回のRubyKaigi 2023には旅費、交通費、会費などを全て経費でご負担していただきました。ありがとうございました。 弊社の福利厚生・制度の詳細は、以下のページをご覧ください。

www.synchro-food.co.jp

*1:プログラミング言語もまた、何か別のプログラミング言語のプログラムなのです

シンクロ・フードのエンジニアが書籍購入補助制度を利用して2022年度に購入した書籍ランキングTOP5を紹介します

こんにちは、シンクロ・フードの越森です。

今回は2023年度最初の記事と言うこともあり、シンクロ・フードのエンジニアが書籍購入補助制度を利用して2022年度(2022年4月〜2023年3月)に購入した書籍を紹介したいと思います。

シンクロ・フードの書籍購入補助制度とは?

始めにシンクロ・フードの書籍購入補助制度についてまとめると以下になります。

  • 制度概要
    • 技術書や業務で必要となる業務知識に関する書籍など、スキルアップにつながる書籍の購入を支援する制度
  • 支援内容
    • 1人当たり1年間で総額30,000円(税込)までの支援
    • 購入した書籍は個人所有(購入した書籍の金額分が課税対象)になる
  • 利用条件
    • 対象書籍は技術書と業務で必要となる業務知識に関する書籍
    • 冊数制限無し
    • 電子書籍での購入も可能

リモートワークを始めてから会社に保管する形式の書籍購入補助制度では使い勝手が悪くなったため、2021年9月にリニューアルして今の形式になりました。
メンバーにも非常に好評でスキルアップの一助になっていると思います。

2022年度の購入書籍

2022年度の1年間で購入された書籍数は218冊で、エンジニアは32名在籍していることから1人当たり6.8冊購入している計算になります。
大体2ヶ月に1冊は制度を利用して購入していると言うことですね。

2022年度の購入書籍ランキングTOP5

次に2022年度に購入された書籍のランキングTOP5は以下になります。

順位 書籍名 購入冊数
1位 プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 15
2位 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 9
3位 研鑽Rubyプログラミング β版 6
4位 プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで 5
5位 りあクト! TypeScriptで始めるつらくないReact開発 第3.1版【Ⅲ.React応用編】 4
5位 プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで 4
5位 プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ 4

1位の「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則」は会社で読書会を開催していたこともあり、多くのメンバーが購入しました。
シンクロ・フードでは若いメンバーが多いのですが、今後良いコードを書く上で重要な原理原則が多数紹介されており参考になったのではないかと思います。

越森は、principle 2.5として紹介されているSLAP(Single Level of Abstraction Principle) の項目が好きで、抽象レベルを揃えることで、優れた書籍のように読むことができると例えられているのが良いなと思います。

2位の「良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方」は、ITエンジニア本大賞2023技術書部門の大賞に選ばれるなど話題になりましたが、シンクロ・フードにおいてもランクインしています。
こちらの書籍は実践的な内容でテーマ毎に良いコード、悪いコードを元に解説されているので非常に分かりやすい内容になっています。

越森は昔、学生時代にテレホーダイで「Cプログラミング診断室」というWebで公開されていた書籍を読んでいたのですが、悪いコードを元に駄目な理由を解説されているところが似ているなと思って読んでいました。(歳がばれる...)

3位は、2023年4月にβが取れて新刊として販売された「研鑽Rubyプログラミング β版」がランクインしました。
シンクロ・フードではRuby on Railsを使って開発しているため、5位にも「プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで」がランクインしているようにRuby関連の書籍が多く購入されています。
入門書から中級者、上級者向けの書籍までバランス良く購入されているようでした。

最後に

今回の記事を書くために、購入されている書籍をまとめてみたのですが、購入書籍数が281冊に対して116種類と思いのほか多くの種類の書籍が購入されていて驚きました。
今年度はどのような書籍が読まれるのか楽しみにしたいと思います。


最後に、エンジニア募集のお知らせです!
シンクロ・フードでは、書籍購入補助制度に限らず今後もエンジニアが成長できる環境を整備していきたいと思っています。

また、飲食店ドットコムを始めとしたサービスの開発・改善も、どんどん進めております。
ご興味のある方は、以下の採用サイトからご連絡ください!
www.synchro-food.co.jp