「自分のPCでは動いてたのに……」
開発の現場でこの言葉を聞いたことはありませんか。あるいは自分で言ったことがある方もいるのではないでしょうか。
ローカルの開発環境ってなぜかいつの間にか壊れますよね。ライブラリのバージョンを上げたら別のプロジェクトが動かなくなったり、チームメンバーと環境が微妙に違ってバグの再現ができなかったり。筆者も何度この問題で時間を溶かしたかわかりません。
そこで登場するのがDockerです。「名前は聞いたことあるけど何がいいのかよくわからない」という方に向けて、今回はDockerを使うべき理由を実務目線で解説します。インストール手順よりも先に「なぜ使うのか」をしっかり押さえておくと、後の学習がぐっとスムーズになりますよ。
この記事でわかること
- ローカル開発環境がよく壊れる理由
- Dockerを使うと何が解決するのか
- Dockerを使う場合・使わない場合の比較
- 実務でDockerが使われている場面
ローカル環境はなぜ壊れるのか
まずここから整理しておきましょう。
開発に使うツールやライブラリは、それぞれ「バージョン」を持っています。たとえばPHPの7系と8系では動作が異なりますし、Node.jsのバージョンが違えばパッケージの動作も変わってきます。
PCに直接インストールして開発を続けていくと、こんなことが起きがちです。
- 新しいプロジェクトのためにライブラリを更新したら古いプロジェクトが壊れた
- チームメンバーのPCと自分のPCでOSやバージョンが微妙に違う
- 「本番環境はLinuxなのに自分のPCはmacOS」という状況でバグが再現しない
- 半年ぶりに触ったプロジェクトが動かない（その間に何かが変わった）
これらは「環境の汚染・差異」が原因です。1台のPCに複数プロジェクトの依存関係が混在することで、じわじわと動作の一貫性が失われていきます。
ローカル環境でのセットアップ方法を知りたい方はこちら。
Dockerって何をしてくれるのか
Dockerは一言でいうと「アプリの動作環境をまるごとパッケージ化できる仕組み」です。
よく使われる例えですが、Dockerのコンテナ（container）はお弁当箱のようなイメージです。アプリの実行に必要なOS・ライブラリ・設定をすべてその箱の中に詰め込んで、どのPCでも同じ状態で動かすことができます。
ちょっと技術的な言い方をすると、DockerはホストOS（自分のPC）の上に隔離された軽量な実行環境を立ち上げます。仮想マシンとは違い、OSそのものをエミュレートしないので起動が速く、リソースの消費も抑えられています。
コンテナとイメージの関係
Dockerを使うときに出てくる用語を簡単に整理しておきます。
| 用語 | 意味 | 例え |
|---|---|---|
| イメージ（Image） | 環境の設計図 | レシピ |
| コンテナ（Container） | イメージから起動した実行環境 | 実際に作った料理 |
| docker-compose.yaml | 複数コンテナをまとめて管理する設定ファイル | 献立表 |
イメージから何度でもコンテナを作れるので「壊れたら作り直す」が気軽にできるのがDockerの便利なところですね！
実際にDockerでPostgreSQLの環境を作る手順はこちらで解説しています。
Docker を使う場合・使わない場合の比較
具体的に何が変わるのか、比較してみましょう。
環境のセットアップ
| Docker なし | Docker あり | |
|---|---|---|
| セットアップ | 手順書通りに各ツールをPCに直接インストール | docker compose up -d 1コマンドで起動 |
| 新メンバーの参加 | 環境差異によるトラブルが起きやすい | 同じdocker-compose.yamlで同一環境が再現できる |
| 複数プロジェクトの並行 | バージョン競合が起きやすい | プロジェクトごとに独立した環境を持てる |
壊れたときの対処
| Docker なし | Docker あり | |
|---|---|---|
| 原因特定 | PC全体が影響範囲になるため難しい | コンテナ単位で隔離されているので特定しやすい |
| 復旧方法 | 再インストールや設定変更が必要 | コンテナを削除して作り直すだけ |
| 本番との差異 | 生まれやすい | 同じイメージを使えば差異を減らせる |
環境が壊れても「コンテナを作り直す」だけで元通りになるのはかなりストレスが減ります。
Dockerと他の開発環境との違い
Dockerのメリットを理解するには、他の開発環境との違いを見るのが一番わかりやすいです。以下に代表的な環境と比較してみます。
| 項目 | Docker | 仮想マシン（VM） | ローカル環境 | クラウド |
|---|---|---|---|---|
| 起動速度 | ◎（数秒） | △（数秒～数分） | ◎ | ○ |
| 環境再現性 | ◎（完全に再現可能） | ○ | × | ◎ |
| 軽さ | ◎（軽量） | ×（重い） | ◎ | ○ |
| チーム共有 | ◎（簡単に共有） | △ | × | ○ |
| 学習コスト | △（やや必要） | × | ◎ | △ |
| 完成系までの簡単さ | ◎（YAMLとコマンドで再現） | △（OS含め構築が重い） | △（インストール・設定調整が必要） | ○（サービス選定・権限設定が必要） |
特に環境をそのまま共有できるという点がDocker最大の強みです。逆に単純な個人開発だけであればローカル環境のほうがシンプルな場合もあります。
Docker以外の実行環境との違いも知っておきたい方はこちら。
Dockerを使うべきケース
どんなときにDockerを使うべきなのか。結論からいうと「環境差異が問題になる場合」はほぼDocker一択、かと思います。
チーム開発をする場合
チームで開発する場合、メンバーごとに環境が違う問題が必ず発生します。Dockerを使えば全員が同じ環境を再現できるため「自分の環境では動くのに…」という問題を防げます。
環境構築を簡単にしたい場合
新しいメンバーが参加するたびに環境構築を説明するのは大変ですが、定義ファイル（docker-compose.yaml）を使用してコマンド一発で同じ開発環境を再現できます。
複数のバージョンを扱う場合
プロジェクトごとに異なるバージョンのツールを使う場合にもDockerは有効です。ローカル環境を汚さずに切り替えが可能になります。
逆にDockerが不要なケース
一方で、以下のようなケースではDockerではなくローカル環境のほうがシンプルで早いこともあります。
・個人で小規模な開発をする場合
・環境差異が問題にならない場合
実務でDockerが使われている場面
「でも実際の現場でどう使うの？」というところも気になりますよね。筆者が経験した範囲でいくつか挙げてみます。
ローカルでの開発環境構築
Webアプリの開発でWebサーバー・DBサーバー・アプリサーバーをセットで用意したいとき、docker-compose.yamlというファイルに書いておけば、このファイルを使用して環境構築を行えばチーム全員が同じ環境を使えます。よくある新メンバーが入ってきたときの「環境構築で半日潰れる問題」がかなり改善されます。
CI/CDパイプラインへの組み込み
GitHub ActionsなどのCI/CDツールと組み合わせるとコードをpushするたびに「同じDockerイメージでテストを走らせる」運用ができます。「自分のPCでは通ってたのに」がなくなります。
本番環境のデプロイ
AWS ECSやGoogle Cloud Runなどのクラウドサービスは、Dockerコンテナをそのままデプロイできる仕組みになっています。開発環境と本番環境の差異を最小化できるのも大きなメリットです。
検証・お試し環境の使い捨て
「このライブラリ、ちょっと試してみたい」というときにDockerコンテナを使うと、PC本体を汚さずに検証できます。試し終わったらコンテナを削除するだけです。
Dockerを使うときに注意したいこと
メリットだけ書くのも正直じゃないので、気をつけたい点も書いておきます。
- 学習コストがある
コンテナ・イメージ・ネットワーク・ボリュームなど、最初に覚えることはそれなりにあります。 - Windowsとの相性
Windows環境ではWSL2（Windows Subsystem for Linux）との組み合わせが必要で、初期設定がやや面倒なことがあります。 - volumesの設定を忘れずに
コンテナを削除するとデータも消えます。DBのデータなどはvolumesで永続化の設定をしておく必要があります。 - 本番環境との完全一致ではない
差異を減らすことはできますが、ゼロにはなりません。特にネットワーク周りや権限まわりは確認が必要です。
Q&A
まとめ
- ローカル環境が壊れる原因は「環境の汚染・差異」だよ。
- Dockerはアプリの動作環境をまるごとパッケージ化できる仕組みだよ。
- コンテナを作り直すだけで環境を復元できるので、壊れてもダメージが少ないよ。
- チームでの環境統一やCI/CD・本番デプロイとの相性もいいよ。
- 学習コストはあるけど、覚えておいて損はない技術だよ。
インストール手順や具体的なdocker-compose.yamlの書き方は別の記事でも解説しています。まず「なぜDockerを使うのか」が腹落ちしたら次のステップに進んでみてください。