はじめに こんにちは！スタメンでエンジニアをしている hisa です。 2025年5月23日・24日に東京・ベルサール神田で開催された TSKaigi 2025 に、両日現地参加してきました！ 今回は、イベントの雰囲気やセッションでの学び、参加者との交流などを中心に振り返っていきたいと思います。 ちなみにスタメンは今回のTSKaigiに Goldスポンサー として協賛し、当日はブース出展も行いました！ スタメンでは主力事業のTUNAGやグループ事業のWatchyで幅広くTypeScriptを活用しています。 フロントエンドのみならず、バックエンドやReactNativeでのモバイルアプリ開発など幅広い技術領域でTypeScriptによるプロダクト開発を行なっています。 こうした開発を通じて、私たちもTypeScriptコミュニティの多くの知見に支えられてきました。これからも一緒にコミュニティを盛り上げていきたいと思い、「TSKaigi 2025」に協賛させていただきました！ 【スポンサーブース紹介】 @stmn_eng さんのブースです #TSKaigi #TSKaigi2025 pic.twitter.com/7kgCYAH7Qn — TSKaigi (@tskaigi) 2025年5月24日 会場の雰囲気と盛り上がり 会場となったベルサール神田には、全国からTypeScript好きなエンジニアが集まり、朝からかなりの盛り上がり。 企業スポンサーはなんと 61社 にも及び、セッション会場もブースエリアも人であふれていて、TypeScriptコミュニティの熱量を肌で感じることができました。 セッションの人気具合はすさまじく、立ち見や通路で聞く方も多く、「TypeScriptってこんなに人を集めるテーマになってるのか…！」と改めて実感しました。 朝ヨガイベントも開催しました 今回スタメンとして初めて、自社主催のサイドイベント「 朝YOGA 」をTSKaigi Day1の朝に開催しました！ 会場は弊社東京オフィスにて、ヨガインストラクターの方をお招きし、カンファレンス前に体と気持ちを整える時間を提供しました。 「ヨガ未経験でもOK」「会話だけの参加もOK」という、ゆるやかなスタイルだったこともあり、朝から和やかで温かい雰囲気のイベントになりました！ 改めてご参加ただいた皆様、ありがとうございました！ スポンサー企業ブース巡り 会場2フロアに広がるスポンサーエリアには、 19社 のブースがずらり。 各社それぞれ工夫を凝らした企画が並び、TypeScriptの型クイズやノベルティ配布、ステッカー交換、軽食コーナーまで、終始わいわいとした雰囲気でした。 スタメンのブースでは、社内プロダクト「TUNAG（ツナグ）」の 抽選機能 を使った体験企画を実施！ 来場者の方にその場で抽選にチャレンジしてもらい、当たった方にはAnker製のグッズをプレゼント🎁 また、参加者全員にオリジナルステッカーもお渡ししました！ さらに今回は、TypeScriptの知識を試せる「型クイズ」や、「このコードどうレビューする？」というレビュー力を問う展示コンテンツもご用意しました。 「考えるのが楽しかった」「同僚と一緒に盛り上がれた！」といった声も多くいただき、ブース担当としてとても嬉しい時間でした。 改めて、ブースにお立ち寄りいただいた皆さま、参加いただいた皆さま、本当にありがとうございました！ 📑今日の問題の答えを発表します📢 エラーが出るのは画像の部分🔍 動的に決められている型だと どのPropsにも該当しないからです✨ みなさん解けましたか👀？ ご参加くださった皆さん、ありがとうございました🙌 明日も面白い問題を用意しているので挑戦してみてください🔥 #TSKaigi #TSKaigi2025 pic.twitter.com/9BYz8PJnTH — stmn, inc. Developers (@stmn_eng) 2025年5月23日 参加者交流の様子 イベント中は、セッションの合間やランチ時間、コーヒーブレイク中などに、自然と参加者同士の交流が生まれていました。 技術の話から日々の課題感、会社での開発体制まで、ゆるくも濃い会話が交わされていて、参加者の温度感の高さを実感。 個人的に印象深かったのは、Day1終了後に開催された「ダイニーさん主催のドリンクアップ」 に参加させてもらったことです。 セッションでは話しきれなかったテーマを深堀りしたり、登壇者や他社エンジニアの方とフラットに意見交換ができたりと、技術者同士のリアルなつながりを感じる時間になりました。 Day2の夜には、公式の懇親会も実施され、こちらもかなりの盛り上がり！ 「来年は登壇してみたいですね」「運営やってみたい！」「チームに持ち帰って共有します！」といった声も多く聞かれ、TypeScriptという共通言語で広がるコミュニティの温かさを改めて感じました。 セッションで得られた学び 全体的に実践知の詰まったセッションが多く、ここでは特に印象に残ったテーマをいくつかピックアップして紹介します。 AI × TypeScriptの可能性 複数のセッションで触れられていたのが、 LLM（大規模言語モデル）とTypeScriptの協調 について。 例えば： 型定義を自然言語から自動生成 型に基づいたモックデータの自動作成 zod のようなスキーマベースの型をLLMで組み立てる といった例が紹介されており、「AIの出力に型で 枠 を与える」設計思想に非常に納得感がありました。 今後AIと人間の役割分担が変わっていく中で、 型がその橋渡しになる という視点は、まさにTypeScriptだからこそ生まれる展望だと感じました。 ツールチェーンの進化と型安全性の向上 TypeScript Language Service Plugin の活用例も非常に印象的でした。 ESLintでは拾えない文脈依存の型ミスを検知 型情報をもとに独自ルールで静的解析 ts-morphを使ったコードの自動生成 など、 型そのものをツールに組み込んでチームの開発体験を最適化していく取り組み が紹介されていました。 現場でもすぐ使えそうな知見が多く、特に「共通型からクライアントとAPIの両方を自動生成する」設計にはかなり興味を惹かれました！ TypeScript Native Preview カンファレンス当日に発表された、 TypeScript NativeのPreview 。 これは、tscを通さずそのままTypeScriptを実行できるという話で、会場中がざわついていたトピックのひとつでした。 まだ技術的な細部はこれからのようですが、「ビルドレスなTypeScriptの未来」が示されたことは非常に刺激的で、セッション外でも話題に事欠かない内容でした。 セッション外でも学びはある イベントの中で、セッション以外の場所――廊下、ブース、懇親会、ドリンクアップ――などの何気ない会話の中にも学びのタネがたくさんありました。 「このライブラリってどうやって導入してる？」「デザイナーと型どうやって擦り合わせてる？」といった日常の悩みこそ、リアルな現場感があって、実は一番ありがたかったりします。 さいごに 2日間にわたって開催されたTSKaigi 2025は、TypeScriptを軸にした技術・人・文化が交差する、非常に濃密な時間でした。 オンラインで得る情報だけでは得られない、空気の濃さや熱量を、肌で感じられたのが一番の収穫です。 今回、スタメンはGoldスポンサーとしてブースも出展していましたが、「プロダクトを作っているチームの雰囲気」や「弊社プロダクト TUNAG の魅力」が参加者の方々に伝わったなら嬉しいです。 登壇者、運営、参加者のみなさん、そしてブースで交流してくださった方々、本当にありがとうございました！ また来年、どこかでお会いできることを楽しみにしています！ スタメンでは、エンジニアを絶賛募集中です🙌 herp.careers 参考：エンジニアのカジュアル面談Q&Aから見るスタメンの姿 note.com

みなさんこんにちは！はじめまして！ プロダクト開発部でプロダクトマネージャーをしている 山本 です。 先日、5/19(月)にオンラインで開催されたPdMイベント「 【一人PM経験者Night】一人PMの経験に学ぶ、プロダクト&組織成長のリアル 」にて「1人PdMの立ち回りとマインド、 価値発揮するために取り組んできたこと」というタイトルで発表をしました。 私自身、社外での登壇は初めてということもあったのでテックブログでも公開してみることにしました！！ 登壇した資料については X やSpeakerDeckで公開していますのでそちらもぜひみていただけたら幸いです⭐️ はじめに イベントタイトルにもある通り「1人PM経験」から当時どんなことをしてきたのか、どのようにその期間を乗り越えてきたのかなどを、「立ち回り」・「マインド」・「価値発揮」の観点から、リアルな取り組み例を交えて、新卒PdM視点でお話しました。 目次 1人PdMとして「どう価値を出すか」 1人PdMだからこその「苦労と試行錯誤」 1人PdMとしての「自分とマインドの在り方」 まとめ 01_1人PdMとして「どう価値を出すか」 PdMとしての役割が広すぎて途方に暮れそうになった時、私が意識していたのは「スピード」と「先回り」です。 特に、1人PdMの環境では、 そもそも組織やプロセスが確立されていないことが多く、開発メンバーや他部署との役割分担ができていなく、すべて自分にメンションが集中したり、逆に色々な場面でボールが落ちまくっていることが多くあると思います。 そんな環境の中で私は、1人PdMとして社内で価値発揮するために 「プロダクトを一番理解している人になり、スピード重視でアウトプットを出す」 ことを徹底してきました。 実際にどんな取り組みをしたのかというと、 「たたき」で手戻りをなくす ことと 「ステークホルダーに合わせて先回りの情報共有」 をしました。 🌟「たたき」で手戻りをなくす 仕様書（PRD）を作る前に、まず手書きのラフやカスタマージャーニーマップを描いて、関係者と「そもそも、これって何のためだっけ？」という目的のすり合わせ、5W1Hを用いてユーザーストーリーの洗い出しを徹底しました。 このひと手間で認識のズレがなくなり、その後の開発がスムーズに進みました。 結果的に、CPOとの合意形成レビューでの手戻りもほぼゼロになりました✨️ 仕様検討時に課題や構想を図解化 🌟「ステークホルダーに合わせて先回りの情報共有」 企画を進めるうえで多くの関係者がいる中で、その人たちの話し方や注目ポイントがどこかを吸収しながら、「この人には図を見せながら」「この人には要点から」と、相手に合わせて説明の仕方を変えてみました。 結果的に、相手が気にしそうなことを先回りして話せるようになるので、信頼にも繋がり、開発メンバーとの議論も建設的になりました。 02_1人PdMだからこその「苦労と試行錯誤」 1人での意思決定のプレッシャーや孤独感があり、ロールモデルや経験者がいない中で、乗り越えられたのは間違いなくチームメンバーのおかげだと思っています。 特に私自身、新卒・未経験で自分よりもプロダクト開発経験があるメンバーしかいなかった環境だったので、チームの心理的安全性を何よりも大切にしていました。 その中で、チームでの「称賛文化の醸成」と「早めの課題解決」を最優先に取り組んできました。 実際にどんな取り組みをしたのかというと、 「デイリーや振り返りでのこまめな称賛と自己アピール」 をすることと、 「エンジニアとの関係構築＆自分の動きをオープン」 にしてきました。 🌟「デイリーや振り返りでのこまめな称賛と自己アピール」 チームでの振り返りをする際に、一般的なKPT（Keep, Problem, Try）に、「Thanks（感謝）」「DOYA（ドヤしたいこと）」「MOYA（モヤモヤ）」を加えています。 これにより、些細なことでも感謝を本人に伝えられる機会が増えて協力体制が作りやすくなったり、普段感じている課題感や中長期的に解決していきたい・やっていきたいことを気軽に共有できる雰囲気が生まれました。 KPTTDMという独自のやり方を構築 🌟「エンジニアとの関係構築＆自分の動きをオープン」 チームが停滞している（全体的に進捗が良くない、コミュニケーションや発言が少ないなど）時は、メンバーと1on1をして、お互いの期待値やギャップ部分を話すようにしました。 さらに日常的にもコミュニケーションとることを大事にしています。 日々の朝会での雑談などを通じて、最近のトレンドの話や良かった本や記事情報などの共有をしたり、プライベートでの良かったことやニュースについてもラフに話したりしています。 期待値調整と日頃の雑談 03_1人PdMとしての「自分とマインドの在り方」 正解のないプレッシャーの中で意思決定やPJ推進をしていく必要があります。 その中でPdM自身が意思決定にブレてしまいチーム全体が不安になってしまった、PdMとしてチームをうまくリードできず、経験値のあるベテランにいつの間にかプロジェクトを先導してもらっていた。など実際にPdMとして失敗しまったことがありました。 これらの経験から、イチ開発メンバーであることをメンバーに認識してもらいながら、個人としては「はやくPdMとして安定的に立ち回れるようにすること」と「自分に少し負荷をかけ筋トレ状態つくりPDCAを回し続けること」を意識してきました。 実際にどんなことを実践してきたかというと、 「チームのイチメンバーとして、PdMとして相談しやすい人になる」 ことと 「限界を決めずに常に筋トレ状態を心がける」 ようにしてきました。 🌟「チームのイチメンバーとして、PdMとして相談しやすい人になる」 プロダクト開発においてPdMだけいても開発ができないので、エンジニアやデザイナーと一緒に開発するメンバーである意識を持つようにしています。 さらに、PdMが上に立つことが多いですが指示するだけの人ではなく、チームに頼る・頼られるの関係性を構築すること、ちゃんとPdMとしてバリュー発揮できる箇所を徹底して繰り替えることで、チームとの信頼を構築して安定的に自分自身も立ち回ることができるようになると実感しています。 頼る頼られるためにも関係構築が一番大事 🌟「限界を決めずに常に筋トレ状態を心がける」 慣れてきたりコツを掴み「安定」して動けるようになってきたら、「安定」にプラスα越えた動きを常にし続けること、 コンフォートゾーンから「ストレッチゾーン/ラーニングゾーン」にできるだけ居続けることが大事だと考えています。 常に筋トレ状態を意識して動くことで、自分の限界値が分かるようになるのと、常に自分を俯瞰してみれるようになってくるので、マルチタスクがうまくなると思っています。 04_まとめ 上記、3つの観点についてお話させていただきました。 私自身は1人PdM期間としては約1年ほどでしたが、1人体制は大変な環境ではあると思います😂 ですが、個人的には一番成長実感があり「自由と責任」の中で色々PDCAを回せた貴重な期間だったと感じています。 自分が止まると開発側が動けないのではないか？などプレッシャーを感じることもありますが、ちゃんとPdMとしてメンバーとしてどうすべきかを考えて動くことで、チームとの信頼も築け同じ先を向いてプロダクトづくりができると思っています。 また、スタメンではチャレンジや成長できる環境があるだけでなく、周りにはサポートしてくれたり一緒に頑張ってくれる仲間も沢山いるので、未経験且つ1人PdMの私でも複数のPJを担当しリリース〜改善まで担当ことができました🌟 この記事が、同じ1人PdM経験者の方・経験中の方にも共感していただけたり、新卒PdM・未経験PdM・PdMを目指している方にも参考になれば嬉しいです🌟 SpeakerDeckはこちら▼ speakerdeck.com 最後に！ スタメンでは一緒に働く仲間を募集しております！！ ポジションは絞らず、プロダクト職全方位で採用してますので、ぜひご興味ある方いましたら採用サイト宛にご連絡ください⭐️ お待ちしております！！！ recruit.stmn.co.jp 〜最後まで読んでいただきありがとうございました🌷〜

はじめに はじめまして！ 2025年2月より、株式会社スタメンにプロダクトマネージャー（PdM）としてジョインしました、えんまめです。弊社ではあだ名文化があり「えんまめ」と呼ばれています。 私は以前Webエンジニアとしてキャリアをスタートしました。そこからPdMという新たな役割に挑戦し、そしてこのたび、「エンゲージメント経営プラットフォーム『TUNAG』」などを提供する株式会社スタメンの一員となりました。 「なぜWebエンジニアからPdMへ？」「そして、なぜスタメンを選んだのか？」 このエントリは、そんな私のキャリアの転機やスタメンへの入社理由を語るものですが、それだけではありません。 「スタメンってどんな会社？」 と興味を持ってくださった方 「他の人は転職で会社を決めるとき、何を考えているんだろう？」 と気になる方 「キャリアチェンジって実際どうなの？」 と考えている方 など、職種や立場に関わらず、多くの方に読んでいただけると嬉しいです。 このエントリでは、私のこれまでの道のりや、スタメンという会社に感じた魅力、そしてこれからここで何を成し遂げたいのか、その「なぜ？」の部分を少し詳しくお話しできればと思っています。 転職のきっかけ 前職では、実名口コミのグルメサイト「Retty」を運営するRetty株式会社に約9年間、Webエンジニアとして勤務していました。 Rettyでは、サービスの成長と共に個人としても多くの貴重な経験をさせていただき、特に会社の上場という大きな節目に立ち会えたことは、私にとって非常に有意義な期間でした。開発業務を通じてユーザーに価値を届けることの喜びを感じながら、充実した日々を送っていました。 そんな中、気がつけば勤続9年。40歳という年齢が目前に迫ってきたとき、ふと「この先の自分のキャリアをどう描いていこうか」と深く考えるようになりました。これまでの経験を土台に、新しい挑戦をすることで、さらに自分自身を成長させたい。その想いが次第に強くなり、長年お世話になったRettyを退職し、新たな環境である株式会社スタメンへの転職を決意しました。 転職時に何を軸としていたか 新たなキャリアを考えるにあたり、私はいくつかの譲れない軸を持って転職活動に臨みました。これまでの経験を踏まえ、これからの自分が最も輝ける場所はどこか、真剣に考えた結果、以下の3つのポイントを特に重視していました。 1. 「誰と働くか」――共に働くイメージを描けるか まず最も大切だと感じたのは、「誰と働くか」ということです。私自身、面接を受けさせていただく立場でありながら、過去には面接を担当した経験もあります。その経験から、面接の場でお会いする方々に対して「この方たちとこれから一緒に働く姿を具体的にイメージできるか」「同じ目標に向かって、気持ちよく連携しながら仕事を進められそうか」という点を、自分の中で非常に重要な判断基準として持っていました。互いに尊敬し合い、切磋琢磨できる仲間がいる環境を求めていました。 2. 「自身の強みを活かせるか」――経験を糧に、新たな価値を創出 次に、Webエンジニアとしての長年の経験や、そこから培ってきた課題解決能力、そしてPdMとして新たに挑戦したいという想い、これら「自身の強み」を最大限に活かせる環境であることも重要な軸でした。単にスキルを発揮するだけでなく、その強みをもって事業やプロダクトの成長にダイレクトに貢献できる実感を得たいと考えていました。 3. 「会社の文化やコミュニケーション」――職種を超えた活発な連携 最後に、会社の文化やコミュニケーションのあり方も重視しました。特に、エンジニア、デザイナー、ビジネスサイドといった職種の垣根を越えて、日頃からコミュニケーションが活発に行われているかという点は非常に気にしていました。それぞれの専門性を尊重しつつ、プロダクトという共通の目標に向かって誰もがオープンに意見を交わし、建設的な議論ができる。そういった風通しの良い環境こそが、一体感を醸成し、より良いプロダクトを生み出す原動力になると考えていました。 これらの軸を満たす企業で働くことこそが、自分自身の働きやすさはもちろん、PdMとしてのさらなる成長にも繋がると信じていました。 スタメンに決めた理由 私が転職活動で大切にしていた3つの軸。それらが株式会社スタメンとどのように合致し、最終的に入社を決意するに至ったのかをお話しします。 1. 「誰と働くか」――鮮明に描けた「共に働く未来」と、温かい歓迎の心 転職軸の筆頭に挙げていた「誰と働くか」。これについては、スタメンの選考プロセスを通して、他社とは比較にならないほど鮮明に「この人たちと一緒に働きたい」というイメージを抱くことができました。 面接でお会いした方々とは、私が面接官の経験も踏まえて重視していた「共に働く姿を具体的にイメージできるか」という点で、最もポジティブな感触を得られました。さらにスタメンでは、選考の過程で、これから一緒に働くことになるであろうメンバーとの座談会を必ず設けてくださったのです。そこでは、実際の業務の進め方やチームの雰囲気など、より踏み込んだ質問をすることができ、入社前に気になる点を丁寧に解消してくれました。 そして何よりも心を動かされたのが、選考の最後に、面接や座談会でお会いした方々全員から心のこもったお手紙をいただいたことです。一人ひとりからの温かいメッセージは、私という個人をしっかりと見てくれているという実感と共に、「ぜひこの仲間たちと働きたい」という気持ちを決定的なものにしてくれました。 2. 「自身の強みを活かせるか」――技術的背景を持つPdMへの期待 次に重視していた「自身の強みを活かせるか」という点です。PdMとしてのキャリアはまだ浅い私にとって、長年培ってきたWebエンジニアとしての経験や技術的な知見を、新しい役割でどのように活かせるかは非常に重要なポイントでした。 面接では、その点を率直にお伝えし、現時点で自分にできること、そしてこれから伸ばしていきたいスキルについて包み隠さずお話ししました。すると、スタメン側もちょうど「技術的なバックグラウンドを理解し、エンジニアとよりスムーズに連携できる、いわゆる『Tech寄りのPdM』」を求めているタイミングだったのです。私のこれまでの経験と、スタメンがプロダクト開発を加速させる上で必要としていた人物像が、まさに合致した瞬間でした。 この出会いにより、「ここならば、私の強みを最大限に活かし、自身の成長につなげられる」と強く確信することができました。 3. 「会社の文化やコミュニケーション」――エンゲージメントを体現する、健全で活発な風土 そして最後の軸が、「会社の文化やコミュニケーション」です。スタメンは、「エンゲージメント経営プラットフォーム『TUNAG』」をはじめとするサービスを通じて、組織のエンゲージメント向上を支援している企業です。その事業内容からも想像できるように、自社内でも称賛の制度が運用されていたり、職種を超えたコミュニケーションが非常に良好であると感じました。 （個人的には、ゴルフ部があるという点も、実はかなり大きな魅力でした！） 特に印象的だったのは、座談会などを通じて感じた「言うべきことは、お互いの成長のために率直に伝える。だけど、日常の小さな頑張りや成果も見逃さずに称賛しあう」という文化です。これはまさに、私が理想としていたオープンで建設的、かつ温かいコミュニケーションが根付いている証だと感じました。このような健全で活発な風土こそが、心理的安全性を高め、チーム全体のパフォーマンスを向上させるのだと改めて確信しました。 これら3つの軸が、スタメンという会社と見事に合致したことで、私は迷いなく入社を決意することができました。 実際スタメンに入ってみて さて、いよいよ実際に入社してからの話をさせていただきます。 正直なところ、スタメンで7社目と、私自身かなり多くの会社を経験してきました。そのため、どんな会社であれ、入社前と入社後で何かしらのギャップが生じるのはある意味当然のことだと、ある種の覚悟を持っていました。 しかし、スタメンは良い意味でその「前提」を裏切ってくれました。これまでお話ししてきた「誰と働くか」「自身の強みを活かせるか」「会社の文化やコミュニケーション」といった軸の部分で、大きなギャップを感じることはほとんどありませんでした。驚いたことに、入社初日から本当にたくさんの社員の方々と自然にコミュニケーションを取ることができ、温かく迎え入れてもらえていることを実感しました。 また、スタメンは名古屋にも本社があり、私は東京本社所属なのですが、同じ部署の名古屋メンバーともオンラインですぐに顔を合わせ、話す機会を積極的に作ってくれました。物理的な距離はあっても、チームとしての一体感やメンバー同士の繋がりを強く感じることができ、「離れていても近い存在」だと思えています。 何より、「この規模の会社で、これほど全員が同じ方向を向き、同じ熱量でプロダクトや事業に取り組んでいるのか」という事実は、私にとって最大のポジティブな驚きでした。面接や座談会で感じた一体感は本物で、それが日々の業務の中でも随所に現れているのです。 入社前に抱いていた期待は、良い意味で裏切られ、今はスタメンの一員として働けることに大きな喜びと手応えを感じています。 さいごに 以上が、元Webエンジニアである私が、PdMとして株式会社スタメンに入社を決めた理由や、実際に入ってみての率直な感想です。 スタメンの一員として、私たちは自分たち自身が前向きに楽しく働くことはもちろん、主力プロダクトである「エンゲージメント経営プラットフォーム『TUNAG』」を通じて、TUNAGを利用してくださる多くの企業の皆様、そしてそこで働く従業員の皆様にも「働くって楽しい！」「この会社で良かった！」と感じていただけるような、そんな世界を実現したいと本気で思っています。 もしこのエントリを読んで、少しでもスタメンや私たちの取り組み、あるいはPdMという仕事に興味を持っていただけたなら、ぜひカジュアルにお話ししませんか？ 最後までお読みいただき、本当にありがとうございました！ herp.careers herp.careers

この度、株式会社スタメンは、TSKaigi 2025にGoldスポンサーとして協賛します。 スタメンでは、企業や組織の業務DX・エンゲージメント向上を支援するクラウド型プラットフォーム「 TUNAG 」を開発・提供しています。TUNAGでは、フロントエンド開発にTypeScriptを活用しています。 また、グループ事業として展開している、クラウド型のIT資産管理・操作ログ管理サービス「 Watchy 」では、フロントエンド・バックエンドともにTypeScriptを積極的に活用しています。 私たちの事業と開発組織が成長できたのは TypeScriptコミュニティの支えがあってこそであり、今後のさらなるコミュニティの発展に貢献するため「TSKaigi 2025」へ協賛いたします。 本カンファレンスへの協賛を通して、これからのTypeScriptコミュニティの発展を後押しし、イベントを一緒に盛り上げていきます！ TSKaigi 2025 開催概要 名称 TSKaigi 2025 開催日時 2025年5月23日(金)〜24日(土) 場所 ベルサール神田（東京都千代田区） 詳細については、下記公式サイトをご覧ください 👇 2025.tskaigi.org ブース出展について スタメンブースでは、「TUNAG」の実際の機能を活用した参加型イベントを実施します！ 来場者の皆さまに楽しんでいただけるよう、抽選イベントやプレゼント企画などをご用意しています。 抽選イベント 別カンファレンスでもご好評いただいた抽選イベントを、TSKaigiでも実施します！ プロダクト「TUNAG」の一部機能を体験しながらご参加いただける仕掛けとなっており、参加いただいた方には、参加賞やちょっと嬉しい景品もご用意しています（※数に限りがございます）。 TypeScriptコードレビュー＆クイズ 弊社エンジニアが用意したTypeScriptをテーマにした “考えるお題” をいくつかご用意しています。 「我こそは！」という皆さまの挑戦をお待ちしています！ 当日ブースで出す予定のコードレビューのお題を、少しだけ先出しします！ // このコードあなたはどうレビューしますか？？ interface Item { id : number ; data : any ; } const processItem = ( item : Item ) => { console .log( `Processing item with ID: ${ item. id} ` ); if ( typeof item.data === 'string' ) { console .log( `Data (string): ${ item.data. toUpperCase () } ` ); } else if ( typeof item.data === 'number' ) { console .log( `Data (number): ${ item.data * 2 } ` ); } else if ( Array . isArray (item.data)) { console .log( `Data (array): ${ item.data. length} elements` ); } else { console .log( `Data (other): ${ JSON . stringify (item.data) } ` ); } } ; // ...続きはお楽しみに！ // TypeScriptに慣れている方なら、気になるポイントがいくつかあるかもしれません...。 // ぜひ当日ブースでお話ししましょう！ 他にもTypeScriptにまつわるクイズをご用意しています！ 皆さまのお越しを心よりお待ちしています！ おわりに 最後まで読んでいただきありがとうございます。 弊社からはエンジニア、HR含め7名が現地参加します！ ブースやイベント等でお話できることを楽しみにしています！ 当日会場ではどうぞよろしくお願いいたします。 サブイベントのご案内 stmn.connpass.com stmn.connpass.com スタメンではTypeScript コミュニティが好きなエンジニアを絶賛募集中です。 herp.careers 参考：エンジニアのカジュアル面談Q&Aから見るスタメンの姿 note.com

はじめに こんにちは、プラットフォーム部の 近藤 です。 2025年4月9日〜11日にアメリカ・ラスベガスで開催された「Google Cloud Next 2025」 *1 に、私とCTOの野口の2名で現地参加してきました。 Google AI Studio を用いて周囲の人物を消したところ顔が歪んでしまいました 会社全体での Google Workspace の利用や、前回の記事で取り上げた Google Kubernetes Engine (GKE) など、その他にも様々に弊社では Google Cloud を活用しています。 tech.stmn.co.jp 弊社の海外イベントへの参加は、2019年の AWS re:Invent 以来です。 tech.stmn.co.jp Looking Back on Next '25 and Its Theme 2025年の振り返りにあたり、過去のイベントも改めて整理してみます。 コロナ禍を経て久しぶりのオンサイト開催となった Next’23 は、Google Cloud が 生成AI へ本格的に参入する姿勢を明確に示した年でした。Google Cloud は、Duet AI をGoogle WorkspaceとGoogle Cloud Platform 全体に導入する方針を発表しました *2 。この時期はちょうど OpenAI の ChatGPT が大きな話題となっていた頃でもあります。 続く Next’24 では、Duet AI は Gemini へとリブランディングされ、発表されました。Gemini Code Assist や Gemini Cloud Assist といった、各分野の専門的なタスクを支援するAIアシスタント群が登場し、汎用的なAIアシスタンスからより特化した機能への流れが見られました。これにより、AI は単なる受動的な情報提供に留まらず、能動的なタスク実行へと進化する可能性が示されました *3 。 これまでの流れを踏まえて Next'25 を振り返ると、AIエージェント時代 の本格的な幕開けと、Google Cloud がその実現に必要な技術スタック全体を構築するという明確な戦略が打ち出されたイベントでした。特に、Agent Development Kit (ADK) やオープンな Agent2Agent (A2A) プロトコルの発表は、マルチエージェントエコシステムという新たなAIの枠組みを示唆するものでした *4 。まさに、汎用的な生成AIから、より高度なAIエージェント、そしてマルチエージェントエコシステムへと時代が進んでいく方向性が、鮮明に示されています。 最高の席で Keynote を観ました The full stack of AI Innovation Keynote でエージェントが強く打ち出されていたことは、エキスポエリアの活況からも如実に感じ取ることができました。多くのパートナー企業が、それぞれのデモを積極的に展示・紹介していました。デモの多くは、AIワークフローと呼ばれるものかもしれませんが、ともあれAIエージェント時代への移行期にあることを肌で感じられる場でした。 GitLab のブースでマグカップと靴下をいただきました その中で Google Cloud は、この新たな AI エージェント時代を本格的に推進するため、AI ハイパーコンピュータ、高性能な基盤モデル、エージェント開発・実行環境、そして多様なエージェントそのものに至るまで、エンドツーエンドの技術スタックを網羅する統合的なプラットフォームプレイヤーを目指す戦略を明確に示しました。 Google Cloud Next 2025 サマリーセッション (日本語) より 具体的には、AIワークロードを支える AI ハイパーコンピュータとして、第7世代TPUである Ironwood が紹介されました。また、エージェントの基盤モデルとしては、高い性能を持つ Gemini 2.5 の発表がありました。さらに、エージェントの開発、管理を効率化するための Vertex AI の大幅な機能強化 や、Google Agentspace のようなエージェント関連の具体的な取り組みも紹介され、エージェント構築のための包括的な環境が整いつつあることが示されました。 Multi-Agent Ecosystem イベント参加当時まで、AIエージェントをまだ先の未来の話だと捉え傍観していた私にとって、Next'25 のセッションやエキスポエリアで目にした発表の数々は、驚きと同時に焦りを感じさせるものでした。そして、Google Cloud が提唱した Agent2Agent (A2A) *5 に基づくマルチエージェントエコシステムという新たな枠組みには、特に大きな衝撃を受けました。 ところで、2024年11月に Anthropic が公開した Model Context Protocol (MCP) の注目が、現在高まっています *6 。MCP は、AI アシスタントが外部のデータソースやシステムと連携するためのプロトコルとして提案されています。MCP が AI とツール間の連携を目的とするプロトコルであるのに対し、A2A はエージェント同士がセキュアに相互に連携するためのプロトコルという点が異なります。A2A は単体のエージェントの能力拡張を目指す MCP を補完し *7 、エージェント間の協調によるエコシステムを実現する可能性を秘めています。 こうしたエージェント間の連携が進めば、各エージェントは特定の役割や専門領域に特化（バーティカル化）していく方向に進むと個人的には想像しています。MCPに関してはセキュリティ上の懸念も指摘される中、A2A がセキュアなプロトコルを目指している点も、印象深く感じられました。 Announcing the Agent2Agent Protocol (A2A) より これらの新たなプロトコルが、今後スタンダードな地位を確立できるかは現時点では不透明です。しかし、紛れもないリーディングカンパニーである Google がこれを主導する姿勢を見せたことには、個人的にも大きな期待を寄せざるを得ません。A2A の発表パートナーリストには Anthropic の名前が見当たらなかった点は気になります。MCP を主導する Anthropic が A2A に対して今後どのような見解や動きを見せるのか、引き続き注目していきたいポイントです。一方で、Google が Anthropic へ追加投資を行ったことも記憶に新しく *8 、両社の良好な関係が維持されることを期待しています。 The Innovation of GKE せっかくなので、セッションについても簡単に取り上げさせてください。イベント全体の話題の中心は AI でしたが、個人的には Google Kubernetes Engine (GKE) のアップデートに関するセッションにも注目していました。特に、「GKE turns 10 and looks to the future of Kubernetes」というセッションでは、GKE の10周年を記念しつつ、次世代の GKE イノベーションについて具体的に紹介されていました。 本セッションでまず強調されていたのは、Google Cloud が大規模クラスタのスケーラビリティに重点的に投資している点です。具体的に 65,000ノード規模のクラスタをサポートするという話は、大規模なエンタープライズ顧客や、複雑かつリソース消費の多い AI ワークロードを GKE 上で実現していくことの、明確な意思表示と言えるでしょう。 そうした発表の中でも、私が個人的に思わず声をあげそうになったアップデートが、In-Place Pod Resizing です。Kubernetes v1.27 でアルファ機能として導入された、コンテナを再起動することなくポッドに割り当てられた CPU/メモリリソースのサイズを変更できる機能です *9 。Kubernetes v1.33 では、ベータ版に移行されました *10 。現在、弊社で稼働している GKEクラスターでは Vertical Pod Autoscaler (VPA) を利用したポッドのリソース調整も行っていますが、再起動が発生するという点がまさに運用上の課題となっていました。この In-Place Pod Resizing 機能が、GKE Autopilot 1.33 以降でアルファ/ベータとして利用可能になる見込みとのことで、非常に期待できるアップデートです。 Del Taco の BURRITOS がお気に入りでした おわりに 今回の Google Cloud Next には、業務の一環として参加させていただき、会社に宿泊費と交通費を負担していただきました。不在中に業務をサポートしてくれたメンバーにも、この場を借りて改めて感謝を申し上げます。 イベントでの様々な発表やデモに触れる中で、私自身の AI 利用がまだ限定的であること、そしてもっと積極的に、高い解像度で活用を進めていく必要があることを強く実感しました。特に、2025年1月からは Google Workspace 全プランに AI が標準搭載されており、まずは身近なツールから積極的な活用を図っていきたいと考えています。 また、イベントを通じて AI エージェント時代におけるプロダクトマネジメントのあり方にも、個人的な関心が大きく高まりました。AI が業務を劇的に効率化する可能性は明らかであり、プロダクトの提供側としては、この強力な AI をいかにプロダクトに組み込み、ユーザーに新たな価値として届けていくか、が今後ますます重要になってくると予想されます。ひとりの技術者としても、AI の理解を深め、そのポテンシャルを最大限に引き出し、社会に貢献できる形で価値を提供していく責務があると感じています。 弊社では、エンジニア採用を積極的に行っています。少しでも興味を持っていただけたら、ぜひまずはカジュアル面談でお話しできればと思います。 herp.careers *1 : https://cloud.withgoogle.com/next/25 *2 : https://cloud.google.com/blog/topics/google-cloud-next/next-2023-wrap-up?hl=en *3 : https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2024-wrap-up?hl=en *4 : https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2025-wrap-up?hl=en *5 : https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ *6 : https://www.anthropic.com/news/model-context-protocol *7 : https://google.github.io/A2A/#/topics/a2a_and_mcp.md *8 : https://www.nytimes.com/2025/03/11/technology/google-investment-anthropic.html *9 : https://kubernetes.io/blog/2023/05/12/in-place-pod-resize-alpha/ *10 : https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/#beta-in-place-resource-resize-for-vertical-scaling-of-pods

はじめに こんにちは、プロダクト開発部の 勝間田 です！ もうすぐGWですね！まとまった時間が取れるこの機会に、読書をしようと考えている方も多いのではないでしょうか。 今回は私含め、スタメンエンジニアが最近のお気に入り書籍を紹介させていただきます！ 技術書・ビジネス書などジャンルは問わず、良かった本を自由に挙げてもらいました。 この記事で気になる・読んでみたいと思うような本が見つかれば幸いです。 におうコードの問題集 〜MySQLインデックスに立ち向かう編〜 最初は勝間田が紹介します！普段はTUNAGのバックエンドを担当しています。 私が紹介する本は『におうコードの問題集 〜MySQLインデックスに立ち向かう編〜』です。 におうコードの問題集 〜MySQLインデックスに立ち向かう編〜 私自身「インデックスについてなんとなくわかる...」、「EXPLAINの結果を見て、効いているか効いてないかぐらいは...」というような状況でした。 そのためEXPLAINの見方がわかりやすく解説されている書籍を探していたところ、この書籍に出会いました！ MySQLのインデックスが「そもそもどういう仕組みで動いているのか？」という基本的な部分から「なぜインデックスが効かなくなることがあるのか？」、「EXPLAINの結果で注目すべきポイント」まで丁寧に解説されています。 内容が具体的であり、キャラクターによる対話形式のため楽しく話が入ってきました。 EXPLAINの見方についての解説がわかりやすかったのがおすすめポイントです。 この書籍のおかげで、実務でのEXPLAINの活用イメージが明確になった気がします。 ページ数も約110ページと短いので、連休で一気に読み切れる量かなと思います！ 以下のような方に特におすすめだと感じました！当てはまっている方はぜひ読んでみてください！ MySQLのインデックスについて基礎からしっかり理解したい方 EXPLAIN の結果をなんとなくしか見れていない、読み解き方をちゃんと知りたい方 パフォーマンスを意識して、より適切なインデックスを設計・利用したい方 難しい技術書は挫折しがちだけど、対話形式なら読みやすいかも、という方 WHYから始めよ！ インスパイア型リーダーはここが違う おしん( @38Punkd )です。 TUNAG iOS の開発を主に担当しています。 僕が紹介する本は 『WHYから始めよ！ インスパイア型リーダーはここが違う』です。 WHYから始めよ! インスパイア型リーダーはここが違う 作者: サイモン・シネック 日本経済新聞出版 Amazon 大学で学生団体の活動をしていた頃に、理想のリーダー像がわからず悩んでいたことがきっかけで出会った本です。 WHY, HOW, WHATの3つの円から成るゴールデンサークルで有名な、『人を動かすのは “何をやるか” ではなく “なぜやるか” 』がキーメッセージの本です。 チームや組織を動かすためのリーダーシップのあり方や、“モノ売り“から脱却して感情で動くストーリーを語る重要性について学べました。 コードを書くのは勿論エンジニアの仕事の一つですが、この本が勧める「WHYから始める」考え方で仕事をすることで、ビジネスマンとしての成長にも繋がると思っています。 新規プロジェクトをこれから担当するけどチームを引っ張るのが不安に感じる方に特におすすめします。 プロを目指す人Ruby入門 スタメンのじゅけいです。 自分はTUNAGのバックエンド開発を担当しています。 僕が紹介する本は プロを目指す人のためのRuby入門 です。 自分はこれまでRubyに触れたことがなくスタメンに入って初めて触ることになりました。そこでおすすめいただいた本が本書になります。 プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) 作者: 伊藤 淳一 技術評論社 Amazon 本書のコンセプトは第1章のイントロダクションでも語られている通り、Ruby開発で必要なナレッジの網羅的な解説になります。 良さを語り尽くすには語彙も時間も文章力も足りないので、自分がためになったと感じるナレッジを一部抜粋します。 Rubyではnilもtrue/falseも全てオブジェクトで振る舞いを持つ p、pp、puts、printの違い moduleのmix-in nilすらオブジェクト扱いでメソッドを持つというのは新鮮です。 また、プリントデバッグの際は内部仕様的にデバッグ用途ならpの方が好ましいというのは細かいけれど重要な違いだと感じました。（ちなみにppは配列などを渡すと展開して出力してくれるので便利） moduleの仕組みについては、継承などの他共通化アプローチとの使い分けの整理が不十分ではありますが、自分の中でのクラス設計の幅が広がりました。 Rubyは改めて記法が多彩で自由な言語だと感じました。細かな仕様を網羅的かつ丁寧に解説してくれる本書は、Rubyに初めて触れる方にぴったりの一冊だと思います。ぜひ読んでみてください。 実践Vim　思考のスピードで編集しよう！ とんとんぼ です。今年(2025年)4月より TUNAG の iOS エンジニアとしてスタメンにジョインしました！ 私が今回ご紹介したいのは、多くの Vimmer にはおそらくお馴染みの名著『実践Vim　思考のスピードで編集しよう！』です。 実践Vim　思考のスピードで編集しよう！ (アスキー書籍) 作者: Ｄｒｅｗ Ｎｅｉｌ , 新丈 径 角川アスキー総合研究所 Amazon 私自身、プログラミングを始めたばかりの頃に、キーボードとマウスの間を頻繁に行き来することに煩わしさを感じ、「この問題をどうにか解決したい」と考えていた際、本書の『思考のスピードで編集しよう！』というキャッチーなタイトルに強く惹かれて手に取りました。 本書の大きな特徴は、現場でよく遭遇するであろう具体的な問題をTips形式で121個も取り上げ、その解決策を解説している点にあり、非常に実践的な内容となっています。中でも特に印象に残っているのは、Vim特有のモード（Normal, Insert, Visual）の概念を画家になぞらえて説明している箇所で、この本を通じてVimを習得すれば、まるで絵画を描くようにコーディングを進められ、プログラミングがより一層楽しくなるだろうと感じさせてくれます。 私自身は開発プラットフォームの事情で主にXcodeを使用していますが、本書の影響もあり、Vimのキーバインドモードを設定してVimライクな操作で開発を進めています。幸いなことに、本家であるvi、Vim、Neovimはもちろん、VSCode、Zed、さらには競合とされるEmacsでさえ拡張プラグイン（Evil）を使えばVimのキーバインドを利用できるため、本書で得たスキルは様々なエディタ環境で応用可能です。 Emacs で Vim 操作する図(Evil) 最後に いかがでしたでしょうか。 今回は、4名のメンバーがそれぞれの視点でおすすめする書籍をご紹介しました。 技術的な学びを深める本、新しい視点を与えてくれる本など、様々なジャンルの書籍が集まったのではないでしょうか。 気になる一冊が見つかった方は、この長期休みの機会にぜひ手に取って読んでみてください！ 最後までお読みいただき、ありがとうございました！！ 採用情報 スタメンでは、全技術領域でプロダクトを成長させていくエンジニア、デザイナー、プロダクトマネージャーの方を募集しています。 もしご興味を持っていただけたら、下記からご応募ください！ herp.careers

皆さん、こんにちは。 株式会社スタメン CTO室の根岸です。 今年の4月に 新卒未経験エンジニア としてスタメンに入社しました！ どうぞよろしくお願いいたします☺️ 本日は、 RubyKaigi 2025 のレポートをお届けします！ スタメンは、今回プラチナスポンサーとして総勢8名で参加しました🙌 私は今回がRubyKaigi初参加なので、どんな体験が待っているのかドキドキしながら参加しました😳 RubyKaigi 2025概要 開催期間：2025年4月16日（水）〜18日（金） 開催場所：愛媛県県民文化会館 今年の開催地は愛媛県🍊 特産品のみかんにちなんだオレンジ色のロゴがとても印象的です✨ RubyKaigiでは毎日さまざまなセッションとブースが開かれており、いろいろと回ったので、その気づきや学びをご紹介します🗣️ セッション参加レポート✍️ 「Ruby Taught Me About Under the Hood」 / @ima1zumi さん Unicode（ユニコード）についてのご登壇です！ そもそも私はUnicodeというものを知らなかったのですが、 とても面白かったです。 以下、登壇の内容を少しご紹介します🤏 Unicodeとは、世界の様々な言語、書式、記号に、番号を割り当てて定義した標準の文字コード。 1つひとつの文字に番号を割り当てることで、プログラマーは、どの言語が混ざっていても、コンピューターに保存、処理、伝送させるような文字エンコーディングを同じファイルやプログラムの中に作ることができるらしいです💭 そして、そのUnicodeには、 書記素クラスタ というUnicodeテキストを1文字ずつ分割するアルゴリズムがあるようです💡 分かりやすく言うと、Unicodeにおいて自然な“1文字”を表す単位です！ 書記素クラスタの概念がないと何が起きるのか？ 例えば「🧑‍🧑‍🧒←この絵文字は何文字ですか？」と聞かれたら、 多くの方が1文字と答えるのではないでしょうか？ しかしながら、実はこの🧑‍🧑‍🧒は、 ①👨　②"" 　③👩　④""　⑤👦　⑥"" 　⑦👧 この７つの要素からなっているそうです😳 人間は、🧑‍🧑‍🧒=1文字 機械は、　🧑‍🧑‍🧒=7文字 と捉えるこの差分が、バグの原因になるとのこと。 そこで人間が1文字と捉えるものを機械が1文字と捉えられるようにしたのが 書記素クラスタ なのだそうです💡 絵文字の書記素分割の表を眺めてみるのも、面白かったです！ 「Goodbye fat gem 2025」 / @ktou さん Fat gemについてのご登壇です！ またまた私はFat gemがなんなのか知らなかったのですが、 Fat gemとは、ビルド済みバイナリー（0or1の二者択一）が入ったgem（便利な機能やよく使う機能を、あらかじめ部品化したようなもの）のこと。 つまり、すごく便利なものなのだということがわかりました。 しかしながら、作る側は大変なのだということをお話いただきました。 具体的には以下の3点が大変なポイントなのだそうです。 環境設定が難しい 脆弱性対応が遅れがち メンテナンスが大変 この3点について、少しだけ詳細を綴ります。 環境設定が難しい →Fat gemはリリースに時間がかかるし、requireにも時間がかかるため、Rubyを使う環境がなかなか整わない。 脆弱性対応が遅れがち →Fat gem内にある外部ライブラリに脆弱性が見つかった際の修正が大変。 メンテナンスが大変 →Fat gemは通常クロスコンパイルして作るのに対し、多くの外部ライブラリがそうでないため、外部の外部ライブラリが修正される度に問題が起きてしまう。 このような理由で作るのが大変になっているようです。 なんとなく使っていたRubyですが、Rubyをサポートするこのようなシステムがあって初めて使えるものなのだということを理解しました💭 「Matz Keynote」 / @yukihiro_matz さん AI時代のプログラミングについてのご登壇です！ 「アルファシンドローム（犬が甘やかされていくうちに自分が家族の中のリーダーだと誤認してしまい、言うことを聞かなくなっていく現象）と逆の現象が、人間とAIの関係の間で起こるのではないか」ということを危惧する内容でした。 つまり、人間がAIさまさまになってしまうということです。 そこで重要なのが、何をAIにお願いして、何を自分でやるのかをしっかり考えることです💡 例えば、人間がやるべき仕事として、顧客の意向の汲み取りが挙げられていました。 私としては現状すでに「AIさまさまです」と思うことが多々ありますが、今後AIアシストコーディングに取り組んで行くにあたり、まさにこの考え方は重要なことだと感じました。 DrinkUpでの学び🍺 RubyKaigiの素敵なところはセッションから学ぶだけでなく、スポンサー企業が開催するDrinkUpイベントでカジュアルにお話しながら学びを深められることです！私が初学者であることを伝えると、とても熱心に教えてくれました。 例えば、基礎の基であるオブジェクト指向について。 「オブジェクト指向というのは、簡単に言うと、鳥という「もの」が飛ぶという「動作」をするという関係性を定義したり、鳥というものの「クラス」（〇〇科など）を定義したりできる、そういう考え方だよ〜」と初学者にわかりやすい例を用いて教えてくださいました💡 とてもわかりやすくて、今までよりイメージが湧いた気がします💭 Rubyに精通された方たちと近い距離でお話できる貴重な機会でした！ 他社ブースでの学び📖 個性豊かなブースが勢揃いで、どこから回ろうか迷いました💭 2日目からは各ブースを回るスタンプラリーも行われていて、とても盛り上がっていました✨ そんな中、私が1番に入ったのは転職ドラフトさんのブース。 Rubyが選ばれ続ける理由を技術トレンドの変化に基づいてご説明いただきました！ RubyKaigi 2025 転職ドラフトPRトーク - Speaker Deck speakerdeck.com エンジニアとしてどんな力を身につけたいか付箋に書いて貼るというワークにもチャレンジ💪 私は新卒未経験ということで、「プログラミング基礎力」と大きく書きました✍️ 各ブースでそれぞれの専門領域におけるトレンドを知ることができ、勉強になりました。 スタメンのブース出展🙌 私たちもブースを出展しました！ 私たちは、自社サービス『TUNAG』のベネフィット機能を用いて、抽選イベントを行いました！当選された方には、モバイルバッテリーをプレゼント🎁 多くの方に『TUNAG』の実際の画面を見ていただけて、嬉しかったです☺️ 感想💭 私が何より言いたいのは、Rubyコミュニティーが 熱くて優しいコミュニティー だということです😌 自分が初学者であることに、はじめは引け目を感じていましたが、終わるころにはすっかりそんな気持ちも消え去っていました。 それから、 Ruby学習への意欲の高まり も感じています。 カンファレンスの内容が今年は全然わからなかったけれど、1年間学んだ来年だったらどれくらいわかるようになるだろうかというワクワクや、今年出会えたRubyistの皆さんともっと熱く語れるように、「まずは自分の知識量を増やしていかなくては！」という意思が芽生えたと思います。 そういう意味で、入社直後にこのような温かいコミュニティーで今後の学習モチベーションを高められた私は、とても恵まれたなと思っています。 来年のRubyKaigiに成長した私で戻って来られるよう、日々精進です💪 また、今年はブースの出展のみだったのですが、来年はDrinkUpの企画にも挑戦し、Rubyコミュニティーとのつながりをさらに深めていきたいと思っています🔥 イベント登壇のお知らせ📢 実は、 「はじめてのRubyKaigi 〜ゆるっとふりかえり会〜」 というイベントで登壇することになりました✨ 日時：2025年5月20日（火）19:00～ 開催場所 : primeNumber　Office Lounge (目黒駅直通) 参加費用 : 無料 このイベントでは、私がはじめてRubyKaigiに参加して学んだことや心境の変化などを等身大でお話しする予定です。 少しでも興味をお持ちいただけましたら、ぜひチェックしていただけたら嬉しいです！ 詳細はこちらのリンクからご覧いただけます！ pn-developer-lounge.connpass.com 一緒に学び、交流できることを楽しみにしています😊 おわりに🌷 最後まで読んでいただきありがとうございます😊 スタメンでは、RubyやRubyコミュニティが好きなエンジニアを絶賛募集中です🙌 herp.careers 参考：エンジニアのカジュアル面談Q&Aから見るスタメンの姿 note.com

はじめに こんにちは！ 株式会社スタメン にバックエンドエンジニアとして 2025年1月 に入社しましたもりしたです。 これまでは主にRubyを使ったバックエンド開発に携わってきました。現在は、SRE（Site Reliability Engineering）やDevEx（Developer Experience）の向上をミッションとするプラットフォーム部に所属しています。 この記事は、 スタメンの採用サイトを見て、少しでも興味を持ってくださっている方 カジュアル面談を受けてみようか迷っている方 実際に入社したメンバーの「生の声」を聞いてみたい方 に向けて書いています。 入社から約4ヶ月経過した今、肌で感じているスタメンのリアルな姿をお伝えすることで、皆さんの疑問や不安を少しでも解消できれば嬉しいです。 スタメンを選んだ理由 - 新たな技術領域への挑戦と、運用経験への意欲 私がスタメンを選んだ理由は、大きく分けて二つあります。 一つは、SRE（Site Reliability Engineering）やDevEx（Developer Experience）といった、これまで深く関わることがなかった新しい技術領域に挑戦できる環境への強い期待です。自身のスキルセットを広げ、より市場価値の高いエンジニアを目指したいと考えていました。 そしてもう一つは、プラットフォーム部でシステムの安定稼働を支えるための知識やスキルを習得したいという強い意欲があったからです。これまでの開発経験に加え、インシデント対応の調査や分析といった運用経験を積むことは、エンジニアとしての幅を広げる上で不可欠だと考えています。 カジュアル面談では、主にスタメンの事業内容や技術スタック、チームの雰囲気などについてお話を伺いました。その中で、プラットフォーム部がシステムの信頼性向上に重要な役割を担っていることを知り、開発だけでなく、運用という側面からもサービスを深く理解し、貢献できる環境に魅力を感じました。 スタメンの 経営理念 ページに書かれている Our Value（行動指針） の1つに 「Work Bravely（大胆に攻め、失敗や挑戦を讃える）」 があります。私はこの Value に背中を押され、未経験の領域にも積極的に踏み出すことを後押ししてくれる文化があると感じ、運用経験を通じて得られる知見は、今後の開発業務においても必ず活かせると確信し、入社を決意しました。 現在の業務内容 - 新しいことへの挑戦と学びの日々 プラットフォーム部の一員として、現在は主に以下の業務に携わっています。 ライブラリのバージョンアップ対応 : アプリケーションの安定性とセキュリティを常に高いレベルで維持するため、Dependabot を活用し、原則として平日毎日ライブラリのバージョンアップ対応を行っています。日々の小さな変更を積み重ねることで、常に最新の状態を保ち、セキュリティリスクを最小限に抑えています。バージョンアップの際には、影響範囲の調査や動作確認を丁寧に行い、システム全体の理解を深めています。 プロジェクトメンバーとしてのバックエンド開発 : プラットフォーム部のミッションであるSRE/DevEx向上に繋がる開発だけでなく、プロダクト開発のプロジェクトにもバックエンドエンジニアとして参加し、機能開発などを担当しています。最近では、TUNAGが提供するタスク機能に関わる開発に携わっています。 オンコール担当 : システムに問題が発生した際に迅速に対応できるよう、チームメンバーと交代でオンコール対応も行っています。スタメンでの経験はまだ浅く、原因特定に時間がかかることが多いですが、チームメンバーの協力を得ながら緊張感と責任感を持って取り組んでいます。 プラットフォーム部では、現在少数のメンバーで、SREやDevExに関わる幅広い業務を協力して進めています。ライブラリのバージョンアップ対応、機能開発のサポート、オンコール対応などを担当する中で、それぞれの得意なことや興味のある分野で助け合いながら、日々業務に取り組んでいます。少人数のチームだからこそ、お互いのスキルや知識を補完し合いながら、幅広い技術領域に触れることができています。 github.com biz.tunag.jp 入社して分かったスタメンの特徴 - 期待を超えたリアル 実際に入社してみて、「なるほど、スタメンはこういう会社なのか！」と感じた特徴をいくつかご紹介します。 技術的な特徴 - 常に進化を求める姿勢 Dependabotによる継続的なライブラリ更新 : Dependabotを活用した自動更新の仕組みがしっかりと根付いており、常に最新の技術を取り入れ、セキュリティリスクを低減する意識の高さに驚きました。 トランクベース開発 : 頻繁なマージと迅速なフィードバックループにより、開発スピードと品質の両立を目指すトランクベース開発を採用していることで、チームの一体感と効率的な開発を実感しています。 AI技術の積極的な活用推奨 : 開発効率や生産性向上のため、GitHub Copilotなどを多くのエンジニアが利用しており、新しい技術へのアンテナの高さと、それを積極的に取り入れようとする文化を感じています。Devin の活用状況については、 こちら のブログ記事をご覧ください。 組織的な特徴 - フラットな連携と成長支援 東京・名古屋の二本社制とフラットな連携 : スタメンは東京と名古屋に本社を置く二本社制を採用しており、エンジニアは両オフィスに在籍しています。しかしながら、物理的な距離を感じさせないスムーズなコミュニケーションが取れており、拠点に関わらずチームとして一体感を持って働けています。 社員コミュニケーション促進の仕組み : 社員同士の交流を活発にするため、社内での懇親会や部署を超えての交流イベントなどを定期的に開催しています。 技術カンファレンスへの積極的な参加支援 : 会社として、エンジニアの成長を支援するため、技術カンファレンスへの参加を積極的に推奨し、参加費用の補助などの支援制度を設けています。最近では、RubyKaigi 2025 に他部署を含めたバックエンドエンジニア全体で参加し、最新のRuby言語に関する動向や他社のエンジニアとの交流を通じて多くの刺激を受けました。カンファレンスで得た知識や刺激は、日々の業務における議論のきっかけとなるだけでなく、エンジニアとしての成長の糧となっています。 rubykaigi.org 会社の雰囲気 - 挑戦を後押しするカルチャーとオープンな対話 賞賛を大切にする文化 : 日々の業務における成果や貢献に対し、部署や役職に関わらず互いに賞賛を送り合う文化が根付いています。 オープンなコミュニケーション : 部署や役職の垣根を越えて気軽にコミュニケーションが取れる雰囲気があり、会社全体の動きや目標を共有しやすい環境です。 東京オフィスの特徴 : 私が所属する東京オフィスは、ビジネスサイドのメンバーが多く、オフィス全体が活気に満ち溢れています。様々な部署のメンバーが活発にコミュニケーションを取っており、エネルギッシュな雰囲気の中で業務に取り組むことができます。 さいごに 入社してまだ日は浅いですが、技術的な挑戦ができる環境、そして部署や拠点を越えて協力し合う組織文化の中で、日々多くのことを学び、刺激を受けています。 この記事を読んで、スタメンに少しでも興味を持っていただけたら嬉しいです。 スタメンでは、プロダクト開発に関わる全ての領域でプロダクト職種の採用をしています。 プラットフォーム部に興味を持っていただけましたら、Site Reliability Engineer (SRE)、ソフトウェアエンジニア（Developer Experience）からご応募ください。皆さんとお話できるのを楽しみにしています。 最後までお読みいただき、ありがとうございました。 herp.careers herp.careers herp.careers

みなさん、こんにちは！初めましての方は、初めまして！ 2025年4月より株式会社スタメンにジョインしました、iOSエンジニアのとんとんぼ( @Ktombow1110 )こと、村岡です！ 2025年4月9日から11日で開催された try! Swift Tokyo 2025 に弊社から、3名のメンバーで現地参加してきました！ 今回は入社エントリ含めて、印象に残ったセッションや会場の雰囲気などをお伝えできればなと思います。 try! Swift とは try! Swift とは、Swift を使った開発のノウハウや最新の事例を学び、共有するために世界中の開発者が集う国際的なイベントです。日頃の Swift 知識やスキルを披露し、協力し合うことを目的に開催されます。 tryswift.jp イベントの主なプログラムは、基調講演、LT(ライトニングトーク)、スポンサーブース、Party(懇親会)などです。 世界中から開発者が集まるため、会場には様々な国籍の方がいらっしゃいます。 そのため、セッションは基本的には英語で行われますが、英語が苦手な方、または日本語が苦手な英語話者に向けて通訳が行われます。 今回のイベントでは、通訳に AI 同時通訳サービス「 Flitto 」が導入され、公式アプリを通じてリアルタイムで翻訳された発表を聞くことができるようになりました。 Flitto の紹介 今回の開催地紹介 昨年は、渋谷のベルサール渋谷ファーストで開催されました。 昨年のイベントの様子や感想については、弊社の青木( @38Punkd )が記事を公開しているので、ぜひご覧ください。 tech.stmn.co.jp 今年の会場は、立川市にある立川ステージガーデンです。 会場周辺は自然が豊かで、近くに飲食店も多く、非常に過ごしやすい場所だと感じました！ 季節もちょうど桜の時期で、隣接する昭和記念公園で桜を楽しむ参加者も多く見られました。 さらに、会場自体も本格的なシアターの雰囲気で、セッションを聴くには最高の環境だったと思います。 立川ステージガーデンの入り口 会場内の様子 Swift 10周年！ イベント内容 さて、ここからイベントの内容について触れていきます。 気になったセッション 今回はLTも含めて33人の方が登壇されました。 全ての方を紹介するのは難しいので、個人的に勉強になったセッションを紹介していこうかと思います。 素早く実現する優れたアプリデザイン 今回の try! Swift の中で、私が最も感動し、まさに「最推し」と言えるセッションがこちらでした。人気カメラアプリ『Halide』の開発者であるSebastiaan de With 氏が登壇し、アプリケーションのデザインや「より良いものを作るためにはどうすれば良いか」という本質的な問いについて、『Halide』を実例に解説してくれました。 このセッションで語られた、ユーザー体験を追求するための強いこだわりは、まさに弊社の Value である “Far Beyond” の精神にも通じるものがあると感じました。 私はこのセッションに感動して、残り２日間を Halide をインストールして写真を撮っていました。とても体験が良かったので、おすすめです！ youtu.be J1プロサッカーチームFC町田ゼルビアのImmersive動画を撮影しSwiftでViewerを実装し体験会実施した Cyber Agent に所属し、 visionOS Engineer Meetup も主催されている服部さんのセッションです。 サッカーJ1リーグ所属の FC町田ゼルビアの Immersive Video(没入型映像)を撮影し、特別会員向けに実施した体験会で得られた貴重な知見についてお話を伺うことができました。 実際に体験したユーザーから「楽しかった」とコメントがあり、エンジニア冥利に尽きるなぁと聞いていて思いました。 体験会に参加したユーザーから寄せられた「（普段見られないアングルから観戦できて）楽しかった」といった直接的なコメントも紹介され、こうした新しい価値を提供できることは、まさにエンジニア冥利に尽きる体験だなと感じました。 youtu.be SwiftUI 8番出口 SwiftUI で UI を実装する際、特定の課題に直面したとき、SwiftUI で解決策を探るべきか、それとも UIKit の力を借りるべきか、この開発者がしばしば悩むであろう判断を、『８番出口』というゲームをモチーフに、ゲーム感覚で解説していくユニークな LT でした。 ゲームの世界観を巧みに再現しており、随所に細かい小ネタも満載で、まさにLTらしい遊び心にあふれた構成で非常に楽しい内容でした。 発表中、会場からは何度も笑い声が上がり、とても和気あいあいとした雰囲気の中で、楽しみながら聴くことができました。 youtu.be スポンサーブース スポンサーブースも非常に充実していました。例えば、参加者が try! Swift のタイムテーブルアプリ開発ができるブースや、ルーレット・くじ引きなどで素敵な景品が当たる企画など、各社が訪問者を楽しませるための趣向を凝らしたコンテンツを多数用意しており、本当に盛りだくさんでした。 ステッカーを当てて浮かれるエンジニア 私は、「売上猫」こと RevenuCat のスポンサーで当てた売上猫ニット帽を2日目と3日目にずっとつけてブースを回っていました。 Party の雰囲気 イベント2日目の最後には、懇親パーティーが開催されました。今回は会場近くにある開放的な屋外スペースでの開催でした！ 様々な方々とおしゃべりしたり、音楽に合わせて踊ったりと、リラックスした雰囲気の中で交流を楽しむことができ、とても楽しい時間でした。 屋外DJブース try Swift 公式アプリについて try! Swift の公式イベントアプリはオープンソースで公開されています。 私は毎年、参加するカンファレンスやイベントの公式アプリには、少なくとも１つのPull Request を送って何らかの形で貢献することを個人的な目標にしています。これは、エンジニアとして技術コミュニティに少しでも貢献したいという思いから、自主的に続けている活動です。 今年は、アプリ内で使用されているライブラリの謝辞表示に関する修正の Pull Request を送りマージしていただきました。拙い英語力のため、やり取りでメンテナーの方を困らせていますが、今年も微力ながら貢献できて嬉しく思っています。 github.com 来年もまた開催することが決まったら、貢献していきたいと思います！ 全体の感想 今年の開催が平日だったことに加え、私自身が入社直後のタイミングだったこともあり、当初は参加を見送るつもりでした。しかし、入社したらすぐに「try Swift 行きます？もう話はしてるので、参加するなら稟議出してください」と言われ、快く爆速で送り出していただきました。いやー、あったけぇ 昨年はプライベートで一人参加でしたが、今年は職場のエンジニア同僚２名と一緒にブースを回ったり、セッションを聴いたりと、終始とても楽しく過ごすことができました。 セッションでは、技術的な知識はもちろんのこと、プロダクト開発に向き合う情熱や心構えに触れることができ、多くの面で良い刺激を受けました。 また、今年の会場が立川だったことも、自然豊かな環境で、リラックスしてセッションに集中できた点でとても良かったと思います。 今回の経験を糧に、これからも業務・個人活動問わず、iOSの開発に一層力を入れていきたいと思います！来年の try! Swift Tokyo 開催も楽しみにしています！ 会場隣りのカフェでチルするiOSエンジニア達 採用情報 株式会社スタメンは、iOSエンジニアはもちろん、全ての領域でエンジニアを募集しています！ もし、興味を持っていただけたら、下記からご応募ください！ herp.careers

プロダクト開発部でTUNAGの開発をしている hisa です。 私たちの開発チームでは、プロダクトをより良く育てていくために、日々の開発の進め方やチームの体制について、試行錯誤を重ねてきました。 ただ、新機能の開発や日常的な対応を優先する中で、「手を入れたいのに後回しになってしまう」タスクが少しずつ積み上がっていく感覚もありました。 そうした状況を見直し、開発の質とスピードのバランスを取り戻す一手として、私たちはDevinの導入に踏み切りました。 この記事では、Devinをチームに迎えてからの変化や、活用における工夫についてご紹介します。 Devin導入の背景 プロダクトを継続的に成長させていくためには、機能開発だけでなく、基盤の見直しや細かな改善対応といったタスクにも継続的に取り組んでいく必要があります。 たとえば、 プロダクト全体のリアーキテクチャ ライブラリアップデート（影響範囲の調査含む） 社内やお客様から上がった改善アイテム こうしたタスクは、いずれもプロダクトの健全性やユーザー体験に関わる重要なテーマですが、どうしても日々の開発サイクルの中では優先度が上がりにくく、着手のタイミングを逃してしまいがちです。 私たちは、これらのタスクを「後回しにしない」ためだけでなく、チーム全体としての開発力を底上げし、より本質的な課題に集中できる体制をつくる一手としてDevinを導入しました。 Devinを使いこなすための5つのTips 1. タスクは10〜15分で完了する粒度に分割する 長時間タスクをそのまま渡すと 作業の途中で認識がズレてしまう 関連ファイルの参照漏れや飛躍した実装が起きる 要件を誤解したまま進行してしまう といったリスクが高くなります。 そのため、タスクは 「遅くとも15分以内に終わる」 ことを目安に分割しています。 2. 実装方針は必ずテキストですり合わせる Devinは仕様を聞かずに実装を始めることがあります。 実践しているのは、PRではなく、 テキストベース で方針のすり合わせを行うこと。 Issue〇〇の対応をして欲しいです。 実装前に実装方針をIssueのコメントに記載してください。 ---> 実装方針をコメントに記載しました。 Buttonコンポーネントはすでに〇〇で実装されています。修正お願いします。 ---> 修正案をコメントに追加しました。 実装提案確認しました。 実装のボリュームが大きくなってきたので、Issueを小分けにしていただけますか？ ---> ご提案いただいた通り、以下の3つのIssueを作成します。 では1の実装からお願いします。 といった流れを踏んでから作業を任せています。 3. DevinにIssueを書かせる Issueなどがない場合、いきなり作業させるのではなく、 まずIssueを書かせる 運用にしています。 背景 ゴール 作業内容 上記を自分で整理させ、そのIssueをそのまま着手させることで実装精度が安定しました。 4. 「やらないこと」を明確にする Devinは善意で リファクタリング 不要なテストの追加 エラーハンドリングの強化 など、 依頼していない作業 をすることがあります。 例えば「今回はテストは追加しないで」「リファクタリングは不要」など、 やらないこともセットで指示 するようにしています。 5. 作業ログは逐次出力させる 作業中に「何も言わずに進めてしまう」ことがよくあります。 常に「今、何をやっているか説明して」「進捗を逐次共有して」とお願いすることで、進捗の見える化と、早期の異常検知ができています。 Devinを活用したタスク例 リアーキテクチャ 現状整理・リファクタ方針作成・Issue分割・実装・テスト ライブラリアップデート Release Note読解・プロダクト内の利用箇所特定・影響レポートの作成 改善アイテム 社内やお客様から上がっていた改善アイテムの実装 Devinが特に得意だったタスク 振り返ってみると、下記のように インプットとアウトプットのイメージが明確なタスク は、特に安定して対応できるようになってきました。 API実装 バリデーション追加 ロジック単体の改善 設定・スクリプト系の作業 一方で、デザインやUI実装など、Figmaを読む前提のタスクは現状ではそこまで得意ではありません。 BoltなどはFigmaを読み取り対応していますが、Devinも今後は対応するのではないかと期待しています。 よくあった失敗と改善 課題 原因 改善策 勝手に設計変更 方針すり合わせ不足 事前にテキストで確認し、ナレッジ化 実装精度の低下 タスクが重すぎた 10〜15分単位に分割 同じ質問を繰り返す コンテキストの欠落 or 曖昧な依頼 前提・背景・制約条件を毎回セットで共有し、必要なら「ナレッジとして記憶させる」 余計な作業を実施 やらないことを指示していない やらないことも明示する Devinに実際に渡したIssue例 # Issue: ラジオボタンのキーボード操作に対応 ## 内容 現在のラジオボタンがキーボードで正しくフォーカスされない。アクセシビリティ改善のため、Tabキー操作での移動＆選択に対応したい ## やること - components/RadioGroup/index.tsx を修正 - role =radiogroup、aria-checked などの属性を適切に付与 - Tab / Shift+Tab / Enterキー で操作可能にする ## 補足 - スクリーンリーダーでの読み上げ確認は不要（別Issueで予定） ## やらないこと - ラジオボタンのデザイン変更 - フォームロジックの修正 Devin導入の効果 着手のハードルが高かったタスクにも手が伸びるように 「気になっていたけれど後回しになっていた」タスクが少しずつ片付いていくようになりました。 小規模な改善Issue ライブラリのアップデートと影響調査 デッドコードの整理や命名統一 など Devinを活用することで、こうしたタスクに手が届きやすくなり、コードベースの健全性向上にもつながっています。 重ための開発にも踏み込みやすくなった プロダクト全体のリアーキテクチャ方針の策定・実装 モジュール単位での構成見直し レガシーな一括バッチの分解・再構成 Devinにまず「現状把握」→「方針案の提示」→「タスクへの分割」までを任せることで、全体像がつかみやすくなり、チームとして動き出すための一歩が軽くなりました。 PR作成数が約1.5倍に増加 定常的な改善タスクをDevinに任せられるようになったことで、メンバーはより注力すべき領域に集中しやすくなりました。 単純なPR数の増加だけでなく、「対応が早くなった」という声もあり、チーム全体のリズムが良くなってきた感覚があります。 「まずDevinに任せてみる」が自然な選択肢に 「ちょっと時間かかりそうなタスク」を見つけたら「まずDevinに投げてみる」が自然なフローに Slack上でも「このIssueDevin向きかも？」というやり取りが増加 文化として根付いた と感じられるのは、大きな成果のひとつでした。 まとめ Devinは、すべてを自動で解決してくれる存在ではありません。 ですが、タスクの粒度を整え、進め方を丁寧に伝えることで、着実に動いてくれる「チームの一員」になり得ます。 導入したことで、これまで着手しにくかったタスクにも少しずつ向き合えるようになり、 さらに大きな変化としては、人が「人にしかできないこと」に集中する時間が増えてきたことがあります。 たとえば、プロダクトの方向性を考える、設計を詰める、チームで議論するといった創造的な時間です。 そうした本質的な領域に、より多くのリソースを割けるようになったことはチームにとって大きな前進でした。 AIに任せるところは任せて、人は人としての強みを発揮する。 Devinは、そのバランスを取り戻すための、ちょうど良いきっかけになってくれています。

株式会社スタメンのTUNAGプロダクト開発部で Android アプリを開発しているカーキ（X: @khaki_ngy ）です。 自分はスタメンには2020年に新卒入社しており、6年目の春が始まりソワソワした気持ちを抱いています🌸 直近、TUNAGの機能開発で AlarmManager の API を利用し、指定した時間にローカル通知を発行する機能を開発しました。 AlarmManager 自体はかなり古くからある API ですが、権限周りで Android12 から変更が加えられるなど近年のセキュリティ強化の影響も受けています。 今回のブログでは、AlarmManager を利用する一連の流れと、プロダクションで運用するための注意事項を紹介します。 AlarmManager とは AlarmManager とは android.app API に存在するクラスであり、指定した時間に特定の処理を実行することができます。 アプリが起動していない状態（バックグラウンドにいる状態）でも、指定の時刻に処理を行うことができます。ユースケースとしては時計アプリのアラーム機能などでユーザーが指定した時刻にアラームや通知を発行するような時に利用されます。 今回 TUNAG では、指定された日時にローカル通知を発行するために採用しましたが、本当に AlarmManager を使うべきかどうかの見極めが必要です。 なぜならば、先述した通り AlarmManager は指定した時刻でバックグラウンドで強力な処理を実行できるポテンシャルがあるためです。正確な時刻にバックグラウンドで処理を起動できること自体が、バッテリーやリソースに影響を与える可能性があるため、AlarmManager を使って正確な時刻にアラームを設定するには後述する特別なアプリアクセス権の取得が必要になります。ユースケースに応じて、本当に AlarmManager を利用するべきかどうかを一度考えた方が良いでしょう。 代替手段との比較では、正確な時間指定が必要かどうかが軸になってきます。 正確な時間指定が必要でない場合、代替手段として公式ドキュメントでは Handler クラスの利用や、 WorkManager での定期実行のスケジュールなどが紹介されています。WorkManager はライフサイクルの考慮や、処理を開始する上でのシステム的な制約を指定することができるので、遅延実行して問題のないバックグラウンド処理であれば WorkManager を利用するのが良いでしょう。 AlarmManager と権限 権限の種別 AlarmManager を利用して正確な時間に処理をスケジュールするには、以下の権限のうちどちらか一つが必要になります。 USE_EXACT_ALARM SCHEDULE_EXACT_ALARM どちらの権限も AlarmManager を通して、正確な時間に処理をスケジュールするのに必要な権限になりますが、どのような機能を提供するアプリかに応じてどちらの権限を利用するかが変わります。 前者の USE_EXACT_ALARM は、 アラーム・カレンダー機能が主となるアプリ向け の権限になります。Android の APIレベル33（Android 13相当）から登場した権限です。 アラーム・カレンダーアプリが主の機能となっていれば、指定の時刻に処理を行なったり、通知を送ったりする機能はほとんど必須の機能となります。そのため、AndroidManifest で権限の利用を宣言していれば、ユーザーの許可なしで正確な時間の処理が可能になります。 ただし、前提となっている アラーム・カレンダーアプリがメインの機能かどうか という点がアプリの審査で判断されることになります。アラーム・カレンダー機能が主となるアプリでない場合は、こちらの権限を利用してもストアへの公開は難しいでしょう。 後者の SCHEDULE_EXACT_ALARM は、前者の対象となる「アラーム・カレンダー機能が主となる」アプリ 以外 を対象とした権限になります。こちらはAndroidのAPIレベル31（Android 12相当）から登場した権限です。 こちらの権限では、アラームやカレンダー機能を主としたアプリ以外での利用を想定されています。 こちらの権限は Android の API 34以降（Android 14相当）では、デフォルトで拒否されるようになっており、ユーザー自身がアプリに「アラームとリマインダー」の権限を許可する必要があります。 「アラームとリマインダー」は特別なアプリアクセス権に分類され、通常の権限リクエストとは若干方法が異なり、設定画面でユーザーに『許可』をしてもらう必要があります。 システムのアプリ設定内にある「アラームとリマインダー」 正確な時間のアラームであっても AlarmManager の OnAlarmListener オブジェクトを利用する場合は、 SCHEDULE_EXACT_ALARM は不要になります。ただ OnAlarmListener を利用したアラームの場合はアプリのプロセスが生きている期間の間は有効になりますが、アプリキルをされた場合などプロセスが終了している状態では、アラームを起動させることができません。この後の内容に関しても OnAlarmListener を利用せず、バックグラウンドでも機能するスケジューリング処理について紹介をしていきます。 権限のハンドリング 先述の通り、AlarmManager による（バックグラウンドで動作する）正確な時間での処理のスケジュールには、 SCHEDULE_EXACT_ALARM 権限が必要になります。 権限を獲得するフローは大体以下の流れです 1. ユーザーがすでに権限を持っているか確認する 2. 持っていなければ、権限のリクエストを要求する 1. 権限の確認 通常、権限の許可がされているかを確認する場合には ContextCompat.checkSelfPermission を利用して、対象のパーミッションが許可されているかどうかを確認します。ただ SCHEDULE_EXACT_ALARM は特別な権限となるため、AlarmManager に用意されている専用のメソッド canScheduleExactAlarms() を利用して確認する必要があります。 （ ContextCompat.checkSelfPermission で確認しても常に許可されていないと返ってきてしまいます） 具体的なコードのイメージとしては以下のようになります。 val alarmManager = getSystemService(ALARM_SERVICE) as AlarmManager // Android 12 より前、もしくは権限が許可されている場合 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.S || alarmManager.canScheduleExactAlarms()) { // alarmManagerによるスケジューリングを実施 } else { // 権限をリクエストする } 2. 権限のリクエスト 権限が許可されていない場合は、ユーザーに権限をリクエストする必要があります。 一般的な権限のようにアプリ内のダイアログで権限リクエストをする仕組みが用意されていないため、設定画面に遷移させて、ユーザーに設定を変更してもらう必要があります。 以下のように『アラームとリマインダー』に関する設定ページに直接遷移するようなIntentを発行することで、ユーザーを設定画面に導くことができます。 val intent = Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM) startActivity(intent) 上記では単純な Intent 遷移の例を示していますが、Activity Result API による遷移を利用すれば、設定画面から戻ってきたタイミングをハンドルできるので、より状況に適した処理を実装できると思います。 権限リクエスト時の注意点 SCHEDULE_EXACT_ALARM はシステムでの権限付与のダイアログが提供されていないため、アプリからユーザーに対して権限リクエストの旨を伝えるのが良いでしょう。 権限の付与が必要なタイミングで突然システムの設定画面に飛ばされてもユーザーは困惑してしまうためです。 そのため、下記のようなダイアログを一つ挟んで、アラームの設定を行うかどうかをユーザーに事前に確認をすると良いです。 ユーザーに向けたダイアログの例 AlarmManager を利用する 指定した時間にアラームをスケジュールする AlarmManagerによりアラームをスケジュールする流れとしては、以下の2ステップです。 PendingIntent を作成 AlarmManager インスタンスからスケジューリングのメソッドを実行 それぞれについて解説していきます。 1. PendingIntent を作成 指定した時間にアラームを受け取る際に BroadcastReceiver を利用し、バックグラウンドでも BroadcastReceiver を受け取れるように PendingIntent を作成します。 この際、アラームのスケジュールを設定する上で考慮するべき点がいくつかあります。 val pendingIntent = PendingIntent.getBroadcast( context, requestCode, intent, PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_IMMUTABLE ) まず getBroadcast の第二引数になっている requestCode です。 これは予約するアラームを一意に識別する役割があります。そのため、例えば、同じ requestCode で複数アラームをスケジュールしても、最後にスケジュールした PendingIntent しか有効になりません。 また後からスケジュールしたアラームをキャンセルしたい場合にも同じ requestCode から作成された PendingIntent が必要になります。 次に第三引数として指定している intent についてです。 この Intent は、アラームが起動した時に実行させたい BroadcastReceiver に向けられた Intent を指定してください。 val intent = Intent(context, MyAlarmReceiver :: class .java).apply { putExtra(MESSAGE_KEY, "アラームです" ) } この intent に対して、 action や extra を指定することができるので、これらを指定することで、 BroadcastReceiver の中で処理に必要な情報を渡すことができます。 第4引数の PendingIntent のフラグに何を渡すのかでもアラームの挙動が少し変化します。 PendingIntent.FLAG_IMMUTABLE は、PendingIntentの中身が他のアプリによって変更されることを防ぐフラグになります。Android API 31以降では PendingIntent.FLAG_IMMUTABLE 、 PendingIntent.MUTABLE のどちらかが必須となっています。アプリによってどちらを選択するべきかは異なりますが、他のアプリによって遷移先が勝手に書き換えられてしまう可能性があるので、基本的には PendingIntent.FLAG_IMMUTABLE を設定しておいた方が良いでしょう。 また PendingIntent.FLAG_CANCEL_CURRENT は既に同じ requestCode で生成されたPendingIntentがある場合に前の内容をキャンセルして、新たなPendingIntentとして登録するために設定をします。 近いものとしては PendingIntent.FLAG_UPDATE_CURRENT というフラグも存在します。こちらは同じ requestCode で生成されたPendingIntentがある場合に、中のIntentだけを新しいものに更新するフラグになります。 requestCode を被らないように設定している場合であれば、どちらを選んでも結果は変わりませんが、同じ値が入る可能性があれば、どちらを選択するべきかをよく考える必要があります。 2. スケジューリングのメソッドを使う アラームをセットするメソッドは複数存在し、アラームが「繰り返しなのか」「正確な時刻が必要なのか」に応じて適切なメソッドを選択する必要があります。 今回は１回きりのアラーム set を中心に紹介をします。 一回きりのアラームの set をいくつか種類があります。 set : 最も効率の良い１回きりのアラームメソッド。効率は良いものの、端末の状態に大きく左右されるため、指定した時刻通りに発火することは保証されていません。 setExact : set メソッドよりは正確に発火することを目的としたメソッド。ただ端末がDozeモードに入ってしまうと発火しないので注意が必要。 setAndAllowWhileIdle : Dozeモードなど、端末がアイドル状態の場合でもスケジュール通りに発火するメソッド。端末の状態に関わらず実行させたい場合はこれを利用する。 また set メソッドの第一引数にはAlarmManagerのTypeを指定する必要があります。 こちらは４種類のタイプがあります。 ELAPSED_REALTIME : デバイスが起動してからの経過時間に基づいてPendingIntentを開始する、デバイスのスリープは解除しない。 ELAPSED_REALTIME_WAKEUP : デバイスが起動してから指定された時間が経過した後にデバイスのスリープを解除し、PendingIntentを開始する RTC : 指定された時間にPendingIntentを開始する。ただし、デバイスのスリープは解除しません。 RTC_WAKEUP : 指定された時刻にデバイスを復帰させてPendingIntentを開始する。 それぞれアラームの特性に合わせて実装をするのが良いと思います。 まとめると アラームを発行する流れをまとめると以下のようになります。 val alarmManager = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager val alarmIntent = Intent(context, MyAlarmReceiver :: class .java) val pendingIntent = PendingIntent.getBroadcast( context, requestCode, alarmIntent, PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_IMMUTABLE ) alarmManager.setExactAndAllowWhileIdle( AlarmManager.RTC_WAKEUP, notifiedDateTime.toInstant().toEpochMilli(), pendingIntent ) アラームされたタイミングで実行される処理 アラームされたタイミングで実行される処理は BroadcastReceiver で実施されるので、こちらの準備も必要になります。 class CalendarEventAlarmReceiver: BroadcastReceiver() { override fun onReceive(context: Context, intent : Intent) { // アラーム発火時に行う処理 } } BroadcastReceiver の利用には AndroidManifest での利用の宣言も必要になるので忘れずに行いましょう。 まとめ 今回は、AlarmManager を使った実装の紹介を行いました。 古くからあるAPIではあるものの、Android API 23 からの Doze モードの登場や、Android API 31 以降の権限の強化によって、ここ数年でも実装や扱い方が変わってきているAPIになります。 AlarmManagerのドキュメントには USE_EXACT_ALARM や SCHEDULE_EXACT_ALARM を利用する場合の注意点が書かれており、アプリケーションが提供したい機能に応じて、どのような方法でスケジュールをするのか（あるいは、AlarmManagerを使わないのか）を判断して利用する必要があります。 株式会社スタメンでは一緒に働く仲間を募集しています。少し気になる、話を聞いてみたい！という場合は以下のフォームからご連絡ください herp.careers

こんにちは、スタメンでエンジニアリングマネージャーをしているasashin（@asashin227）です。 近頃は暖かくなり、もうすっかり春の気候ですね。 最近、桜の盆栽を手に入れて、視覚的にも春を感じられるようになりました。 EMConfに参加してから1ヶ月ほど経過しましたが、日々の業務の中でもEMConfでの学びを振り返る事があり、自分の考えとして定着したものや腹落ちしたものなどありましたので、改めて登壇された方のスライドを見ながら振り返っていこうと思います。 2025.emconf.jp EMConf2025は2025/02/27に開催されました。（実は当日は誕生日でした） 参加レポートとしては、 @hisa が執筆した 非EMがEMConf JP 2025に参加して学んだこと 〜エンジニア視点で見るEMの役割と未来〜 をご覧ください。 tech.stmn.co.jp EMの役割 一般的にはEMの役割として以下の項目を挙げられることが多いです。 プロダクトマネジメント プロジェクトマネジメント テクノロジーマネジメント ピープルマネジメント これは、EMConfでキーノートを務められた広木大地さんが執筆した エンジニアリングマネージャー/プロダクトマネージャーのための知識体系と読書ガイド によって広く知られるようになりました。 qiita.com 今回、広木さん自らこれをアップデートし、テクノロジーマネジメントからプラットフォームマネジメントとなりました。 プロダクトマネジメント プロジェクトマネジメント プラットフォームマネジメント ピープルマネジメント hirokidaichi.github.io プラットフォームマネジメントという考え方 これまでの役割として提示されていたテクノロジーマネジメントとしては、技術負債のコントロールや、技術戦略、アーキテクチャ選定、モニタリングなど、エンジニアリングに対して直接的に関与するようなことが多かったように考えていますが、プラットフォームマネジメントという表現では、エンジニアリングはメンバーに任せつつ一歩引いたマネジメントを行う表現になったように感じています。 直接的に技術的負債を解消するための働きかけも必要ですが、技術的負債を生み出さないためのデリバリーフローの構築や、ツールの整備などを主戦場とすることと、これらが必要なタイミングでチームに提供できるように、定点観測したり、早期に失敗できる（Fail fast）できるように準備しておくことが必要となります。 また、スタメンではプラットフォーム部が存在し、プロダクト部全体に対して開発者体験の向上を行っていますが、EMの役割としても管掌組織に対しての、開発者体験と生産性の向上を担っていくとことが、プラットフォームマネジメントと捉えました。 開発者体験の向上のためのツールの導入支援やCI/CDの構築などが具体的な方法論としてはありますが、これらを戦略的に導入しつつ、メンバーにかかるコストを中長期で低下させるための技術基盤を構築、維持し続けることが、プラットフォームマネジメントと言えるのではないでしょうか。 現在の私の管掌チームでは、CI/CDの整備などのデリバリーフローの効率化を行えていますが、技術的負債のマネジメントまで踏み込むことができていないため、今後の課題となってきそうです。 エンジニアリングの価値をどう考えるか 開発生産性を語る上で、どのように経営指標と接続していくのか、例えば機能がどれほど売り上げに貢献したのかや、DXによってコスト削減し、利益率を上げるなどありますが、 エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり(by Kazuki Maeda) の中でも損益計算書（P/L）のように捉えて開発組織内で黒字化させるという手法について、以前から頭の中にはあったのですが、視覚化されることで改めて、気づきがありました。 speakerdeck.com 経営との接続を考えるとどうしても金額的なものに置き換えて語りたくなってしまうのですが、そうではなく価値提供速度を挙げていた点が、腹落ちしました。 価値のボリュームを計ろうとするとどうしても利益率や売り上げに紐付いてきてしまい、変数が多くエンジニアリングの貢献度合いが曖昧になってしまうため、この観点は非常に良いものだと感じました。 開発や運用コストを抑えつつ、早く早く価値を届けることがエンジニアリングの価値として定義してみるという試みがありそうと考えています。 サバイバルフェーズの心得 speakerdeck.com ここでの文脈でのサバイバルフェーズとはKPIの未達成や事業計画のビハインド、収益構造の悪化など事業面の事象やメンバーの疲弊と離職という状態を指しており、過去の似たような状況に遭遇したため思い出しながらセッションを聴いていました。 足元の数値改善は当然として、根本的なコスト構造改善のための方針を打ち出されていたとお話を聞くだけでかなりハードな状況だった事が伺えました。 その中でも大変参考になったのが、考える時間軸を伸ばすというお話でした。 目の前の課題に取り組み続けることのみに注力するとメンバーやマネージャー自身の目線が下がり、すべての施策が後手に回ってしまうという事が経験上ありました。 やるべきタスクが消化されず目先のわかりやすい問題に目がいってしまい、本質的な課題解決ができない状態となってしまいます。 こにふぁーさんの発表では１年半先に向けて組織とプロダクトの目線を合わせることでその中で必要な役割にチャレンジしてもらったり、重要度の高いが緊急性の低い問題に取り組む事ができるようになったと紹介されていました。 また、少し先のチャレンジングな目標が共有されることでメンバーの熱量が大きくなり、自らチャレンジしてくれるメンバーもいたとのことでした。 直近のプロジェクトが半年以内に終了するサイズ感のものが多く、１年以上先の話をメンバーとする機会が少なくなっているので（現状サバイバルモードというほどでもないですが、）私自身もっとメンバーと未来の話をせねばと思いました。 これからのエンジニアリングマネジメント キーノートの広木さん、岩瀬さんがお二人とも触れていたことでもありますが、昨今のAIの成長によってエンジニアリングマネジメントはEMだけが行うものではなくなっていくと感じました。 スタメン社内でもAIを用いた開発が徐々に浸透し始め、私自身も、ClaudeやGithub Copilotを活用しながら開発を行なっています。 チームの一部メンバーは Devin.ai を使い始めており、人間が指示して、AIが実装するということが現実になっています。 コミュニケーションしている様はまさに先輩エンジニアと後輩エンジニアのオンボーディグのように見えます。 このように、意図せずとも、AIに対しての教育やタスクの分解、指示だし、進捗管理など、マネジメントの要素は徐々にエンジニアメンバーの業務にも染み出してきています。 広木さんのキーノートにも記されている通り すべてのエンジニアは、AIをメンバーに持つエンジニアリングマネージャーになる。 ということが現実的にすでに起こっていると考えています EMでなくともEMっぽいことが求められるという未来がそう遠くない中で、我々、現在のEMはメンバーに対して、EMっぽいことをできるようになろうということを伝えていかなければなりません。 プロジェクトマネジメントやAI教育と指示出しのための言語化能力は必ず必須スキルになっていきますし、簡単な実装はAIに置き換わっていくため、より高度な技術を身につけなければなりません。 最後に テック系のカンファレンスに参加することはありますが、マネジメント系のカンファレンスは（現地参加としては）初めてだったため、他の参加者の方との交流ができたことが、最も良かったと感じる部分でした。 特に、スタメンでは専任のEMが私一人ということもあり、同じ立場だからこその悩みや具体的な取り組みの事例などのお話を聞くことができて、楽しい1日となりました。 スタメンでは、プロダクト開発に関わる全ての領域でプロダクト職種の採用をしています。 もしご興味を持っていただけたら、下記からご応募ください！ herp.careers

この度、株式会社スタメンは昨年に引き続き、RubyKaigi 2025にPlatinumスポンサーとして協賛します。 昨年のRubyKaigiのレポートはこちらから👇 tech.stmn.co.jp スタメンは、企業や組織の業務DX、エンゲージメント向上を支援するクラウド型プラットフォーム「TUNAG（ツナグ）」を開発・提供しています。「TUNAG」はバックエンドの開発言語にRubyを使用しております。 事業と開発組織が成長できたのは RubyとRubyコミュニティの支えがあってこそであり、今後のさらなるコミュニティの発展に貢献するため「RubyKaigi 2025」へ協賛いたします。 本カンファレンスへの協賛を通して、これからのRubyコミュニティの発展を後押ししていきます！ イベントを一緒に盛り上げていきます！ RubyKaigi 2025 開催概要 名称 RubyKaigi 2025 開催日時 2025年4月16日(水) 〜 18日(金) 場所 愛媛県県⺠⽂化会館 (愛媛県松⼭市) 参加方法や詳細については、下記公式サイトをご覧ください 👇 rubykaigi.org 今年のブース企画について 昨年、好評だったスタメンのブースを今年も出します！ 『 TUNAG 』の機能の一部を利用した、参加型ブースイベントとなっており、実際のプロダクト機能を使った抽選イベントで、来場者の皆さまにワクワクと楽しさをお届けします！ 参加いただいた方には、参加賞や景品も用意しておりますので、ぜひ遊びにきてください！（数には限りがございます。） 皆さまのお越しを心よりお待ちしています！ おわりに 最後まで読んでいただきありがとうございます。 弊社からはエンジニア、HR含め8名が現地参加します！ ブースやイベント等でお話できることを楽しみにしています！ 当日会場ではどうぞよろしくお願いいたします。 スタメンでは、RubyやRubyコミュニティが好きなエンジニアを絶賛募集中です。 herp.careers 参考：エンジニアのカジュアル面談Q&Aから見るスタメンの姿 note.com

はじめに こんにちは、プラットフォーム部の 近藤 です。 2018年に初期リリースしたチャット機能は、システムの拡張性と安定性の向上が課題となっていました。そこで、これらの課題を解決し、より快適なサービスを提供するために、2025年3月に「TUNAGチャット」をリリースしました。本記事では、このリプレースにおいて、マルチテナント型の SaaS アプリケーションをどのように構成したのかをご紹介します。 prtimes.jp 図1にアーキテクチャ全体の構成を示しました。Google Kubernetes Engine (GKE) を中心に構成しています。実際にはもっと多くのコンポーネントを用いていますが、この記事で取り上げたい内容に限定して図にしました。弊社ではこれまで、Amazon Elastic Container Service (Amazon ECS) を採用することがほとんどで、GKE の導入は今回が初めてです。 図1 全体の構成図 マルチテナントを構築する上で考慮すべきトピックは多岐にわたります。本記事では、インフラストラクチャの共有・占有という主にテナント分離の観点に焦点を当てて説明させていただきます。 ドメイン 図1で示したとおり、アプリケーションはテナントごとに分離されています。このようなサイロモデルにおいては、テナントルーティングが必要です。テナントルーティングの戦略として、(1)ドメイン駆動型ルーティング、(2)データ駆動型ルーティングの2つが考えられます *1 。図2に、それぞれの比較を簡単にまとめました。詳しくは、Amazon Web Services ブログなどもご参照ください *2 。 図2 テナントルーティング戦略の比較 今回は認証をアプリケーション側で実装する必要があったため、ドメイン駆動型ルーティングを選択しました。具体的には、各テナントに固有のサブドメインを作成し、テナントを識別しています。そしてサブドメインには、意味のない文字列ではなく、テナントごとにパーソナライズされたバニティサブドメインを使用しています。例えば、株式会社スタメンの場合、「stmn.example.com」のようなサブドメインとなります。バニティサブドメインはシステム側ではなく顧客が決定するため、運用や開発にコストが発生しますが、ユーザーエクスペリエンスを重視し、この方式を採用しました *3 。 ロードバランサー ロードバランサーは、全テナント共有のインフラストラクチャとなっています。インフラストラクチャを共有する理由は、主にコストの最適化のためです。Cloud Load Balancing は、受信・送信データ量に加えて、「転送ルール数 × 利用時間」に対する従量課金のため *4 、テナント間で共有することでコストは抑えられます。 Kubernetesクラスター内で実行されているサービスへの外部アクセスには、一般的に Ingress が使用されることが多いかもしれません。今回は図1に示すとおり、各テナントは Namespace で分離されています。Ingress は Namespace を跨いで利用することが単純にはできないため、このような場合には Gateway の使用が選択肢として考えられます *5 。Gateway は Ingress のスーパーセットとして提供されている点 *6 も、採用理由の一つです。ただし、GKE Gateway では Cloud CDN をサポートしていない点 *7 には留意が必要です。 アプリケーション 今回のアプリケーションの要件として、テナントごとに Pod を用意して、サーバーを立てる必要がありました。Pod を分離した主目的ではありませんが、テナントごとに最適なコンピューティングリソースが適用できたり、ノイジーネイバーの対策にも繋がっています。 また、各テナントの Pod は Namspace によって分離しています *8 。テナント専用 Namespace によるサイロ化には、いくつかのメリットがありました。 第一に、分離された環境により、セキュリティを強化できます。テナント間のデータ漏洩は、SaaS において非常に大きなビジネスリスクの一つです。 第二、モニタリングでの利便性です。Google Cloud のコンソール上で、Namespace 単位で各種メトリクスが確認でき、より柔軟かつ素早く分析することが可能です。 第三に、Kubernetes オブジェクトの名前の衝突を意識する必要がなくなるなど、オブジェクトの管理が容易になります。今回のアプリケーションでは、新規にテナントを追加する場合は、テナント専用の設定ファイルを追加してワークフローを実行します。解約に伴いテナントを削除する場合は、Namespace を削除することで、属するオブジェクトを一括で削除できます。こうした管理も、Namespace による分離が効果を発揮しています。 図3 ファイル管理のイメージ データベース マルチテナントにおけるデータベースの分離パターンはいくつか考えられます。(1)単一インスタンス共通データベース方式、(2)単一インスタンス個別データベース方式、(3)インスタンス分離方式などです *9 。また、RDB にとらわれず、マネージドなサービスも選択肢になり得るかもしれません *10 。今回は、アプリケーションの特性として、RDB の利用が前提となっていました。 データベースの分離パターン 単一インスタンス共通データベース方式は、インフラ費用や運用コストにメリットがあります。このパターンの場合、データ分離は PostgreSQL の Row Level Security を利用したり、アプリケーションレイヤーで対応することになります。これまで弊社のRailsアプリケーションでは、主にこのパターンを採用してきました。 今回は、アプリケーションレイヤーでデータ分離を対応することが困難だったため、単一インスタンス個別データベース方式を採用しました。テナントごとにデータベースユーザを作成し、各アプリケーションはそのユーザを利用して、データベースにアクセスします。各テナントは、別テナントのデータベースを参照することは、権限の制約によりできません。一方で、インスタンスを共有しているため、ノイジーネイバーなどはリスクとなり得ます。インスタンス分離方式は、インフラ費用や運用コストが高いため採用は現実的ではありませんでした。 図5 分離されたアクセスのイメージ 単一インスタンス共通データベース方式を採用している弊社の Rails アプリケーションでは、activerecord-multi-tenant *11 という Gem を用いて、アプリケーションレイヤーでデータ分離を実現しています。ただし、Gem による制約の適用を確実にするため、弊社では独自のテストコードを実装するといった様々な工夫が必要になっており、その対応は簡単ではありません。 単一インスタンス個別データベース方式にも課題はあり、1つのインスタンス内のデータベース数とテーブル数がスケールしたことで、マイグレーションにかかる時間の増加などの課題が生じた事例をSmartHR社が紹介しています *12 。今回はそこまでのスケールは不確実であり、懸念には考えていません。また、アプリケーションの特性として、テナントは明確に分離されており、今後は複数インスタンス構成も比較的容易に導入できると考えています。 図6 複数インスタンス構成 最後に 私にはGoogle Cloud と Kubernetes の経験がほとんどなかったのですが、さまざまな選択肢の Pros & Cons やトレードオフを整理して構築を進めていくことは非常に良い経験になりました。 9年目を迎えた弊社の TUNAG では、ありがたいことに導入企業数やユーザー数が着実に増えています。このようなスケールに伴い、今後の中長期的なスケーラブルなアーキテクチャのための取り組みを積極的に行っています。また、マルチプロダクト戦略にも本格的に取り組んでおり、0 → 1でアプリケーションを構築する機会も今後ますます増えていくはずです。 クラウドを中心としたアーキテクチャ構築に興味を持っているエンジニアにとっては、非常にやりがいのある環境だと感じています。少しでも興味を持っていただけたら、ぜひまずはカジュアル面談でお話しできればと思います。 herp.careers 参考 Golding Tod. (2024). Building Multi-Tenant Saas Architectures: Principles, Practices, and Patterns Using AWS . California: O'Reilly Media. (ゴールディング・トッド. 河原 哲也・櫻谷 広人(訳)(2025).マルチテナントSaaSアーキテクチャの構築―原則、ベストプラクティス、AWSアーキテクチャパターン) *1 : AWS における SaaS アプリケーションのテナントルーティング戦略 *2 : SaaS におけるテナントリソースへのリクエストルーティングを JWT を用いて実現する *3 : バニティサブドメインは、SlackやZoomなど広く採用されている。今回のアプリケーションの仕様では、ログイン時にサブドメインを入力するため、記憶しやすいバニティサブドメインを用いた方がユーザーエクスペリエンスは向上する。SmartHR社の スマートフォン向けアプリのログインにサブドメインの入力が必要になりました（03/21更新） のような体験に近い。 *4 : All networking pricing *5 : Cross namespace communication in GKE ingress *6 : About the Gateway API Comparison of Ingress and Gateway *7 : Deploying Gateways Restrictions and limitations *8 : Google Kubernetes Engine 上で SaaS プラットフォームを作成する *9 : Windows Azureエンタープライズアプリケーション開発技法 マルチテナント・アーキテクチャ を参考にした。"データベース"という単語が PostgreSQL で用いられる"データベース"との混同につながる。よって説明の便宜上、参考記事の語彙を、「データベース → インスタンス」、「スキーマ → データベース」に置き換えて本記事では表現をさせていただいた。 *10 : RDBを使わない究極のマルチテナント *11 : activerecord-multi-tenant *12 : SmartHR が定期メンテナンスを始めた理由とやめる理由

はじめに プロダクト開発部でTUNAGの開発をしている hisa です。最近、花粉の症状が出始めて悩まされています。目のかゆみと戦いながらも、先週EMConf JP 2025に参加してきました。 エンジニアリングマネジメント（EM）は、エンジニアのキャリアの中でも特に難易度が高い領域の一つだと感じています。私はEMではありませんが、「プロダクトに関わるすべての人が幸せになれば」という思いを持ち、そのためには「良いプロダクトを作るには良い組織が必要」と考えています。その延長として、EMについての理解を深めたいと思い、EMConf JP 2025に参加しました。 今回のカンファレンスを通じて、EMという役割の多様性と、その難しさを改めて実感しました。また、EMだけの問題ではなく、エンジニアとしても組織やプロジェクト運営に関わることの大切さを学びました。本記事では、非EMの立場から見たEMの役割や学びについて、特に印象に残ったポイントを紹介します。 エンジニアとしての学び 1. 不確実性との向き合い方 「エンジニアリングは不確実性との戦い」と言われることがありますが、EMにとっても同じであることが分かりました。 カンファレンスでは「フェイルファスト（Fail Fast）」という考え方が強調されていました。特に印象的だったのは、不確実性を無理に排除しようとするのではなく、向き合い、小さな成功体験を積み重ねていくことが重要だという話です。 エンジニアリングにおいても、技術選定や仕様策定の際に「最適解が分からないから決められない」と迷うことは多々あります。しかし、その状態を避けるのではなく、「とりあえず試す」「失敗してもすぐにリカバーできる環境を整える」といったアプローチが大切だと感じました。 2. タスク管理ではなくリスク管理 「プロジェクトマネジメントとはタスクを管理するのではなく、リスクを管理すること」という話がありました。 ソフトウェア開発は目に見えないことが多く、進捗の管理が難しいですが、そもそも「進捗を管理しようとする」こと自体が間違っているのかもしれません。 重要なのは、何がリスクになり得るかを見極め、それを最小化すること。 特に、以下のポイントが印象に残りました。 進捗共有を頻繁に行うこと プロダクトの完成形が見えにくいからこそ、こまめな共有が必要 チームメンバーだけでなく、ステークホルダーにとっても進捗が可視化されている状態を作る タスクよりもリスクを中心に考えること 「このタスクが終わるか？」ではなく、「どこでつまずく可能性があるか？」を考える これはプロジェクトマネージャーだけでなく、エンジニアとしても意識できるポイントだと感じました。 3. 技術的負債とエンジニアリングマネジメント 技術的負債に関する話も多く出てきました。「技術的負債とアーキテクチャは対の存在」という考え方はとても腑に落ちるものでした。技術的負債は見えてしまえば管理できる。逆に言えば、見えていないから管理が難しくなる。 エンジニアとしても、以下のような点を意識することで、EMや組織全体に貢献できるのではないかと感じました。 技術的負債の可視化 負債がどこにあるかを整理し、共有する ADR（Architecture Decision Record）の管理 どんな判断をしたのか記録を残し、振り返りやすくする 非機能要件の見える化 性能・運用コスト・可用性などの指標を数値化する EMは「エンジニアが働きやすい環境を作る」役割ですが、その環境づくりにエンジニア自身が協力することも重要だと感じています。 EMの役割とは？ EMの役割について話を聞く中で、「EMとは価値を実現するためになんとかすること」という表現が印象に残りました。 これは単にチームの管理をするのではなく、「必要なことを理解し、それを実現するためにあらゆる手段を講じる」役割だということです。 「なんとかする」とは？ 制約のある中で、目標を達成する手段を探す 必要なスキルがなければ、自ら学ぶか、適切な人をアサインする プロダクトの方向性が見えないときに、仮説を立て、検証のサイクルを回す 組織の成長に合わせて、マネジメントの仕組みそのものを変える つまり、EMは「何をすべきか」「どうすれば組織として目標を達成できるか」を考え、障害を取り除く仕事をしていると感じました。 これは、EMだけの話ではなく、エンジニアとしても「自分の仕事をどう価値につなげるか？」を考える上でヒントになる考え方だと思いました。 まとめ 今回のEMConf JP 2025を通じて、エンジニアリングマネジメントの奥深さを学ぶことができました。 EMという役割は「エンジニアが最大限の価値を発揮できる環境を作ること」にあると理解しましたが、そのためにはエンジニア自身も組織の在り方やマネジメントを意識することが重要だと感じました。 特に印象に残った学びは以下の3点です。 不確実性に向き合い、小さな成功体験を積み重ねること タスク管理ではなくリスク管理を重視すること EMだけでなく、エンジニア自身も組織の改善に関わること 良いプロダクトを作るためには、良い組織が必要。 そのためにEMが果たす役割は大きいですが、エンジニアとしても「組織やチームを良くするためにできることは何か？」を考えていきたいと思いました。 さいごに BuySell Technologiesさんのブースでガチャガチャがあり、硬貨が当たりました。 とても貴重そうなので大切にとっておきます✌️ BuySell Technologiesさんのブース スタメンでは、プロダクト開発に関わる全ての領域でプロダクト職種の採用をしています。 もしご興味を持っていただけたら、下記からご応募ください！ herp.careers

TUNAGのプロダクト開発チームでiOSアプリを開発している おしん です。 SwiftUIの標準コンポーネントである List を使う機会があったのですが、List を使ってデザイン通りに画面を実装することは予想以上に困難でした。 このブログでは、Listのデフォルトの挙動と適切な対処法について紹介します。 List とは UIKitの UITableView に相当するSwiftUIのコンポーネントで、縦方向のスクロール可能なリストを作成できます。 Listを使用することで、データ配列を自動的にレイアウトし、パフォーマンスが最適化されたスクロール可能なUIを構築できます。 以下のコードでは、 items の配列をリストに変換し、各要素を Text で表示しています。 struct ContentView : View { let items = [ "Pacific" , "Atlantic" , "Indian" , "Southern" , "Arctic" ] var body : some View { List(items, id : \. self ) { item in Text(item) } } } Listの使い所 無限スクロールの実装が必要な画面では、配列の要素の(個数 - 1)番目が画面に表示されたら、次の要素を配列の末尾に足すという方法を取ることが多いと思います。 その際、(個数 - 1)番目の要素のViewの .onAppear を適切に制御する必要がありますが、 ScrollView + LazyVStack を用いた実装では、要素追加時の .onAppear の発火タイミングの調整が難く、実用的ではありません。 そのような場合においてはScrollView + LazyVStack ではなく、子要素の.onAppearを適切にハンドリングできるList を使うことが推奨されます。 List の何が大変か 高いパフォーマンスを発揮する List は便利なコンポーネントですが、Listのデフォルトの挙動を調整する際に、以下のような難しさがありました。 行・セクションの余白やセパレータの扱い List 内に埋め込んだボタンが意図しない挙動をする それぞれの課題と対処法を紹介します。 行・セクションの余白調整 デフォルトでは以下のように余白やセパレータが適用されているため、デザインに合わせて調整が必要です。 出典： https://developer.apple.com/documentation/swiftui/list List { Text( "Pacific" ) .listRowSeparator(.hidden) // セパレータを非表示にする .listRowInsets(EdgeInsets()) // 行の余白をなくす(四隅のpaddingを0にする) } .listStyle(.plain) // Listのデフォルトのスタイルを変更 セクションの余白については、iOS15 以降では行の余白を消す API が提供されていますが、セクションの余白を消す API は iOS17 以降でしか利用できません。 そのため、以下のように inset を余白分だけマイナス値で相殺することで回避しました。 if #available(iOS 17.0 , * ) { List { Text( "Pacific" ) } .listSectionSpacing(.leastNonzeroMagnitude) // iOS17以降でのみ使用可 } else { List { Text( "Pacific" ) .listRowInsets(EdgeInsets(top : - 20 , leading : 0 , bottom : 0 , trailing : 0 )) // セクションの余白を相殺 } } ボタンが意図しない挙動をする問題 List ではデフォルトでスワイプアクションやコンテキストメニューのようなボタンが用意されています。 そのため、行に対して追加でボタンを配置すると List 側のボタンと競合してしまうことがありました。 List のデフォルトのアクションを無効化するか、明示的にカスタムボタンの動作を定義することで意図しない動作を防ぎました。 List { Button(action : {}) { Text( "Pacific" ) } } .buttonStyle(.plain) // rowのデフォルトのタップアクションを無効にする ボタンが反応しなくなる問題 1行に複数のボタンを埋め込むと、特定のボタンがタップに反応しなくなることがありました。 Rectangle を shape に設定することで回避しました。 List { HStack { Button(action : {}) { Text( "button1" ) } .contentShape(Rectangle()) // タップ領域を明示的に確保 Button(action : {}) { Text( "button2" ) } .contentShape(Rectangle()) // タップ領域を明示的に確保 } } .buttonStyle(.plain) 全体像 以上を踏まえ、Listのデフォルトの見た目を最大限抑えた場合の全体像がこちらになります。 // セクション間の隙間の調整が必要な場合は // iOS 17以上 → `listSectionSpacing` // iOS 17未満 → `listRowInsets`の当て方を調整 List { Group { HStack(spacing : 0 ) { Button(action : {}) { Text( "button1" ) } .contentShape(Rectangle()) // タップ領域を明示的に確保 Button(action : {}) { Text( "button2" ) } .contentShape(Rectangle()) // タップ領域を明示的に確保 } let items = [ "Pacific" , "Atlantic" , "Indian" , "Southern" , "Arctic" ] ForEach(items, id : \. self ) { item in Text(item) } } .listRowBackground(Color.clear) // 背景透過 .listRowSeparator(.hidden) // セパレータを非表示にする .listRowInsets(EdgeInsets()) // 行の余白をなくす(四隅のpaddingを0にする) } .listStyle(.plain) // Listのデフォルトのスタイルを変更 .buttonStyle(.plain) // rowのデフォルトのタップアクションを無効にする .environment(\.defaultMinListRowHeight, .leastNonzeroMagnitude) // rowのデフォルトの高さを0にする プレビュー まとめ 無限スクロールを実現するために List を採用した結果、List のデフォルトの挙動について深く理解する機会となりました。 SwiftUI の List は便利ですが、デフォルトの挙動が多く、その挙動を最小限にするには多くのモディファイアが必要であるとともに、そのデフォルトの挙動を十分に理解する必要があると感じました。 本ブログが List を使う際の参考になれば幸いです。 採用情報 スタメンでは、iOSエンジニアに限らず、全ての領域でエンジニアを募集しています。もし興味を持っていただけたら、下記からご応募ください！ herp.careers

スタメンのCTOの @tnir です。前回は 9年選手のTUNAG RailsアプリをRuby 3.4にアップデートした という記事を書きました。スタメンでは、従業員体験プラットフォーム「TUNAG」の開発にGitHub Copilotを導入し、特にCopilot WorkspaceとGitHub Copilot pull request summaries・GitHub Copilot code review（旧Copilot for Pull Request）を活用しています。 注）Copilot Workspaceは執筆時点（2025年2月）でpublic previewです。 先週末にOpenAI o3-miniがGitHub Copilot上でも利用可能になり利用を開始し1週間ほど経過したので、この記事では10年選手のモノリスアプリケーションを継続的に改善していく上で、GitHub Copilotがどのように役立っているかをご紹介します。previewである機能の利用は GitHub Pre-release License Terms - GitHub Docs に基づきます。 github.blog モノリスの課題と継続的改善 TUNAGは、10年以上の歴史を持つモノリスアプリケーションです。長年にわたって機能追加や改修を重ねてきた結果、コードベースが複雑化し、以下のような課題を抱えていました。 コードの可読性・保守性の低下 新機能開発・改修コストの増大 技術的負債の蓄積 これらの課題を解決し、TUNAGの成長を支えるためには、継続的な改善が不可欠です。 GitHub Copilotの導入 開発効率向上のため、2022年ごろよりGitHub Copilotを導入しました。当時のエンジニアからはこのような評価を得ており、その後現在に至るまでエンジニアには有償版Copilotアカウントを付与しています。 2022年時点での社内エンジニアの評価 先週末の以下のGitHub CopilotのOpenAI o3-mini (preview)サポートの発表を踏まえ、今回は、特にCopilot WorkspaceとGitHub Copilot pull request summaries・GitHub Copilot code review（旧Copilot for Pull Request）に注目し、モノリス改善への効果を期待しました。 GitHub Models users with a paid Copilot plan will also be able to leverage the o3-mini model to enhance their AI applications and projects later today. In the GitHub Models playground, you can explore o3-mini’s versatility as you experiment with sample prompts, refine your ideas, and iterate as you build. You can also try it alongside other models available on GitHub Models including models from Cohere, DeepSeek, Meta, and Mistral. OpenAI o3-mini now available in GitHub Copilot and GitHub Models (Public Preview) - GitHub Changelog Copilot Workspaceの活用 Copilot Workspaceは、IDE上でコードの補完や提案を行ってくれるため、開発効率を大幅に向上させることができます。筆者はVisual Studio Codeを利用していますが、そのエクステンション vscode:extension/GitHub.copilot?referrer=docs-copilot-ai-powered-suggestions を利用しています。 code.visualstudio.com Copilot Chat Copilot Edits TUNAGの開発では、Copilot Workspaceを活用することで、以下のような効果が得られています。 エラーハンドリングの抜け漏れの回避 類似コードの提案によるコーディング時間の短縮 API仕様の自動生成による開発効率化 特に、初期実装から時間が経過したコンポーネントにおいては、Copilot Workspaceがコードの理解を助け、開発スピードを向上させる上で非常に役立っています。 Copilot for Pull Request (GitHub Copilot pull request summaries・GitHub Copilot code review)の活用 Copilot for Pull Requestは、プルリクエストのレビューを支援してくれる機能です。2023年3月時点では GitHub NextでCopilot Enterpriseユーザーのみに提供されていた ため、利用を断念していた人・組織が多いのではないかと思います。GitHub Web上で利用しています。（ Copilot for Pull Requestは2023年12月 に廃止されました） 現在は Copilot for pull requests という形で独立したドキュメントになっており、GitHub Copilot pull request summariesとGitHub Copilot code reviewが主な機能です。 TUNAGの開発では、 Copilot pull request summariesとCopilot code reviewを活用することで、以下のような効果が得られています。 変更箇所の説明文の自動生成 レビュー観点の提案 コード品質の向上 プルリクエストのレビューは、コード品質を維持する上で重要なプロセスですが、多くの時間と労力を必要します。Copilot for Pull Requestは、レビュープロセスを効率化し、より質の高いレビューを実現する上で貢献しています。 モノリス改善への貢献 GitHub Copilotの導入により、TUNAGの開発Developer Experience (DevEx) チームは、モノリスアプリケーションの継続的な改善を効率的に進めることができるようになりました。 コードの可読性・保守性の向上 新機能開発・改修コストの削減 技術的負債の解消 2025年に入ってから、DevExチームではバンドリングツールをwebpack 4/5からesbuildへのリプレースするプロジェクトを推進していたのですが、そちらでも活用ができています。 コミットメッセージも次のようになっていて、Copilotというエンジニアと開発している感覚にもなりました。 Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> 新モデルの利用 先に書いた通り、1/31にo3-miniがリリースされると同時に、GitHub Copilotでも利用が可能になりました。特に GitHubを運営するMicrosoftグループとOpenAIの協力なパートナーシップ の元、高速なo3-mini対応が実現したと認識しています。これはシングルプロダクト・all-in-oneプロダクトの強みを最大限活かしたものであり、TUNAGが同様にシングルプロダクト・all-in-oneプロダクトであることのSaaS事業運営上の強みと通じるものがあると感じることができました。 blogs.microsoft.com o3-miniだけではなく、既にGemini for Google WorkspaceやGoogle AI Studioで活用できていた Gemini 2.0 も利用可能にしています（オプトインが必要でした）。 今後の展望 私たちは、以下の施策を通じてさらなる改善を目指しています。 本日発表された agent mode を活用した開発の深掘り 既に手元では利用できていましたが、公式に使えるようになったということもあり、深掘りして利用できればと思います。 テスト自動化の拡充 テストケースの自動生成を通じたテストカバレッジの向上ができそうだと感じています。 リグレッションテスト強化にも使えそうです。 ドキュメンテーションが不足しているケースがあるので、その解消にも役立ちそうです。 コードベースの自動ドキュメント生成 ADRの整備にも一役買いそうです。 Gemini 2.0の統合 これまではGeminiとGitHub Copilotでいったりきたりが必要でしたが、それらが統合されたことにより、IDEまたはWebブラウザで操作できるのは快適でした。同じ画面上で用途に応じて使い分けをしていこうと思います。 github.blog まとめ GitHub Copilot、特にCopilot WorkspaceとCopilot for Pull Requestは、モノリスアプリケーションの継続的改善を支援する強力なツールです。DevEx・プラットフォームエンジニアリングの領域においては、まだ適用できないケースもありましたが、それでも生産性向上への貢献は絶大だと感じました。 スタメンでは、GitHub Copilot以外のGenerative AI技術・プロダクトを活用を進めているため、そちらについても別途共有できればと思います。GitHub Copilotの導入は、複雑なアプリケーションを抱える開発チームにとっても非常に有効な手段なので、未導入で迷っているようでしたらぜひ試してもらえればと思います。 注）本記事の内容の執筆に関して、GitHub Copilot の利用規約 (GitHub Copilot プライバシーに関する声明など) を遵守しています。Copilot Workspaceを含む一部の製品機能においてプレビュー版が含まれているため、将来の仕様変更やサービス提供終了に注意が必要です。 この領域でアクセルを踏むため、以下のポジションでエンジニアを募集していますので、チェックいただけると幸いです。 herp.careers herp.careers herp.careers herp.careers 参考 Responsible use of GitHub Copilot pull request summaries - GitHub Docs Using GitHub Copilot code review - GitHub Docs

TUNAG with Ruby 3.4 昨年末12月25日にRubyの最新バージョン3.4がリリースされました。従業員体験プラットフォームTUNAG（ツナグ）を開発・運用している私たちのチームでは、この最新バージョンにいち早く追従。複数のRuby on Railsアプリケーションのバージョンを、すべて3.4.1にアップデートしました（2025年1月10日現在）。アップデート後1週間ほど問題なく運用できていますので、速報として記事化します。 移行前はRuby 3.3.6+YJIT、移行後はRuby 3.4.1+YJITとなります。 $ ruby -V ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux] 過去のTUNAGにおいてRuby/Railsのアップデート実績については以下の記事もご覧ください。 tech.stmn.co.jp tech.stmn.co.jp tech.stmn.co.jp YJIT 3.4 今回はYJIT 3.3からYJIT 3.4への移行最終局面でMaxime Chevalier-Boisvertさんによる記事 https://railsatscale.com/2025-01-10-yjit-3-4-even-faster-and-more-memory-efficient/ が公開されたので、最終チェックとして、この情報を活用しました。 特に今回のアプリケーションでRubyの影響を受けるのはActiveRecordの箇所だと捉えると、その高速化は+2.6%と推測していました。 railsatscale.com --yjit-mem-sizeの調整 Ruby 3.1から提供されてきた --yjit-exec-mem-size オプションに加え、YJIT 3.4では --yjit-mem-size オプションが2024年10月に新たに導入されています（ https://github.com/ruby/ruby/pull/11810 ）。 --yjit-exec-mem-size オプションはこれまでRuby 3.3においてもデフォルト48 MiBのままで運用していたため、 --yjit-mem-size=128 (in MiB) で運用を開始し目立った問題は発生していません。 github.com 全体のメモリ消費量 メモリ使用量については過去のRuby 3.1-3.3周辺のアップデートの中でやや苦労した Ruby/YJITエコシステム的にもメモリの問題はある程度落ち着いてきており、チーム組織内でも特に新たな発見はなく、スムーズにリリースに至りました。 実際のパフォーマンス差 実際に移行前後でのRailsアプリ (puma サーバで実行)のレイテンシー差異は軽微で、有意な差がある高速化は全体平均値や主要な個別箇所では確認できませんでした。今回はcanaryリリースをしない選択をしており、production環境において同一ソースコードの実行結果の差を取得していません。 native gem システム内部通信にgRPCを使っていることもあり、native gemに依存している状況です。Rubyマイナーバージョンアップ時はnative gemの最新マイナーバージョンへの追従が例年遅れる傾向にあります。 Ruby 3.3リリース直後と同様に、Ruby 3.4リリース直後もこれらのgemではネイティブビルドが利用できなくなりました。DevExはやや低下しますが、最新技術の活用を優先しています。この制約は約1ヶ月程度で解消される見込みで、通常は毎年2月ごろに改善されています。 native gemはfat gemと呼ばれることもあり、廃止したいという意見もあるようです。が、RubyGemsのキャッシュの兼ね合いからnative build gemは開発・運用業務をする上ではまだ必須かなという認識です。 www.clear-code.com 特に grpc gem はローメモリでのビルドが難しくCI環境などでメモリ不足が起因でビルドに失敗するケースに遭遇しています。こちらの問題はRuby 3.4対応のgrpc native gem (grpc 1.70.0予定) で解消される見込みです。 Stacktraceにクラス名が含まれることでSentryでFingerprintが変わる 2024年2月に、stacktraceにメソッド名のみが含まれていたものがクラス名+メソッド名が出力されるようになりました。 github.com Ruby 3.3以前に「後回しにした」(*1)エラーが、再度新規エラーとして扱われるようになりました。幸い、該当するエラーは数件程度だったため、手動でグルーピングすることで問題なく対応することができました。 事前準備は大事 プレリリース版より検証することが重要です。今回のRuby 3.4シリーズのプレリリースのうちpreview2とrc1を利用して、2024年中より評価・検証を進めました。 Ruby 3.4.0-rc1 2024-12-12 Ruby 3.4.0-preview2 2024-10-07 オフラインで開催されるRuby/Rails勉強会も有用な情報として助かりました。特にFukuoka.rb / 株式会社Ruby開発共催の福岡 Rubyist会議 04への参加は内部構造を理解するのにとても参考になりました。 regional.rubykaigi.org 毎週のように都内ではRuby関連勉強会は実施されているので、タイミングが合えば今後も積極的に参加していこうと思います。また、年次カンファレンスRubyKaigiも最もRubyについて深い議論ができるため、参加したいと考えています。 今年もスタメンからRubyエンジニアを中心にプロダクトメンバー複数名で参加する予定です。 いつやるのかという意思決定 プロジェクト実施を意思決定する以前から利用していたRuby 3.3は、2027年3月にEOLを迎えることが確定していました。そのため、今回のバージョンアップはそれまでの約2年間で実施する必要がありました。組織・プロダクトの状況を考慮すると、最大2年間は後回しにすることも可能でしたが、2024年のコミュニティへのフィードバックという貢献を最大化するため、このタイミングでの実施に至りました（実際には12月末はホリデーシーズンでチームは稼働していなかったため、年明けからの開始となりました）。 2025年第1週には最終プロセスに入り、すべて完了しています。しかし、productionレベルでの投資は2024年10月頃から緩やかに開始していました。例年以上に、特に今年の1月はチームに多くの新入社員が参画したこともあり、最初の週の実施はハードスケジュールでした。個人的には、2週目の実施でもよかったのではないかと感じています。 早期に実施することにリスクを感じる方もいるかと思いますが、私たちのチームではプロダクト内でのリスク回避策を講じることで、リスクを限定的に抑えられています。このあたりについては、読者の皆様が技術選定をどのように行っているのか、今後お伝えできればと思っていますし、他社の事例についても情報交換したいと考えています（執筆時点では、一定規模以上でRuby 3.4にアップデートしたという報告事例はあまり見つけられませんでした）。 我々もRuby 3.4力をつけて4月に愛媛で開催されるRubyKaigi 2025に参加し、各社でのRuby 3.4利用状況について議論できることを楽しみにしています。 参考 noteにも詳細を載せた関連記事を掲載していますので、ご参照ください。 https://note.com/takuya_stmn/n/n673ed32f80fe?magazine_key=m3805182520ce

TUANGのプロダクト開発チームでAndroidアプリを開発している カーキ です。 最近は、ダンダダン のアニメ放送に毎週歓喜しています。 2024年の末に投稿しようと思っていたものの、気付いたら年を越して2025年になっていました。 スタメンのAndroidエンジニアは3-4人と、決して大きい組織ではありませんが、機能開発をしつつプラットフォームの改善にも並列で取り組んでいます。 今回のブログでは、2024年の1年間でのAndroidチームでの技術的な変化・挑戦をまとめて紹介します。 Compose のコード規約を作成 TUNAG の Android プロジェクトでは、2021年ごろから Jetpack Compose をUI作成のフレームワークとして導入していました。 これまでは Jetpack Compose について知見にあるメンバーが知見の浅いメンバーに対して教えたり、レビューを通じて知見を共有することで、Jetpack Compose の共通認識を作っていました。 ただ実際にComposeのコードを書くメンバーが増えたときに、複数の書き方があるときにどちらを選択したら良いかが分からないなどの問題が表出してきました。 そこで、これまで暗黙的に共有されていた記述方法を言語化したり、まだチームの中で方針が決まっていなかった部分を GitHub Issues などで議論を深めていきました。 また自社での Compose のコード規約を考える上で、 API Guidelines for Jetpack Compose を参考に作成をしました。 コード規約の一部 コード規約は GitHub の wiki にまとめています。 コード規約が策定されたことによって、実装者が安心してJetpack Composeを利用することができるようになりました。 また成果物としてのコード規約の影響だけでなく、チームのメンバーでコード規約を作る過程にも価値があったと感じています。 コード規約では、いくか記述法として方法がある中で「なぜその選択をしたのか」の背景が必要になります。GitHub Issues などで議論を深める中で、「一般的にそう書かれているから」ではなく、「なぜその書き方が良いのか」について話し合うことができました。 様々な方法がある中で、TUNAGというプロダクトでなぜその選択をするのかについて、話し合うことができたのが良かったと感じています。 lintを導入 コード規約の作成に加えて、Compose の記述方法に関する lint をプロジェクトに追加しました。 今まで TUNAG 全体でも linter は未導入だったのですが、プレビュー用のComposable関数のprivate 修飾子のつけ忘れなど、どうしても抜け漏れが発生していました。 Compose のコード規約をチームで守っていくために linter の導入を決めました。 linter としては、 detekt を採用しました。 外部から Compose の lint のルールセットを追加できる点であったり、潜在的なバグの検出などのルールが標準で用意されている点で detekt を選択しました。 採用したルールに関しては、自分たちで作成したコード規約をもとに、必要なものを取り入れる形で決めています。 また linter による指摘を GitHub Actions の reviewdog を使って、PRでコメントされるようにもしています。 reviewdogによるlintのワーニング通知 これによってレビュワーによるレビューの前から、問題を検知することができるようになりました。 マルチモジュールのアップデート TUNAGでは、2020年ごろからマルチモジュールの導入を行っていました。 しかし、この当時のマルチモジュール化は細かい責務分けができていなかったため、むしろ負債になっている状態でした。 そこで2023年ごろから、責務分けなどを考慮した上でモジュールを再編していました。2024年はそれをさらに進化させ、モジュールを介した画面遷移を行うためのNavigationモジュールの作成を行いました。 マルチモジュールのアプリ構成では、モジュールを横断した画面遷移は依存関係が循環してしまうため、機能ごとでモジュールを切ることができませんでした。 モジュールが膨大になってくるとそのままビルドの速度にも影響します。機能をモジュールで分割できずappで実装することになり、ビルドの速度やJetpack Composeのプレビューに時間がかかる状態になっていました。 Navigationという画面遷移の抽象のみを持つモジュールを用意し、遷移実装をappで持たせることで、モジュールの依存関係が循環しないような形で実装をすることができました。 この実装が用意されたことで、2024年からは機能ごとにモジュールを分けることが可能になり、新機能に関しては新しい機能モジュールとしてスムーズに開発を進めています。 アプリの起動のフローの整理 アプリ起動処理のフローの整理を行いました。 元々はタイムラインの機能を提供するMainActivityにすべての実装がありました。そのためMainActivityの実装が非常にファットになっており、本来のタイムラインのために実装したい処理との区別がつかないような状態になっていました。また新たに起動時に処理させたいことがあっても、現在の処理を理解することが障壁になっており、機能追加時の障害にもなっていました。 それらを解消するために、起動の処理を整理し、MainActivityからの引き剥がしを行いました。 これにより、起動時にはどのような順番で処理が行われて、処理に応じたユーザーへの表示が明確になりました。 アプリの起動フロー再構成時に利用したメモ Android15対応 2024年秋に安定版がリリースされ、提供されている Android15 の対応を実施しました。 TUNAGプロジェクトとしては、そこまで大きな対応はありませんでしたが、edge-to-edge の対応が全画面に対して必要となりました。 edge-to-edge 対応とはAndroidのシステム領域である「ステータスバー」や「ナビゲーションバー」まで画面の描画領域を広げることができる機能です。 edge-to-edge の提供自体は過去から提供されていましたが、Android15 以降を targetSDK に設定しているアプリでは、強制的に適用されるようになりました。 TUNAGのAndroidプロジェクトはほとんどの画面でActivityベースで開発が行われているため、すべての画面において edge-to-edge の対応を行う必要がありました。 今回の対応としては、edge-to-edge で利用できるようになった領域に関しては従来通り透過をしないという暫定的な対応をしました。 今後よりネイティブアプリとして真価を発揮できるよう、画面に応じてナビゲーションバーの領域を一部透過するなど適宜対応していく方針となっています。 Kotlin 2.0への更新 Kotlin2.0へとメジャーバージョンの更新を実施しました。 TUNAGでは通常Kotlinのリリースの１ヶ月以内でのプロジェクトへの導入・リリースを目指しています。ただ今回はメジャーバージョンの更新であったため、慎重に検証を行いました。 結果としては、TUNAGにはそこまでKotlinのバージョンに依存しているライブラリが少なかったため、大きな問題もなく上げることができました。 Kotlin 2.0 へのアップデートでの大きな目玉としては、K2コンパイラへ移行があります。 ただK2コンパイラが Android Studio で利用可能になった当時はアルファ版であり開発に支障をきたすレベルのバグが存在していました。年末時点でK2コンパイラーを普段の開発で利用しているメンバーはおらずその早さはまだ実感できていません。 今回チームで2024年を振り返ったタイミングで、改めてK2コンパイラを使ってみようとなり、K2コンパイラの性能についてはこれからチームで検証していくこととなります。 PicassoからCoilへの移行 2024年11月に Picasso が非推奨となり、 Coil への移行が推奨されることがアナウンスされました。 TUNAGアプリは2018年当時からPicassoを利用しており、かなりの部分でPicassoに依存していました。 2023年からは Jetpack Compose で実装している部分に関しては一部 Coil の利用していましたが、過去に AndroidView で実装された部分に関してはすべてPicassoが利用されていました。ただ現在は Jetpack Compose での実装がメインとなり、TUNAG においては Coil がデファクトスタンダードになりつつあることを踏まえて、AndroidView で実装された箇所に関してもこの機会に Coil に移行する措置を行いました。 元々 Jetpack Compose のために Coil を導入したときにシングルトンの ImageLoader インスタンスの実装を行っていたため、両ライブラリで多少の違いはあったものの単純な置き換え作業となりました。 Markdown の検証 TUNAGの投稿では、マークダウンを利用することができます。 今まではWebViewのHTML表示などを利用して騙し騙しにマークダウンを提供していましたが、アプリケーションとしてよりWebViewに依存しないような構成にするために、TextViewベースのマークダウン表示の技術検証を行いました。 こちらは Markwon というライブラリをカスタマイズして、TUNAGでのマークダウンの書式が適用されるようにしました。 現在は技術検証が終わった段階で未リリースですが、これから順次アプリ内のマークダウンの表示を、こちらのネイティブベースのものに置き換えていく方針です。 最後に2025年に向けて 今回は2024年にTUNAG Androidアプリにて行った技術的な変化と挑戦を紹介しました。 こうして並べてみると、結構様々なチャレンジを行ってきたんだなと感じます。 機能開発だけでなく、アプリ開発におけるプラットフォームの改善にもより一層力を入れて、機能開発のベースラインを向上し、生産性の向上を目指しています。 株式会社スタメンでは、2025年より一層開発部門のギアを上げていくために全方向で開発メンバーを募集しています。 herp.careers

みなさんこんにちは、プロダクト開発部でTUNAGの開発をしている 小松 です。 先日行った社内イベント「BKP（ベスト開発ピッチ）」について紹介します！ 今回のイベントは、プロダクト組織（エンジニア、PdM、プロダクトデザイナー）とカスタマーサクセス部（以下、CS部）が一緒になって取り組んだ初めての試みでした。 普段の業務ではなかなか伝えきれない「プロダクト開発の裏側」や「日々の活動や成果」を共有する場として開催し、大いに盛り上がりました。 BKPとは？ 「BKP（ベスト開発ピッチ）」は、プロダクト組織が日々の成果や活動をピッチ形式で発表し、共有し合うイベントです。 もともとは、CS部で毎月恒例の「BKP（ベスト更新ピッチ）」がきっかけとなりました。CS部では、BKPで共有された取り組みが他のメンバーに受け継がれ、成果につながるという好サイクルが生まれています。 今回はCS部のメンバーからの提案を受け、この良い文化をプロダクト組織でも取り入れようと、企画段階からCS部と一緒に進め、プロダクト組織でも初めて実施することとなりました！ プロダクト組織のBKPでは日々の活動や成果を共有しながら、メンバー間や部署間の連携を深め、称賛の文化を育むことを目的としてます！ 開催の背景と目的 目的 プロダクト組織のナレッジを可視化 隠れた貢献の表層化・称賛の文化を育む 部門間の相互理解を深め、より良いサービスを届ける プロダクトをより良いものにするには、CS部とプロダクト組織の協力が欠かせません。 CS部は日々お客様からのフィードバックを集め、プロダクト改善のヒントを提供してくれています。一方で、プロダクト組織もその声を受け、新しい機能の開発や改善に取り組んでいます。 ただ、プロダクト開発部とCS部間の活動内容が見えづらいという課題もありました。 そこで、「BKP」を通じて、プロダクト組織が普段どのように改善や新機能の開発に取り組んでいるかを共有し、部門間の連携を深める場を作りました。 CS部とプロダクト組織が密に連携することで、スピーディーかつユーザーに価値のあるプロダクトを届けることを目指しています。 （取り組みの詳細は スタメン公式note でご覧ください。） 当日の様子 当日は、オンラインで開催され、6名のメンバーがそれぞれのテーマでピッチを行いました。 発表では、プロダクト改善の裏側や、未来のビジョン、新しい機能開発に込めた思いなどが語られました。 タイトル 登壇者 よりアプリらしさを出すために おしん 自動化しませんか? まっきー 管理画面の情報設計を見直した話 森田かすみ きれいなコードと責務のお話 hisayuki_mori レガシーコードDestiny〜本音を論じたい〜 カーキ プラットフォーム部のとある一日 uuushiro CS部からは「改善の裏にこんなストーリーがあったんですね」「新しい機能の背景がわかって嬉しい」といったコメントが寄せられ、互いの活動への理解が深まる時間となりました。 また、投票によるピッチ優勝者の表彰も行いました。もっとも多く票を集めたのは、まっきーさんの「自動化しませんか？」でした！ プロダクト運用の効率を大幅に向上させた自動化の取り組みについて、具体例を交えながら分かりやすく説明しており、参加者から高い評価を得ました。 優勝したまっきーさんを始め、登壇したメンバーを皆で賞賛し、楽しい雰囲気の中でイベントを締めくくることができました！ 今回のイベントを実施して感じたこと 1人1人の手で高めるプロダクトの価値 プロダクト組織の業務は、単にソフトウェアを作るだけではありません。 私たちは、部門を超えた協力の中で、より良いプロダクトをスピーディーに実現することを目指しています。 今回の「BKP」では、各メンバーが自身の取り組みを発表し、普段の業務ではなかなか共有できない知見や経験を共有する場となりました。 発表の中で感じたのは、「プロダクトをより良くしたい」という思いに基づいた真剣さと情熱です。 一人ひとりが主体的に発表し、他のメンバーと意見を交わす中で、チーム全体の結束がさらに強まったと感じています。 部門を超えたコラボレーションと一体感 また、スタメンでは、部門間の距離が近く、気軽に話しやすい環境が整っているため、こうしたイベントが自然体で進むのも魅力の一つです。 部門を超えた取り組みを通じて、多角的な視点を得ながらプロダクトづくりを進められるのは、スタメンならではの特徴だと思います。 このような環境の中で、メンバー全員が一体感を持ってプロダクトを磨き上げる姿勢を改めて実感しました。 今回の「BKP」をきっかけに、CS部との連携をさらに強化し、TUNAGをご利用いただく皆さまに価値を届けることで、感動や幸せが感じられるプロダクトを目指していきます。 採用情報 スタメンでは、プロダクト開発に関わる全ての領域でプロダクト職種の採用をしています。 もしご興味を持っていただけたら、下記からご応募ください！ herp.careers herp.careers