既存RailsアプリをDocker化する前に見る論点
「新しく入ったメンバーの開発環境構築に3日かかった」「あの人のPCでしか再現しないバグがある」「READMEの手順通りにやっても動かない」——長く運用されているRailsアプリでよく聞く話です。原因の多くは、環境構築の手順が言語化されず、特定のPCの中だけで安定して動いている状態にあります。Docker化はこの問題への有力な解決策ですが、既存アプリに後から入れる場合は新規アプリとは違う注意点があります。この記事では、Docker化の利点・落とし穴・段階的な進め方を整理します。
「動くのは特定のPCだけ」問題とは
サービス立ち上げ期のRailsアプリは、たいてい1〜2人のエンジニアが自分のPCで環境を作り、そのまま運用を続けます。Ruby・gemのネイティブ拡張・ローカルのMySQL/PostgreSQL・ImageMagickなどのミドルウェア——これらのバージョンと設定が、その人のPCの中に暗黙のうちに固定されていきます。
この状態のまま数年運用が続くと、次のような症状が現れます。
- 新メンバーのオンボーディングに数日かかる: READMEに書かれた手順通りにやってもエラーが出る。実は「READMEに書かれていない一手間」が必要で、それは既存メンバーの頭の中にしかない
- 「私のPCでは動きます」問題: あるバグがローカルでは再現せず、本番でだけ起きる。OSやライブラリのバージョン差が原因のことが多いが、切り分けに時間がかかる
- 担当者交代で詰む: 環境構築ができる人が退職・異動すると、新しいメンバーが環境を作れず開発が止まる
- 本番との差異に気づけない: ローカルはmise/rbenvで管理されたRuby、本番は別バージョン、といったズレが積み重なり、デプロイして初めて問題が発覚する
これらは個々には小さな摩擦ですが、積み重なると「新しい機能を作る前に、まず環境を直す」という本末転倒な状態になります。
Docker化で得られるもの
Docker化の本質的な価値は「環境の再現性をコードとして固定する」ことです。
- OSやミドルウェアのバージョンをコードで固定できる:
DockerfileにRuby・システムライブラリのバージョンを明記すれば、誰の環境でも同じものが立ち上がる - オンボーディングの短縮: 新メンバーは
docker compose upを叩くだけで、既存メンバーと同じ環境が手に入る。理想的には数分〜数十分で完了する - 本番との差異を減らせる: 開発・ステージング・本番でベースイメージを揃えれば、「ローカルでは動くのに本番で落ちる」類の問題を減らせる
- 属人化した知識の言語化: Dockerfile化の過程で「実は必要だったあの設定」を明文化せざるを得なくなる。これ自体が副次的な資産になる
特に、複数人での開発体制に移行するタイミングや、外部の開発チームに一部機能の開発を委託するタイミングでは、この再現性の価値が一気に高まります。
見落とされがちな落とし穴
一方で、既存アプリへのDocker化は「とりあえずDockerfileを書けば終わり」ではありません。いくつかの地雷があります。
既存の暗黙依存が掘り起こせない
長く運用されたRailsアプリには、「このgemはOS標準のImageMagickに依存している」「あるバッチ処理はローカルにインストールされたLibreOfficeを呼んでいる」といった、コードには表れない暗黙の依存が潜んでいることがあります。これらはDockerfileを書く段階で初めて発覚し、洗い出しに想定以上の時間がかかることが珍しくありません。着手前に「今の環境に何がインストールされているか」の棚卸しが必須です。
パフォーマンスの劣化(特にmacOS)
macOS上のDocker Desktopは、ファイルシステムのマウント方式によってはホストとコンテナ間のI/Oが遅く、Railsの起動やテスト実行が体感で明確に遅くなることがあります。対策(volumeのキャッシュ設定、:cached/:delegatedオプション、Mutagenなどの高速同期ツールの併用)を知らずに導入すると、「Docker化したら逆に開発体験が悪化した」という不満が出て、現場に定着しないまま形骸化するリスクがあります。
本番環境との「本当の一致」は別問題
開発環境をDocker化しても、本番がDocker化されていない(あるいは別の構成の)場合、「開発と本番が一致した」とは言えません。本番のインフラ構成(Unicorn/Pumaの設定、systemdとの連携、ロードバランサー配下での挙動など)まで踏み込んで揃えるかどうかは、別の意思決定が必要です。開発環境のDocker化と本番のコンテナ化(ECS/Kubernetesなど)は目的もコストも異なるプロジェクトとして切り分けて考えるべきです。
安易にやらない判断も必要
すべての既存アプリにDocker化が最適とは限りません。開発メンバーが1〜2人で固定され、今後もその体制が続く見込みが高く、環境構築の摩擦が実害を出していないなら、優先度は低いかもしれません。逆に、外部チームとの協業や複数拠点での開発、頻繁な採用が見込まれるなら投資対効果が高くなります。「困っていることの実害」と「導入コスト」を比較してから着手するのが原則です。
段階的な進め方
いきなり本番までDocker化しようとせず、開発環境から着手するのが現実的です。
ステップ1: 現状の環境を棚卸しする
Dockerfileを書き始める前に、今の開発環境に何が入っているかを洗い出します。Ruby・gemのバージョン、OSレベルのミドルウェア(ImageMagick、libvips、wkhtmltopdfなど)、DBのバージョンと拡張機能(PostgreSQLのextensionなど)を一つずつ確認し、抜け漏れなく書き出します。この工程を飛ばすと、後になって「動かないgemがある」が頻発します。
ステップ2: 開発環境だけをDocker化する
まず docker-compose.yml でアプリ・DB・Redisなどをまとめ、開発者のローカル環境から統一します。この段階では本番構成には手を付けません。既存メンバーに実際に使ってもらい、既存のワークフロー(デバッガの利用、ログの確認、rails consoleの実行など)が問題なく回るかを検証します。
ステップ3: CI環境に適用する
開発環境のDockerイメージが安定したら、CI(GitHub Actionsなど)でも同じイメージを使ってテストを実行するようにします。ここまで来ると「ローカルでテストは通ったのにCIで落ちる」という食い違いがほぼ解消されます。
ステップ4: 本番への適用は別途判断する
本番のコンテナ化(ECS Fargate、Kubernetesなど)は、開発環境のDocker化とは別プロジェクトとして扱うべきです。既存のUnicorn+systemd構成が安定して稼働しているなら、無理に本番まで揃える必要はありません。本番のインフラ変更はダウンタイムやロールバックのリスクを伴うため、費用対効果を見極めた上で計画します。
外注する場合の進め方
社内にインフラ専任がいない場合、Docker化を外部チームに依頼するケースも多くあります。その場合の進め方の目安です。
- 現状の環境の棚卸しを一緒に行う: 外部チームがいきなり着手すると、暗黙の依存を見落として「動くはずが動かない」を繰り返します。既存メンバーへのヒアリングと、実際の開発環境の調査を最初に行うべきです
- 開発環境から着手し、本番は分けて判断する: 一足飛びに本番まで巻き込まず、まず開発環境のDocker化で効果を検証してから、本番への適用要否を改めて判断します
- 手順とハマりどころをドキュメントとして残してもらう: Dockerfileや
docker-compose.ymlだけでなく、「なぜこの設定にしたか」「よくあるエラーと対処法」を文書化してもらうことで、次の属人化を防ぎます
Docker化を含むインフラ整備は、既存プロダクト改善の一環として対応可能です。Rails・PostgreSQL・AWS環境でのコンテナ設計・構築はインフラの技術領域として支援しています。
なお、環境構築の属人化は「既存プロダクト改善」の中でも着手前に見落としやすい観点の一つです。改善に着手する前に何を確認すべきかは既存プロダクトの改善、外部チームが最初に見る観点で整理しています。また、リリース作業そのものが属人化しているケースはデプロイが属人化したシステムを改善する方法も合わせてご覧ください。
まとめ
- 「動くのは特定のPCだけ」状態は、オンボーディングの遅さ・本番との差異・担当者交代時のリスクという形で事業に実害を及ぼす。Docker化は環境の再現性をコードとして固定する有効な手段
- 既存アプリへの導入では、暗黙の依存の掘り起こし・macOSでのパフォーマンス劣化・本番との一致は別問題という3つの落とし穴があり、開発環境から段階的に進めるのが安全
- すべてのアプリにDocker化が必要とは限らない。実害とコストを比較した上で着手を判断し、外注する場合も棚卸しとドキュメント化を必ず成果物に含める
「環境構築が特定の人・特定のPCに依存していて不安」「新しいメンバーが入るたびに環境構築で詰まる」という段階でも、torcheees はご相談を受け付けています。まずは「既存プロダクト改善」の診断で現状の開発・インフラ環境を確認し、改善の優先順位と概算費用をご提示します。改善支援も継続支援として対応可能です。お問い合わせフォームからお気軽にご連絡ください。