企業間のファイル共有

　ファイル共有のポリシーは、最も企業によって対応が分かれるポイントです。

　リンク先を知っている全員とフォルダを共有するという、緩い共有設定で社外とやりとりをしている企業はいまだに存在しています。一方、NDA（秘密保持契約）を結んだ上でも一切ファイル共有を禁止している企業もあります。

　厳しすぎると抜け道を探して対応してしまう人がいることに注意が必要です。ファイル共有の際に情シスに申請しなければならないような場合も、その申請を渋って抜け道を探す人を見かけします。例えば「Google スライド」や「Google スプレッドシート」のデータを「Microsoft PowerPoint」や「Microsoft Excel」の形式に変換し、ダウンロードして電子メールで送付するといったケースです。

　送られてきた添付ファイル付き電子メールが各社のセキュリティポリシーにのっとって「HENNGE Secure Download」のような有料のファイル共有サービスで送られてくれば、ポリシーの範囲内かと思います。しかし、厳しすぎる運用を強いることで無料のファイル共有サービスを経由して送られたり、プライベートアカウントで送られたりすると、予期せぬ穴を産むでしょう。それらを黙認している情シスもいるため落とし所の難しさを感じます。

　私は、機微な情報を多く扱うのであれば、自社のアカウントを払い出した上でフォルダ単位で管理するといった方法が落とし所なのかと考えています。ある程度を従業員の裁量に任せ、定期的に権限をチェックするといった監査をすることも有効でしょう。

企業間のチャット

　チャットツールを使用した企業間のやりとりは一般的になってきました。代表的なものは「Microsoft Teams」（以下、Teams）と「Slack」でしょう。

　Teamsはエンタープライズを中心に利用されている他、「Microsoft 365」を契約している企業にも利用されています。社外と連携する際はゲストアカウントを発行するのが一般的です。

　アカウント発行企業は特に問題はありませんが、ゲストアカウントを受ける側は注意が必要です。単一のアカウントを扱っている分には問題ないのですが、Teamsで複数のアカウントを利用すると認証エラーが起きる場合があります。2023年にアプリがリニューアルされて解決されたという意見もあるのですが、「Active Directory」による連携やセキュリティ設定などに引きずられて利用そのものを断念するケースもあります。

　スマホアプリのTeamsであれば切り替えができるため（時折アプリを立ち上げ直さないとエラーになる）、私はメインでのやりとりはスマホで実施し、しっかりとやりとりが必要な場合は「Google Chrome」のゲストアカウントでログインしています。シークレットウィンドウではメインウィンドウの認証状況が引き継がれるようでエラーになります。実に企業間コラボレーションのコストが高いチャットツールです。

　Slackは「Slackコネクト」などで連携するのが一般的です。しかし自社のポリシーでSlackの利用が規制される場合があります。Teamsに応じてくれる取引先であれば問題ないのですが、そうでない場合は無料のSlackアカウントを“野良”で作成し、企業間のやりとりをしている組織を散見します。

　ある企業は自社サービスに関するユーザーコミュニティーを無料Slackで運用しています。現状のSlack無料アカウントでは、投稿が90日間で非表示になります。コミュニティーからの重要なお知らせが非表示になっていたり、埋もれないように定期的に重要なメッセージを手作業で再投稿したりしている様子を見ると、DXとは何だろうか、セキュリティとは何だろうかと思わされます。

業務委託との権限

　SESやフリーランスの場合、情報統制の観点からアクセスできるチャンネルを制限するのが一般的です。

　私も業務委託として複数の企業で働いていますが、アクセスできるチャンネルが少なすぎるために「降ってくるタスク以外は何も分からない」という状況です。正社員になる可能性が高い業務委託人材や副業人材については例外的に、社内の雰囲気が伝わり、かつ経営上問題ないレベルの情報を扱うチャンネルなどの許可をすることについて、人事や法務を交えてディスカッションしてもよいでしょう。

例外対応が必要な退職者のアクセス権限

　権限を付与する場合もあれば、退職や退場により削除する場合もあります。BYOD（Bring Your Own Device）を許可しているような場合、退職者アカウントに速やかに対処しなければなりません。しかし、何事にも例外はつきものです。よくあるトラブルについて紹介していきます。

いつまでアカウントを残すか

　退職日翌日に各種アカウントを削除するのが一般的ですが、削除するとややこしい場合があります。

　オンラインストレージやクラウド型メールサービスであれば、退職者のアカウントを任意の人材に移管できます。しかし、一部のチャットツールや、IMAPメールサービスではアカウントを削除するとファイルが消えることもあります。アカウント削除に対して特段の配慮がないサービスは復元不可能な場合も少なくありません。パスワードを変更し、当人がアクセスできない状態にした上で一定期間保存するような対応も考えられます。

　残された同僚や上長に対して削除時期の確認をすることになりますが、特に背景説明が無いと「取りあえず残しておいて欲しい」という曖昧な言葉が返ってきがちです。ここはアカウントが残されることによるコストの説明とセットにして説得しましょう。

読み書き権限以上に問題な実行権限

　読み書きの発生するファイルは、権限の付け直しだけなのでまだいい方です。

　近年、業務の効率化やデジタル人材の育成といったDXの文脈で、非ITエンジニア職が「Google Apps Script」やVBAなどを使ってプログラムを動かしているケースが増えています。そうした活動をリスキリングへの取り組み実績としてプレスリリースしている場合もあります。しかし、情シス目線で言うと“野良スクリプト”が増える点に注意が必要です。

　私が見てきた企業でも、非ITエンジニア職が書いたスクリプトが退職者のアカウントで動いていたという話を散見します。本来は共有アカウントに移すべきなのですが、個人のアカウントでテストしていたものがそのまま便利だからと複数名に利用されることもあります。特にチャットツールへの通知スクリプトなどは簡単に始められる上、退職と共に動かないことに気付くため、もはや各社で“あるあるな問題”になっています。

　悲劇的な例としては、退職者の非ITエンジニアが書いたFAX自動送信Google Apps Scriptが暴走し、顧客にエンドレスでFAXを送信し続けるというものがありました。スクリプトはあらゆるサンプルプログラムからコピペされていたため可読性が低く、本職のITエンジニアが1日かけて書き直すことになりました。

　今後は各社でこうした野良スクリプトが増加していくでしょう。本職のITエンジニアを巻き込んでスクリプトをリストアップし、権限管理と「Git」によるバージョン管理をしましょう。

キーワードとしての堅牢性と柔軟性

　権限についてのお話を整理していくと、最近ある企業の法務の方が「法務の立場として企業を守ることは重要だが、守りすぎて事業にブレーキをかけてはいけない。事業部が攻める上でそのマージンを削りながら支援していくのがあるべき立場だ」と話していました。

　堅牢（けんろう）に情報システムを守る姿勢も必要ですが、事業にブレーキをかけるようなことは特に成長企業では望ましくありませんし、窮屈な運用は抜け道を生んでしまいます。ITのプロとしてバランスをとりながら、事業貢献をしていくことが求められている分野であるといえるでしょう。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito