純国産の内部不正・情報漏洩防止対策ソフトなら

ケーススタディ②:既存ルールと二重申請にならないための運用例(開発・設計部門)

実際の運用イメージは部門ごとの業務によって大きく変わります。
ここでは開発・設計部門を例に、現実的な使い方を整理します。

設計

開発・設計部門では、設計図面や仕様書、試験データなどを社外の顧客や協力会社とやり取りする機会が多く、日常的にデータの持ち出しが発生します。その一方で、これらのデータは機密性が高いため、社内の承認プロセスを経て外部に提供するのが一般的です。

例えば、次のような流れになります。

  1. 設計データを外部に提供するため、社内ワークフローで上長承認を取得
  2. 承認後、実際にデータをメール添付や外部媒体で送付

ここにコプリガードを導入すると、さらに「コプリガードの持ち出し申請・承認」というプロセスが追加されます。社内ワークフローで承認し、さらにコプリガードでも承認する、という二重申請の状態になってしまい、そのまま運用すれば次のような問題につながります。

  • 同じ内容を2回申請する手間が発生する
  • 現場がどちらを優先すべきか迷う
  • 承認漏れやルール逸脱が起きやすくなる

特に開発・設計部門では、外部とのやり取りが日常的に発生するため、この負荷は無視できません。

現実的な解決策としては、既存ワークフローへの「申請コード・承認コード」の組み込みです。既存ワークフローを「業務上の判断(このデータを出してよいか)」の場とし、コプリガードを「技術的制御(システム的な持ち出し許可)」として役割分担させた上で、両者の手続きを一つに統合します。

この運用の整理により、実際の流れは次のように一本化されます。

  1. 既存ワークフローでの一括申請
    申請者は、既存ワークフローの申請時に、コプリガードから発行される「申請コード」もあわせて連絡し、申請を依頼します。
  2. 承認
    承認者は、既存ワークフロー承認時に、コプリガードから発行される「承認コード」もあわせて連絡します。これにより追加の申請を行うことなく、システム的な持ち出しも一時的に許可できます。
  3. 安全なデータ持ち出し
    コプリガード側で許可されたデータのみが、実際に持ち出し可能となります。

つまり業務上の判断は従来通りでありながら、最終的な持ち出しはシステムで確実に制御する、という構造を「1回の手続き」で実現できます。

ポイント

開発・設計部門のように外部とのデータやり取りが多い業務では、コプリガードの持ち出し申請と既存ワークフローが二重化するように見えるケースがあります。しかし、既存ワークフローを業務判断、コプリガードを技術的制御として役割分担させることで、両者は競合せず補完関係になります。

これにより、現場の運用を大きく変えることなく、持ち出しの統制を強化することが可能になるのです。

一覧へ戻る

To top