こんにちは、松久です。 食べチョクのデザインチームでは、Figma を利用して日々の業務をしています。 Figma は、何かを作り、様々な職種の人とコラボレーションをすることに長けたツールです。細かいアップデートで使い勝手が良くなることも多いので、Figma を使っています。 Figma の特徴の1つにプラグイン機能があります。審査が通ればプラグインによる機能拡張ができます。 今回は、特徴の1つである Figma のプラグインを自作して普段の業務にある面倒くさいを減らす試みの話です。 プラグインを作るきっかけ 毎月作成しているバナーを一覧ファイルにまとめ、過去の履歴を辿りやすくするという業務があります。 ただ、手作業で作成しているため手間も多く、間違い・漏れが発生しやすい状態でした。 毎月のバナー制作一覧 手作業をある程度でも自動化できないかと思ったのが、プラグインづくりのきっかけの1つで

皆さんこんにちは、ビビッドガーデンCTOの西尾です。 食べチョクでは2024年5月23日より、Ruby3.3.1とYJITの運用を開始しました。 その結果、サイト全体のレスポンスが10%ほど高速化されましたので、詳細をご報告いたします。 サイト全体のパフォーマンスが10%高速化 以下は食べチョクの商品詳細ページのパフォーマンスです。 商品詳細ページのパフォーマンスが10%高速化 食べチョクはECサイトであり、商品詳細ページが最もよく見られるページとなっています。 このページのレスポンスが150〜160msだったところが、140ms程度まで改善しました。 最もよく見られるページが10%高速化したことは、すなわちサイト全体のパフォーマンスが10%高速化したということです! 商品一覧ページのレスポンスも改善 商品一覧ページのレスポンスも改善しました。 もともと300ms近くだったレスポンスタイム

こんにちは、松久です。 各自で「ふりかえり」をして、人事評価がされます。 私も「ふりかえり」をするのですが難しいです。適切な「ふりかえり」だったのかわからず、手探りで行うことが難しく感じます。 そこで「ふりかえり」をどうやっているのか、まとめてみました。 ふりかえりとはなにか 経験したことを身につける（自分の知恵）にすることです。 反省する（過ちを認める）ことが「ふりかえり」ではないです。 経験したことを身につけるというのは、以下の3つのステップに分解できそうです。 認知：知った・（他者から聞いて）知っている 行動：使った 結果：成功・失敗 経験とは、知ったことをもとに行動し結果を知った状態になることとします。 自分の知恵にするには、これらを「抽象化」して「次の行動を決めること」が必要になります。 経験したことを身につけるための「ふりかえり」は3ステップになります。 経験の確認 経験を抽象

こんにちは、松久です。 日々の"業務"の中には、手作業が定期的に必要で、必要だけれどデザインチームでなくてもいいし、サービスの変化とともに増えていることに気づく業務があります。こうした業務を「トイル」と呼んで減らすようにしています。 トイルとは何か Google がサイト信頼性エンジニア（SRE）の指標の1つとして「トイル」を挙げています。詳しくは「SRE の原則に沿ったトイルの洗い出しとトラッキング」で紹介されています。 トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。 デザインチームでのトイルの例としては次のようなのがあります。 キャンペーンにまつわる色々な表示作業 定期的なバナーの変更 動線の変更 こうした業務をデザイナー以外のチームが取り組みたいタイミングで実行できるようにしたり、できるだけ自

こんにちは、松久です。 昨年（2023 年）、デザインチームに新しいデザイナーが加わりました。新しいデザイナーがすぐ活躍しやすいようにオンボーディングを実施しました。 デザインチームでのオンボーディングとは デザインチームでのオンボーディングが久しぶりなので、改めてオンボーディングの目的を定めました。 入社してきた人が、早く実力を発揮しやすくすること（自分がチームでやっていけそうという感覚を手に入れる） 入社している人が当たり前と思っていたことを改めて確認する機会になること 目的を「入ってくる側」「受け入れ側」の 2 つに分けて、オンボーディングの実施計画を用意しました。 受け入れ側のオンボーディングの目的は、ドキュメントにもなんもなっていないことを言語化してみることで、説明できる状態を目指しました。また、そもそも「当たり前」と思っていることについて、指摘をもらわないと気付けないことが増え

こんにちは、松久です。 先月、デザインチームで 2023 年の「ふりかえり」をはじめました。はじめて、1 ヶ月経ちますが、まだ終わっていません。終わっていませんが、なかなか良さそうだと感じています。 「ふりかえり」をすることにした理由 2023 年は、チームでの「ふりかえり」をしてきていませんでした。してこなかった理由はいくつかあります。 「ふりかえり」からのカイゼン行動ができていないことがあるため デザイナーが複数のチームで活動しており、そのチームでの「ふりかえり」を重視した 目の前の期日がある仕事を優先してしまうので「ふりかえりをした」で終わっていました。カイゼンの実施まで辿り着くことが出来ないので、デザインチームの「ふりかえり」は、しばらくしていませんでした。 再び「ふりかえり」をした 今回、再び「ふりかえり」をしています。 理由は、いくつかありますが、人が少し増え、目の前のこと以外

こんにちは、松久です。 デザインチームの 2023 年のブログ記事をふりかえり執筆後から変わったことや、変わらなかったことを書き出すことで、2024 年に向けて動き出せるようにします。 Figma のファイル管理ルール（ 2022 年 12 月 ） ファイル名については、デザインチームでは浸透が進み当たり前の状態になっています。変える話もいまのところなく、やってよかったです。 マスターデータの運用は、GitHub Projects で「🏁 マスターデータに反映待ち」を用意し、ここを通らないと作業完了とはしないことにしました。ただ、マスターデータへの反映が滞りがちなところがあるので、課題は残っています。 Figma の操作方法を学ぶ（ 2023 年 2 月 ） 公式の YouTube から学んだことは生かされているし、YouTube で学ぶのは良い、と実感しています。 出来ていないことは、

こんにちは、松久です。 株式会社ビビッドガーデンでは、「週次 Sync & Share の会 」が開催されています。 （だいたい）毎週、各チームから全社に向けて、学んだことを伝えたり、聞いたりしています。 デザインチームから Sync & Share 会で「デザインと上手くお付き合いする話」というテーマで、デザインチームとより上手に仕事をする方法がわかることを目的とした発表をしました。 発表テーマを決めた気持ち 「デザインと上手くお付き合いする話」というテーマだと、今は「上手くできていない」と聞こえます。正直、すべてが上手くいっているとは言えません。上手くできているところもあるので、上手くできているところを増やすために伝えたい、という気持ちでした。 「デザインチームはどんな事ができるのか」を伝えて、デザインの必要性や、どんな風に関わると事業に対してよい影響を与えることができるか社内の広報活

こんにちは、松久です。 デザインチームでは、GitHub Projects でタスク管理しています。 タスク管理する理由はいくつかあります。 「食べチョク」の改善を少しでも進めるため チームで効率的に改善を進めるため 他のチームと一緒に仕事をするため チームで成果を出せているのかを確認するため GitHub Projects を使って「カンバン」を参考にして管理をしています。 なぜ GitHub Projects を使っているのか GitHub が、職種関係なく導入されています。GitHub issue で、タスクを書き出して GitHub Projects に集約がある程度されている状況がすでにありました。もし、GitHub Projects を使い続けて問題が発生すれば移行することを検討することにしました。 現在の GitHub Projects の状態 GitHub Projects

こんにちは。松久です。 デザインデータを作るとき、デザイナーが一人で作業をすることもありますが、複数のデザイナーや、デザイナー以外の職能の人と一緒に取り組む事も少しづつ増えています。 現在、どのようにデザインデータを作っているのかを紹介します。 デザインデータができるまで 食べチョクで、デザインデータができるまでの大まかな行程は下記の通りです。 施策の目的を整理する。資料を集める。 施策の目的にそったデザインの初稿を作る 関係者で見ながら作って確認する（ モブデザイン・ペアデザイン ） デザイナー同士で確認・検討をする（デザインレビュー） 関係者で合意する（ デザインが確定 ） 今回は 3〜4 の工程で取り組んでいることを紹介していきます。 UI のためのデザインデータは認識合わせのためのドキュメント デザイナーが作っている「デザインデータ」の役割は、バナーなどのグラフィックとUIでは異な

こんにちは。食べチョクの松久です。 今回は、複数人で Figma のファイルを管理するために工夫していること、悩んでいることも含めてどのようにしているかを紹介します。 ファイル管理をする目的 ファイルを管理する目的は、なんでしょうか。 複数人でデザインを行う体制のために、下記のことを実現するためだと捉えました。 過去の積み重ねによる一貫性（UIや、らしさ・ブランディング）を保つため デザイナーが過去のファイルを見つけやすくする デザイナー以外もデザインに関われる状態を作り、全員でプロダクトを作るため デザイナー以外もファイルを見られる状態を作る 上記の目的のために、今までの管理方法を踏まえながら、ルールとして明確にしていきました。 プロジェクトを端末ごとに分ける 食べチョクのデザイナーは、Web / iOS / Android といった端末でのサービスや、広告、キャンペーンなどのデザイン作

こんにちは、endo と kawabata です。 今回はプロダクトチーム内の自動テスト改善チームでコツコツカバレッジを上げた取り組みと振り返りのお話をしたいと思います。 ここでテストのカバレッジを上げているのは、RSpec でのお話になります。 テストのカバレッジを上げていこうというお話は、こちらの食べチョクの自動テスト改善活動 〜これまでとこれから〜のお話からきています。 ゴールを設定せずに活動するのは良くないので、10 月末までにカバレッジを 80%まで上げるということを目標に設定しました。 80%まで上がれば広範囲をカバーできているだろうというざっくりとした見立てです。 今回の取り組みでは、大きく分けて以下の 3 点を実施しました。 どのテストを追加するか決める コツコツテストを追加する 不要なコードを削除する どのテストを追加するか決める テストのカバレッジを上げていこう！という

こんにちは。食べチョクの松久です。 今回は、デザイナーへの依頼数を GitHub CLI と jq を使って集計している話を紹介します。 どうして、依頼数を計測することになったのか、どうやって GitHub CLI と jq を使って集計しているのか、を順番に説明していきます。 組織の中でのデザイナーの位置付け 最初に、「食べチョク」を作る組織の中でのデザイナーと、エンジニア、プロダクトマネージャーの関係は下記の図の通りです。 2022年9月現在の組織図 「食べチョク」を作る組織は、チームトポロジーを原則としています。 2022年9月現在、「プロダクトチーム」にミッションを持った「ユニット」がいくつかあります。ユニットには、プロダクトマネージャー、エンジニア、デザイナーなどで構成されています。ただ、ユニットによっては、デザイナーがいないこともあります。詳しくは「食べチョクのプロダクトチーム

皆さんこんにちは、エンジニアの久保と金田一です。 今回は、食べチョクの自動テスト改善チームが取り組んでいるテスト実行速度の改善についてお話しいたします。 自動テスト改善チームとは何か？について知りたい方は、以下のエントリーをご覧ください。 食べチョクの自動テスト改善活動 〜これまでとこれから〜 食べチョクにおける自動テストの現状 食べチョクでは、GitHub Actions のワークフローを使って、push をトリガーに自動テストを実行しています。食べチョクのリポジトリには System Spec までを含んでいて、E2E は別リポジトリとなっています。 メンバーが増えて体制が整ってきたこともあり、この 1 年くらいに実装した機能についてはテストがしっかり書かれていることが多いです。一方で、それ以上前に作られた機能については、まだまだカバレッジが低い箇所もあり、みんなで手分けして少しずつテ

どうもはじめまして。 muryoimpl です。 前回のエントリ 食べチョクの自動テスト改善活動 〜これまでとこれから〜 で、自動テスト改善チームが発足したことを書きましたが、今回はその活動の中で実施した、RSpec による自動テストのカバレッジのデータ収集の自動化と、そのデータを利用した可視化について書きたいと思います。 これまではどう可視化していたか 食べチョクは Ruby on Rails で動いており、バックエンドの自動テストは RSpec を使って書いています。 テストカバレッジは定番の SimpleCov で計測して結果を HTML に出力し、テストケースごとの実行情報は RSpec JUnit Formatter を使って XML として出力して、GitHub Actions でそれらの情報を Code Climate に送信していました。 また、可視化という点では、以前ビビ

みなさん初めまして。 QAエンジニアのujeです。 食べチョクでは、2022年4月から正式に自動テスト改善チームが発足いたしました。 チームメンバーは機能開発との掛け持ちにはなりますが、Webエンジニア5名・QA1名で取り組んでいます。 自動テスト改善チームの発足に伴い、食べチョクのテストにまつわる振り返りと、改善チームが取り組んでいることをお話しいたします。 これまで 食べチョクはサービスリリースから5年がたつプロダクトです。 特にここ1年半は食べチョクに参加してくれる仲間が増えており、サービス開発のスピードも上がっています。 食べチョクは2020年まで、テストカバレッジが低く、またなかなか向上しない状態でした。 システム全体に影響がある改修をする際は、毎回全画面を一通り手作業で触りテストするなど労力のかかる状態でした。 この状態を脱するため、2020年末から少しずつ自動テスト改善の動き

こんにちは。 今年の年始からジョインした遠藤です。 さて、入社したところ会社支給のMacBook ProがM1チップのものでした。 はい、現状は開発環境で苦労するとか色々噂を聞くやつです。 実際に試したのですが、 現状の開発環境構築スクリプト、手順書が一切使えない VitualBox, Vagrantは利用不可 Dockerは利用可能ではあるが、一部イメージが対応されてない 古いパッケージは動かす手段がない などなど、通常ではぶつからない問題にぶつかります。 食べチョクでは、 Ruby Node.js MySQL Redis ElasticSearch Kibana を利用しています。 この辺りをメインに話つつ、Intel版とこんな風に違うのかっていう辺りの雰囲気を感じ取っていただければと思います。 どこに開発環境を構築するか まず、どこで開発環境を構築するかを考えてみたいと思います。 ロ

皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い（コーディングができないなど）よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要