どこのプロジェクトにおいてもセキュリティインシデントは起こりうるものであり、未然に予防するための教育も定期的に実施されています。
そして、実際にセキュリティインシデントが発生した場合、PM/PMOに対して再発防止策を検討するような依頼が発生することもあります。
一方で、PMBOKにおいてセキュリティに関するネタはさほど出てこないのが実情でもあります。
そこで今回は「セキュリティ施策」に着目する形でコラムの連載を開始させていただくことにしました。
支援に入っているプロジェクトにおいて「○○について検討いただけないか?」という依頼を受けているはずです。
そして、JPSにはこの際「依頼されたことだけでなく、他にも何かプラスアルファの価値を出す形で応えよう」とする素晴らしい思考を持つメンバーも多くいるはずです。
私は、こちらの「プラスアルファ」について、セキュリティに着目し、セキュリティを強化するための施策を提案したいと考えます。
例として、「コミュニケーションツール」で考えてみることにします。
以前は「経緯・証跡を残せる唯一のコミュニケーション手段」はメールでした。しかし現在では、SlackやTeams等のメンション機能を有するツールが主流となり、メールを使う頻度は減ってきています。そして、「社内に限定したコミュニケーションはSlack（Teams）を使い、社外に連絡が必要な場合のみメールを使う」ことをルール化しているプロジェクトも多く見られるようになっています。
この際、「メールには誤送信、標的型攻撃、サイバー攻撃等のセキュリティインシデントが発生するリスクがついて回るが、用途を制限し使用頻度を減らすことでリスクを軽減できるだろう」と言われることがあります。
しかし、ここで大切なのは「リスクは軽減されるのではなく余計増える」と考えることです。
何故かと言いますと、メールを「たまにしか使わないようになってしまう」ことでルールを忘れ、基本的なルールである送信時の宛先確認や添付ファイルの暗号化等が漏れてしまう可能性が高くなってしまうためです。
さらに対社外となると、セキュリティインシデント発生時の影響が社内のみの場合と比べはるかに大きいことは明らかです。
対策としては、社外へのメールを送信できる人や送信先のドメインに制限をかけること、セキュリティ教育の定期的な開催によりメンバーへの注意喚起をより一層徹底すること等が考えられます。
このように、何かを依頼された際、セキュリティに着目することでプラスアルファの効果をもたらすポイントが見えることがあるはずです。
既存のルールを改善したり、新たなルールを策定する際にはそのルールをより良いもの・価値のあるものにしていくための施策に加え、「改善や策定により新たに発生する可能性があるセキュリティインシデントに目を向け、もし何か見つかればこちらを未然に防ぐための施策を考え、提案する」ということも必要だと考えます。