テクブロ — 技術ブログの新着まとめ

未読のみANDPAD

31件

フィード

ANDPAD·5日前

社内システム開発のPMからアンドパッドのPdMへ

はじめにこんにちは、PdMの永塚です。早いものでアンドパッドに入社してから２年が経過しました。私は前職では、社内向けの業務システム開発に携わるPMをしていました。営業やカスタマーサポートといった社内メンバーが利用するシステムの新規立ち上げや、基幹システムとの連携などを担当し、現場へのヒアリングを通じて業務の見直しや要件定義を行う日々を送っていました。現在は、アンドパッドのPdMとして多くのお客様に向けたプロダクトの開発を推進しています。この2年間、全く異なる環境でプロダクトに向き合う中で、「ユーザーの業務を理解し、あるべき姿を設計する」という本質は共通していながらも、業務の中で求められる思考の質や意思決定の難しさには大きな違いがあると感じるようになりました。今回は、社内システム開発のPMからアンドパッドのPdMへと転身した私が実感した、大きな違いを2つ共有したいと思います。前職の私と同じように、社内システム開発の経験を活かして次のキャリアを模索している方にとって、少しでも参考になれば幸いです。 1. 【要件定義】プロダクトをどう形にしていくか要件定義において「理想の業務フローを描く」アプローチは共通していますが、その理想を具体的なシステムや機能に落とし込むプロセスにおいて、向き合うべき前提条件や複雑さの性質が異なります。前職（社内システム開発）前職の社内システム開発では、もちろん自社の業務だけを盲目的にシステム化していたわけではありません。「業界における一般論は何か」「本来あるべき理想の業務フローは何か」を常に検討し、標準的な最適解を模索していました。一方で、実務においては独自の組織形態、既存システムとの連携制約、現場で長年積み上げられてきた運用のローカルルールなど、無視できない固有の諸条件が存在します。こうした複雑に絡み合う固有の制約を一つひとつ紐解き、今の組織にとって最も機能する着地点を見出す。「本来どうあるべきか」という理想を描きながらも、目の前の現実的な制約をクリアし、現場で本当にワークする仕組みへと落とし込んでいく。自分たちの手で社内の業務を裏から支え、最適化していく面白さが社内システム開発にはありました。アンドパッド一方で、アンドパッドに転職して向き合うことになったSaaSの世界は、前提となる条件の広がりがガラリと変わりました。対象は単一の組織ではなく、同じ建設業界に属する無数の企業です。一言で「建設」と言っても、元請、協力会社、職人さん、資材メーカーなど、本当に多種多様な業種の人たちが複雑に絡み合って一つの現場が成り立っています。さらに大企業から町の工務店さんまで、企業規模によっても業務フローや管理の細かさは全く異なります。求められるのは、個別の事象やご要望をそのまま機能にするのではなく、「なぜその業務が必要なのか」という背景を一段上のレイヤーで捉え直すことです。バラバラに見える各社の要望の奥にある『本質的な課題』を見極め、異なる業種や規模であっても『汎用的なユースケース』を設計して、プロダクトの機能に落とし込んでいく。この「多様性のなかから共通の構造を見出し共通解を導き出す」プロセスこそが、SaaS開発の難しさであり面白いところだと感じています。 2. 【合意の形成】関係者を巻き込み、どう意思決定していくか要求を要件に落とし込み、さらにリリースに向けて合意を作っていくプロセスでも以下のような違いがありました。前職（社内システム開発）社内システム開発における主なステークホルダーは、現場のユーザーやその責任者です。基本的には同じ会社のメンバーであり、目指すべきKPIや事業目標、会社としての大きな方向性を最初から共有しています。もちろん、部署や立場ごとの「利害調整」は発生します。しかし、「どうすれば今の業務がより良くなるか」そして「本来の事業目標が達成されるか」という同じゴールに向かって膝を突き合わせ、一緒に議論して決めていくことができました。同じ船に乗る仲間として、関係者が納得できる着地点を泥臭く見出していきました。アンドパッド一方で、アンドパッドに転職してからは、合意形成に関わるメンバーの広がりと、求められる意思決定の性質が大きく変わりました。まず向き合うべきユーザー・クライアントは、業種や企業の規模、さらには元請・協力会社といった現場での立ち位置によって、置かれた状況が全く異なります。そのため、それぞれの立場から上がる要望も多種多様であり、すべての要望をそのまま反映させた一律の着地点を見出すことはできません。さらに、プロダクトが成長するにつれて寄せられる要望の数は膨大になり、PdMが一人ですべてのユーザーやクライアントに直接ヒアリングを行うことは物理的に不可能です。限られた時間の中で、いかにして多様な現場の解像度を上げていくか――。そのために不可欠なのが、社内の様々なプロフェッショナルとの協働です。例えば、最も密に協働するパートナーであるPMMとは、営業やカスタマーサクセスを巻き込んだ顧客ヒアリングを通じて「現場のどのようなユーザーに対して、どんな価値を提供していくべきか」「そして、その提供できる価値を最大化させるために何が必要か」を一緒に突き詰めていきます。また、日々ユーザーと直接向き合っているカスタマーサクセスからは、現場の目線に立ったフィードバックをもらいます。新機能によって直接恩恵を受けるユーザーの体験を考えるのはもちろんですが、それに加えて、そのリリースが「プロダクトを利用するすべてのユーザーの日常の運用」にどんな影響や変化をもたらすかという、全方位的な視点での議論を重ねます。このように膨大なユーザーの要望や、社内の各メンバーが持つ現場の知見を集約し、チーム一丸となって「現場の解像度」を徹底的に上げていくこと。そしてその高い解像度をベースに、最終的に私たちがどのようなプロダクトを作っていくべきかを決めることが現在の主要な仕事です。この意思決定が難しくもありますが、アンドパッドのPdMのやりがいだと思います。おわりに私自身、転職してからのこの2年間は、向き合う世界の広さと意思決定の性質の変化に、日々頭を悩ませながらの挑戦でした。前職で培った「ユーザーの業務課題と向き合い、最適解を形にしていく経験」は今も活きています。目の前のユーザーに向き合ってきた土台があるからこそ、アンドパッドで出会う多様な顧客の声を聞いたときにも、その裏にある「本当の困りごと」を捉えることができます。一方で、社内システム開発の時には経験できなかった「膨大な要望と多角的な視点の中から、チームの力を結集してプロダクトの針路を決める」という環境は、難しさはもちろんありますが、それ以上にPdMとしての視座を大きく広げてくれる場だと感じています。もし興味を持っていただけたなら一度お話しできたら嬉しいです！ hrmos.co

プロダクトマネジメント

ANDPAD·2026/06/05

RubyKaigi 2026 のコード懇親会と RubyGems/Bundler チームの成果報告

こんにちは、Ruby コミッタの柴田です。RubyKaigi 2026 in 函館から1ヶ月が経ち、自宅のガーデニングではバラのシーズンが一段落して梅雨に入る前に剪定を...という手入れに移ったところです。今回はRubyKaigi 2026 2日目の夜にアンドパッドが運営として関わったコード懇親会 (Code Party) と、私がホストを担当した RubyGems/Bundler チームから生まれた成果をまとめます。コード懇親会の進め方コード懇親会はクリアコードの須藤さんが提唱しているコンセプトで、お酒の代わりにコードで懇親する形式の懇親会です。今回はアンドパッドが函館市民会館で会場の設営とお弁当など運営を担当しました。 www.clear-code.com 今回からテーマを事前固定にしました。dRuby (咳さん)、Ruby 本体 (前田さん)、RubyGems/Bundler (私)、mruby/PicoRuby、Ruby × Rust (udzura さん) の5チームです。当日テーマを決める方式だと初心者が入りづらいので、ホストが事前に取り組めるイシューと環境構築の道筋を用意しておき、来てすぐコードを書ける状態にする狙いがありました。 RubyGems/Bundler チームの様子私のテーブルには9名が集まり、多くは ruby/rubygems を fork してテストをどう実行するのか、という手探りなところからのスタートでした。最初に簡単に自己紹介をしてもらい取り組むイシューを選んだ後に、私が席を回りながら困ったことがないかの相談をしていました。普段使っているのに中身は読んだことがない、という状態から、当日中に PR を1本送れるところまで持っていくのが目標です。 OSS を使っていてメンテナと隣で話しながらコードを書ける機会は普段そう多くないと思います。参加者のフィードバックでも「issue に着手すべきか迷っていたところを直接相談できた」(nissyi-gh さん) という声があり、メンテナを物理的に隣に置くことの効果はやはり大きいと感じました。フィードバックは andpad-dev/code-party に全員分が公開されています。なお私は RubyKaigi 2026 の期間中に 4.0.11 をリリースしようと作業をしていたのですが、どうしても時間をかけて取り組む必要があるテストの失敗に遭遇してしまい、コード懇親会当日のリリースは断念しました。「リリースを全力で自動化している」が Day 3 での私の発表テーマだったので、まだまだやることはある、ということを実感してしまいました。 rubykaigi-2026-day-3-ruby-releases-rubyfrom Hiroshi SHIBATA その日の PR がリリースに乗るまで当日 RubyGems/Bundler チームから出た PR のうち、すでに公式リリースに含まれたものを紹介します。 rubygems/guides (当日マージ) rubygems/guides#458 (Yuhi-Sato さん): Gemfile ドキュメントの「master がデフォルトブランチ」記述を修正。 rubygems/guides#459 (otsuboa さん): ガイドのコードブロックにシンタックスハイライトを追加。 Bundler 4.0.11 (4月30日リリース) ruby/rubygems#9500 (nissyi-gh さん): newgem テンプレートの gem ガイド URL を現行の rubygems.org に更新。当日 PR、翌日マージ。 blog.rubygems.org Bundler 4.0.12 (5月20日リリース) ruby/rubygems#9502 (kurotaky さん): Bundler::LockfileParser が lockfile 以外の文字列を黙って受け取る挙動に deprecation 警告と valid? を追加。#8932 の解消。 ruby/rubygems#9505 (willnet さん): bundle config get が未設定キーで exit status 0 を返していたのを 1 に修正。#3215 の解消。 blog.rubygems.org 当日から1週間で 4.0.11、1ヶ月以内に 4.0.12 に乗っています。長年保留状態だった issue (#8932, #3215) が一晩で片付いたのは、メンテナがその場でレビューと方針判断を返せたからで、これがコード懇親会の最大の利点です。エコシステムはこの積み上げでできている RubyGems と Bundler のコードベースは、私のような主担当メンテナが書いたものよりも、こうした「気になったから直す人」の PR が積み上がって今の形になっています。普段は GitHub 越しのレビューで進むこのループを、年に一度、物理的に同じ場所で回す機会がコード懇親会です。参加者のフィードバックには「これからは気になったことがあれば issue や PR を送れそう」という声が複数ありました。当日リリースに乗った PR より、ここで contributor の母集団が一段広がったことのほうが、エコシステムへの貢献としては大きいと思っています。おわりにグループのホストを引き受けてくださった皆さん、参加者の皆さん、会場準備に動いてくれたアンドパッドの同僚たちにお礼を伝えます。RubyKaigi に毎年行っているけど懇親会では話すきっかけがなかった、という方は、来年もたぶん開催するコード懇親会に参加してください。手元の OSS で気になっていることをひとつ持ってきてもらえれば、その場で pull request の作成、または Merge まで持っていけるかもしれません。アンドパッドでは Ruby/Rails エコシステムをはじめとする、プロダクト開発に関わりたいエンジニアを募集しています。 hrmos.co

Ruby
OSS

ANDPAD·2026/06/04

アンドパッド技術イベントのご案内 2026 年 6 月

こんにちは、 id:sezemi です。季節外れの台風に振り回されましたが、元気にやっております。天候急変によるイベントのハンドリングは難しいですねぇ。さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。今月もイベント情報をまとめてお知らせします。ぜひご参加ください !! なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. スポンサー情報 | 松江Ruby会議12 開催日時 : 2026年6月6日(土) 会場 : 興雲閣主催 : Matsue.rb イベント概要 : Matsue.rb が主催する地域Ruby会議です。アンドパッドは本カンファレンスにスポンサーとして協賛します。申込方法 : カンファレンスの公式ページからお願いいたします。「興雲閣」は、松江城山公園内に建つ美しい歴史的な洋風建築です。地域 Ruby 会議らしく、趣のある空間で開催されていて、建築好きの私には見逃せない楽しみです。また、アンドパッドはブースを出展していますので、ぜひ遊びに来てください。そして nagachika が「ruby.wasm で作る MIDI コントローラー」というタイトルで発表しますので、ご期待ください！ちなみに、今回の "Kaigi" も音ネタが多いですね。 2. 登壇情報 | 食べログ x ANDPAD x Sansan モバイル勉強会 #4 開催日時 : 2026年6月17日(水) 会場 : Sansan株式会社主催 : 食べログ、アンドパッド、Sansan イベント概要 : 食べログ、アンドパッド、Sansanの3社が共催するモバイルアプリ開発者向けの勉強会です。本イベントには、アンドパッドから長堀が登壇予定です。申込方法 : イベントページからお願いいたします。今回はモバイルアプリ開発では対応が欠かせない "OS アップデート" がテーマです。当たり前すぎて、実はなかなか知見がないテーマなので、発表された Tips は貴重なものになる予感です。ぜひご参加ください！長堀翔太 @nashcft 2023 年 6 月に Android アプリエンジニアとして入社。チャットアプリの開発に携わりつつ、チームビルディングや開発プロセス改善にも取り組んでいる。長堀翔太のテックブログ執筆記事 - DroidKaigi 2024 参加レポート / 感想編 - ANDPAD Tech Blog - アンドパッドは DroidKaigi 2024 に協賛しています & 事前勉強会のお知らせ - ANDPAD Tech Blog 発表タイトル: OS アップデートの進め方がもっと共有されてほしい 3. 登壇・会場スポンサー | v-tokyo Meetup #25 開催日時 : 2026年6月16日(火) 会場 : 株式会社アンドパッド主催 : v-tokyo イベント概要 : v-tokyoが主催するミートアップイベントです。本イベントに、アンドパッドは会場スポンサーとして協賛し、会場を提供するほか、アンドパッドから羽馬（NaokiHaba）と小泉 (@ykoizumi0903) が登壇予定です。申込方法 : イベントページからお願いいたします。いま大注目の VoidZero 社が開発している Void / Vite+ がテーマのイベントです。カンファレンス並みのゲストとトークが揃い、とても楽しみですね。そしてアンドパッドのフロントエンドエンジニア陣を代表する二人、羽馬と小泉が登壇します。ぜひ期待ください。 NaokiHaba @naokihaba 株式会社アンドパッドフロントエンドエンジニア。 Vite+ Team Member 発表タイトル: Vite+ 「The Unified Toolchain for the Web」を掲げる Vite+ は、runtime や package management、build、さらには monorepo のタスクキャッシュに至るまで、あらゆる機能を一つの依存関係に統合しています。今回はこの Vite+ について、開発に携わるチームメンバーとしての視点から詳しくお話しします。小泉佑太郎 @ykoizumi0903 ANDPAD引合粗利管理や ANDPAD資料承認などのプロダクトや機能をテックリードとして開発しているフロントエンドエンジニア。業務では Vue/Nuxt を中心に、Next や React Router を使った開発にも携わる。 Zenn で Vue や Nuxt に関する記事を ykoizumi0903 というユーザーネームで書いている。小泉佑太郎のテックブログ執筆記事 (直近 2 記事を抜粋) - Nuxt の自動インポート機能、無効化しました - ANDPAD Tech Blog - 乗り換えるなら今！ Prettier から Oxfmt への移行を試してみた - ANDPAD Tech Blog 興味のあるイベントがございましたら、ぜひご参加ください !! アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。広報の経験がない方でも Welcome です！カジュアル面談やご応募、お待ちしております。 hrmos.co

Ruby
Android
フロントエンド

ANDPAD·2026/06/04

アンドパッドは総勢 23 名で RubyKaigi 2026 を楽しんできました！

こんにちは、広報の id:sezemi です。アンドパッドの広報の仕事のかたわら、 Rubyist Magazine 略して「るびま」の編集に携わっています。ただ編集と言いながら、まだまだスッといい感じの文章が書けないなぁとるびまのチャンネルで呟いたところ、 kakutani さんから「Rubyist にはダジャレの訓練が求められる…(主語ﾃﾞｶ」というアドバイスをもらい、道理で ruby-jp の Slack でみんな大喜利を (ry 。精進します！さて、アンドパッドからは RubyKaigi 2026 に採用チームも含め、総勢 23 名が参加しました。この記事では、沢山の思い出を作ってきたアンドパッドの Rubyist たちが、参加したトークやイベント、函館や会期中の思い出、そしてブースで行った立ち読み喫茶などなどをテーマに、思い思いに書きました。ぜひアンドパッドの Rubyist の KaigiEffect をご覧ください。中林友弥(@borashisan) よりトークで刺さったことや感想 Guide to getting started walking source codes of CRuby(@youchan) これまで「CRubyのソースコードを読む」ことに対して高いハードルを感じていたのですが、そのとっかかりとなる知識や、コードリーディング全般に役立つTipsを惜しみなく共有していただき、非常に実用的なセッションでした。すっかり感化され、後述する同人誌『CRuby Quest』も購入したので、これからじっくりと読み倒してCRubyの世界を歩いてみたいと思います。濃密すぎたLightning Talks LT枠とは思えないほど、通常のセッションとしてじっくり聴きたいトピックの連続でした。 Ruby on Bare Metal(@S.H.): 「mRubyを使えば簡単に動くからあえてCRubyをベアメタルで動かす」という気骨に痺れました。最低限の依存関係を特定して動かすアプローチが非常に面白かったです。 Is Ruby's Multi-Encoding Overhead Heavy?(@ima1zumi): RubyがCSI方式といういわば力技でマルチエンコーディングに対応していることを初めて知りました。「そんな無理をしてそうなのにオーバーヘッドがないのか？」という疑問に真っ向から切り込む調査が興味深かったです。 Pure Intonation on Browser(@nagachika) 純正律と平均律の話から始まり、「シャサフ式音楽理論」、さらにはそれを表現するための「シャサフ語」という言語まで存在していることを知り大変興味深かったです。アコースティック楽器特有の制約を持たない電子音楽だからこそ、純正律や微分音を論理的に扱うルールが発展していくのだなと深く感動しました。 A Faster FFI(@tenderlove) 技術的な深さはもちろんのこと、アーロンさんによる流暢な日本語で、しかもユーモアたっぷりに発表されているプレゼン力に感銘を受けました。 Ruby Committers and the World(@rubylangorg) 毎年恒例のコミッター陣によるセッションです。「今やほとんどのコミッターがAIによるRuby開発を行っている」という実態や、多数決に頼らないコミュニティ運営の難しさなど、リアルな議論を聞くことができました。技術的な話題では String#popcount の導入提案が印象的でした。最初は用途のイメージが湧きませんでしたが、調べてみるとハミング距離の計算や、在庫管理・予約枠をビット列で表現した際の高速な一括取得など、パフォーマンス改善に大きく寄与する可能性を知り、言語仕様が実務にどう活きるのかを考える良いきっかけになりました。 Matz Keynote(@yukihiro_matz) 今年のMatzさんのKeynoteは、AIを活用して開発したAOTコンパイラ「Spinel」についての内容でした。 (AOTコンパイラってなんだって思ったんですが、実行中にコンパイルされるJITコンパイラに対して、通常僕らがイメージする事前に実行されるコンパイラのことをこうやっていうんですね。) Rubyの構文でGo言語のようにシングルバイナリを生成できるようになる未来が提示され、とてもワクワクしました。また、Matzさんご自身がClaude Codeを使って大きな桁の掛け算（カラツバ法）を最適化しようとした際、AIから「もっと良いアルゴリズムがある」と提案されてそれを採用したというエピソードには、「MatzさんでもそういったAIとの協働があるんだ！」と大いに勇気づけられました。余談ですが、デモ中のベンチマークとして「マンデルブロ集合」が用いられていたのが勉強になりました。数値演算のループや再帰が非常に高密度に行われるため、インタプリタやコンパイラの最適化能力が如実に現れるのですね。これに感化され以前にバイブコーディングによりRubyで実装した純Lispで実際にマンデルブロ集合を描画して計測してみました。参考までにScheme実装のGaucheと比較した結果です。 Lisp(Scheme)で記述したマンデルブロ集合を描画するコード (define SCALE 1000000) (define quotient (lambda (a b) (if (< a 0) (- 0 (quotient (- 0 a) b)) (if (< a b) 0 (if (< a (+ b b)) 1 ((lambda (q) (+ (+ q q) (quotient (- a (* (+ q q) b)) b))) (quotient a (+ b b)))))))) (define fix* (lambda (a b) (quotient (* a b) SCALE))) (define mandelbrot-iter (lambda (cr ci zr zi count max-iter) ((lambda (zr2 zi2 zri) (if (>= (+ zr2 zi2) (* 4 SCALE)) count (if (>= count max-iter) count (mandelbrot-iter cr ci (+ (- zr2 zi2) cr) (+ (* 2 zri) ci) (+ count 1) max-iter)))) (fix* zr zr) (fix* zi zi) (fix* zr zi)))) (define mandelbrot (lambda (cr ci max-iter) (mandelbrot-iter cr ci 0 0 0 max-iter))) (define char-for-count (lambda (count max-iter) ((lambda (q3) (cond ((eq? count max-iter) (quote @)) ((> count (+ q3 q3)) (quote *)) ((> count q3) (quote +)) (else (quote -)))) (quotient max-iter 3)))) (define print-row (lambda (x y x-end step max-iter) (if (> x x-end) (newline) ((lambda (_) (print-row (+ x step) y x-end step max-iter)) (display (char-for-count (mandelbrot x y max-iter) max-iter)))))) (define render (lambda (y y-end x-start x-end step max-iter) (if (> y y-end) (quote done) ((lambda (_) (render (+ y step) y-end x-start x-end step max-iter)) (print-row x-start y x-end step max-iter))))) (render -1000000 1000000 -2000000 500000 50000 30) マンデルブロ集合の描画実行計測比較 # Gauche(Scheme)での実行結果 (0.166 total) ❯ time gosh examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- gosh examples/mandelbrot.lisp 0.11s user 0.01s system 75% cpu 0.166 total # Ruby(YJIT)で実装した自作Lispインタプリタでの実行結果 (6.797 total) ❯ time ruby --yjit bin/repl.rb examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- ruby --yjit bin/repl.rb examples/mandelbrot.lisp 6.54s user 0.08s system 97% cpu 6.797 total # Ruby(ZJIT)で実装した自作Lispインタプリタでの実行結果 (9.045 total) ❯ time ruby --zjit bin/repl.rb examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- ruby --zjit bin/repl.rb examples/mandelbrot.lisp 8.72s user 0.10s system 97% cpu 9.045 total JITを有効にして、実行環境のオーバーヘッドを可能な限り減らした状態での計測ですが、末尾再帰などの最適化は行なっていない素朴なLispインタプリタということもあり、圧倒的な速度差を目の当たりにし、コンパイラやインタプリタの最適化の重要性を肌で感じることができました。 RubyKaigi 2026 の思い出今回のRubyKaigiを通して強く感じたのは、「自分はRubyを『使う側』の人間なのだな」という事実です。正直なところ、どのトークも技術的な難易度が高く、「当たり前だけれど、自分の知識の範囲内でしか理解できない」というもどかしさを感じました。しかし、それは決してネガティブな感情ではなく、「何を知れば『Rubyを作る側の人間の話』が理解できるようになるんだろう？」という新たな好奇心の芽生えでもありました。立ち読み喫茶での出会いと、来年に向けた冒険「作る側の話」を理解するための第一歩として、弊社ブースの「立ち読み喫茶」で手に取ってみたり、ブースに訪れたRubyistにおすすめいただいたりした中から、来年のRubyKaigiまでに絶対に読むべき本を心に決めました。『CRuby Quest 〜Rubyのぼうけんのしょ〜』（自費出版 youchan 著） ParserからAST、ISeq、VMへと至るCRubyのレイヤーを素直に理解できそうだと感じて購入しました。ありがたいことに、著者のyouchanさんから直接サインをいただくことができました！『APIデザインケーススタディ』（技術評論社刊田中哲著）言語の中核となるAPI設計(Web APIじゃないよ)の考え方について、深く理解するための指針になると感じています。『白と黒のとびらオートマトンと形式言語をめぐる冒険』（東京大学出版会刊川添愛著）オートマトンの基礎を知ることで、言語の字句解析や構文解析の概念がよりクリアになることを期待して選びました。また、Rubyの内部仕様だけでなく、自身の発信力を高めるために『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』（翔泳社刊伊藤淳一著）も購入し、こちらもありがたいことに、いつも技術記事でお世話になっている伊藤淳一さんから直接サインをいただくことができました。これらの知識が「作る側」になるための武器や経験値になることを信じて日々精進していきます。大西晃平(@kOnsh) より RubyKaigi 2026 の思い出 Rubyが繋ぐ「人」の輪と、新たな一歩私はこれまでフロントエンド開発が中心だったので、RubyKaigiは初めての参加でした。その中で一番心に残ったのは技術そのもの以上にRubyという言語を中心としたコミュニティの圧倒的な「厚み」でした。会場には、名だたるエンジニアから、キャリアをスタートさせたばかりの方、さらには他の言語から飛び込んできた方まで、本当に幅広い層の人々が集まっていました。特に刺激的だったのは、SNSのアイコンでしか見たことのなかったエンジニアの方々と、セッションやDrinkupを通じて直接お話しできたことです。同じRubyistとして気さくにかつ情熱的に技術を語る姿を見て、「自分ももっと頑張ろう」と自然に気持ちが引き締まりました。今回のもう一つの大きな思い出は、技術書が購入できる本屋さんのサイン会です。先行販売していた『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』をその場で購入させていただきました。サインをいただき、著者と直接お話したことで、「まずは個人でも少しずつ、アウトプットを増やしていこう」という具体的な目標ができました。 Rubyはこうした個々の熱量が集まることで、エコシステムが大きくなっていると肌で感じました。自分にできることは小さいですが、今回の体験を経て「自分もこの素晴らしいエコシステムのために、何か少しでも貢献したい」という前向きな気持ちが芽生えています。山田(@amymd) よりトークで刺さったことや感想 Ruby Committers and the World(@rubylangorg) 私は今回のRubyKaigiが現地初参加でした。たくさんのトークがあってどれも面白かったのですが、特に印象に残ったのはRubyのコミッター陣によるトークセッションでした。毎年恒例のこのトークセッションでは、Rubyの開発プロセスやRubyの今後の展望についてコミッター陣でディスカッションするという貴重な機会となっており、今回初めて参加した私にとっては、Rubyの開発の裏側を垣間見ることができる非常に興味深いセッションでした。当日議論されたテーマとしては、 Integer#popcount or String#popcount Rubyの開発にconclave processを導入するのはどうか Ruby開発におけるAIの活用 setjmp/longjmp Revisiting frozen_string_literal などがありました。 Rubyの言語仕様に関する議論だけでなく、conclave process導入の話など開発プロセスに関する話もあり、長く続く開発コミュニティならではの議論が聞けてとても面白かったです。また、他のトークでもAI活用の話は多く出ていましたが、Ruby自体の開発でも当たり前にAIが活用されているという話も印象に残っています。会場でどのくらいコードをAIに書かせているのか挙手で聞いてみると、「半分以上書かせている」でほとんどの人が挙手していて、多くのRubyistがAIを活用していることに改めて驚きました。コードを書かせるだけでなく、不具合の調査やエッジケースの洗い出しなどでもAIを活用していて便利だという話があり、まさに私自身もAIにテストコードを書かせることが多くその便利さを実感していたので、非常に共感しました。 AIの登場によってOSS開発への参加のハードルが下がったという話もあり、この後のMatzさんのKeynoteでも話に出てきましたが、これまでやりたくても時間やリソースの関係でできなかったことが、AIの活用によって誰でも実現できる世の中になってきたのだと改めて感じました。そういった中でエンジニアとしてどのようにAIと向き合い、活用していくのか。このテーマは今後もますます注目されていくのだろうなと思います。気が早いですが、来年のRubyKaigiのセッションも楽しみです。 RubyKaigi 2026 の思い出セッションやブース担当以外の時間はスポンサーブースを回ったり、他の参加者の方と交流したりしていました。各社いろんな工夫を凝らしたブース展示をしていて回っているだけでも楽しいですし、異なる業界のプロダクトの話が聞けるのもいつもとは違う刺激があって面白かったです。 ANDPADのロゴ入りTシャツを着て回っていたこともあって、弊社が提供していたローカルフードの話や前回のRubyKaigiでの弊社ブースの話を振っていただくことも多かったです。RubyKaigiは毎年参加している方も多いので、そういった話ができるのも例年開催しているイベントならではの特徴だなと感じました。弊社ブースの「立ち読み喫茶」も運営として参加させていただきましたが、ブースを訪れた方に逆におすすめの本を教えていただいたりと、楽しい時間を過ごすことができました。私は「データモデリングでドメインを駆動する」（技術評論社刊）という本を推薦しました。基幹系システムの中核にある「帳簿」のデザインの重要性やそのためのデータモデリングの考え方に関する本です。社内で輪読会を実施したところ非常に好評で、基幹系システムの開発に携わる人には特におすすめです。小倉(@Ogura) よりトークで刺さったことや感想 Ruby はこれまで、YARV、MJIT、YJIT と着実にパフォーマンス面での進化を続けてきました。そして去年の RubyKaigi で、YJIT のさらに上を目指す ZJIT が発表されて以来、現在どのような状況にあるのか強い関心を持っていました。今回の RubyKaigi では、ZJIT については以下の2つのセッションがありました。 The design and implementation of ZJIT & the next five years (@tekknolagi) Lightning-Fast Method Calls with Ruby 4.1 ZJIT (@k0kubun) セッションを聞いていて特に印象に残ったのは、「最適化と実用性のバランス」についてです。高度な最適化を行うと、例外発生時にスタックトレースを正しく生成するための情報が不足してしまう問題があるそうです。そのため、状況に応じて Deoptimization が必要になるとの解説がありました。最適化を突き

Ruby
RubyKaigi

ANDPAD·2026/06/03

【RubyKaigi 2026】採用担当が振り返るアンドパッドブースの3日間

こんにちは！開発本部組織開発部で、エンジニア採用・育成を担当している磯崎と中野です。アンドパッドがRubyスポンサーとして参加した「RubyKaigi 2026」。今回は、初参加で現地を全力で駆け抜けた磯崎のレポートと、5回目の参加となるマネージャー中野の視点の2つの軸で、熱気あふれる3日間の様子をお届けします。まずは、大盛況だった現地のブースの様子から振り返ります！はじめに開発本部組織開発部で、エンジニア採用・育成を担当している磯崎です。私は普段、開発本部付の人事として、日々素晴らしいエンジニアの方々と出会うべく採用活動に奮闘しています。そんな中、今回はエンジニア採用活動の重要な一環として、北海道・函館で開催された「RubyKaigi 2026」に参加してきました！ RubyKaigiは、エンジニアの皆さんが技術の深い議論に熱狂する特別な場です。今回、私たちアンドパッドもスポンサーとしてブースを出展しました。私自身もブースに立ち、全国から集まった多くのRubyistの皆さんと直接お話しさせていただきました。「現場でどんな技術が使われているの？」「アンドパッドの開発文化って実際どうなの？」といった生の声に触れながら、少しでも多くの方にアンドパッドという会社、そして私たちのプロダクトの面白さを知っていただく「機会の創出」に一役買いたい！そんな熱い想いを胸に駆け抜けた3日間をレポートします。 23名のメンバーで盛り上げた、アンドパッドブース今回、アンドパッドは「Ruby Sponsor」としてRubyKaigi 2026を協賛させていただきました。現地に駆けつけたメンバーは、エンジニア16名、広報・採用担当7名の計23名という、弊社としてもかなり大規模な布陣です！技術カンファレンスであるRubyKaigiに、なぜ私たち人事や広報といった非エンジニアのメンバーがこれほど多く参加したのか。それは、アンドパッドの魅力をエンジニアの視点だけでなく、組織やカルチャーを支える非エンジニアの多角的な目線からも発信したいという強い想いがあったからです。当日のブースでは、事前にお知らせしていた通り「技術への深い関心」と「ホスピタリティ」の両面からアプローチを試みました。 📘 エンジニアによる「立ち読み喫茶」アンドパッドのエンジニアたちが厳選した技術書をずらりと並べ、その場で自由に読みながら交流できるスペースを提供しました。単なる一方的な会社説明の場にするのではなく、本をきっかけに「この技術、実務ではどう使ってる？」「うちのチームだとこう工夫していて……」といったディープな技術談義が至る所で発生！技術へのリスペクトと探究心にあふれる、まさにRubyKaigiらしい熱気あふれる光景が広がっていました。 ☕ 広報・採用担当による「おもてなしコーナー」私たち広報・採用チームは、ランチ（お弁当）の配布や函館のご当地ドリンク、そしてアンケートコーナーを担当しました。開催期間中の函館は少し冷える風が吹いていましたが、ブースに立ち寄ってくださった皆さんにホッと一息ついていただけるよう、笑顔と温かいおもてなしで運営。アンケートコーナーにも多くの方に足を止めていただき、アンドパッドに対するリアルで貴重なフィードバックを直接伺うことができました。 🤝 過去と現在が繋がった、印象的なエピソード 3日間ブースに立った中で、特に心に残っているエピソードがあります。ブースを訪れてくださった方の中に、現在アンドパッドで活躍している社員と、前職で一緒に働かれていたという方がいらっしゃいました。その方から「今のアンドパッドってどんな事業に挑戦しているの？」「実際の技術スタックはどうなっているの？」と、非常に熱心にご質問をいただく場面がありました。そこから会話が弾み、現在の私たちの開発体制や、これから目指していく組織のビジョンについてディープにお話しする中で、さらに新しい交流へと発展していきました。単に「懐かしい再会」や「情報交換」に留まらず、最終的には「アンドパッドの選考フローがどうなっているのか」という具体的なステップにまで興味を持ってご確認いただくことができました。最先端の技術を追う場所であると同時に、「過去の繋がりや、人と人とのコミュニティの交流の大切さ」を肌で感じられたことは、カンファレンスならではの忘れられない瞬間です。それと同時に、私たちのミッションである「アンドパッドの仲間を増やしていく」という究極の目的に一歩近づくような、採用担当としてこれ以上ないほど手応えのある、素晴らしい交流を生み出すことができました。 🚀 全てのコンテンツが大盛況！現場で感じた「アンドパッドらしさ」おかげさまで、どのコーナーも3日間を通して大盛況のまま終了することができました！「アンドパッドのTechBlog、いつも読んでます！」「エンジニアの皆さんとこんなに深く技術の話ができると思わなかった」といった温かい声を直接いただけたことは、採用担当としてこれ以上ない喜びでした。今回、23名という大所帯のメンバーが職種や役割の垣根を越えて連携し、来場者の皆さんに「最高の体験」を提供しようと奮闘する姿は、まさに弊社のバリューである Professional を体現していました。エンジニアが技術の楽しさと奥深さを全力で伝え、私たちが人事・広報としてその環境や文化をサポートする。この両輪が揃ってこそ、アンドパッドという組織の魅力が真っ直ぐに社外へ伝わるのだと確信した、本当に濃密で素晴らしい3日間でした。【番外編】函館の食と景色を満喫！今回のRubyKaigiは、歴史情緒あふれる函館での開催でした。ブース運営の合間には、函館ならではの景色や食に触れ、チームメンバー同士の親睦を深める貴重な時間となりました。満開の桜と五稜郭：ちょうど見頃を迎えた五稜郭公園。満開の桜の下で、リフレッシュすることができました。函館の味覚：ジンギスカンや海鮮など、地元の食を囲んでエンジニアと採用チームの連携をより強めることができたと感じています。こうしたオフラインならではの体験が、最終日のブース運営まで走り抜けるエネルギーに繋がりました！アンドパッドとRuby、これまでの歩みとこれからここからは、採用・育成チームでマネージャーをしている中野がお送りします。磯崎のレポートにもあった通り、今回のRubyKaigi 2026はメンバー全員が職種の垣根を超えて一丸となり、本当にいいブース展開ができたなと感じています。私自身は、今回で5回目の参加でした。毎年思うことですが、あの独特のあたたかい空気感と、会場全体に満ちている「技術へのワクワク感」は、何度来ても心地いいですね。この空間に一緒にいられることが、純粋に嬉しいなと感じる時間でした。言葉で説明できない「あの感じ」を共有したくて今回は、初参加の人事メンバーも連れていきました。普段、社内で「Rubyコミュニティはすごいんだよ」といくら言葉で説明しても、あの現地の熱気だけは伝わりきらないんですよね。実際に足を運んでみて、「あ、こういうことか！」という発見や、参加する楽しさを少しでも感じてくれていたら嬉しいです。それにしても、RubyKaigiって本当に不思議な場だなと思います。私のような非エンジニアに対しても、Matzさんや松田さんがラフに話しかけてくださったりして。そんな懐の深さに触れるたび、「自分たちもこのコミュニティの一員なんだな」と実感できて、すごくありがたいなと思います。この素晴らしいコミュニティが続くよう、アンドパッドとしても支援していきたいし、私たちが企業として成長していくこと自体が、コミュニティへの一番の恩返しになるのかもしれないといつも思っています。 2019年から続く、アンドパッドとRubyコミュニティのつながり今回アンドパッドが「Rubyスポンサー（※ 広瀬のブログにある通り、気合を入れて様々な企画を準備しました！）」を務めている背景には、実はちょっとした思い入れがあります。きっかけは2019年に初めてスポンサーをした時まで遡ります。当時は社名もロゴも今とは違っていて、まさにこれから組織を大きくしていくぞ！というタイミングでした。あの時、RubyKaigiを通じてたくさんの素晴らしいエンジニアと出会えたことが、今の私たちの成長に繋がっています。あれから、お陰様でリリース10周年を迎え、ARRも100億円を突破しました。この成長を支えてくれたRubyやコミュニティに対して、今度は私たちがスポンサーという形で盛り上げるお手伝いができるのは、とても感慨深いです。もちろん、私たちの挑戦はまだまだ続きます。「幸せを築く人を、幸せに。」このミッションの下、ARR300億円というさらに大きな目標に向けて、AI活用も含めてやりたいことは山積みです。そのためには、もっともっと新しい仲間が必要です。このRubyKaigi 2026での色々な出会いが、次の10年を一緒に歩むきっかけになればいいな、と願っています。次は、宮崎で！色々な出会いに感謝、そして今回しか味わえない最高のカンファレンスに参加させてくれた会社にもありがとう、ですね。来年の宮崎でも、また胸を張って皆さんとお会いできるよう、明日からまたエンジニアが活躍できる環境づくりを頑張っていきます。おわりに「幸せを築く人を、幸せに。」このミッションを支える技術の力を信じて、これからもアンドパッドの魅力を発信し続けていきたいと思います。今回の記事で少しでもアンドパッドに興味を持っていただけたなら、ぜひカジュアルにお話ししましょう！函館の思い出話から、私たちが目指す組織の話まで、皆さんからのご連絡をお待ちしています。 ▼ アンドパッドでは、一緒に働く仲間を募集しています！カジュアル面談はこちら採用情報・求人一覧

Ruby
採用
技術広報

ANDPAD·2026/05/27

清聴御礼! RubyKaigi 2026 でアンドパッドから 4 名登壇 + 1 名司会 + 1 名スポンサーセッションを行いました

こんにちは、採用広報の id:sezemi です。 RubyKaigi 2026 が終わって、はや 1 か月、興奮冷めやらぬまま、次は地域 Ruby 会議がやってきますね。アンドパッドは 6/6 開催の松江 Ruby 会議12 に協賛しており、当日はブースも出展しますので、また Rubyist の皆さんに会えることを、とても楽しみにしています！さて、その RubyKaigi 2026 ではアンドパッドから合計 6 名が登壇しました。この記事では、登壇の裏話、補足、思い出などなどを登壇者に語ってもらいました。なお、登壇者の一人 hsbt は別エントリで記事を出しますので、ぜひそちらもご覧ください。 Hasumikin 話したこと・伝えきれなかったこと PicoRubyをWASMビルドしたPicoRuby.wasmと、その上につくったFunicularというブラウザアプリフレームワークの話をしました。最近なぜかPicoRubyのトークをする人が増えたので、ハードウェアのトピックは彼等に任せ、わたしはちょっと趣向を変えてみようと思った、というわけです。なのですが、どうにもガマンしきれずに、「PicoRubyで動くキーボードにWebSocketサーバを建て、ブラウザのPicoRuby.wasmクライアントとdRubyで通信してLEDを光らせる」といういつものマイコン芸人仕草を30分のトークに詰め込んでしまいました。ですからFunicularの詳しい話はあまりできませんでした。この続きは、ことしのKaigi on Rails 2026でお届けします（プロポーザルが通ったら）。よろしくお願いします。 hasumi の登壇の模様 by hsbt 発表で大変だったこと初日の午前中の発表だったため、プレッシャーからあっというまに解放されました。まことにありがたいことです。 Funicular: A Browser App Framework Powered by PicoRuby.WASM RubyKaigi 2026 の思い出やんちゃハウスという宿泊イベント（？）を利用しました。Kaigi会場至近だし1階にラーメンバーがあるし、道路を渡れば日帰り温泉があり、完璧な宿泊体験でした。 Kaigi後にはレンタカーに乗って、小樽や余市や支笏湖やディープな温泉を旅しました。小樽ではぬかるみで滑って転んでiPhoneを壊してしまいましたので、急遽札幌の電器店へ行き、新しいiPhoneを購入しました。同道のポーランド人は、このトラブルに乗じてポケモンセンターサッポロへ寄ることができて大満足な様子でした。 Youchan 話したこと・伝えきれなかったこと「Guide to getting started walking source codes of CRuby」というタイトルでCRubyのソースコードを読むためのTipsを紹介しました。 CRubyに限らないジェネリックなソースコードの読み方からCRubyに特有のことなどをなるべく実際のソースコードを参照しながら解説しました。また、AIを活用してソースコードを読むという方法も紹介しました。 CRubyの内部に関しては伝えたいことが沢山ありましたが、本トークではなるべく読み方にフォーカスして話しました。伝えられなかったことは、同人誌として執筆した「CRuby Quest ～Rubyのぼうけんのしょ～」に書いたのでRubyKaigiの会場で購入されたかたはそちらも参考にしてほしいです。 youchan の登壇の模様 by hsbt 発表で大変だったこと発表自体よりも前述の同人誌の執筆が大変でした。発表は同人誌の執筆による副産物のようなものでしたが、苦労して本を書いたのでトークの内容も自信を持って話せるものになったと思います。 Guide to getting started walking source codes of CRuby 左右キー(← →)でページ送りできます RubyKaigi 2026 の思い出自分のトークの後は休み時間はだいたい本屋さんにいて、ずっとサインをしていたように思います。売れっ子の作家になった気分で楽しかったです。あとはコード懇親会でPicoPicoRuby(コミュニティ)のみなさんとワイワイできたのがよかったです。 Day 2 で bento プレゼンターをした様子 nagachika 話したこと・伝えきれなかったこと「Pure Intonation on Browser: Building a Sequencer with Ruby」というタイトルで ruby.wasm と Web Audio API を利用してブラウザ上で動作するシンセサイザー/シーケンサーを開発した話をしました。最近の RubyKaigi で音声まわりに関する発表が多かったことに触発されて以前からやりたかったシンセサイザー開発+最近興味を持った音楽理論の実現をやってみたというものです。ruby.wasm については ledsun さんのセッションも類似のテーマとなりそうだったのでトークの半分くらいは元にした音楽理論についての話に割くという RubyKaigi っぽくない内容になって個人的には良かったかと思います。開発しているシーケンサーはさらに MIDI コントロールも可能にしていて、専用の MIDI コントローラーをこれまたブラウザで動かすものを開発しています。これについては松江Ruby会議12で発表させていただく予定です。 nagachika の登壇の様子 by hsbt 発表で大変だったこと大きなカンファレンスでのトークはとても久し振りだったこともあり、資料の発表者ノートも入念に書き上げ(RubyKaigi では日→英の同時通訳が行なわれ、日本語での発表者は翻訳者の方に事前に資料を提供する必要があるのでそのためという側面もあります)練習もしていました。本番では逆にそれにひきずられて台本を読み上げることに集中してしまって普段通りのトークができなかったなという反省があります。次の機会ではもうすこしリラックスして発表できるようにしたいです。 RubyKaigi 2026 の思い出アンドパッドのランチ提供の3日目のやきとり弁当を手渡す係をやらせていただいたのですが、大量のお弁当が次々と配られていくのを目の当たりにして不思議な充実感を覚えました。なんというか人間には食事を提供して人々の腹を満たすということに快感を覚える本能があるのではないでしょうか。また会期後の Day 4 には函館市電に乗って LT 大会をするというイベントに参加して紙芝居形式の LT をするというはじめての経験もしました。他の方の LT もユニークなものばかりで楽しかったです。 Leo 話したこと・伝えきれなかったこと RubyKaigiの定番企画「Ruby Committers and the World」の司会を務めさせていただきました。RubyKaigiに参加しているRubyコミッター全員をステージに集めて、観客の前でRuby開発者会議を開催し、ワイワイと楽しく議論していただくことがコンセプトです。トピックは事前にコミッターたちから集めて、いい感じに議論できるように選定しました。今年は特にRubyの開発におけるAI活用の話が盛り上がりました。去年の同セッションでAIの活用のトピックもありましたが、懐疑的な意見が多かった。一方、今年はRuby開発で本格的に使っているコミッターが目立っていました。中でも、Matzが他のコミッターよりも積極的に活用していたのは驚きでしたが、同日のMatzキーノートで「これまでヒューマンインテリジェンス(コミッタの方々)に頼んでいたことが、AIに頼むようになっただけ」と語っていて、なるほどと納得しました。発表で大変だったことこのセッションの司会になったのは、RubyKaigi 2024直前にRuby Committers SponsorのShopify Engineeringに声を掛けて頂いたことがきっかけでした。毎回、トピックの選定が難しいです。トピックはShopify所属のRubyコミッターと相談しながら選定しますが、普段意識しないレイヤーの話題が多くて、トピックの下調べが必要です。トピックの背景を理解するために、Ruby開発者会議の議事録やRuby本体のRedmineイシューを漁って予習をしました。きゃー、 Leo さーん #rubykaigi pic.twitter.com/QO6fKDJ59q— ANDPAD (アンドパッド)開発部 (@andpad_dev) April 24, 2026 RubyKaigi 2026 の思い出 RubyKaigiの初回開催は2006年でした。数え方によっては、RubyKaigi 2026は20回目の開催となります。そういう背景もあり、2日目のheadius氏のKeynot「Twenty Years of JRuby」が印象に残りました。20年の積み重ねは偉大！ kei-s 話したこと・伝えきれなかったこと 3日目の Matz キーノート直前に、アンドパッドとしてのスポンサーLTに登壇しました。今回の発表では、「帰り道に建設現場を見たら、その現場を動かす Ruby のことを思い出してほしい」というメッセージを軸に、アンドパッドの現在と未来をお話ししました。今年3月にサービス開始10周年を迎え、ARR100億円を突破して次なる300億円へ挑む私たちのプロダクトを支えているのは、まぎれもなくRubyの力です。今年は4名のスピーカー登壇に加え、セッションの司会、ブース出展、ランチやドリンクの提供、そして総勢23名の参加とアンドパッドの存在感が高かったので、それを最後に聴衆の印象に残せるよう目指しました。 kei-s の登壇の様子 by hsbt 発表で大変だったこと「3分」というタイトな尺の中に、どうやって伝えたい内容を込めるかというタイムマネジメントに注力しました。全体の構成や大枠自体は会期前に完成していたのですが、函館の名の由来が室町時代の「館（建物）」にあることや、初日のキーノートで語られた「Box Building」の文脈など、現地で得たトピックをどうしても盛り込みたくなり、会期中に急遽内容をアップデートしたのです。限られた時間の中で、追加したストーリーとビジネス・組織のファクトを綺麗に繋ぎ、かつ3分ピシャリに収めるための推敲とトーク練習は、登壇直前のギリギリまで繰り返し行いました。現地での熱量を生で取り込んだからこそ、ライブ感のある最高のアピールができたと思っています。 RubyKaigi 2026 の思い出アンドパッドが提供したランチは非常に人気で行列ができたのですが、列形成が少しスムーズにいっていないのを見て、勝手に責任を感じて当日スタッフのように列の整理を手伝ったりしていました。また、2日目夜に開催したアンドパッド主催のコード懇親会には、実はこれといった役割を決めずにぶらっと参加していました。しかし会場に着くと、気がつけば雑務をこなしたり、参加者の皆さんに積極的に声をかけて、お互いにまだ知らない隣の人同士を繋げたりしていました。それが、個人的にとても楽しかったです。まとめアンドパッドの Speaker の面々、 5 名に発表のふりかえりと舞台裏などを語ってもらいました！ Ruby のコアなところからブラウザアプリケーション、そして多くの反響を生んだ Ruby Committers and the World での司会進行、そして建設現場の話まで、アンドパッドからの幅広い発表をご清聴いただき、ありがとうございました。これからも Kaigi on Rails や地域 Ruby 会議などでの今後の発表をお見逃しなく！そして、建設現場をみてアンドパッドを思い出した方はぜひお話しましょう！カジュアル面談やポジションへのご応募お待ちしております。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fhrmos.co%2Fpages%2Fandpad%

Ruby

ANDPAD·2026/05/26

RubyKaigi 2026 アンドパッドブースで実施したアンケート結果から見える Ruby コミュニティの現在地

こんにちは、Ruby コミッタの柴田 (hsbt) です。最近はプレイするゲームに NTE を追加してしまい、いよいよ早起きする時間を30分繰り上げないとプレイしているゲーム全てのデイリークエの消化が追いつかなくなってきました。先日の RubyKaigi 2026 では、例年通りアンドパッドはスポンサーとしてブースを出展し、ご当地ランチやドリンクを提供しました。たくさんの方から「これが食べたかった」という声を聞いて、選んだ当事者としては大満足です。今回のアンドパッドのブースでは、参加者の皆さんに普段の Ruby 開発環境について 7 つの質問に答えていただくアンケートを実施しました。この記事では、その結果を順番に紹介しながら、Rubyist の現在地と、Ruby と Ruby のエコシステムのメンテナとして私見をあわせてお伝えします。なお、Q1 と Q2 は単一回答ですが、Q3 以降は複数回答可の設問になっています。ユニークな回答者数は 350〜400 名前後ですが、グラフの棒の長さは「その選択肢を採用している人の絶対数」を表しており、「シェア」ではないことに注意して読んでいただければと思います。 RubyKaigi はその性質上、回答者は日本を中心としつつ、来日した Rubyist も多く含まれます。グローバルな Stack Overflow Developer Survey などとは母集団が大きく違うので、「Ruby を現役で書いている、カンファレンスに足を運ぶようなアクティブな開発者」のスナップショットとして読んでいただくのが良いかなと思います。 Q1. Ruby の使用歴は何年ですか？ 1 問目は Ruby 歴です。回答の分布はおおよそ以下の通りでした。 0 年〜2 年: 約 115 3 年〜5 年: 約 95 6 年〜9 年: 約 65 10 年以上: 約 100 「0 年〜2 年」が最多で、「10 年以上」がほぼ同数で続く U 字型の分布になりました。Ruby は登場から 30 年を超えた言語ですが、新しく Ruby を書き始めた層と、長年メインで使ってきた層が両方厚いというのは、コミュニティの世代交代と継続性が両立しているサインだと受け止めています。世界的にも、AI coding を活用して少人数チームでも「もう一度 Rails で作ってみよう」という機運が高まっている一方で Shopify や GitHub のような大規模事例も継続的にアップデートされています。ブースに来ていただいた方からも「最近 Ruby を書き始めました」という声を聞く機会が増えてきたのと、このアンケート結果の手触りは一致しています。 Q2. 業務プロジェクトのメインとなる Ruby のバージョンは何ですか？業務で使用している Ruby のバージョンについての結果は以下の通りです。 Ruby 3.2 以前: 約 60 Ruby 3.3: 約 50 Ruby 3.4: 約 145 Ruby 4.0 (Stable): 約 140 Ruby 4.1 以上 (master/dev): 約 15 私が一番驚いたのはこの結果です。Ruby 4.0 は 2025 年 12 月 25 日にリリースされたばかりですが、半年も経たないうちに業務プロジェクトのメインバージョンとして Ruby 3.4 と肩を並べる規模になっています。Ruby 4.0 はメジャーバージョンアップながら互換性を強く意識して設計されており、3.x からの移行コストが小さいことを開発チームとして意識してきました。各種 Gem の対応も急速に整い、CI で 4.0 を主要バージョンに切り替えるプロジェクトが増えているのは、その設計判断が報われた結果だと感じています。 3.3 以前を引き続き使っている層がそれなりにいる点も、長期運用しているサービスの実情として現実的な数字です。3.2 系はすでにEOL、3.3 系も 2026 年 3 月で通常メンテナンスを終了しているので、セキュリティメンテナンス期間のうちに 3.4 系か 4.0 系へのアップデートを計画していただきたいところです。アップデートの障壁になっている点があればメンテナとしてフィードバックは歓迎します。 Q3. 業務でメインに使用しているエディタは何ですか？エディタの回答分布は以下の通りです (複数回答可)。 VS Code: 約 200 Cursor: 約 110 Neovim / Vim: 約 70 RubyMine: 約 45 Zed: 約 15 Emacs: 約 10 Sublime / Cmux / Antigravity / Helix: 各数件その他: 約 10 ここから複数回答可能な設問です。そのため、「業務で使っているエディタを複数選んだ」結果と読むのが妥当です。VS Code 利用者の一定数が Cursor も併用していたり、Neovim / Vim を日常使いつつ補完目的で VS Code も入れている、といった重なりが含まれているとして、それでも VS Code が約 200 名で圧倒的トップ、Cursor が約 110 名で 2 位という勢力図は明確です。世界的にも JetBrains の State of Developer Ecosystem や Stack Overflow Developer Survey で VS Code は数年来トップですが、それに加えて Cursor や Zed などの増加を見ると、LSP (ruby-lsp )やAI アシスト機能の質で決まるフェーズに入ったことが、この結果に表れています。 Q4. 業務に導入・活用しているコーディングエージェントは何ですか？ここは今回のアンケートの中で最も結果が偏った質問でした (複数回答可)。 Claude Code: 約 325 GitHub Copilot (Chat / Autocomplete): 約 85 GitHub Copilot Workspace: 約 55 Codex: 約 25 会社規定により使用不可・使用していない: 約 10 Devin: 約 10 Amazon Q Developer / Cline / Roo Code / Gemini / その他: 各数件注目すべきは、Claude Code が約 325 名で、回答者全体の 8〜9 割を占めている点です。「Coding Agent を使っているなら、その中に Claude Code が含まれている確率がきわめて高い」という事実が示されており、Ruby 開発者のあいだで Claude Code が事実上の標準採用になっていると言えます。「会社規定により使用不可・使用していない」が一定数あるのは現実問題として重要なポイントです。コードや顧客データを LLM に送信する経路の整理、ベンダーロックインの懸念、契約上の取り扱いなど、企業として整理すべき論点はまだ多く残っています。こうした「ツールを使えるようにする側」の地道な仕事も含めて、これからの開発組織の競争力に直結する領域だと感じています。 Q5. Coding Agent を使って何を作っていますか？ Coding Agent の用途の分布は以下の通りです (複数回答可)。業務のプロダクト: 約 320 趣味のソフトウェア: 約 165 業務の間接ツール: 約 160 プロダクトで使っている OSS: 約 50 その他 OSS 全般: 約 35 その他: 約 5 合計票数は約 735 と 1 人あたり平均 2 つの用途で Coding Agent を活用していることが分かります。「業務のプロダクト」が約 320 名で回答者のほぼ全員が業務プロダクトに Coding Agent を導入しているのは予想通りですが、特に注目したいのは「趣味のソフトウェア」と「業務の間接ツール」がそれぞれ 160 名前後と、業務プロダクトの半分の規模で並んでいる点です。私自身、Ruby の周辺ツール (all-ruby) やリリース/パッケージングスクリプトなどのメンテナンスを Claude Code に任せられるようになってから、自分の手で書く量は減ったのに進められる仕事は増えるという状態になっています。「プロダクトで使っている OSS」(50) と「その他 OSS 全般」(35) を合わせると、85 名前後が OSS の改善にも Coding Agent を活用していると回答しています。重複を考慮しても、回答者の 2 割程度が OSS のメンテナンスに Coding Agent を持ち込んでいる計算で、これは昨年なら考えにくかった結果です。Ruby の OSS エコシステムにとっても、Coding Agent はメンテナの負荷を下げる方向に作用していくはずで、私自身も RubyGems や Bundler のメンテナンスでその効果を実感しています。 Q6. プロジェクトのパッケージ・バージョン管理には何を使用していますか？ Ruby とその関連ツールのバージョン管理の分布は以下の通りです (複数回答可)。 rbenv など Ruby 専用のツール: 約 200 mise / asdf: 約 145 Homebrew (Project local): 約 140 Dev Containers: 約 60 Nix 系のツール (nix / devbox など): 約 5 その他: 約 10 私もメンテナの一人である rbenv 系を選んだ人が依然として最大の勢力ですが、mise / asdf のような汎用バージョンマネージャもそれに迫る規模に育っています。Node.js や Python、Go など複数言語を行き来する開発が当たり前になってきた今、「言語ごとに専用のバージョンマネージャを入れる」アプローチから「一つのツールで全部を管理する」アプローチへの移行が Ruby コミュニティでも確実に進んでおり、rbenv ユーザーの一部が mise への併用・移行を始めている過渡期と読むこともできそうです。 Homebrew (Project local) が mise などと同じ数なのは Docker やリモート開発環境で業務プロジェクトごとの Ruby を実行している人が増え、「ローカルマシン上で複数バージョンを切り替える必要がそもそも無くなった」結果ではないかと推測しています。 Q7. 業務プロジェクトのローカル実行環境はどう構築していますか？ローカル実行環境の分布は以下の通りです (複数回答可)。 Docker Compose: 約 295 Native (macOS / Linux): 約 65 Lima / Colima: 約 35 OrbStack: 約 30 Kamal (Local Runner): 約 5 Codespaces / Cloud IDE: 約 5 Podman Desktop: 約 5 その他: 約 5 Docker Compose を選んだ人は約 295 名で、回答者の 8 割近くが日常的に Docker Compose を立ち上げている計算になります。Rails アプリケーションの開発では、Web サーバ・データベース・Redis・ジョブキューなどを Docker Compose でまとめて立ち上げるのが事実上の標準形になっているようです。今回の結果では Lima / Colima が 35、OrbStack が 30 と拮抗しています。Apple Silicon 上での Linux コンテナの動作については、macOS 26 で導入された Apple 公式の container コマンドがどう普及してくるかも個人的には気になっています。Native (macOS / Linux) が 65 と一定数あるのは、Ruby / PostgreSQL / Redis などは macOS や Linux 上でそのまま動かすことができ、コンテナ経由よりもネイティブ実行の方が単純に速いから、というのが推測です。私もこの方法で開発することが多いです。アンケート結果から見えてくる Ruby コミュニティの現在地 7 つの質問の結果を通して見えてくるのは、Ruby コミュニティが「成熟しつつも、ツーリングの面では非常に動的なフェーズにある」という姿です。 Ruby 4.0 への移行が予想以上に早く進んでいること、エディタは VS Code / Cursor のような AI 連携の強いものに集約されていること、Coding Agent は Claude Code が突出していること、バージョン管理は rbenv 一強から mise / asdf へ

Ruby
Docker
生成AI

ANDPAD·2026/05/22

Security-JAWS【第41回】〜Day1〜でAWS WAFの運用について発表しました！

こんにちは！アンドパッドセキュリティグループの宜野座(ぎのざ)です。 2026/05/16(土)に開催された Security-JAWS【第41回】〜Day1〜にて登壇の機会をいただき、私のセッションでは「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表をしました。今回はCfPを出した背景やセッションでお話しした内容の補足、興味深かったセッションの内容をご紹介します。 Security-JAWS にこれから現地参加したい、CfPを出してみたいと考えている方にも参考になると何よりです。 Security-JAWS についてなぜCfPを出したのか CfP採択後の準備セッションの内容についてセッションでは話せなかったこと AWS WAFの新規作成 AWS WAF ルールのPriorityの順番 AWS WAFの更新作業が属人化してしまう興味深かったセッション Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか Security-JAWS 全体を通しての感想 We are actively hiring! Security-JAWS について AWS を利用している人なら知っている有名なイベントですが、念のため紹介すると、AWSを利用する上で非常に重要な要素であるセキュリティの活用を共有して、より安全にAWSを利用することを目的として、立ち上がったイベントです。詳しくは connpassページをご参照ください。 s-jaws.connpass.com そして今回は10周年イベントということで、改めて10周年おめでとうございます 🎉🎉 登壇者の記念Tシャツもいただきましたので、大切にします！なぜCfPを出したのか AWSに関わる大きなイベントでもいつか発表してみたいとは思っていたのですが、なかなか挑戦できずにいました。そんな中 3月に Security.any というイベントでも登壇の機会をいただき、せっかくの機会なので他のイベントにもチャレンジしてみようと思ったのが最初のきっかけでした。そして以前から AWS x Security といえば Security-JAWS というくらい多くの方が参加するイベントだと知っており、10周年のイベントには元々参加しようと思っていたのですが、もしかすると1年くらいかけて取り組んでいたAWS WAFの取り組みが発表できるのではないかと考え、CfPの提出に挑戦してみました。 CfP採択後の準備 4月にCfPの採択のご連絡をいただいて本格的に準備を開始し、CfPに提出していた登壇概要の情報からどのような内容を伝えられると参考になるだろうと1年余りの取り組みを改めて振り返りながらスライド作りに取り組みました。スライドのデザイン統一・全体構成についての意見・分量が適切かというところではAIにも意見を貰いながら、4日前から時間を測った練習を何度か実施し、時間を大幅にオーバーしていたのでスライドを削ったり全体の時間の調整を行なうという流れで準備を進めていました。ここまでの個人的な準備に加えて、社内でもチームの方を中心にたくさんレビューいただいて、無事発表に間に合わせることができました。セッションの内容について今回は1番最初のセッションの枠をいただきまして、「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表しました。 speakerdeck.com 準備に少し手間取ってしまい皆さまに申し訳なかったですが、会場が温かい雰囲気だったため、そこまで緊張せずに話せてよかったです。またいくつか参考になったというコメントをXでもいただき、非常に嬉しかったです。セッションでは話せなかったことセッションの時間は非常に限られていたので、課題を4つに絞っていました。そのため細かな課題はスキップしていたので、ここで一部共有したいと思います！ AWS WAFの新規作成 AWS WAFの新規作成を簡単に行えないというところも課題としてありました。主に以下が課題の要因だったと考えています。 AWS WAFに設定するべき、マネージドルールがわからない新規作成の時に必要な手順がわからないまずは1つ目の課題を解消するために、設定を必須とするマネージドルールのポリシーを定めていきました。現在AWSが提供している全てのマネージドルールを確認し、未導入のものは有効性を検証の上追加したり、すでに導入されているものでも必須ではないものを除外したりという選定を行いました。続いて2つ目の課題を解消するために、1つ目の課題解消で決めたポリシーを元にGitHubにてTemplateディレクトリを作成しました。そしてREADMEに新規作成の手順を追加し、現在はWAFの作成依頼に対して数時間程度で対応可能となりました。(元々既存ルールの調査やコードの修正、申請などで数日かかっていました。) AWS WAF ルールのPriorityの順番ルールはPriorityの値が小さい順に評価されますが、整理を始める前は独自 allowルール、独自 blockルール、AWSマネージドルールが様々なPriorityで設定されているという課題がありました。そのためどのようにリクエストが評価されるかの確認がしにくかったり、追加箇所で悩むことがありました。こちらの課題を解決するために、以下のようなルールを設けることにしました。 allowルール: Priority 0 - 49 block ルール: Priority 50 - 99 AWSマネージドルール: Priority 100 以降で設定 AWS WAFの更新作業が属人化してしまうコード化を終えたタイミングでAWS WAFマネージドルールのバージョン最新化に取り組んでいましたが、最初のうちは個人でアップグレードの対応が行われており、属人化が課題となっていました。しかし、その後更新手順を整備したタイミング(登壇でお話しした内容)で、チームで担当者をアサインする体制に移行したことで現在はチームで分担しながら実施する運用とすることが出来ました。コード化をしていたことで非常にスムーズにチームでの運用へ移管することができたと思います。興味深かったセッション今回のセッションは全部で11セッションありました。その中からこのテックブログでは、特に私が興味深かったセッションを2つ紹介します。他のセッションの資料も以下にアップされていますので、ぜひご参照ください。 Security-JAWS【第41回】~Day1~ 2026年05月16日(土) - 資料一覧 - connpass Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 1つ目は、株式会社エス・エム・エス SRE 山口隆史さんの発表になります。 2024年2月のGoogleガイドラインによって、SPF/DKIM/DMARCが必須の対応となり地道に改善を進めているというお話しでした。 SPF/DKIM/DMARCのわかりやすい説明に加えて、問題となったケースについての紹介もあり、非常に有益な内容でした。そして改めてセキュリティの取り組みは銀の弾丸はなく、地道な運用が必要なんだと感じました。 speakerdeck.com Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか 2つ目は、アジアクエスト株式会社足立和生さんのセッションになります。様々なAIツールの企業導入が進んでいますが、AWSなど他のパブリッククラウドの権限をどの範囲で許可するかは非常に悩ましい問題だと思います。その中で、人間用のIAMロールとAI用のIAMロールを分けた方が良いよという話であったり、Claude Code / Codex / Kiro と統制観点で比較したりと興味深いお話しでした。こちらのセッションを聴いて、改めてAIに渡している権限は今のままで大丈夫だろうか。と考えるきっかけになりました。 speakerdeck.com Security-JAWS 全体を通しての感想イベント全体を通して、みなさんが楽しく過ごされているのが印象的でした。そしてAWSを利用する上で学びとなる内容もたくさんあり、イベント会場も素敵でリラックスしてイベントに参加することができました。運営のみなさま、素晴らしいイベント運営ありがとうございました！これからもまた参加したいと思います 🙌 We are actively hiring! アンドパッドのセキュリティグループではチーム力を更に向上させて、一筋縄ではいかないセキュリティ課題への挑戦を続けていきます。そのためにも「セキュリティ施策をどんどんリードしていきたい！」「これまでの開発経験をセキュリティ分野で活かしてしてみたい！」など、多様なバックグラウンドをお持ちの方と一緒に働きたいと考えています。カジュアル面談もいつでも大歓迎ですので、ご興味がある方はぜひ以下より申し込みお待ちしております。 hrmos.co またその他にも、さまざまなポジションを募集していますのでご興味がある方はぜひご参照ください。 hrmos.co

AWS
セキュリティ
IaC

ANDPAD·2026/05/19

CREがMVTを受賞した話~激流を乗り越えるCREチーム~

こんにちは！CREの山本です。今回はCREがアンドパッドの開発本部とプロダクト本部の合同総会DevPro総会で、MVT（Most Valuable Team）に選ばれた話について書こうと思います！はじめに何度かブログに登場しておりましたが、またまた久しぶりの登場となりました。アンドパッドにJOINしてから色々ありましたが、トータルで約3年半が経ちました。月日が流れるのは早いものです。私は引き続き引合粗利管理や受発注、請求管理といったFinancial系のプロダクトCREを担当し、リーダーとして日々課題に向き合っております。 MVT受賞 CREチームがアンドパッドの開発本部とプロダクト本部の合同総会DevPro総会で、MVT（Most Valuable Team）に輝きました！ CREチームとしては前年あたりから大きな岐路に立っている中で、今回MVT受賞は非常に価値があると考えています。この激流を乗り切り今も成長を続けているCREチームについてMVT受賞を機に振り返りたいと思います。激流を乗り越えるCREチーム向き合ってきた課題課題1: お問い合わせ件数の急増事業成長・利用拡大・ユーザー層の拡大・多様化に伴い、開発本部へのお問い合わせ件数も増大傾向となり、CREが門番としてその激流を受け止め、技術的なトリアージを行うことで、プロダクト開発チームを本来のミッションに専念させる。それがCREが請け負う責任でした。事業成長に伴うお問い合わせ増大は喜ばしいことであり、それをキャパオーバーになることなくプロダクトへのフィードバックや迅速な対応を維持できる組織が信頼されます。課題2: 障害対応の複雑化と難解な調査プロダクトの拡大やマイクロサービスとの連携の多様化も進んでいるため、障害対応も複雑化しており、CREチームとしてはスムーズな収束に導くために、どのようにして状況整理していくかが課題でした。また、エンタープライズ企業様への導入が進んでおり、発生する課題がより難解になってきている中で、CREチームもより多くの課題に向き合う必要がありました。膨大なお問い合わせを集約し、プロダクトの信頼性と開発の集中を両立するハブとしてのCREチームの役割も大きくなってきています。課題3: 属人化とナレッジの継承 CREチームでは、限られたベテランメンバーと新メンバーが協力しながら、挑戦の日々を過ごしています。様々なタスクがある中で一部のベテランメンバーで属人的に回しているタスクが存在し、注力すべきタスクに集中できるよう体制を整える必要がありました。振り返りと成果成果1：タスクの平準化と自動化による「脱・属人化」これまでベテランメンバーが属人的に行っていたタスクを見直し、自動化可能なところは自動化し、タスクについても属人的に対応するのではなく専任のメンバーを複数アサインするなど平準化も進めてきました。このことによってタスクの状況次第では別メンバーにアサインするなど流動的なタスク配分を行えるようになりました。成果2：AI（Cursor/Claude）活用による調査・対応の劇的効率化お問い合わせ調査の効率化のため、本格的にCursorやClaudeなどのAIを導入し、メンバー間による一次調査結果の標準化や調査スピードの向上も進めてきました。新たに加わったメンバーが率先して導入を行い、CRE内での勉強会を通して他メンバーへ事例共有を行うことでチーム内での活用を進めることができたことで、得られた成果です。複雑化した障害対応における状況整理の効率化についても進めました。多数のサービスが絡む事象には関わるステークホルダーの数も膨大となります。これらを整理するために社内共有用のフォーマットを整理したり、AIを利用してなるべく短時間で状況が可視化できるようプロンプトの整備なども行いました。これは日々問い合わせ対応を行っているメンバーのお困りごとから派生して取り組んだ成果でもあります。 (CREが調査や障害対応効率化のためにAI導入を進めてきた話は別途テックブログに書こうと思っています。) 成果3：オンボード体制の再構築 CRE組織も急拡大していく中で新メンバーも複数JOINしています。これまでの入社オンボードのやり方も見直し、入社後短期間で活躍できるようなオンボード体制も整備してきました。評価された点以上のように今回のMVT受賞はベテランメンバーと新メンバーでの試行錯誤の中、プロダクトの成長に応じて増大する開発本部へのお問い合わせ流入を精査・集約することで、プロダクト開発チーム本来の機能開発に集中できる環境を維持してこれたということが評価に繋がったと考えております。新メンバーの中には激流の中での挑戦となり不安だった部分もあったかと思います。それぞれのメンバーが自分の力を最大限に発揮し、アイデアを出し課題に向き合ってくれたことで、この激流を現在進行形で乗り越えられています。しかし、まだまだ成長を続けられるチームだと思っていますので、このMVT受賞は数年後のスケールに向けた基盤構築の第一歩と捉えています。さいごに現時点ではアンドパッドとして急成長真っ只中、1Qを終えてすでに前年比を大きく上回るお問い合わせをトリアージしております。このお問い合わせ接点から迅速に顧客の課題を解決することと急成長するプロダクトの開発を両立させるためには、ハブとしてのCREの立ち回りが非常に重要になってきます。 CREでは急成長の中、ユーザーのお困りごとを少しでも早く解決できるようアイデアを出したり、一緒に課題に向き合っていける仲間を募集しています。アンドパッドのCREに興味を持っていただけましたら、ぜひカジュアル面談などにいらしてください！ hrmos.co

CRE
生成AI
チームマネジメント

ANDPAD·2026/05/18

ソフトウェアサプライチェーン攻撃対策実践レポート 2026春

こんにちは、アンドパッドセキュリティチームの小野寺です。近年、ソフトウェア開発のエコシステムを狙ったソフトウェアサプライチェーン攻撃が大きな脅威となっており、開発環境や CI/CD パイプラインにおけるセキュリティの強化が急務となっています。アンドパッドでは、以前のブログでご紹介した EDR によるサプライチェーン攻撃対策とあわせて、より多層的な防御策の導入を進めています。本記事では、弊社が直近で取り組んだソフトウェアサプライチェーン攻撃に対する具体的な対策について、実践的なアプローチと実運用にのせる上での工夫や課題を交えてご紹介します。 Takumi Guard の導入 GitHub Copilot Coding Agent の Firewall に Custom allow list が必要となる場合がある他のジョブによって .npmrc がコミットされてしまう利用方法に応じたレートリミット外部 Action の SHA 固定による不変性の担保 GitHub Actions の permissions 最小化 AIエージェントを活用した対応まとめ We are hiring! Takumi Guard の導入 Takumi Guard は GMO Flatt Security 社が提供する、悪意のあるパッケージをブロックするレジストリプロキシです。 flatt.tech アンドパッドでは Takumi Guard を以下の方法で利用しています。開発者端末全台に Takumi Guard のプロキシを設定 Node.js のパッケージもしくは Python ライブラリをインストールする GitHub Actions で、Takumi Guard をレジストリプロキシに設定 2026年4月22日に RubyGems にも対応されたため、追加で対応を検討しています！ EDR によるサプライチェーン攻撃対策とあわせて、ソフトウェアサプライチェーン攻撃の入り口となりやすい開発者端末への悪意あるパッケージの混入を防いでいます。加えて、攻撃対象となりやすい CI/CD パイプラインへ Takumi Guard を導入し、サプライチェーン全体のセキュリティ強化を図っています。既に多くの開発者の方がブログで触れられているため、機能や導入手順の詳細なご紹介は割愛しますが、導入の容易さが考慮された設計となっていることもあり、アンドパッドでも大きな問題が発生することなく、スムーズに開発サイクルへ組み込むことができました。その中でも、実運用にのせる上でいくつか注意が必要な事項がありましたので、この場でご紹介します。 GitHub Copilot Coding Agent の Firewall に Custom allow list が必要となる場合がある GitHub Copilot Coding Agent を利用している開発組織も多いと思いますが、その場合には注意が必要です。GitHub Copilot Coding Agent は既定で Firewall が構成されており、有効になっている許可リスト以外への通信はブロックされます。そのため、以下の条件に合致する場合には、GitHub Copilot Coding Agent から *.flatt.tech レジストリへの通信が弾かれてしまいます。リポジトリの .npmrc に *.flatt.tech レジストリが追加されている GitHub Copilot Coding Agent がパッケージのインストールを伴う作業を実施する上記のようなケースでは、個別に GitHub Copilot Coding Agent の Custom allow list に *.flatt.tech を追加する必要があります。導入時点では、この Custom allow list はリポジトリ単位で個別に設定をする必要がありました。しかし、2026年4月のアップデートにより Organization レベルで設定ができるようになり、リポジトリごとの設定の手間は不要になっています。 github.blog 他のジョブによって .npmrc がコミットされてしまう GitHub Actions で Takumi Guard をレジストリプロキシに設定するステップを追加した場合、同一ワークフローの後続ステップによって .npmrc の変更が自動コミットされてしまうケースがありました。弊社では GitHub にコードを push すると、自動でコード整形（フォーマット）およびコミットを行う CI を利用しています。このステップの前に Takumi Guard を設定する処理を追加したところ、書き換えられた .npmrc まで一緒に自動コミットされてしまう事象が発生しました。これを避けるために、npm install 実行後に明示的に git checkout -- .npmrc のステップを追加し、.npmrc の変更を元に戻すことで自動コミットを回避可能です。利用方法に応じたレートリミット Takumi Guard は、利用方法（匿名利用や認証利用など）によって複数のレートリミットが設定されています。それぞれの値については以下をご参照ください。 shisho.dev 弊社では直近のサプライチェーン攻撃への対策として、決定から開発者端末への導入までを短期間で実施したため、一部の環境・ユーザーにおいてレートリミットに達してしまうケースが発生しました。特に「匿名利用」の場合、制限単位が IP アドレス単位となります。そのため、オフィス出社時など複数人が同一のグローバル IP を利用する環境下では、匿名利用モードではなく、メール認証を行うなどレートリミットを意識した導入方法の検討が必要になると考えます。現在は、よりレートリミットの閾値が高い組織ユーザートークンや Bot トークンでの導入も可能になっているため、そちらの利用を検討いただくのがおすすめです。以上、組織や開発環境単位で大規模に導入するにあたって、気を付けていただくと良い点を紹介しました。現在は、組織単位での感染可能性の通知など、集中管理を意識した様々な機能のリリースが発表されています。今後もセキュアな開発環境の構築に向けて、継続的に改善していきます。外部 Action の SHA 固定による不変性の担保 GitHub Actions で外部 Action を利用する際、タグ指定ではなく SHA で固定することが公式ドキュメントで推奨されています。 SHA 固定が推奨される理由は以下の通りです。参照している外部 Action が侵害された場合、タグはそのままで悪意のあるコードに差し替えられるリスクがある Git のタグは後から別のコミットに付け替え可能 Immutable-releases を利用したタグは除く SHA は不変（変更不可能）なため特定コミットを確実に参照し、意図しないコードの混入を防ぐことが可能社内のワークフローの SHA 固定状況にバラツキがあったため、全てのワークフローで SHA 固定する対応を実施しました。 SHA 固定への書き換えはルールが明確なため自動化と相性が良く、pinact 等のツールを使うことで大きな問題なく対応が可能でした。 github.com 併せて今後のワークフロー追加・変更に対応するため、Enforce SHA Pinningの利用を検討しました。Enforce SHA Pinning は Organization、リポジトリレベルで SHA 固定を強制できる機能です。この機能は自分たちのワークフローだけでなく、使用している外部 Action で呼び出されている Action も含め、依存先を再帰的にチェックします。そのため、コントロール外のところでエラーが発生する可能性があり、今回の短期対策では使用を見送りました。外部 Action で SHA 固定されていない箇所があると、そこから侵害の影響を受ける可能性があるため、外部 Action を精査して Enforce SHA Pinning を有効化したいと考えています。 GitHub Actions の permissions 最小化 GitHub Actions では permissions を明示的に指定することで、GITHUB_TOKEN に付与される権限を最小に絞ることが可能です。公式ドキュメントでも最小限の権限を付与することが推奨されています。権限の最小化によりサプライチェーン攻撃を防ぐことはできませんが、万が一ワークフローが侵害された場合に被害を最小限に抑えるためにも重要な対策となります。 2023年2月から Read repository contents permission がデフォルトになりましたが、それ以前に作成された Organization、リポジトリでは Read and write permissions がデフォルトになっています。 github.blog 弊社の Organization は上記変更以前から存在しているため Read and write permissions が設定されており、permissions が明示的に指定されていないワークフローも存在することから、全ワークフローに permissions を追加しました。 AIエージェントを活用した対応 SHA 固定の対応では pinact を使用することで自動的に修正できました。一方、permissions の最小化では、必要な権限をワークフローの記述だけで判断できず、利用している Action のソースコードや GitHub API のドキュメントまで確認して初めて明らかになるケースも多く、同様の自動化は困難でした。自動化ツールも存在しますが、対応している Action のカバレッジに限界があります。そこで、AIエージェントを活用した permissions 指定を併用することにしました。ワークフローファイルを読み込ませ、外部 Action のソースコードや GitHub API のドキュメントを参照しながら各ステップに必要な権限を推定させることで、人手で行う場合と比べて大幅に効率よく対応できました。また、contents: read をデフォルトとし、それ以上の権限が必要な場合のみ明示するという方針をあらかじめ与えることで、必要最小限の権限のみを付与するようにしています。まとめ今回は、アンドパッドでのサプライチェーン攻撃対策の取り組みについて紹介しました。攻撃が活発に行われているエコシステムを対象に、開発チームへの負担を抑えながら実施できる優先度の高い対策から着手しました。今回の対策はあくまで出発点であり、今後継続して侵害の予防・早期検知・迅速な対応の強化に取り組んでいく予定です。具体的には、より広範なエコシステムへの対応、CI/CD の外部通信の制御・ログの可視化等を検討しています。サプライチェーン攻撃は特定の組織だけの問題ではなく、ソフトウェア開発全体に関わるリスクです。本記事が、同様の課題に取り組むエンジニアの参考になれば幸いです。 We are hiring! セキュリティチームでは、ANDPADのセキュリティをより強固なものにする仲間を募集しています！少しでも興味を持った方は以下採用ページをご確認ください。 hrmos.co

セキュリティ
CI/CD
GitHub Actions

ANDPAD·2026/05/13

try! Swift Tokyo 2026 に参加しました！

今年4月に try! Swift Tokyo 2026 が開催されました。会場は去年と同じく立川、そして今年はワークショップも復活し、技術にどっぷり浸かれる刺激的な3日間となりました。アンドパッドからは iOS アプリエンジニア3名が参加し、ワークショップは各々興味を惹かれたものを選択、セッションとスポンサーブースは3人仲良く一緒に見て回りました。この記事では、数々の面白いコンテンツのなかでも特に興味深かったものを各自ピックアップし、その概要や興味深かったポイント、感想などを述べていきます！（左から）入社したての佐藤、腰の低い髙木、笑顔の硬い西 Day 1：ワークショップこんにちは、髙木（@kiwi_yuki）です。初日のワークショップでは、iOS Private Playgrounds に参加しました。 UIKit などの中に眠る、Private API について、どう調べ、どう Swift / Objective-C から呼ぶかをハンズオンで学ぶワークショップです。リポジトリは Private-Playgrounds/Try-Swift-Playgrounds です。学んだことワークショップは、Private API の「探索」、「呼び出し」、「実践」の3つのパートで進みました。探索編では、LLDB の po から呼び出す _ivarDescription / _shortMethodDescription / _methodDescription といったランタイム API を紹介してもらいました。あわせて、ヘッダを横断検索できる headers.82flex.com の使い方についても学びました。この _methodDescription を使った例として、以下のメソッドが発見できることを教えてもらい、自分でも実際に見ることができました。Objective-C らしい文章としても読めるセレクタで注意喚起をしていて面白かったです。 - (void) attentionClassDumpUser:(id)arg1 yesItsUsAgain:(id)arg2 althoughSwizzlingAndOverridingPrivateMethodsIsFun:(id)arg3 itWasntMuchFunWhenYourAppStoppedWorking:(id)arg4 pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:(id)arg5; 呼び出し編では Swift から Private API を呼ぶ4つのパターン (KVC、Selector、dlsym、Bridging Header) について学びました。どのパターンがどのようなときに使えるのかということがまとめられていてわかりやすかったです。実践編実践編では用意された課題を行う、もしくは興味のある API があればそれを呼び出してみる、という形式で行われました。探索編で教わった headers.82flex.com を眺めていたら、MapKit に MKAppleLogoImageView という非公開クラスを発見しました。さらに、そこには +logoForMapType:forDarkMode: というクラスメソッドが生えていました。このクラスメソッドの2引数を適切に渡して UIImage を返してもらう実装を Selector 経由で書きました。実際、当日は4つの呼び出しパターンをまだ理解しきれておらず、 Claude と相談しながら実装しました…。 private func makeLogoImage() -> UIImage? { let cls: AnyClass? = NSClassFromString("MKAppleLogoImageView") let sel = NSSelectorFromString("logoForMapType:forDarkMode:") guard let method = class_getClassMethod(cls, sel) else { return nil } typealias LogoFactoryIMP = @convention(c) (AnyClass, Selector, UInt64, Bool) -> AnyObject let fn = unsafeBitCast(method_getImplementation(method), to: LogoFactoryIMP.self) return fn(cls!, sel, mapType, isDarkMode) as? UIImage } これで、MKMapView を画面に載せることなく、以下のように地図タイプや DarkMode 別の Apple ロゴ画像を直接取り出せます。 Pull Request は#23 MKMapView Apple Logo Viewです。感想 Private API は実際のリリースには使用できません。しかし、これらのフレームワークの内側を知り探索できるようになることで、より実装やデバッグ時に生きる理解の深さを得られた半日でした。LLDB の使い方や、ランタイム API 周りの知識はすぐに業務でも使えそうです。 Day 2-3：セッション Swift Concurrency Type System www.youtube.com 西（@jrsaruo_tech）です。このセッションは「Swift Concurrency はなぜ難しいのか」「このコンパイルエラーはなぜ起きるのか」という問いを提示し、それに明確に答えるために形式的アプローチで型システムを深掘っていく、というかなり内容の濃いものでした。セッションではまずクロージャの変換ルールについて説明されたのち、Swift Concurrency の基盤となる2つの軸： Capability (“Where code runs”) と Region (“Where data lives”) という概念が導入され、さらに Affine 型システムについても触れたうえで、Swift Concurrency の型システムの形式化が図られました。正直私にとっては非常に難しく、当日ふむふむと分かったような顔をしながらどんどん付いていけなくなり、最後はちんぷんかんぷんでした（こんな顔 ( ᐛ ) をしていました）。後日動画で復習しましたがまだ完全には理解しきれていません。ですが型推論に触れられる機会はなかなかないので、下記リポジトリも参照しつつ学びを深めたいです。 github.com 個人的には、sending と consuming の類似性に関する話が興味深く感じました。例えば Rust は Ownership システムを言語の中核に据えていますが、Rust の公式ドキュメントには Ownership 由来の制約によってデータ競合がコンパイル時に防がれる旨の説明があります*1。そのような側面を持つ Ownership と Swift Concurrency がそれぞれ consuming と sending という似た道具を持っているのは、ある種の対称性があるように見えて面白かったです。この記事を書き終えたら動画をもう一周してきます。素晴らしい発表でした！ SwiftUIってなんでこうなるの？ youtu.be 佐藤（@luto_dev）です。このセッションでは、SwiftUIの内部構造と、その仕組みによってSwiftUIがどのように動作しているのかが紹介されていました。特に印象に残ったのは、Modifierと条件分岐の内部的な扱いです。多くのModifierは元のViewを直接変更するのではなく、Viewをラップして ModifiedContent という新しい型を生成していることが紹介されていました。また、if や switch を使ってViewを条件分岐させると、ViewBuilder によって内部的には _ConditionalContent のような型に変換され、条件のTrue側とFalse側は定義上異なる別のViewとして認識されます。そのため、同じViewの状態変化としてアニメーションさせたい場面でも、意図せずViewの破棄と再生成によるフェードアニメーションとして扱われてしまうケースがあるという解説は、とてもわかりやすかったです。さらに、ViewBuilder がこれらの型を組み合わせてView階層を静的な型として表現していることや、some Viewを用いることで、開発者からは複雑にネストした型を隠蔽しつつ、コンパイラには静的で具体的な型情報を提供する仕組みについても触れられていました。 SwiftUIが内部でModifierや条件分岐をどのように扱っているのか知れたことで、これまで感覚的に理解していたSwiftUIの挙動に対する解像度が上がりました。SwiftUIを使った開発が増える中、その仕組みを理解した上で扱えるようになりたいと感じていたため、非常に学びの多いセッションでした。おわりにワークショップやセッションを通して、多くの学びを持ち帰ることができました。また他の参加者の皆さんと交流できたこともオフラインイベントの醍醐味だなと感じます。 Embedded Swift をテーマとしたセッションも増え、Swift の活用領域が着実に広がり、“Swift Everywhere” の実現がより現実味を帯びてきていることも感じ取れました。来年もまた濃密な時間を過ごせることを楽しみにしています！ありがとうございました！アンドパッドではカンファレンスで新しい知見にふれることが大好きな Swift エンジニアを募集しています。ぜひカジュアル面談などで try! Swift Tokyo 2026 の感想戦をしましょう！ hrmos.co *1:https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#mutable-references<

Swift
iOS
SwiftUI

ANDPAD·2026/05/12

アンドパッド技術イベントのご案内 2026 年 5 月

こんにちは、 id:sezemi です。実は昨年度 2025 年 4 月～ 2026 年 3 月まで自宅のマンションの理事をしていました。そこで区分所有法の変更などがあり規約の改定をする必要があったのですが、 NotebookLM がいい感じに変更案を作ってくれて承認されました。仕事だけでなくプライベートも AI 漬けです。そして、アンドパッドも AI ネイティブなプロダクト "ANDPAD ナレッジ AI" をリリースしております。業界特化の膨大なデータを蓄積してきたからこそのプロダクトなので、ぜひご期待ください。 ai.andpad.co.jp さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。今月もイベント情報をまとめてお知らせします。ぜひご参加ください !! なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. 登壇情報 | Mobile Mob #1 〜スマホのハードウェア制御の悩み・工夫を語り合う〜開催日時 : 2026年5月12日(火) 19:15 ～ 21:15 会場 : Sansan株式会社本社イベントスペース主催 : 株式会社ビットキーイベント概要 : モバイルアプリ開発者が現場で直面する悩みと工夫を、みんなでカジュアルに語り合う勉強会です。第 1 回となる今回のテーマは「スマホのハードウェア制御」です。本イベントには、アンドパッドから平池拓也が「Android アプリから 360 度カメラ「RICOH THETA」に接続して写真を撮影する」というタイトルで登壇予定です。申込方法 : イベントページからお願いいたします。 bitkey.connpass.com 平池拓也 @hiraike32 2019 年から Android アプリの開発に従事し、2024 年にアンドパッドに入社。施工管理アプリや社内共有 SDK の開発を担当。平池拓也のテックブログ執筆記事 - Android アプリから 360 度カメラ「RICOH THETA」に接続して写真を撮影する - ANDPAD Tech Blog - 複数の Android アプリで使う社内 SDK の開発を整備する - ANDPAD Tech Blog 登壇タイトル: Android アプリから 360 度カメラ「RICOH THETA」に接続して写真を撮影する 2. 会場スポンサー | Tamachi.sre#4 開催日時 : 2026年5月19日(金) 19:00 ～ 21:00 会場 : 株式会社アンドパッド主催 : Tamachi.sre イベント概要 : Tamachi.sre は田町らへんでやる SRE のオフライン勉強会です。 SRE のテーマであれば、何でも発表は OK のイベントです。申込方法 : イベントページからお願いいたします。 tamachi-sre.connpass.com 3. 会場スポンサー | DroidKaigi.collect { #30@Tokyo } 開催日時 : 2026年5月29日(金) 19:00 ～ 22:00 会場 : 株式会社アンドパッド主催 : DroidKaigi イベント概要 : DroidKaigi が主催する、 Android 技術情報の共有とコミュニケーションを目的としたイベントです。今回は「Google I/O 2026・KotlinConf 2026」をテーマということで、 Android 17 での Gemini Nano との統合や、 Kotlin で AI エージェントを構築するための専用フレームワーク Koog などなど、大注目ポイントが目白押しです。最速で Recap しましょう！本イベントに、アンドパッドは会場スポンサーとして協賛し、会場を提供いたします。申込方法 : イベントページからお願いいたします。 droidkaigi.connpass.com まとめ採用広報から 5 月に開催されるイベント情報をお届けしました。 4 月に協賛した RubyKaigi 2026 については別途レポート記事を準備中なので、ご期待ください。では、イベントやカンファレンスでお会いできることを楽しみにしています ! また、アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。広報の経験がない方でも Welcome です！カジュアル面談やご応募、お待ちしております。 hrmos.co

Android
SRE
モバイルアプリ

ANDPAD·2026/05/11

Lambdaランタイムの更新をRenovateで検知できるようにしました

こんにちは、SREの千明です。2020年1月に入社して、気づけば7年目に突入しました。最近SREでは、イベント参加やブログ執筆が活発になってきているので、私もそれに触発されて久しぶりにブログを執筆することにしました。前回ブログに投稿したのが2020年6月だったので、なんと約6年ぶりの投稿になります。 WordPressをShifterへ移行した話 - ANDPAD Tech Blog 今回は最近導入した「Lambdaランタイムの更新をRenovateで検知できるようにする仕組み」について紹介しようと思います。こんな方におすすめの内容です今回の内容は、以下のような方向けになっています。ぜひ参考にしていただけると幸いです。 TerraformでLambda関数の管理をしていて、ランタイム更新を自動検知したい方 Renovateをすでに導入済みでパッケージ自動検知、更新に利用されている方（Renovateの導入方法は説明しません）複数のLambdaランタイムが混在しているリポジトリを管理されている方何を解決したかったのかこの仕組みを導入する以前は、以下の手順で定期的にLambdaランタイムの更新を実施していました。 Lambda runtimes(英語版)のページを定期的に確認して、EOLが間近に迫ったLambdaランタイムがないか確認する。 EOLが間近に迫ったLambdaランタイムがあった場合、該当のLambdaランタイムを使用しているLambda関数をリストアップする。リストアップしたLambda関数を管理している開発チームへLambdaランタイムの更新を依頼する。各開発チームが開発環境でLambdaランタイム更新の動作検証を行い、問題なければ本番環境でもLambdaランタイムの更新を実施する。しかし、上記の方法では誰かが能動的にEOLの確認をしなければいけません。さらに、EOLを基準として動き始めるため、更新期間（移行のための準備期間）が短くなってしまいます。Lambda関数を多数管理している開発チームの場合は、期限日（Deprecation date）までに更新が間に合わないこともあります。この課題を解決するために、新しいLambdaランタイムがリリースされたタイミングを自動検知して、更新を始められるようにしたいと考えました。まず、更新タイミングを自動検知することによって、能動的に確認をする必要がなくなります。そして、更新を始めるタイミングをEOLからリリースにすることで、更新期間を長く取ることができて、余裕を持ってLambdaランタイムを更新できます。どうやって解決したのか上記の課題を解決するために、Terraformで管理しているLambdaランタイムのバージョンをRenovateで検知して、新しいバージョンがリリースされたタイミングでPRを作成するようにしました。以下でその方法を解説します。リポジトリ構成今回サンプルとして用意したリポジトリは以下のような構成になっていて、lambda_function_rubyとlambda_function_nodejsの2つのLambda関数を管理しています。（ソースコードは別で管理されていて、今回の説明では割愛します） . ├── lambda_function_ruby │ └── main.tf ├── lambda_function_nodejs │ └── main.tf ├── modules │ └── lambda_function │ └── main.tf └── renovate.json いくつかのファイルについても、簡単に説明します。まず、modules/lambda_functionは、Lambda関数に必要なリソースを定義するモジュールで、runtimeの値を変数で受け取るようになっています。例えば、lambda_function_rubyでは、以下のようにモジュールを呼び出して、ランタイムの値を指定しています。 module "lambda" { source = "../../../modules/lambda_function" runtime = "ruby3.3" } また、すでにRenovateが導入されていて、その内容はrenovate.jsonによって設定されています。今回は、Terraformを更新するだけのシンプルな設定になっています。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": [ { "matchManagers": ["terraform", "terraform-version"], "labels": ["dependencies", "terraform"] }, { "matchPackageNames": ["hashicorp/terraform"], "additionalBranchPrefix": "{{packageFileDir}}-", "groupName": "terraform-version", "versioning": "hashicorp" }, { "matchDatasources": ["terraform-provider"], "additionalBranchPrefix": "{{packageFileDir}}-", "groupName": "terraform-providers" } ] } 説明は以上にして、次からはlambda_function_rubyを使って、Lambdaランタイムの更新をRenovateで検知できるようにするための設定方法を解説していきます。 Terraform側の設定まずは、Terraform側のLambda関数のリソース定義にあるruntimeへ、以下のようなRenovate用のコメントを追加します。このコメントを元にRenovateが更新対象を抽出します。 module "lambda" { source = "../modules/lambda_function" # renovate: datasource=endoflife-date depName=aws-lambda versioning=loose runtime = "ruby3.3" } Renovate側の設定次に、renovate.jsonにcustomManagersを追加します。この設定によって、先ほど追加したコメントとLambdaランタイムの設定を抽出します。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": ["...Terraformの設定（省略）..."], "customManagers": [ { "customType": "regex", "description": "Update AWS Lambda runtime in Terraform files", "managerFilePatterns": ["/.+\\.tf$/"], "matchStrings": [ "#\\s*renovate:\\s*datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s*runtime\\s*=\\s*\"(?<packageName>[a-z]+)(?<currentValue>[0-9.]+)(\\.x)?\"" ], "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{/if}}" } ] } このとき、正規表現の名前付きキャプチャーグループで名前を付けた値が、後述するpackageRulesの設定で利用できます。そして、ここが今回のミソなのですが、packageNameにrubyが入るようになっていて、この値もpackageRulesの中で利用できます。次に、先ほどのcustomManagersで抽出した部分を修正するために、packageRulesに2つのルールを追加します。このリポジトリでは、RubyとNode.js、2つのLambdaランタイムを管理しているので、それぞれのLambdaランタイムに対してルールを追加しています。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": [ "...Terraformの設定（省略）...", { "matchDatasources": ["endoflife-date"], "matchDepNames": <span class="synS

AWS
Lambda
Terraform
Renovate
SRE

ANDPAD·2026/04/30

ANDPADをビジネスの心臓部へ。システム連携コンサルタントの1日のスケジュールと業務内容を徹底解剖

こんにちは。プロダクト本部の公原です。私は現在、プロダクトマーケティング部でPMMと兼務で「システム連携コンサルタント」という役割を担っています。「システム連携コンサルタント」という職種ですが、職種名から実際の業務のイメージがしにくいといったお話をカジュアル面談などでお伺いします。そこで今回は「実際、毎日何をしているの？」という疑問にお答えするため、システム連携コンサルタントの1日をご紹介していきます。そもそもシステム連携コンサルタントとは、お客様の利用するシステムとANDPADをAPIで繋ぎ、最適な業務フローを設計するというポジションです。詳しく知りたいと思った方は、この記事だけでなく募集情報もぜひご覧ください。システム連携プリセールス/コンサルタント　/　HRMOS hrmos.co スケジュール平日の標準的なスケジュールは以下の通りです。基本的に午前・午後の各時間帯にお打ち合わせが入ることが多いため、合間の時間を活用して個別の作業や社内ミーティングを行っています。 8:00　起床眠気覚ましにコーヒーを淹れたり、ニュース・SNSアプリで時事情報をチェックしたりして過ごしています。 9:00　始業・メールチェック自宅からリモートワークを開始します。月に1度の出社必須な日を除き、基本的にはリモートワークを選択するメンバーが多いです。また、フレックスタイム制（コアタイム 11:00-15:00）を導入しているため、始業時間は個人の裁量に合わせて調整可能です。この時間帯にメールの確認や、社内ツール（Slack）のメッセージへの返信を行います。 10:00　社内すり合わせ(営業担当と一緒に) 営業担当から、API連携を希望されるお客様との商談への同席依頼を随時受けます。その際、事前準備として「お客様の現在の運用」や「APIで何を実現したいのか」を軸に、提案に必要な情報の収集を徹底しています。 11:00　お打ち合わせお打ち合わせは1日に2件程度です。 API連携に関心を持ってくださったお客様へ、API連携の概要などのご案内を行います。基本的にはオンラインでの実施が中心です（肌感ですが、全体の約9.5割がオンライン完結となっています）。 12:00 昼食自宅で簡単に済ませることが多いです。休憩時間を利用して、ちょっとした家事を並行して行うこともあります。 13:00　社内すり合わせ(部内で) 一人あたり約20社のお客様を担当しているため、対応漏れや回答の遅延を防ぐべく、部内で各メンバーの相談事項や進捗状況の共有、目線合わせを行います。 14:00　お打ち合わせ初回のAPI連携提案や意向確認は1時間程度で終了することが多いですが、導入に向けた要件定義や運用整備のお打ち合わせでは、1回あたり1.5時間ほどのお時間をいただきます。これを週1回、約1ヶ月にわたって継続し、運用の最適化を目指していきます。 15:30　資料作成(お客様向け) お客様のAPI連携に伴う要件定義の内容（連携のキーとなるID、トリガー、リクエスト数の試算など）について論点を整理し、次回のお打ち合わせに向けた資料を用意します。 17:00　資料作成(社内向け) お客様向けのタスクが一段落した際は、部内の業務改善や仕組み化に向けた施策の起案・実行にあてています。具体的には、提案資料のブラッシュアップや、過去の事例に基づいたリスク観点の整理など、チーム全体の質を高める活動を行っています。 17:30 メールチェック API連携の実装を担当されるシステム会社様から、仕様に関するご質問を随時いただくため、対応漏れがないよう終業前に再確認と返信を行います。 18:00　終業在宅ワーク中心の生活だと運動不足になりやすいため、リフレッシュも兼ねて近所のスーパーへ買い物に出かけることが多いです。帰宅後は、積読していた本を読んだりゲームを楽しんだりと、自宅でのプライベートな時間を満喫しています。業務の内容を割合で見てみるここまでは1日のスケジュール例をご紹介しましたが、システム連携コンサルタントの業務とその割合は4つに大別できます。ここでは、それぞれの業務についてより掘り下げていきます。 1.顧客折衝　　　　　：4割 2.要件定義・資料作成：3割 3.社内連携　　　　　：2割 4.業務改善・仕組み化：1割 ※補足上記はあくまで一例です。メンバーそれぞれの得意領域や、その時々のプロジェクト状況によって、この割合は柔軟に変化します。「自分の強みをどこで最大化させるか」をチームで相談しながら決めていける環境です。顧客折衝単なる機能説明ではなく、お客様の基幹システム（顧客管理や会計など）の仕様を紐解き、ANDPADと繋ぐことで「現場の運用をどう劇的に変えるか」を議論します。 DXを推進するお客様のご担当や、お客様のシステムを構築するシステム担当（場合によってはベンダーとなるシステム会社）と、「技術的に実現可能かつ運用が回る」落とし所を見つけ出します。設計・資料作成商談で伺った内容を持ち帰り、デスクでじっくりと「最適解」を練り上げる時間です。要件定義の試案を見ながら、お客様の要望は重要視しつつ全てを鵜呑みにせずに「より良い運用はないのか」、「このAPIのリクエストで、本当にお客様の現場は回るか？」と自問自答しながら、よりスムーズな業務フローや連携のタイミングや項目などを組み立てます。社内連携営業やカスタマーサクセスとの戦略会議です。お客様の業務フローを深く理解する担当と連携し、「お客様が本当に叶えたいことは何か？」を事前にすり合わせ、時には「このケースなら連携よりも別の新機能提案がベスト」といった踏み込んだ判断も行います。業務改善・仕組み化このポジションの面白いところは、単に「今ある機能」でお客様を支援するだけでなく、「まだない機能」を形にしていける点にあります。お客様の基幹システムと向き合う私たちは、誰よりも「プロダクトの伸び代」を知っている存在だからです。特定のユースケースにおいて不足しているAPIが、クリティカルかつ汎用的に今後必要になると判断した場合は、PMMへ要望を共有しつつ、「あるべきAPIの姿」を徹底的に目線合わせします。私たちが現場で掴んだ一次情報を、PMMがプロダクト戦略へと昇華させる。この密な連携があるからこそ、現場のフィードバックが置き去りにされることなく、ANDPADというプロダクトの進化へと直結していきます。また組織の「型」づくりにも尽力しています。例えば、誰もが最短距離で高品質な提案ができるよう、提案資料の型のアップデートや社内規定・ナレッジのドキュメント化によって「これってどうすればいいんだっけ？」という迷いをゼロにして、業務フローや判断基準を言語化し、オープンな資産にしています。　　　まとめシステム連携コンサルタントはこのように、単なる「データ転送の設定」を行う役割ではありません。顧客の業務フローを深く理解し、ANDPADと既存システムを最適に繋ぎ合わせることで、建設DXを完遂させる「最後の一手」を担っています。今回の記事を通して「システム連携コンサルタント」への理解が少しでも高まり、私たちの仕事の面白さが伝わったのであれば嬉しいです。最後に Wantedlyでは他の魅力的なシステム連携コンサルタントの実体験に基づくやりがいや入社前後のギャップを掲載しています。ぜひこちらもご参考ください。システム連携コンサルタントの真髄に迫る。お客様の課題解決にコミットし続けた1年間のリアル。/wantedly www.wantedly.com システム連携コンサルタントは現在、共に建設DXを加速させる仲間を募集しています！入社意思は問わず、詳細を聞いてみたいという場合でもカジュアル面談のお申し込みをお待ちしています。 www.wantedly.com

API
プロダクトマネジメント

ANDPAD·2026/04/21

Active Record アソシエーションを安全に廃止する

こんにちは、ザックです。アンドパッドでフリーランスの Rails エンジニアとして働きながら、趣味で Ruby や Rails にコントリビュートしています。このポストでは、Rails へ静かに加わったあまり知られていない機能を紹介します。大規模な Rails アプリケーションを扱うエンジニアには、特に役立つと思っています。 Deprecated Associations 古いアソシエーションの削除は、本来ならルーティンな作業のはずですが、実際には手探りになりがちです。コードベースを検索し、明らかな呼び出し箇所を修正し、テストを走らせ、アソシエーションを削除します。すべて問題なさそうに見えます。しかし、バックグラウンドジョブや管理画面、めったに使われないエンドポイントがまだ古い名前を呼び出していることが本番で発覚します。もはやクリーンアップ作業ではなく、インシデントです。 Rails 8.1 は小さな機能を追加しました: アソシエーションを deprecated としてマークできるようになりました。単に警告を出せるというだけではなく、段階的に移行する道筋を示してくれます: 開発環境では :warn を使い、エンジニアが作業を妨げずに deprecated な使用箇所を確認できる。テストと CI では :raise を使い、新しい呼び出しが混入しないようにする。本番環境では :notify を使い、残っている隠れた呼び出し元を構造化ログで見つけてからアソシエーションを削除する。「もう使われていないと思う」を、ほぼ確実な保証に変えられます。問題アソシエーションを削除するときに難しいのは、リファクタリング自体ではありません。すべての呼び出し元を見つけられたかどうかを確認することです。コード検索は役立ちますが不完全です。アソシエーションの使用箇所は、コントローラ、ジョブ、ビュー、preload クエリ、スクリプトなど各所に散らばっています。ローカルで再現しにくいパスもあれば、本番トラフィックでしか実行されないパスもあります。だからこそ、アソシエーションを早まって削除するのは危険です。メソッドはすぐに消えますが、呼び出し元は消えません。移行後に1つでも残っていれば、そのコードパスが実行された瞬間に落ちます。既存のアプローチこの機能が登場する前は、各チームが独自の解決策を用意していました。よくあるアプローチは、アソシエーションのメソッドをラップして deprecator で警告を出すことです: class Author < ApplicationRecord has_many :articles, class_name: "Post" has_many :posts, class_name: "Post" def posts Rails.deprecator.warn("Author#posts is deprecated, use #articles instead.") super end end 直接呼び出しはキャッチできますが、eager load やネストされた属性、フレームワーク側の間接的な使用は漏れます。廃止したいアソシエーションが十数個あれば、形の違う手書きのラッパーが十数個できあがります。段階的なアプローチを省略して grep・置換・削除だけで済ませるチームもあります -- うまくいかなくなるまでは。黙って壊れるのはこういう状況です: class Author < ApplicationRecord has_many :articles, class_name: "Post" end class LegacyAuthorDigest def published_titles(author) author.posts.published.order(:id).pluck(:title) end end Author#posts がすでに削除されていれば、LegacyAuthorDigest はそのコードパスが初めて実行された瞬間に NoMethodError で落ちます。アソシエーションを deprecated にする class Author < ApplicationRecord has_many :articles, class_name: "Post" has_many :posts, class_name: "Post", deprecated: true end Rails のドキュメントでは Deprecated Associations として解説されています。この変更だけで、Rails が posts の使用を報告し始めます。対象は直接のメソッド呼び出しだけではありません -- クエリ実行、ネストされた属性、:dependent や :touch といったオプションの副作用による使用も報告されます。宣言はアソシエーション自体に付くため、呼び出し箇所ごとに警告を書く必要がありません。まず :warn から始める # config/environments/development.rb config.active_record.deprecated_associations_options = { mode: :warn, backtrace: false } エンジニアは警告を確認できますが、作業はブロックされません。 LegacyAuthorDigest.new.published_titles(author) # => ["Kindred"] :warn モードでは、deprecated なアソシエーションを呼び出しても結果は返りますが、警告がログに出ます: The association Author#posts is deprecated, the method posts was invoked (app/services/legacy_author_digest.rb:3:in 'LegacyAuthorDigest#published_titles') ["Kindred"] コードは動き続けました。警告は移行の初期段階で有効で、作業の邪魔にならないからこそ意味があります -- 最初からエンジニアへ負担をかけると、回避策を探し始めて移行への協力が得られなくなります。テストと CI では :raise を使う # config/environments/test.rb config.active_record.deprecated_associations_options = { mode: :raise, backtrace: false } :raise に設定すると、古い呼び出し箇所はすぐ失敗します: ActiveRecord::DeprecatedAssociationError: The association Author#posts is deprecated, the method posts was invoked (app/services/legacy_author_digest.rb:3:in 'LegacyAuthorDigest#published_titles') app/services/legacy_author_digest.rb:3:in 'LegacyAuthorDigest#published_titles' フィーチャーブランチで新たな呼び出し箇所が追加されても、テストを走らせた時点で気づけます。移行が「なるべく使わないでください」から「誤って新しい使用箇所をマージできない」に変わります。置き換え後のパスはそのまま動きます: class AuthorDigest def published_titles(author) author.articles.published.order(:id).pluck(:title) end end 本番環境のツール: :notify # config/environments/production.rb config.active_record.deprecated_associations_options = { mode: :notify, backtrace: false } このモードでは、Rails はログ出力や例外の raise の代わりに deprecated_association.active_record 通知を publish します。本番環境こそ、隠れた呼び出し元が見つかる場所です。忘れられたジョブ、古い管理画面、低頻度のリクエストパスは、ローカルのテストでは一切現れないことがあります。:notify を使えば、本番トラフィックを失敗させずにそれらの呼び出し元を観測できます。 deprecated_association.active_record 通知のペイロードには以下が含まれます: アソシエーションのリフレクション人が読めるメッセージ deprecated な使用が発生したアプリケーション側の場所任意のバックトレース通知を受け取る Active Support Instrumentation と ActiveSupport::Notifications を使います。イニシャライザでイベントを購読し、構造化ログを出力します: # config/initializers/deprecated_association_subscriber.rb ActiveSupport::Notifications.subscribe("deprecated_association.active_record") do |_name, _start, _finish, _id, payload| reflection = payload.fetch(:reflection) Rails.logger.warn( { event: "deprecated_association_usage", association: "#{reflection.active_record.name}##{reflection.name}", model: reflection.active_record.name, association_name: reflection.name.to_s, location: payload[:location]&.to_s }.to_json ) <span cl

Ruby
Rails
ActiveRecord

ANDPAD·2026/04/17

アンドパッド PMMの役割とリアルな1日

こんにちは、PMMの西村です。月日が経つものは早いもので、入社して早1年（2025年7月入社）が経過しようとしています。その間に、PMMメンバーが3人増えています！私は前職でもPMMをしていましたが、「PMMって聞いたことはあるけれど、具体的にどんなことをする役割かわからない」「会社によって求められることが違う印象がある」という声を聞くことがあります。そこで、本日は「アンドパッド PMMの役割とリアルな1日」について紹介したいと思います！ 1. 「まだ、足りない」という現状カジュアル面談でよく「アンドパッドはもう組織として完成されていますよね？」という質問をいただきます。しかし、実態は全く逆です。もちろんPMMチームが成長する中で、型が整いはじめているものもありますが、常にトライアンドエラー。変化が求められる段階にあると感じています。現在、PMMチームは今なお拡大していますが、これは「建設業界のペイン」がそれだけ深く、広いことの裏返しです。新規事業の立ち上げ、既存プロダクトの市場浸透、そして圧倒的な「Moat」の構築。やるべきことは山積みですが、実際は「すべてのプロダクトにPMMが配置できているわけではない」という状態にあります。そのため、まだまだ、プロダクトを生み、市場浸透をしていくチャレンジングな機会にあふれるポジションになります。 2. PMMの役割：顧客課題の「真因」を探り、顧客アウトカムを描く「PdMと何が違うのか？」という問いに対し、私たちは役割分担を定義しています。以下の図の通りPMMは要求整理に始まり、グロースまで多岐に関わります。主な業務については上図の通りとなりますが、PMMの真価が発揮されるのは「コアバリューの特定」「顧客アウトカムの提供」に関わる活動だと考えています。コアバリューの特定：事業部から上がる声を頼りにしますが、鵜呑みにはしません。「XXの機能がほしい」となった場合、その機能を求める理由が何か、事実ベースで要求を整理します。それによりこれから開発する機能のコアバリューを定義し、要件定義以後の開発における方向性のぶれを最小化させます。顧客アウトカムの提供：機能を開発したら終わりではなく、それをどのように届けるかについてマーケティングチームや事業部の方と連携し、検討します。私自身、まだまだ至らぬ点がありますが、顧客アウトカムの実現に責任を持つことがPMMとしての責務であり、腕の見せ所だと考えています。関係者はPdM、デザイナー、エンジニア、FS（営業）、CS、BizOpsなど多岐にわたり、まさに事業の「結節点」として動くことになります。 3. スケジュール：圧倒的な「対話量」と「思考時間」の両立 PMMの仕事は、一人では完結しません。1週間のうち半分程度は各所とのミーティングに充てられます。大別すると次のような内訳で1週間を過ごしています。私の1日のスケジュール 7:00～7:30: タスク整理・Slack確認 7:30～9:00: 朝ごはん・子供の送りだし 9:00～12:00: PMM定例や1on1、事業部との情報同期・議論 12:00～13:00: 昼ごはん 13:00～18:00: 開発チーム定例、プロジェクト定例、顧客ヒアリング、企画・作業 18:00～18:30: 振り返りと翌日の準備チームの半数ほどは小さいお子さんがおり、無理な時間に働くということは少なく、フレックスで柔軟に対応している印象があります。また18時以降になるとSlackでのメンションも落ち着き、オンとオフの切り替えがしやすい環境です。 4. ドメイン知識の壁：必要なのは「知識」ではなく「解像度」への責任「建設業界の知識がない」という不安は不要です。実はPMMチームの9割は異業種からのジョインです。私たちがドメイン知識以上に重視しているのは、知識の量ではなく、「未知の課題を自分事として解決していくための行動力」です。業界未経験でも活躍するメンバーに共通する「スキルと姿勢」ドメイン経験がないからこそ、自ら解像度を上げに行く。活躍しているメンバーには、共通して以下のような姿勢があるように感じます。「業務を代替できる」までの手触り感：プロダクトを使うユーザーの業務を、自分自身が代わりに行えるレベルまで解像度を高める姿勢です。顧客要望の声を浴びることはもちろん、事業部メンバーへの徹底的なヒアリング、さらには建設現場に足を運び、実際の活用方法を横で観察する。手段は問いませんが、自分なりのやり方で「手触り感」を掴み、ドメイン課題を自分事化する力が求められます。「答えのない問い」に対する意思決定：解像度が上がると、自ずと「このプロダクトはこうあるべきだ」というビジョンが見えてきます。正解が用意されていない状況の中においてビジョンを実現するために、他部署のメンバーを巻き込み、様々な視点のフィードバックをもらいながら進める「推進力」が、ドメイン知識以上に求められるPMMスキルです。専門性を最速で身につけるための「オンボーディング」もちろん、個人の努力だけに頼るわけではありません。最速で立ち上がるための仕組みも整っています。全社オンボーディング（1週間）: 業界構造や戦略を各部長陣から直接インプット。 PMM独自の研修（約1ヶ月）: プロダクト理解を深めるための学習内容、各種定例MTGに同席、メンターとの1on1など。リモート中心の働き方ですが、slackで気軽に相談もできます。プロダクトアサイン: チーム配属後、1ヶ月後を目安に理解度を確認。キャッチアップのプロセスなども通じて、アサイン時期や担当プロダクトのすりあわせをします。またアサイン後は、数ヶ月～半年ほど先輩PMMが伴走しながら徐々に独り立ちをしていきます。 5. 変化を楽しみ、既存の仕組みも再定義する現在のPMMチームは、個別のプロダクト最適を超え、複数ある事業部×プロダクトをつないで「ALL ANDPADとしてどう動くのが顧客にとって最善か」を考えるフェーズにいます。また、生成AIなどの技術発展に合わせ、これまでの開発体制やプロセス自体を見直す議論も活発に行われています。そのような変化を「面白さ」と捉えて働くメンバーがいるのが、PMMチームです！ぜひ、ご興味ある方は一度お話しできたら嬉しいです！最後にアンドパッドのPMMは、単に機能をビジネス寄りに立ち、つくる人ではありません。複雑な業界課題を紐解き、本質的な価値を見出し、届け、変化をみるところまでが仕事です。私たちの介在によって、数年後の日本の建設現場が変わる。そんな手応えを、ぜひ一緒に味わいましょう！

プロダクト
組織

ANDPAD·2026/04/16

アンドパッドが RubyKaigi 2026 で Ruby スポンサーになった理由

こんにちは、 id:sezemi です。この特集を始めた頃は、子どもたちの春休みのお弁当に悩む時期でしたが、いまは学校が始まりました。ふい～と胸をなでおろしつつ、ふと昼食時の静寂がさみしさを感じる在宅勤務です。さて、いよいよ RubyKaigi 2026 まで、あと 7 日です。 RubyKaigi 2026 特集もこの記事がラストです。これまで Drinkup 、 Drinks and Local Meals 、立ち読み喫茶、アンドパッドから登壇する Speakers によるトーク紹介と特集して参りました。アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(前編) - ANDPAD Tech Blog アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(後編) - ANDPAD Tech Blog アンドパッドは RubyKaigi 2026 で立ち読み喫茶と本のプレゼント企画をやります - ANDPAD Tech Blog アンドパッドから RubyKaigi 2026 にエンジニア 4 名が登壇します! - Ruby のコアからエコシステムまで - ANDPAD Tech Blog 最後の記事はアンドパッドブースの展示内容とノベルティを紹介しながら、締めくくりとして、アンドパッドが、なぜこれだけ RubyKaigi 2026 を Ruby スポンサーとして盛り上げようとしているのか、その背景を紹介します。最後までぜひご覧ください。 Ruby 開発環境現状確認 2026 アンケートに答えるとノベルティをプレゼント！アンドパッドブースでは先日の "立ち読み喫茶" に加えて、 Ruby 開発環境現状確認 2026 アンケートを行います。その名の通り、 RubyKaigi 2026 に来ている Rubyist の開発環境現状確認として、業務で使っている Ruby のバージョンやエディタ、コーディングエージェントなどを聞く簡単なアンケートを実施します。回答結果は Day ごとに X でポストするほか、最終結果はテックブログで公開しますので、ぜひご協力ください。私自身、開発環境現状確認エントリ大好き人間なので、とても楽しみにしています。そして、アンケートに答えたり、 X アカウントをフォローいただくと、恒例のアンドパッドのオリジナルノベルティをプレゼントします！今回用意したノベルティは 4 種。カンファレンスや日常生活に役立つものを作ったので、ぜひ受け取って、使ってください。 ANDPAD デカデカバッグ Conference Journey Log ANDPAD メジャー ANDPAD マスキングテープ今日はこの中から 2 つ紹介します。カンファレンス巡りで使えるスタンプ帳、 Conference Journey Log が新登場！ Ruby コミュニティで開催されるカンファレンスは、 RubyKaigi や Kaigi on Rails だけでなく地域 Ruby 会議もあります。また、 Ruby だけでなく様々な専門技術のカンファレンス、横断テーマのカンファレンスなどが全国各地、世界各地で開催されています。 Rubyist の皆さんも旅をしながら、カンファレンス巡りを楽しんでいることでしょう。そして、各カンファレンスでは独自のステッカーや中にはスタンプがあり、また、それに加えてスピーカーや書籍の著者のサインももらう機会もあります。それらをコレクションできるスタンプ帳として制作したのが、 Conference Journey Log です。中身は白地のノートになっているので、思い思いにステッカーやプリクラを貼るなど自由に使ってください。 Rubyist が大好きなカンファレンス巡りで活躍しますので、ぜひお供にどうぞ！ ANDPAD メジャーが復活アンドパッドでは軍手やグローブ、ツールセットなど建設小物をノベルティにしてきましたが、根強い人気を誇っていたのがメジャーです。過去のメジャー今回それを復刻しました！そして、水平器付きです。メジャーとしての機能だけでなく、 DIY や家具の組み立てのときなどに重宝するアイテムです。新作メジャーその他にもカンファレンスや日常生活で使えるノベルティを揃えましたので、アンドパッドブースへのお越しをお待ちしております。アンドパッドが RubyKaigi 2026 で Ruby スポンサーになった理由これまで特集してきたように、アンドパッドは RubyKaigi 2026 を盛り上げようと Ruby スポンサーになり、気合を入れて、ドリンクやランチ、 Drinkup にブースと沢山のことを企画・準備しております。その背景にあるものは、アンドパッドが初めて RubyKaigi に Ruby スポンサーとして協賛した 2019 の経験からです。 RubyKaigi 2019 当時はロゴも社名も今とは違っていました (https://rubykaigi.org/2019/sponsors/ より出典) 当時のアンドパッドは大型の資金調達ができ、プロダクト開発を非連続で拡大・成長させるべく、これまでのリファラル採用だけでなく、本格的に門戸を広げたエンジニア採用と広報をはじめる必要がありました。そこで RubyKaigi 2019 で Ruby スポンサーとして協賛したのでした。そのときの経緯は以下の記事で触れています。アンドパッドカンファレンススポンサーの歴史と教訓～巨人の肩の上に立つ - ANDPAD Tech Blog RubyKaigi 2019 で Ruby スポンサーをしたことで、コミュニティとのリンクができ、結果として多くの素晴らしいエンジニアを迎えることができました。それに端を発し、お陰様で会社・プロダクトともに圧倒的な成長を遂げ、 ANDPAD は今年でリリース 10 周年を迎え、今では利用社数 23 万社、ユーザー数 68 万人の毎日の建設業務を支え、 ARR は 100 億円に到達しました。アンドパッドの 10 年間の成長を生み出した一つは Ruby と、それを支える Ruby コミュニティがあったからとも言えます。アンドパッドが RubyKaigi 2026 で Ruby スポンサーを務めるのは、 10 年の成長要因の一つとなった 2019 での恩返しでもあります。 page.andpad.jp それでもまだ ANDPAD が建築・建設業界すべての業務をカバーできているわけではなく、 AI 活用も緒についたばかりです。昨年末に公開した CEO の稲田の記事の通り、これまでの 10 年をさらに超える ARR 300 億円という目標を立て、 ANDPAD が浸透すべき業務や業種への展開をさらに加速させています。そのためには、エンジニア組織のさらなる拡大が不可欠です。この RubyKaigi 2026 ならびに Ruby コミュニティを盛り上げることで、アンドパッドの次の挑戦を共にする新たな仲間に出会うきっかけになればと願っています。まとめ最後はエモさが出ましたが、それだけ RubyKaigi 2026 で盛り上げたいと準備を進めています。ぜひご期待ください。では、 RubyKaigi 2026 をともに楽しみましょう！函館でお会いできることを願っております。

Ruby
技術広報

ANDPAD·2026/04/13

アンドパッドから RubyKaigi 2026 にエンジニア 4 名が登壇します! - Ruby のコアからエコシステムまで

こんにちは、 id:sezemi です。小 4 になる娘から素朴に「大人は春休み、ないの？」と聞かれて、「今度パパは函館に行くんだ！」と謎の返しをしてきました。間違ってない、 RubyKaigi は各地に連れて行ってくれる旅行のようなもんなんだから。さて、その RubyKaigi 2026 です。テックブログでの RubyKaigi 2026 特集月間はまだまだ続きます。これまでの特集記事は以下のリンクから。アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(前編) アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(後編) アンドパッドは RubyKaigi 2026 で立ち読み喫茶と本のプレゼント企画をやります今回はアンドパッドから 4 名が Speaker になり、過去最高の人数となったので、各 Speaker に見どころや意気込みを語ってもらいました。ぜひご覧ください！ h2{border-left:#ef3340 .3em solid; padding:.4em; border-bottom:none; margin:1em 1em 1em .5em} hasumikin: Funicular: A Browser App Framework Powered by PicoRuby.WASM (Day 1 10:50 rubykaigiA) X: @hasumikin PicoRubyとPicoRuby.wasmの作者。mrubyとmruby/cのコミッター。トークについて PicoRuby.WASMでブラウザアプリ（SPA）を書くためのフレームワークをつくっている、という話をします。言語処理系からフレームワークまで一貫して開発しているという点がRubyKaigiっぽいと思います。 RubyKaigi 2026 で楽しみにしていること 10年以上ぶりの北海道旅行なので、広大な大地を堪能します。 youchan: Guide to getting started walking source codes of CRuby (Day 1 16:00 rubykaigiC) X: @youchan Rubyで書かれたプレゼンテーションツールGibierの作者。 Asakusa.rb, Chidoriashi.rb のメンバー。トークについて RubyKaigiに参加のみなさんはRubyの実装についてもっと知りたいと思いますよね。CRubyのソースコードを読んでみたいと思いますよね。私もその一人です。CRubyのソースコードを読むことは冒険のようにワクワクします。そんなワクワクが伝えられたらいいなと思います。 RubyKaigi 2026 で楽しみにしていること RubyKaigiは何もかもが楽しみなのですが、Rubyistのみなさんと会えることが一番の楽しみです。一緒に函館を楽しみましょう！ nagachika: Pure Intonation on Browser: Building a Sequencer with Ruby (Day 2 13:30 rubykaigiC) X: @nagachika CRubyコミッター。CRuby安定版ブランチメンテナ。サウンドプログラマワナビー。トークについて ruby.wasm と Web Audio API を利用してブラウザで動く純正律シーケンサーの紹介をします。ruby.wasm の活用事例と音楽理論の話というまったく違うトピックを織り交ぜるので、幅広い層の人に興味を持ってもらえれば嬉しいです。 RubyKaigi 2026 で楽しみにしていること久しぶりの発表なのでフィードバックがいただけると嬉しいです。また他にも WASM 関係や音楽関係のセッションが多くあるので、そこから新たな知見や刺激が得られるのも楽しみにしています。 hsbt: Ruby Releases Ruby (Day 3 14:10 rubykaigiA) X: @hsbt OSS プログラマ、 Ruby コミッター、 ruby, rubygems, bundler, rake, rbenv, ruby-build, psych など多数の OSS のメンテナー、そして ruby-lang.org の管理者。 Ruby プログラミング言語の開発を支えるインフラのメンテナンスを担当。株式会社アンドパッドで技術広報業務に従事しながら、 Ruby プログラミング言語の OSS 開発をフルタイムで行っている。トークについて RubyやRubyGemsのリリース工程を「手作業の運用」から「堅牢なコード」へ昇華させた技術的実装を紹介します。Linux,FreeBSD,macOSなど数十台の多様なプラットフォームをIaCで統制するCI基盤、リリース時に変更点の集計からMarkdown生成・CDNパージまでを自動化したRubyスクリプト群、バックポートの自動化、そしてgemリリースのSigstore統合まで。最近のリリース頻度向上とサプライチェーンセキュリティ強化を両立させた、RubyだからこそできるRubyの開発とリリース基盤の全貌を解説します。 RubyKaigi 2026 で楽しみにしていること世界中のプログラマと Ruby と RubyGems について方向性を話してから、色々と物事を進めると言うのを毎年やっているので、今年もあれこれ進めていこうと思います。まとめ 4 名の Speaker に意気込みを語ってもらいました！ぜひトークにお越しいただいて、感想などを Speaker たちにフィードバックいただければと思います。また、 Speaker たちはアンドパッドのランチ配布時にお弁当を手渡ししますので、ぜひエールやメッセージをいただけると大変喜びます。 ANDPAD Tech Blog での RubyKaigi 2026 特集はまだ続きます。次回は皆さん、お楽しみのノベルティを中心に紹介します。

Ruby
WebAssembly
OSS

ANDPAD·2026/04/10

浮いたボールを拾いまくったらトイルを改善していた話

こんにちは。サービスプラットフォーム部 SRE チームの谷合です。普段はメガネ集めと、毎日のビールを楽しみながら生きています。 2025年11月に入社してから今日まで、浮いているボールや浮きそうなボール、あるいはすでに落ちているボールを拾うことを、意識的にやってきました。ちなみに、あとから振り返ってみると、その姿勢の背景には、Kyash 執行役員 VP of Engineering の Konifar さんの記事の影響があったように思います。「ボールは落とさない」という考え方に以前から強く共感していましたが、入社後はそれを一段階進めて、「なら拾いにいこう」と思ったきっかけが、まさにこの記事でした。とてもいい記事なので、皆さんも是非ご覧ください！ konifar-zatsu.hatenadiary.jp 今回のブログでは上記のKonifarさんの記事をもっと紹介したいところですが、私が入社後どんなボールを拾って、どんな結果になったかをご紹介します。拾ったボール拾った結果トイル解決へ依頼を見える化プロファイルの送信自動化さいごに We are hiring! 拾ったボール SREチームは、日頃から様々な依頼を他チームや他部門から受けることがあります。 SREチームは割り込みタスクが発生しやすく、タスクが業務時間から溢れてしまいがちです。効率よく捌いたり、発生そのものを抑制する努力が大切です。ですので、新入社員の私は先輩社員をサポートするためにボールを拾いまくる決断をしました。そんな私が感じたのは SREチームの新入社員こそ浮いたボールを拾った方が良いということでした。自発的に課題を見つけて倒しに行く過程で、既存SREメンバーやその他の社員にとっては当たり前のことでも、新入社員の視点から見るとトイルであると気付くことができます。また、浮いたボールを拾いまくることで、現状の歴史的経緯やコンテキストにも多く触れることができ、自身の成長にも繋がります。実際に拾ってきたボールを、定常業務の巻取りと、参加する過程で見つけた改善のボールに分けて記載します。まず、定常業務は浮いていたわけではありませんが、依頼量が多くて大変だったため、積極的に参加しました。 AWS IAMユーザやグループ追加 GitHubリポジトリ、チーム追加 SREチーム内のコードレビュー定例会議のファシリテーションベトナム法人 ANDPAD VIETNAM (アンドパッドベトナム) のエンジニアのIaCレビューもしくはインフラ実装一方で、参加する過程で「ここは改善できそうだ」と感じた部分は、浮いていた課題としてボールを拾って対応しました。拾った結果現在、弊社ではIAMユーザからAWS IAM Identity Centerに移行し、さらにIdPと連携させることでSSOへの移行を進めています。しかし、まだ完全移行が完了していないため、前述したようにAWS IAMユーザの払い出しやグループへの追加申請は、SREの業務を圧迫することがよくありました。各種アカウントやユーザ発行、グループ追加などの申請業務フローにSlackワークフローが使われていて、１つのチャンネルに様々な依頼が集まっています。そのため、月末月初の入退社対応、開発に必要な権限払い出しや、グループ追加、GitHub関連の依頼が集まるチャンネルはカオスな状態でした。このチャンネルにくる依頼の難しいところは、SRE以外のチームが対応する依頼も含まれるといったことです。そんな無数の依頼に対して、SREチームはチャンネルを自発的に見に行き、対応すべき依頼を目視で見つけている状況でした。申請が羅列されているので、SREチームが対応すべき依頼を探すのが大変だったため新入社員の私はこれを何とかできないかと考えました。さらに、IAMユーザの払い出し後は初期プロファイルを手動でDMしていました。加えて、弊社ではAWSで二要素認証を必須としているため、DM後にその設定がうまくできない人からの個別問い合わせが日本とアンドパッドベトナム両方で発生していました。これらが結構なトイルとなっていたのです。 SREチームの稼働を圧迫していたボールを拾いまくった結果、以下のトイルが見えてきました。 SREの対応すべき依頼を見つけるための目視 IAMユーザの初期プロファイルを手動DM 二要素認証の設定個別対応トイル解決へ見つけたトイルに対して私は以下のアプローチをとりました。依頼を見える化当初、 SREチームが対応すべき依頼を目視確認している状況について、以下のように一覧を自動作成する改善を検討しました。対応すべきタスクを Slack リスト化対応すべきタスクをスプレッドシート化ところが、弊社の依頼が集まるSlackチャンネルのワークフローが作成する投稿のメッセージでは、リアクションをトリガーにできませんでした。また、アンドパッドベトナムのエンジニアは独自のSlackワークスペースを持つため、このチャンネルにSlack Connectで接続しています。 Slackの仕様上、外部の人が参加しているチャンネルではキーワードトリガーは設定できないため、 SRE といったキーワードを持つ依頼をトリガーにできませんでした。そこで、「一覧の自動作成」以外の道を模索すべく、チャンネルの管理者にコンタクトをとり、一緒にソリューションを検討しました。まず、弊社の依頼は以下のフローで処理されていました。依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される依頼を上席が承認する管理者が投稿をSREに依頼する目視で確認すべき数が多いため、対応漏れが発生するそこで、以下のようにチャンネルの管理者に変更してもらい、SREが対応すべき依頼をfeedとして集約することで可視化できました。このフローは今では上手くいってますが、SREから細かくFBをしてチャンネル管理者と一緒に連携してオペレーションを変更するなどして作り上げていきました。依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される依頼を上席が承認する管理者が投稿をSREに依頼する SRE用の依頼を、別の feed チャンネルへ通知投稿するワークフローが動く feedの通知投稿には、依頼元投稿と依頼元スレッドリンクが記載される依頼元で対応するボタンを押すと対応者の名前がメンションされ、通知投稿に対応中スタンプが自動で押される対応後は対応しましたボタンを押すと、通知投稿に対応完了スタンプが自動で押されるこのようにSREだけでなく、他チームにいるSlack管理者を巻き込んで会話でトイルを解決しました。また、このフローの副次的なメリットも生まれました。以前は1つの依頼に対してオーナーを可視化する術がなかったので、依頼が対応中であることを知らずに複数の担当者で対応してしまうことが発生していました。今回のフローに変更することで対応者の名前がメンションされることでオーナーが可視化でき、2重対応がなくなりました。プロファイルの送信自動化ここまでは申請をどのように可視化するかという問題に対して、目視によるトイルを他チームと連携して会話で解決するアプローチをご紹介しました。ここからは、 IAMユーザの初期プロファイルを手動DM をどのように自動化してトイルを倒したかをご紹介します。アンドパッドでは、IAMユーザはTerraformで管理しているのでコードを開発者に書いていただき、PRを起票いただくことでユーザを払い出しています。その後、以下のフローで後処理を手動で実施していました。初期パスワードをマネジメントコンソールで作成初期パスワードとIAMユーザ名、マネジメントコンソールのURLをSlackへDM 毎月の月初には日本のみならずアンドパッドベトナムの新入社員のIAMユーザ払い出しが発生するため、累計するとそれなりに時間を要する作業でした。さらに、人間がDMで初期情報を送っていたため、二要素認証の設定でつまずいたユーザーはそのDMで直接問い合わせてくることが多く、SREメンバーへの個別対応が頻発していました。これを技術の力で解決しました。まず、IAMユーザを作成した時に、CloudTrailで CreateUser イベントが発生します。これを Amazon EventBridgeで検知します。 Amazon EventBridgeはAWS Lambdaをトリガーし、以下の流れで処理を行います。アンドパッドのポリシーに沿ったパスワードを、初回ログイン時の変更を強制した上で文字列として作成 aws/aws-sdk-go-v2パッケージのCreateLoginProfile関数でパスワードを登録 AWS Systems Manager Parameter Storeに事前登録したSlack Bot Tokenを読み出す slack-go/slackパッケージを使用し、Slack Bot経由でDM シーケンス図で書くと以下のようになります。この仕組みのおかげで、IAMユーザの作成後は以下のDMが自動送信できるようになりました。なお、弊社は日本だけでなく、アンドパッドベトナムもあるため、日本語と英語を併記しています。 Bot経由の自動送信に切り替え、メッセージ内で「問題が発生した場合は申請スレッドで問い合わせてください」と案内することで、問い合わせがオープンな場に集約され、個別DM対応のトイルも解消しました。この自動化を実装したことで、SREは余剰の時間を別のタスクへ充てられるようになり、チームの生産性も改善しました。さいごにここまで私がボールを拾いまくって、いつの間にかSREチームの長年のトイルを「会話」と「技術」で解決した話をご紹介しました。ボールを拾うのはとても勇気が必要ですし、「できなかったらどうしよう」とか「自信がないな」とか色々と考えて一歩踏み出せないですよね。でも、拾った先には所属チームから感謝されるし、自分の成長にも繋がります。何よりも数をこなすことで誰も気づかないチームの問題点にも気づくことができるようになります。ボールを拾って、問題点を解決するなんて素敵なアクションにも繋がるので、是非臆せずに行動してみてほしいです。浮いたボールにはチャンスがあるぞ！ We are hiring! アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。 hrmos.co hrmos.co hrmos.co github.com

SRE
AWS
Slack
自動化

ANDPAD·2026/04/09

アンドパッドは RubyKaigi 2026 で立ち読み喫茶と本のプレゼント企画をやります

こんにちは、Ruby コミッタの@hsbt です。函館の後に実家に帰るついでに北海道旅行に行こうと15年ぶりくらいに十勝方面の旅程を組んでいる真っ最中です。十勝といえば豚丼、ということで楽しみにしているのですが、ここにきてインデアンのカレーが良い、という情報を入手してそんなに食べられない...となっています。さて、今回は RubyKaigi 2026 のアンドパッドブースで実施する「立ち読み喫茶」という企画のご紹介です。アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(前編) アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(後編) 立ち読み喫茶とは喫茶店のテーブルに本や雑誌が置いてあって、コーヒーを飲みながらページをめくる、あの感覚をカンファレンスのブースに持ち込む企画です。ブースにはアンドパッドの Rubyist たちが選書した技術書を展示します。ソフトスキル、ハードスキルを問わず、それぞれがエンジニア人生で影響を受けた一冊を持ち寄りました。手に取って、気になるページを開いて、立ち読みしてみてください。気になることがあれば、その本を選んだエンジニアに声をかけてください。「この章の考え方を実際のプロジェクトでこう使った」など、本を介した「雑談」はカンファレンスの廊下での立ち話と同じくらい価値があると思っています。セッションの合間の休憩に、コーヒーを片手に気軽に立ち寄れる場所を目指しています。私の一冊: APIデザインケーススタディ私が選んだのは田中哲さんの「APIデザインケーススタディ ――Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方」です。Ruby の標準ライブラリの API がなぜあのような設計になっているのか、どのような問題意識から現在の形に至ったのかを、実例をもとに解説した本です。私自身が Ruby の標準ライブラリや default/bundled gem のメンテナンスをする中で、この本で紹介されている設計判断の背景に何度も立ち返っています。田中さんが開発者会議の際に「この視点にはユーザーにどのようなコードを書かせたいか、という点が足りないですね」というようなコメントをされていて、その内容を聞いて真っ先にこの本が思い浮かびました。それくらい、API デザインの背景にある問題意識や設計判断を理解することは、API を作る際に重要なことだと思っています。本屋さんとのコラボ今回の企画では、展示する書籍の調達の多くを笹田さんの本屋さんにお願いしています。Ruby のイベントで定番となりつつある本屋さんとのコラボです。カンファレンスという場で本に出会い、良いと思ったら本屋さんで買う、という流れを作りたいと考えました。展示している本の中で気に入ったものがあれば、ぜひ本屋さんで購入してください。本のプレゼント企画立ち読み喫茶では、会期中の毎日、本のプレゼント企画を実施します。ランチの受け取りやブースへの立ち寄りの際に応募券を配布するので、必要事項を記入の上ブースにある応募箱に投函してください。毎日午後の休憩時間に若干名へ展示していた書籍をそのままお渡しします。カンファレンスの記念として手元に置いていただけると嬉しいですし、もし著者が会場にいたらサインをもらうチャンスです。著者と直接話ができるのもカンファレンスならではの体験なので、ぜひ交流のきっかけにしてください。まとめ私が本を読むのは、頭の中にインデックスを作るためです。「問」と「解」の両方を手早く引けるようにしておくことを大事にしています。生成 AI が何でも答えてくれる時代であっても、適切な問いを与えるには自分の中にインデックスがなければなりません。技術書はそのインデックスを作るための最も効率的な手段の一つだと考えています。立ち読み喫茶で本を手に取り、気になるページを読み、その本を選んだエンジニアと語り、気に入ったら本屋さんで買って帰る。本のプレゼントに当選したら、ぜひ会場にいる著者を捕まえてサインをもらってください。カンファレンスで手に入れた本は、セッションの記憶と一緒にずっと本棚に残ります。 RubyKaigi 2026 のアンドパッドブースで、あなたのお気に入りの一冊を見つけてください。会場でお待ちしています。

Ruby
技術書

ANDPAD·2026/04/07

アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(後編)

こんにちは Ruby コミッタの hsbt です。4月に入って RubyKaigi... もありますがバラのシュートが順調に成長してきて函館に行っている最中に開花しないでくれ〜と祈りつつ、5月の満開に向けて毎日手入れをする日々が続いています。さて、この記事では id:sezemi によるアンドパッドのスポンサー内容紹介の後編として、Drinks and Local Meals について紹介したいと思います。 RubyKaigi 2026 に参加する Rubyist の皆さん、必見です(2回目)。 tech.andpad.co.jp Drinks and Local Meals のメニュー大公開 ! アンドパッドは前年、愛媛・松山の "みかんジュース蛇口" や入れたてのコーヒーを Drinks スポンサーとして提供して大変好評いただけました。そこで今年はドリンクだけではなくランチも!とさらに拡張して Drinks and Local Meals という、北海道・函館のご当地のドリンクに加えて、ご当地ランチも提供します！ https://rubykaigi.org/2026/sponsors/ より引用 Local Meals はラッキーピエロのバーガーセット、いかめし阿部商店のいかめし弁当、ハセストのやきとり弁当を日替わりで提供会場近くにあまり飲食店がないとの情報もあり、今回、アンドパッドからは函館の美味しいご飯を日替わりランチとして毎日 400 食提供します！もちろんアンドパッドだけでなく RubyKaigi Team もお弁当を用意されているので、昼食難民にはならないと思います。補足として、アンドパッドの日替わりランチのメニューを見て、北海道出身の hsbt も素朴に食べたいと言ってくれた自信メニューなので、ぜひご賞味あれ。 hsbt のワンポイントコメント: 函館来たら食べてもらいたい!というメニューはたくさんあれど、ホテルと RubyKaigi の会場を往復する日々だとなかなか食べにいくのは大変です。それなら会場で食べられるようにすればいいのでは、と考えてランチ提供として発注できないかを検討したところ、いずれのお店も手配するルートがあり、実現できることになりました。どれも函館の定番の味で、地元民も大好きなメニューなので、ぜひ3食コンプリートしていただきたいです。 Day1: ラッキーピエロチャイニーズチキンバーガーセット函館といえば、ご当地ハンバーガーとして大人気のラッキーピエロさん。その中でも定番のチャイニーズチキンバーガーセットが Day1 に登場です。初日から皆さんの胃袋をつかみにいきますよ。ちなみにセットでついてくるラッキーガラナと、北海道名物コアップガラナ、どっちがどっちか飲み比べする謎企画があるかも !? hsbt の函館旅行記の写真より hsbt のワンポイントコメント: ラッキーピエロは函館を中心に展開する地元民に愛されるハンバーガーショップです。ハンバーガーだけではなく、カレーライスなど日常使いのお店なのですが今回は定番中の定番のチャイニーズチキンバーガーを用意しました。ラッキーピエロの看板メニューの甘辛いタレに漬け込んだ鶏肉を揚げたものが挟まれたハンバーガーと北海道のソウルドリンク、ガラナの独自ブランドラッキーガラナをぜひご賞味ください。 Day2: いかめし阿部商店のいかめし弁当昭和 16 年に生まれた北海道函館本線森駅の名物駅弁として、長年愛されているお弁当です。国内最大級の駅弁大会とも言われる、京王百貨店が発表している「元祖有名駅弁と全国うまいもの大会」で 50 年連続売上 1 位を記録したとのことで、書いている私もワクワクしてしまいます。パッケージもいい hsbt のワンポイントコメント: いかめしは、厳密には函館、ではなく少し北にある森町の名物です。イカの旨味ともち米の食感が絶妙なバランスで、地元民も大好きなメニューです。私も上野や日本橋の百貨店で定期的に開催される北海道物産展に行ってはいかめしを買って食べています。刺身として食べるイカとは違うやみつきになる風味をぜひ味わってみてください。 Day3: ハセストのやきとり弁当こちらは地元民の皆さんに人気のコンビニエンスストア、ハセガワストア (通称、ハセスト) さんの名物弁当です。ハセストの店舗にドドーンとある (hsbt の函館旅行記の写真より) 一番の驚きポイントは「やきとり」なのに使われているのは豚肉なところです。厳しい寒さ対策のため、スタミナがつく豚肉が好まれたからだとか。やきとりと言われると、焼き鳥の味を思い出しますが、どんな味になるのでしょうか？書いていると、ワクワクどころか、お腹が減ってきました ... 。お腹が減る写真です hsbt のワンポイントコメント: 焼き鳥!といえば豚肉だろう、という室蘭で育ったのでハセストのやきとり弁当でも豚肉だったのは何も違和感がなかったのですが、改めて考えてみると豚肉?ってなってしまいました。北海道のコンビニといえばセイコーマートことセコマもあり、店舗ごとに調理をしてお弁当を販売しているのが特徴なのですが、ハセストも同様に店舗で注文をしてから焼き鳥を焼くという調理をしています。今回はランチの提供のため、焼きたての焼き鳥を提供することはできないのですが、タレ味の焼き鳥と次に紹介する北海道のサイダー、ナポリンの組み合わせは最高なので、ぜひご賞味ください。 Drinks はコーヒーとご当地ドリンクを提供前年好評だったご当地ドリンク (Cold) を合計 900 本、コーヒー (Hot) 900 杯を今年も提供します ! Cold Drinks は北海道で生まれた様々なドリンクから 3 つを選びました。ランチのお供にぜひご賞味ください。 Cold Drinks はコアップガラナ、 Ribbon ナポリン、雪印ソフトカツゲンの 3 種を提供コアップガラナは地元民が愛する炭酸飲料です。コーラに似た見た目ながら、ブラジル産ガラナの実から抽出された独特の苦味とフルーティーな香りが特徴です。コーラとの違いもさることながら、ガラナにも複数種類があるので、先程ランチで挙げたラッキーガラナで飲み比べてみましょう！コーラじゃないよガラナだよ Ribbon ナポリンは、なんと 1911 年誕生の炭酸飲料です。誕生以来、北の大地で愛され続けている超ロングセラーの定番サイダーで、どこか懐かしい、やさしい甘さと爽やかなのどごしが魅力です。 Day3 の「やきとり弁当」のタレ味との相性もバッチリです。中身もオレンジ色で植物由来の天然着色料を使用北海道といえば乳製品の宝庫です。雪印ソフトカツゲンも歴史ある乳酸菌飲料で、まろやかでコクがあるのに、後味はスッキリです。その名の通り「活力の源（カツゲン）」として親しまれています。トークの圧倒的な情報量を消化するのに疲れた頭にとても効きます！こちらはパックなので持ち歩きと飲むときに注意が必要です hsbt のワンポイントコメント: 北海道のご当地ドリンク3つは、八重洲の地下にある北海道フーディストで購入することができ、私もカツゲンは定期的に買って補充したり、ガラナはなんなら通販で箱買いして風呂上がりやジンギスカンを食べながら飲んでいます。ぜひこの機会に味わってみて、ご当地ドリンク沼にハマっていただければと思います。 Hot Drinks は函館で評判の HOTEIYA さんがやってきますアンドパッドは「現場の施工管理アプリ」から成長した会社なので、「現場」にこだわっております。現場といえばコーヒーですよね。愛媛・松山でも地元のコーヒー屋さんにお越しいただきましたが、函館でも地元で評判のコーヒー屋さん HOTEIYA さんをお呼びしました。実は RubyKaigi 2026 のローカルオーガナイザーである Chris Salzberg (@shioyama) から、ぜひ Rubyist に HOTEIYA さんのコーヒー、特にエスプレッソを味わって欲しいとのリクエストをいただいたことから実現しました。 Chris さん、ありがとうございます！提供するコーヒーは全部で 4 種です。フィルターコーヒーラテアメリカーノエスプレッソ 1 日 300 杯で合計 900 杯を提供します。 HOTEIYA さんのメニューまとめアンドパッドが RubyKaigi 2026 で提供する、 Drinks and Local Meals の内容をお知らせしました。コーヒーを除き、3日間それぞれ違うメニューを提供するので、ぜひ全種類制覇してみてくださいね。ちなみに、ランチは 400 食、ドリンクは 300 本/杯を毎日提供する予定ですが、毎日全食配布したい!という意気込みで用意しているので、ランチタイムでは配布エリアの一番奥のアンドパッドテーブルへお越しください。今回の記事では、Drinks and Local Meals の内容を紹介しましたが、次回はブースやランチ&ブース連動企画についてご紹介します。引き続き続報をお待ちください。

Ruby

ANDPAD·2026/04/03

アンドパッドは RubyKaigi 2026 で Ruby Sponsor として Drinks and Local Meals と Drinkup を提供します(前編)

Hello, Rubyist ! id:sezemi です。先日社内の RubyKaigi 2026 の参加者を集めて 30 分のキックオフをしたところ、ブースやカスタムスポンサーの内容を説明するだけで 30 分話してしまいました。盛り沢山すぎる ... 。さて、昨日 4/2 に開催された Omotesando.rb #120 でアンドパッドは会場スポンサーを務めました。 Omotesando.rb の皆さま、ご来場 and いい時間をありがとうございました ! そこで会場スポンサー LT をしたのですが、 RubyKaigi 2026 でアンドパッドがカスタムスポンサーをする Drinks and Local Meals と Drinkup を紹介しました。この記事ではその内容を改めて前編 (Drinkup) と後編 (Drinks and Local Meals) に分けて記事にしてお届けします。 RubyKaigi 2026 に参加する Rubyist の皆さん、必見です。 figure{text-align: center} Drinkup は恒例の前夜祭とコード懇親会の 2 つを開催しますアンドパッドが開催する Drinkup は 2024 年の沖縄・那覇からスタートし、前夜祭とコード懇親会を開催してきました。そして、もちろん、今年も前夜祭とコード懇親会を開催します。 https://rubykaigi.org/2026/sponsors/ より引用 RubyKaigi 2026 前夜祭 ANDPAD Welcome Drinkup 前夜祭の今回のお店は地元家函館本店です。さぁ、「地元家」さんは何と呼ぶのでしょうか？ ...... 答えは「じもとげ」さんです！ (じもとやさんの間違いでした。大変失礼いたしました) お店の選考の最終候補で 2 店に絞られたのですが、アンドパッドに在籍している北海道出身の Rubyist から「ぜひ函館に来るなら一度は "活イカ (かついか)" を皆さんに食べていただきたい！」という一言で地元家さんに決まりました。活イカと聞いただけで、食欲がそそられます。完全にお腹が減りました。 hsbt からのワンポイントコメント: 函館ではヤリイカとスルメイカの2種類があり、4月はヤリイカの旬の時期です。スルメイカはここ数年収穫量が安定しない状況が続いていましたが、2026 年のヤリイカは大丈夫そうです。ヤリイカは5月には漁が終わってしまうので、4月下旬の函館という時期は食べ納めとして絶好のタイミングです。今回の前夜祭は、地元家さんの最高級ランクである「極新選組コース」を提供します。料理の内容は以下の通りです。美味堪能！地元家最高級ランクでおもてなし【極新選組コース】季節の先付け 1 点季節の前菜盛り 5 点盛り合わせ本日の市場からのお刺身盛り合わせ 7 点道産牛朴葉味噌焼き季節の一品料理国産牛すじ煮込み季節の土鍋ご飯 or 炊き込みご飯棒寿司料理のイメージ前夜から RubyKaigi 2026 を盛り上げていきましょう！申込は connpass のページで 4/6 10:00 から受付開始です。コード懇親会/Code Party(Social Coding) at RubyKaigi 2026 コード懇親会とは、お酒とお食事を肴に懇親する会ではなく、コードを肴に懇親しよう、という会です。とはいえ、夕食時なので、キーボードフレンドリーなお食事とソフトドリンクを用意しています（もちろん北海道・函館のローカルフードです）。ご安心ください。そんなコード懇親会は毎年アップデートをしているのですが、前年の課題の一つに挙げられたのが、場所の狭さと Wi-Fi 環境でした。今回はそういったことが起こらないよう、早めに場所を探していたところ、ちょうど函館アリーナと函館市民会館に、 100 名ぐらいが入れそうな会議室を発見。 RubyKaigi Team に確認したところ、函館市民会館で Wi-Fi 付きで貸出 OK となったのでした。会場の近さはもちろん、 Wi-Fi 問題はなかなか準備が大変なので、とても助かりました。 Team の皆さまには改めて御礼を申し上げます。というわけで、 rubykaigiC の隣のお部屋なので、もはや RubyKaigi 2026 の会場内と言っても差し支えないでしょう。お待ちしております。そして、肝心のコンテンツは ... 今年も豪華なテーマが揃いました。 Theme 1: dRuby by seki Theme 2: Ruby by shugo Theme 3: RubyGems/Bundler by hsbt Theme 4: mruby/PicoRuby by PicoPicoRuby, hasumikin and matz Theme 5: Ruby x Rust by udzura and ahogappa dRuby は前年もワークショップの感動から、 seki さん dRuby フリークが新たに誕生していたので、今年も楽しみですね。そして、こちらも継続となる RubyGems/Bundler では、前年 hsbt さんに見守られながら、初めて Gem を公開した方がいらっしゃるなど、今年も胸熱エピソードが生まれる予感です。 hsbt からのワンポイントコメント: 今年も RubyGems と Bundler のテーマを用意しました。Gem を公開したい、にとどまらず RubyGems や Bundler にこういう機能が欲しいであるとか、こうなってもらいたいなどのディスカッションのレベルからも歓迎します。ぜひ RubyGems や Bundler に興味がある方はお越しください。同じく前年からの継続となるものの、中身がちょっと変わるのが Ruby 本体と mruby/PicoRuby です。 Ruby 本体は新しく shugo maeda さんにテーマオーナーを引き受けていただきました。ありがとうございます！なかなかハードルが高いと思われがちですが、 String や Integer などの組み込みクラスにメソッドを追加するくらいであれば、少し C 言語の知識があれば意外と簡単にできますので、お気軽にご参加ください！ということなので、 RubyKaigi で高まった Ruby 愛をもとにコントリビュートしてみましょう。そして mruby/PicoRuby です。そう、今年も Matz さんが来てくれます！それだけでなく様々な Ruby のカンファレンスで話題になっている PicoRuby ですが、 PicoRuby 未経験の方も経験者の方もどちらも楽しく懇親できるはずです！未経験の方でも、 PicoRuby でワイワイ自作のデバイスを作っているコミュニティ、 PicoPicoRuby の面々のサポートもあるので、デビューする環境としてはバッチリです！ただし、事前に PicoRuby が動くデバイスを準備しておく必要があることに注意してください。デバイスの準備の仕方は PicoRuby デバイス準備ガイドを参考にしてください！最後に今年から初めて生まれたテーマが Rust です！ ruby-jp の Slack ワークスペースにある #rubykaigi チャンネルで kou さんがコード懇親会の新テーマを募集したところ、即座に手を挙げていただいたのが udzura さんでした。　ありがたい限りです。 Rust は初めて、という方も udzura さんの解説に加えて、触ってみるコースがあったり、経験者には Rust で Gem をつくるというコースがあったりと、なかなか幅広い方を対象に楽しめるテーマ内容になっていますので、 Rust に興味がある、という方はとてもオススメです！申込は connpass のページで、こちらも 4/6 10:00 から受付開始です。まとめアンドパッドが RubyKaigi 2026 で提供するコンテンツの中から Drinkup の内容をお知らせしました。後編 (Drinks and Local Meals) の内容もですが、アンドパッドから登壇するトークの紹介、さらにスポンサーブースでの催しもあり、まだまだ RubyKaigi 2026 を盛り上げるものがあります！ RubyKaigi 月間として、テックブログでこれから記事を公開しますので、ぜひお楽しみに。では、まずは 4/6 から前夜祭とコード懇親会の申込が開始されますので、申込をお待ちしております！

Ruby
Rust

ANDPAD·2026/04/02

アンドパッドのCREがTamachi.sre#3で発表してきました！

アンドパッドCREチームの島根です。 2026/03/19（木）に開催されたTamachi.sre#3に登壇者の1人として「極端に遅いリクエストとの戦い」というタイトルで発表させて頂きました。この記事では登壇した内容、現地の様子や反響などについて書いていき、アンドパッドCREチームの取り組みやTamachi.sreについて少しでも興味を持って頂ければ嬉しいです。 Tamachi.sreとは Tamachi.sreはSRE NEXTのコアスタッフである渡部さん、横山さんと、元コアスタッフで当社FinOpsチームTechLeadの吉澤さんが勤め先が3名とも田町駅近辺という共通点をキッカケに発足したSREの地域コミュニティです。 Tamachi.sre#3の会場今回は当社と同じオフィスビルに居を構えられている株式会社IVRyさんに会場を提供頂きました。ボルダリングウォールがオフィスにある光景を初めて見たので、遊び心を感じられました。発表極端に遅いリクエストが事業にどう影響するのか、なぜCREが担当すべきなのかについて発表しました。発表の様子今回の発表でも触れているDatadogを活用したリクエストの自動集計はCREチームの山本が執筆したこちらの記事で詳細を紹介していますので、覗いてみてください。発表スライド speakerdeck.com 発表で伝えたかったことサービスの規模が大きくなってくるとこのようなパフォーマンスの課題は避けられないものかと思います。パフォーマンスの課題の解決がなぜ重要なのか、そしてCREが担当することでどのようなメリットがあるのかと言う点を話しました。当社においてもより良いサービスを提供すべく改善中ではありますが、少しでも参考になれば嬉しいです。発表を通じての感想 CREとしてTamachi.sreに初めて登壇させて頂きましたが、温かい雰囲気で会場もXも盛り上げて頂き、終始とてもやり易かったです。また、自身の発表だけでなく、他社の事例やノウハウをたくさん吸収でき、とても有意義な時間・機会となりました。CREの職責は概してSREと似ていることもあるので、他社のCREの発表もTamachi.sreで見ることができれば嬉しいなと思いました。 We are hiring! アンドパッドでは「幸せを築く人を、幸せに。」というミッションを実現すべく、一緒に働く仲間を募集中です。アンドパッドのCREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。 hrmos.co

CRE
SRE
Datadog

ANDPAD·2026/03/27

アンドパッド技術イベントのご案内 2026 年 4 月

こんにちは、 id:sezemi です。子どもたちが春休みを迎え、毎日のお昼の献立に頭を悩ませています。食わず嫌いが多い子どもたち向けのナイスソリューションを渇望しております。さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。今月もイベント情報をまとめてお知らせします。ぜひご参加ください !! なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. 会場提供情報 | 【ハイブリッド開催】Omotesando.rb #120 開催日時 : 2026 年 4 月 2 日(木) 会場 : 株式会社アンドパッド東京オフィス（オンラインとのハイブリッド開催）主催 : Omotesando.rb イベント概要 : Omotesando.rb は Ruby の周辺技術に関する LT を行う地域 Rubyist コミュニティで、今回はアンドパッドが会場を提供しています。イベントでは「 RubyKaigi 直前予習会」と題して開催され、コメンテーターに Omotesando.rb メンバーの神速さん、大倉さん、 kishima さんが登場し、今年の RubyKaigi 2026 のスケジュールを見ながらみんなで予習を行います。会場では簡単なドリンクや軽食をご用意しており、有志による懇親会も予定されていますので、ぜひ気分を盛り上げていきましょう。申込方法 : イベントページからお願いいたします。【ハイブリッド開催】Omotesando.rb #120 2. イベント開催情報 | RubyKaigi 2026 前夜祭 ANDPAD Welcome Drinkup 開催日時 : 2026 年 4 月 21 日(火) 会場 : 本格海鮮居酒屋地元家函館本店主催 : アンドパッドイベント概要 : 開催前日に RubyKaigi 2026 に向けて、毎年恒例のアンドパッド主催 Welcome Drinkup を開催します。函館に前入りしている海外コミッタや Speaker、Rubyist の皆さまを招き、前夜祭として一緒に盛り上がるイベントです。会場では、市場直送のお刺身盛り合わせや道産牛朴葉味噌焼きなど、函館の名物料理が堪能できる地元家最高ランクの「極新選組コース」とお酒を無料でご用意しています。ぜひカンファレンス本編の前に楽しく交流しましょう。申込方法 : イベントページからお願いいたします。 RubyKaigi 2026 前夜祭 ANDPAD Welcome Drinkup 3. 登壇・スポンサー情報 | RubyKaigi 2026 アンドパッドは RubyKaigi 2026 に Ruby Sponsor として協賛し、ブース出展を行います。また、カンファレンス本編にてアンドパッドから 4 名の Rubyist が登壇します。登壇者とトークは以下の通りです。羽角均 (X: @hasumikin) 登壇日時・場所 : 【Day 1】10:50 - 11:20 @ Large Hall タイトル : 「Funicular: A Browser App Framework Powered by PicoRuby.WASM」プロフィール : PicoRuby と PicoRuby.wasm の作者であり、mruby と mruby/c のコミッターです。大崎瑶 (X: @youchan) 登壇日時・場所 : 【Day 1】16:00 - 16:30 @ Small Hall タイトル : 「Guide to getting started walking source codes of CRuby」プロフィール : Ruby で書かれたプレゼンテーションツール Gibier の作者であり、 Asakusa.rb, Chidoriashi.rb のメンバーです。近永智之 (X: @nagachika) 登壇日時・場所 : 【Day 2】13:30 - 14:00 @ Small Hall タイトル : 「Pure Intonation on Browser: Building a Sequencer with Ruby」プロフィール : CRuby コミッター、および CRuby 安定版ブランチメンテナを務めるサウンドプログラマワナビーです。柴田博志 (X: @hsbt) 登壇日時・場所 : 【Day 3】14:10 - 14:40 @ Large Hall タイトル : 「Ruby Releases Ruby」プロフィール : OSS プログラマ、Rubyコミッターであり、ruby、rubygems、bundler、rake、rbenv、ruby-build、psych など多数の OSS のメンテナー、そして ruby-lang.org の管理者です。 Ruby プログラミング言語の開発を支えるインフラのメンテナンスを担当しています。株式会社アンドパッドで技術広報業務に従事しながら、 Ruby プログラミング言語の OSS 開発をフルタイムで行っています。開催が近づきましたら、また Speaker から登壇の見どころや意気込みなどをテックブログで紹介しますので、ご期待ください。 4. イベント開催情報 | コード懇親会/Code Party(Social Coding) at RubyKaigi 2026 開催日時 : 2026 年 4 月 23 日(木) 18:30 ～ 21:15 会場 : 函館市民会館 3F 大会議室主催 : アンドパッドイベント概要 : お酒を飲みながら話す一般的な懇親会とは異なり、「参加者同士が一緒にコードを書きながら交流する」という全く新しいスタイルの懇親会です。今年は好評だった「オススメテーマ」に特化し、dRuby、Ruby本体、RubyGems/Bundler、mruby/PicoRuby、Ruby x Rustの5つのテーマで、それぞれ詳しいエキスパートと共に深くコードで懇親できます。RubyのパパであるMatzさんも参加予定です！Day2終了後にそのまま会場へお越しいただけるよう、簡単な軽食とノンアルコールドリンクをご用意してお待ちしております。申込方法 : イベントページからお願いいたします。コード懇親会/Code Party(Social Coding) at RubyKaigi 2026 RubyKaigi 2026 一色の開催となりますが、興味のあるイベントがございましたら、ぜひご参加ください !! アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。広報の経験がない方でも Welcome です！カジュアル面談やご応募、お待ちしております。 hrmos.co