複数の協力会社と同時並行でプロジェクトを動かしているとき、「どこまでの情報を外部に見せてよいか」という判断を毎回個別に行っている組織は少なくありません。メール添付や個人判断のクラウド共有が混在した状態では、プロジェクトが終わった後も元の担当者がファイルにアクセスできる状態が残り、情報管理上のリスクにつながることがあります。
本記事では、協力会社の種別と情報の機密度に応じたワークスペース設計の考え方から、プロジェクト終了後の権限失効まで、PMが情報システム部門や法務・情報セキュリティ担当と連携しながら設計・説明できる、実務レベルの運用フローを解説します。
Contents
なぜ「協力会社との情報共有」は野良運用になりやすいのか
協力会社との情報共有が組織的に整備されにくい背景を理解することが、設計を始める前の第一歩です。
社内チーム向けの共有フォルダやドキュメント管理ルールは、IT部門や情報システム部門が主導して整備することが多いです。一方、外部の協力会社との情報共有は「現場のPMが都度判断する」という暗黙のルールで動きがちです。プロジェクトの立ち上げ時間が限られているため、とりあえずメールで送る、馴染みのあるクラウドストレージを個人判断で使い始める、という対処が積み重なります。
問題が表面化するのは大抵、協力会社の担当者が退職・交代したタイミングや、プロジェクトが終了した後です。「前の担当者のアカウントがまだ生きているかもしれない」という不安は、管理ルールが整備されていないことの裏返しです。さらに、万一情報漏洩が起きた場合、「誰がどのルールで共有を許可したのか」を説明できず、現場のPMや関係部門が対応に追われることになります。この問題を解決するためには、ITセキュリティの知識ではなく、権限設計と運用フローを誰がどう決めるかという意思決定の仕組みが必要です。
外部共有ワークスペースとは何か―社内共有との本質的な違い
外部共有ワークスペースの概念と、社内共有との違いを理解することで、設計すべき要件が明確になります。社内向けの共有フォルダは、同一企業内の就業規則や情報セキュリティ規程に従うメンバーが使うことを前提としています。 アクセス権の粒度が粗くても、トラブルが起きたときの責任の所在は比較的明確です。
外部共有ワークスペースは、この前提が根本的に異なります。協力会社のメンバーは自社の就業規則の直接の対象ではないため、情報取扱いのルールはNDA、業務委託契約、基本契約、個別契約、情報セキュリティ条項などで定めた範囲に依存します。 つまり、契約の範囲とアクセス権の範囲を一致させる設計が、外部共有において本質的に重要な要件です。
メールで送ったファイルは受信者側の端末に残り続けます。一方、ワークスペース型の共有では、ファイル本体を一元管理し、権限を失効させることで以後のアクセスを遮断しやすくなります。
ただし、すでにダウンロードされたファイルや、受信者側で複製されたファイルまで回収できるわけではありません。そのため、ダウンロード制限、閲覧のみの権限、共有期限、操作ログと組み合わせて運用することが重要です。
協力会社の種別分類と情報区分の考え方
権限設計に入る前に、自社が関わる協力会社の種別と、共有する情報の機密レベルを整理します。
協力会社の種別を3つに分類する
設計をシンプルにするために、協力会社を次の3種別で捉えます。
① 常駐型パートナー
プロジェクト期間を通じて継続的に関与する会社・個人です。設計会社、開発会社のコアメンバー、長期の業務委託先などが該当します。 情報共有の頻度が高く、プロジェクトの全体像に触れることが多いため、適切な権限付与とNDAの締結状況の確認が不可欠です。
② 単発委託型パートナー
特定フェーズや単一業務のみ関与する会社・個人です。印刷会社、翻訳会社、短期の作業委託先などが該当します。 必要な成果物と仕様書のみにアクセスを限定し、期間終了とともに権限を失効させる設計が基本です。
③ 閲覧専用の関係者
進捗報告や納品確認のために一部資料を共有する必要がある外部関係者（エンドクライアントや監査関係者等）です。書き込み・ダウンロード権限を原則付与しない運用を前提とします。
共有情報を3段階に分ける
協力会社の種別と組み合わせるために、共有する情報も機密度で分類します。
- Aランク（高機密）：顧客情報、未公開の設計仕様、原価情報、未公開の見積もり情報など。原則として社内限定とし、外部共有が必要な場合は、共有目的・対象者・期間を明確にしたうえで、個別承認を経て付与します。
- Bランク（中機密）：仕様書、議事録、作業指示書など、プロジェクト遂行に必要な業務資料。常駐型パートナーには必要に応じて閲覧・編集を許可し、単発委託型には原則として閲覧のみを基本とします。
- Cランク（低機密）：公開済みの仕様、スケジュール表、提出用テンプレートなど。3種別すべてに共有しやすい情報ですが、プロジェクト外への転送や再配布を認めるかどうかは、契約条件や社内ルールに沿って整理します。
ワークスペース設計マトリクス――誰に何を見せるかを一覧化する
協力会社の種別と情報の機密度を組み合わせることで、権限設計の指針が得られます。
| 協力会社の種別 | Aランク（高機密） | Bランク（中機密） | Cランク（低機密） |
| 常駐型パートナー | 個別承認のうえ閲覧のみ | 必要に応じて閲覧・編集可 | 閲覧・編集可 |
| 単発委託型パートナー | 原則非公開 | 閲覧のみ（必要に応じてダウンロード制限） | 閲覧のみ |
| 閲覧専用の関係者 | 非公開 | 閲覧のみ（ダウンロード制限） | 閲覧のみ（必要に応じてダウンロード制限） |
このマトリクスは、あくまで設計の起点です。自社のプロジェクト特性や契約形態に応じて調整してください。重要なのは、「なんとなく全部見せている」状態から脱し、見せる根拠を言語化することです。
ワークスペースの構成としては、「プロジェクト共通フォルダ（全協力会社が参照できるCランク資料）」「社名・役割別の個別フォルダ（Bランク以上の資料をパートナーごとに分離）」「社内限定フォルダ（Aランク資料）」という3層構造にすると整理しやすくなります。
ただし、Aランク資料は原則として社内限定とし、外部共有が必要な場合は個別承認を前提に、共有先・期間・操作権限を限定します。
プロジェクトライフサイクル別の運用フロー
権限の付与から失効まで、プロジェクトの段階ごとに誰が何をするかを明確にします。
フェーズ①：プロジェクト開始時
最初に行うのは、契約上の共有範囲とアクセス権の紐付け確認です。 NDAや業務委託契約などで情報取扱いの範囲が確認できていない会社・個人には、Bランク以上の情報へのアクセスを付与しない、というルールを開始時に明確にしておきます。これにより、後から個別判断が発生するケースを減らせます。
次に、各協力会社のワークスペースへの招待は「プロジェクトオーナー（PM）の申請→情報システム担当またはファイル管理者の承認」という2段階で行います。PMが単独で招待を完結できる運用にする場合でも、承認履歴や招待理由、権限レベルが記録される仕組みを必ず用意します。特にBランク以上の情報を共有する場合は、「PMの申請→情報システム担当またはファイル管理者の承認」という2段階にしておくと安全です。
招待時に確認する項目として、招待時には、①招待するメールアドレスが企業ドメインのものか、②会社名・所属・担当業務が確認できるか、③設定する権限レベルがマトリクスと一致しているか、④招待の有効期限または見直し日を設定したか、の4点を確認します。フリーメールを利用する場合は、理由と承認者を記録しておきます。
フェーズ②：プロジェクト進行中
進行中の管理で特に重要なのは、メンバー変更時の即時対応です。協力会社の担当者が交代した場合、旧担当者のアクセス権を失効させないまま新担当者を追加すると、不要なアクセス権が残り、情報管理上のリスクが高まります。 交代が発生したら「旧担当の権限失効→新担当の招待」をセットで行うルールを徹底します。
また、案件の重要度や機密性に応じて、月次・フェーズ終了時・納品前などのタイミングでアクセス権の棚卸しを行い、 現在のアクセス権保有者一覧と実際の関与メンバーを照合します。「誰も使っていないアカウントが残っている」という状態は、棚卸しの習慣がないことで発生します。
フェーズ③：プロジェクト終了時
終了時の処理は、開始時と同じかそれ以上に重要です。プロジェクト完了の確認後、外部協力会社のアクセス権をすべて失効させるクロージングチェックリストを使って確認します。クロージングで確認すべき項目は次のとおりです。
- 全外部招待者のアクセス権が失効しているか
- 共有リンクが発行されている場合、リンクを無効化したか
- 納品物・完成資料のアーカイブフォルダへの移動が完了しているか
- クライアントや協力会社への最終提供物の受け渡し記録が残っているか
- 契約書、NDA、成果物、議事録などの保存期間と照らし合わせて、アーカイブ期限や保管場所を設定したか
これらのチェックを実施した記録を残しておくことで、万一確認が必要になった際に、共有範囲や権限失効の対応状況を説明しやすくなります。
運用ルールの社内整備と情報セキュリティ担当への連携
設計したフローは、社内で共有・承認されて初めて機能します。
PMが自分の判断でワークスペース設計を進めても、情報システム部門や法務・情報セキュリティ担当が把握していない状態では、組織全体のガバナンスにつながりません。設計をまとめた後に連携すべき内容は次の3点です。
- NDAと共有範囲の紐付けを契約管理台帳に反映する：どの協力会社が、どのプロジェクトで、どのランクの情報にアクセスできるかを、契約管理台帳やプロジェクト管理台帳などで追跡できるようにします。 法務担当に「このような対応表を作りたい」と相談し、契約書の保管体制と整合させます。
- アクセス権棚卸しのタイミングを情報セキュリティポリシーに明記する：情報セキュリティポリシーを整備している企業では外部アクセスの管理規定が含まれていることがありますが、協力会社向けの棚卸し頻度が未定義のケースがあります。「月次」「フェーズ終了時」「案件終了時」など、自社のプロジェクト特性に合った棚卸しタイミングを明文化するよう情報セキュリティ担当に提案します。
- 承認フローの権限者を明確にする：外部招待の承認を誰が行うかが曖昧だと、結局PMが一人で完結する運用に戻ります。「PM申請→情報システム担当承認」という役割と代替者を文書に残します。
失敗しがちなパターン3選
実際の運用でよく発生するつまずきを把握しておくことで、設計段階での予防が可能です。
パターン①：「とりあえず招待して、終わったら削除する」で運用を始める
計画を立てずにアカウントを発行し、削除を後回しにするパターンです。プロジェクトが終わっても削除タスクが誰のToDoにも入っておらず、数ヶ月後に棚卸しをしたら、すでにプロジェクトを離れた外部担当者のアカウントや共有リンクが残っていた、という事態が起こり得ます。 終了後の処理を「誰の責任でいつ行うか」を開始時に決めておくことが防止策です。
パターン②：全員に同じ権限を付与してフォルダで分ける
権限設定が面倒なため、全員に編集権限を与えてフォルダ名で「この会社は見ないこと」と書くケースがあります。フォルダ名の注記は強制力を持ちません。権限はシステム側で制御してこそ機能します。「見ないこと」という注意書きだけに依存する運用では、アクセス制御として不十分です。
パターン③：ワークスペース外での情報共有を禁止しない
ワークスペースを整備しても、「急ぐから」とメール添付やチャットツールへの直接添付でファイルを送り始めると、ワークスペースの外に管理できないコピーが発生し続けます。SlackやTeamsなどのビジネスチャットは連絡手段として便利ですが、そこにファイル本体を直接送る運用にすると、誰がどのファイルを受け取り、どこに保存されたのかを後から追跡しにくくなります。
ワークスペースを導入する際は、「このプロジェクトのファイル共有はワークスペース内のみ」「メールやチャットにはファイル本体を添付しない」というルールを協力会社にも明示することが必要です。チャットでやり取りする場合も、ファイル本体ではなく、クラウドストレージ上の共有リンクを貼る運用に統一します。
あわせて、共有リンクにはアクセス権限、公開期間、ダウンロード可否を設定し、プロジェクト終了時にはリンクを無効化できる状態にしておきます。キックオフ時の説明事項として、「ファイル本体は送らず、必ず指定のワークスペースまたは共有リンクでやり取りする」と文書化しておくことが重要です。
Fleekdriveを使った外部共有ワークスペースの実装ポイント
法人向けクラウドストレージ「Fleekdrive」では、ユーザ別・フォルダ別のアクセス権限設定や、アカウントを持たない外部ユーザーとのファイル共有に利用できるファイル配信・公開スペース・共有リンクなどの機能が用意されています。外部の協力会社とファイルをやり取りする際にも、共有範囲や公開期間を設定しながら運用しやすい仕組みです。
特に本記事の設計で重要になるのは、ユーザー別・フォルダ別のアクセス権限設定、公開期間やパスワードなどを設定した外部共有、ダウンロード可否や操作履歴の確認です。協力会社の種別ごとにアクセス範囲を分ける場合は、これらの機能を組み合わせて、自社のマトリクスに合う権限設計を行います。
現在、メール添付や個人判断のクラウド共有が混在している場合は、まず本記事のマトリクスを使って協力会社を分類し、共有する情報ランク、フォルダ構成、権限レベル、有効期限を整理してみてください。そのうえで、Fleekdriveのような法人向けクラウドストレージ上で、設計したルールを実装できるか確認するとよいでしょう。
まとめ：PMが今すぐ着手できる3ステップ
本記事の内容を、読んだその日から動き出せる手順に整理します。
ステップ1：自社の協力会社を3種別に分類する
現在関与しているすべての協力会社を「常駐型・単発委託型・閲覧専用」に仕分けし、それぞれのNDA締結状況と現在のアクセス権を書き出します。この棚卸しだけで、権限が過剰に付与されている状態が可視化されます。
ステップ2：情報を3ランクに分類してマトリクスを埋める
自社のプロジェクトで扱うファイル・フォルダをA〜Cランクに分類し、前述のマトリクスに当てはめます。「この協力会社にはこのフォルダを見せる根拠がある」と言えるかどうかが判断基準です。
ステップ3：クロージングチェックリストを作成して次のプロジェクトから使う
既存プロジェクトの整理と並行して、次の新規プロジェクトからはクロージングチェックリストをキックオフ時に合わせて作成します。「終わったら誰が権限を失効させるか」を最初から決めておく習慣が、ガバナンスの基礎を作ります。
外部共有ワークスペースの設計は、技術設定だけの問題ではありません。 「誰に何を見せるか」「いつ権限を失効させるか」「誰が承認したか」を事前に決めて記録することが、外部共有における情報漏洩リスクを下げる基本です。
そのためには、メール添付だけでなく、SlackやTeamsなどのチャットツールへのファイル直接添付も含めて、ワークスペース外でファイル本体を共有しないルールを徹底する必要があります。共有が必要な場合は、クラウドストレージ上の共有リンクを使い、権限・期限・ログを管理できる状態にしておくことが重要です。
