Rettyのデータ分析チームMGR平野です。 今回はRettyにデータアナリストスキル定義の作成とFB制度を導入した話です。 データアナリストスキル定義＆FB制度の作成は、今年の4月に着手スタート、メンバーと議論を重ねて8月末に完成しました。そして、9月には初の運用をスタートさせ、メンバーからの所感やフィードバックをもらったところです。 まだまだ粗削りで改善点はあるものの、このタイミングで紹介させていただき、皆さんからのフィードバックを受けてもっと良くできればと思っています。 また、このデータアナリストスキル定義は、Rettyの現状と未来に必要なスキルを定義しています。そのため、必ずしも各社の参考になるものでないと思うものの、これから作成と運用を考えている方々に少しでも参考になればと思って書きました。 さらに、今回作成するにあたって社内のエンジニアやPM、デザイナーの先行事例を参考にしてい

自己紹介 インターンで行った業務 背景 使用技術 作業の仕方 1日の流れ 朝会の準備・朝会 朝会後の10分間の雑談 作業約80分＋休憩10分のモブワーク (3~4回) 1週間の振り返り (金曜日のみ) 成果 完成ページ 改善内容 振り返り 自己紹介 サマーインターン(フロントエンド)に参加した、ウマ娘ならぬウマ男のチームメンバーを紹介します。 電気通信大学情報理工学域3年 大住航希 北海道大学理学部3年　後藤凌 東海大学情報理工学部3年 中島功貴 メンター　木村一馬 インターンで行った業務 背景 Rettyには、ユーザーから新しくお店を登録できる画面があるのですが、古いページになっており、改善が必要になっていました。私たちのチームでは、この画面のフロントエンドを作り直す業務を行いました。 現状のページ 使用技術 以前の新店登録画面は、PHPを用いて書かれていましたが、今回Nuxt.jsで置

自己紹介 課題とその背景 技術スタック/開発形式 全体のスケジュール 一日のスケジュール 朝会の内容 夕会の内容 やったこと 1. 050番号の発行と更新をするワーカーの処理移行 2. 社員向け管理画面の処理移行 3. お店会員さん関連のモノリスサービスの処理移行 結果 学び 感想 自己紹介 2022年Rettyサマーインターン(バックエンド)に参加した、からあげおふとんチームです。 メンバーを紹介します。 豊田高専情報工学科4年 坂口 文陽 @fuu38 東京都市大学メディア情報学部3年 髙野 氷河 @ninebolt6 大阪大学大学院修士1年 田川 翔暉 @shoki-tagawa 東京大学工学部3年 屋比久 怜央 @ReoYabiku メンター社員 鈴木 文也 @Sntree2mi8 今回は、インターンの様子や開発したサービスについて紹介します。 課題とその背景 Rettyと契約いた

はじめに こんにちは アプリ開発チームの@レイです 最近約1ヶ月間、RettyのiOSアプリパフォーマンスの改善について集中的に作業しました。 本記事では、 今回の改善の必要性について どのような改善をしたのか どのような効果があったのか 上記について2章にわたってご紹介しようと思います。 画像のキャッシュを管理するマネージャーの導入背景 Rettyアプリでは数多くの投稿写真を表示しているので、写真に対してキャッシュメモリーを多く使っています。 それによってメモリーが多く消費されてしまう可能性が高いのですが、 これはパフォーマンス的に遅くなる上、メモリー不足問題につながってアプリがクラッシュする問題がありました。 よって、周期的にキャッシュを削除する機能が必要でした。 そのため、下記のようなキャッシュマネージャーを作ろうとしました。 Default キャッシュだけで管理するのではなく、1い

アプリチームの松田です。 今回は自分が行ったアプリチームの最近の開発の改善について、共有しようと思います。 課題 アプリチームではリリースビルドやQA用のビルドで、以下の問題を抱えていました。 リリースビルドを行い、QA用にFirebase App Distributionに配信する為のMac Miniが社内に存在しているのです。これは、ずっと起動し続けている為、それが原因でビルドできなくなり、再起動が必要な時があります。 特にこのマシンでないといけない理由もなく、過去から引き続いて使用されていただけでした。アップデート等のコストもかかりますし、これをCIサービスに移すことにしました。 改善 これらの処理をGitHub Actionsに移すことにしました。手動での実行が楽なのが良い点です。 ボタンを押したら実行されるというのは workflow_dispatch を利用すればできます。 こ

2022/09/10(土)から09/12(月)に行われるイベント「iOSDC Japan 2022」にて、RettyアプリチームからiOSエンジニアの登壇・スポンサーをさせていただきます! iOSDC Japanについて iOSDC Japan はiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。 iOSDC Japan メインのコンテンツは日本中、世界中から公募されたスピーカーによる知的好奇心を刺激するトークと参加者間のコミュニケーションですが、それ以外にも開催期間をお楽しみ頂ける企画を検討中です。 (https://fortee.jp/iosdc-japan-2022 より引用) 開催概要 日程：2022年9月10日（土）〜2022年9月12日（月） 会場：早稲田大学理工学部 西早稲田キャンパス ＋ ニコニコ生放送 主催：iOSDC Japan 2022 実行委員会

この記事について Rettyの2022サマーインターンのチームで書いた参加記になります。 自己紹介 私たち酸辣湯麺チームのメンバーを紹介します。 北海道大学工学部4年 茂木 貴紀（@manattan_me） 日本大学大学院1年 田中勇太（@nayuta999999） 京都大学理学部3年 松田 和樹　(@diracmax) 早稲田大学大学院1年 山倉拓也 この記事について 自己紹介 今回のインターンで作成したもの 背景 選定技術・開発形式 全体方針 各メンバーの学び アーキテクチャについて理解を深めることができた（もぎ） 個人開発ではできない経験ができた（松田） 複数人でプログラミングをしていく上で、重要なこと (山倉) Rettyのインターンに参加して分かったRetty社の特徴（田中） 総括 今回のインターンで作成したもの Rettyで実際に提供されているオリジナルリストのシェア機能を作成

自己紹介 サマーでRettyを選んだ理由 インターンの1日の流れ 全体方針 実際にやったこと 学び Go言語 Clean Architecture gRPC 感想 自己紹介 この度Retty2022サマーインターンに参加しました、(男前)マンチカンチームです。メンバーはそれぞれ、 筑波大学の表 (@yj7tj) 明治大学の石田尾 (@backtestl) 京都大学大学院の平野 (@hiran_ery) です。 サマーでRettyを選んだ理由 Rettyのサマーインターンを選んだ理由としてチームの3人で共通していたのは、今回のインターンで取り扱う技術に興味があった点です。後にも書きますが、今回のサマーインターンでは「Go / gRPC / CleanArchitecture」といった、既存マイクロサービスで採用されている技術スタックを扱います。 3週間というある程度長期的なスパンで、これらの

マネージャーの常松(@tunepolo)です。Developers Summit 2022 Summer(以降愛着を込めてデブサミで表記)で登壇機会をいただき、「「全社でアジャイル！」を広げるために 」のタイトルで、Rettyの開発外部門を巻き込んだアジャイル推進の事例を紹介をさせていただきました。 ちなみに今回のデブサミはオンライン開催でしたが、お邪魔させていただいた配信スタジオの設備や、スタッフの皆様の準備・対応は本当に素晴らしく、しっかりしたものでした。さすがデブサミ！という感想です。 登壇の概要 Rettyはアジャイルな開発の取り組みを続けています。開発・企画側の取り組みは先日SELECKさんに取材いただいたのでそちらを参照ください。 seleck.cc 企画・開発はアジャイルな価値観が身についてきたものの、営業や総務といった全社ではまだまだです。 私たちが身を置く飲食業界はここ2

2022/06/30に、おいしい健康さん、アンドパッドさん、ZOZOさん、RettyでJetpack Composeについての登壇イベントを開催しました。 Rettyからは、「Jetpack Composeのパフォーマンスの基本について」という内容で、RettyのAndroidアプリで気にしているパフォーマンスに関する部分を紹介しました。 andpad.connpass.com 登壇内容の概要 CompositionをSkipする為の、Stable, Immutableと、Layoutフェーズだけを実行するという点から、パフォーマンスの最適化について解説しています。 アーカイブ動画 youtu.be 補足 登壇翌日に、どの程度Stableについて気にするべきかという記事が出ていたため、こちらを読んでからの補足をしていこうと思います。 Jetpack Compose Stability Ex

この記事は #Rettyマイクロサービス強化月間 の第5弾の記事です。 engineer.retty.me 前回は鈴木さんの「予約 API のマイクロサービス化と gRPC ゲートウェイの置き方」でした。 インフラチームの幸田です。 自分の番はまだまだ先だと思っていたら、もう月末で焦って記事を執筆しています。 今回の記事ではマイクロサービス基盤を新しく Terraform で構築し直した話をしようと思います。 マイクロサービス化のはじまり システム構成 抱えていた問題 マイクロサービス間での設定差異や変更漏れの発生 新規サービスの追加に時間がかかる 作業に対するレビューができない 課題解決に向けて IaC ツールの選定 Terraform 化の方法について 工夫したポイント Terraform の module の構成について ECS Service module ALB module L

エンジニアの堤です。 #Rettyマイクロサービス強化月間第二弾として、検索サービスの構築についてお話します。 第一弾は、id:pikatenor の「マイクロサービスのデータぜんぶ抜く……gRPCで！」でした。 Rettyでは最近、検索機能を新たにマイクロサービスとして切り出し、Search Serviceが誕生しました。 その背景としては、Rettyのお店検索に使われているElasticsearchのバージョンが非常に古く(2.4)、バージョンアップ & アーキテクチャ刷新を行ったというのがあります。 今回はそのアーキテクチャ刷新のうち、Search Serviceの作成の背景・実施内容についてお話します。 Rettyのお店検索 アーキテクチャ(マイクロサービス切り出し前) マイクロサービス切り出しに関わる背景課題 検索マイクロサービスの作成 全体の作業の流れ Search Servi

Feature Flagで 素早くマージ 安全にリリース Rettyアプリチームの @imaizume です、新しい年度が始まり新卒社員も入社してフレッシュな気分になる今日このごろですね。 今回は最近Rettyアプリチームで利用することが増えている、Feature Flagを使った開発についてのお話です。 Feature Flagを使うことで、大規模な開発であっても開発中から継続的に差分をマージできるようになり、デリバリー効率を大きく向上させることができます。 本記事では、この方法を採用するに至った背景や実際に取り入れて感じたメリット、課題感などを書きましたので、読んでみてメリットが感じられたならぜひみなさんの開発でも取り入れてみていただければと思っています。 Feature Flagとは? FFを採用する前の開発の様子 RettyでのFFによる開発の始まり アプリチームでFFを採用したこ

マネージャーの常松です。 2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (愛称 #ちいとぽ) が発売になりましたが、皆さんもう読まれましたか? この書籍には事前レビューから参加させていただいていたのですが、「出版されたら自社の開発体制を図にして話せると良いな」とずっと考えていました。ただタイミングを逸してしまい・・・ようやく筆をとったのが本記事です。 チームトポロジーとは 描いてみた & 解説 基本はストリームアラインドチーム SREチームを立ち上げ中 トポロジー図を元に角谷さんと話したこと XaaSはセルフサービスを目指す スマホアプリとWebで開発順序の依存関係がたまにある 開発部門外とのコミュニケーションをどう扱うか ストリームアラインドチームに専門の役目を持たせるか オンコール対応をフローとして描い

書き手：@takegue (分析チーム) Rettyのデータ活用の多くにはBigQueryが現在利用されており、その活用の方法についてこれまでこのブログでもいくつかとりあげさせていただきました。 engineer.retty.me そのほか分析チームの記事一覧 これらの記事はおかげさまで好評いただいております。いつもありがとうございます。 しかしながら、我々が初期からこのようにBigQueryを使い続けてきかというと、実はそうではありません。 事業の成長とともにデータ基盤を変化させてきた経緯があり、今の成果は過去のトライアンドエラーの賜物であり、数多くの苦労を背景にしてできあがっています。 ほんのつい最近まで、Rettyで構築されていたデータ基盤は表立って見える実態よりもかなり複雑なパイプラインで構成されていました（以降で触れますが、4種類のデータパイプラインが共存しているカオスな状態でし

はじめに Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック（以下、フィードバックはFBと省略します）制度があります。 本記事はRettyのエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。 （2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください） engineer.retty.me engineer.retty.me エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。 対象としたい読者 下記のような項目にピンと来る方に読んでいただけると嬉しいです。 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り

昨日は、西村さんよりAurora移行大全#2 でした。ドキドキの移行が無事成功して嬉しいですね。 engineer.retty.me Retty Advent Calendar も終わりが近づいてきました。 24日目の本日はデータ基盤について紹介します data-platform-meetup.connpass.com 今回の記事は、先日登壇した以下のイベントで発表を行いました。 コミュニティの盛り上がりを感じる良いミートアップだったと思います。 この記事では発表ではお話しできなかったことの補足も含め、 我々のデータ基盤を取り巻く構成と その背景となる考え方について紹介したいと思います。 誰のためのデザイン？ データの民主化と基盤開発 Rettyにおけるデータウェアハウジング データ基盤開発の標準化 効果的なプラクティスの導入 データウェアハウシングのための実践的なレイヤ構成 データ置き場