ローカル環境
エンジニアやデザイナーが、自分の PC(手元のパソコン)の中に擬似的な Web サーバを構築し、Web サイトの動作確認を行う「開発専用の環境」のこと。XAMPP、MAMP、あるいは近年主流の Docker、WSL2 といったツールを使って構築される。インターネットには非公開の完全に閉じた環境なので、どれだけコードを破壊しても外部に影響が出ず、安全かつ自由にテスト開発ができる。
運用の要点：「3 段階プロセス」は品質管理の絶対条件
Web 運用の現場で絶対に守るべきなのが、「①ローカル環境(手元で開発・テスト) → ②ステージング環境(本番そっくりの非公開テスト環境で最終確認) → ③本番環境(一般公開)」という 3 段階の確認プロセス。実務において、このプロセスは「制作業者の開発レベル(信頼度)」を測るリトマス試験紙になる。発注時の要件定義書や契約書に「ローカル → ステージング → 本番の 3 段階運用を行うこと」と明記しておくだけで、ずさんな体制の業者を牽制し、品質トラブルを未然に防ぐことができる。
現場でよくある「落とし穴」
ローカル環境をサボる業者は、顧客のビジネスを平気で危険に晒す。
- 「本番直接編集(本番直当て)」が引き起こす大惨事：納期や予算に追われた業者が手間を省くため、ローカル環境を作らず、いきなり稼働中の「本番環境」のコードを直接書き換えて修正(リリース)を行ってしまう。悲惨な末路として、たった 1 文字のコードの記述ミスで、稼ぎ時(キャンペーン中など)にサイト全体が「真っ白なエラー画面(デグレード)」になってダウンする。さらに最悪なことに、ローカル環境(手元の正常なデータ)がないため、「エラー原因の調査と復旧テスト」まで公開状態の本番環境で泥縄式にやるハメになり、長時間にわたって売上と信用をドブに捨て続けることになる。この修正フローの確認を怠ることは、発注者にとって最大の過失になり得る。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- バックエンドエンジニア
- Web 担当者(発注側)
- 情シス
会話上での使用例
業者選定の打ち合わせで開発体制を確認する場面
-
営業
うちはスピード対応が強みで、修正があればすぐ本番に反映できますよ。
-
Web 担当者(発注側)
スピードはありがたいのですが、本番に直接手を入れるのは事故のリスクが高いので避けたいんです。ローカル環境 で開発して、ステージングで確認してから本番へ、という流れで対応していただけますか。
-
営業
承知しました。弊社でもその3段階の体制を取っていますので、ご安心ください。
発注前に開発フローを業者に確認する場面
-
プロデューサー
修正が発生したとき、御社ではどういう流れで反映しているんですか?
-
Web 担当者(発注側)
そこは大事な確認ポイントですね。各自の ローカル環境 で開発して、ステージングで動作確認をして、最後に本番へ反映する3段階のフローを必須にしておきたいんです。
-
プロデューサー
では要件にもその3段階運用を明記しておきましょう。