「私(ローカル)の環境
では動きました」
開発者のPCではサクサク動く。
しかし、本番サーバーにデプロイした瞬間、エラーで真っ白になる。
「おかしいな、さっきまでは...」
この言葉は、免罪符にはなりません。顧客にとっては「動かない」という事実だけが真実です。
- 開発者はMac、本番はLinuxで、微妙に挙動が違う
- 本番環境の設定ファイルを手作業で修正している（Config Drift）
- 「手順書通りに環境構築したが動かない」という新人が後を絶たない
- DBのデータが本番と開発で全然違うため、バグが再現できない
環境の一致（Parity）が保証されていない開発は、ロシアンルーレットと同じです。
01. Dockerを使おう
「私の環境では動く」なら、その「環境」ごと出荷してしまえばいい。
それがDocker（コンテナ技術）の発想です。
OS、ライブラリ、設定ファイル。全てをコード化（Infrastructure as Code）し、
開発環境と本番環境を「1bitの狂いもなく」同じにする。
これはもはや選択肢ではなく、現代開発の義務です。
バグではない。
「仕様」にせよ。
02. 手順書を捨てよ、スクリプトを書け
「環境構築手順書.xlsx」は、書いた瞬間から腐り始めます。
人間は必ず読み間違え、手順を飛ばします。
環境構築は、コマンド一発（`docker-compose up`）で完了しなければなりません。
機械ができることを人間にやらせるのは、非人道的であり、かつ非効率的です。
03. バージョン固定の重要性
「最新版を使う」というのは聞こえはいいですが、
ライブラリのバージョンを固定（Pinning）しないのは自殺行為です。
今日動いていたコードが、明日の朝、ライブラリのアップデートで突然死ぬ。
`package-lock.json` や `Gemfile.lock` をコミットし、再現性を担保してください。