🍎食べチョクアプリのFlutter化とMaterial Design 3 導入！デザインマスター刷新の舞台裏 🚀

はじめまして。食べチョク（株式会社ビビッドガーデン）のデザイナー千田です。
2024年11月、食べチョクアプリのFlutter化が無事完了しました。この機会に、プロジェクトの背景、進行過程、学びについてお伝えします。

Flutter化の背景

導入前は、アプリ開発をiOSとAndroidそれぞれで行っていたため、開発工数が二重で発生しており、かつ差異が生じていました。そこで、Flutter（複数のプラットフォームに対応したアプリケーションを一つのコードで開発できる）を導入し、根本的な開発工数削減と、これまで以上に新しい取り組みを実現できる状態を目指すこととなりました。

Flutter化前の状態

デザインマスター（Figma）

• ページによってデータがあったりなかったりの歯抜け状態😞
• 実装とデザインマスターに差がある（でもしょうがないよね）状態😞
• iOS版を基盤に作成されており、Androidは「よしなに」状態😞

実装

• iOSとAndroidで二重開発😞
• AndroidはiOS版のデザインを見て「よしなに」作っていた😞
• インタラクションは「よしなに」作っていた😞

Flutter化=アプリの開発コードの刷新が主題ではありますが、Figmaで作られている食べチョクアプリのデザインマスターにも様々な問題が発生していました。デザインデータ自体の見直しもミッションの1つとなり、そこでUIデザイナーとして私がアサインされることになったのです。

Flutter化の取り組みに関わったメンバー

UIデザイナー

コンポーネント、マスター、インタラクションの作成を担当

• 私
• 通称ずっきーさん

トークン作成

• デザインチームのマネージャー 松久さん
• 外部の協力会社のデザイナーさん

アプリエンジニア

• iOSエンジニア
• Androidエンジニア

※本記事では、UIデザインやマスターデータに関することを主にお伝えするため、エンジニア・QA・プロジェクトオーナー等は要約しています。

私は何者？

2023年11月に食べチョク（株式会社ビビッドガーデン）へUIデザイナーとしてジョインしました。これまで、グラフィック、WEBデザイン、ディレクションを経験してきましたが、前職はディレクターとして動く場面が多かったため、Figmaの使用歴も約6ヶ月間程度と自信を持って使いこなせているとは言えない状態でした。また私自身は、前段の背景にもあるFlutterの導入の議論に参加しておらず、実働決定後にアサインされています。

というのも「Flutter？Material3って何？」と問い返してしまうほど、アプリデザインの経験や知識はほぼ皆無に近い状態でした。

で、デザイナーは何をしたのか？

• 食べチョクアプリで実存している全ページのマスターデータを作成
• デザインマスターを正として実装との整合性を確保
• デザインフレームワークのMaterial3を元に
  • トークン（色、スペーシング、タイポグラフィ）を作成
  • コンポーネントを作成
    • 個別でインタラクションを設定

前述の通り、デザインデータは歯抜け状態でガイドラインも明確な定義がない状態にありました。理想をいえばオリジナルのガイドラインを設定したいところではありますが、今回の取り組みはあくまで開発環境を整えるスタートに立つためのものです。 最短でガイドラインを設定するためにも、まずはGoogle が提唱しているMaterial Design 3をベースにトークン・コンポーネント・インタラクション等を設定していきました。

コンポーネントとインタラクションの設定

「設定していきました」とさらりと書くとそれまでですが、Material Design 3をベースとするためには事前にインプットする作業が必要になります。正直に言うとそのインプットが本当に苦しい苦しい時間でした。Material Design 3という教科書を読み、それを現状のデザインに当てこんでいくという作業を、コンポーネントの1つ1つに対して設定するのです。

Material Design 3 のページのキャプチャ

英語だし、自動翻訳すると意味が分からなくなるし、ざっくり理解だと突っ込まれるし…と、私もずっきーさんも「よく頑張った！」と思っています。

取り組みの振り返り

2023年の8月に議論をスタートしたFlutter化は、2024年11月にリリースすることができました。最初から最後までエンジニアの皆さんはそれはそれは大変な偉業を達成されましたが、そこはエンジニアの皆さんによって語られることを期待して割愛します。

😞BAD（反省点）

• マスター作成初期時点はトークンをあまり理解できていなかったので、後々エンジニアから指摘が多々あった
  • それぞれのカラーに設定した「意味」を考慮せず、見た目だけで設定してしまったことが原因
• スピード優先 & 現状前提でマスター作成をしたため、UIデザインの改善は最小限に止まってしまった
• エンジニアからのコメントに対して返信漏れ等が多発したため、コメントの使い方は見直しを実施することに
  • コメントの中身が即座に解消できる問題であれば「✅解決」で残さない
  • 時間がかかるものはissue化をする

    

    放置されてしまったコメントの一例

☺️GOOD（よかった点）

💪経験値💪

• トークンの設定を外部デザイン制作会社に協力を依頼して完成させた
  • Material Design 3の知識があるメンバーがいなかったため、一から学びながらやるのではなく知識がある人に協力をあおぎ、スピードと精度をUP
• インラクション設定の際にMaterial Design 3を読むことが必須となった為、苦しいながらもインプットをすることが出来た

⚙️運用面⚙️

• トークンを設定することでデザイナーとエンジニアの認識の齟齬がなくなった
• エンジニアから「とても開発しやすかった」という声多数
• デザイナー同士で各ページやコンポーネントのデータ作りのレベルまで相互のレビューとFBを行ったこと
  • Figmaの機能/知識を吸収できる
  • トークンの設定漏れを防ぐことができる
  • コンポーネントの命名をなんとなくでつけず、命名規則から見直しを実施
• Material Design 3を基準に制作するという前提が関係者の中で共通認識が取れている
  • 各個人の主観ではなく、Material Design 3を元にUIデザインのあるべき姿を検討することが出来た

最後に

実は、リリースされるまではデザイナーが行ったことの影響範囲を私自身があまり理解できていなかったのです。ところが、Flutter化の振り返りを実施した際にエンジニアの皆さんから「トークンやマスターの作成があるおかげで実装しやすかった」とお褒めの言葉をたくさんいただき「そうなのか😳」と影響範囲を実感することができました。 デザイナーの中でもフロントに強いデザイナーが存在していたことで、今回のような実装までを考慮したデザインマスター作成まで一歩踏み込んで考えることができたのではと思っています。
デザイナーもエンジニアも未経験の分野を学びながら、議論しながら、頭を抱えながらの取り組みは、難しくも良い経験と自信になったといえます。 効率的なアプリ開発の基盤が整ったので、さらにより良いサービスを提供できるようにこれからもチームで前向きに取り組んでいきます。

生成AIを活用してGitHubのIssueをSlackから簡単に起票できる仕組みを作った話

皆さんこんにちは、ビビッドガーデンCTOの西尾です。 今回はGitHubのIssueをSlackから簡単に起票できるツールを開発し、運用しているお話をしたいと思います。

Issueの起票は意外と手間がかかる

弊社ではエンジニア、ビジネスメンバーともにGitHub Issuesにて課題管理をしています。 Issueに記載する内容はいくつかテンプレート化されているのですが、以下のような内容を記載することが多いです。

## 💫 目的や背景
## 💪 実現したいこと
## 🉑 受け入れ基準
## 📎 資料
## 🔧 タスク

Issueは誰が見てもわかりやすい記載をするのがベストではあります。

しかし、こんなことをいったら怒られてしまうかもしれませんが、このIssueを起票するという行為、さらにいうと文章をきちんと考えるのが意外と億劫だったりします。

弊社でも、「〇〇をIssue化しておいてくれませんか?」みたいなやりとりが発生することがたびたびありました。

生成AIを活用して、Slack上での会話を元にいい感じにIssueを起票する

Issueを起票をする前は、たいていSlack上でディスカッションをしていたりします。

これまでは、その会話を元に誰かがIssue化していたのですが、これをChatGPTにまるっとお願いしたら楽できるのでは? と思い、社内用のツール「alpha」を作りました。

例えば、Slackでディスカッションした内容をもとにalphaに依頼すると、自動でGitHub Issueしてくれます。

以下はその動作例です。これは適当な会話と適当なIssueですので、ご了承ください。

せっかく生成AIを使っているので、壁打ちできる機能も搭載しています。 Slackのスレッド上でいろいろディスカッションし、alphaにIssue化してと依頼をすると、以下のようにGitHub Issueが自動で起票されます。 過去の自分の発言やSlackスレッド内の会話を踏まえて、Issue化されます。

ツール alpha の仕組み

ここからは作成したツール alpha の仕組みを紹介します。

現時点では社内向けのコードが書かれているため、残念ながらソースコードがそのまま公開できません😢 これはどこかで直して公開できればいいなあとは思っています。

alphaはAWS Lambda上で動作しており、データはDynamoDBに保存されています。コードはRubyで書かれており以下のように動作します。

1. SlackのEvent Subscriptionsの仕組みを使い、alphaにメンションされたら会話をAWS Lambdaに通知する
2. メンションされた会話はDynamoDBに保存する
   • いままでのコンテキストを踏まえて動作するために、過去の発言はDynamoDBにいれておき参照する
3. Issueを起票するべきか、ただ壁打ち相手となってもらうかのどちらのアクションをとるべきか、まずは判断する
   • 壁打ち相手になってほしい場合は、いままでの発言を含めてChatGPTに送り文章を生成して返す
   • Issueを起票すべきと判断して場合は、Step4に進む
4. いままでの会話を踏まえて、Issueを起票する
   • Issueを起票すべきと判断した場合は、まずメンションされたスレッド内の会話をSlack APIで引っ張ってくる。会話が長いとChatGPTに渡せないので、ある程度要約をするというアクションも必要であれば取る
   • Issueのタイトルと本文をChatGPTで生成する
   • GitHub APIを利用して、Issueを起票する
   • 起票したIssueのURLをSlackのレスポンスとして返す

具体的には以下のようなコードを実行しています。 まずStep3では次に実行すべきアクションをChatGPTに判断してもらいます。

def get_action_command(message)
    messages = [
      {
        role: "system",
        content: <<~COMMAND,
          チャットボットです。回答は必ず日本語でしてください。
          あなたは以下コマンドを実行できます。ユーザーのメッセージをもとに、実行するコマンドを返してください。
          #{' '}
          A001. GitHubのIssueを起票する
          C003. 上記に当てはまらないコマンド

          コマンドを実行する場合は、コマンド番号を返してください。
          次にユーザーからのメッセージを送ります。
        COMMAND
      },
      {
        role: "user",
        content: message,
      }
    ]
    response = @client.chat(
      parameters: {
        model: "gpt-4o",
        messages: messages,
        temperature: 1.0,
      },
    )
    response.dig("choices", 0, "message", "content")
end

次にとるアクションをコマンド形式で返したあと、以下のように処理を振り分けます。 A001 なら Issue起票、それ以外ならいままでの会話をもとに壁打ちします。

  def dispatch_action(user_id, message, channel, timestamp, thread_timestamp)
    com_message = get_action_command(message)

    case
    when com_message.include?("A001")
      @slack_action.add_reaction(channel, timestamp, "github")
      summary = summary_thread_message(channel, thread_timestamp)
      github_title = get_github_issue_title(message, summary)
      github_message = get_github_issue_pbi(message, summary)

      create_message = create_github_issue(github_title, github_message)
      @slack_action.send_message(channel, create_message, timestamp)
    else
      ai_response = get_memory_openai_response(user_id, message)
      @slack_action.send_message(channel, ai_response, timestamp)
    end
  rescue => e
    pp e
    @slack_action.add_reaction(channel, timestamp, "dango")
  end

Issueを起票するための文章生成は、以下のようなコマンドを投げています。 ここは都度チューニングしていく必要があります。

  def get_github_issue_pbi(message, summary)
    com_messages = []
    com = <<~COMMAND
            あなたはプロダクトマネージャーです。GitHubのIssueを作成してください。だ、である調で書いてください。
            形式は以下のようにしてください。あなたの発言はそのままIssueとして作成されますので、回答は余計なメッセージを記載しないでください。

      ## 💫 目的や背景

      ## 💪 実現したいこと

      ## 🉑 受け入れ基準
                   #{'  '}
    COMMAND
    com_messages << { role: "system", content: com }

    com = <<~COMMAND
      次にいままでのコンテキストを渡します。この発言が関係あれば、それをIssueに反映してください。

      #{summary}
    COMMAND
    com_messages << { role: "system", content: com }

    get_openai_response(message, additional_messages: com_messages)
  end

最後にIssueをAPI経由で起票します。

require "octokit"

class GithubAction
  def initialize
    @client = Octokit::Client.new(access_token: ENV.fetch("GITHUB_TOKEN", nil))
  end

  def create_issue(repo:, issue_title:, issue_body:)
    issue = @client.create_issue(repo, issue_title, issue_body)

    issue.html_url
  rescue Octokit::Error => e
    puts "Error creating issue: #{e.message}"

    ""
  end
end

おわりに

Slackから気軽にIssueを作成できる仕組みを作成し、運用をはじめています。 社内でも少しずつ使われはじめています。

生成AIを活用することで、これまで煩わしかった作業を自動化できました。 AIを活用してどんどん楽をしていきたいですね!

アサインの悩みを解決するための取り組み

こんにちは、松久です。

デザインチームでは日々いろいろなことに取り組んでいます。 取り組むタスク（バナーづくりや、UIデザイン、マークアップなど）は、GitHub Project で issue を使って管理しています。 管理はしているのですが、誰が取り組むのかを決めていく上で悩ましいことがあります。 それは担当者の割り振り方法です。

今回は、悩んでいて解決していないアサインの話です。

現在のアサインの決め方

現在は、マネージャー（松久）が issue を見ながら誰に担当してもらうかを決めています。 issue には、グラフィック（バナーや、印刷物など）やUI など様々な依頼の種類があり、それぞれ得意な人にお願いしています。 なにかトラブルが起きているわけではないのですが、私が取りまとめて依頼をしているので「自主的に取り組んでいる」とはいい難く、私がいないと誰が何をやるのか決まらないことになっています。

このような状況になっている理由は以下の通りです。

• issue をみんなが揃っている時に、みんなで見ていない
  • チームメンバーには限られた時間帯で稼働している人もいる（約半分）ため全員が揃う時間は有りません
  • issue を見て何をするのか判断して業務に取り組んでもらう必要があります
• 何をするのか書いていないissueがある
  • 何を実現したいのかわからないので、担当者に聞いて確認したり、相談したりすることが必要になります
  • issue の担当者に詳細を聞くとしても、担当者とデザイナーで勤務する時間帯が必ずしも同じとは限らず、詳細が分かるまでに待機時間が発生することもあります。
• 急ぎの取り組みが多い
  • 20営業日の間に平均14件前後の急ぎがあります
  • 急ぎの対応が必要な場合、自主的に取り組むのではなく、なんとかする！という気持ちで担当を決めてしまうことが1日に1回ぐらい発生しています

この状態だと、やらされている感がどうしても出てしまいます。チームで成果を出していると感じることも少なくなりそうです。

少しでも解消するために

何をするのか書いていないissueを減らしたり、わからない状態を脱しやすくする取り組みを始めました。issue に書いていない、読んでもわからないことをハッキリさせるために、GitHub Project のボードに「Un Ready」というカラムを用意して issue を入れることにしました。 このカラムのことを他チームとも共有して、空のissueに情報を書いてもらったり、取り組むための情報が足りていないことを知らせることが出来るようになりました。

おわりに

理想はあるけれど、いくつかの理由で現実との差分が生まれている状態です。 いちどに全部を解決することは難しいですが、1つ1つ解決をしてチームで「食べチョク」の改善ができるようにしていきます。

デザインチームの業務効率化を目指し #Figma プラグインの開発に挑戦

こんにちは、松久です。

食べチョクのデザインチームでは、Figma を利用して日々の業務をしています。 Figma は、何かを作り、様々な職種の人とコラボレーションをすることに長けたツールです。細かいアップデートで使い勝手が良くなることも多いので、Figma を使っています。

Figma の特徴の1つにプラグイン機能があります。審査が通ればプラグインによる機能拡張ができます。
今回は、特徴の1つである Figma のプラグインを自作して普段の業務にある面倒くさいを減らす試みの話です。

プラグインを作るきっかけ

毎月作成しているバナーを一覧ファイルにまとめ、過去の履歴を辿りやすくするという業務があります。
ただ、手作業で作成しているため手間も多く、間違い・漏れが発生しやすい状態でした。

毎月のバナー制作一覧

手作業をある程度でも自動化できないかと思ったのが、プラグインづくりのきっかけの1つです。
もう1つは、自身の開発機会が減っていたこともあり、「プラグインづくりにて TypeScriptを用いた開発機会を補いたい」という目的もあります。

プラグインを作り始める

ドキュメントを読めば始められるのですが、英語のドキュメントなので不安がありました。そんなときに、Figma Office Hours で「デザインと開発の生産性向上: Figma APIによる自動化とプラグイン開発」が 開催されました。 そこに 参加し全体像を知った上で、 ドキュメントを読みつつ、開発を始めることができました。

https://www.figma.com/community/file/1355039140557528563/www.figma.com

プラグインを作るときに困ったこと

プラグインを作る時にドキュメントを読めばわかるけれど、すぐにはわからなかったことをいくつか紹介します。

色指定

RGB では 255 までの指定ではなく 0〜1までになります。なので、 255 で割りました。

color: { r: 184/255, g: 28/255, b: 37/255 }

点線

点線は プラグインの API は dashPattern で指定します。 REST API では異なります。

frame.strokes = [{ type: "SOLID", color: { r: 0, g: 0, b: 0 }}];
frame.strokeWeight = 10;
frame.dashPattern = [20, 20];

findAll で取得した node は 全て SceneNode型になる

このため、Section だけを取得したつもりが、SectionNode ではなく SceneNode になっています。

const page = figma.currentPage;
const sectionNodes = page.findAll(node => node.type === 'SECTION');
// MEMO: findAll で取得すると SceneNode になる。SectionNode ではない。
// https://www.typescriptlang.org/docs/handbook/advanced-types.html
// https://forum.figma.com/t/type-scenenode-is-not-assignable-to-type-componentnode/19694/2
sectionNodes.forEach((sectionNode) => {
  const section = sectionNode as SectionNode;
  section.children.forEach((child) => {
    if(child.type === 'FRAME') {
      const frame = child as FrameNode;
    }
  });
});

非同期処理が多い

フォントの設定なども非同期になっています。そのため思った以上に1つのプラグインの中に非同期処理があります。

料金プランで使えない機能がある

API があることは確認したのですが、料金プランによっては使えないことが後からわかり残念でした。

おわりに

月に1回だけ使うプラグインですが、Figma で公開をしています。料金プランによっては、チーム内で公開できる機能もあり、社内特有のルールにあわせたプラグインを作ることも可能なようです。

プラグインを作ってみて、制作時に使うだけではなく、日々のメンテナンスのためのプラグイン作成もありだとわかりました。

日々の業務で出てくる面倒を減らすため、プラグインを作ることにも取り組んで「食べチョク」の改善を進めていきます。

デザイナー間での桃色の共有化と改善による成果

こんにちは、松久です。

今年も「桃」の季節になりました。
食べチョクでは、昨年に引き続き「夏の桃ラボ」と題して、色々な桃を味わえる特集をしています。デザインチームは、桃の特集を今年も実施するだろうと予想し、2 月頃から準備をしてきました。

品目毎の色パレットを作る

準備したのは、品目毎の色パレットを作ることです。
きっかけは、「桃やぶどうのような同じ品目でバナーを作る前に事前準備したこと」で紹介した品目毎の特集の色の管理で良かったことを徹底し、できなかったことを減らしたい気持ちからでした。

数人のグラフィックデザイナーでバナーなどを作るときに、それぞれが色を検討すると時間もかかりますし、色もなんだかバラバラになっていきます。また「食べチョク」らしさというのも揃えにくいことを感じていました。

「Starbucks Creative Expression」を参考にして、品目毎のカラーパレットを作ることにしました。「Starbucks Creative Expression」は、スターバックスを利用するお客様の体験のため作られたクリエイティブに関する事例の集まりになっています。

GGitHub issue に要件をまとめつつ検討を開始し、グラフィックデザイナーが中心となって、Figma 上で形にしていきました。 昨年の制作物を活かしつつ、他の色ともバランスをとって作っていくことができました。

GitHub issue を用意して、目的や取組方法の案を書き始めました

Figma で制作を始めて色の配分なども含めて検討

実際に作ってから

2 月末ぐらいから始めて、4 月末ぐらいには夏頃の品目について準備ができたので制作を担当したグラフィックデザイナーから、デザインチームの他メンバーへ共有しました。 社内で運用している esa に色のページを設けてメルマガなどでも使えるように周知を始めました。ここは、去年は取り組めなかったことなので、適用できる範囲を広げることができました。

バナーと特集ページを作ってから、esa で色の共有を始めました

運用を始めると、足りないこともわかってきました。
例えば、グラデーションはどうするか？ありなのか？なしなのか？色だけじゃない表現サンプルは必要なのか？などが話題にでました。もっと良くするための話ができたのは、次回に向けての大きな収穫でした。

おわりに

「桃色」のパレットを作ったのでデザイナー間で「桃色」が共有化できていることを感じています。共有化したことで、足りないところも見つけることができました。 気づいた足りないことも、今後埋めていくことで「食べチョク」の改善を進めていきます。

Figmaプラグイン「Google Sheets Sync」を活用したSNS投稿用画像生成

こんにちは松久です。

「生産者さんだから知っている そのままおいしい野菜の食べ方」が先日発売されました。本には生産者さんからの知恵が色々掲載されています。そこで、生産者さんが本の紹介をX（旧Twitter）やInstagram で投稿しやすいように、生産者さんごとの投稿用画像を用意することになりました。

この本には生産者200名ほどの方が掲載されています。そのため、生産者さんごとに掲載されているページや、品種・品目の情報がある画像を用意する必要があります。そこで、Figma の「Google Sheets Sync」を使って投稿用画像を生成することにしました。

導入までの流れ

作成までの全体の流れは以下のとおりです。

1. Figma でテンプレートを作る
2. 表示するデータを用意する
3. Figma に「Google Sheets Sync」を入れる
4. 実行

Figma でテンプレートを作る

Figma で画像を生成するためのテンプレートとしてコンポーネントを用意します。 コンポーネントを作るときに、レイヤー（Groupなど）の名前に #producer_name というふうに # を頭につけ、Google スプレッドシートの項目と一致させる必要があります。 データを入れたあとのことを想定し、文字数などでレイアウトが変わることもあるので、AutoLayout を使う必要があります。

コンポーネントを作ったら、生成が必要な分のインスタンスを作ります。

表示するデータを用意する

生産者さんのデータを用意するために、Redash を利用しました。デザインチームも SQL を書いたら利用できるようになっています。 本の掲載ページ数や、品目・品種については Google スプレッドシートに入れてもらうことにしました。

画像もいれることが出来ます。画像は、公開されているURLで Google スプレッドシートに記載します。今回は、Redash で 画像の URL も生成して用意しました。

Google スプレッドシートのデータを作るときに1行目は、Figma のレイヤー名と合わせる必要があります。ただし、# は抜きます。 準備ができたら、Google スプレッドシートの共有のURLを取得してください。URLは「リンクを知っている人」全員に「閲覧権限」を付与します。

Figma に「Google Sheets Sync」を入れる

「Google Sheets Sync」を開き、Plugin をインストールします。

プラグインを実行して生成する

これで準備は整いました。あとは実行のみです。

1. Google Sheets Sync（プラグイン）を起動
2. Google スプレッドシートの共有リンクを入力して、 Fetch & Sync を押します

少し時間がかかりますが、200枚ほどの画像は生成されました。

おわりに

ダミーデータをいれる時に便利なプラグインなのですが、テンプレートを用意して大量の画像生成もできます。 Figma のプラグインは大変便利なので、普段から使ってみることで急な依頼でも対応できる方法を思いつくことがわかりました。ツールを使いながら「食べチョク」の改善を進めていきます。

宣伝

Amazon などで販売中です。

生産者さんだから知っている そのままおいしい野菜の食べ方

食べチョクでは Ruby3.3.1 + YJIT の運用を開始し、サイトが10%高速化しました

皆さんこんにちは、ビビッドガーデンCTOの西尾です。

食べチョクでは2024年5月23日より、Ruby3.3.1とYJITの運用を開始しました。 その結果、サイト全体のレスポンスが10%ほど高速化されましたので、詳細をご報告いたします。

サイト全体のパフォーマンスが10%高速化

以下は食べチョクの商品詳細ページのパフォーマンスです。

商品詳細ページのパフォーマンスが10%高速化

食べチョクはECサイトであり、商品詳細ページが最もよく見られるページとなっています。 このページのレスポンスが150〜160msだったところが、140ms程度まで改善しました。

最もよく見られるページが10%高速化したことは、すなわちサイト全体のパフォーマンスが10%高速化したということです!

商品一覧ページのレスポンスも改善

商品一覧ページのレスポンスも改善しました。 もともと300ms近くだったレスポンスタイムが、Ruby3.3.1 + YJITの導入により250〜270msまで改善しました。

商品一覧のパフォーマンス

ただし、食べチョク社内ではGETレスポンスタイムを200ms以下にしようという取り組みを続けており、このページのレスポンスタイムはまだ満足のいくものではありません。 引き続きパフォーマンス改善に努めてまいります。

導入にあたり発生したあれこれ

YJITの導入は以前から社内インフラチームで検討しており、Ruby3.3系になったら導入しようと計画していました。 しかし、Ruby3.3.0では動作が不安定になるという問題が発覚したため、導入を見送っていたのがあります。

この問題の関連Issueは https://bugs.ruby-lang.org/issues/20085 や https://github.com/ruby/ruby/pull/9371 です。

2024年4月23日にリリースされたRuby3.3.1でこの問題は修正されましたが、今度はbootsnapに関する不具合が発覚し、Railsが立ち上がらないという問題に直面しました。 関連Issueは https://bugs.ruby-lang.org/issues/20450 です。

このコメントにあるようにパッチを適用することでRuby3.3.1でも動作するようになりました。 具体的には以下コマンドでRubyのインストールをしなおしました。

rbenv install -v --patch 3.3.1 < <(curl -s https://raw.githubusercontent.com/havenwood/rvm-1/696d4f652864109a0cffff62e30a9e405fb0636a/patches/ruby/3.3.1/fix_bootsnap.patch)

パッチを当てることでRuby3.3.1でも動くようになったのですが、このままパッチをあててまで本番リリースするのか、急いでリリースしなくても次のリリースまで待てばいいんじゃないの? といった声はメンバーからあがりました。

ただ、今回はYJITを有効化するとサイトのパフォーマンスが10%向上する! みたいな記事をちらほらみかけ、Rubyを変えるだけでパフォーマンスがあがるんだから導入しない理由はない! という話をしたところ社内エンジニアの納得も得られたので、Ruby3.3.1 + YJIT導入に踏み切りました。

パフォーマンスがあがるといったわかりやすい理由があると、バージョンアップのモチベーションにつながるのだなと感じました。

まとめ

Ruby3.3.1 + YJITを有効化することで、食べチョクのパフォーマンスは10%高速化しました。 Railsを使っている皆さまも、ぜひYJITの導入を検討してみてください。

これからも食べチョクのさらなるパフォーマンス改善に取り組んでまいります。