こんにちは。まよ(@josysnohito)です。
ユーザ企業の情シス部門で働いていると、SIerで働いた場合と比較しどうしてもITリテラシーに疎い人たちと仕事をすることになる。そんな環境では多種多様なストレスも発生します。
いや、さすがに「プリンタ壊れたから直して!」とか、「なにもしてないのにパソコンが動かなくなくなった!」とかそのレベルの問い合わせは自分は経験してないけどね。
この記事ではそんな情シス部門で働く社内SEが感じるストレスをいくつかご紹介します。
記事を読んで感情移入しすぎてイライラするなよ!
あくまで、あるあるネタとしてお楽しみください。
情シスのストレスランキング

第5位
業務部門「システム不具合疑いですので調査願います」
何でもかんでもシステム不具合疑うな。使い方がわからないならマニュアル読むか業務有識者に聞け。
そして質問するなら期待値と実績値を明確にしてくれ。
「マニュアルに記載されたこの操作をしました。想定では✕✕と表示されるはずだったのですが、実際には◯◯と表示されました。」
と聞かれるなら理解できるし調査も早い。でも、
「ここを操作したらこういう挙動をしたんですが、システム不具合ですか?」
みたいな漠然と質問しないで。あるべきが何なのか自分の意見を持ってよ。大体その画面は貴部のご要望のとおりに作ってるはずだから貴部が一番仕様に詳しいはずなのだけど。
という愚痴ばかり思いつきますが、この質問の何が怖いかって本当にシステム不具合な可能性が0じゃないということ。
ちょっと操作がわからないからって、すぐにシステム不具合疑いで問い合わせするのやめてくんないかなー。
初歩的な質問なら秒で突っぱねるのに、不具合疑われたら調査しなきゃいけないじゃん。99%勘違いなのに、ごく稀に本当にシステム不具合なこともあるから強気になれないんだよー。
— まよ (@josysnohito) September 1, 2021
システムの仕事していて100%自分が悪くないって確信を持てる事ってそんなに多くないと思います。私の場合不思議なことに強くになればなるほど実は自分のシステムがバグってたってオチになることが多い。
だから不具合疑いと言われると必死で調査せざるを得ないんですよね。本当に不具合だったら自分が悪いわけなので。。
ということで空振りの確率が限りなく高くイライラはするものの、先方の発言が正しいこともなくはないので5位でした。
第4位

営業「✕✕社から問い合わせを受けました。内容確認して直接回答してね。」
ザ・丸投げ!あなたはメール転送屋さんなのかな?って思ってしまうこの質問。
営業担当か突然メールが転送されて一言。
「xx社より以下の問い合わせを受けております、お手数ですが直接ご回答願います」
いや、いいんだけどさ。あなたの存在価値はなに?
仕事とってくる営業じゃなくて社外窓口の営業なんでしょ?って気分になったわ。— まよ (@josysnohito) August 6, 2021
大体の場合よくわからない添付ファイルか長い引用メールとセットでくる。そして具体的になんの画面のことを言っているのか、どのインタフェースのことを質問しているのかわからない。翻訳者不在で外国人と会話している気分になる。
うちはこの手の翻訳はフロントに立つ営業の仕事となっている。(こういう仕事取ってくる営業ではなく、社外窓口として営業を置いている会社は多いハズ)
そして営業は口が上手い率が高いからなおたちが悪い。たちが悪いと言うか分が悪い。よくわからないけどこっちで対応しなきゃいけなくなる。ほんと困る。
第3位

UAT工程で業務部門「これも必要なんで仕様追加しといてください」
UATとはユーザアクセプタンステスト、つまり開発を依頼した側(=ユーザ)の承認を受けるためのテスト工程のこと。
大体のシステム開発案件で要件定義書をインプットとして試験項目を起こし、試験の最終工程として設けられている事が多いと思います。
もちろんこの工程で要件通りに作り込まれていない仕様があればそれは開発する側の責任。大至急要件を満たすための機能の作り込みをしなきゃならない。
でも時々この工程で要件定義書に書かれていない仕様変更を依頼されることがある。
理想のUAT
・ユーザが業務に沿ったテストシナリオを作成する
・開発者は試験される側として参画
・一度OKが出たら手戻ることはない現実のUAT
・ユーザがテストシナリオ作れるなんて幻想
・シナリオの消化方法を開発者がユーザに手取り足取り教える
・テストでOKが出たのになぜかリリース後に仕様変更— まよ (@josysnohito) February 4, 2022
100歩譲って本当に必要な業務なら仕様変更もやむなしだと思う。もちろんスケジュールは変更しまけどね。
でもなぜ仕様変更をするのか不明確だったりする。それだけじゃない。
「そんなミス猿じゃねえとしねえよ!」レベルのオペレーションミスを救うためみたいなしょうもない仕様変更もよく起こる。
システム開発は要件定義工程が肝なんだ。UAT工程で仕様を変えないでくれ。
「でも、UAT工程で仕様変更してはいけないって言われてないですよね?」
とか論点ずれた質問しないでくれ。話がこじれるだけなんだ。
第2位

えらいひと「保守費用を削減せよ」
どうしてなんだろうか。システムのランニングコストというのは常に削減対象に挙げられがち。無駄だとすら思われている。だからいつでも削減削減言われてしまう。
社長「全然トラブル起きてないから、保守要員と予算減らすことにしたわ」#情シスを一行でイラつかせる選手権
— ブラック企業アナリスト 新田 龍 (@nittaryo) April 13, 2021
もちろん既存業務の効率化を進めた上で費用削減するのは構わないと思う。定例作業をマクロ化したことによる費用削減とか、複数のデータセンタ集約による監視要員削減とかならわからないでもない。
でもね、根拠もないのに毎年何%削減せよ!とかやめて欲しい。システムを動かし続けるということはお金がかかるの。電気代だってそうでしょ。毎月一定の料金がかかるでしょ。それと同じなの。
大体、天下のOracle様なんて年々保守費用増額してるんだよ?その理由は年々保守コストが増額しているから。日本だってエンジニア不足が問題になっているのに、どうして保守コストを執拗に下げたがる?
何度も言うけど既存業務の効率化を進めた上で費用削減するのは正しい。ただしコスト削減には相応の根拠が必要だということを忘れないで。
根拠なくエンジニア切ったらなにかが起こるからね。
実際、某メガバンクもシステムリリース後の要員を減らしすぎた事が障害の原因だという分析もありますしね。
平成30年3月末時点で1143人だった担当者は今年3月末時点で491人となり、3年間で57%減った。6月の第三者委員会報告書では開発段階から関与していた担当者の減少に言及して「システム構造のブラックボックス化」が進んでいると指摘していた。
引用元:https://www.itmedia.co.jp/business/articles/2109/01/news085.html
第1位

業務部門「大至急お願いします」「最優先でお願いします」「本日中にご対応ください」
「業務に支障が出ているので早めにお願いします」#情シスを一行でイラつかせる選手権
— おかしん ☕ 👨💻 (@okash1n) April 13, 2021
すごく共感したツイート。私も週に1度はこの依頼を受けていらっとしている気がします。
大半が要件定義漏れだったり、誰かが放置していた案件が炎上したりなど、本来やるべきタイミングでできていない事が表面化したときにこの依頼を受ける事が多い。
理不尽なのは本当に至急性が高い場合、きちんとタスク分解して余裕を持ったスケジュールを立てて1つ1つ確実に仕事をこなしている人のタスクを押しのけて、この手の至急依頼をこなさなきゃいけなくなること。つまりきちんとやってる人が割を食う場面がある。
そしてこれが上司経由での依頼となるとまじで泥沼になります。
自分が要件提示するのに半年かけたくせにさー、1日や2日返信遅れただけで上司経由して催促かけて来るのなんなのーやめようよ。
上司経由の催促とか悪手でしかないからね。そんなやつのこと信頼しないし、そんなことしてくるやつの案件なんて優先度最低として扱うからね。— まよ (@josysnohito) October 22, 2021
これを食らうと許容限界を一気に超える。本当にこっちの非なら頑張るけど依頼元に非があるなら絶対に至急対応として取り扱わない。
本来はこうならないために日々良好な人間関係構築しておくべきなんですよ。それができてないからって上の力を使って人に命令してくるって何様なのって気持ちになる。
まとめ:真に受けるなよ!ただの愚痴だぞ!

ということで情シスがイライラすることランキングをご紹介しました。こんなイライラする記事を最後まで読んでくださってありがとうございます。
結局、情シスの仕事ってこの手の面倒事をうまくさばくことなんだろーなと思います。
それに面倒だと思った対応をこなした経験が自分の知識向上に繋がることもあったりするので、決して悪い仕事じゃないと思うよ。情シス社員って。
ということでガス抜き目的の愚痴でした!