開発環境・テスト環境・本番環境の違いとは？発注者が知っておくべき3つの環境
システム開発を依頼していると、担当エンジニアからこんな言葉を聞くことがあるかもしれません。
「開発環境で動作確認ができました」 「ステージング環境にデプロイしましたので、ご確認をお願いします」 「本番環境へのリリースは〇月〇日を予定しています」
これらの「環境」という言葉、正確に理解できていますか？エンジニアにとっては当たり前の用語ですが、発注側の事業担当者にとっては聞き慣れない言葉です。
しかし、各環境の役割を理解することは、発注者として非常に重要です。環境の違いを知ることで、開発会社と対等にコミュニケーションが取れるようになり、「本番でいきなりバグが発覚した」「テストが不十分なまま公開されていた」といった発注トラブルを防ぐことができます。
本記事では、非エンジニアの方でもわかるように、システム開発で使われる3〜4つの環境をわかりやすく解説します。各環境で発注者としてどのような確認や承認を行うべきかについても説明しますので、ぜひ最後までお読みください。
目次
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
システム開発における「環境」とは何か
システム開発における「環境」とは、ソフトウェアが動作する場所や設定の組み合わせのことです。具体的には、サーバー（コンピューター）、OS（基本ソフト）、データベース、その他の設定がひとつにまとまった状態を指します。
なぜ複数の環境が必要なのか、映画制作に例えてみましょう。
- 撮影スタジオ（開発環境）: 俳優がセリフを覚えたり、カメラワークを練習したりする場所。失敗しても大丈夫な場所
- 試写会（テスト環境・ステージング環境）: 一般公開前に関係者だけで作品を確認する場
- 映画館での本公開（本番環境）: 実際の観客（ユーザー）が見る場所。ここで問題が起きると大きな影響が出る
同様に、システム開発でも「作りながら確認する場所」「最終確認する場所」「実際に使ってもらう場所」を分けて管理することで、品質を担保しています。
もし環境を分けずに、いきなり本番環境で開発・テストをしてしまうと、バグが直接ユーザーに影響を与えたり、本番データが壊れたりするリスクがあります。
開発環境（Development Environment）とは
開発環境とは、エンジニアがコードを書き、動作確認をするための場所です。
開発環境の特徴
開発環境は通常、エンジニアが使っているパソコン（ローカル環境）や、チーム専用のクラウドサーバー上に構築されます。ここでは、エンジニアが自由にコードを変更したり、機能を試したりできるように設定されています。
- 本番データ（実際の顧客データ等）は使わず、テスト用のダミーデータを使用する
- エンジニアが自由に設定を変えられる
- 動作が壊れても問題ない「実験場」のような場所
発注者へのポイント
開発環境では、エンジニアがまず機能を「動くか動かないか」の観点で確認しています。発注者がここでの動作確認を求められることは少ないですが、もし確認する場合は**「機能が大まかに動いているかどうか」だけを確認**すれば十分です。見た目の細かい調整や、使いやすさの確認は、後の環境で行います。
テスト環境（検証環境 / Test Environment）とは
テスト環境とは、開発した機能が正しく動くかを、複数のメンバーで確認するための場所です。「検証環境」と呼ばれることもあります。
テスト環境の特徴
テスト環境は、開発チームのメンバー全員が同じ条件でテストできるよう、共有のサーバー上に構築されます。ここでは主に以下のようなテストが行われます。
- 単体テスト: 個々の機能が正しく動くかの確認
- 結合テスト: 複数の機能を組み合わせたときに正しく動くかの確認
- バグの発見と修正
発注者へのポイント
テスト環境での不具合発見は、システム開発において費用対効果が最も高いタイミングです。本番環境に公開した後に不具合が見つかると、修正コストは開発中の数倍から数十倍になることもあります。
発注者として、「テストは十分に行われているか」「誰がどのようなテストをするのか」を事前に開発会社に確認しておくことをおすすめします。テスト項目書（テストケース）を提出してもらうことで、テストの網羅性を確認できます。
システム開発の品質管理の目的と手法についても理解しておくと、開発会社とのコミュニケーションがよりスムーズになります。
ステージング環境（Staging Environment）とは
ステージング環境とは、本番環境と同じ構成で、リリース直前の最終確認を行うための場所です。「本番前の最後の関門」と理解すると分かりやすいでしょう。
ステージング環境の特徴
ステージング環境は、本番環境と同じ（またはほぼ同じ）ハードウェア、ソフトウェア、データ量の設定で動作します。テスト環境が「機能が動くか」を確認する場所であるのに対し、ステージング環境は「本番に近い条件で、実際に使い物になるか」を確認する場所です。
ステージング環境を省くと何が起きるか
コスト削減のために「ステージング環境は不要では？」と考える発注者の方もいます。しかし、ステージング環境を省いた場合、以下のようなリスクがあります。
- 本番環境で初めてバグが発覚する: テスト環境では問題なく動いていたのに、本番環境の条件（データ量・負荷・設定の細かい違い）によって動かなかった、ということが実際のプロジェクトでよく起きます
- ユーザーへの直接影響: 公開後すぐに不具合が見つかり、サービスの停止や修正作業が必要になる
- 信頼の損失: リリース直後のトラブルは、ユーザーや関係者からの信頼を大きく損ないます
ステージング環境の構築にはコストがかかりますが、本番での障害対応コストと比べれば大幅に安く済みます。
発注者へのポイント
ステージング環境は、発注者が本番公開前に実際にシステムを操作して確認する絶好の機会です。ここでの確認（受け入れテスト）で問題がなければ、本番公開のGOサインを出すことになります。
「本番とほぼ同じ条件で試せる」ため、「本番で使えるか」を発注者自身が判断できます。開発会社に確認してもらうだけでなく、発注者側でも実際に使用してみましょう。受け入れテストの具体的な進め方については、別途詳しく解説しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
本番環境（Production Environment）とは
本番環境とは、実際のユーザーが使用する環境です。「プロダクション環境」と呼ばれることもあります。
本番環境の特徴
本番環境は、外部のユーザーが実際にアクセスする環境であり、システム開発の最終目的地です。
- 高い安定性が求められる: システムが止まるとビジネスに直接影響する
- 高いセキュリティが必要: 本物のユーザーデータ（個人情報等）が扱われる
- パフォーマンスが重要: 多くのユーザーが同時にアクセスしても問題なく動作する必要がある
本番環境で直接修正をしてはいけない理由
発注者から「急いでいるから本番環境で直接修正してほしい」という要望が出ることがありますが、これは危険な行為です。
本番環境で直接修正（ホットフィックス）をすると、修正中にシステムが一時的に止まる可能性があります。また、修正の影響を事前に確認する手順がスキップされるため、修正が別の問題を引き起こすリスクもあります。緊急の修正であっても、開発環境→テスト環境→本番環境という手順を踏むことが重要です。
発注者へのポイント
本番環境にリリースした後も、発注者として以下の点を確認しておきましょう。
- 監視体制: 本番環境でエラーや異常が発生した場合、誰が気づき、誰が対応するのかを事前に決めておく
- 障害対応フロー: 障害発生時の連絡先・対応手順・優先度の基準
- バックアップ: データのバックアップが適切に行われているか
これらのリリース後の体制は、システム開発の発注段階で必ず確認しておくべき事項です。システム開発で失敗しないためのポイントについては、システム開発が失敗する原因と防止策の記事も参考にしてください。
4つの環境を使ったシステム開発の流れ
ここまで説明した4つの環境は、システム開発において以下の順番で活用されます。
開発環境 → テスト環境 → ステージング環境 → 本番環境
各フェーズで行われる主な作業をまとめると、次のようになります。
環境 |
主な目的 |
主な担当者 |
発注者の関与 |
|---|---|---|---|
開発環境 |
コーディング・個人での動作確認 |
エンジニア |
基本的に不要 |
テスト環境 |
機能テスト・バグの発見と修正 |
エンジニア・QA担当 |
テスト項目の確認・一部参加 |
ステージング環境 |
本番リリース前の最終確認 |
エンジニア・発注者 |
受け入れテスト・公開承認 |
本番環境 |
実際のユーザーが使用 |
運用担当 |
監視・フィードバック収集 |
このように段階を踏んで進めることで、各フェーズで問題を発見・修正でき、最終的に高品質なシステムを本番環境に公開できます。
発注者として知っておきたい3つのポイント
環境についての基本を理解した上で、発注者として特に重要な3つのポイントを押さえておきましょう。
1. 各環境での確認タイミングと担当者を事前に決める
「どの環境で誰が何を確認し、承認するのか」を、開発開始前に明確にしておきましょう。特に以下の点は重要です。
- ステージング環境での受け入れテストのスケジュール
- 発注者側の確認担当者と連絡先
- 本番公開前の最終承認者と承認フロー
これを事前に決めておかないと、「確認の連絡が来たが、担当者が不在で判断が遅れた」「本番公開後に発注者が問題に気づいた」というトラブルの原因になります。
2. 「ステージング環境なし」の提案には注意する
開発会社から「コスト削減のためステージング環境は省きます」という提案が来ることがあります。小規模・短期のシステムでは省略できる場合もありますが、基本的には設けることをおすすめします。
ステージング環境なしで本番リリースをすると、発注者がシステムの完成品を確認するのは「本番公開後」になってしまいます。これでは問題が見つかっても、修正の影響がユーザーに直接及ぶリスクがあります。
3. 「本番環境で直接修正してほしい」と言わない
急いでいる場合でも、「本番環境で直接修正してほしい」という要求は避けましょう。本番での直接修正は、適切な確認手順を省略した行為であり、修正が別の問題を引き起こすリスクを高めます。
代わりに「修正を最優先で対応してもらい、開発環境→テスト環境→本番環境の手順は維持しつつ、スピードを上げてほしい」と伝えるようにしましょう。
まとめ
システム開発における各環境の役割をまとめます。
- 開発環境: エンジニアがコードを書く実験場。発注者の関与は少ない
- テスト環境: 機能の動作確認と不具合の発見。ここでの修正がコストを抑える鍵
- ステージング環境: 本番前の最終確認。発注者が受け入れテストを行う場
- 本番環境: 実際のユーザーが使う場所。直接の修正作業は避ける
環境を分けて段階的に確認することは、システムの品質を高めるための重要なプロセスです。発注者として各環境での確認フローを理解し、適切なタイミングで関与することで、「リリース後にバグが続出した」「思っていたものと違った」というトラブルを防ぐことができます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
