IQ49

IT業界の感想

「俺は優秀だから裁量労働制でも平気」と思っていたら死ぬ

なぜなら俺がそんな甘いことを思っていたから。

そもそも優秀とはなにか

プログラマの9割は自分のことを平均以上のプログラマだと思っています。(俺脳内調べ)

周りを見てきて思うのは、自らの能力を客観視するのは難しいということ。IQ50未満と言われた俺でさえ、自分のことを優秀なプログラマだと錯覚しているからねほんと。そして周りの奴らはどう見てもプログラミング能力しょぼいと思えるのに「俺はこれまで複数プロジェクトを成功に導いてきてプログラミング能力高い」とかマウント取り合っているというわけわからん状態。ようするに自分自身を客観的に見れておらず過大評価している。経験年数が多いからプログラミング力高いってほんとお?
自分を優秀だと思っている時点で、冷静になる必要がある。

システム開発というものは難解でだれしもミスをするものである。自分の思ったとおりに進捗は進まない。自分ができると思っていた仕事が思ったよりできなかった場合、そのギャップに苦しむのは自分である。
自分は優秀じゃないんだから失敗して当然くらいのスタンスでないと自責の念で幸せになれない。

仮に優秀でもそんなの関係ない

仮に優秀だとしよう。
なら果たして好きな時間に帰れるのかと言うとそんなことはない。なぜなら暇な人にはどんどん仕事が割り振られるから。俗に言うできる人に仕事が回ってくる状態。

そもそも仕事量というものは下っ端が決められるものでなく、営業が受注契約を結んだ時点で決まる。受注契約以外にも改善活動とか内製化とか会社が存続している限り仕事は山のように沸いてくる。
そのため普通に仕事していた場合は残業したくないと思っていても営業がたくさん仕事取ってきた時点で終わり。もうどうしようもない。

仕事の納期もゆとりがあればいいのだが、システム開発において突発的な対応というのは当然のように発生する。特にリリース前に「あの機能がやっぱり足りてなかった!」というのはしょっちゅう。
システム開発は開発環境さえあれば前準備ほとんどなしで取り組めるから突発作業を平然と積まれる。

裁量労働制にも関わらず残業時間で評価する企業に入ると死ぬ

「でもそんなの関係ない俺は早く帰るぜ」とやっていたら評価を下げられる。別に3,4時間で帰ってるわけでなく8時間働いているのだが、サボっているように見えるらしい。

さらにシステム開発は個人で働くのでなくチームで働くものである。チーム内で残業時間が少ないやつがいると「お前のせいでチームの評価が下がるぞ」とマネージャーからの激が飛ぶ。チームメンバーに迷惑をかけるかもしれないと言われて気持ちよく定時に帰れるものだろうか。
やっていることは江戸時代の五人組そのものではないか。

見込み残業◯◯時間で手当もらってるから残業するのも仕方ない?

「見込み残業◯◯時間で手当でてるからそのぶん残業するのは当然」
もっとものように聞こえる。基本給が低くなければ。
そもそも基本給が高ければ"見込み残業代◯◯時間"という表記は必要ないのではないか。たとえ手当が多いように見えても基本給を下げて調整すればいいのだからみせかけだけの◯◯時間にはなんの意味もない。意味があるとしたら「手当やってるんだから残業する義務があるんだぞ」と社員を恫喝するときだけだろう。

最後に

残業せずに帰るために必要なのは技術力でなく、帰りたいから帰るというメンタル。

責任は徹底的に追求するが、対策はほとんど追求しない組織で感じたこと

今いる職場というものが、責任はとことん追求するが対策はほとんど追求しないというなんだかなあという職場。 そのせいもあってかうつ病経験者が多い。具体的に書くと4人に1人はうつ病になる。

うつ病患者や自殺者が多い職場というのはもうどうしようもないものがある。 俺も昔は「上司が悪い」とか「アイツさえいなければもっと良くなる」と特定の個人に責任があり、職場としては責任がないと思っていたがそれは間違いだと最近気がついた。 たしかに特定の害悪というものは存在するのだが、そいつがいなくなってもまた空いたポストに代わりのものが収まるだけなのだ。なぜならそれは組織としてのカルチャーの問題であり、人間というのはうつ病経験者が蔓延する職場で数年働くと自然と同僚をうつ病に追い込む体質になってしまうのだ。
これを書いている俺自身も他人をうつ病へ追い込む性質になっているのでないかと恐怖せざるを得ない。

後工程の作業者へのリスペクトがない

例えば上流設計者はプログラマを平気で馬鹿にするし、プログラマは平気でテスターを馬鹿にする。
仕様の食い違いや漏れがあった場合はいかに後作業者がミスをしたかのなすりつけが発生する。 自分の担当分以外は関わらないのが当然というスタンスなので、担当者しか把握していないドキュメント、プログラムというのが平然と存在する。

属人化しているというのは結果であり、結果だけ見て「属人化はよくない」と叫ぶのは原因を把握していない証拠である。 本当に気を遣うべきは、なぜ担当者しか把握していない制作物があるかの根本的な問題の解消である。

プログラマやテスターを馬鹿にしているExcel使いを観察して気がついたのだが、彼はプログラムを書く能力もテスト設計をする能力も非常に低いものだった。 おそらく彼の中のプログラマやテスターのハードルというものが非常に低く設定されておりそれゆえに、他のプログラマやテスターもこんなものだろうという意識が生じ見下すに至ったのだろう。

プロジェクトは黒字で当然という歪んだ結果主義

システム開発の請負において、初期一括見積であれば先行きの不透明さからある程度の割合で赤字のプロジェクト発生するのは当然である、しかし目標で赤字がゼロは当然とされている。 そのためどれだけ効率良く開発を行っていたとしても見積り金額より赤字という理由で最低評価を付けられる。
これにより、簡単なプロジェクトを計画通り終わらせるほうが、難しいプロジェクトを計画ズレありで終わらせるより評価が高くなる。

また品質においては事故件数◯件以下というふざけたような目標が掲げられている。 これはプロジェクトの難易度に限らず事故一件は同じ事故一件と数えられる。 ここでも、簡単なプロジェクトを事故無く終わらせるほうが、難しいプロジェクトで事故を起こすより評価が高くなる。

リスクを恐れるあまり、リスクのある作業を他人に押し付けあっているだけなのではないかと感じる。そしてその根回しに生産活動を行なう労力や時間を割いている気がする。

安易に項目が増えるチェックシート

事故が発生した場合、根本的な対策をとることをせず、チェックシートに項目を増やすことで対応しようとする。 事故に至る無数の原因のうち、特定の物しか防止できないような、しょぼいチェック内容のため事故を防止する効果は一切ない。
過去の事例と似たような事故が発生した際には「作業者が手順を守っていなかったため発生した」と作業者が責任を取らさせるが、 ほとんどいいがかりに近いものがある。作業者が手順を破るとうことは基本的に発生しない。そもそもSIerお得意のダブルチェックが頻繁に入るので手順をあえて破るというリスクある選択は作業者は行わない。

例えば「プログラムが詳細設計どおりに作られていること」というチェック項目がプログラミング作成時にあったとする。 はっきりいってこれはなんの意味もない。プログラムが詳細設計通りに作られていることを検証するのは単体テストを終えた後である。 このチェック項目が有効なのは作業者が意図してプログラムを詳細設計通りに作っていない場合だけである。そんなことを確認してなんの意味があるのだろうか。 このような責任をなすりつけたいがためのチェックシートで作業者を弾劾するのは正気の沙汰ではないだろう。

残業時間はみんなおなじくらいに

残業時間はみんなおなじくらいに(限界まで)高くするのは当然、ひとりだけ楽して帰るなんてもってのほかというスタンス。 おもにこれのせいでうつ病の人でてくるんじゃないかなほんと。 苦しんだら苦しんだ分だけ給料に反映されると思っている。

管理職が、部下の残業時間ばかりに目を向けて、仕事そのものと向き合えていない。

ミスを隠蔽する

何か失敗した場合はすぐに隠蔽に走る。隠蔽する理由は上司の追求が厳しいものだから。
そのためPDCAサイクルのCAが回らず、施策を出す→うやむやになって終わるの繰り返し。
無駄な時間だけが過ぎていく。

システムエンジニアの日常6

プロパー「この画面変な動きするんですけどバグですよね?ちゃんとテストしてるんですか?」 ワイ「ごめんなさい!仕様どおりに作ったと思ってたんです…」

ワイ「今までずっと間違ってたみたいで…ほんとに知らなくて…あのすみませんすぐ直し…ん?」仕様チラ ワイ「仕様やんけ!!」

プロパー「!」

ワイ「仕様に!書かれとるやんけ!!!!お!?」

ワイ「仕様に入っとるでこれ!!見えてんの!?仕様に画面動作入っとるでこれ!!!」

プロパー「あわわわわ」

プロパー「大変失礼致しました!!不快な思いをさせてしまい申し訳ございませんでした!このまま検証を…ん?」要件チラ プロパー「入ってないやんけ!!」

ワイ「!」

プロパー「要件に入っとらんやんけ!!!!お!?」

プロパー「もらった要件見えてんの!?そっちの仕様書には書かれててもこっちが出した要件にはそんなのないわこれ!!!」

ワイ「あわわわわ」

ワイ「ご、ごめんなさい!こっちの勘違いで…ほんと悪気はなくて…!あのすみませんすぐ直しますから勘弁…ん?」タスクスケジューラチラ ワイ「要望きとるやんけ!!」

プロパー「!」

ワイ「実装期間中に!要望出しとるやんけ!!!!お!?」

ワイ「要件締切後に頼んでたでこれ!!覚えてへんの!?要件締切後に頼んどるでこれ!!!」

プロパープロマネ「「あわわわわ!」」

娯楽界隈に立ちふさがる時間の奪い合いというハードル

20年前と今を比較して娯楽(コンテンツ)に対してのビジネスモデルがだいぶ移り変わってるんじゃないですかねえという話。
なんで20年前と今を比較するのかというと、今はインターネットがあって娯楽へのアクセスがとにかく簡単になったから。娯楽が多様化し、しかも低価格で手軽に入手できるようになっている。

最近は「娯楽時間の奪い合い」という表現をよく耳にするようになった。 この言葉は新聞、テレビ、雑誌、音楽といった既存の業界の売上減少とともに語られることが多い。インターネットの発展に伴い、娯楽が多様化した結果割をくらっているのだと。

ここで疑問となるのが、20年前は「娯楽時間を奪い合う」という状態が存在していなかったのではないかということだ。
主観になるが20年前はとにかく暇だった。新聞は興味ない記事は飛ばすにしても一通り読んだし、本も何回も読み直していた。ゴールデンタイムとなるとかかさずテレビを見ていた。 しかし今となっては娯楽が多すぎて暇と感じる時間が減った。むしろ色々やりたいのに足りないくらいだ。

思い返してみれば20年前は「(大衆の)金銭を奪い合う」ことしかせずにすんでいたのだ。もちろん今でも金銭の奪い合いは行われている。しかし、その前に「時間の奪い合い」に勝ち残らなくては金銭を奪い合いというフェーズに参加すらできないのだ。売上を落している企業も決してコンテンツに魅力がなくなったわけではなく、旧来の方法が「時間の奪い合い」という要素に対して戦略的に間違った方法を取っているのでないかと思う時がある。

f:id:baito_mo_yamunai:20180212205833p:plain

どのようなコンテンツが時間の奪い合いに勝利しているかというのは結果を見れば一目瞭然だ。 例えばYouTubeのような"無料"で"手軽"にアクセスできるコンテンツが圧倒的に強い。

既存業界の衰退に対して「消費者がクリエイターを尊重し適切な対価を支払うことが打開策」のようなものを目にすることがあるがちょっと違うと思う。クリエイターへの報酬の大小で勝負できたのは旧来の「金銭奪い合い」空間の中であり、おそらく根本的な解決策とならないからだ。もっともピュアオーディオ界のように今いる顧客から最大限搾り取るという戦略もあるのかもしれない。

まあでもテレビってまだまだ強いよねピークは過ぎた感はあるが。

要件定義書が一切変更されないプロジェクト

プロジェクトの最初から最後まで要件定義書が変更されないとしたら、そのプロジェクトはいびつでなにか問題を抱えている可能性が高いだろう。

要件定義書とは顧客から見て何が行われるかを示すものである。どのような設定があり、どのように動作し、どのような見た目をしているかを記述する。逆に言うとプログラムでどのような実装がされているかの情報は必要ないと言える。

要件定義書が変更されない理由はいくつか考えられる。
1. 本来変更が入る箇所を要件定義書以外のドキュメントで管理している。
2. 最初から完璧なドキュメントが用意されているので、変更の必要がない。

2については「簡単なプロジェクトなんでしょうね」くらいしか言うことはない。
ここでは1について説明したい。

そもそも、なぜ1のような事象が起きるのだろうか。
要件定義書というのは本来顧客が作成するものである。もちろんシステムの機微に詳しいベンダーが手伝う場合もあるだろう。
原因は会社間でやり取りするドキュメントなので変更管理が難しいということにあるのではないかと思う。 一度作った要件定義を変更するのが面倒なので、要件定義は変更されないことにして次のタスクに進むといったことをしている。そのため本来変更すべきものを変更対象に出来ず1のようなことが起きるのではないだろうか。

では要件定義書じゃないならどこで変更すべきものの調整が行われているのかというと、これは詳細設計書で行われる。 詳細設計書とはSIer特有のプログラムがどのように実装されているかを示す書類である。 これには問題点がいくつかある。

  • 要件定義書だけではシステムの使い方が分からず、詳細設計書まで顧客に納品しなければならない
  • 顧客は使用方法だけが知りたいにも関わらず、プログラムの実装方法を見る羽目になる
  • 顧客が受け入れ検証する際のノイズとなる
  • 納品の際に、要件だけでなく詳細設計書の内容を満たすかどうかの証左が必要となる
  • 詳細設計書ありきになってしまい、いざというときに詳細設計書をなくすことができない

詳細設計書に該当する記述は本来プログラミング中のコメントとして記述し、プログラムからの自動生成を行えることが望ましい。

結論

詳細設計書を顧客に渡してるプロジェクトは地雷。 仕事としてドキュメントを書くからには、誰が何のために読むのかを考えなければならない。

女性差別のむなしさ

女性差別して楽しいのか、本当に心の底から女性を見下しているのかって話ですよ全く。
まずナチュラルに女性を見下す人が多くない?なぜ女性という多種多様な35億人いる軍団を見下せるのか。
だって35億人もいたらどう考えても見下せない人が結構な割合でいるわけじゃないですか。
男女の性差よりも、個人としての特徴のほうが100倍くらい大きいので女性を能力で差別するのって無理でしょ。

例えば100走。
全体のトップだけ見ると男性のほうが記録は出ています明らかに。では果たして何人の男性が女性の世界記録保持者より速く走れるのか。おそらく1%もいないでしょうね。言わずもがなですが、個人差が激しいから。短距離走という男女差がはっきり現れる分野ですら女性より劣っている男性もたくさんいますね。
にもかかわらず、アスリートにむかって「男子高校生にも勝てない」とか言う発言が絶えないわけですよ。じゃあお前は吉田沙保里に勝てんのって感じですよ。 こういう勝てる勝てない発言は全ての男性が全ての女性に対して優位であるという条件がせめて満たせないと言えないんじゃないですかねえ。

もっとも仮に男性全員が女性全員に勝ってたらそれ当たり前なんで、わざわざ発言として表明する意味あるのかって話ですけどね。 「カラスよりも人間のほうが賢い!」とか言う人いないじゃないですか。

あと女性差別に限らず、「◯◯君(俺)でもできたから余裕」とか言って見下してくる発言、もうなんなのと。 Q.「うちのこ頭悪いんですけど、◯◯高校受かりますか?」 A.「◯◯君(俺)でもできたから余裕」 Q.「うちのこ頭悪いんですけど、運転免許とれますか?」 A.「◯◯君(俺)でもできたから余裕」 Q.「うちのこ頭悪いんですけど、警備員なれますか?」 A.「◯◯君(俺)でもできたから余裕」

いやしらねーから、俺という存在が頭悪い人代表みたいに言われても困るし、俺とそいつは違うだろうと全く違う人生を歩んできた別人だろうと。むしろ俺は勉強ができないだけで勉強以外の面では他の奴らより優れた部分はあると思ってるから。あと警備業界はやめとけ。

プログラマに丸投げするSE達の行動

  • ちゃんと仕様書読めよ

  内容を解読できないから失敗したんですけどおわかり?

  • 仕様書書くのが俺の仕事で後は知らん

  あなたこの仕様書で後工程実施できるんですか?

  • 書いて無くても常識でしょ

  俺この現場初めてなんですけど

  • Aさんにも確認してもらって

  Aさんは仕様のこと全く知らないけどな

  • 任せられるところは任せて自分の負担を減らすのがコツよ

  任せたところの責任は取らないけどな

  • 派遣のやつがひどいプログラムを書きやがった、全部派遣のせいだ

  丸投げの行き着くところは非正規社員なんすね

  • 仕様書を変更する必要性が分からない、分かりやすく説明してよ

  なぜ一度作ったものの変更を頑なに拒否するのか

  • 作業記録は逐一残せよ、自分の身は自分で守れるはずです

  記録取らないと事故原因捏造されて押し付けられる職場ってなんなんでしょうね

  • コード?設計書を読めばコード無くても分かるよ

  エラーログからエラー内容たどる作業してるんですけど

  • なんでやってないのかわからない

  なんでやってると思った?

  • 言ったんだからお前がやるんだよな?

  言い出しっぺに押し付ける法則

  • 俺らパソコンに◯◯入ってないからできないんだわ

  入れろよ