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