デザイナーのための開発ステージングプロダクション：2026年ガイド

多くのデザイナーは、開発環境、ステージング環境、本番環境について、間違った環境で何かを壊してしまうことで初めて学びます。Loomが送信され、エンジニアが顔をしかめ、Slackスレッドが「あれ、このURLはどれだっけ？」という質問で始まります。これがオンボーディングのすべてです。

本来、初日に受けるべき説明はこれです。専門用語を並べ立てたり、曖昧な説明をしたりするのではなく、3つの環境、それぞれの環境で働く人々、そしてデザイナーとしてそれぞれの環境で何をすべきかを明確に説明します。

間違ったタブを見ながら「これ、もう公開されてる？」と疑問に思ったことがあるなら、この資料はあなたのために書かれたものです。

なぜ3つの環境が存在するのか

ソフトウェアには、物理​​的な製品にはない問題があります。一度出荷されると、すべての人に即座に、同時に届けられます。工場も、テスト市場も、段階的なロールアウトもありません。ページを更新する間に、たった一つの変更が何百万人ものユーザーに影響を与える可能性があります。

3つの環境が存在するのは、ユーザーが問題に気づく前に、チームが間違いを犯すための場所を提供するためです。開発段階では、多少のミスは許容されます。ステージング段階では、多少のミスは許容されます。しかし、本番環境では、実際のユーザーが見ているため、一切のミスは許されません。

これは、同じ記事が3回の編集プロセスを経るのと似ています。最初のドラフトは粗削りで、ゲラ刷りはほぼ完成しており、印刷された雑誌は10人ほどの人に読まれています。誰も最初のドラフトを公開しませんし、同じ理由で、誰も設計段階からいきなり本番環境に移行しません。

段階を飛ばすチームは、規模が小さい、開発スピードが速い、あるいは無謀な場合があります。時には、そのすべてが当てはまることもあります。この構造は、チームがスピードを落とすことなく、無謀さを克服して成長できるようにするために存在します。

3つの環境のチートシート

さらに詳しく説明する前に、スクリーンショットを撮っておけば、二度と質問する必要がなくなるチートシートをご紹介します。

| 環境 | 目的 | 対象ユーザー | データ | URLパターン | デプロイトリガー | レビュースタイル |

|---|---|---|---|---|---|---| | 開発環境 | 自由に構築・破壊 | エンジニア1名、時にはあなた | ダミーデータまたはシードデータ、しばしば不具合あり | localhost:3000 または yourname.dev.app | ローカルでのコード変更 | ペアプログラミング、画面共有 |

| ステージング環境 | ユーザーへの公開前の最終チェック | 社内チーム、デザイナー、QA担当者 | 現実的、匿名化、更新済み | staging.app.com または pr-123.app.com | PRマージまたは手動プッシュ | 非同期レビュー、Loom、Figma比較ツール |

| 本番環境 | 実際のシステム | 顧客、全世界 | リアル、機密性、不可逆性 | app.com | タグ付きリリースまたはメインブランチへのマージ | モニタリング、リリース後のQA |

もし1行だけ覚えておくとしたら、データ行を覚えておきましょう。開発環境にはダミーデータ、ステージング環境には現実的なデータ、本番環境には改変すると訴訟につながるデータがあります。これら3つを適切に扱いましょう。

開発環境：エンジニアの住まい、そして意図的に不具合が発生する場所

開発環境とは、エンジニアが自分のノートパソコンや個人用クラウドサンドボックスで実行している環境のことです。通常はlocalhostと呼ばれます。これはエンジニアのマシン上で動作し、仮想データベースと通信し、一度に一人しかアクセスできません。このような環境を目にすることはほとんどありませんが、それは当然のことです。

エンジニアが「私のマシンでは動く」と言う場合、それは開発環境のことです。半分は、データが仮想データで、ネットワークが高速で、他に何も処理が行われていないため、そこで動作するのです。残りの半分は、5分前に完成したばかりで、現実世界に近い環境でテストされていないためです。

開発環境は、新しいコンポーネントが初めて登場する場所でもあります。Figmaでカードパターンを受け取った場合、それが実際のコードに初めて登場するのは、エンジニアの開発環境です。エンジニアはlocalhostからスクリーンショットやLoomの結果をあなたに送ってくるでしょう。それは最終版ではなく、ラフカットを見せているだけです。

開発環境のピクセル単位の完成度をレビューする必要はありません。開発環境をレビューして、構造、動作、意図を確認します。ピクセルに関するメモはステージング環境用に保管してください。

ステージング：最終リハーサル

ステージングとは、顧客がテストする前にチームが自ら検証を行う場です。

実際のインフラストラクチャ上で、現実的なデータを用いて、通常は通常のドメインの前に「staging」という単語が付いたURLで動作します。

チームメンバーは誰でもステージング環境を確認できますが、顧客はできません。

デザインレビューの大部分はここで行います。Figmaファイルと比較し、実際のデバイスでフローを操作します。Figmaでは問題なく見えるのに、コードでは奇妙な動作をする箇所（行の高さ、フォーカス状態、名前が40文字の場合、データが全くない場合など）を見つけ出します。

ステージング環境は、チームが可能な限り本番環境を忠実に再現します。同じデータベース構造、テストモードの同じサードパーティサービス、同じ機能フラグ、同じ認証フローを使用します。ステージング環境が本番環境に近ければ近いほど、出荷時に予期せぬ問題が発生する可能性は低くなります。ステージング環境と本番環境の連携が疎かになると、本来なら無料で発見できたはずのバグを出荷してしまうことになります。

ステージング環境は、エンジニアがあなたの設計を意図通りに解釈したかどうかを確認する場でもあります。半分のケースでは正しく解釈されていますが、残りの半分は、まさに議論が始まる場所です。

本番環境：実際のユーザーが利用する場所

本番環境とは、稼働中のウェブサイトのことです。顧客がブラウザにURLを入力した際に目にするものです。実際のインフラストラクチャ上で稼働し、実際のデータ、実際の資金が流れ、あらゆる変更が実際の結果をもたらします。あなたがクリックするたびに、ユーザーと同じシステムとやり取りしていることになります。

本番環境では、あなたはデザイナーではなく、ゲストとして行動することになります。アイデアをテストするために本番環境でクリック操作をしたり、試用したりしてはいけません。何が起こるかを確認するために偽のユーザーでログインしてはいけません。なぜなら、本番環境には偽のユーザーは存在せず、実際のユーザーと実際のレコードしか存在しないからです。そして、それらのレコードは、あなたが誤って破損させてしまう可能性があります。

本番環境は、監視、デプロイ後のスポットチェック、既に稼働しているもののスクリーンショット撮影などに使用します。何かをテストする必要がある場合は、ステージング環境に戻ります。ステージング環境で確認できない場合は、プレビューを依頼します。本番環境に直接手を加えてはいけません。

どのチームにとっても、このルールをどれだけ厳格に守っているかが成熟度を測る指標となります。経験の浅いチームは頻繁に本番環境にアクセスしますが、経験豊富なチームは本番環境をクリーンルームのように扱います。

単一変更のライフサイクル

単一のデザイン変更は、ユーザーが目にするまでにすべての環境を経由します。このライフサイクルを理解しているかどうかが、エンジニアを苛立たせるデザイナーと、エンジニアを喜ばせるデザイナーを分ける決定的な要素となります。

変更が実際にどのように進むかは以下のとおりです。

1. 注釈、状態、エッジケースを含むデザインをFigmaで渡します。

2. エンジニアが変更を開発環境に取り込み、ローカルでビルドします。

そして、作業はチームに公開されます。

3. プルリクエストが作成され、固有のURLを持つプレビューデプロイメントが開始されます。

4. プレビューを確認し、コメントを残し、変更を要求し、承認します。

そして最終的に、ユーザーに反映されます。

5. プルリクエストがマージされ、変更がステージング環境にデプロイされ、チームによる最終レビューが行われます。

6. ステージング環境が承認されると、変更が本番環境にデプロイされ、ユーザーが確認できるようになります。

ステップ3と4は、まさに画期的な機能です。プレビューデプロイメントのおかげで、ステージング環境がコードに反映されるまで待つ必要がなくなりました。エンジニアがブランチをプッシュした瞬間に、変更を確認できます。これはかつては贅沢な機能でしたが、今では必須機能です。

もしあなたのチームがプレビューデプロイメントを導入していないなら、これは導入すべき最も効果的な機能です。ぜひ導入を働きかけましょう。

プレビューデプロイメントがすべてを変えた

10年前、設計レビューといえば、エンジニアのデスクまで出向くか、翌週の火曜日のステージング環境へのプッシュまで待つかのどちらかでした。現在、最新のホスティングプラットフォームはすべて、プルリクエストごとに固有のURLを付与します。Vercelはこれをプレビューデプロイメント、Netlifyはデプロイプレビュー、Render、Cloudflare、AWS Amplifyはいずれも同様の機能を提供しています。

これは実際にはどういうことかというと、すべてのブランチ、すべてのプルリクエスト、すべての変更に対して、何も待つことなく確認できるライブのクリック可能なURLが発行されるということです。エンジニアがブランチをプッシュすると、プレビューは2分でビルドされ、ボットがプルリクエストにURLを挿入します。あなたはそれをクリックして確認し、コメントを付けて、次の作業に進みます。

プレビューデプロイメントは、設計レビューのサイクルを数日から数分に短縮します。また、プレビューURLは操作可能なLoomビデオであるため、Loomビデオの必要性を大幅に減らします。まだプレビューを使ったことがない場合は、エンジニアにオープンなプルリクエストのボットコメントの場所を尋ねてください。リンクはそこにあります。

プレビューについて知っておくべき点がいくつかあります。プレビューはステージングデータまたはテストデータで実行され、本番データでは実行されません。プレビューは一時的なものであり、プルリクエストがクローズされると削除されます。各ブランチごとに固有のURLが割り当てられているため、10個のブランチを同時に開いて、それぞれ異なる機能を使用できます。

環境変数、設定、そして「テストモード」が表示される理由

すべての環境は同じコードを実行しますが、異なるサービスと通信します。開発環境はテストデータベース、ステージング環境はステージングデータベース、本番環境は実際のデータベースを使用します。また、各環境ではサードパーティツールの異なるバージョンが使用されます。開発環境とステージング環境ではテストモードでStripe、本番環境ではライブモードでStripeが使用されます。メール送信ツール、分析ツール、認証ツール、その他の外部依存関係についても同様です。

チームがこれらの情報を管理するために使用するのが環境変数です。環境変数は設定やシークレットとも呼ばれます。これらはDATABASE_URLやSTRIPE_KEYといった名前付きの値で、環境ごとに変更されます。Doppler、Vercel env vars、AWS Secrets Manager、1Password Connectなどのツールがこれらの環境変数を管理します。

デザイナーであるあなたにとってこれが重要な理由：ステージング環境で「Stripe」と入力するとテスト用のカード番号が表示される場合、それはステージング環境の「Stripe」キーが動作しているからです。開発環境で自分の開発者プロフィール画像が表示されるのに、クレジットカード情報が完全に偽物の場合、それは開発環境が偽のデータベースからデータを取得しているのに、実際の店員による認証が行われているからです。ステージング環境では動作するのに本番環境では動作しない場合、90%の確率で環境変数が欠落しているか、異なっていることが原因です。

これらの環境変数を管理する必要はありません。ただ、それらが存在することを知っておけば、エンジニアが「待って、それは本番環境の「Stripe」キーを使用している。そのボタンをクリックしないで」と言ったときに、その意味が理解できます。

データパリティ：実際に何を見るか

各環境内のデータによって、テストできるものとできないものが決まります。これはデザイナーが最も見落としがちな点です。

開発環境には通常、シードデータ、つまり少数の偽ユーザー、偽商品、その他すべてが偽物で、毎朝新しいデータに更新されます。名前はふざけたもので、住所はスプリングフィールドの住所、アバターは小さな灰色の四角形です。このデータに対して、空の状態やエッジケースを評価しようとしないでください。なぜなら、これは正常な動作経路を再現するために構築されているからです。

ステージング環境には通常、匿名化された本番データ、または厳選された現実的なデータセットがあります。実際の形状、実際の長さ、実際のエッジケースが含まれていますが、名前とメールアドレスは削除されています。ここでは、クリストファー・ハッサン＝ウィリアムソン3世という名前の顧客や、63個の明細項目を含む注文に対して、デザインがどのように表示されるかを実際に確認できます。真の設計品質保証を行えるのは、ここだけです。

本番環境には実際のデータがあります。だからこそ、本番環境をいじってはいけません。スナップショットやダッシュボードを参照することはできますが、本番環境をテスト環境として使用してはいけません。

各環境におけるデザイナーの役割

各環境における自分の役割を最も分かりやすく理解するには、それぞれの環境で異なるモードを自分に割り当てましょう。

開発環境では、あなたはチームメンバーです。画面共有で簡単なチェックインを行い、エンジニアが設計を理解しているかを確認し、大きな構造上の問題を早期に発見します。エンジニアがまだ開発段階にあるため、開発環境では修正指示を出す必要はありません。

ステージング環境では、あなたは設計の品質保証担当者です。Figmaファイルと比較し、状態を確認し、パンチリストを作成します。ここでは本格的なレビューを行い、構造化されたコメントを残し、変更を承認または却下します。ステージング環境はあなたの領域です。

本番環境では、あなたはゲストです。リリースされた変更を確認し、スクリーンショットを撮り、必要であればアナリティクスを監視します。本番環境では、むやみにクリックしてテストしたり、「ちょっとだけ試してみよう」などとしたりはしません。

これらの3つのモードを常に意識しておけば、エンジニアリングチームにとって最も扱いやすいデザイナーの一人になれるでしょう。

デザイナーが頻繁に犯すミス

私はデザイナーがこれらのミスを犯すのを何度も見てきました。私自身もいくつか犯したことがあります。どれも致命的なミスではありませんが、チームの作業効率を低下させ、エンジニアリングチームの信頼を損なう原因となります。

よくあるミス：

• 開発用URLをクライアントに送る。 開発環境は誰かのノートパソコンにあるため、クライアントがリンクをクリックすると接続エラーが発生し、「何か出荷する予定はあるのか？」と尋ねられます。

• 古いCDNキャッシュから「本番環境のバグ」を報告する。 6時間前にキャッシュされたバージョンを見ていたため、強制的に更新すると問題が解決します。

次に挙げるのは、どのバージョンが本番環境で動作しているのかを誤解することから生じるミスです。

• ステージング環境で既に修正済みのバグを報告する。 本番環境を見て古いバージョンを確認し、慌ててバグ報告（Slack）を提出。修正はステージング環境で1週間前から適用されていました。

• プレビューリンクを求めない。 エンジニアがプッシュした瞬間にプレビューURLを共有できたはずなのに、ステージング環境に反映されるまで3日間も待たされる。

最後の2つは、ステージング環境と本番環境の境界線を尊重することに関するものです。

• 本番環境にアクセスして「テスト」する。 あなたはもう実際のユーザーであり、実際の結果が伴うので、やめましょう。

• デプロイログを確認する代わりに「これはもう稼働していますか？」と尋ねる。 ほとんどのチームには、デプロイのたびに投稿されるSlackチャンネルがあるので、ブックマークしておきましょう。

これらは、存在を知っていればどれも一行で修正できます。どれも愚かなことではありません。ただ、誰も教えてくれなかっただけです。

必要なものを求める方法

これらの間違いの裏側には、マナーがあります。環境に関するデザイナーとエンジニアのコミュニケーションは、ほとんどの場合、具体的に伝えることが重要です。曖昧な要求は時間を浪費しますが、具体的な要求は何も損失しません。

悪い例：「新しいカードデザインをどこかにプッシュしてもらえませんか？見たいです。」

良い例：「カードデザインのブランチをプッシュして、準備ができたらプレビューURLを教えてください。」

悪い例：「ホームページの更新はもう反映されていますか？」

良い例：「PR 412はもう本番環境に反映されていますか？それともまだステージング環境ですか？」

悪い例：「本番サイトで何かがおかしいようです。」

良い例：「本番環境で、/pricing の価格カードの下部の枠線が表示されません。ハードリフレッシュしても、まだ表示されません。スクリーンショットを添付します。」

どの例もパターンは同じです。環境名、変更内容、そして証拠を提示してください。このようにリクエストを提出するデザイナーのために、エンジニアはあらゆる努力を惜しみません。そうでないデザイナーには、密かに不満を抱くでしょう。

フィーチャーフラグ：本番環境内のステージング環境

開発/ステージング/本番環境というモデルを、より効果的に覆す4つ目の概念があります。それがフィーチャーフラグです。フィーチャーフラグとは、コード内のスイッチで、「この新機能をユーザーXには表示するが、ユーザーYには表示しない」という指示を出すものです。チームはこれを利用して、新機能を少数のユーザーグループ（多くの場合、社内スタッフのみ）にのみ公開しつつ、コードを本番環境にデプロイします。

LaunchDarkly、Statsig、ConfigCat、そしてVercel独自のフラグといったツールがこれを実現しています。新しいデザインは技術的には本番環境で稼働していますが、内部フラグが設定されているユーザーのみがそれを見ることができます。それ以外のユーザーは旧バージョンを見ることになります。

これはあなたにとって重要です。「これは本番環境ですか？」という質問への答えが曖昧になるからです。コードは稼働していても、機能自体は稼働していない可能性があるため、エンジニアにアカウントのフラグを切り替えてもらう必要があるかもしれません。あるいは、「リリース済みですが、フラグで保護されています。火曜日に全員に公開します」と言われるかもしれません。

フィーチャーフラグは、成熟したチームが全員に影響を与えることなく継続的にリリースを行うための方法です。また、実際のユーザーと実際の本番データを使って、低リスクでステージングレビューに相当するものを実施することもできます。

各環境からわかるチームの成熟度

チームがこれら3つの環境をどのように扱っているかを見れば、そのエンジニアリングの成熟度をほぼすべて把握できます。新しいクライアントや役割を担う際に、この情報を手っ取り早く確認するのに活用してください。

ステージング環境がないチームは、急いで開発を進め、あとは運任せです。いずれ顧客を失うようなバグに遭遇し、それからようやくステージング環境を構築するでしょう。

ステージング環境はあるもののプレビューデプロイメントがないチームは、中間段階です。レビューは遅く、「完了」から「デザイナーが確認できる」までのサイクルは数日単位で、待ち時間が長くなります。

プレビューデプロイメント、本格的なステージング環境、監視された本番環境、そしてフィーチャーフラグを備えているチームは、まさに理想的なレベルで運用されています。フィードバックループは短く、ミスは早期に発見され、ローンチ当日にパニックになる人はいません。このレベルで働いた経験があれば、他のレベルの環境は疲れ果ててしまうでしょう。

3つの環境、3つのユーザー、3つのデータセット、そしてそれらを繋ぐ1つのライフサイクル。これがコンセプトのすべてです。その他はすべて、その上に構築されたツールに過ぎません。

コードのデプロイ方法やVercelアカウントの管理方法を知る必要はありません。必要なのは、どの環境を見ているのか、そこで何ができるのか、そして適切なURLをどうやって入手するのかを知ることだけです。そうすれば、エンジニアが一緒に仕事をしたいと思うデザイナーになれるでしょう。

デプロイログをブックマークし、プレビューリンクをリクエストして、本番環境には絶対に手を出さないでください。