「Rubyistは、どう生きるか」柴田 博志 × 友井 義明 × 難波 恭平

この記事は、2023年9月6日開催の勉強会 『Rubyist はどう生きるか』を再編集し記事化したものです。

この10年でRubyエンジニアの新着求人数は10倍に増加しています。フォークウェルが実施したRubyエンジニアへのアンケートでも明らかになったように、急増する需要の中で熱心にRubyistを探す採用企業と自らのキャリアに迷いを感じる Rubyist の間には一定のギャップが感じられます。そこで今回は 経験豊富な Rubyist 達とのディスカッションを通じ、Rubyist に新しい視点や励み、楽しく働くためのヒントやアクションのきっかけを提供できればと思います。 Rubyist の皆さんがキャリアの「解像度」を上げるキッカケになれば幸いです。¹

「100名調査：Rubyエンジニアの楽しさと悩みを大解剖」ハイライト

Rubyist 100人アンケート 半数以上がRubyへの愛着や楽しさを感じ、今後も使い続けたいと考えている しかし、成長に伸び悩む方も存在する 求人・年収トレンド 過去10年で求人数が10倍に増加 募集年収は毎年平均で19万円上昇 30代後半では、5人に1人が年収800万円以上、20人に1人が年収1000万円以上 技術トレンド Ruby以外の言語（Python、Java、Go、PHP）も充実 Web業界の求人数はほぼ横並び どの言語が主流か、あるいは儲かるかという明確な状況は存在しない

パネルディスカッション｜プロフィール

タイミーのサービスや取り組みについてはこちらの記事でも紹介しています。

freee人事労務のソースコード 複数のドメイン機能を1つのRails appで開発 db/schema.rb: 約350 tables Ruby files: 約6000 JS/JSX files: 約3000 rails routes: 約1200 1ヶ月あたりのPull Request: 約1000 Line Coverage: 約93%

楽しさの要因 Full Cycle Developers を推奨している 柔軟なチーム変更 「異動戦国」と呼ばれるカジュアルに異動できる制度 オープンソースへの寄与 業務上の必要性からOSSへのcontributionを奨励 Pull Requestを作成する方が、単に手元で修正するよりも推奨される 最新技術の活用 GitHub CopilotとChatGPTを積極的に利用 GitHub Copilot 導入時に考えたセキュリティのあれこれ 快適な開発環境 開発用に整備されたEC2が標準の環境として提供 使用するエディタは自由に選べる 高品質な社内ライブラリ 社内で提供される基盤ライブラリの品質が非常に高い

²

パネルディスカッション｜8Qs

Q1：Ruby/Railsが企業で選ばれる理由は、ずばり仮説検証の速さだ

Ruby on Rails demo を見て「これは初速勝てんわ」と思った

― ― お、全員マルですね。

freee 友井：DHHが15分でアプリを作る「Ruby on Rails demo」を見ると「これは初速勝てんわ」と（笑）Laravel や SpringBoot のような後発のフレームワークもRailsのアイディアからきている点を考えても、マルですね。

タイミー 難波：僕は10年前からRailsを使っていますが、とにかくライブラリやエコシステムが充実していますよね。Rubyに慣れていると、思ったことをすぐにコードにできる。作りたいものを早く作れるだけでなく、仮説検証が早くできるのは、やっぱり強みですよね。

アンドパッド 柴田：仮説検証の速さはもちろん、Ruby/Railsはテストがしやすいですよね。他の言語ではテストのセットアップも大変ですが、Ruby/Railsでは容易に全体をテストできる。そういった部分も強みだと感じます。

― ― アンケート結果にあったような「初学者向け」「楽しさ」についてはどう感じますか？

freee 友井：もし自分が新卒の時に 日本語であれだけきちんとしたRailsガイドがあったら確かに始めやすいかなとは思いますね。

Q2：Rubyist としてのキャリアの悩みがある

アンドパッド 柴田：僕自身は25年前からRubyエンジニアで、Rubyに特化した人生を送ってきました。Railsのアップグレードに異様に詳しいのが自分の武器。だから Railsを使用している事業会社が存在する限り、仕事は無限にあると思っています。

タイミー 難波：タイミーのバックエンドエンジニアは基本的にRubyに興味を持って入社しているので、Rubyistとしての悩みはあまり聞くことはないんですよね。私自身は、Ruby on Railsを中心に活動していますが、最近は社内エンジニアのパフォーマンスを最大化する環境やツール作りにも関心があります。多角的な価値を提供できるように、Rubyに囚われず、キャリアの可能性を広げていきたいですね。

freee 友井：Rubyは他の言語に比べて自由度が高く修正が難しいという意見は理解できますが、解決できない問題ではないと考えています。ゆえに悩みにはならないかも。freeeは、フルサイクルというところもあり、業務でRubyだけ書いているわけではないし、そもそもRubyを書く時間を減らせることがRailsの良さですよね。だからあまりRubyだけに集中する話題が出てきてないのが正直なところです。

Q3：Ruby以外の言語の習得方法は？

環境を変えてみるのも、ひとつの手段

― ― Slidoからの質問です。「Rubyしか使えない場合、どのように他言語の実務経験を取得すべきでしょうか」

freee 友井：確かにバックエンド専門であれば、設計書を上から与えられるだけというケースは考えられますよね。そのような状況だと、他の言語に触れる機会が限られるかも。

アンドパッド 柴田：少し抽象的な回答になりますが、Railsを使っている場合、View や API で渡す先として、JavaScript や TypeScript を用いた開発を行う担当やチームが存在する事が多いと思います。事業会社で働いているなら、部署を変えることも一つの手段です。例えば、フロントエンドの経験を積む、またはインフラやSREの領域に移るなど。バックエンドのスキルを持ちつつ、フロントエンドやインフラ、SREにも手を広げて、両軸の武器を持つのはいかがでしょうか。

タイミー 難波：タイミーでは、チームトポロジーを採用した組織運営をしています。ストリームアラインドチーム、要は顧客に提供する価値をチームごとに持っていて、運用まで責任を持っています。他の領域の実務経験を積みたいと手を挙げれば、挑戦できる風土があります。もし質問者の会社がそういった環境でない場合は、そういう組織になるように上司にかけあってみるなど、環境そのものを変えてみるのもひとつの手段ですよね。

Q4：Rubyにマンネリを感じたことがある

Rubyそのものよりも、Rubyで何を生み出せるかに焦点を

― ― 全員バツ！！アンケートでは変化のないことに対する焦りの声も聞かれましたが。

freee 友井：最近、型チェッカーSorbet（ソルベ）を導入したんですが、かなり刺激的でした。Tapioca（タピオカ）というツールチェーンも今ホットな話題で開発もアクティブに進んでいます。そういったプロジェクトをコードリーディングすると非常に学びが多いです。ただそれ以外のプロジェクトでは、確かにルーチンワークの感覚があるかもしれませんね。

タイミー 難波：プロダクト開発の面白さのポイントは人それぞれ。仮説検証が面白いのか、チームの生産性が面白いのか。多くの人はRubyそのものよりも、Rubyで何を生み出せるかに興味を持っているのでは。Rubyをツールの一つとして捉えることで、マンネリ感を避けられるかもしれませんね。

アンドパッド 柴田：Railsの開発が単調かどうか……。過去のRails 3や4の時代に比べライブラリの選択肢が収束してますよね。昔は多数あった fixture replacement も最近は「FactoryBot」以外はあまり使わないので、マンネリ感は理解できます。ただ Ruby そのものには今でも驚きがあって、例えば「え、ハッシュがこんな動きをするの！？」「これは言語の仕様なの？成り行き上なの？」など。それが知的好奇心を刺激する面白さでもある。それが面白くて深追いしてしまうあまり、プロダクト開発の生産性に影響を与えることもあります（笑）

Q5：仮説検証後に設計を大きく変えるケースは多いですか？

― ― Slidoからの質問です。「仮説検証後に設計を大きく変えるケースは多いですか？そのまま運用に移行すると、後で変更が難しくなるアプリが多いと思いますが。」

freee 友井：私が所属するチームは内部品質に重点を置いていて、テストカバレッジも93%程度と高めなので、リファクタリングは比較的容易なんです。テーブル設計は後から変更が難しい部分もありますが、ロジックの調整や細かいリファクタリングは、しっかりとテストを書いていればスムーズです。Railsを保ったままでも後からスケーラビリティを考慮した設計に変更することも十分可能です。ただ、それが全員にできるわけではない。逆に言えば、このスキルがあればキャリアの強みになるのではないでしょうか。

Q6：Ruby以外の言語を選ぶなら？

流行りではなく、目的に応じた選択を

タイミー 難波：プロダクトや目的に応じて選びますね。例えば、フルスタックなWebフレームワークでWebアプリを作りたい場合は、PHPやPython、パフォーマンスが重要な小規模プロジェクトなら、GoやRustを選ぶかもしれません。モバイルアプリなら、SwiftやKotlinが選択肢になりますよね。

freee 友井：私はScalaが好きですが、学習コストと採用コストが高い……。Railsは独特なので、全く違うエコシステムや静的型付け言語を学ぶと、新しい学びが多いのではないでしょうか。

アンドパッド 柴田：私は言語よりもパッケージマネージャーに興味があって、多くの言語のパッケージマネージャーを触っています。新しい言語がどのようにパッケージ管理を行っているかに興味があるんですよね。言語自体で物を作るというよりは、ライブラリの管理や活用に焦点を当てています。

Q7：いま興味のあること

ー ー 言語や開発に関係なくてもOKです。いま興味のあることはなんでしょう？

タイミー 難波：モジュラーモノリス化に注目しています。ビジネスドメインの境界をどう設定するかが一番の課題。柔軟性を保ちつつ、明確なドメイン境界を見つけるための試行錯誤を行っています。オライリーの本などを参考に勉強中です。

freee 友井：自動テストが好きですね。主にRspecを使用していますが、他のテストフレームワークも結構好きです。Rubyに囚われず、テスト自動化に関する多層的な知識を積むことができるので、楽しみながら勉強しています。

アンドパッド 柴田：技術書よりも哲学や社会学の本を読んでます。人と人とが関わる背景や歴史に興味があるんです。「2000年前も同じことで悩んでるんだ！」と、現代の人間関係にも通じる部分に感動したり（笑）

Q8：この先もRubyを使い続けたい

― ― アンケートでは、51%がこの先も Ruby を使い続けたいとのことでしたが、いかがでしょうか？

開発スキルはコモディティ化、言語選びは重要ではない

― ― おぉ！友井さんはバツ！友井さんは事前アンケートで「物を作るスキル自体は、だんだんコモディティ化している」と回答されていましたよね。

freee 友井：そうですね。開発スキルの一般化、つまりコモディティ化はあるでしょうね。多くの言語とフレームワークが似たような開発体験を提供していると感じています。Railsは初めは開発速度が速いとされましたが、今では多くのフレームワークが同様の性能を持っているので、実は言語選びはあまり重要ではなく、どれを選んでも大差はないと思います。私自身も、Rubyの次にGo言語が必要になれば、切り替えていくと思います。

タイミー 難波：確かに、Rubyに関しては使用するツールが次第に固まってきてますよね。ただ、Webアプリケーション開発のベストプラクティスは絶えず変化していて、例えば 10年前は認証に「Devise」を使うのが一般的でしたが、今では「IDaaS（Identity as a Service）」のような新しい選択肢もあります。SaaS製品も増えていて、それらと連携することで新しい発見やチャレンジがありますよね。RubyやRailsが安定しているからこそ、新しいサービスと連携しやすいのかなと。

freee 友井：なるほど。言語非依存のプラクティス、例えばgRPCやGraphQLなども多く存在していますよね。Rubyだけでできる特別なことは少ないのかなと感じています。

― ― 柴田さんは、いかがでしょう

アンドパッド 柴田：Rubyの特徴として、創始者まつもとゆきひろさんが日本に住んでいる点は大きい。Ruby会議などで直接会うことができ、日本語で意思疎通が可能なのは大きなメリットです。実際に会うことの重要性は、言語に限らず感じています。例えば、GitHubでプルリクエストを作っても反応がない場合「渾身の出来なんですけど、マージしてもらえませんか？」と、直接質問ができますし、会って話すとやっぱり違うんですよね。日本語でのコミュニケーションだけでなく、直接会ってエンジニアリングの話をすることで、自分の課題解決や事業成長にも貢献できますよね。

「Rubyist はどう生きるか」

日本人が開発し世界的に愛される Ruby。日本人エンジニアにとって、Rubyやそのコミュニティは特別な存在です。しかし、Rubyに対するマンネリ感を感じるエンジニアも一定数存在します。そのような時に考えるべきは「プログラミング言語はただのツール。何を生み出すかが重要」という視点です。言語選択は一つの要素に過ぎません。最終的には、そのツールを使って何を創造し、どのような価値を提供するかがキャリアを形成する決定的な要素です。Rubyが好きならその道を突き進むも良し、他の言語や技術へ挑戦するも良し、どちらの道も尊重されるべきで、そのバランスがキャリア形成において非常に参考になるポイントです。

成長の鈍化を受け入れる | DHH

なにかを極める道程において「もう学ぶことはない」と感じる瞬間は最も危険です。一定のスキルを獲得すると、成長の速度が遅くなることは当然のこと。でも、それでいいのです。確かに、成長のペースは遅くなるかもしれませんが、進化は止まりません。私自身も5年、10年前に比べて、現在の自分の方がずっと成熟したプログラマーだと感じています。これは、日々の業務を学びのチャンスとして捉え続けたからです。「20年間、Rubyを使ってきた」から、なんなのでしょうか。新しい技術や手法を学ぶ旅は、まだまだ続くのです。

軸足をもって、遊ぶ | DHH

新しい技術に触れることはプログラマーの成長に不可欠です。最先端のフレームワーク、言語、データベースを採用することには魅力がありますが、それだけを追い求めるのはリスクが伴います。いつも最新の技術に飛びつくことで、結果的にあらゆる面で初心者のままでいる可能性があります。最先端の技術を学ぶことは大切ですが、選択する技術を1つや2つに絞り、それらに深くフォーカスすることも重要です。hey.comのRailsコードのように必ずしも常に大きな革新が必要なわけではなく、安定した技術をベースにして、他の分野、例えばフロントエンドに注力することも、賢明な選択と言えるでしょう。