LASSIC Media らしくメディア
Ruby on Rails受託開発会社の選び方｜比べたい5つの点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Railsは版ごとに修正の期間が決まっているため、受託開発会社は版上げと保守まで続けられるかで比べます。
- 版上げの経験とテストの書き方は後から取り返しにくいので、契約の前に進め方を具体的に聞きます。
- コードと部品の一覧、手順書、テストを受け取る約束をしておくと、別の会社への引き継ぎで困りにくくなります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
Railsで作った社内システムの改修を、どの会社に頼めばよいか分からない。前の開発会社が手を引き、コードを説明できる人がいない——。Railsのシステムを持つ会社では、こうした悩みが起こりがちです。Ruby on Rails受託開発とは、Rubyというプログラミング言語と、その上で動くWebアプリケーションの枠組みであるRailsを使ったシステムの開発や改修を、外部の会社に請け負ってもらうことです。
新しく作るときだけでなく、版の更新や保守を任せる場面でも受託開発会社を選びます。ただし、Railsで作った実績があるだけでは、数年先まで任せられるかは判断できません。本記事では、情報システムの担当者に向けて、受託開発会社の選び方として比べたい5つの点、版上げとテストの確かめ方、保守とコードの引き継ぎ、Rubyアソシエーションの認定制度の見方を整理します。
目次
Ruby on Rails受託開発とは
Railsは、決まった書き方に沿えば少ない手間でWebアプリケーションを組み立てられる枠組みです。その一方で、Rails自体の版が定期的に新しくなり、古い版にはいずれ修正が配られなくなります。Railsの公式の方針では、各版の不具合の修正は最初のリリースから1年、セキュリティの修正は2年とされています。*1 新しい機能を含む版は、6か月ごとに出すことを目標にしています。*1
- 新規開発：業務システムや会員向けのサイトなどを、Railsで一から作る
- 改修・機能追加：動いているシステムに画面や機能を加える
- 版上げ：RubyとRailsを、修正が続いている版へ上げる
- 保守・運用：不具合の調査や小さな修正、セキュリティの修正の適用を続ける
Railsのシステムは作って終わりではなく、版の更新を続けることになります。受託開発会社は、最初の開発の力に加えて、版上げと保守を続けられるかまで見ておきます。Rails人材の不足を外部の力で補う考え方はRuby on Railsエンジニア不足を受託・委託で補完する進め方で扱っています。
受託開発会社を比べる5つの点
Ruby on Railsの受託開発会社を金額や期間だけで決めると、納品後の保守で困ることがあります。選び方の軸として、次の5つの点を同じ質問で各社に聞くと比べやすくなります。
| 比べる点 | 確かめること | 確かめ方 |
|---|---|---|
| 1. 版上げの経験 | RubyやRailsを古い版から新しい版へ上げた経験があるか | 上げたときの手順と、途中で動かなくなったときの対処を聞く |
| 2. テストの書き方 | 自動テストを書き、改修や版上げのたびに流しているか | 納品物にテストが含まれるか、どこまで確かめるテストかを聞く |
| 3. 保守の体制 | 納品後に不具合の調査や修正を受け持つ人と窓口があるか | 問い合わせの受け方と、セキュリティの修正を当てる手順を聞く |
| 4. コードの引き継ぎ | ほかの会社や社内の担当者でも読み継げる形で渡すか | 納品物の一覧と、開発用の環境を作る手順書の有無を聞く |
| 5. Rubyの技術力の示し方 | 技術者の資格や事業者の認定など、外から確かめられる材料があるか | 認定の種別と、案件に入る技術者の経験を聞く |
後から取り返しにくいのは1と2です。自動テストが無いシステムは、版上げのたびに機能を人の手で確かめることになり、手間が膨らみます。
版上げとテストの確かめ方
Railsの公式ガイドは、版上げの前にテストを十分に整えることを勧めています。自動テストが無ければ、アプリケーションのすべての機能を手で確かめることになると説明しています。*2 また、Rails 8.0と8.1はRuby 3.2.0以上が必要で、RubyとRailsは別々に上げ、先にRubyを上げるのがよいとしています。*2
公式ガイドが勧める進め方は、マイナー版（8.0から8.1のような1段階の版）を1つずつ上げ、そのたびにテストを流して直す形です。*2
- マイナー版を1つずつ上げる進め方で、版上げをした経験があるか
- 非推奨の警告（次の版で使えなくなる書き方の知らせ）をどう洗い出して直すか
- 版上げの間、機能追加の作業とどう並べて進めるか
- 本番に出す前に、どの環境で何を確かめるか
Ruby自体にも修正が続く期間があり、公式サイトによると、Ruby 3.2は2026年4月1日に修正の提供を終え、Ruby 3.3も2027年3月31日に終える見込みです。*3 Railsの方針も、修正が終わった版の不具合やセキュリティの問題は、利用者自身の責任で扱うことになると説明しています。*1 Rubyの版上げの具体的な進め方はRuby 3.1サポート終了と3.3系への移行で扱っています。
保守体制とコードの引き継ぎ
納品後の保守を同じ会社に頼むとしても、いずれ別の会社や社内の担当者に引き継ぐ日が来ることがあります。そのときに困らないよう、契約の段階で受け取るものを決めておきます。
- ソースコード一式と、変更の履歴（Gitなどで残した記録）
- 使っている部品（gem：Rubyの追加部品）の一覧と、それぞれの版
- 開発用の環境を一から作る手順書
- 自動テスト一式と、テストの流し方の説明
- 画面と機能の一覧、外部のサービスとのつなぎ方の説明
保守の体制では、窓口に加えて、Railsのセキュリティの修正を誰が判断して当てるかを確かめます。Railsは、修正が続いている版すべてに向けてセキュリティの修正を用意し、公式ブログで告知すると公表しています。*4 影響を調べて当てる時期を決めるまでを保守に含めるかで、見積もりの中身は変わります。
Rubyアソシエーション認定制度の見方
Rubyの技術力を外から確かめる材料の一つに、Rubyアソシエーションの認定制度があります。Rubyアソシエーションは、法人向けに4つの認定制度を設けており、技術者個人向けにはRuby技術者認定試験があります。*5 受託開発会社を比べるときに参考になるのは「認定システムインテグレータ」で、Rubyでシステムを開発する企業を対象に、申し込みと書類の審査を経て認定されます。*6
| 種別 | 認定の条件 |
|---|---|
| Gold | Ruby技術者認定試験のGold資格を持つ人が、正社員として5名以上所属している |
| Silver | Ruby技術者認定試験のSilverまたはGold資格を持つ人が、正社員として5名以上所属している |
認定は、会社に一定数の資格保持者が正社員として所属していることを示すものです。*6 案件に入る技術者の版上げやテストの経験は、認定とは別に面談で確かめます。認定を受けた企業の一覧は、Rubyアソシエーションの公式サイトで公開されています。
まとめ：発注先で確かめたい3つの点
Ruby on Railsの受託開発会社の選び方で、確かめておきたい点は3つに整理できます。第一に、テストを流しながら版上げを1段階ずつ進めた経験があること。第二に、保守の窓口とセキュリティの修正を当てる手順が決まっていること。第三に、コード・部品の一覧・手順書・テストを受け取れることです。この3点を踏まえておけば、「作ってもらったものの、版上げのたびに一から調べ直すことになった」という事態を避けやすくなります。発注先の比べ方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
新規開発と保守を別の会社に頼んでもよいですか
頼めます。その場合は、開発の契約の段階で、ソースコード・手順書・テストを納品物に入れておくことが前提です。保守を受け持つ会社に開発の終盤から加わってもらうと、引き継ぎで確かめる点を減らせます。
版が古いままのRailsのシステムでも相談できますか
相談はできます。まずは今のRubyとRailsの版、テストの有無、部品の版を調べてもらうと、版上げの見積もりの根拠がはっきりします。修正の提供が終わった版の問題は利用者自身の責任で扱うことになるため、*1 早めに版上げの計画を立てておくと進めやすくなります。
認定を受けていない会社は避けたほうがよいですか
避ける必要はありません。認定は判断の材料の一つです。認定の有無にかかわらず、版上げの経験やテストの書き方、引き継ぎの資料について同じ質問をして、答えを比べるのが確実です。
Ruby on Railsの受託開発・保守のご相談
Railsのシステムの開発や改修から、RubyとRailsの版上げ、納品後の保守と引き継ぎまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Ruby on Rails Guides「Maintenance Policy for Ruby on Rails」（https://guides.rubyonrails.org/maintenance_policy.html）。出典：不具合の修正は1年・セキュリティの修正は2年、6か月ごとのリリース目標、修正が終わった版は利用者の責任で扱うことの記述を参照（2026年10月確認）
- *2 参考：Ruby on Rails Guides「Upgrading Ruby on Rails」（https://guides.rubyonrails.org/upgrading_ruby_on_rails.html）。出典：版上げ前のテストの整備、Rails 8.0・8.1に必要なRubyの版、RubyとRailsを別々に上げる進め方、マイナー版を1つずつ上げる手順の記述を参照（2026年10月確認）
- *3 参考：Ruby公式サイト「Ruby ブランチごとのメンテナンス状況」（https://www.ruby-lang.org/ja/downloads/branches/）。出典：Ruby 3.2・3.3のEOL（修正の提供の終了）の日付を参照（2026年10月確認）
- *4 参考：Ruby on Rails「Security policy」（https://rubyonrails.org/security）。出典：修正が続いている版へのセキュリティの修正の用意と、公式ブログでの告知の記述を参照（2026年10月確認）
- *5 参考：Rubyアソシエーション「事業者認定制度」（https://www.ruby.or.jp/ja/certification/）。出典：法人向けの4つの認定制度と、技術者個人向けのRuby技術者認定試験の記述を参照（2026年10月確認）
- *6 参考：Rubyアソシエーション「Rubyアソシエーション認定システムインテグレータプログラム」（https://www.ruby.or.jp/ja/certification/sier/overview）。出典：プログラムの対象、GoldとSilverの認定の条件、書類の審査と認定までの流れの記述を参照（2026年10月確認）
