異動や転職する際の復讐
サービス残業やパワハラ、不理解による業務の超高負荷などなど、種々様々な問題があったので転職を選ぶ方も少なくないと思います。
そういった方々は、最後一矢報いてやると上司や会社に復讐を考えないこともないと思います。
その際にどうしたら『うまく』復讐できるか、ちょっと案を羅列しました。
ちなみに、この記事はあくまでも思考実験としてのジョーク記事です。
逆パターンとして、注意事項としてご利用いただければ、と。
むしろ、大体がメンバーが抜けることで迷惑被った実体験パターンな気がしないでもない。
前提
1. 犯罪者にならない
データ消すとか不正アクセスを行えば一瞬で致命傷を負わせることができるけど、自身も傷を負う可能性があります。
一般的な運用として、会社はそれを防ぐためにアカウント関係は見直しを行うでしょうし、そっち方向の考えは持たない方が良いです。
(一般的なセキュリティ運用すらやってない会社は知らない。いずれ誰かやるので、自分がやるまでもないでしょう)
2. できれば即効性を持たない、時限式であること
異動や退職直後に問題が起これば、原因がわかりやすくすぐ対応されるでしょう。
人員が足りない問題が明確化するので、自分が居た時に欲しがっていた補充要員が即座に追加されるかも。
それだと単純に犠牲者が増えるだけなので、できれば数ヶ月後に発生する爆弾が望ましいです。
3. 重要度は「運用事故＞障害」で、なるべく大規模になること
内部での障害であれば、内部の人(＝以前の戦友)が死ぬだけです。
その問題を、上司や会社は自分を潰したように、うまく立ち回って責任を有耶無耶にするでしょう。
このため、問題は他の会社やユーザ影響がでる形が良い形です。
４.引き継ぎ不足と指摘されない
社会人として最低限は守るべきラインは守っておきましょう。
開発系
担当者居ないので情報アップデートをできない、という問題をメインで目指していきたいところ。
引き継ぎ資料外となる「経緯」「構成」という知見も会社としてゼロにしていきましょう。
・手製のマクロ、ツールをたくさん残していく
運用する分には問題ないけど、運用更新の際に障壁になるようにする。
VBAであればソース見るのにパスワード必須にするとか。
固定文字列で特定の場所やネットワークドライブ参照させるというのも良い。
・ビルドやデプロイを呪文化
何故動いているんだという状況を発生させる。
問題が起きた際に調査が難しい状況にすること。
・エラーを放置
運用上問題ないと判断したエラーを放置しているのであれば、そのままにしておきましょう。
他の問題発生時に、ちょっと足を引っ張ることができます。
・開発環境を厳密化
言語バージョンやフレームワークを限定するように、特定のバージョンのみ有効な機能を活用。
非推奨 (deprecated) な処理をたくさん入れておくと、バージョンアップの際に支障を出せます。
保守・運用系
しっかりした運用を行なっている会社だったら問題はないと思うんですが、
履歴管理外のノウハウも将来問題になる可能性が高いので、しっかり残していきたいところ。
・サーバのログ削除設定を有効化しない
サーバをパンパンにさせることでシステムは止まります。
自分がいなくなって、ずいぶん経った頃に。
cronの動作異常を起こさせて、メール通知パンパンするとか良いかも。
・ログ情報/テーブルの削除設計を放棄
定期的にメンテナンスしないとシステム(検索など)が重くなる、という処理があればベスト。
・従量系課金システムの利用を徐々に増大させる
最近はクラウド系サービスも多いので、ディスク容量とか気にしなくても大丈夫になってますよね？
ということは、徐々に容量増えていくものがあれば、遠い日付でお金の問題が発生するようになります。
・リカバリー対応のドキュメントをシンプル化
そもそも問題っていろんなパターンがあるので一つのドキュメントで対応とかできないですよね。
なので、情報は残すけど実施した問題に対するログレベルのドキュメントにしておきましょう。
どうせ精査されないと思いますし。
応用編
もっと迷惑が発生するようにしたい場合は、バグや対応不足を残しておくのが一番かと思います。
・メールの多重配信
・二重請求や架空請求の発生、請求すべき対象に対して無請求
・特定パターンの時に高負荷問題
・システム設計、構造上の問題を明文化しない
・環境依存問題
うう、苦労した記憶が昨日のように蘇ってくる…
最後に
アンチパターンは逆パターンにすれば、対応すべき問題がわかりやすくなると思います。
ただ、「頼りになる社員が抜ける」というのが一番の問題なんで、そこをなんとかしてもらいたいです。