今回はSNSでよく見かけるITネタを解説します！
「SNSでよく上がってるITのあるあるって本当なんですか？」
これ、実際私もよく聞かれる事あるんですけど、結構本当の事多いです。
私は「あるある」として楽しんでますが、こういうブラックなネタが、嫌いな人もいるかもしれません。
でも、これからIT業界で頑張る若手の方には、我々世代が築いてきた失敗事例を、教訓として知ってほしいのです。
もちろん「あるある」として楽しんでもOKですし、野次馬根性で楽しむのもいいと思います！
一番やっちゃいけないやつ
＃IT業界クソ現場オブザイヤー より
１年前からいるSE「自分がやっても10日かかります」
部長「じゃあ10人いたら1日で終わるよね？」
翌日、何も知識のない素人10人ドーン
部長「じゃあ彼らの管理と教育も含めてよろしく」
これ一番やっちゃいけないやつで、失敗プロジェクトの例としてよく挙げられます。
新人が覚えるまで、数か月を見込む事が必要なのと、教える時間も考慮しなければいけません。
これが原因で先輩エンジニアの仕事が結局倍以上になり、倒れるエンジニアが続出してました。
しかも「人を増やしたのに？なんでそうなる？」みたいに上長が理解できてない事が多いのも、このケースの怖いところ。
人だけ増やしても期間は短縮できません！
※詳しく知りたい方はこちらも読んでみて下さい！
もう誰も信じられない・・
＃IT業界クソ現場オブザイヤー より
私「仕様変更なんて聞いてないですよ」
クライアント「言った」
営業「言った」
上司「言った」
議事録&音声「言ってない、むしろ変更しないって言った」
クライアント「…変更するって言った」
営業「…言った」
上司「い、言った」
エビデンスを残してるのに、味方にも裏切られエンジニアがピンチになる流れ。
なぜピンチになるのかを解説すると、例えば作業工程が１～100あったとします。
仕様変更は、90まで完了しているのに1からまたやり直しになる事を意味します。
ちゃんと決めていたのに、それでも仕様が気に入らなくて変えたい状況です。
納期直前になると、こんな意見が飛び交いやすく、納期の延長も認められません。
これがエンジニアを、何日も徹夜させた問題の元凶です。
※仕様変更の問題について、詳しく知りたい方はこの記事を読んでみてください！
どんだけレビューすればいいの？
＃IT業界クソ現場オブザイヤー より
ぼく「『select * from テーブル』したいです！」
先輩レビュー
リーダーレビュー
マネージャーレビュー
作業報告連絡
作業終了連絡
事後先輩レビュー
事後リーダーレビュー
事後マネージャーレビュー
この作業は、秒で終わる仕事なんですが、上長がレビューしなければいけないため、結局、何時間もかかってしまう問題。
おそらく、過去に人力の作業に問題があり、毎回毎回、再発防止策だけを求め続けられて、最後にこうなったと思われます。
オンスケ問題
＃名画で学ぶ業界より
お前オンスケって言うたやん・・。
波風を立てないように「オンスケなので順調です」といい続けると、どこかで事実が発覚してこの名画のようになります。
実はこれも割とよくある話、スケジュールの遅延ってものすごい追及されるので、こういうの隠ぺいしちゃう人結構いました。
やっぱり、心理的安全って大事なんですね。
要望を受け続けた結果
＃名画で学ぶ業界より
言われた通りに作りました。
できれば、要望通りのモノを作ってあげたいですよね。でも、要望だけを統合して無理やりくっ付けても、なんだかよく解らないものが出来上がるだけ。
相手がどんなに怖いお客様だったとしても、おかしいものはおかしいと言って、ちゃんと正しい方向に誘導しましょう。
ちなみにこれに類似した話題もありました。それがこれ・・
根拠もなく「できます、できます」を繰り返して、破綻してしまったイメージです。
ここで問題です。
#IT系応用問題 より
たかし君は、いつも名刺をきらしています。なぜでしょう？
ちなみに、多重請負をやっている会社は、給料がものすごく安いので、覚えておいてください。
最近では禁止されていますが、抜け道は普通にあるので、まだ根絶していません。
※多重請負および、なぜ給料が安くなるのが確定なのか？興味のある方はこちらを読んでみて下さい！
最後に
今でこそ笑い話にしていますが、これが原因で体を壊してしまったり、キャリアを失う事になったら笑いごとじゃありません。
おかしな事をしてる会社にいくら尽くしても、リターンなんてありません。それどころか何かあれば、逆にどこかで切り捨ててくるでしょう。
自分の身は自分で守るしかありません。
笑い話でもよいから、こういう話があった事を知っていただき、これから頑張る皆様に、ワクチンみたいな効果がでたらいいな・・なんて思ってます！
