Timee Product Team Blog

タイミー開発者ブログ

統計検定準1級に不合格を乗り越え、合格した話

こんにちは、タイミーのデータアナリティクス部でデータアナリストをしている山本です。普段は主にマーケティング部の向き合いとして、分析業務に従事しています。

先日、社内の資格支援制度も活用しながら統計検定準1級(CBT)を受験し合格しました。不合格を経て合格に至ったため、実際の学習の流れやデータアナリストに統計検定準1級がおすすめできるポイントなどをご紹介したいと思います!

試験について

  • 準1級のレベル感
    • 「実社会の課題に対する適切な手法の活用力」というレベルで具体的には2級までの基礎知識をもとに、実社会の様々な問題に対して適切な統計学の諸手法を応用できる能力を問うものとされています。(統計検定公式HP
  • 試験範囲
    • 試験結果レポートでは「確率と確率分布」「統計的推測」「多変量解析法」「種々の応用」と分けられていますが、非常に広範囲をカバーしています。(公式の範囲はこちら
  • 受験形式
    • CBT形式により、都合の良い試験日時や会場で受験が可能です。

受験の動機

  • 統計知識を体系的に整理し幅広く基礎的な理解を身につけたかったため。
  • 実務で活用できる分析アプローチの幅を広げたかったため。
  • 弊社での資格支援制度が活用できたため。
    • 合否に関わらず、受験費用を支援してくれるため積極的に挑戦できました。

学習開始時の状況

  • 新卒から4年間データアナリストとして働いており、本試験の範囲内に理論の理解や実践経験がある箇所が含まれている。
  • 2年前に統計検定2級を取得済み。
  • 数学力は文系大学卒レベルだが、経済学部卒で数式に比較的抵抗はない。

受験結果

1回目は「3.多変量解析法」「4.種々の応用」の後半範囲の理解が如実に甘く、不合格に終わりました。

約10ヶ月後に再受験をして見事合格🌸優秀成績賞をいただきました。

4つのセクション全てで合格基準の60%を超えることができていたのが嬉しかったです!

教材について

  • メイン教材
    • 日本統計学会公式認定 統計検定準1級対応 統計学実践ワークブック
    • 日本統計学会公式認定 統計検定 準1級 公式問題集
  • サブ教材
    • Youtube動画やWeb上の公開記事
  • 社内勉強会
    • 統計学入門や時系列分析、ベイズ統計に関わる輪読会などがあり、間接的に理解の習熟やモチベーション維持の助けになりました。(勉強会の詳細はこちら)

学習方法について

不合格時、合格時の学習方法と習熟のレベル感を振り返っているのでこれから受験される方の参考になれば嬉しいです。

  • 学習期間
    • 合格時、不合格時の双方で受験前約2ヶ月間で短期集中で学習しました。自分としては、これ以上の長期の学習期間を取ることがモチベーション維持観点で厳しかったです。
  • 学習方法と習熟レベルの振り返り
    • 1度目の受験(不合格)まで
      • 上記の統計学実践ワークブックが試験範囲を網羅している参考書なので、各章を読み込んで理解→章末の演習問題を解くという流れで学習しました。分からないところは詳しい解説を探しつつ、全32章に及ぶため疑問点が解消されない場合はマークだけつけて飛ばして先の章に取り組み、まずは範囲を一周することを優先しました。
      • 2周目として1周目でマークをつけている理解が浅い箇所の再学習し、公式問題集の過去問を3年分ほど解き受験に挑みました。
    • 1度目の受験結果をうけて
      • 点数的には52点で、不合格でした。あと8点で合格点という点差以上に自分の理解度合いが足りていない感覚を受けました。特に統計学実践ワークブックの演習問題が解けるだけのレベルでは試験問題には対応できず、より本質的な理解や数式での理解ができているレベルが求められていると感じました。
    • 2度目の受験(合格)まで
      • 約半年開けて再度学習するモチベーションが湧いてきたので、再挑戦することを決めました。教材としては引き続き統計学実践ワークブックを用いて1度目の受験で点数が取れていなかった領域を中心に学習し直しました。各章を自分の言葉で説明できる理解度を目標に取り組み、特に回帰分析、多変量解析、時系列解析、分散分析などの範囲は数式や導出を丁寧に追いかけて暗記に頼らない理解を心がけました。

学習時間について

平日は終業後に1~1.5時間、休日は土日合計で4~5時間ぐらいを目安に時間を確保していました。1ヶ月で50時間弱ぐらいになるボリューム感です。

予定があったり、業務が忙しいタイミングがあったりするのできっちり時間を確保するというより、週間単位で全然時間を確保できなかったとはならないように帳尻を合わせていました。

また机に向かうモチベーションが湧かない時でもテキストを流し読むとか関連動画を見るとかしながら、学習から離れたからモチベーションが下がってきたという状態にならないように気をつけていました。

データアナリストに統計検定準1級がおすすめできるポイント

  • 幅広い範囲を体系的に理解できるため、分析業務をする上での引き出しの幅が広がり業務に活かせるところ。教科書通りの分析手法を業務でそのまま使えることは稀ですが、多くの選択肢の中からより良い手法の選択をできるようになったと感じます。
  • 統計モデリングや因果推論、機械学習などさらに発展的な内容を身につける際の基礎になるためキャッチアップがスムーズになるように感じるところ。
  • 回帰分析などPythonのパッケージを使ってアウトプットを出している分析手法の導出方法や考え方の理解を深められ、活用できるタイミングや注意点に気づけるようになるところ。

最後に

今回は統計検定準1級の受験体験記として、学習の流れやデータアナリストにおすすめできるポイントなどを紹介させていただきました。

弊社のデータアナリストは分析手法の選定が基本的にメンバーに権限が委譲されており、弊社のデータアナリストには、分析方法を自分で選ぶ自由が与えられています。そのため、さまざまな分析の引き出しを持っていることが、ビジネスに貢献するために非常に重要です。資格取得を通じて得た学びをどんどん実務において活かしていけるように努めたいと思います!

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っています。 統計知識を活用した業務できるので、少しでも興味がありましたら、気軽にご連絡ください。

【Front-End Ops/イベントレポート】「コミュニケーションでフロントエンドの 「広さ」に立ち向かう」

イベント概要

2024年2月21日に「GENBA #2 〜Front-End Opsの現場〜」と題してタイミー、Sansan、ココナラ、X Mileの4社でFront-End Opsに関する合同勉強会を開催しました。 今回はそちらの勉強会からタイミーフロントエンドエンジニアのyama_sitterさんの発表をイベントレポートでお伝えします。

2023年9月にタイミーにジョインしたやましたです。よろしくお願いいたします。前職ではスクラムマスターやEMを担っており、タイミーで久々にエンジニア復帰しています。

1. どんな状況で何が起きたか

今回はフロントエンド特有の問題に対し、あらゆる施策を実施してきた結果、「結局、コミュニケーション大事!」という話をします。まずはフロントエンド特有の課題やタイミーでの状況を整理します。

浅く広くフロントエンドに向き合っている

フロントエンドは1機能・1画面に幅広いドメインが集約されることが多く、その特性上「浅く広く」になりがちな印象があります。さらに新たな技術やフレームワークの導入が頻繁にあり、この点でも大変です。もちろんバックエンドも新しい技術やパターンが導入されることはありますが、フロントエンドほどの頻度や速度ではないことが多いと思います。

タイミー独自の環境

タイミーでは、多様な機能を開発するfeatureチームがあり、フロントエンドエンジニアもこれらのチームに参加しています。一応「chapter」と呼ばれる職能別の横断組織はあるのですが、あくまで主戦場はfeatureチームのため、横断課題の優先順位がすごく上がりづらい状態です。各チームが自分のタスクに専念するあまり、組織全体の課題に目を向けることが難しいことがあります。さらに、フロントエンドの担当範囲は一つのサービスやリポジトリに限られがちで、その結果、誰がどの部分を担当しているのかが不明瞭になることがあります。また直近は、フロントエンドエンジニアの数が増え、リモートワークが常態化することで、コミュニケーションの複雑さはさらに増しています。

この状況下で何が起きたか

チームメンバー個々では、全ての領域を網羅することが困難です。特定の外部サービスの運用などは、有志の自発的な取り組みに依存しています。知識の共有が限定的なグループ内でしか行われず、組織全体への伝搬が不十分になるため、一部の課題に対して担当者が固定され、柔軟な対応が困難になっています。横断的な課題に対する担当者の割り当てが難しく、解決に至らないことが多いです。多くの重大な横断的課題が放置されたままです。「一旦起票します」と起票はするものの、それ以上の進展が見られないケースも多くありました。

広さに立ち向かうための運用や体制が別の課題を生む

タイミーでフロントエンドの広範な業務に対応するために構築した体制や運用が、意図せず別の課題を引き起こしていると考えました。

  • 積み重なる横断課題
  • 業務の属人化
  • 地層化
  • 伝搬されない知識

解決策が新たな問題を生んでしまう、一種のジレンマと言えるでしょう。

2. 何をしてどうなったか

横断課題の整理とリファインメントの実施

私が最初に着手した施策です。チームメンバーの課題認識を一致させるために、まず横断的な課題の洗い出しと詳細化を行いまし た。これは具体的な問題解決だけでなく、今後の方向性や現状認識の共有にも役立ちました。

「改善デー」の導入

フェデックスデーや20%ルールのようなイメージで、これまで2回「改善デー」を開催しています。この日は、メンバーが一堂に会し、解決したい横断課題を自由に選んで取り組みます。活発なプルリクエストのやり取りがあり、「一旦、起票します」という言葉で終わらせることなく、実際に成果を出すようになりました。

業務知識の共有

知識の属人化を防ぐため、不定期に知識共有会を開催しています。もちろん即座に「知識」となるわけではありませんが、「知らない」ことを減らすことに成功しています。※私が主導する前から不定期で実施されていました。

アーキテクチャの定例の開催

私が最も注力している取り組みです。フロントエンドのアーキテクチャが地層化することへの懸念から、どのようなアーキテクチャが望ましいかを話し合う場を設けています。私が1人で考えていても解決できない課題に対し、多様な意見が出されることで、改善への一歩となっています。

テックトークの導入

技術的な話題にフォーカスした「テックトーク」を導入しました。これは任意のメンバーが集まり、フロントエンド開発に関連する技術的な話題について議論する場です。

3. 重要なことは何だったか

これまで紹介してきたことをまとめると、要するに「コミュニケーションが大切だよね」ということです。日常的な共有や議論、意見の交換を通じて、チーム全体が同じ方向を向いて進めるようになりました。

選ばれたのはコミュニケーションでした

フロントエンドの広さゆえのメンバー間の思考や課題感の違いを理解するために、コミュニケーションが中心的な役割を果たしていることが分かりました。フロントエンドの領域が拡大し続ける中、コミュニケーションによって多くの問題に対処できていると感じています。チームやドメインが拡大する中でも、そのスピードに遅れを取っていないと思います。

ただし、リモートワークには固有の課題があります。チャットだけではコミュニケーションの限界があると感じています。私はリモートワークが好きなので継続するためにも、リモートでも効果的なコミュニケーションを図る方法を模索しています。

注:コミュニケーション = 雑談ではない

コミュニケーションについて多く語りましたが、目的は単なる雑談を促すことではありません。雑談も重要ですが、重要なのは課題を特定し、それに対するコミュニケーションの方法を模索することです。

人に依存しない仕組み化が重要

コミュニケーションはもちろん、人に依存しない仕組みを構築することも非常に重要です。コミュニケーションは問題解決のトリガーに過ぎません。根本的な解決には仕組みが必要です。チームが拡大し、単純なコミュニケーションだけでは対応できなくなった現在、仕組み化を進めることの重要性を強く感じています。

4. これから考えていきたいこと

あらゆる施策を実施するなかで、改善の兆しは見えつつありますが、課題もあります。

課題を整理し「旗」を立て直す

多岐にわたる取り組みが散発的になってしまい焦点がぼやけがちです。線ではなく点の施策をたくさん実施してきましたが、これではいくら各コミュニケーションが良くても、離散してしまいます。今後は、課題を明確にし目標を再設定する必要があると考えています。

例えば、リファインメントのセッションが「しーん」と静かになる瞬間があることや、限られたメンバーのみが参加する状況は、チームの一体感を損ないます。また、課題の認識に齟齬が生じたり、優先順位が不明確になることも問題です。

これらの問題に対処するためには、共通の目標を示す「旗」を立て直し、チーム全体が同じ方向を向いて進めるようにすることが重要だと考えています。

まとめ

  • フロントエンドは浅く「広く」なりやすい
  • この「広さ」に立ち向かうためには「コミュニケーション」が重要
  • 課題を捉え、そのために必要なコミュニケーションの形を模索する
  • 但しコミュニケーションそのものは解決「策」ではないので注意

その他の方の発表も気になる方はこちら!

www.youtube.com

少しでも興味を持っていただいた方は是非こちらからカジュアルにお話しましょう!

devenable.timee.co.jp

少人数制でLookerの講習会をやってみた話

はじめに

こんにちは!タイミーでデータアナリストをしているhatsuです。

私は普段、タイミーの営業戦術などについての分析に携わるほか、社内でのデータ利活用を推進する取り組みを行っています。

今回は、社内のデータ利活用推進に取り組む中で、これまで定期的に開催していたBIツールの社内講習会の運営方法を見直した話をご紹介したいと思います。

従来のLooker講習会における問題点

タイミーでは、社内のデータ利活用推進のため、LookerというBIツールを導入しています。

このLookerというツールをより多くのメンバーに活用してもらうため、これまでにも社内でLookerの使い方をレクチャーする講習会、通称「Looker講習会」を定期的に実施してきました。

従来のLooker講習会はオンラインのウェビナー形式で、40~90人ほどの人数を対象に実施していました。

しかし、講習会実施時にとったアンケートや、社内メンバーとの会話の中で、従来のLooker講習会には以下のような問題点があることがわかりました。

  • 受講者側の問題
    • 大人数(40~90人程度)の前だと質問しにくい
    • 講習会の内容についていけない
    • 説明の途中に質問をしにくい
  • 講師・運営側の問題
    • 受講メンバーからのリアクションや質問が受け取りにくく、説明が伝わっているかがわからない

Looker講習会はLookerの基本的な使い方をマスターするための講習会であり、受講者もLookerをほとんど使ったことがないメンバーが大半を占めます。

そのため、講習会の内容が基礎的なものであってもつまずく受講者は多く、それゆえ「質問しにくい」という現状は看過しがたいものでした。

少人数制のLooker講習会の概要

これらのLooker講習会の問題点を解消するために、参加人数を10人以内に絞った少人数制のLooker講習会を開催してみることにしました。

参加者の人数を少なくすることで質問する際のハードルが下がり、講習会の内容についていけない受講者のサポートをしやすくすることが狙いです。

また、参加人数以外にも、開催方法をオンラインからオフライン(対面)に変えました。

講習会をオフラインに変えることにより、受講者のリアクションを汲み取りやすくなるほか、講習会に付いていけていない受講者を講師側のサポートメンバーが個別にサポートできるようになると考えたためです。

さらには、従来の講習会用の資料に沿って進めるのではなく、実際にLookerの操作画面を見せながら操作方法を説明するように講習会の内容も少し変更しました。

これにより、受講者は自分のLooker操作画面と講師のLooker操作画面とを見比べながら操作を覚えることができます。

少人数制Looker講習会をやってみた結果

新しい方式でLooker講習会を実施したところ、講習会の途中にも質問が飛び交い、従来のオンラインでの講習会よりも講師と受講者のコミュニケーションをとりながら講習会を進めることができました。

また、オフラインでの開催だったため、隣の座席の受講者同士で教え合う様子なども見られ、置いてけぼりの受講者が従来より生まれにくくなった手応えを感じました。

実際、講習会後にとったアンケートでも「ちゃんと初心者向けでついていけた」「初歩的な質問でもすぐに回答頂けたので、とても理解できた」などの感想が多く見られました。

Looker講習会の今後

今回実施した少人数制のLooker講習会にも、まだまだ課題は残っています。

例えば、現在の方式では一度に少ない人数しか参加できないので、社内全体へLookerの使い方を広めるには講習会の回数を重ねる必要がありますし、講習会をオフライン開催のみにしてしまうと、地方支社に所属するメンバーにLookerの使い方を学ぶ機会はなかなか提供できません。

これらを解決していくため、今回の少人数制のLooker講習会の取り組みを踏まえ、今後も継続してLooker講習会の運営方法の改善を続けていこうと考えています。

We’re hiring!

タイミーでは、一緒に働くメンバーを募集しています。

https://hrmos.co/pages/timee/jobs

カジュアル面談も実施していますので、少しでも興味を持っていただけましたら気軽にご応募ください!

学生向けに講演する中で考えた、データサイエンティストの仕事像と未経験就職

こんにちは、タイミーでデータサイエンティストとして働いている小栗です。

先日、群馬大学にご招待いただき、大学生向けにキャリアに関する講演を行いました。

講演や学生との交流を行うにあたり、データサイエンティストの仕事やキャリアについて考える時間が自然と発生しました。

この記事では、学生からいただいた以下の質問をテーマに据えて、私やタイミーの事例を紹介しつつ考えてみます

  • 大企業とベンチャー企業のデータサイエンティストはどう違う?
  • 未経験からデータサイエンティストを目指すには?
続きを読む

「チームで育てるAndroidアプリ設計」の輪読会を行いました

はじめに

こんにちは、タイミーでAndroidエンジニアをしているsyam(@arus4869)です

昨年、「チームで育てるAndroidアプリ設計」という本について、計10回にわたって輪読会を実施しました。本書は「アーキテクチャとチーム」に焦点を当てた一冊になっており、タイミーのAndroid組織の技術顧問としてさまざまなサポートをしてくださっている釘宮さん(@kgmyshin)が著者として名を連ねている本になります。

この記事では、技術顧問の釘宮さんとAndroidメンバーでの輪読会で得た学びをシェアできたらと思っています。

輪読会の説明

週に1回テーマを設けてAndroid会という勉強会を実施しています。

勉強会の中では、miroを利用した輪読会を実施しています。

輪読会は参加者の「感想」や「勉強になったこと」を共有し、「わからなかったこと」、「話してみたいこと」について議論しながら深掘りをし、学びを得ています。

学びと実践への応用

セクションごとに学びがありましたが、特に実践へ応用された部分について抜粋して紹介しようと思います。

アーキテクチャを図にしてREADMEに見える化しました。

第2章の中にある多層アーキテクチャの例が非常に参考になったので、今のタイミーのアーキテクチャはどうなっているかも気になり、miroを利用した輪読会ならではの「その場で図にする」というワークを行いました。

下記は輪読会中に実際に図を描いた様子です。

Miroのワークの様子
Miroのワークの様子

タイミーでは、4層アーキテクチャから3層アーキテクチャに変遷した歴史があり、今もレガシーコードとして残っているので、新旧のアーキテクチャをREADMEに記載することにしました。この時に明確にできたおかげで、新規参画者への説明のハードルが下がり、輪読会の議論がとても良いきっかけになりました。

下記は輪読会で図にしたものを改めて整理して、READMEに記載したものです。

アーキテクチャの概要図
アーキテクチャの構成図

モジュールごとにREADMEを用意することにしました。

本書の第3章ではアーキテクチャの理解と適用を促進し、チームの生産性向上にどう貢献するか紹介されていました。特に理解の促進のためには、アーキテクチャの概要図やパッケージ構成、各層、クラスの説明をドキュメント化することが推奨されており、チームでもREADMEに記載することになりました。 また輪読会の中では、モジュールにも説明が必要ではないか?と議論が発展しモジュールの説明も各モジュールごとに用意することになりました。

モジュールについて
モジュールについての議論

タイミーのAndroidアプリでは、Featureごとにモジュールを分割しているので、モジュール数が多岐に渡っており、モジュールの解釈に認識齟齬が発生するリスクがありました。モジュールに対してもREADMEを記載するアプローチを生んだのは、良い議論に発展したおかげだと思います。

また、モジュールの書くべきことについては、本書に書いていない内容だったので、筆者の釘宮さんに改めて確認することができたのは、筆者が参加する輪読会ならではでとても有り難かったです。

終わりに

タイミーでは定期的に輪読会を開催しております。

輪読会では、本を読んでただ学ぶだけでなく様々な議論がおこなわれ新しい洞察を発見する場となっています。

本輪読会で取り扱った「チームで育てるAndroidアプリ設計」についても新しい洞察が得られ実際に実務への応用に発展しました。是非一度よんでみてください!

少しでもタイミーに興味を持っていただける方は、ぜひお話ししましょう!

product-recruit.timee.co.jp

Ruby 3.3.0+YJIT本番運用カンパニーになりました

こんにちは。バックエンドエンジニアの須貝(@sugaishun)です。

今回はタイミーが本番運用しているRailsアプリケーションに対してRuby3.3.0へのアップデートを行った(YJITは引き続き有効なまま)のでその結果をご紹介したいと思います。

昨年弊社のid:euglena1215が書いたエントリーのRuby3.3.0版です。

tech.timee.co.jp

前提

タイミーのWebアプリケーションとしての特性は基本的には昨年と変わりありません。ですので、昨年の内容をそのまま引用させてもらいます。

タイミーを支えるバックエンドの Web API は多くのケースで Ruby の実行よりも DB がボトルネックの一般的な Rails アプリケーションです。JSON への serialize は active_model_serializers を利用しています。

今回の集計では API リクエストへのパフォーマンス影響のみを集計し、Sidekiq, Rake タスクといった非同期で実行される処理は集計の対象外としています。

今回はRuby3.2.2+YJITからRuby3.3.0+YJITへアップデートを行い、パフォーマンスの変化を確認しました。

結果

以下のグラフはAPIリクエスト全体のレスポンスタイムの50-percentileです。

グレーの点線がアップデート前の週で、青い線がアップデート後の週になります。集計した期間ではアップデート前後の平均でレスポンスタイムが10%高速化していました。

今回も前回にならってレスポンスが遅く、時間あたりのリクエスト数が多いエンドポイントに注目し、タイミーのWeb APIのうち3番目に合計の処理時間が長いエンドポイントへのパフォーマンス影響を確認しました。

以下のグラフは3番目に合計の処理時間が長いエンドポイントのレスポンスタイムの50-percentileです。こちらも同様にグレーの点線がアップデート前の週で、青い線がアップデート後の週になります。集計した期間ではアップデート前後の平均でレスポンスタイムが約12%高速化していました。

またECSの起動タスク数にも良い変化がありました。

タイミーではCPU使用率が一定の割合になるようにタスク配置する設定をしているのですが、リリース後は起動タスク数が減りました。リリース前後1週間の比較で下記のように変化しています。

  • 平均で33.1 tasks → 30.36 tasks
  • 最大値で58.6 tasks → 53.0 tasks

このあたりはYJITの効果でリクエストに対するCPU負荷が下がった影響ではないかと推測しています。メモリ上に配置した機械語を実行するJITならでは、という感じがします。コスト的にどれだけインパクトがあるか具体的な数値は出せていませんが、パフォーマンス以外のメリットもありそうです。

と、ここまでは良かった点です。

以降では自分たちが遭遇した事象について述べたいと思います。

一部のAPIでメモリ使用率が増加

タイミーのRailsアプリケーションはモノリスですが、ECS上ではネイティブアプリ向けのAPIとクライアント様の管理画面向けのAPIはそれぞれ別のサービスとして稼働しています。前者のネイティブアプリ向けAPIでは特に問題なかったのですが、後者の管理画面向けAPIではメモリ使用量の最大値が約3倍超(20%弱→65%程度)になりました。以下のグラフの赤いラインがRuby3.3.0にアップデートしたタイミングになります。

さすがに3倍超は困ったなと思い、YJITのREADMEを読んだところ下記のようにありました。

Decreasing --yjit-exec-mem-size

The --yjit-exec-mem-size option specifies the JIT code size, but YJIT also uses memory for its metadata, which often consumes more memory than JIT code. Generally, YJIT adds memory overhead by roughly 3-4x of --yjit-exec-mem-size in production as of Ruby 3.3. You should multiply that by the number of worker processes to estimate the worst case memory overhead.

We use --yjit-exec-mem-size=64 for Shopify's Rails monolith, which is Ruby 3.3's default, but smaller values like 32 MiB or 48 MiB might make sense for your application. While doing so, you may want to monitor RubyVM::YJIT.runtime_stats[:ratio_in_yjit] as explained above.

メタデータ(yjit_alloc_size)の増え方が想定以上なのではと思いつつ、ddtrace*1ではyjit_alloc_sizeは送信していないようなので、code_region_size を確認。実際、YJITのcode_region_size(JITコードのサイズ)とメモリ使用率はほぼ同じ動きをしていました。以下のグラフの左がcode_region_sizeで、右がメモリ使用率です。

というわけで--yjit-exec-mem-sizeをデフォルトの64MiBから32MiBに減らしたところ、メモリ使用量はアップデート前より少し増えた程度の水準まで抑えることができました。なお、この変更によるパフォーマンスへの影響は見られませんでした。

以下の右のグラフがメモリ使用率で、赤いラインが--yjit-exec-mem-sizeの変更をリリースしたタイミングになります。実際にメモリ使用率が下がっているのが見て取れます。

今回のメモリ使用量の大幅な増加は完全に予想外で、ステージング環境でもメモリ使用量の変化はウォッチしていましたが、特に大幅な増加は見られず本番環境で初めて発覚する事態になりました。すでにRuby3.2系でYJITを有効にしているプロダクトでも、Ruby3.3.0+YJITにアップデートされる際には--yjit-exec-mem-sizeの値には注意したほうが良さそうです。

まとめ

Ruby3.2ですでにYJITを有効にしているプロダクトでもRuby3.3.0にアップデートしてパフォーマンスの改善が見られました(YJITの影響なのかそれ以外の最適化による恩恵なのかまでは検証しておりません)。

すでにYJITを有効にしていた場合でもRuby3.3.0へのアップデートでメモリの使用量が大幅に増加する可能性があるので注意しましょう。

調査の際には下記の(主にk0kubunさんの)ドキュメントに非常に助けられました。この場を借りてお礼を申し上げます。

github.com

k0kubun.hatenablog.com

gihyo.jp

本エントリーがこれからRuby3.3.0+YJITへアップデートされる方のお役に立てば幸いです。

*1:タイミーはDatadogを使っています。ddtraceはDatadogにメトリクスを送信するgemです

【Front-End Ops/イベントレポート】「いつか来たる大改修のために備えておくべきn個のこと」

イベント概要

2024年2月21日に「GENBA #2 〜Front-End Opsの現場〜」と題してタイミー、Sansan、ココナラ、X Mileの4社でFront-End Opsに関する合同勉強会を開催しました。 今回はそちらの勉強会からタイミーフロントエンドエンジニアの西浦太基さんの発表をイベントレポートでお伝えします。

こんにちは、西浦 太基です。家族で北海道札幌市で暮らす33歳です。 Javaでキャリアをスタートし、今はフロントエンドエンジニアとして3年目になります。趣味はカレー作りとゲームです。

本日は「いつか来たる大改修のために備えておくべきこと」について、実際に大きな改修を経験して学んだこと、泥臭い現場の話や反省点を、エピソードベースでシェアします。

1. どんな大改修だったか

店舗向けの管理画面をシングルページアプリケーション(SPA)へ移行する改修でした。もともとサーバーサイドレンダリング(SSR)で構築されていたシステムを、ReactとNext.jsを使用したSPAに段階的にリプレイスしていきました。改修した機能は大きく下記3つです。

  1. 求人機能(作成/編集)
  2. 求人ひな形機能(作成/編集)
  3. メッセージ機能(一覧表示/送信)

2. 泥臭かったこと

既存機能の仕様調査に苦労 既存のSSR画面の詳細なドキュメントが残っておらず、非常に苦労しました。これは、タイミー入社前のSler時代もよく経験したことで、 “あるある” なのですが、状況を打開するためには非常に泥臭い調査が必要です。もちろんドキュメントが全く残っていないわけではなく、Figma や Notion に部分的に残されてはいたのですが、完全にはカバーされていません。おまけにソースコードの情報が必ずしも正確でないこともあり、かなりの時間と労力をかけ、調査を行いました。

E2E自動化の仕組みがなく、431件のE2Eテスト項目に自動テストを実施した

ユニットテストはコンポーネント単位で存在していましたが、E2E自動化の仕組みが存在しませんでした。VRT(Visual Regression Testing)は、Storybook を用いて行われていたのですが、今回のプロジェクトの規模や顧客への影響を考えると、軽い検証を行うだけではリスクが大きいと判断し、結果的に 431件の E2Eテストを手動で泥臭く実施する道を選びました。

レビュー体制がなく、レビューコストが大きくなった

当時のフロントエンドチームはレビュー体制の整備が不十分で、メンバーも限られており、レビューコストが高くなってしまいました。チームは僕を含めてわずか2人と、非常勤の業務委託1人。レビューに十分な時間を確保するのが難しく、プロジェクトの進行に影響が出ていました。そのため、レビューを効率的に進めるために、一人のエンジニアの時間をまとめて確保し、一気にレビューを完了させる方法を取りました。本来は、フルリモートでの非同期レビューを行える体制が理想的だと思います。

3. 備えておくべきと感じたこと

機能の仕様は背景込みで残しておく 詳細なソースコードコメントや定義書があれば、将来の改善に役立ちます。特に複雑な機能や多くの入力項目を持つ場合、実装の背景を理解することで、後々の改善が容易になり、属人化を避けることができます。最近は、Figma や Notion に仕様と背景を含めて記録するよう心がけています。

自動化テストの仕組みを導入する

これまでUTやVRTが充実していれば、そこまでE2Eは重要ではないと考えていました。しかし、今回のリプレイスを経て、自動化テストの重要性を再認識しています。E2Eによって、UTで検知できない問題をリリース前に特定できることがあり、改めてE2Eの重要性と自動化の利点を実感しました。

レビュー時の観点を整備

  • レビューの文化を根付かせておく
  • 同時にレビュー時の観点や視点に関してチーム内で明文化
  • ドキュメント化することで普段からレビューコストを下げておく

レビュー文化をしっかり根付かせつつ、レビューのポイントをチーム内でしっかりドキュメント化しておくことが大事です。ドキュメント化してないと、都度のすり合わせで時間を取られ、レビューコストが増えます。その結果、リリースサイクルも遅れたりするわけです。現在はフロントエンドチームの拡大もあり、レビュールールを明文化する作業を進めています。

まとめ

私がSler時代に直面した、「ソースコードを見なければ仕様が理解できない」といった “あるある” な内容も含め、日頃から大きなリプレイスに向けた心構えや備えが必要性を共有できたら嬉しいです。泥臭い作業を発見したら、悲観的になるのではなく「これは考え直すタイミングだな」というマインドを持つことも大切かと思います。

  • n個と言いつつそこまで数は挙げられなかった
  • 日頃から大規模リプレイスに備えた心構えをしておくことは大事
  • (何が起こるかもわからないので)かもしれない運転
  • あるあるな内容になったと感じている
  • Timee以外のプロジェクト(SES就業時代)でも直面した事が多かった
  • 泥臭いこと゠備えておくべきこと、に繋げるマインドが大事に感じた

その他の方の発表も気になる方はこちら!

www.youtube.com

少しでも興味を持っていただいた方は是非こちらからカジュアルにお話しましょう!

devenable.timee.co.jp