フリーランスなど外部のパートナー人材と協働する場面が増えています。その一方で、情報システム部門にはリスク管理や運用体制の強化が求められています。
「IT百物語蒐集家」としてITかいわいについてnoteを更新する久松氏が、情シス部長を2社で担当した経験を基に、情シスに関する由無し事を言語化します。
DXの推進や開発体制の柔軟化に伴い、フリーランスなどの外部パートナーと協働する機会が増えています。必要に応じて専門スキルを持つ人材をスポットで登用できるメリットがある一方で、情報システム部門にはより広い対応力とリスクマネジメントの強化が求められます。
本稿では、実際のトラブル事例やSaaSの利用規約に触れながら、情シスが押さえておくべきポイントを整理します。
私自身、過去にフリーランスの方が顧客から厳しい指摘を受けた翌日から突然連絡が取れなくなり、顧客貸与のPCを持ったまま音信不通になるというトラブルに遭ったことがあります。最終的には弁護士の関与を示すことでようやく連絡が取れましたが、対応には多くの時間と労力を要しました。
外部パートナー人材との協働が進む一方で、最初から途中で離脱することを見越して案件に応募するような悪質なケースも報告されており、トラブルを見据えたリスク管理がより重要になっています。
事前のスクリーニングや契約条件の明確化も重要ですが、それ以上に、現場と情報システム部門の間で実際に機能する運用体制を整備することが不可欠です。
パートナー人材がどの勤務形態(出社、フルリモート、ハイブリッド)を取るかによって、情報システム部門の対応方針や求められる対策は異なります。
出社型の場合には、入館管理や座席・有線LANの手配、USBポートの制御など、物理的かつ技術的なセキュリティ対策が求められます。一方で、フルリモート勤務では、VPN環境の整備やファイルアクセス権限の管理、業務ログの取得といったリモート前提の運用体制が必要となります。ハイブリッド勤務はその両方の課題を内包しており、最も管理が複雑かつリスクの高い勤務形態と言えるでしょう。
勤務形態ごとのルールと、その徹底が必要です。
業務委託のパートナー人材にどのような端末とアカウントを用意するかも重要です。
PC端末の扱い
個人情報や機密データを取り扱う業務においては、企業から業務用PCを貸与するのが一般的です。一方、PCの貸与が難しいケースでは、MDM(モバイルデバイス管理)や仮想デスクトップ、シンクライアント環境の導入など、代替手段の検討が必要となります。PC貸与の有無によってリスクや必要な対策は異なります。
アカウント払い出しの是非
「Microsoft 365」や「Google Workspace」などのクラウドサービスを利用している場合には、業務委託者向けに専用アカウントを発行することが推奨されます。
アカウントを発行しない場合は、契約書においてログイン条件や情報の帰属範囲を明確かつ厳密に定義する必要があります。
パートナー人材がこれまでにどのような情報セキュリティ教育を受けてきたのか、またどの程度のITリテラシーがあるのかは分かりません。そのため、入場時に正社員と同等の情報セキュリティ研修を実施し、理解度確認テストを実施している企業もあります。自社にとって重要なセキュリティ要件について「知らなかった」と言われないよう、明文化された教育や確認プロセスをあらかじめ設計・導入しておくことが重要です。
パートナー人材とのコミュニケーションにおいて、「Slack」や「Microsoft Teams」(以下、Teams)などのチャットツールが最大のセキュリティリスクとなるケースも珍しくありません。
チャンネルの命名ルール
パートナー人材が含まれるチャンネルは、名称に「-ext」や「-vendor」などを付けて明示します。以下がその例です。
#project-alpha-ext
#dev-vendor
Slackの「Enterprise Grid」プランなどで「外部共有あり」のアイコンが表示される場合でも、チャンネル名に外部共有であることを明示しておくことで誤送信や社内情報の漏えいリスクを低減できます。
ゲストアカウントと棚卸し
Slackではシングルチャンネルゲスト、Teamsでは「Microsoft Azure AD」のゲスト管理機能を利用することが効果的です。いずれの場合も、定期的なアカウント棚卸しと自動期限設定による無効化ルールの運用が、セキュリティ維持に有効です。
投稿内容と運用ルール
パートナー人材が参加するチャンネルでは、トピックやピン留めメッセージで以下のような注意喚起を表示しておくと効果的です。
また、Slackの表示名を「氏名 [EXT]」のように統一することで、パートナー人材の識別性を高め、匿名性に起因するリスクを低減できます。
パートナー人材と「GitHub」や「GitLab」を共有する際には、幾つかの基本原則を順守する必要があります。
アカウントは個別に招待
GitHubなどのサービスでは、利用規約により共用アカウントの使用が禁止されています。また、無料プランにおいては1人が複数のアカウントを所有すること自体が禁止されているため、以下のような対応が求められます。
成果物の帰属を明文化
契約書には、GitHubで作成されたコードやIssue、コメント、Wikiを含む全ての成果物はクライアント企業に帰属することを明確に定めておくことが重要です。Forkやローカル保存の防止は困難なため、成果物の監査やPush履歴の管理によって対応する必要があります。
ログと識別性の確保
アカウント削除後もGitHubにはコミット履歴が残るため、個人を特定できる表示名の運用や、内部管理番号と突合できる仕組みの導入が有効です。
Google Colabは個人アカウントにひも付いているため、業務成果の帰属やセキュリティ管理が曖昧(あいまい)になりやすい点に注意が必要です。同様に、「Notion」や「Miro」といったナレッジ管理ツールやホワイトボードツールについても、Enterprise管理下での運用を検討することが望まれます。
セキュリティ事故は、悪意によるものよりも、「ささいな気の緩み」や「設計上の見落とし」から発生することが多いものです。例えば、期限切れのゲストアカウントが放置されていたり、パートナー人材が社内用「Google ドライブ」にフルアクセスできていたり、削除済みのSlackチャンネルでファイル共有が続いていたりといった小さなミスが、重大なインシデントに発展する可能性があります。
パートナー人材の活用が一般化するにつれ、情報統制の網目はより細かく、かつ広範囲になります。技術的な対策に加え、日々の運用プロセス自体を見直し、「属人化しない仕組み」を構築することが情報システム部門に求められています。ツールの設定や契約設計、教育、退職・退出処理までの一連の流れを「パートナー人材向けの受け入れ導線」として明文化することで、再現性のある安全な運用体制が実現できます。
パートナー人材の活用はただ人材を確保するだけでなく、情報システム部門や管理部門に新たな統制課題をもたらします。セキュリティや情報資産管理、ガバナンスの観点を踏まえて、現場で円滑に運用できるルールの設計が重要です。
エンジニアリングマネージメントの社長兼「流しのEM」。博士(政策・メディア)。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。
2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。
Twitter : @makaibito
Copyright © ITmedia, Inc. All Rights Reserved.
製品カタログや技術資料、導入事例など、IT導入の課題解決に役立つ資料を簡単に入手できます。