「自分のPCでは動いてたのに……」
開発の現場でこの言葉を聞いたことはありませんか。あるいは自分で言ったことがある方もいるのではないでしょうか。
ローカルの開発環境ってなぜかいつの間にか壊れますよね。ライブラリのバージョンを上げたら別のプロジェクトが動かなくなったり、チームメンバーと環境が微妙に違ってバグの再現ができなかったり。筆者も何度この問題で時間を溶かしたかわかりません。
そこで登場するのがDockerです。「名前は聞いたことあるけど何がいいのかよくわからない」という方に向けて、今回はDockerを使うべき理由を実務目線で解説します。インストール手順よりも先に「なぜ使うのか」をしっかり押さえておくと、後の学習がぐっとスムーズになりますよ。
Dockerを開発環境で使う最大のメリットはプロジェクトごとに独立した環境を作り、別のPCでも同じ状態を再現しやすいことです。チーム開発や複数プロジェクトを扱う場合は特に有効ですが、小規模な個人開発ではローカル環境の方が手軽なケースもあります。
この記事でわかること
- ローカル開発環境がよく壊れる理由
- 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を使うべきかどうかは開発環境を何度も再現する必要があるかで判断するとわかりやすいです。
チームで同じ環境を使いたい、複数のプロジェクトを並行して進めたい、Webサーバーやデータベースをまとめて用意したい。このような場合はDockerが向いています。
依存関係の少ない小さなプログラムを一人で試すだけなら、ローカル環境へ直接インストールした方が早いこともあります。Dockerは便利ですがすべての開発で必須というわけではありません。
Dockerなしの環境と何が変わるのか
Dockerを使わない場合、PHPやNode.js、データベースなどをPCへ直接インストールします。最初は手軽ですが、プロジェクトが増えるにつれてバージョンや設定が混在しやすくなります。
Dockerではプロジェクトごとに独立したコンテナを用意します。別のプロジェクトで異なるバージョンを使っていても、基本的には互いの環境へ影響しません。
| Dockerなし | Dockerあり | |
|---|---|---|
| 環境構築 | 必要なツールをPCへ個別にインストールする | 定義ファイルをもとにまとめて起動する |
| 複数プロジェクト | バージョンや設定が競合しやすい | プロジェクトごとに環境を分けられる |
| チームへの共有 | 手順書を見ながら各自で構築する | 同じ定義ファイルから環境を再現できる |
| 環境が壊れた場合 | インストールや設定を見直す | コンテナを削除して作り直せる |
| 本番環境との差 | OSやバージョンの違いが生まれやすい | 同じイメージを使えば差を減らせる |
特に助かるのが環境を作り直しやすい点です。
PCへ直接インストールした環境では、どの設定が原因なのかわからなくなることがあります。Dockerなら問題のあるコンテナを削除し、定義ファイルから再作成できます。
データベースのデータを保存している場合は注意が必要で、ボリュームまで削除すると（設定次第ですが）データが消えることがあります。
Docker・仮想マシン・ローカル環境の選び方
Docker以外にも仮想マシンやPCへ直接インストールする方法があります。どれが優れているかではなく、何を分離したいかで選びます。
| 向いている用途 | 注意点 | |
|---|---|---|
| Docker | アプリやデータベースの実行環境をプロジェクト単位で分けたい | Docker固有の操作を覚える必要がある |
| 仮想マシン | OSごと分離し、別のOS環境を再現したい | 起動が遅く、メモリやストレージを多く使う |
| ローカル環境 | 小さなプログラムをすぐに試したい | プロジェクトが増えると環境が混在しやすい |
| クラウド開発環境 | PCに大きく依存せず、ブラウザなどから作業したい | 利用料金や通信環境、権限設定を確認する必要がある |
Dockerは仮想マシンのようにOS全体を起動する仕組みではありません。ホストOSのカーネルを共有しながら、アプリの実行環境をコンテナとして分離します。
本番環境をOSごと再現したいような場合は仮想マシン、アプリの依存関係を分けたい場合はDockerが向いています。
Dockerが向いているケース
Dockerを使う効果が大きいのは環境の違いがトラブルにつながる開発です。
チーム開発ではメンバーごとにOSやツールのバージョンが異なると、同じコードでも動作が変わることがあります。Dockerの定義ファイルを共有すれば、全員が近い条件の開発環境を用意できます。
複数のプロジェクトを扱う場合にも便利です。たとえば、一方ではPHP 8系、もう一方ではPHP 7系が必要でも、コンテナを分ければPC全体のバージョンを入れ替えずに済みます。
Webサーバー、アプリ、データベースなど、複数のサービスを組み合わせる開発にも向いています。docker-compose.yamlに必要なサービスを書いておけばdocker compose up -dでまとめて起動できます。
個人開発でもDockerを使うべきか
個人開発だからDockerが不要とは限りません。あとから環境を作り直す可能性があるなら、一人で使う場合にもメリットがあります。
| Dockerを使う価値が高い個人開発 | ローカル環境でも進めやすい個人開発 |
|---|---|
| Webサーバーとデータベースを組み合わせる | 依存関係の少ない短いスクリプトを試す |
| 複数のプロジェクトを並行して進める | 一度だけ動作を確認する |
| 将来ほかの人へ環境を共有する可能性がある | 環境差異が問題にならない |
| 数か月後にも同じ環境を再現したい | Dockerを覚える時間の方が負担になる |
| 本番環境に近い構成で試したい | PCへ入っているツールだけで完結する |
筆者は、複数のサービスを組み合わせる開発や、あとから触り直す可能性があるプロジェクトではDockerを使う方が楽だと感じています。
反対に、数行のスクリプトを試すだけのときまでDockerを用意すると、かえって準備が増えてしまいます。環境を分ける必要があるか、同じ環境をもう一度作る可能性があるか。この2点を基準にすると判断しやすいです。
実務で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で永続化の設定をしておく必要があります。 - 本番環境との完全一致ではない
差異を減らすことはできますがゼロにはなりません。特にネットワーク周りや権限まわりは確認が必要です。
よくある質問
まとめ
- ローカル環境が壊れる原因は「環境の汚染・差異」だよ。
- Dockerはアプリの動作環境をまるごとパッケージ化できる仕組みだよ。
- コンテナを作り直すだけで環境を復元できるので、壊れてもダメージが少ないよ。
- チームでの環境統一やCI/CD・本番デプロイとの相性もいいよ。
- 学習コストはあるけど、覚えておいて損はない技術だよ。
インストール手順や具体的なdocker-compose.yamlの書き方は別の記事でも解説しています。まず「なぜDockerを使うのか」が腹落ちしたら次のステップに進んでみてください。