はじめに

こんにちは、SAKURUGのTakumiです。

システムの開発業務において、「開発環境」「テスト環境」「本番環境」といった複数の環境で作業する機会は、多くの方にあるかと思います。

本記事では、私自身がこれらの環境で実際に作業する中で気づいた注意点や、その対策についていくつか整理し、簡単にまとめてみました。

本内容が、各環境での操作時におけるトラブルやミスの発生を少しでも抑える一助となれば幸いです。

１．開発環境

1-1.開発環境とは

そもそも開発環境とは何なのか...

エンジニアがプログラムの実装や修正を行うための環境です。

この環境では、新機能の作成や既存機能の改修、ローカル環境での動作確認を行います。

データは主にダミーやテスト用のものが使用され、失敗や不具合が発生しても業務に影響が出ないようになっています。

1-2.注意点・対策

①実データや機密情報の取り扱い

【注意すべきこと】

開発環境で本番データや機密情報を安易に扱うと、PCの紛失・盗難、マルウェア感染、ログやスクリーンショットへの個人情報出力などをきっかけに、情報漏えいが発生する可能性があります。

特に開発環境は本番環境に比べてセキュリティ対策が甘くなりがちなので、実データの取り扱いには十分な注意が必要です。

【対策】

開発環境では、原則として主にテストデータやダミーデータを使用します。

やむを得ず本番データを使用する場合は、以下の対策を行い、情報漏えいリスクを最小限に抑えましょう。

・データの暗号化

・アクセス権限を必要最小限に制限

・業務に必要な範囲にデータを絞る（使用データの最小化）

②不要な設定変更やデータ削除の防止

【注意すべきこと】

一時的な検証や動作確認のつもりで行った設定変更やデータ削除が、そのまま放置されることで、後になって原因不明の不具合や想定外の挙動を引き起こす可能性があります。

特に複数人で開発環境を利用している場合、意図しない変更が他の人の作業に影響を与える可能性があります。

【対策】

設定変更やデータ操作が必要な場合は、必ず元に戻せる状態を確保しましょう。

具体的な作業内容として、以下を実施すると良いと思います。

・変更内容・変更理由・変更日時を記録する

・設定ファイルやデータのバックアップを事前に取得する

・検証完了後は設定を元に戻す、または不要なデータを整理する

③中途半端な状態のまま放置しない

【注意すべきこと】

動作しないコードや未完成の設定をそのまま残してしまうと、後から別の担当者が作業する際に分からず混乱を招いたり、不要な調査や切り分け作業が発生する場合があります。

その影響で、作業効率の低下やミスの誘発につながる可能性があります。

【対策】

やむを得ず未完成のコードや設定を残す場合は、その状態や意図が他の人にも分かるように整理しておきましょう。

具体的な作業内容として、以下を実施すると良いと思います。

・ソースコードや設計書、作業メモなどにコメントとして理由や状況を残す

・検証途中のコードはブランチを分けて管理する

・不要になったコードや設定は削除し、開発環境を整理された状態する

④他のメンバーへの影響を意識して作業する

【注意すべきこと】

修正しているソースコードをチームで共有していることが多く、自分の修正やデータ変更が、他のメンバーの作業を妨げたり、想定外の不具合を引き起こす可能性があります。

特に共通処理や共通データへの変更は、影響範囲が広くなりやすいので注意が必要です。

【対策】

他のメンバーへの影響を最小限に抑えるために、以下を実施すると良いと思います。

・大きな変更や影響範囲が広い修正を行う場合は、事前に内容を共有する

・修正箇所が他メンバーの作業内容と競合しないか確認する

・必要に応じて作業タイミングの調整を行う

⑤変更内容を記録する

【注意すべきこと】

どのファイルのどの機能・コードを修正したのか、またその変更目的を記録していない場合、修正前後の差分確認や追加調査が必要となり、結果として作業時間が大幅に増加する可能性があります。

【対策】

変更内容や変更目的を記録として残し、後続のテストやレビューがスムーズに進む状態にしましょう。

具体的に以下を実施すると良いと思います。

・修正したファイル、機能、コード箇所を明確に記録する

・変更理由や背景、期待する動作を併せて記載する

・コミットメッセージや作業メモを残し、誰でも追跡できるようにする

２．テスト環境

2-1.テスト環境とは

そもそもテスト環境とは何なのか...

開発環境で作成したシステムが正しく動作するかを、本番に近い条件で確認するための環境です。　

この環境では、機能が仕様どおりに動くかだけでなく、複数の機能を組み合わせた際の挙動や、他システムとの連携、性能面の問題などの確認を行います。

2-2.注意点・対策

① 直接DBを操作する場合は影響範囲を必ず確認する

【注意すべきこと】

UPDATE・DELETE・TRUNCATE などのSQLを直接実行する際、WHERE句の書き忘れや条件の誤りによって、想定以上のデータを変更・削除してしまう可能性があります。

誤った操作はテストデータの破損や再準備の手戻りにつながり、テスト全体の進み具合に大きく影響する可能性があるので注意が必要です。

【対策】

直接DB操作を行う場合は、影響範囲を事前に把握した状態で作業を行うようにしましょう。

具体的な作業内容として、以下を実施すると良いと思います。

・COMMIT 前に SELECT 文で対象データを事前確認する

・トランザクション内でSQLを実行し、必要に応じて ROLLBACK できる状態で作業する

・万一に備え、バックアップ取得や復旧方法を事前に確認しておく

②他の開発者の作業状況を把握する

【注意すべきこと】

テスト環境を複数の開発者で共有している場合、他のメンバーが同時にテストを行っている可能性があります。

複数の開発者で共有している状態で自分の検証のためのデータ変更や設定変更を行うと、他の開発者のテスト結果に影響を与え、正しい検証ができなくなる可能性があります。

特に、共有テーブルの更新、共通設定の変更、Mock の切り替え、定期バッチの手動実行などは影響範囲が広いため、注意が必要です。

【対策】

他の開発者への影響を防ぐために、以下のような作業を実施すると良いと思います。

・テスト環境を使用している開発者の作業状況を事前に確認する

・影響が大きい操作を行う場合は、事前に関係者へ共有・合意を取る

・必要に応じて作業時間を調整する、または専用のテスト環境・データを用意する

③開発環境とテスト環境の差分を常に意識する

【注意すべきこと】

開発環境とテスト環境では、設定ファイル、環境変数、ミドルウェアの種類やバージョン、ファイルパス、権限、外部システム連携設定などに差分が存在する場合があります。

これらの差分を把握せずに作業を進めると、「開発環境では正常に動作していたのに、テスト環境では動作しない」といった問題が発生する可能性があります。

【対策】

環境差分による不具合を防ぐため、以下のような作業を実施すると良いと思います。

・開発環境とテスト環境の各種設定差分を事前に確認する

・設定変更がある場合は、その内容を整理し共有する

・環境依存となりやすい項目はドキュメント化する

④ 設定変更・手動操作は必ず記録に残す

【注意すべきこと】

設定変更や手動操作の記録を残さなかった場合、後から「誰が・いつ・何をしたのか分からない」状態となり、障害や不具合が発生した際の原因特定が困難になる可能性があります。

特に、Git の履歴では追跡できないような管理画面での設定変更や、SQL の直接実行などは、明確な作業内容が把握しづらいため注意が必要です。

【対策】

トラブル発生時にも迅速に原因を特定できるよう、以下のような作業を実施すると良いと思います。

・設定変更や手動操作の内容・実施者・日時・目的を記録する

・管理画面操作や SQL 直打ちなど、履歴が残らない作業ほど優先的に記録を残す

・作業ログ、共有ドキュメントなど、チームで確認できる場所に格納する

３．本番環境

3-1.本番環境とは

そもそも本番環境とは何なのか...

実際にユーザーや業務担当者が利用する環境です。

この環境では実データが扱われるため、障害やミスが発生すると、業務停止や顧客への影響といった重大な問題につながります。

3-2.注意点・対策

①やること・やらないことを作業前に決める

【注意すべきこと】

本番環境での作業中に、その場の判断で目的外の操作を追加してしまうと、想定外の不具合や復旧不能な障害、原因不明のトラブルにつながる可能性があります。

特に本番環境では影響範囲が大きく、軽微な操作であっても重大な問題に発展するリスクがあります。

【対策】

本番作業を安全に実施するために以下内容を明確にし、手順書や資料として整理しましょう。

・何を修正するのか

・どの範囲（どこ）を触るのか

・どのような操作を行うか

・想定作業時間

・失敗した場合の復旧手順（戻し方）

※上記内容に合わせて、「やらないこと」として、目的外のデータ修正、追加の設定変更、コードの追加修正なども明確に定めておくと良いと思います。

また、作成した手順書や資料については有識者による事前確認と承認を得た上で本番環境での作業を実施しましょう。

② 作業中・作業後の影響を自分の目で確認する

【注意すべきこと】

コマンド操作やバッチ実行などで処理が「成功」と表示されていても、実際にはログにエラーや警告が出力されていたり、想定外の再実行が発生していたりする場合があります。

また、処理時間やレスポンスの悪化、CPU・メモリ・DB負荷の急増など、システム全体に影響が出ている可能性もあるため、結果表示だけで安心しないようにしましょう。

【対策】

本番環境での作業による影響を正しく把握するため、以下のような作業を実施すると良いと思います。

・コマンドの実行結果だけでなく、アプリケーションログやシステムログを確認する

・実際の画面表示や動作を確認し、想定どおりの結果になっているかを確認する

・作業前後で処理時間、レスポンス、リソース使用状況（CPU・メモリ・DB負荷）に異常がないかを確認する

③ 自分の操作は後から説明できる状態にしておく

【注意すべきこと】

本番環境で行った操作内容を説明できない場合、障害が発生した際に「ロールバックすべきか」「再実行すべきか」「他に影響が出ていないか」といった正しい判断ができず、原因特定や復旧対応が遅れてしまう可能性があります。

また、チームや組織からの信頼も失う可能性があるので、自身の評価にも影響します。

【対策】

本番作業を行う際は、以下の内容を意識しておくと良いと思います。

・実施する操作内容や手順、影響範囲を事前に理解した上で作業する

・どの操作を行ったのかを後から説明できるよう、作業内容を整理・記録する

・障害発生時にも状況説明や判断ができるよう、作業の意図と結果を把握しておく

④ 異常を感じたら即作業を止めて報告する

【注意すべきこと】

本番環境で、想定していない ERROR／WARN のログ出力や、想定していた処理件数を大幅に上回る実行結果などの異常を感じた状態で作業を継続すると、ログが大量に出力されて原因特定が困難になったり、データ破壊の影響範囲が拡大したり、ロールバックが不可能になる可能性があります。

最悪の場合、影響範囲がユーザー全体に拡大することもあるかもしれません。

【対策】

異常を検知した場合は、被害拡大を防ぐため以下の内容を意識すると良いと思います。

・確認が取れるまで、次に実行予定だったコマンドや操作を行わない

・自動処理やバッチが動作している場合は、停止可能かを速やかに確認・対応する

・報告時には以下の情報を整理して共有する

　　＞何をしようとしていたのか

　　＞どの時点で異常を感じたのか

　　＞何が想定と異なっていたのか

　　＞現在どの状態で処理が止まっているのか

ーーーーーーーーーーーーーーーーーーーーーーー
株式会社SAKURUGは「寄付月間2025」に参画しています。
12月中のテックブログのpv数に応じて、アフリカの支援団体に寄付をおこないます。
https://giving12.jp/
ーーーーーーーーーーーーーーーーーーーーーーー