DroidKaigi 2026に参加しました はじめに 株式会社スタメンでAndroidアプリ開発を担当している鈴木と申します。 今回はDroidKaigi 2026に参加した感想や知見を共有したいと思います。 インフルエンザにかかってしまい投稿が遅れてしまいました 今年は下記の日程で開催されました。 9月1日(火)：Event Day Workshop 9月2日(水)：Conference Day 1日目 (After Party) 9月3日(木)：Conference Day 2日目 After Partyでは今年もマグロの解体ショーが行われました。(とても美味しかったです) Event Day Workshop ここ数年恒例となっていますが、前半はハンズオン形式のKotlin Multiplatform/Compose Multiplatformのワークショップでした。 こちらについては前年とほぼ同じ内容なので割愛します。 今年は後半にKoogのハンズオンが行われました。(あまり発音に自信ないのですが、クーグと読むようです) JVM環境でAIエージェントへのフィードバックループやオーケストレーションをプロジェクトに組み込むための基盤となるフレームワークのようです。 ハンズオンでは家電製品の消費電力を効率化するアプリケーションの実装を行いました。動かしてみた感じは結構チューニングが必要そうな感じでした。 詳しくは下記の公式ページをご覧ください www.jetbrains.com Conference Day 各参加メンバーの印象に残ったセッションの内容を共有します。 鈴木 Foreground Service と歩んだ運用記：登山アプリが制約と向き合ってきた軌跡 あまり自身では触れることのなかったForeground Serviceについての知見や生々しい運用上の対応の歴史を知ることのできる内容でした。 OSのアップデート時には新しい権限が追加されたり破壊的な変更などは何かしらありますが、Foreground Service(Service)はできることが多すぎたため毎年のように変更が加えられていたようです。 Foreground Serviceに関連して以下のような実運用に基づいた実践的な内容を学ぶことができました。 ユーザーの端末設定による影響 メーカー独自機能や端末のスペックによる意図しない挙動への対応 WorkManagerとの違い 2026.droidkaigi.jp 宮澤 低レイヤもKotlinにお任せ！ 〜ハードウェア制御でも言語機能を使いこなす〜 Compose UIを汎用レンダリングエンジンとして活用する（ハードウェア制約の突破） ハードウェア制御の最大の壁は「実機がないと検証できない」「実機のスペック（日本語フォント非対応など）に依存する」ことです。本セッションでは、Composeのプレビュー機能を用いてハードウェアの挙動を素早く検証するサイクルを実現します。さらに、Composeの内部挙動をハックしたオフスクリーンレンダリングにより、Composeで構築したUIをそのままBitmap化して印刷するアプローチを実演します。 直近で似たような課題に直面していたこともあり、とても共感しながら聞いていました。 私自身、AST（抽象構文木）として構造化された解析結果をどう表現するか検討した際、その手段としてComposeを採用したことがあります。Composeのプレビュー機能を使えばアウトプットを視覚的に確認できるため、将来的にスクリーンショットテストで解析結果の妥当性を検証したり、膨大なテスト項目を効率的に一括テストできる点にメリットを感じていました。 ただ、自分の中では具体的な活用方法まで落とし込めず、本格的な実装は後回しにしていました。自分一人ではここまで上手く活用しきれなかったと思うので、今回のセッションを聞いたことで、自分の中のアイデアが広がるのを感じました。 2026.droidkaigi.jp とんとんぼ 起票時点でnoteで公開されていました。 本人に変わってスキをお願いします。 note.com 最後に スタメンではエンジニアを絶賛募集中です🙌 👇👇👇気になる方はこちらからアクセスをお願いします👇👇👇 herp.careers

はじめに # GFXBenchというGPUベンチマークソフトを取り上げたシリーズの4回目です。 前回で古いAndroidバージョン対応のビルドが行えました。 今回は実際に古いAndroidバージョンで実行してベンチマークスコアを確認してみます。 ベンチマーク実行結果 # 実行までの手順は今までと変わらないので、早速結果からです。 実行するAndroid端末はAndroidバージョンが古いものを手元のコレクションから見繕ってみます。 目標は SdkVersion:'21' (Android5.0) だったのですが、手元のAndroid端末の都合上、SdkVersion:'22' (Android5.1) までとなりました。 以下、実測した結果例です。ベンチマークスコアはオフスクリーン版のfps値です。 --> Caution あくまで 「筆者の環境および測定時点における一例」 であり、同様のGPU、手順で測定された場合でも、環境によって異なる結果となる可能性がある点をご了承ください。 GPU SoC Driver version Android version T-Rex score Manhattan score Adreno 418 Snapdragon 808 OpenGL ES 3.1 V@103.0 5.1.1 34 15 Kepler GK20A Tegra K1 OpenGL ES 3.2 NVIDIA 361.00 6.0.1 66 32 Kepler GK20A Tegra K1 (Denver) OpenGL ES 3.1 NVIDIA 343.00 7.1.1 63 30 Maxwell GM20B Tegra X1 OpenGL ES 3.2 NVIDIA 361.00 8.1.0 109 59 上記 Tegra X1 のスコアは Pixel C というタブレットのものです。携帯用のためか低い値となっているようで、確か据え置き用のAndroid端末の SHIELD だと T-Rex/Manhattan = 120/60 オーダーのスコアだったかと思います。 この Tegra K1 のスコア T-Rex/Manhattan = 60/30 と Tegra X1 のスコア 同 120/60 のオーダーが長らく私の中で比較する際の基準のスコアとなっていました。 --> Information Tegra K1の SHIELDタブレット で実際にサンプル（Unreal Engine、Unity等）を動かしたりゲームをしたりの感触より。覚えやすい値だったというのもあります。 時代的に仕方ないですが、このあたりのタブレットがメモリ2GBでなく4GB積んでいれば今でも普段使いしていたのに...と惜しく思います。 スマートフォン/タブレットを見る時はまずは Tegra K1 のスコア位あれば十分と見ていたものでした。Tegra X1を超えようものならもうえらい事です（※個人の感想です）。 今回はGPU違いですがオフスクリーン版の結果なのでそのまま比較できます。ただGPUの FLOPS (Floating-point Operations Per Second) も考慮に入れるとまた違った比較が行えます。次回以降に機会があれば触れてみたいと思います。 以下スコア以外の余談です。 ビルド時に CUDA Toolkit が必要だった件ですが、Tegra K1 で無事CUDA情報が表示されていました。Android版でまったく無駄というわけでもなかったようです。例はこれ位かもですが。 今回の古いバージョン5.1.1のAndroid端末でも、Car Chase（OpenGL ES 3.1 + AEP）および Aztec Ruins（OpenGL ES 3.1）までも実行可能でした。 Androidバージョン5.0から OpenGL ES 3.1 + AEP 対応が始まっていたので確かに可能ではあるのですが、実際に描画される画、fpsも低く健気に動く姿に目頭が熱くなる思いでした。 こんな昔からきちんと頑張ってくれていたのだなと...。 おわりに # 今回は前回ビルドした古いAndroidバージョン用のGFXBenchを実際に実行してベンチマークスコアを確認しました。 この記事をお読みの方の中にも、古いAndroid端末を眠らせたままにしている方は多いかもしれません。 久しぶりに取り出して、どこまで頑張れたのかチャレンジしてみてはいかがでしょうか。 より古いAndroidバージョン、より多くのベンチマーク種類の実行、より低いスコアを出せた方が優勝！です。 ライセンスおよび免責事項 # 本記事に掲載している検証結果は、BSD 3-Clause Licenseのもとで公開されている Kishonti-Opensource/gfxbench のソフトウェアおよびアセットを利用したものです。 Original Copyright: (c) 2005–2025 Kishonti Ltd. License: BSD 3-Clause License 【免責事項】 本記事に掲載している手順、ベンチマークスコア等の測定結果は、特定の検証環境における現状のまま（AS IS）のものであり、その正確性、安全性、再現性を保証するものではありません。 本情報の利用や検証の実行により生じた直接的・間接的な損害について、筆者および株式会社豆蔵は一切の責任を負いません。内容を十分にご確認の上、ご自身の責任においてご利用ください。

はじめに こんにちは！エニグモの採用広報担当です。 本記事では、現在のプロダクト開発チームの体制や組織を横断した意思決定の仕組み、そしてAI駆動開発をはじめとする現在のエニグモの開発環境について紹介します。 エニグモが前回、開発組織の変更発表を行ったのは3年前の2023年のことです。 当時は『チームトポロジー』の考え方を取り入れつつ、Domain・Squad・Chapterをベースとした体制へと大きく転換しました。 それから約3年、生成AIをはじめとするテクノロジーの劇的な進化に伴い、開発スタイルや組織に求められる役割も目まぐるしく変化してきました。 今年2026年4月には、サービスエンジニアリング本部 部長の木村より、今後目指していくエンジニア組織のビジョンを発表しています。 （参考： AI駆動開発とベンチャー回帰で創る次世代エンジニア組織 ） 今回は、前回の記事を3年ぶりにアップデートし、掲げられた「AI駆動開発」や「フルスタック・フルサイクルな開発」を、現在の組織・開発体制の中でどのように実現しているのか、その具体像をお伝えします！ はじめに エンジニアが所属する組織について プロダクト開発体制 ■Domain（ドメイン） ■ Squad（スクワッド） ■ Chapter（チャプター）　 プロダクト開発を支えるチーム エンジニア組織の意思決定 ■ Committee ■ Squad Weekly エニグモならではの開発環境の魅力 ■ 大規模なグローバルCtoCサービスを開発できる ■ AI駆動開発を前提に、フルスタック・フルサイクルへ ■ チームや事業を越えて、経験の幅を広げる まとめ エンジニアが所属する組織について サービスエンジニアリング本部（以下、SE本部）は、エンジニアが所属する部署で、大きく以下の3つのグループで構成されています。 アプリケーション開発グループ ：主力事業である「BUYMA」をはじめとしたプロダクトの機能開発を担当 AIテクノロジーグループ ：AI・データ基盤・機械学習・検索などの専門領域を担当 インフラグループ ：インフラ・セキュリティ領域を中心にプロダクト開発を支援 ここからは、実際の開発体制について詳しく紹介します。 エンジニアはいずれかのグループに所属していますが、日々の開発業務をグループ単位の縦割りで行っているわけではありません。実際のプロダクト開発では、所属グループの枠を越え、事業ミッションや専門性に応じてチームを組みながら活動しています。 プロダクト開発体制 BUYMAのプロダクト開発体制は、事業やユーザーへの提供価値を軸とした「Domain（ドメイン）」「Squad（スクワッド）」と、技術領域を軸とした「Chapter（チャプター）」という3つのチーム単位を設けています。 これらを独立した組織として分けるのではなく、エンジニアはDomain／Squadで事業課題に向き合いながらプロダクト開発を進め、同時にChapterを通じてチームを越えた技術的な取り組みも行う、マトリクス型の体制をとっています。 （※AIテクノロジーやインフラなど専門領域のメンバーは、このDomain/Squadでの開発を横断的に支援するチームとして機能しています。詳しくは後述します。） 　 それでは、マトリクス型の開発体制を構成するDomain／Squad／Chapterについて、それぞれ詳しく見ていきましょう。 ■Domain（ドメイン） Domainは、BUYMAにおける事業・ユーザーへの提供価値を軸に設定された開発領域です。 各Domainには、エンジニアだけでなく、ディレクター、データアナリスト、デザイナー、ビジネスサイドなど、さまざまな職種のメンバーが所属しています。共通のミッションや事業KPIを持ち、職種を越えて事業課題に向き合いながらプロダクト開発を進めています。 現在は、すべてのDomainがユーザーに直接価値を届ける「ビジネスミッション」を持つ体制への転換を進めています。 そのためエンジニアも、担当する機能を開発するだけではなく、事業KPIやユーザーへの提供価値を意識しながら、プロダクトや事業成果により深く関わることができます。技術だけでなく、事業視点を持ってプロダクト開発に携われることも、Domain体制の特徴です。 BUYMAには現在、以下の3つのDomainがあります。 BUY Domain ミッション：購入者を強力に吸い上げ、集客とCVRを最大化する。 主なカバー範囲：会員登録、商品詳細、購入リスト、レコメンド、クーポン、広告、特集ページ、カート、商品レビューなど。 SELL Domain ミッション：世界中から商品を力強く吸い上げ、品揃えを最大化する。 主なカバー範囲：出品ページ、出品リスト、受注リスト、商品画像、お問い合わせ、タイムセール、ショップ連携など。 SERVICE INFRA (SI) Domain ミッション：決済や安心補償などの機能を提供し、ユーザーへの提供付加価値を最大化する。 主なカバー範囲：決済連携、物流（配送・倉庫連携）、入金関連、セキュリティ関連など。 ※大型キャンペーン対応、商品画像施策など、複数Domain横断のプロジェクトもあります。 ■ Squad（スクワッド） 各Domainは、事業ミッション達成に向けて複数のSquadで構成されています。 Squadは、具体的な事業課題やプロジェクトを軸に組成され、その達成に必要なシステム開発にオーナーシップを持つチームです。 例えば、BUY Domainには「集客・流入Squad」「CVR Squad」、SI Domainには「配送Squad」などがあり、それぞれのテーマに沿って開発を進めています。　　 各Squadにはチームをリードする「Squad Lead」が存在し、要件の設計やタスクへの落とし込み、プロジェクトマネジメントなどを担います。 また、Squadでは設計・開発・テスト・リリースから運用・不具合対応まで、開発ライフサイクルを一貫して担当します。実装して終わりではなく、リリース後のユーザーの反応やデータを見ながら継続的に改善し、プロダクトを育てていけることも、Squadで開発する面白さのひとつです。 ■ Chapter（チャプター）　 Chapterは、特定の専門領域を担当するメンバーが、Domain／Squadを横断して活動するチームです。 メンバーはそれぞれのSquadでプロダクト開発を行いながら、Chapter活動として技術的な改善や基盤整備にも取り組んでいます。 Frontend Chapter ：フロントエンド領域を横断し、プロダクトの品質向上、パフォーマンス改善、計画的なバージョンアップやリファクタリングなどを担当 モバイルアプリ Chapter ：iOS・Androidアプリ開発を担当。各Domainの企画段階から参加し、アプリ領域の開発を横断的にリード QA Chapter ：サービス品質の維持・改善をミッションに、上流工程からプロジェクトに参加。自動テストの導入や本番不具合の分析・対策など、横断的な品質向上を推進 事業やプロダクトに向き合うDomain／Squadでの活動と並行して、専門領域を軸とした技術改善にも取り組めることが、Chapterを設けている特徴です。 プロダクト開発を支えるチーム Domain／Squadでのプロダクト開発を、技術や開発環境の面から横断的に支えるチームもあります。 Application Platform、AI Technology、Infra、DX、DevRelの5つのチームが、それぞれの専門性を活かしながら、ソフトウェア基盤の改善や開発環境の整備、組織づくりなどに取り組んでいます。 Application Platform 各Squadに共通する技術的な課題や、Squad単独では対応しづらい課題を横断的に解決し、開発全体の生産性を高めることをミッションとしています。 具体的には、言語・ライブラリ・フレームワークのバージョンアップ、AWS化に向けたアプリケーション修正、疎結合化・モジュラー化・マイクロサービス化などのアーキテクチャのモダナイズ、サービスの信頼性強化（SRE活動）などに取り組んでいます。 複数のSquadに関わる中長期的な技術課題やアーキテクチャ改善に取り組めることも、このチームの特徴です。 AI Technology AI・データ基盤・機械学習・検索など、データ領域の専門知識が必要となるシステムについて、設計・開発から運用までを担当しています。 データサイエンティスト、検索・MLOpsエンジニア、データエンジニアなどのスペシャリストが所属し、開発初期の設計・開発フェーズからSquadと密接に連携してプロジェクトを進めています。 専門性を活かしながら、AI・データ技術を実際のプロダクト開発につなげていけることも、このチームの特徴です。 Infra インフラ・セキュリティ領域の専門知識が必要となるシステムについて、設計・構築から運用・監視までを担当しています。 BUYMAのオンプレミス環境からAWSへの移行後の運用や、Kubernetesクラスタの構築・運用および開発支援、サービスのセキュリティ強化などに取り組んでいます。 ※以下2つのチームは、専任メンバーでのチーム組成ではなく、他チームのエンジニアが開発業務を兼任して活動しています。プロダクト開発だけでなく、自分たちの手で「開発者体験」や「エンジニア組織の文化」を作っていけるのがエニグモの特徴です。 DX Developer Experience（開発者体験）の略で、開発者体験の維持・向上をミッションとしています。 主にBUYMAのローカル開発環境やCI/CDツールの整備などに取り組んでいます。 DevRel Developer Relationsの略で、社内エンジニアの技術力向上や知識共有、交流促進を目的として、社内LT・勉強会を企画・運営しています。 また、テックブログや対外イベント、カンファレンス協賛などを通じた技術広報にも取り組んでいます。 エンジニア組織の意思決定 ここまで、プロダクト開発を担うチームと、それを支えるチームについて紹介してきました。 複数のチームが連携してプロダクト開発を進めるSE本部では、すべての意思決定を一か所に集約するのではなく、チームを横断して情報共有や組織課題について議論する場を設けています。 ■ Committee SE本部における組織運営や意思決定を担っています。 すべての意思決定を部長一人に集約するのではなく、内容に応じて部長が判断するもの、マネージャーを含めて議論・判断するものを分けながら意思決定を行っています。 また、特定のテーマについては分科会を設け、その領域を担当するエンジニアも議論に参加しています。 役職者だけで組織や技術に関する議論を完結させるのではなく、テーマに応じて現場のエンジニアも意思決定に関われることが、SE本部の組織運営の特徴です。 ■ Squad Weekly 各SquadやChapterの状況共有や、チームを横断するアジェンダについて相談するSE本部の定例ミーティングです。 部内での情報共有や、各チームから上がってきた課題について相談・解決することを目的としています。 必要に応じて、本定例で扱われた内容を部長から役員や他部門長へ共有しています。 チーム単独では解決しづらい課題も、組織全体で素早くフォローアップできる透明性の高い環境を作っています。 エニグモならではの開発環境の魅力 ここまで、SE本部の組織・開発体制について紹介してきました。 エニグモではAIを活用した開発を進めるとともに、特定の技術領域や所属チームにとらわれず、一人ひとりのエンジニアがカバーする領域を広げていくことを目指しています。 ここでは、エニグモが目指すエンジニア像と、実際にどのような挑戦の機会があるのかをご紹介します。 ■ 大規模なグローバルCtoCサービスを開発できる BUYMAは20年以上にわたり運営を続け、1200万超えのユーザーを抱える、グローバル×CtoCの大規模プラットフォームサービスです。 多くのユーザーが利用するサービスだからこそ、安定したサービス運営を続けながら、新たな機能開発や改善を進めていく必要があります。 また、ユーザー数が多いため、施策の効果が数値として現れやすいことも特徴です。 新機能のリリース後には、A/Bテストやデータ分析を通じて成果を検証し、次の改善につなげています。 トラフィック量や扱うデータも大きく、スケーラビリティやパフォーマンスなど、大規模サービスならではの技術課題にも向き合いながら開発を進めています。 長く続くサービスを安定して運営しながら、ユーザーの反応やデータをもとにプロダクトを改善し続ける。こうした開発に携われることも、エンジニアとしての醍醐味です。 ■ AI駆動開発を前提に、フルスタック・フルサイクルへ SE本部では、AIを開発プロセスに取り入れ、AIを活用することを前提とした開発を進めています。 AIの支援によって技術領域を越えて知識を得たり、これまで専門外だった領域の開発に取り組んだりしやすくなったことで、エンジニア一人ひとりがカバーする領域を広げる「知識のフルスタック化」を目指しています。 実際に、バックエンドを主な専門領域としてきたエンジニアがフロントエンドの開発を担当するなど、これまでの専門領域に閉じずに開発を進めるケースも生まれています。 今後は技術領域だけでなく、企画から設計、開発、運用まで、個人やチームがより広い範囲でプロダクトに関わるフルスタック・フルサイクルな開発を進めていきます。 目指しているのは、AIを活用しながら自身の専門性を広げ、単独でもユーザーへの価値提供を進められる「PM兼アーキテクト」として振る舞えるエンジニアを増やしていくことです。 ▼AI駆動開発については、以下の記事で詳しく紹介しています。 「 AI駆動開発とベンチャー回帰で創る次世代エンジニア組織 」 ■ チームや事業を越えて、経験の幅を広げる SE本部では、所属するDomainやチームを固定的なものとはしていません。 組織の状況や本人の希望などに応じて、別のDomainやチームへ異動するケースもあります。 例えば、AI Technologyからアプリケーション開発に関わるチームへ異動したり、アプリケーション開発からApplication Platformへ活動の幅を広げたりするなど、これまでの経験を活かしながら新たな領域に挑戦する機会があります。 また、通常の開発業務と並行して、DXやDevRelの活動を兼務することもできます。 プロダクト開発だけでなく、開発者体験の向上、社内の技術力向上・知識共有、社外への技術発信など、自身の関心に応じてエンジニア組織づくりにも関わることができます。 さらに、BUYMAだけでなく、新規事業やグループ会社のサービス開発にプロジェクトベースで携わるケースもあります。 BUYMA TRAVELをはじめとするグループ会社のサービスや、新規事業のサービス開発・基盤構築を担当するなど、BUYMAにとどまらず、エニグモグループのさまざまなサービス・技術領域に関わる機会があります。 まとめ 今回は、2026年現在のエニグモのエンジニア組織・開発体制についてご紹介しました。 Domain／Squadを中心としたプロダクト開発、専門領域を横断するChapter、そして開発を支える各チームが、それぞれの役割を持ちながら連携して開発を進めています。 また、AI駆動開発を前提に、これまでの専門領域にとらわれずフルスタック・フルサイクルにカバー範囲を広げたり、チームを越えた兼務や異動、新規事業・グループ会社のプロジェクトに携わったりと、エンジニアとしてさまざまな領域に挑戦できる環境があります。 エニグモでは、一人ひとりのエンジニアが自身の専門性を活かしながら、新しい技術や領域にも挑戦し、プロダクトや事業への価値提供の幅を広げていくことを目指しています。 そんなエニグモの開発組織に少しでも興味を持っていただけた方は、ぜひ私たちと一緒に、これからのプロダクトや開発組織をつくっていきませんか？