本番データに触れる担当と作業範囲を、契約前に決める
「開発会社がどこまで触れるか」が曖昧だと、本番データの誤操作や情報持ち出しのリスクが残ります。システムができてから決めると、手戻りも大きくなります。
外注前に権限と本番アクセスの境界を決めておくと、見積の精度も上がり、導入後の不安も減ります。
曖昧
先に決める
社内の承認と、開発会社の検証・反映作業を分ける
本番権限の最終承認とデータ分類の判断は社内が持ち、開発会社は検証環境での実装と承認後の本番反映に集中する——この分け方が基本です。
担当者を識別できる作業用アカウントを個別発行し、役割に応じた権限と利用期間に限定します。いつ・誰が・何をしたかを追える記録も確認してください。
社内
- 本番権限の承認
- データ分類の最終判断
- 運用責任
開発会社
- 検証環境での実装
- 承認後の本番反映
- 作業ログの提出
環境・権限・操作履歴の条件を、見積時に共有する
次の項目を社内で埋めてから見積を取ると、開発会社との会話がスムーズになります。環境分離、権限、ログ、アクセス範囲です。
より詳しいチェックリストは関連コラムにまとめています。RAG導入予定がある場合は、資料の境界も先に決めてください。
- 01
チェック項目を埋める
権限・本番・ログを整理
- 02
見積で共有
開発会社と同じ前提で話す
- 03
仕様に落とす
設計段階で権限を固める
業務の課題整理から、設計・開発・導入まで
外注先のアクセス範囲を、
SHINJIDAIにご相談ください。
- 開発会社に本番情報をどこまで見せるか迷う
- 作業者・権限・期間が明確になっていない
- 検証環境と本番反映の手順を分けたい
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
ID・パスワードや顧客データは、フォームに記載しないでください。
開発の進め方・役割分担を見るよくある質問
開発会社に本番へのアクセスは必要ですか?
原則は検証環境で作業し、本番反映は承認付きにするのが安全です。本番への直接ログインが必要な場合も、作業用アカウントとログのルールを先に決めてください。
最低限、何を決めておけばよいですか?
環境の分離(本番・検証・開発)、役割ごとの権限、開発会社のアクセス範囲と作業ログ、の3点が出発点です。
詳しいチェックリストはありますか?
発注前のセキュリティ全般については、関連コラムでより詳しいチェックリストを公開しています。あわせてご覧ください。