こんにちは！GMO ペパボのてつをです。この度、フロントエンドカンファレンス東京 2025に参加・登壇してきたので、その内容をご紹介します。フロントエンドカンファレンス東京とは「フロントエンドを次世代に」をテーマに開催される、フロントエンド技術に特化したカンファレンスです。今年初開催ながらもオフライン350人以上が参加し、国内最大級のフロントエンドカンファレンスとなりました。また、全セッションでAMAルームが用意されていたのも印象的でした。AMAとは「Ask Me Anything」の略で、登壇者に自由に質問できるコーナーのことです。各セッション終了後、登壇者ごとに個室が用意され、参加者が直接議論できる場が設けられていました。どのルームも活発な議論で盛り上がっており、登壇内容を直接登壇者に深掘りできる貴重な機会だなと感じました。登壇についてここからは、今回私が発表させていただいた内容について紹介します。ブラウザストレージを活用した複数アプリを跨ぐ高速化とリアクティブな同期本発表では、Alive Studioで実際に活用している、localStorageとstorageイベントを組み合わせた、複数window間でのリアクティブな同期を実現する方法について紹介しました。また、Alive StudioはOBS（ライブ配信で広く利用されているオープンソースの配信ソフトウェア）上のブラウザ（Chromium ベース）で動作するということもあり、OBSブラウザならではの特徴についても併せてお話しすることができました。主な内容：localStorageとstorageイベントによる複数のwindow間の同期の仕組みセキュリティ・型安全性・保守性を考慮した実装の重要性localStorageの利用指針の事例実装上の工夫：イベントハンドラの増殖を防ぐための抽象化と依存性注入によるテスト可能な設計Zodを使った型安全性の確保（parse + validate）複数のドキュメント間で状態をリアクティブに同期し、よりシームレスなユーザー体験を提供できることを実例を交えて紹介しました。登壇の感想発表後、多くの方から「storageイベントでそんなことができるのか」「その発想はなかった」「擬似的な双方向通信として面白い」といった沢山の反応をいただきました。このような反応をいただけたことで、多く

こんにちは、chiroruです！私が所属する技術基盤グループ(以下GKG)は、複数のサービスを横断的にサポートする、いわゆる組織横断チームです。各メンバーは担当するサービスも専門領域も異なり、日々多種多様なタスクと向き合っています。そんな私たちですが1つ、チームとして大きなミッションがあります。それは全社的に利用しているインフラ基盤の移設プロジェクトです。今年から本格的に始動したこのプロジェクトをチーム一丸となって進めています。移設の対象となるサービスやロールは多岐にわたり、メンバーは移設に向けたプラットフォームの刷新に取り組みながら、それぞれサービスのSREやインフラに関するタスクを担当しています。そのためチームで毎週のスクラムイベントを行っていますが、それぞれ異なるサービスを進めていることもあり、結局「チームの移設プロジェクトってちゃんと前進できているのか？」というのが、メンバー全員で同期するのが難しくなっていました。このような問題を改善するため、チームで導入したタスク運用術についてご紹介します！困っていたことをもう一度整理する 1. チームプロジェクトの進捗が見えにくい2. タスクの優先度が同期できない3. 適切なリソース配分やフォローが難しい「zettao」を導入してみた zettaoの運用方法zettaoに設定すべきタスクは何か？期待していた効果「zettao」がチームにもたらした3つの変化 1. タスクの「なぜ？」を問う文化の醸成2. 「進捗どうですか？」の解像度が上がり、個人ではなくチームとしてタスクを絶対倒すためのアクションが取れるようになった3. 大きなプロジェクトへのコンパスができたまとめ困っていたことをもう一度整理する私たちのチームが感じていた課題は他にもあり、最終的には大きく3点に集約されました。1. チームプロジェクトの進捗が見えにくいメンバーそれぞれが異なるサービスや領域のタスクを抱えているため、毎週スクラムイベントを行っているものの、「チームとしての移設プロジェクトが進んでいるのか」が把握しづらい状況でした。2. タスクの優先度が同期できないメンバーそれぞれが異なるサービスや領域のタスクを抱えているため、個人ごとにはタスクに優先度付けして進めているものの、チーム全体から見るとその優先度や重要度が伝わりづらく、結果として「いまチームとして

SUZURI事業部ウェブエンジニアのkromiiiです。SUZURIではさまざまな非同期ジョブをSidekiqを使って管理しています。その中で月に一度、月初に実行されるジョブがあり、これがなぜか半年に一回の頻度で落ちることがあったので、その原因と対策をお話しします。発生していた現象原因の調査対策 1. ジョブをべき等にする2. terminationGracePeriodSeconds を設定する3. Sidekiq の外でジョブを実行するおわりに発生していた現象Sidekiqを実行しているPodのログを見たところ、ジョブは以下のようなメッセージとともに突然終了していました。{"ts":"2025-05-01T05:06:16.936Z","pid":1,"tid":"2hd","lvl":"INFO","msg":"Bye!"}これ以外にはエラーメッセージはなく、突然Podが停止しているような印象を受け、デバッグは難航しました。結局原因は特定できず、重いジョブが特定の時間に集中してシステムの負荷が高まったのが原因だろうと判断し、ジョブに必要なデータを再抽出した上で時間を空けて再度実行することで解決しました。原因の調査しかしその半年後、またしても同じようなメッセージとともにジョブが落ちることがあり、今回はログだけでなくさまざまなメトリクスを見ながら原因を調査していたところ、ある事実に気づきました。上の画像はジョブが落ちた前後のSidekiqのCPU使用率で、それをPodごとに色分けして表示しています。これを見ると、想定したよりもCPU使用率はずっと低く、システムの負荷が原因で落ちているわけではなさそうだということがわかりました。しかし色分けの結果からジョブが落ちた前後でなぜかPodが生え変わっていることに気づきました。「なぜこのタイミングでPodが生え変わったのだろう」と考えると、思い当たることが一つありました。本番リリースです。リリースによってSidekiqのジョブが消し飛んでしまう現象は有名なこちらのスライドでも説明されていましたが、まさにそれと似たような現象がわれわれのサービスにも起こっていました。つまりジョブが実行される時間に本番リリースがあり、これによってSidekiqのPodが生え変わってしまうと、実行中のジョブが中断されてしまっていたのです。わかってし

はじめに2025年に新卒エンジニアとして入社しました、bqnq です。新卒エンジニア研修の一環として、新卒パートナーで『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』を読みました！読書会で扱ったのは第1, 2, 3, 9章です。新卒パートナーがそれぞれ1章ずつ担当し、読んだ内容について説明しながら議論するという形式で行いました。はじめに研修中での Bad Code 体験談今後の自分のコードにどう活かすか／意識したいことみんなの感想 SatoMichi：Chapter1担当bqnq: Chapter2担当Jonny: Chapter3担当taki: Chapter9担当研修中での Bad Code 体験談研修では、私は Cursor を使ってコードの実装を行っていました。AIエージェントに頼れば、要件を満たすコードがすぐに生成され、テストも問題なく通ります。実際に使ってみて、便利だと感じています。しかし、後から自分の実装を見返すと、複数の責務が詰め込まれていた実装になっていて、コードが肥大化していることに気づきました。明示的に粒度についてプロンプトで指示していなかったため、実装が読みにくく・変更しづらく・再利用しにくい構造になってしまっていました。また、研修という限られた時間の中では、リファクタリングの時間がなく、コードの構造まで意識を向けられませんでした。これらのことがBad Codeを生む最大の原因だったと感じています。今後の自分のコードにどう活かすか／意識したいこと今回の研修を通して強く実感したのは、AIエージェントはあくまで補助輪であり、設計や実装の最終的な責任は自分にあるということです。たしかに、AI を使えばこれまでより早くコードを実装できます。しかしその一方で、運用や保守、拡張を意識した設計の質が伴っていないことに、後から気づくことが多々ありました。ペパボでは「最高・最速の両立」という価値観が掲げられています。私は最高とは何かを考えられるエンジニアでありたいと思っています。AIは動くコードを返してくれますが、なぜこの設計にするのか、どうすれば読みやすくなるのか、責務をどう分離すべきかといった設計意図までは汲み取ってくれません。今後は、設計のゴールを自分の頭で描くことを意識して業務に取り組みたいと考えています

はじめにminne事業部プロダクト開発チームのtossy＆fumyです。2025年7月26日に株式会社マネーフォワード様の京都支社にて開催された 「【非公式】きのこカンファレンス in 関西」 に参加＆登壇をしてきました！「【非公式】きのこカンファレンス in 関西」とは？「【非公式】きのこカンファレンス in 関西」は、「エンジニアがこの先生きのこるためのカンファレンス」をテーマに開催されるITカンファレンスです。参加者が自身のキャリアやロードマップを見つめ直し、未来を描くヒントを得ることを目的としています。現役エンジニアはもちろんのこと、デザイナーやマネージャーといった周辺職種の方、エンジニアを目指す学生など、幅広い層が対象です。年齢を問わず、キャリアのヒントや働き方、ライフステージとの向き合い方、そしてエンジニアとしての生存戦略について深く考える機会を提供しています。【非公式】きのこカンファレンス in 関西※【非公式】となっているのは、きのこカンファレンスの運営メンバーの方々に相談をし、名前を貸していただいた別イベントのためです。登壇内容: 会場にあったのは「エンジニア一人ひとりの人生の縮図」「【非公式】きのこカンファレンス in 関西」の登壇内容は、まさにエンジニア一人ひとりの人生の縮図を見ているようでした。それぞれの発表から、各自の個性や深い洞察が感じられ、とても多くの学びがありました。登壇者の皆さんそれぞれのプロフィールや技術的バックグラウンドが個性的で、まさにエンジニアの「生き様」を感じました。単なる方法論や技術的な解説だけでなく、そこに至るまでのキャリアの選択、困難にどう向き合ってきたかなど、深い知見や示唆に富む内容ばかりで、深く共感する場面が多々ありました。特に印象的だったのは、「率直な議論」や「現場の生の声」 といった、現地でしか聞けない「リアリティーに溢れる生きた情報」が聞けたことです。これはオンライン開催では味わえない、オフラインイベントならではの醍醐味だと感じました。また、休憩時間がこまめに設けられていたのも、このカンファレンスの嬉しい点でした。おかげで、参加者同士での交流や意見交換、情報交換をする機会が非常に多く、新たな繋がりも生まれました。また、会場全体が笑いや驚きの感情に満ち溢れていたのがとても印象的でした。この経験や知見は、今後の

こんにちは技術部データ基盤チームの染矢です。日本では暑さが本格的になってきましたね。最近の私はアイスの実が主食になりました。この記事では、Debezium Serverによる変更データキャプチャ（CDC）ログの抽出の状態を観測可能にした技術について紹介します。この記事で書くことJVM環境におけるOpenTelemetryについてDebezium Server内部で実装されている計装についてOTel CollectorからAmazon CloudWatchにテレメトリを送信する方法についてこの記事で書かないことDebezium Server、OpenTelemetry、Amazon CloudWatch自体の説明背景ペパボのCDCペパボでは、ニアリアルタイムなデータ分析を目的に、各サービスのデータベースに対してCDCを実施しています。ペパボではCDCを実現する手段としてOSSのDebezium Serverを使用しています。Debezium ServerによるChange Data Captureの事例紹介をお読みください。Debezium ServerはECS on EC2でホストされています。CDCログの送信先はCloud Pub/Sub Topicです。課題 - データ反映遅延さて、「ニアリアルタイム」と謳っている以上、そのデータ鮮度は維持したい指標です。以前、なぜかわからないけどCDCログの処理が遅延したことがありました。経路全体を見てDebezium Serverがボトルネックであると判断した後、さまざまなパラメータをいじっているうちになぜかわからないけど直りました。Debezium Serverコンポーネント内での原因切り分けが難しいと、それだけデータ反映遅延の復旧が難しくなります。そこで、集められるテレメトリーを集めて探索可能にする仕組みの整備を決定しました。テレメトリーの収集今回のDebezium Serverのテレメトリー収集には、次の技術を使いました。計装と出力はOpenTelemetryのJava Agentにさせます。間にOTel Collectorを立たせます。最終的にCloudWatchに保存し、CloudWatch上でクエリできるようにします。それぞれ詳しく説明していきます。Java AgentOpenTelemetry用のJava Ag

技術部データ基盤チームの zaimy です。2025年7月11日に開催されたData & Analytics 井戸端会議 #03 「データアナリストから見たデータ基盤」に登壇しました。「井戸端会議」という名前の通り、発表者と参加者の議論を通じてデータ基盤に関わる知見を共有し合うイベントで、30名の定員に対して44名の申し込みがあるなど、多くの関心を集めるイベントとなりました。イベントについてData & Analytics 井戸端会議は、データエンジニア、MLエンジニア、データアナリスト、アナリティクスエンジニアなど、データ基盤に関わる職種の方々が集まるイベントです。今回のテーマは「データアナリストから見たデータ基盤」でした。LINEヤフー、メルカリ、GMOペパボに所属する3名によるライトニングトークが行われ、発表後の「Ask the Speaker」セッションや懇親会を通じて、参加者同士の活発な交流が行われました。『ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり』私からは「ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり」というタイトルで発表しました。発表の背景ペパボでは、従来の「データプラットフォーム」としてのデータ基盤から「データプラットフォームサービス」への転換を図り、事業部制組織におけるデータ活用の課題に取り組んできました。特に、ビジネス部門が深いドメイン知識を持ちながらもデータ分析に集中できていないという課題や、データ利用者のデータに対するオーナーシップや継続活用の問題に直面していました。具体的な取り組み発表では、以下の取り組みについて詳しくお話ししました。1. Team Topologies の導入チームタイプとインタラクションモードの明確化2. ELT（Extract, Load, Transform）モデルをベースにした責任境界の明確化データエンジニアリングチームとビジネスチーム間の役割分担各チームが得意領域に集中できる体制の構築3. データの Transform 層のフレームワーク化ビジネスチームが扱いやすいデータ変換ツールの整備セルフサービス分析の推進4. ビジネス職の基盤チーム加入によるサポート強化ビジネス観点とテクノロジー観点の融合意思決定プロセスの効率化取り組みの成果これらの取り組みを通じて、以下のような成果

この記事の担当 @penpeen214224こんにちは！ 2025年6月1日にGMOペパボに入社した Ikechi です。Agentic AI/Vibe Coding を駆使して、入社15営業日で、minneのクーポン割引額上限機能をリリースした話をします。入社早々、決済処理に変更を加えることに不安がありましたが、Vibe Codingを通じて、ドメイン知識を習得しながらリリースを実現することができました。リリースまでの道のりとVibe Codingによる開発の中で得られた知見を共有しようと思います。Vibe Codingとは？Vibe Codingは、「完全に雰囲気に身を任せて、コードの詳細に気を払わず、自然言語だけで指示をしてコーディングする」コーディングスタイルです。このスタイルは、OpenAIの共同創設者であり、TeslaのAIディレクターとしての経験があるAndrej Karpathy氏が2025年2月に提唱したものです。There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…— Andrej Karpathy (@karpathy) February 2, 2025GMOペパボでは2025年新卒研修でも 「Vibe Coding」研修を実施しています。日本初!?「Vibe Coding研修」を2025年新卒研修の目玉として実施しますminne についてminne は GMOペパボが運営している 「ハンドメイド作品の売買ができる国内最大のハンドメイドマーケットプレイス」 です。2013年にローンチされ、私がこれまで経験したRailsプロジェクトよりもかなり大きい規模のプロダクトです。$ bin/rails stats+---------------------

こんにちは！GMO ペパボのグループ会社である GMO クリエイターズネットワークのよしだです。2025/06/28開催のPHPカンファレンス2025に登壇 & 実行委員として参加してきました！登壇についてMySQL5.6から8.4へ 戦いの記録当日は下記の流れで説明しました。システム構成方針先行対応アップグレード当日まとめ本件で一番苦労した点として、既に保存されている「ゼロ日付」への対応がありました。ゼロ日付をnullにすることで、Goのコードの修正、テーブル定義の修正、既存のデータのUPDATE、Redashのクエリ修正に対応する必要があります。数も多く、大半の労力をゼロ日付に捧げました。既に保存されているデータは意外と盲点ですが、注意深く対応しなければなりません。もしMySQL5.6から8.4へアップグレードする方がいれば参考にしていただけると幸いです。実行委員について実は数年前からPHPカンファレンスの当日スタッフや実行委員をやらせていただいてます。今回は、実行委員として参加したため、開催の数ヶ月前から準備を行っていました。実行委員が主にやることとしては下記の通りとなります。会場手配・設営準備スポンサー募集スピーカー募集プログラム作成当日スタッフ募集広報備品発注上記の作業を各担当ごとに割り当てて、進めていくことになります。事前準備今回、私は「スピーカー担当」であったため、メインの作業はスピーカー確定後からになります。スピーカーの採択確認やTシャツのサイズ確認、各種案内メールの作成と送信などを行っていきます。また、当日のスピーカー受付用の管理表の作成や、当日スタッフ向けのマニュアル作成、シフトの作成なども行います。中でも、スピーカー受付用の管理表は、スピーカーの特徴などを収集しつつ、当日の不測の事態に備えてスピーカーへコンタクトが取りやすいように作成する必要があります。良かった点として、去年までは、スピーカーの名前の読み方を当日の受付の際に伺っていましたが、今回は事前にTシャツのサイズと共に集められました。来年はセッションタイトルの読み方も事前に集めることで、当日の負担を減らせると良いなと思います。前日作業前日は実行委員や当日スタッフの中から参加できる方々で、会場の 大田区産業プラザPiO で設営を行います。登壇ステージやスポンサーブースの設営と、来場者配布物

こんにちは。技術部技術基盤グループのshibatchです。プラットフォームエンジニアとして、主にSUZURIやminne、カラーミーといった複数プロダクトをより良くするおしごとをしています。ちょうど1年前、私は なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか という記事を執筆しました。これはHerokuコンテナを移設するにあたり、Amazon EKSにするのかAmazon ECSにするのかを悩みに悩んで判断した事例が、どなたかのお役に立てればと考えてのことでした。実はこの記事が出た直後くらいには移設は完了しています。遅れに遅れたのですが、さすがにそろそろ…と思い移設の詳細についてご紹介します。移設の手法EKSといいますか、AWSのVPCへ移設することにしたのは、以前の記事で紹介した通り、明確に移設のリスクが低い手法を採れるからです。実はHerokuはAWSのVPCの上で構成されており、Enterprise版だと専用環境(Private Space)を構築できます。まさにSUZURIはそのような使い方をしているのですが、この場合はVPC Peeringを通じて自身で構築したVPCと疎通することができるのです。つまり、実質AWSの別のネットワークからペパボ(SUZURI)のネットワークに動かすイメージで移設を行えることを意味しています。これを順に説明していきますね。移設前の構成まずはじめの状態です。Herokuは以下で構成していました：Dynoと呼ばれるコンテナRedis（アドオン）PostgreSQLデータベース（アドオン）Schedulerと呼ばれるジョブ（アドオン）先ほど言った通り、これらは運用する上ではほぼ意識はしませんが AWSのVPC、東京リージョンで使っていました。移設の8つのステップ1. ネットワーク設計まずは移設先のVPCを新しく作成しました。VPCは/16 で作成し、サブネットは以下の通りに分けました。Kubernetes専用ではなく、将来にわたって使っていくことを見越したVPCになります：Global IPをつけることができるPublic Subnet (/24) を各リージョン1つずつ、計3つ分RedisやDatabaseを移設する予定のPrivate Subnet (/22)を各リージョン1つずつ、計3つ分Kubernet

快適なショップ運営体験を目指して、カラーミーショップ上での商いを支援する「管理画面」のユーザー体験の改善を続けています。このアプリケーションを長期間運用していく中で、開発体験に関する以下のような問題が出てきました。DOM APIを直接利用した手続き的なUIの実装により、管理する状態が複雑になるにつれてコードの見通しが悪くなる適切にモジュール化されていないスクリプトによるテスタブルではない実装ユーザー体験の向上のために多機能なUIを提供しつづけるためには、これらの課題も同時に解決する必要がありました。管理画面はショップ運営において重要なWebアプリケーションであることから開発頻度も高く、日々機能が追加されていきます。また、注文の処理や顧客管理、ECサイトのエディタなど、提供している機能も多岐に渡ります。このため、ショップ運営や他の開発プロジェクトに影響を与えないように、徐々に、かつ継続的に取り組みを広げていくことが重要となります。Nuxtをはじめとしたフロントエンドフレームワークベースのアプリケーションサーバに機能を移行すれば、統合されたフロントエンド開発環境を手にいれることができ、かつSSRをはじめとした機能によって快適なユーザー体験を提供できますが、作業量の観点から、現時点では全面的に移行する作戦を取ることは困難でした。この前提のもとに、Vue.jsを活用し、様々な工夫によりフロントエンド関連技術を徐々に導入しているので、その事例を紹介します。Vueコンポーネントをカスタム要素ライブラリ化して利用するVueコンポーネントは defineCustomElement() APIを介することで、Web Componentsにおけるカスタム要素として利用することができます。HTML上に直接配置できるようになるメリットのほかに、スタイルやUIに必要なスクリプトをDOMの構造と一緒に配信できるので、UIコンポーネントのポータビリティを高めることができます。以前からこのAPIを活用することで、サーバサイドのテンプレートエンジンで描画するHTMLのあらゆる箇所で、Vueコンポーネントを部分的に利用しています。ショップ運営を支えるプロダクトにフロントエンド開発環境を薄く導入しているカラーミーショップの管理画面のVue 3マイグレーションを行っています加えて、パッケージ構成を工夫する