Rubyエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

Rubyエンジニアのスキルシートは、RubyとRailsの版、アプリの構成（画面までRailsで作るのか、APIだけか）、少人数のチームで自分が担った範囲の3つが読み取れるように書くのが基本です。Rubyの案件は自社サービスの開発チームに入る形が多く、シートを読むのは開発リーダーやCTOであることがよくあります。技術の判断を短く添えると、読み手の関心に合ったシートになります。

全体の構成はスキルシートの基本にまとめています。この記事では、Rubyのエンジニアが書くときに押さえたい点に絞って説明します。

読み手は「入ってすぐ既存のコードを触れるか」を見ている

Rubyの案件の多くは、すでに動いているRailsのサービスに途中から加わる形です。読み手は、シートから次のことを読み取ろうとします。

• 自分たちと近い版のRuby・Railsを経験しているか
• 同じような構成（Hotwireなどで画面まで作る形、APIとフロントエンドを分けた形）を経験しているか
• テストを書く習慣があり、レビューのある開発に慣れているか
• 少人数のチームで、設計からリリース後の対応まで担ってきたか

求められるスキルそのものはRubyの案件で求められるスキルの記事で解説しています。スキルシートでは、それらが「どのサービスで、どの立場で」使われたかが分かるように並べます。

版は「担当した期間の版」と「更新の前後」を書く

技術欄に「Ruby on Rails」とだけ書くと、読み手は版を推測するしかありません。RubyとRailsはどちらも版ごとにサポートの期限があり、古い版のサービスを抱える現場も多いため、版の数字は案件との相性を判断する大事な材料です。

書き方の目安は次のとおりです。

更新に関わった場合は、自分が何を担当したかを括弧で添えます。版の更新は、非推奨の置き換え、gemの更新、テストの修正、段階的なリリースなど作業が多岐にわたります。どこを担ったかが書いてあると、面談で話が具体的になります。

gemは「主なもの」だけを選んで書く

Railsのプロジェクトでは多くのgemを使いますが、すべてを並べる必要はありません。読み手が知りたいのは、設計や運用に関わるものです。

• 認証・認可（Devise、Punditなど）
• 非同期処理（Sidekiq、Solid Queueなど）
• テスト（RSpec、FactoryBot、Capybaraなど）
• 検索・ファイル保存・決済など、機能の中心になったもの

「Sidekiq（ジョブの設計と失敗時の再実行を担当）」のように、使い方の深さを一言添えると、名前を並べただけのシートと差がつきます。

構成と担当範囲を書き分ける

同じRailsの経験でも、画面までRailsで作る構成と、RailsをAPIにしてフロントエンドを別に作る構成とでは、担う仕事が違います。プロジェクト欄の「案件概要」に、構成を一言で書いておきます。

• Railsで画面まで作る構成（Hotwire、ERBなど）
• RailsはAPIのみ。フロントエンドはReactなどで別に開発
• 両方が混在し、段階的にAPIへ移している途中

そのうえで、担当範囲は工程と領域の両方で書きます。少人数のチームでは、一人が設計・実装・テスト・リリース・障害対応まで担うことがよくあります。会社員の頃に当たり前にしていたことでも、シートに書かなければ読み手には伝わりません。

サービスの段階も一言添える

自社サービスの開発は、立ち上げ直後で機能を急いで増やす時期と、利用者が増えて性能や保守のしやすさが課題になる時期とで、求められる動き方が違います。「立ち上げ期から参加」「利用者が増えた後の性能改善の時期に参加」のように、参加したときのサービスの段階を書いておくと、読み手は自分たちの状況と重ねて判断しやすくなります。社名やサービス名を書かなくても伝えられる情報です。

テストと品質の取り組みの示し方

Rubyの現場では、テストを書くことが前提になっていることが多くあります。そのため「RSpecでテストを作成」と書くだけでは、ほかの候補者と差がつきません。シートで示したいのは、テストをどう良くしたかです。

• テストのない古い機能に、改修の前にテストを足してから直した
• 遅くなったテストの実行時間を、並列化やデータの作り方の見直しで短くした
• 落ちたり通ったりする不安定なテストの原因を調べて直した

カバレッジの数値を書く場合は、それが自分の取り組みでどう変わったかとセットにします。数値だけが単独で書かれていても、読み手は評価の材料にしにくいからです。

プロジェクト欄の記入例

次は書き方の型を示す例です。業種や規模はぼかしてあり、実在の案件ではありません。ご自身の経験に置き換えてください。

期間：○年○月〜○年○月（2年程度）
案件概要：toC向け 予約サービスの開発。Railsで画面まで作る構成から、一部をAPIに切り出し中
規模・立場：開発チーム数名（エンジニアとして参加。後半はレビューも担当）
担当工程：機能の設計、実装、テスト、リリース、障害時の一次対応
使用技術：Ruby 3.1→3.3、Rails 7.0→7.1、PostgreSQL、Sidekiq、RSpec、AWS（ECS）
担当内容：予約の変更・キャンセル機能の設計と実装。RubyとRailsの版の更新（主担当）
工夫・成果：肥大化していたモデルから予約の処理をサービスオブジェクトに分け、テストを足した。版の更新は非推奨の警告を先に解消し、複数回に分けてリリースした

この例では、構成（画面まで作る形とAPIの混在）、版の更新の担当、テストの取り組みが1件の中で読み取れる形にしてあります。

OSS・技術記事・GitHubの扱い

自社サービスの経験は、守秘義務の関係で詳しく書けない部分が出てきます。書いてよい範囲の考え方はスキルシートと守秘義務の記事をご覧ください。その補いとして、Rubyでは公開されている成果が判断材料になることがあります。

• gemへの修正の提案：どのgemに、どんな修正を出したか。取り込まれたかどうか
• 自作のgemや小さなRailsアプリ：テストとREADMEが整っているか
• 技術記事や登壇：版の更新やN+1の解消など、実務に近いテーマか

シートには、URLとあわせて「Railsの版の更新で直面した非推奨の置き換えについての記事」のように内容を一言で書きます。公開の成果は量より、実務の書き方が伝わるかどうかで見られます。

よくある質問

Railsの経験しかなく、Ruby単体の経験はありません。どう書けばよいですか？

Railsの経験として書いてかまいません。スキル一覧ではRubyとRailsを分けて並べ、Rubyの欄には、バッチやスクリプトなどRails以外で書いたものがあれば添えます。なければ、Railsの開発の中でRubyを使った期間として書けば十分です。

Hotwireを使っていない場合、不利になりますか？

使っていないこと自体が不利になるとは限りません。シートでは、画面をどう作っていたか（ERB、API構成のフロントエンドなど）を正確に書きます。Hotwireを求める案件に応募する場合は、学習中であれば実務と分けて「学習中」と書いておくと、面談での食い違いを防げます。

受託開発で複数のRailsアプリを短期間ずつ担当してきました。全部書くべきですか？

すべてを同じ分量で書くと、シートが長くなって直近の経験が埋もれます。期間・件数・主な担当をまとめた行を作り、応募する案件に近いものを数件だけ詳しく書く形が読みやすくなります。