LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

来週から業務委託のエンジニアに入ってもらうのに、リポジトリの権限も検証用の環境もまだ決まっていない。初日は環境の準備待ちで終わってしまった——。社外の技術者を開発に迎える現場では、こうした悩みが起こりがちです。業務委託エンジニアの受け入れで用意する開発環境とは、社外から加わる技術者がプログラムを書き、動かし、確かめるために使う場所と道具の一式を指します。

開発環境を本番環境と分けて先に整えておけば、参画した日から作業に入ってもらいやすくなり、本番のシステムやデータを誤って傷つけるおそれも小さくなります。ただし、分けただけで守れるわけではありません。どこまで開くか、どのデータを置くか、どの経路で本番に反映するかを決めておかないと、抜け道が残ります。本記事では、開発の現場を預かるマネージャーに向けて、環境を分ける理由から開く範囲、テスト用データ、本番への反映、初日までの準備、外部に委託するときの確認点までを整理します。

受け入れで用意する開発環境とは

開発の仕事で使う環境は、一般に3つに分けて考えます。プログラムを書いて動かしてみる開発環境、まとめて動作を確かめるテスト環境、利用者が実際に使う本番環境です。テスト環境のうち、本番に近い形で最後の確認をする場所はステージング環境と呼ばれることもあります。

業務委託エンジニアを受け入れるときに用意するものは、環境そのものだけではありません。ソースコードの保管場所（リポジトリ）、課題や仕様を管理するツール、設計書などの文書、開発に使うサーバーや端末、テスト用のデータまで含めた、作業を始めるのに要る一式です。政府機関向けのガイドラインも、開発環境の例として、ドキュメントとソースコードへのアクセス権、開発に使うサーバー装置や端末の設置場所、アクセス制御の方法を挙げています。^*3

手順を決めるときの手がかりは2つあります。1つは経済産業省の「情報セキュリティ管理基準（令和7年改正版）」で、情報セキュリティの国際規格に沿って、組織が選んで使う管理策（情報を守るための対策）を並べた基準です。もう1つは、国の機関向けの「政府機関等のサイバーセキュリティ対策のための統一基準」と、対策の例を示すガイドラインです。民間企業に守る義務はありませんが、システムの構築を外部に頼むときに求める項目が具体的に書かれています。

3つの環境を分ける理由

管理基準は、開発環境、テスト環境及び本番環境を「分離してセキュリティを保つ」ことを管理策に掲げ、その目的を「開発活動及びテスト活動による危険から本番環境及びそのデータを保護するため」としています。^*1 作りかけのプログラムを試したり、設定を変えて動きを見たりする作業は、失敗することを前提にしています。その失敗が、利用者の使うシステムに及ばないようにするのが分ける目的です。

分け方は一律ではなく、本番環境での問題を防ぐために要る分離の水準を決め、それに従って分けるとしています。分けるときに考える事項として、次の7つが挙がっています。

業務委託エンジニアの受け入れに引き寄せると、要は「本番環境に触れずに作業を始められる場所」を先に作っておくことです。社外の人が加わるのを機に、環境の境目を決め直しておくと、その後の参画のたびに同じ準備を繰り返せます。

業務委託エンジニアに開く範囲

環境を分けたら、次はどの環境に、どこまで入ってもらうかを決めます。管理基準は、開発環境とテスト環境を守るために考慮する事項の1つに「環境へのアクセスの制御」を挙げています。^*1 開発環境だから誰でも入れてよい、という扱いにはなっていません。

開く範囲は、任せる作業から逆にたどると決めやすくなります。画面の改修を頼むなら、そのアプリケーションのリポジトリ、開発用のサーバー、テスト環境、関係する課題と設計書までを開き、本番環境と担当外のシステムのリポジトリは開かない、という線の引き方です。

ソースコードの扱いも、受け入れの前に決めておきます。ガイドラインは、システムの構築を業務委託するときに委託先に求める事項として、ソースコードが不正に変更・消去されることを防ぐための管理を挙げ、その中身を「ソースコードの変更管理」「ソースコードの閲覧制限のためのアクセス制御」「ソースコードの滅失、き損等に備えたバックアップの取得」の3つとしています。^*3 業務委託エンジニアが手元にソースコードを複製して作業する場合は、変更をどこに戻すのか、手元の複製をいつ消すのかまで決めておきたいところです。

テスト用データの用意

受け入れの準備で後回しになりやすいのが、テスト用のデータです。本番のデータベースをそのまま複製してテスト環境に入れれば手早く用意できますが、顧客の氏名や連絡先が、社外の人も触れる場所に置かれることになります。

管理基準は、個人を特定できる情報を含む取扱いに慎重を要する情報を、開発環境及びテスト環境へ「複製しない」としています。^*1 ガイドラインも、開発中のソフトウェアの動作を確かめるために、運用中のシステムの要機密情報（秘密にしておく必要がある情報）をテストデータとして使わないようにする必要があるとしています。^*3

それでも本番のデータの複製をテストに使う場合について、管理基準は、テスト環境を社内に置くかクラウドのサービス上に置くかにかかわらず、次の5つを適用するとしています。

業務委託エンジニアを受け入れる前に、架空の顧客や取引を並べたテスト用のデータを用意しておくのが、いちばん扱いやすい方法です。本番に近い件数や偏りがどうしても要る検証では、上の5つを満たせるかを先に確かめ、満たせないならその検証は社員の担当に残す、という分け方もあります。

本番環境へ反映する経路

業務委託エンジニアが書いたプログラムを本番に出すまでの経路も、参画の前に決めておきます。管理基準は「一人の人間が、事前のレビュー及び承認なしに、開発環境及び本番環境の両方に変更を加えることができないようにする」としています。^*1 これはアクセス権の分離や、監視を伴う規則によって達成できるとされています。

形の一例を挙げます。業務委託エンジニアは開発環境で変更を作り、リポジトリに変更の依頼を出します。社内の担当者がその中身を確かめて承認し、テスト環境で動作を確かめてから本番に反映します。本番への反映を社内の担当者だけが行う形にしておけば、本番環境の権限を社外の人に渡す必要もなくなります。

ガイドラインは、構築を業務委託するときの試験について、情報セキュリティの観点から必要な試験があれば項目と方法を定めて実施し、その実施記録を保存するよう委託先に求めるとしています。^*3 実施記録とは、試験の項目、実施結果、見つかった不具合とその修正の記録などを指します。誰が作った変更を、誰が確かめ、どの試験を通して本番に出したのかを残しておけば、後で不具合が見つかったときにたどれます。

開発環境そのものの保守

開発環境は、本番環境ほど目を配られないまま古くなりがちです。管理基準は、開発環境とテスト環境を守るために考慮する事項として、6つを挙げています。開発・統合・テストに使う全てのツールへのパッチの適用と更新、システムとソフトウェアのセキュリティに配慮した構成、環境へのアクセスの制御、環境の変更と保存されているコードの監視、環境の監視、そして環境のバックアップです。^*1

業務委託エンジニアが加わると、開発環境に入る人が増え、人の入れ替わりも多くなります。古いライブラリのまま放置された開発用のサーバーや、誰が作ったか分からない検証用のアカウントが残っていると、そこが入り口になりかねません。受け入れのたびに、使っていない環境やアカウントを片づける機会にすると、手間をまとめられます。

環境を取り違えない工夫も要ります。管理基準は、誤りのリスクを減らすために、メニューに適切な「環境識別ラベル」を表示するとしています。^*1 画面の上部に「テスト環境」と色付きで出しておく、接続先のサーバー名に環境の名前を入れておく、といった工夫は、初めてその環境に触れる業務委託エンジニアにとって特に助けになります。

初日に動かせる状態にする準備

ここまでの決めごとを参画の初日に間に合わせるには、準備の順番を決めておくのが近道です。管理基準や統一基準は初日の段取りまでは示していないため、次の表は本記事としての整理です。

準備のかなめは、手順書どおりに環境が立ち上がるかを、社内の誰かが前もって試しておくことです。開発環境の立ち上げ方が特定の社員の頭の中にしかないと、参画の初日がその人への質問で埋まってしまいます。手順書の通りにやって詰まった箇所は、その場で手順書を直しておくと、次に受け入れる人の分まで準備が進みます。

最初の課題には、小さな修正を1つ選ぶのがおすすめです。変更の依頼から承認、テスト環境への反映までを一通り経験してもらえば、反映の経路の説明も兼ねられます。

外部に委託するときに確認しておきたい点

業務委託エンジニアを受け入れる前に、自社で用意する環境と、委託先の会社や本人に用意してもらう環境の境目を決めておきます。管理基準は、システム開発を外部委託するときにサプライチェーン全体で考慮する事項の1つに「開発環境のセキュリティ要求事項」を挙げています。^*1 統一基準も、政府機関が情報システムの構築を業務委託するときは、契約に基づいて「情報システムの開発環境及び開発工程における情報セキュリティ対策」の実施を委託先に求めるとしています。^*2

委託先の会社が用意した端末や環境で作業してもらう場合は、ここまでの項目を契約や発注の書面でどう扱うかを確かめておきます。どちらが何を用意し、誰が管理するかは契約の内容によって変わるので、迷うときは契約の担当者や専門家に確かめてください。

受け入れのときの手続き全体は業務委託エンジニアの受け入れで決める5つの手続きで扱っています。

アカウントの渡し方と見直しは業務委託エンジニアの受け入れ時の権限管理にまとめました。

3つの環境の役割の違いは開発・ステージング・本番環境の違いで解説しています。

まとめ：開発環境で確かめておきたい3つの点

業務委託エンジニアの受け入れで開発環境を用意するうえで、確かめておきたい点は3つに整理できます。第一に、開発環境とテスト環境を本番環境と分け、開く範囲を任せる作業に要る環境までにとどめること。第二に、テスト用のデータに本番のデータの複製を使わず、使うならアクセス制御・その都度の認可・ログ・マスキング・終了後の削除を満たすこと。第三に、本番への反映を承認を経た経路に限り、手順書どおりに環境が立ち上がるかを初日の前に社内で試しておくことです。この3点を踏まえておけば、「参画の初日が環境の準備待ちで終わった」「本番のデータが検証用のサーバーに残っていた」という事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：経済産業省「情報セキュリティ管理基準（令和7年改正版）」（PDF）（https://www.meti.go.jp/policy/netsecurity/is-kansa/IS_Management_Standard_R7.pdf）。出典：経済産業省「情報セキュリティ管理基準（令和7年改正版）」。8d-8.30.2 j)（外部委託による開発）、8d-8.31（開発環境、テスト環境及び本番環境の分離）の管理策と8d-8.31.1〜8d-8.31.5、8d-8.33（テスト用情報）の8d-8.33.1〜8d-8.33.3を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：サイバーセキュリティ戦略本部「政府機関等のサイバーセキュリティ対策のための統一基準（令和7年度版）」（PDF）（https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf）。出典：令和7年6月27日 サイバーセキュリティ戦略本部決定、令和8年9月14日一部改定。4.1.2「情報システムに関する業務委託」の遵守事項(2)(a)を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン（令和7年度版）」令和8年10月1日一部改定 第3部〜付録（PDF）（https://www.cyber.go.jp/pdf/policy/general/guider8_6_02.pdf）。出典：4.1.2「情報システムに関する業務委託」の遵守事項(2)(a)、基本対策事項4.1.2(2)-1・4.1.2(2)-2と解説を参照（確認日2026年10月2日）（2026年10月確認）

Tweet