発注が止まるのは、「何を預けるか」が決まっていないから
営業所ごとのExcelを受発注システムへまとめたい。現場は二重入力を減らしたい一方、情報システム部門から「開発会社は顧客情報をどこまで見られるのか」と聞かれ、話が進まない。複数部署が関わる開発では、業務の改善案と情報の扱いを同じ場で整理する必要があります。
以下は、営業・出荷・経理が顧客情報と受注情報を使う会社の架空例です。開発会社の管理体制を調べることと、作るシステムの安全性を設計することを分けて考えます。確認結果を仕様とテストに結びつけるところまでが、発注の判断材料です。
開発を任せる会社
- 誰が情報を扱うか
- どこに保管・再委託するか
- 問題発生時に誰へ連絡するか
これから作るシステム
- 部署ごとに何を見せるか
- 変更・出力の記録をどう残すか
- 止まった業務をどう戻すか
顧客情報の流れを、部署と開発環境に分けて描く
この例では、営業は担当顧客の受注を登録し、出荷担当は配送先と出荷内容を確認し、経理は請求条件を管理します。同じ顧客の情報でも、必要な項目と変更できる範囲は異なります。
開発会社が検証する環境には、まず架空データを用意します。本番でしか起きない不具合を調べる場合は、必要な記録だけで再現できないか検討します。名前を伏せても、住所や取引内容の組み合わせから特定できる場合があるため、伏せ字にしただけで安全と扱いません。
開発・検証環境は別に設ける。本番の顧客情報を、そのまま複製する前提にしない。
- 資料：顧客情報・受注・請求が、どのシステムを通るかを示した構成図
- 確認：外部サービスや再委託先にもデータが渡るか。保存場所・閲覧者・削除の扱いは説明できるか
- 判断：説明が不足する受け渡しは保留し、必要な調査・代替方法を決める
「対応済み」の回答を、資料と今回の対象範囲で確かめる
チェックシートの「はい」だけでは、どの環境に、いつから適用されているか分かりません。自社の確認票に、対象範囲・確認資料・未確認事項・回答担当をひも付けます。
IPAの委託先確認の実践例では、体制や再委託、対応・復旧手順を質問し、必要に応じて裏付け資料を求めています。以下は、その考え方を受発注システムの発注場面へ具体化した確認例です。
- 01
対象を聞く
どの業務・環境に適用するか
- 02
資料で確かめる
更新日・確認範囲も見る
- 03
残る課題を決める
担当・期限・次の判断を残す
- 体制・再委託：責任者と再委託先の管理方法を確認する。体制図や委託範囲の説明から、誰が顧客情報を扱うかを追えるか。
- 権限・環境：権限一覧と構成図を確認する。開発・検証・本番で、接続先と扱う情報が分かれているか。
- 変更・出力の履歴：記録項目の見本と確認手順を見る。誰が請求条件を変え、誰が顧客一覧を出力したか調べられるか。
- バックアップ・復旧：保存設定だけでなく、復旧手順と試験記録を確認する。対象データと実施日、戻せなかった項目が分かるか。
- 事故・契約終了：連絡窓口、連絡する条件、アクセス停止、情報の返却・削除を確認する。受付時間や追加対応の範囲が契約と一致しているか。
「役割ごとの権限」と「担当者ごとのID」を分ける
営業・出荷・経理という役割には、必要な閲覧・変更権限を割り当てます。ログインするIDは担当者ごとに分け、誰の操作かを記録できるようにします。「営業用」という共有IDを全員で使う意味ではありません。
開発会社にも担当者を識別できる作業用アカウントを発行し、必要な権限と期間に限定する方法を優先します。個人の私用サービスアカウントを業務へ流用しないことと、個人を識別する業務IDを使うことは、別の話です。
共有IDだけで管理
担当者ID＋役割の権限
- 本番作業は、目的・作業者・対象・期限・承認者を決める。多要素認証など必要な認証方法も要件にする。
- 作業後は結果と記録を確認し、不要になった権限を停止する。退職・異動・契約終了も停止のきっかけに含める。
- 古い製品で個別発行できない場合は制約を隠さず、接続承認・操作記録・作業後の認証情報更新などの代替策と残るリスクを確認する。
受注が登録できるだけでなく、「見せない・戻せる」も試す
この受発注の例では、正常に登録できることに加え、他部署の情報を見せないこと、担当変更を反映できること、障害後に仕事を再開できることを完成条件へ含めます。以下は試験項目の例で、網羅的な診断や安全性の保証ではありません。
現場で使えるか
- 担当顧客の受注を登録できる
- 訂正が出荷・請求へ反映される
- 障害時の代替手順で対応できる
権限と復旧を確認できるか
- 出荷担当が不要な単価を見られない
- 停止したIDで再接続できない
- 復旧後の受注・請求を照合できる
- 画面表示だけでなく、CSV出力やシステム間の受け渡しにも権限制限が適用されるか
- 異動・担当交代・外部担当の離任後に、以前の権限が残っていないか
- バックアップから戻した記録と、その間に処理した受注を照合し、二重出荷・二重請求を防げるか
未確認が残ったら、担当・期限・進めてよい範囲を決める
例えば、復旧手順はあるが対象システムの復旧試験が未実施なら、「対応済み」にまとめず、未確認として残します。試験の範囲・費用・実施担当を決め、その結果で本番移行を判断します。
顧客情報の保存場所や閲覧者が分からない段階では、実データの提供を保留します。架空データによる業務確認や構成調査を先に進められるかを検討します。調査を始められることと、本番運用へ進められることは区別します。
条件を満たす
確認資料・対象・日付を記録する
追加確認が必要
担当と期限、止める工程を決める
必須条件に合わない
代替策・対象範囲・発注先を再検討する
SHINJIDAIに相談するときは、業務と発注条件を一緒に整理する
SHINJIDAIは、業務の課題を伺い、解決策の提案から設計・実装まで支援します。この受発注の例なら、転記が生じる工程と既存ソフトを確認し、データを渡す必要がある範囲、部署ごとの権限、訂正・復旧の確認方法を整理します。
既存ソフトの設定や連携で対応できるか、追加開発が必要かを比べ、最初に変える範囲を提案します。合意した仕様を実装し、現場の担当者と情報の見え方や例外時の動きを確認する進め方です。以下は本例での進め方の提案で、個別案件の実績を示すものではありません。
- 01
現状を調べる
転記・既存ソフト・情報の流れ
- 02
範囲を提案する
残す機能・権限・確認条件
- 03
実装して確かめる
通常業務と訂正・権限・復旧
- お客様：調達条件、業務ルール、許容できる停止時間を確認し、権限の承認・受入確認を担う。
- SHINJIDAI：合意した調査・設計・実装・検証を担い、不明点や対応範囲を整理する。
- 共同：構成図、権限一覧、確認課題、試験条件など、必要な成果物と完成の判断方法を合意する。
業務の課題整理から、設計・開発・導入まで
開発の進め方から、
SHINJIDAIにご相談ください。
- 顧客情報を扱うため、権限や情報管理をどう決めるか不安
- 今のシステムを活かしながら、転記や確認作業を減らしたい
- 社内説明から開発まで、担当者だけでは手が回らない
課題の整理から伴走現場の業務と既存システム、情報管理の条件を一緒に整理します。残す仕組みと変える範囲を提案し、合意した設計・実装から、権限や現場で使えるかの確認まで支援します。
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
ID・パスワードや顧客データは、フォームに記載しないでください。
開発の進め方・役割分担を見る出典
資料確認日：2026年9月19日。業務例・図・試験項目は説明用の設計提案です。個別の顧客事例や認証取得、安全性・改善効果の保証を示すものではありません。
よくある質問
セキュリティの要件が決まっていなくても相談できますか？
相談できます。改善したい業務、扱う情報の種類、利用部署、既存システム、自社の調達条件を共有してください。SHINJIDAIでは必要な調査と役割分担を整理し、工程ごとの対応範囲・費用を合意して進めます。初回の問い合わせに本番データや認証情報を添付する必要はありません。
認証を取得している開発会社なら、確認を省略できますか？
まず自社の調達条件として必要な認証と対象範囲を確認します。そのうえで、今回の委託業務・拠点・再委託先が対象に含まれるか、権限や復旧などの運用が案件の条件を満たすかを確認します。認証の有無だけで個別システムの安全性を判断しません。
開発会社には、共有の管理者アカウントを渡せばよいですか？
担当者を識別できる作業用アカウントを個別に発行し、必要な権限と期間に限定する方法を優先します。古い製品などで個別発行できない場合は、その制約を明示し、接続承認・操作記録・作業後の認証情報更新などの代替策を合意します。残るリスクも社内の責任者が確認します。
秘密保持契約を結べば、本番データを渡してよいですか？
秘密保持契約だけで渡す範囲は決まりません。利用目的、必要な項目、保存先、閲覧者、再委託、保管期間、終了後の削除を確認します。まず架空データで検証できるかを検討し、実データが必要な場合も対象を絞って受け渡し方法を合意します。
社内AIやRAGの開発でも同じ確認が必要ですか？
委託先と開発環境の確認に加え、投入する資料、利用者ごとの閲覧範囲、外部サービスへ送る情報、保存・学習利用の条件を確認します。RAGは社内資料を検索して回答に使う仕組みです。資料が検索できることだけで、機密情報の取り扱いが適切とは判断できません。