アンドパッド 技術イベントのご案内 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
- モバイルアプリ
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
浮いたボールを拾いまくったらトイルを改善していた話
こんにちは。 サービスプラットフォーム部 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
- 自動化
アンドパッドの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
アンドパッド 技術イベントのご案内 2026 年 3 月
こんにちは、 id:sezemi です。 小 3 の娘がガチャガチャ (いまはカプセルトイというのが主流 ...) にハマっており、その中でも "こめちゅあ" を集めています。 ただハマったのが最近で、いま出ている vol.2 より、 vol.1 に夢中になっていて、収集が難しくなっております。 もし「こめちゅあ vol.1 がココにあるよ！」という情報があれば、こそっと X でメンションいただけると、とても喜びます。 さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。毎月、イベント情報をまとめてお知らせしています。ぜひご参加ください !! また今回は前月 2 月の開催レポートもお知らせします。 なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. 登壇情報 | Road to SRE NEXT 2026 @福岡 開催日時 : 2026年3月13日(金) 会場 : 株式会社アンドパッド 主催 : 株式会社Fusic オープンオフィス イベント概要 : SRE の普及・発展を目指すカンファレンス「SRE NEXT」のプレイベントです。 申込方法 : イベントページからお願いいたします。 https://sre-lounge.connpass.com/event/382311/sre-lounge.connpass.com 本イベントにて 谷合 純也 が登壇予定です。 谷合 純也 @jnytnai0530 2025 年 11 月入社。現職ではマルチプロダクトを横断的に支援する SRE チームに所属。トイルの自動化や様々な仕組みづくりに関心があります。ｱｻﾋｨｽｩﾊﾟｧﾄﾞｩﾙｧｧｧｧｲが好きなエンジニア。 谷合 純也 のテックブログ執筆記事 アンドパッドのSRE・DBRE・CRE：2025年の活動ハイライト 発表タイトル: SRE がやりたい仕事に集中するための処方箋 SRE が本来の職務であるサイト信頼性や自動化に集中できず、 DB 相談やアカウント発行などの「便利屋化」する現状があります。 本発表ではアンドパッドの事例を元に、「やらないこと」を明確にして解決するプラクティスをご紹介します。 2. 登壇・会場提供情報 | Security.any #09 卒業したいセキュリティLT 開催日時 : 2026年3月19日(木) 会場 : 株式会社アンドパッド 主催 : Security.any イベント概要 : Security.any が主催するイベント「Security.any #09 卒業したいセキュリティLT」が開催されます。 申込方法 : イベントページからお願いいたします。 https://security-any.connpass.com/event/382763/security-any.connpass.com 本イベントにて、アンドパッドが会場提供を行うほか、 Kiyotaka Ginoza が登壇予定です。 Kiyotaka Ginoza @kiyogino 派遣エンジニア企業にてインフラエンジニアとして勤務したのち、 2020 年 6 月にアンドパッドに入社。 SRE として運用やセキュリティの課題に数年取り組み、 2024 年からセキュリティチームのテックリードに就任。 趣味は読書、サッカー観戦。 Kiyotaka Ginoza のテックブログ執筆記事 アンドパッドセキュリティチーム 初のチーム合宿を開催！ 3. 登壇情報 | Tamachi.sre#3 開催日時 : 2026年3月19日(木) 会場 : 株式会社IVRy オフィス 主催 : Tamachi.sre イベント概要 : Tamachi.sre は田町らへんでやる SRE のオフライン勉強会です。 SRE のテーマであれば、何でも発表は OK のイベントです。 申込方法 : イベントページからお願いいたします。 https://tamachi-sre.connpass.com/event/381960/tamachi-sre.connpass.com 本イベントにて、アンドパッドが 島根 雄也 が登壇予定です。 島根 雄也 @YEngine8 新卒で百貨店に総合職として入社。 2018 年にラクスにテクニカルサポートとして入社し、 IT 業界へ。 2021 年 10 月、アンドパッドに CRE として入社。 島根 雄也 のテックブログ執筆記事 SRE Kaigi 2025 でアンドパッドCREチームの5年史を発表しました 2026 年 2 月の開催レポート ここからは先月に開催されたイベント・カンファレンス等のレポートです。 1. Go Conference mini in Sendai 2026 非公式 前夜祭 日時 : 2026年2月20日(金) 会場 : enspace 5B1 主催 : アンドパッド 当日のタイムライン: #sendaigo 予定されていた前夜祭が急遽中止となった関係で、非公式ながらアンドパッドが前夜祭を開催しました。 告知が急だったにも関わらず、熱心な Gopher が集まり、定員 40 名満席となりました。 ご参加いただいた皆さま、ありがとうございました ! そこで #golang_friends という、 Ruby コミュニティでカンファレンスで出会った方と仲良く写真を撮って、友だちになる #rubyfriends をオマージュしたハッシュタグを提案したのですが、いくつか写真が投稿されており、胸熱でした。 今後、広まることを願っております。 また当日のプログラムの 1 つ、座談会形式でタイムテーブルを眺めた予習会では、急遽声がけしたにも関わらず、二つ返事で OK いただいた tenntenn さん、 sivchari さんに出演いただきました。 ありがとうございました ! お陰様で、沢山の方に喜んでいただけたようでした。 前夜祭を取り上げていただいた参加レポート ujiprog.com sago35.hatenablog.com 2. 登壇情報 | Go Conference mini in Sendai 2026 日時 : 2026年2月21日(土) 会場 : アーバンネット仙台中央 カンファレンスルーム 主催 : Sendai.go 当日のタイムライン: #sendaigo 通常は 1 トラックでの開催が多い Go Conference mini ですが、今回は 2 トラック構成で多彩なトークが行われ、アンドパッドからも 小島 夏海、sunecosuri が登壇しました。 なお、 Go Conference mini in Sendai 2026 については別途、テックブログで参加・協賛レポート記事を近日公開します。 ぜひご期待ください。 3. Go 1.26 リリースパーティ 日時 : 2026年2月25日(水) 会場 : 株式会社アンドパッド 主催 : Gophers Japan 当日のタイムライン: #go126party 定期開催されている Go の新しいバージョンのリリースを祝うパーティです。 1.26 で入った様々な新機能を紹介いただきました。 アンドパッドは会場提供を行ったほか、 tomtwinkle が「米国のサイバーセキュリティタイムラインと見る Go の進化」というタイトルで登壇しました。 私も配信を担当しながらトークを聞いていたのですが、 arthur1 さんのトーク「go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ」で、 Go 1.26 が出たのに、 Go 1.25 で入った機能を喜ぶ、というお話がとても印象に残りました。 1.26 がリリースされると、ビルドに要求されるバージョンを定義する go directive まで 1.26.0 に上がってしまい、まだ公式のサポート期間内であるはずの Go 1.25 を使っているユーザー環境に対して、予期せぬツールチェーンの更新を強いてしまったり、特定の環境下でビルドが通らなくなってしまったりします。 また、その他、パッチのバージョンによってはまだバグが残存していたり、セキュリティ修正が必要だったりするケースがあり、あえて 1 つ前のバージョンを使いたいケースもありますが、これも出来ません。 なかなか使う側にとってもツライ話ですし、 OSS 作者にとっては最新版への速やかな追従を強制されるので、なかなか負担が大きいですね。 この現状を変える proposal が通ることを願っています。 4. 福岡Rubyist会議05 スポンサー 日時 : 2026年2月28日(土) 10:00–18:00 会場 : リファレンス駅東ビル 3 階 会議室H-2 主催 : Fukuoka.rb 当日のタイムライン: #fukuokark05 「最近、何してる？」をテーマに開催されました。 アンドパッドは スポンサー として協賛し、ブースを出展したほか、 hsbt によるスポンサートークも行いました。 ブースでは、アンドパッドの「最近、何してる？」としてプロダクト本部・開発本部における AI 活用状況を紹介しました。 同じようにブース来場者の方にも同じアンケートを実施したところ、アンドパッドの活用状況と、ほぼ同じような傾向が見られたことが発見でした。 現在の業務で AI に渡したいと感じる負担が大きい作業はどれですか？ という質問の回答として、既存コード（他人が書いたコード）の読解・調査 が一番でした スポンサートークでは hsbt が主にアンドパッドの会社紹介・業界説明をしました。 エンタープライズなお客様での利用が増えていることに驚かれたり、福岡にアンドパッドの支社があるのは知らなかったなど、いい反響をいただきました。 興味を持たれた方はぜひアンドパッド福岡オフィスでお会いしましょう ! また、トークでは こしば家 による「ふつうの Rubyist、ちいさなデバイス、大きな一年」では Tiny デバイスを使ったデモを披露されるなど、とても賑やかなトークがあったほか、「Rubyist としてアメリカで 10 年戦ったらどうなったか」では登壇された Jugyo さんが、長年勤めた会社をレイオフされても Ruby/Rails を使っていたことで新しい会社に転職できた、という、いいお話を披露されるなど、テックトーク / ソフトトークどちらも織り交ぜたタイムテーブルで、とても楽しかったです ! 参加された皆さま、登壇された皆さま、そして 福岡Rubyist会議05 Team の皆さま、ありがとうございました !! まとめ 採用広報から 3 月に開催されるイベント予告と、 2 月の開催レポートをお届けしました。 またイベントやカンファレンスでお会いできることを楽しみにしています ! また、アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。 広報の経験がない方でも Welcome です！ カジュアル面談やご応募、お待ちしております。 hrmos.co
- SRE
- セキュリティ
- Go
- Ruby