今年もペパボは、Kaigi on Rails 2025に参加してきました！登壇・一般参加・運営スタッフなど、それぞれのイベントへの関わり方で楽しみました。この記事では、私たちがどのようにイベントを過ごしたのか、印象に残った出来事や感じたことなどを、それぞれの視点からお届けします！Kaigi on Rails とは登壇者のレポート yumu登壇を終えて一般参加者のレポート akatsuuratossyyancyaオーガナイザー(運営スタッフ)のレポート shiorinchiroruまとめKaigi on Rails とはKaigi on Rails のコンセプトは「初学者から上級者までが楽しめるWeb系の技術カンファレンス」です。その名前の通り、Ruby on Railsを中心としながらも、Webに関する話題を幅広く取り扱うのが特徴です。例えば、フロントエンド技術、プロトコル、設計手法、決済などをテーマにしたトークも行われています。初回の2020年にオンラインで開催されたことを皮切りに、2023年からはオンラインとオフラインのハイブリッド形式で開催されています。2025年の今年は3度目のハイブリッド開催で、オフライン会場はJPタワー ホール＆カンファレンスで行われました。登壇者のレポートyumuminne事業部の@yumuです。今回「Railsアプリから何を切り出す？機能分離の判断基準」というテーマで登壇しました。発表内容13年以上運営されているminneでは、コアとなるRailsアプリケーションのコードベースの複雑化やDBパフォーマンスの悪化といった課題に直面し、様々な機能の分離を検討・実施してきました。しかし、その都度「この機能は分離すべきか」という判断に悩まされていました。そこで、2年間で経験した様々なプロジェクトの中で得た知見を体系化し、5つの判断軸として整理しました。判断軸 分離推奨 要検討 分離回避 ビジネスロジックとの関連度 低 中 高 インフラ依存 弱 中 強 複雑さ シンプル 中 複雑 運用コスト vs 開発スピード 開発スピード重視 バランス 運用コスト重視 ビジネス上の柔軟性 求められる 中程度 求められない 1. ビジネスロジックとの関連度コア機能（商品管理・注文・決済など）や複数テーブル・モデルと密結合している機能は分離を避けるべきです。一方

こんにちは、2025年新卒エンジニアのtakiです！10月4日～5日に開催された NASA Space Apps Challenge 2025 に同期と参加してきました。本記事ではそのレポートをお届けします。参加の経緯とハッカソンのすすめNASA Space Apps ChallengeとはつくったものCUPOLA QUESTの詳細 takiJonnybqnqraito結果おわりに参加の経緯とハッカソンのすすめなぜ NASA Space Apps Challenge 2025 に参加したのか、その経緯とともに、ハッカソン参加についてお伝えしたいことがあります。私たちは、入社時の研修のときから「同期でハッカソンに出たいね」という話をしていました。ハッカソンを調べてみて、スケジュールとテーマが私たちにあうものを選ぼうと思っていました。しかし、調べ始めてから気がついたんです。ほとんどのハッカソンは学生限定であると…！社会人が参加できるハッカソンはなかなかありませんでした。そんななか、やっと見つけたのが NASA Space Apps Challenge 2025 。社会人も出られる上、規模も大きく、宇宙関係のテーマ。宇宙好きのメンバーが複数いる私たちにとって最高のハッカソンでした。たまたま見つけた社会人OKのハッカソンが、私たちにぴったりのものだったので、「これだ！」となり参加することとなりました。本当にラッキーな出会いでした。学生の皆さん、ハッカソンは学生のうちに出ておきましょう！”学生のうちに学割を使い倒すんだ！”とよく言われますが、それと同じ熱量で言っております。学生じゃない方は、出られるハッカソンを見つけたらチャンスです。迷わず出ましょう！NASA Space Apps ChallengeとはNASA Space Apps Challengeは、NASAが主催する世界最大規模のグローバルハッカソンです。2025年は10月4日～5日の2日間、世界中で450以上のローカル会場とオンラインで同時開催され、登録者数は22万人を超えています。このハッカソンでは、NASAやそのパートナー宇宙機関が公開するオープンデータを活用して、地球環境や宇宙探査に関する実際の課題に取り組みます。参加者は提示された18個のテーマの中から1つを選び、衛星データの可視化から宇宙探査技術まで、幅広

こんにちは。ペパボでは最近宇宙への興味が指数関数的に上昇しています。本記事は、ペパボでの第一回宇宙イベントとして実施した、宇宙食ランチ会についての話です。何も考えずに宇宙食の話を振ったらランチを企画することになった@takiと、 宇宙を一番知っていて好きな人枠に自ら名乗り出た@haruotsuがお送りします。なぜ急に宇宙なのか執筆者：@haruotsuテック企業と宇宙産業の急接近もちろん、社内に宇宙に興味を持つパートナーが多かったり、やっていき・のっていきの文化ということも大きな理由の一つではありますが、エンジニア視点で改めて「なぜいま宇宙なのか」を考えてみたいと思います。ここ数年、宇宙産業は劇的な変化を遂げています。かつては国家主導の巨大プロジェクトが中心だった宇宙開発は、コストが安くなり、民間企業の参入により宇宙はもはや遠い存在ではなくなりつつあります。そのような中で、私たちエンジニアにとって宇宙は技術的好奇心を刺激する要素に満ちています。極限環境での信頼性設計：宇宙空間という過酷な環境で動作するシステムは、地上のサービス開発を応用できる可能性の宝庫大規模データ処理：地球から数分〜数時間の通信遅延がある環境からの膨大なデータをリアルタイムで処理や自律的な意思決定する技術は、私たちが日々向き合うスケーラビリティの課題に通じるこれらは一例ですが、一見遠い存在に思える宇宙開発ですが、実は私たちが日々取り組むWeb開発と多くの共通点があります。高い可用性が求められるインフラ設計、リソース制約下での最適化、リモートでのシステム監視・運用など、宇宙開発で培われた手法やマインドセットは、現代のアプリケーション開発やクラウドインフラの実践に通じるものを感じています。spaceチャンネルの誕生あんちぽさんと話をする中で、宇宙に興味を持つメンバーが集まるチャンネルを作成しました。まずは宇宙情報、コミュニティに気軽に触れ合える場を作るために#space チャンネルを作成しました。ここでは日々、宇宙に関するニュースが流れたり、宇宙に関する雑談をしたり、こんな場所に行ってきた！などとわいわい共有がなされています。今回の宇宙食ランチも、この#space チャンネルで宇宙と掛け合わせてなにかペパボとしてできないか、というような会話をしていたときに、宇宙関連ショップを眺めていて、@taki が

はじめにEC事業部エンジニアの yukyan です。最近はあすけんのキャラクターに怒られる毎日が続いています。この記事はGoGoペパボという社内のGoコミュニティがお送りする、「GoGoペパボアウトプット祭り」の第一弾です。残り2つ、GO株式会社さまと共同で開催したGoイベントと、Go Conference 2025の参加についての記事が出ますので、よければそちらもGoタグからご覧ください。9月27日(月)、ちょうどGo Conference 2025の翌日にGMO Yours・フクラスにて、golang.tokyo #41を開催しました。golang.tokyoは、導入企業のメンバーが集まり、Goの普及を推進する東京のコミュニティです。活動の一環としてイベントを各社が定期的に行っており、毎回Goに関する技術的に深い話から初心者歓迎の登壇まで、幅広いテーマの発表を聞くことができます。GMOペパボにはGoGoPepaboというGoの社内コミュニティがあり、Goを多く使っているロリポップ・ムームードメイン事業部、技術部のエンジニアを中心に毎週Goに関する話題や、お悩みごとについて話しています。その活動の一環としてさまざまなイベントに参加しており、その中でご縁がありGoのコミュニティイベントである golang.tokyo を開催させていただくことができました。この記事では、当日の様子と、社内のGoコミュニティの初挑戦だった「配信」の裏側をお届けします。ぜひgolang.tokyoへの参加や、イベントの開催を検討している方に読んでいただきたいです。はじめに当日の様子 Xでの反応懇親会裏話: 配信での工夫 配信の理想像を描くMermaidで配信の構成図を書いておくリハーサルをするアンケートの結果おわりに当日の様子Xでの反応まとめました。多くの投稿をありがとうございます！きたよ！#golangtokyo— the よしだ (@theyoshida3) September 29, 2025竹田さんによる「Go Embedでwasm埋め込み(仮)」すっかり上げ忘れてました昨日のgolangtokyoで発表した資料です！Go EmbedでWasmを埋め込む話ですhttps://t.co/ZpxqRS1WJc#golangtokyo— TKD (@TKDDDDDS) Septembe

筑波大学1年生の私、大学との共同研究で医療のDX化に挑み、そして今GMOペパボのエンジニアとして働く話。はじめに皆さん、はじめまして！GMOペパボ株式会社で学生エンジニアとして勤務しています、高橋実来と申します。普段は筑波大学の情報学群に在籍し、医療情報の広大な海を泳いでいる（時々溺れかけている）1年生です。つい先日、このテックブログの存在を知り、「私も書いてみたい！」と感じたため今回このように執筆してみました！そんな記念すべき初筆の記事テーマは、「私がこれまでどんな道を歩み、なぜ今GMOペパボにいるのか」です！実は私、今まで様々なプロジェクトに携わってきており、社内でも度々「経歴が突出的すぎる！」などと話題に上がっていたため、今回は上記テーマで執筆させていただけますと幸いです！なぜここに？ 〜ソロ冒険者、パーティープレイの重要性に気づく〜私のこれまでの活動は、良く言えば「独立独歩」、ゲームに例えるなら「孤高のソロ冒険者」でした。思い返せば3歳の頃から手の届く範囲にドライバーがあり、家電を分解するほど好奇心旺盛。目の前にある課題に対し、あらゆる知識を駆使してクリアしてきました。その最たる例が、コロナ禍でのアプリ開発です。これは私の主観的な所見ですが、当時、私の住む静岡県は未知のウイルスに混乱し、行政からの情報発信も十分ではありませんでした。「日々の感染者数やワクチン予約をアプリで管理できたら…」という思いから、独学でプログラミングを学び「静岡県新型コロナ対策アプリ」をリリースしました。このアプリは後に、県主催のコンテストで複数の賞をいただきました。しかし、こうしたソロプレイでの冒険には限界も感じていました。一人でサービスを創るのは最高に楽しいですが、それは広大なフィールドを一人で駆け巡るようなもの。一方、世の中で愛されるサービスは、多様な職業の仲間（専門家）が知恵を出し合い、長い年月をかけて築き上げた巨大な城や国に例えることもできると、私は考えます。その世界の成り立ち（設計思想）や冒険のルール（開発プロセス）、連携のノウハウ（チーム開発文化）は、外から眺めているだけでは決してわかりません。GMOペパボが掲げる「もっとおもしろくできる」という言葉に、ユーザーのために新たな価値を創り上げてきた力強い意志を感じました。この場所なら、私のソロでの冒険経験を、伝説級のレイドボ

こんにちは。GMOペパボのてつをです。2025年10月4日（土）～5日（日）の2日間、GMOペパボ鹿児島オフィスにて「かごがくハッカソン2025 byGMOペパボ」を開催しました。「かごがくハッカソン」は鹿児島で学ぶエンジニア志望の学生たちが集まり、2日間の開発合宿を通じて新しいアイデアやサービスを創出するイベントです。昨年に続き2回目の開催となった今回、私は実行委員長として運営に携わりました。本記事では、ハッカソンの様子と、学生たちが生み出した素晴らしい作品たちをレポートします。ハッカソンに興味がある学生の方、技術イベントの開催を検討されている方、鹿児島のエンジニアコミュニティに関心がある方は、ぜひご覧ください。ハッカソンとはハッカソンとは、ハック（hack）とマラソン（marathon）を組み合わせた造語で、短期間で集中的にアイデアを形にするイベントです。参加者はチームを組み、限られた時間の中でサービスやプロダクトを開発します。イベント概要今回の「かごがくハッカソン2025 byGMOペパボ」の開催概要は以下の通りです。日程: 2025年10月4日（土）10:00 ～ 5日（日）21:00会場: GMOペパボ 鹿児島オフィス参加者: エンジニアを目指す学生34名参加方法: チーム参加（2名以上）または個人参加（運営側でチーム編成）テーマ: 自由(プログラミングを用いて制作したものであれば何でもOK)また、以下のような学生におすすめのイベントとして企画しました。ものづくりすることが好き！アウトプットしたい！エンジニア志望の学生とつながりたい！就活を見据えて成果物を作りたい！開発インターンやアルバイトの予定がないけど、何か形に残したい！また、テーマは完全に自由で、Webアプリ、モバイルアプリ、ゲーム、IoT、AIを使ったサービスなど、プログラミングを用いて制作したものであれば何でもOKです。豪華審査員陣今回のハッカソンでは、以下の3名の審査員をお迎えしました。栗林 健太郎（あんちぽ）GMOペパボ株式会社 取締役 CTO 兼 事業開発部部長 兼 CTO室室長X: @kentaro今熊 真也株式会社ユニマル 代表取締役X: @shin73渕田 孝康鹿児島大学 教授情報基盤統括センター センター長スポンサー企業のご紹介とご支援今回のハッカソンは、GMOペパボ株式会社の主催

はじめに新卒エンジニア研修を担当しました、yukyan, ugoです！今年も新たなパートナーを迎え、研修のカリキュラムを実施しました。この記事では、各コンテンツの講師陣がその内容と資料をまとめています。ぜひご覧ください!はじめに2025年度新卒エンジニア研修概要Webアプリケーション開発研修フロントエンド研修コンテナ研修オブザーバビリティ研修セキュリティ研修 アプリケーションセキュリティ研修(n01e0)過去インシデントの再現アプリケーション体験と伝承 (hiboma 研修)ドメイン名とDNSに関連するセキュリティの話 (hirokawa 研修)影響を広げる力研修 実体験から学ぶアウトプットの価値実践のススメデータエンジニアリング研修 研修の狙いと構成座学とハンズオンのバランスAI 時代の学習アプローチの提案研修の成果と今後の展望機械学習研修AIを前提とした体験の実現に向けてVibe Coding研修Web3/Crypto研修外部講師による研修コンテンツおわりに2025年度新卒エンジニア研修概要今年は、新卒エンジニアはもちろん、講師陣や迎え入れる全パートナーで「2年後にシニアエンジニアになる」という目標を掲げました。ここでいう「シニアエンジニア」とは、ペパボのエンジニアの制度上の職位になります。エンジニア組織と制度シニアエンジニアは、単に業務を遂行する能力が高いだけでなく、ペパボにおける人材要件の3軸すべてにおいて高度な専門性が求められます。作り上げる力：専門領域において、組織のトップレベルを引き上げられる深い知識を持ち、未解決の課題の解決を完遂できる先を見通す力：専門領域の将来像を示し、現状を整理して課題を抽出した上で、技術・手法の候補を理由とともに言語化し、組織の技術標準として昇華できる影響を広げる力：自身の技術的な経験や知見を言語化し、社内外に発信することで組織力向上やファン獲得につなげられるまた、シニアエンジニアへの昇格の判断は、日常の中で3軸を満たすふるまいをしていることを言語化して表明し、その評価によって「追認」されるものです。つまり、2年後にこの職位に到達するためには、それまでにそうしたふるまいを日常的にできているという実績が必要です。こうした、ペパボのエンジニアリング組織のトップレベルを引き上げられる専門力を持ったシニアエンジニアに向け走っていくため

はじめにはじめまして！2025年のGMOペパボサマーインターンに参加しましたインターン生のマッチーノです！インターンシップでは事業開発部のAlive Studioに配属され、9日間でたくさんの経験や学びを得させていただきました。この記事では、アウトプットも兼ねてインターンシップでの体験や感想を書き留めていこうと思います！はじめに この記事を読んでほしい人インターンシップの概要インターンシップに参加するまで 応募した理由面接インターンシップで期待していたことインターンシップのタスクについて インターンシップのタスク紹介実際の実装日常について ミーティングランチ福利厚生インターン生！感想おわりにこの記事を読んでほしい人GMOペパボや Alive Studio に興味がある方夏のインターンで成長したい方楽しくチーム開発を体験したい方ライブ配信やVTuber向けのプロダクト開発に興味がある方インターンシップの概要業務概要：機能改善や新機能の開発配属サービス： Alive StudioLOLIPOP! for GamersSUZURIカラーミーショップ期間：9日間（09/08〜09/19 10:00〜19:00）勤務形態：原則出社参加人数： Alive Studio：4人（自分はここ！）LOLIPOP! for Gamers：2人SUZURI：4人カラーミーショップ：4人待遇： Claude Code 使い放題！MacBook Pro 貸与（Windowsも可）ランチ無料ドリンク飲み放題交通費宿泊費支給時給：1,700円インターンシップに参加するまで参加するまでの経緯や応募理由について書いていきます！応募した理由GMOペパボのサマーインターンを知ったきっかけは、大学でのインターン説明会でした。そこからインターンの内容やGMOペパボの事業内容について調べ、「就活が本格化する前に実務を経験したい」 という思いと、「プロダクトやミッションが自分の軸と合致している」 と感じたことが決め手となり、応募に至りました。選考フローは書類選考と面接のみで、選考スケジュールは、7/10 書類提出 → 7/14 書類選考通過 → 7/23 面接 → 7/25 合格と、書類提出をギリギリに出したことも相まってかなり短い期間での選考だったと思います。他社のインターンシップ選考がひと段落したタイミングで

こんにちは！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が生え変わってしまうと、実行中のジョブが中断されてしまっていたのです。わかってし