![見出し画像](https://assets.st-note.com/production/uploads/images/44607994/rectangle_large_type_2_c1cbca2d8025415f4a5b59f064dfcaa3.jpg?width=1200)
過度のセキュリティ管理が引き起こす新しい技術習得への弊害
こんにちは、桜草です。
今日はしがないエンジニア目線の、エンジニア以外の人にはちょっぴり面白くない、人によっては耳が痛いかもしれないお話です。
1. IT企業のセキュリティ管理事情
IT企業に勤めていると、現場によってはセキュリティがかなり厳しいところがあります。
扱うデータがゴリゴリの個人情報だったり、セキュリティ対策関連のソフトを開発している現場、ISOを取得している現場などは特にセキュリティ関連に意識を向けているように思います。
以下より私が直面したセキュリティ周りの制限を例として挙げておきます。
1. PC持ち出し申請の強制もしくは持ち出し不可
基本的に会社から支給されたPCは持ち出し申請の提出が求められます。
こんなのどこも同じだよ、と言うところが多いかもですね。
ただキツいところは派遣やパートナー会社からきている人は持ち出しできないよう、そもそもデスクトップしか支給しない現場もありました。
2. 私用端末の持ち込み禁止
持ち出すのがダメなら、持ち込みもダメです。
私用のスマホタブレットは会社のデスクの上に置くことすら禁止されていました。ただ近年ユーザーが増えつつあるスマートウォッチだけは黙認されてましたね。(規約が追いついてなかっただけかもしれない)
昼休みに外に出て初めて自分のスマホが自分の手の中に帰ってくるのは、正直辛い環境でした。
3. PCでの個人アカウントログインの禁止
情報を流せてしまうSNS(Twitter、Instagram、YouTubeなど)はもちろん、Googleアカウントもログイン禁止です。業務上はG Suite経由で発行された業務専用アカウントを使用してやりとりしていました。
ちなみにSNSのページをWebブラウザで開くと制限がかかって閲覧すらできないところもありました。
あとはGitHubアカウント。これも個人用のGitHubアカウントは使用できず、会社側で発行したアカウントを使用します。
このため業務で対応したあらゆる実績は個人アカウントには反映できないため、実績証明が難しくなります。
4. 指定されたツール以外のインストール禁止
IFTTTのような自動連携ツール、FTPソフトのような転送ツールは基本的に使用不可、その他のツールも会社の監査が通ったものしか使用できませんでした。
5. 退出時のノートの破棄の強制
業務の指示や考えをまとめたり、何かとメモをとる機会があるノートですが、なんと、プロジェクトが変わったり異動になったりで現場が変わる場合、それまで取ったノートはシュレッダーにかけることが義務付けられていたところもありました。
自分のノートなのに。自分の知識と経験なのに。と思わなくはないですが、知識と経験は自分の頭に残っているものだけが頼りと言うことですね。
2. セキュリティが厳しすぎる環境での弊害
つろつろと書き連ねてきましたが、上記のような制限がない環境に変わった時に初めて、制限がある環境特有の弊害があると感じました。
2-1. 新しい技術・ツールを知ろうとしなくなる
上記の例であったように、業務で使用するPCにインストールできるソフトが決められていた場合、
もしくは使用したいと思っても、ソフトウェア利用申請が通るまでに1ヶ月かかる場合(よくあることです。。)、わざわざ新しいツールを調べようと思わないのです。
今あるツールでどうにかするしかない。
どうにもならないなら力技でどうにかしよう。
こんな考えに慣れてしまい、思考が固着してしまうように感じました。
2-2. 不便さ・しんどさに慣れてしまう
古い技術を使い続け、初めはなんだか使いづらいな、やりにくいな、と思っていたことも、回数を重ねるごとにそれが「普通」だと思ってしまう。
いわゆる慣れです。
エンジニアは不便さ、しんどさをITの力で改善するのが仕事なので、これらの不快な感情に慣れてしまうと、それはもう技術者としての死を意味します。
成長が止まったエンジニアは、同じことをただ繰り返す機械になってしまうのです。
2-3. 新しい技術に取り残される
新しい技術やツールは、新しいからこそ試してみて別の問題が出てくることもあり、百歩譲ってそこは目を瞑りましょう。
ただ今流行りの実装方法や流行りの開発言語を知らず、古い技術のまま開発を進めていくのは近い未来そのプロジェクトの崩壊を意味します。
技術に流行り廃りがあるのは、古い技術に何かしらの弱点があったからです。
それを新しい技術に差し替えることで、より良いパフォーマンスを発揮するとか、可読性を上げるだとか、少なくとも何かしらの恩恵にあずかれる。
だからこぞってみんながその技術を使い始め、やがて流行りになっていきます。
その流行りの技術を知ろうともしない技術者は、その現場の外では生きていけない人になってしまいます。
3. 例えばどんな改善ができたのか?
不要なPCをローカルサーバーとして立てていた
今なら絶対にDockerを使用した方がいいです。
各個人のPC内なら、DBのデータを書き換えようが、PHPの実装を壊そうが、自分が困りはしますが、他人の作業にまで影響を及ぼしません。
遷移図やシーケンス図、ER図を設計書をExcelで書いていた
サービスが大きくなればなるほど、設計書に特化したUMLなどのツールを使用する方がいいです。
大きく崩れることもなく、かつ分かりやすく表現できるのであれば、それに越したことはありません。
機能を追加するごとにサービスのパフォーマンスが低下していた
サービスとしての流行りの実装方法やクリーンアーキテクチャなど、今となっては検討すべきことがいくつか出てきますが、当時の自分には提案することすらできませんでした。
終わりに
私が最近関わる現場は、幸いなことにここまでセキュリティ制限の厳しい現場にはお目にかかりません。
自分が使いやすいツールをインストールしていいし、
会社支給のPCでVS CodeのTwitterやFlutterのYouTubeなどを見たりしてもいい。
チームとして使っていきたいと思うツールは積極的に声を上げて取り入れていける。(多少お金がかかっても)
ただこのように「やっていい」と思えるのは、制限された環境から制限の外れた環境に出たからです。
制限の中に居続けるとその不便さに気づくことすらできなくなります。
過度の制限は技術者の首を締め、ひいては日本全体の技術の停滞につながるのではないか、と思った次第です。
ここまで読んでくださり、ありがとうございました!
では。
この記事が気に入ったらサポートをしてみませんか?