はてなブックマーク

Repro Boosterのプロダクトマネージャー、Edward Foxです。 以前の記事（Repro Booster が AWS Roadmap Acceleration (RAP) プログラムに参加しました）でもご紹介した通り、BoosterチームとしてAWSのRoadmap Acceleration (RAP) というプログラムに参加する機会をいただきました。事前の質問回答に加えAWSのオフィスで約2時間の同期セッションを行い、事業やプロダクト開発の現在地、将来の展望、そして現在の課題や今後の戦略について、非常に密度の濃いディスカッションをすることができました。 そのディスカッション内容に基づき、後日AWSからレポートを受領しましたので、本記事ではその内容と実際にBoosterのロードマップ策定に活用してみた顛末をまとめています。 Scoring Rubric 今回いただいたレポート

はじめに こんにちは。Repro Teamでエンジニアをしている矢作です。　Reproには入社して約2ヶ月程になります。 Repro というシステムのうち、マーケターの方々が利用する管理画面は Ruby on Rails で構築されており、現在は ECS (Amazon Elastic Container Service) 上で稼働しています。 先日、この Rails アプリケーションを動かしているコンテナのベースイメージのOS（Debian）を Busterから Trixie へアップデートした際に、アップデート自体は問題なく完了したものの、タイムゾーン関連でニッチな不具合に遭遇しました。 まずは、実際にどんなエラーが発生していたのかを見てみましょう。 ActionView::Template::Error: Invalid Timezone: Rangoon どうやら Asia/Ran

こんにちは、Repro Boosterの開発責任者・プロダクトマネージャーの Edward Fox です。全国的に長く続いた酷暑も少し落ち着きを見せ始め、朝晩は涼しく感じるようになってきましたね。 はじめに 2021年からプロトタイプ開発を始めたRepro Boosterですが、2022年の8月頃に正式なプロジェクト・チーム化しました。開発チームにはRepro社歴が長いメンバーも多く、チームが組成されてからこれまで大きな入れ替わりもなく開発を行ってきたのもあり、非常に安定した組織運営ができていると感じています。 これ自体は素晴らしいことであり、チームの成熟度が高い証でもあります。しかしながら、新規事業の本分は「非線形的な成長」であり、安定の先にある未来の解像度が高く持ててしまっている点に、得も言われぬ不安を感じるようになったタイミングがありました。プロダクト・事業の成長に「天井」が見え始め

Platform Team/Core Unit の村上です。 Repro は分散メッセージングシステムである Kafka を用いたイベント駆動アーキテクチャで構築されています。 私が所属している Core Unit は、Repro のコアとなる基盤を支えているチームであり、Kafka のストリームアプリケーションを日常的に扱っています。 私は Repro に入ってから Kafka のストリームアプリケーションを触るようになりましたが、一般的な Web API や Worker アプリケーションの実装とは異なるマインドセットが求められると感じます。 その中で特に重要だと考えているのが Kafka のパーティションに関する理解です。 Kafka のパーティションは分散処理を扱う上で重要な概念であり、ここの理解が浅いまま実装を進めていくと、後になってトラブルに見舞われることがあります。私自身 K

こんにちは。新規事業部門でエンジニアをやっている重本です。2025年5月にReproへ入社し、この記事を書いている今でちょうど3ヶ月が経ちました。 わずか3ヶ月ながらも、プロダクトの一部を担う責任や、技術的に解くべき課題の難しさ、そしてそれらを支える人や文化に、日々驚きと学びの連続でした。入社を検討している方や、同じような課題意識を持つ方の参考になればと思い、この記事を書くことにしました。 入社経緯 私はこれまでSESを中心に、複数の会社・案件で開発を経験してきました。ある程度のアプリケーションは作れるようになってきた反面、「この先、エンジニアとして何を積み上げていけば良いのか？」という漠然とした悩みもありました。 そんな中、Reproの面談で率直にその悩みを話してみたところ、「じゃあウチで修行してみる？」という一言で話が進みました。 「修行」と聞くと少しストイックな印象もありますが、私に

Repro Boosterのプロダクトマネージャー、Edward Foxです。好きなAWSサービスはAWS Ground Stationです。AWS Ground Stationを知った際に、軽い気持ちで衛星基地局のデータを受信するNode.jsのプログラムを書いて動かしてみたところ、瞬く間に3万円ほど消費されたのは良い思い出です（涙目）。新しいサービスを動かす際は、必ず事前に料金表を確認してから取り組むことを学びました。 さて、Repro Boosterは多くのシステムコンポーネントがAWS上で稼働しており、各種サービスを組み合わせることで効率的なシステム提供と運用を実現しています。主に利用しているのは、Amazon CloudFront、Amazon S3、AWS Lambda、Amazon ECS、Amazon CloudWatch、Amazon EventBridgeといったサービ

社内ドキュメントの内容をAIに食べさせたいじゃないですか こんにちは。Feature2 Unitのうなすけです。一番よく使っているAIサービスはClaudeです。 Reproでは社内ドキュメントにesaを使用しています。他にも、Kibela、DocBase、Notion、Confluenceなど、様々な社内ドキュメント用サービスがありますよね。その中でもNotionにはNotion AIが、ConfluenceにはAtlassian Intelligenceがあり、AIと連携した便利な機能がある……と聞いています。僕はどちらも使ったことはありませんが。 僕の周りでは特にNotion AIを使ったことのある人が多いのですが、Notion上にある情報をAIで探してもらうという使い方をしている人が多いようです。むしろ自分では見つけられない情報がAIに聞くと見つかることも多いと聞きます。 社内ドキ

やや煽り気味のタイトルで失礼しました、Repro Booster のプロダクトマネージャーの Edward Fox です。暑いですね。 Repro Booster開発チームでは、昨今の盛り上がりに漏れることなく、生成AIやコーディングエージェントを積極的に開発に取り入れています。その活用範囲は開発業務に留まらず、ドキュメンテーションやお客様からのお問い合わせ対応といった周辺領域にも及んでおり、プロダクト開発の効率を大きく向上させていると実感しています。しばらく取り組みを続けてきて、ある程度体系化できてきたと感じられるフェーズに入ってきたので、Boosterチームにて実践している具体的な手法を紹介できればと思います。 ユースケース1. 開発全般 現在の開発チームで最も活用されているのが、自律型AIソフトウェアエージェントであるDevinです。DevinはSlackに常駐しており、チャット経由

こんにちは、Repro Booster のプロダクトマネージャーの Edward Fox です。Booster開発チームでは定期的に開発合宿を行っています。この記事では、6月下旬に実施した開発合宿についてのレポートをお届けします。 概要 今回の開発合宿は神奈川県横須賀市にあるAirbnbで宿を押さえ、2泊3日の予定で敢行しました。 普段フルリモートの開発メンバーもこれに合わせて来てもらい、事業側のメンバーも含め合計5人での開催となりました。 宿はこんな感じのいわゆる古民家で、築150年の建物だそうです。庭も含めてとても趣のある施設でしたが、室内はリフォームされており快適に過ごすことができました。 成果 これまでの開発合宿では、ハッカソン的な形でメンバーそれぞれで機能を開発し発表し合ったり、全員で1つの機能を作ってリリースまで行う、といったやり方で開催してきました。 今回は少し主旨を変え、現

こんにちは、Repro Booster のプロダクトマネージャーの Edward Fox です。5月15日に開催された Repro Tech Meetup #10: パフォーマンスを改善する技術のイベントレポートをお届けします。 前置き: イベントの形式について これまでの Repro Tech Meetup では、発表者を事前に募り、4-5本ほどのLTを行い、その後懇親会に移行するスタイルで開催してきました。技術系の勉強会では非常に一般的なスタイルで、開催する側としても参加する側としても馴染み深い形式かと思います。ただ個人的に感じていた課題として、せっかく非常に面白いトピックに出会えても5-10分程度でセッションが打ち切られてしまうと、深堀りができずに終わってしまい、もっと聞きたかった！という気持ちを抱えたまま帰路につくことが（稀によく）ありました。懇親会で直接話して根掘り葉掘り聞かせて

こんにちは、Repro Booster のプロダクトマネージャーの Edward Fox です。 先日LAPRASさんの主催する【LAPRAS Engineer Talk】に出演させていただき、その動画が公開されたのでお知らせです。 LAPRAS CTOの興梠さんからのキラーパスがテンポよく繋がり話が非常に盛り上がったため、全体で50分ほどの尺になり、動画は前後編に分かれていますｗ 前編では Repro Core Unit の 村上より、Reproの大規模なトラフィックを支えるデータ処理基盤について説明しています。 【前編】事業を支えるサービス基盤のアーキテクチャと今後の挑戦 前編の推しポイントとしては 15億件／日（！）のイベントデータを処理するアーキテクチャについて知れる 基盤チームが抱えている課題や今後の展望が聞ける あたりですかね。動画内でも触れていますが、15億件／日を秒単位にな

はじめに こんにちは。Repro Booster プロダクトマネージャーの Edward Fox です。普段はRepro Boosterの製品戦略立案やロードマップの策定を担当していますが、プロダクトの提供とは別にお客様サイトの根本課題を一緒に解決する取り組みも行っています。本記事では、最近担当した大規模ECサイトのパフォーマンス改善事例を題材に、技術面と組織面の両方から「パフォーマンス改善をどう進めればよいか」という観点で記事を書いてみました。 Repro Booster と伴走支援の位置付け Repro Booster は「タグを設置するだけでWebパフォーマンスを改善する」ことを目的にしたプロダクトです。一方、既存サイトに長年積み上がった負債や部門間の調整といった課題はツールだけでは解決が難しい領域でもあります。そこで私たちは、少人数の伴走チームを編成し「小さく試して、パフォーマンス

Repro Boosterの開発を担当しているRyoma Shindo です。 今回はView Transition APIについて、基本的な使い方やCore Web Vitalsへの影響の有無など調査したのでご紹介します。 View Transition API とは View Transition APIは、ページ遷移する際のアニメーションを手軽に実装するためのAPIです。MPA（Multi Page Application）/SPA(Single Page Application)どちらでも利用できますが、MPAで利用する場合、MPAでありながらSPAのようなスムーズな画面遷移を実現できます。 今回はMPAでの動作に焦点を当てて記載します。 最低限の使い方は簡単で、以下をCSSに追加するだけです。 @view-transition { navigation: auto; } 適用する

皆様こんにちは。Boosterの杉浦です。 Repro ではここのところ、各種 AI を活用して生産性を上げられないか、色々模索しているところです。 Devin も複数のチームで実験的に導入をはじめ、現状3か月ほどになりました。 Booster チームでは主に既存レポジトリのコードの改善、機能追加の目的で試しており、以下のような感触です。 人間のジュニアプログラマと比較して十分役に立ち、高速かつ大量に作業を行える プレーンテキストのドキュメントやリソースがすでにあるかが非常に重要 開発 - ビルド - テストのパイプラインが手元の VM/Docker ですべて完結するように整備されていると、作業のスピードもクオリティも上がる 実機が要る、などの場合は現実的に頼めることがあまりない ローカルでテストが回せないと途端にやり取りの手間が激増する テスト環境の整備自体を頼むこともできる 頼む側は、

こんにちは。Feature2 Unitのうなすけです。我々のチームの担当範囲のひとつには「データの入出力」というものがあり、お客様からAPI呼び出しやファイルアップロードなどで受け取ったデータを適切に処理するコンポーネントの運用・開発をしています。 我々の担当している機能のひとつに、お客様からアップロードしていただいたCSVファイルの内容をデータベースにインポートするというものがあります。これは裏側ではEmbulkを使ってMySQL(Aurora)に投入するということを行っています。 このとき、アップロードされるCSVの内容に日本語(マルチバイト文字列)を含められるように機能追加しようとしたところ、日本語のデータがインポートできていないという問題が発生しました。冒頭画像で ??? となっている部分には日本語の文字列が表示されていてほしかったのですが、データの取り込みに失敗しています。 どこ

Development Division/Platform Team/Sys-Infra Unit では、よりセキュアな状態を維持できるように様々なことに取り組んでいます。 背景 Repro ではメインとなる AWS アカウントに以下の環境で利用するリソースを全て作成していました。1 production 所謂本番環境 staging 本番リリース前に QA を行うための環境 dev_staging 開発者の動作確認用 test アプリケーションの CI で利用する internal 内部利用のためのウェブアプリケーション AWS Well-Architected Tool を使って既存環境をチェックしたところ、まずは AWS アカウントを分離し、各環境のワークロードを分離した方がよいとの結果でした。 SEC01-BP01 アカウントを使用してワークロードを分ける: - AWS Well-

Development Division/Platform Team/Sys-Infra Unit では、開発者がスムーズに開発作業をできるように様々なことに取り組んでいます。 今回はそのうちの1つを紹介します。 背景 Repro の Slack には、開発オペレーション用のチャンネルがあります。このチャンネルには@deploy-botが存在しています。前回の改善1で@deploy-botは使いやすくなったのですが、Development Division 全体ではあまり活用されていませんでした。 新規アプリケーションのデプロイ準備時に Sys-Infra Unit への作業依頼が多かったため、原因を探ってみたところ、使い始めるのが意外と大変だということがわかりました。 課題 @deploy-botでデプロイするために必要な従来の作業は、詳細に書くと以下の通りです。 デプロイ用の IAM

はじめに みなさまこんには。日々 Booster で楽しくコードを書いている杉浦(sugi) です。 Booster プロジェクトではタグを入れるだけでサイトを高速化できる「Repro Booster」という製品を作っていますが、そのためにも日々さまざまな最適化手法を調査・模索しています。 その中で個人的に期待しているのが、 103 Early Hints というHTTPステータスコードです。 この記事では Repro Tech Meetup #9 で行った発表(資料)を元に、103 Early Hintsはどのような仕組みなのか、なぜ高速化につながるのか、さらに現状の実装に関して解説します。 ちょっとマイナーな内容ですが、知っておくとウェブパフォーマンス最適化の大きな武器になるかもしれません。 103 Early Hintsの背景 従来のHTTP通信の課題 通常のHTTP通信においては、

はじめに こんにちは、Repro Booster という製品の開発責任者／プロダクトマネジメントを担当しているEdward Fox（@edwardkenfox）です。 今回は、ServiceWorkerに組み込まれた新機能「Static Routing API」を実際に試してみた件について説明します。Repro Boosterでの応用を通じて得た知見を共有できればと思います。 Repro Boosterとは Repro Boosterは、私たちが提供しているパフォーマンス最適化ソリューションです。サイトにタグを設置するだけで、読み込み速度が向上するというシンプルなコンセプトで設計されています。 その鍵となる技術の一つがServiceWorkerの活用です。ServiceWorkerはブラウザのバックグラウンドで動作し、リソースキャッシュやネットワークの中継など、従来のWebサイトでは実現で

Repro Team / Feature Unit の下村です。 Reproで行っている技術書の読書会をどのように運営しているのかについて紹介します。 Reproの技術書読書会の現状 現状は2週間に1回のペースで1時間ほど時間をつかって読書会を行っています。参加者はその時々によって変わりますが、2-5人程度が参加しています。 今までは以下のような本を読んできました。 システム設計の面接試験 (半年程度で読破) ソフトウェア設計のトレードオフと誤り (半年程度で読破) 分散システムデザインパターン (現在読んでいるところ) Reproでは高トラフィックなシステムの保守運用や開発が求められる場面が非常に多いです。せっかくなのでそのようなReproの特性に合う本を読もうという方針のもと、参加者間で議論して読む本を選んでいます。 モチベーション そもそもなぜ読書会をやりたいのか？という理由はチーム

こんにちは、Repro Booster開発責任者のEdward Fox（edwardkenfox）です。12月13日に開催された Repro Tech Meetup #9 のイベントレポートをお届けします。 今年の3月には「Deep Dive into Browsers」というテーマで開催した Repro Tech Meetup ですが、今回はもう少しテーマを広げ「Webパフォーマンス」という括りにしてみました。テーマの裾野が広くなったことも手伝ってか、前回のイベントと比較すると参加者が倍近くまで増え、約30名の皆さんにご参加いただきました。規模が拡大した一方で、熱量の高い発表や質疑応答が次々と展開され、予定していた懇親会の時間を短縮せざるを得ないほど濃密な会となりました。本記事では、その熱いイベントの内容を振り返ります。 前回のイベントについては Repro Tech Meetup #8

こんにちは。Feature2 Unitのうなすけです。我々のチームの担当範囲のひとつには「データの入出力」というものがあり、お客様からAPI呼び出しやファイルアップロードなどで受け取ったデータを適切に処理するコンポーネントの運用・開発をしています。 AWS Lambdaの処理が失敗するようになった 皆さん、AWS Lambdaはお使いでしょうか。我々も様々な処理にAWS Lambdaを活用しています。一例として、ユーザーからアップロードされたCSVファイルのバリデーションを行うLambda functionをAWS Step Functionsの一部として実行しています。 ある日、機能追加として日本語を含む1CSVファイルのアップロードを許可したのですが、CSVファイルのバリデーション処理でエラーが発生するようになりました。日本語も受け入れるようにしたタイミングと同時にRuby runti

Reproでチーフアーキテクトをやっているjoker1007です。 前回、Apache Hudiというテーブルフォーマットについて紹介する記事を書きましたが、今回はHudiを実際に本番に近いデータで検証し、パフォーマンス特性とチューニングについていくつか知見を得たので、その辺りについて紹介します。 また、同じ内容をベースにOTFSG Tokyo Meetup #4というイベントで発表させていただきました。 これぐらいの規模でHudiについてガッツリ検証している例は国内では余り見ない様なので、それなりに貴重な知見を共有できたかなと思います。 ブログ記事とほぼ同じ内容ですが、スライドになってる資料もありますので、参考までにリンクを貼っておきます。 speakerdeck.com 実験データ データ構造 今回利用したデータは、いわゆるユーザーごとのプロフィール情報を想定して欲しい。 カラム名 タ

こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります

Platform Team/Sys-Infra Unitの伊豆です。今回は、pt-online-schema-changeにnohupをつけてバックグラウンドで実行してもSIGHUPを受け取って終了する現象に遭遇したので、そのときに調査した内容を共有します。 調査は以下の環境で行いました。 pt-online-schema-change v3.6.0 Amazon Linux 2023 bash 5.2.15 OpenSSH 8.7p1 背景 ReproではAurora MySQLを使っていて、レコード数の多いテーブルのスキーマを変更するときに、pt-online-schema-changeを使うことがあります 1 。pt-online-schema-changeを実行するときは、実行用のサーバーにSSHでログインして実行しています。 中には10億レコード以上あるテーブルもあり、pt-on

Platform Team/Repro Core Unit の村上です。 Repro では Kafka を基盤としたストリーム処理のアプリケーションを構築する際に、Kafka Streams を積極的に活用しています。 Kafka Streams は、フォールトトレラントなステートフル処理を簡潔に実装でき、データパイプラインを Topology という表現で抽象化することで、複雑な処理でも管理しやすい形で組み立てていくことが可能です。 また、Apache Kafka 以外の外部依存がないことや Streams DSL によるシンプルな記述でストリーム処理を実装できることなども、ストリーム処理のアプリケーションをスムーズに構築する上で助かっています。 一方で、 なにかしらの問題が発生したときのトラブルシューティングや影響範囲調査の際には、Kafka Streams の内部処理を把握していない

Repro では AWS 等のリソース管理に Terraform を活用しています。 この度 Terraform で管理しているコードの CI を Atlantis に移行したので、その経緯などについて書きます。 背景 Repro では以下のリソースを Terraform を使ってコード化して GitHub で管理しています。 AWS で構築したインフラ DataDog のモニターやアラート Google Cloud Platform で利用している一部のリソース GitHub の reproio organization のメンバーやチーム Kafka Topic MySQL アカウント PagerDuty の通知まわりの設定 Rollbar の通知 移行前は CircleCI や AWS CodeBuild を活用して独自に CI を構築していました。 課題 初期から CicleCI

はじめまして。ReproでUI/UXデザイナーをしている竹内と申します。Reproのデザイナーはプロダクト企画を行っているProduct Planning Teamに所属しており、中期製品戦略の策定とその浸透および状況にあわせた戦略の改定、顧客からの一次情報を収集、戦略の実行のため体験設計、UI設計まで一貫して行っています。 Product Planning Teamがやっている仕事は、いくつかのブログ記事でもご紹介しているので、よろしければご参照ください。 tech.repro.io tech.repro.io 今回は、プロダクト全体の企画に関する話ではなく、個別の機能開発においてデザイナーとしてどのように関わっているかのお話です。開発初期で要件が固まっていない時に役に立つ、要件・フェーズを決めるための手法であるユーザーストーリーマッピングをご紹介します。 ユーザーストーリーマッピングと