LASSIC Media らしくメディア

システム開発のプロジェクトを進めていると、ベンダーから「まず開発環境で作って、ステージング環境で確認いただき、問題なければ本番環境へ反映します」といった説明を受ける場面があるのではないでしょうか。IT事業部で開発の進捗やリリースの報告を受ける立場にいると、この「開発」「ステージング」「本番」という言葉が当たり前のように飛び交うものの、それぞれが何を指し、なぜ分ける必要があるのかは、あらためて聞きにくいところかもしれません。これらは、システムを壊さずに育てて世に出すために用意される「作業場所」の区分です。役割の違いを大まかにでも理解しておくと、なぜ確認に時間がかかるのか、どの環境での話をしているのか、リリースのどの段階にいるのか、といった判断がしやすくなります。本記事では、特定のツールや構築手順ではなく、開発・ステージング・本番という3つの環境がそれぞれ何を担い、なぜ分けるのか、そして発注・運用の場面で何に気をつけるべきかを、発注者やPMの視点から順に整理します。用語をすべて覚える必要はありませんが、「本番に近づくほど慎重に扱う」という勘所をつかんでおくと、ベンダーとの会話がぐっと通じやすくなるはずです。

開発・ステージング・本番環境とは

システム開発では、同じシステムを動かす「場所」を用途ごとに複数用意するのが一般的です。代表的なのが、開発環境・ステージング環境・本番環境という3つの区分です。まずはそれぞれの位置づけを大づかみに押さえておきましょう。

そもそも「環境」とは、システムが動くために必要な一式——サーバやデータベース、各種の設定、つながる外部サービスなどをひとまとめにした「動作する場所」を指します。同じプログラムでも、動かす環境が違えば、使うデータも設定も別物になります。この一式を用途ごとに分けて用意することが、環境を複数持つということの中身です。まったく同じ建物の間取りで、モデルルーム・内覧用の部屋・実際に住む家を別々に用意するようなイメージだと捉えると分かりやすいでしょう。

開発環境は、開発者が実際にプログラムを書き、動かしながら試すための場所です。いわば作業場や工房にあたり、思い切って手を加えたり、途中で壊れたりしても問題ありません。ステージング環境は、本番へ出す前の最終確認を行うための場所で、本番とできるだけ近い構成で用意するのが基本です。リハーサル会場のようなもので、開発者だけでなく、品質を確認する担当者や発注者が「本番と同じように動くか」をチェックします。本番環境は、実際にエンドユーザーが利用する、いわば本番の舞台です。ここで動いているものが、利用者の目に触れ、業務に使われます。

変更は、この3つを「開発 → ステージング → 本番」の順に、段階的に進めていくのが基本です。左にあるほど自由に試すことができ、右へ進むほど本物に近づき、慎重な扱いが求められます。次の図は、この流れと各環境の位置づけを単純化して示したものです。

なぜ環境を分けるのか

環境を複数に分けるのは手間もコストもかかります。それでも分けるのには、はっきりした理由があります。

いちばん大きな理由は、利用者に影響を与えずに開発と確認を進めるためです。もし開発中のプログラムを本番環境で直接いじれば、作りかけの機能や不具合が、そのまま実際の利用者の目に触れてしまいます。データが壊れたり、サービスが止まったりするおそれもあるのです。作業用の場所を切り離しておけば、いくら試行錯誤しても、利用者に迷惑をかけずに済みます。もう一つの理由は、本番に出す前に落ち着いて検証するためです。開発者の手元では動いたものが、本番に近い構成では思わぬ挙動を見せることがあります。その差を、利用者に見せる前のステージング環境で洗い出しておくわけです。

加えて、役割と権限を分けやすくなるという利点もあります。本番環境は影響が大きいため、触れる人や変更の手順を限定したいものです。環境を分けておけば、「開発者は開発環境で自由に、本番環境の変更は決められた手順で」といった線引きがしやすくなります。つまり環境の分離は、単なる作業スペースの都合ではなく、品質と利用者保護のための土台だといえるでしょう。

具体的な例で考えてみましょう。ある企業で、本番稼働中のシステムに小さな修正を、確認用の環境を通さずに直接加えたとします。修正そのものはささいでも、想定していなかった別の機能に影響し、利用者が注文を確定できなくなってしまった——このような事故は、環境を分けずに本番へじかに手を入れたときに起こりがちです。開発とステージングという「試せる場所」があれば、こうした影響を世に出す前に見つけられます。環境を分ける手間は、事故を避けるための保険のようなものだと考えると、その意義がつかみやすくなるはずです。

3つの環境の役割の違い

3つの環境は、目的も、使う人も、扱うデータも異なります。違いを表に整理すると、それぞれの性格がつかみやすくなります。

この表からわかるのは、右へ進むほど「本物に近く、壊れたときの影響が大きい」という点です。だからこそ、変更はいきなり本番に入れるのではなく、開発で作り、ステージングで確かめ、最後に本番へ、と順を追って進めます。なお、プロジェクトの規模によっては、ステージングを省いて開発と本番の2つにする場合や、逆に検証用の環境をさらに細かく分ける場合もあります。3つが絶対の型というわけではなく、リスクと手間のバランスで選ばれる、という点も覚えておくとよいでしょう。

ステージング環境について補足すると、その価値は「本番にどれだけ近いか」で決まります。サーバの構成やデータ量、つながる外部サービスが本番とかけ離れていると、そこでの確認が本番での動作を映しにくくなります。とはいえ本番とすべて同じにすればコストもかさむため、どこまで近づけるかは、確認したいリスクとのバランスで判断するのが実務的でしょう。「ステージングでは問題なかったのに本番で不具合が出た」という声の裏には、両者の隔たりが大きかった、という事情が隠れていることもあります。

環境の違いで起きやすい問題

環境を分けること自体は有効ですが、環境ごとの「違い」が原因で、思わぬトラブルが起きることもあります。代表的なものを知っておくと、報告を受けたときの理解が深まります。

よくあるのが、環境差異による「開発では動いたのに本番で動かない」という問題です。各環境の設定やソフトのバージョン、つながる先が少しずつ違うと、開発環境では問題なかった処理が、本番で不具合を起こすことがあります。これを防ぐために、ステージング環境を本番にできるだけ近づけておくことが重要になります。次に多いのが、設定値の取り違えです。接続先やパスワードにあたる情報などは環境ごとに異なるため、本番用の設定を入れ忘れたり、逆に検証用の設定のまま本番に反映してしまったりすると、障害につながります。こうした環境ごとの設定は、プログラム本体と切り離して管理するのが定石です。

もう一つ注意したいのが、データの扱いです。検証のために本番の実データをステージングへコピーする場面がありますが、そこには個人情報などが含まれることも多く、そのまま持ち込むと情報の取り扱い上のリスクが生じます。氏名やメールアドレスなどを別の値に置き換える（マスキングする）といった配慮が求められるでしょう。これらの問題は、いずれも「環境が違うのに、同じもののように扱ってしまう」ことから生まれます。環境ごとの差を前提に、設定やデータの受け渡しの手順を決めておくことが、つまずきを減らす近道です。

こうした食い違いを防ぐために、近年は環境の構成をできるだけ自動化し、同じ手順で再現できるようにする考え方が広がっています。手作業で一つずつ環境を作ると、担当者や時期によって微妙な差が生まれがちですが、構成を決まった形で記述して同じ手順で組み立てれば、環境間の差を小さく保てます。発注者が細部まで把握する必要はありませんが、「環境の差をどう抑えているか」をベンダーに尋ねてみると、品質への向き合い方が見えてくることもあるでしょう。

発注・運用で意識したい観点

環境の仕組みそのものは難しくありませんが、プロジェクトを円滑に進めるために、発注や運用の会話で押さえておきたい観点がいくつかあります。

第一に、どの環境が用意されるかです。プロジェクトの初期に、開発・ステージング・本番のうちどれを用意するのか、費用や納期との兼ね合いも含めて確認しておくと、後から「確認する場所がない」と慌てずに済みます。第二に、ステージングでの確認の進め方です。発注者やPMが実際に触れて確認できるのは、多くの場合ステージング環境になります。誰が、いつ、どこまで確認するのかを、リリース計画とあわせて決めておくとよいでしょう。第三に、本番反映の手順とタイミングです。本番への変更は影響が大きいため、いつ・誰が・どんな手順で行うのか、問題が起きたときにどう戻すのかまで、あらかじめ取り決めておくと落ち着いて臨めます。

第四に、データと権限の扱いです。検証に使うデータの用意の仕方や、本番環境に触れられる人の範囲は、品質と情報の取り扱いの両面で重要です。特に個人情報を含むデータの検証利用は、取り扱いのルールを事前に確認しておくことをおすすめします。なお本記事は特定のツールや構築手順ではなく、環境という考え方と運用で押さえたい観点に焦点を当てているものです。個別の環境構築やリリースの仕組みを詰める段階では、利用するクラウドやツールの公式ドキュメント、実績のあるベンダーへの確認が別途必要になります。

まとめ

• 開発・ステージング・本番環境は、システムを育てて世に出すための用途別の作業場所です。
• 開発は作り試す場、ステージングは本番同様の最終確認の場、本番は実際に使われる場という役割の違いがあります。
• 分ける目的は、利用者に影響を与えずに開発・検証を進め、品質と利用者保護を保つことにあります。
• 本番に近づくほど影響が大きく、変更は開発→ステージング→本番へ段階的に進めます。
• 環境差異・設定の取り違え・検証データの扱いが、環境をまたぐ際に起きやすい問題です。
• 発注・運用では、用意する環境・確認の進め方・本番反映の手順・データと権限の扱いを押さえておくと安定します。
• 本記事は特定ツールの手順ではなく、環境という考え方と運用の観点の整理を狙いとしています。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• IPA「アジャイル開発の進め方」関連資料
• Microsoft「デプロイ環境に関するガイダンス」

Tweet