シン・ウルトラマン視聴完了

 AmazonPrimeでシン・ウルトラマンの視聴完了。(´・ω・`)

本当は映画館に行きたかったんだけど、コロナとかあるから自粛しててね。
最近は仕事も忙しくて観る元気も出なかったけど、本日ようやく元気が出て観れた。

実は僕ってウルトラマンを観たことが殆ど無くて。

ウルトラマンはスーパー戦隊と違ってシリーズ通してずっと放送され続けてるわけじゃなくて、空白期がある。
僕が小さい頃はその空白期に相当していたから、レンタルビデオとかで断片的に観たことはあっても、本格的には観なかったんだよね。

その後、ウルトラシリーズが復活するのは１９９６年ウルトラマンティガだが、この時の僕はもう１４歳で、特撮からも離れていたから観ることは無かった。

そして現在では「スーパー戦隊」「仮面ライダー」「ウルトラマン」は毎年常にあるものになってるけど、重い腰を上げて観るわけでもない、くらいの温度感で日々を過ごしている。

でもシンウルトラは庵野秀明監督の話題作でしょ？(´^ω^`)
毎週特撮観てるわけではないけど、これは押さえておきたいもんね。(´^ω^`)

感想としては、怪奇色とでも言うのか。
仮面ライダーもそうなんだけど、昔の特撮は今よりもダークで泥臭いイメージがあったのよね。

シン・ウルトラマンはＣＧとかは凄く美麗なんだけど、路線としては古い時代のウルトラマンを連想させるような演出が多くあったように思える。
古き良き時代のウルトラマンを念頭に置きつつ、新しく作り直したようなイメージ。大人向け感を感じるけど、一方で子供が観ても楽しいような出来栄えだったと思う。

さて、これで残すは「シン・仮面ライダー」だな。２０２３年３月公開。

楽しみに待ちたい。(´^ω^`)

休日対応

 あら？　今日も休日出勤しているヤツがおるな。まあ、遅れているからな。問い合わせが来ているから対応。(´・ω・`)

ここがリモートワーク最大の利点で、僕は自分の仕事は９割終わっているから、休日出勤してまでやることは無い。

しかし、別チームで何か問い合わせが発生したら話は別でしょ？

「３０分くらいで良いから反応して欲しい」

みたいなケースが結構あって。そこでリモートワーク。

僕はリモートワーク、かつ休日も殆ど家にいるから、昼寝して起きてチラッと見て「何か来てるな？」と気付いたら１０分くらい仕事するわけよ。
その１０分でみんな凄い助かる。

平日と休日の境目がグレーでブラック労働の温床。まあ、僕は裁量労働制だし、元々がフリーランス上がり。稼働がキツい時のコントロールも自分でやれるから、そういうのは気にしていない。

自分で稼働調整が出来ない若い衆とかにはオススメしないが、ベテランには都合の良いやり方おね。(´・ω・`)

デタラメ検知人

 しかし、ま～、我ながらよくやると言うか。(´・ω・`)

僕もＩＴ業界で長くやってきて今や４０歳。若い頃から技術力を高める事には熱心で勉強も重ねて来たつもりだが……。

最近はもう何か、世の中はそういうもんじゃないなぁ、という感。

じゃあ、何が重要か？
僕が思うのは、「デタラメがデタラメであると見抜けるかどうか？」という能力。

僕は一応、立場上はプログラマーなのよ。プログラマーってのは設計に従って実装することが仕事なわけだが、実際はそうはならなくて。

( ﾟДﾟ)「この設計で実装をお願いします」
(｀・ω・´)「こんな設計で良いはずが無い！！」

こんなやりとりの嵐。

設計とか要件定義とかに限らず、日常動作の全てにデタラメが混ざり込んでいる。

デタラメをデタラメであると識別してやり直しを命ずるのが僕の最大の仕事。

本来の仕事である実装なんてオマケみたいなもの。上流工程がしっかりしていれば実装なんて楽勝だし、上流工程がデタラメだったら実装工程では何ともならん。

• プログラマーのウズマスが要件定義の妥当性を検証し、
• プログラマーのウズマスが設計の合理性を検証する

何やねん、これは。(´・ω・`)

何かもう、「人間力」みたいな世界に入っちゃってて、「この人はそろそろ限界だから頼まれなくてもＨＥＬＰするべきかな？」とか思いやりみたいなものまでが僕の仕事の範疇になっちゃってて。

どうなっとる一体？(´・ω・`)

違和感

 いや、これ、ちょっとおかしいな。(；´・ω・`)

だって、休日出勤するなら朝から出勤するでしょ？　休むならずっと休む。

「夜の２０時から３０分ほど仕事して消える」なんて挙動ある？

リモートワークだから物理的にはこの挙動は出来るんだけどさ、心理的におかしくない？

• もう疲れちゃってて仕事したくない
• でもプロジェクトはピンチだから頑張らなきゃ
• だから夜の２０時になって、やっと死力を振り絞って仕事を始めた
• でも３０分くらいでもう限界になっちゃって落ちた

こういう挙動なんじゃないかなぁ、という印象。真面目な人だし。僕みたいに酒飲みながら仕事するような不良社員じゃない。しっかり者なのにこの挙動。(；´・ω・`)

でもこの生真面目なだけの凡人共が僕と同等の精神的タフネスを持っているはずが無いから、僕が「ここからが本当の戦争だ」と感じている今、他の連中にとってはギブアップ水準である可能性は、十分にある。(；´・ω・`)

自分で言うのも何だけど、やっぱり僕は何かおかしいんだよね。(´・ω・`)

僕と同じ水準だと思ったのは、前職社長、前職部長、現職社長の３人しかいなくって。
ハッキリ言って全員キチガイだよ、う～ん。(´・ω・`)

こんなキチガイ中年と健全な若い衆が同じ職場というのが無理なんや。

住み分けみたいなものを考慮しないと死んでしまうぞ。僕と社長は平気でも、それ以外の連中が(´・ω・`)

夜間始動

 若い衆が夜になってから仕事始めやがった。キッツ……。(；´・ω・`)

と言うのも、プロジェクトの遅れはかなり深刻で、休日出勤待った無しなのよ。
遅れているのはあくまで他チームであって、僕ではない。

でもプロジェクトってのは繋がっているから、他チームからの問い合わせには僕が即座に対応してあげないと、他チームが休日出勤していたところで何も出来なくなっちゃうのよ。

つまり、

「自分の仕事は終わっているかもしれないけど、他チームで何かトラブった際に即座に対応出来るようにして欲しい」

という実情に応じて本日ずっとＰＣ前にいるわけだが。

午前中にポロポロと問い合わせはあったけど、午後は何も無し。

何も無いと思って酒飲んでたら、２０：００から再始動。

キッツ……。(；´・ω・`)

お前ら……。同じ休日出勤でも日中の問い合わせと２０時の作業依頼は違うからね。

ま～、そこまで気を回す余力が無いことは理解しているが。(´・ω・`)

デザインパターン

 プログラマーではない設計者に教えるのが難しくて苦戦しているのが、チェックなのよね。(´・ω・`)

( ﾟДﾟ)「この項目は必須チェックです」
( ﾟДﾟ)「マスタを検索して存在しているかをチェックして下さい」
( ﾟДﾟ)「半角英数字チェックもお願いします」

これね～、明確に序列があるのよ。

必須チェック⇒半角英数字チェック⇒マスタ存在チェック、の順だ。

これね～、当たり前なのよ。

MVCモデル、バリデーションチェック……、言葉は色々あるんだけど、考え方の根本は同じ。

まず外から入って来たインプット情報のみでチェック（バリデーションチェック）し、それを通過した後でＤＢとの突合などのチェック（ビジネスチェック）を行う。

これは基本中の基本であり、これはWeb画面でも、WebAPIでも、ファイル入出力バッチでも、同じ。

チェックの順番には定石がある。これをデザインパターンと言う。

ただ、これが厳しいのは、そもそも何故デザインパターンというものがあるのか？
それはデザインパターンに即さなければ設計が綺麗にならないからだ。これは保守性と効率に密接に結び付く話だ。

だか、プログラマーではない設計者はデザインパターンという概念が無い。

( ﾟДﾟ)「え？　マスタチェックした後に半角英数字チェックは出来ないんですか？」

とか、そういう出来る出来ないの話をしているんじゃないんだよ。

デザインパターンに即した設計にしなければ、必然的に生産性は低く、保守性も低いシステムに成り下がる。これは常識だ。
生産性と保守性の話だ。

だが、この設計者はプログラマーではないから、デザインパターンという概念を理解していない。
だから出してくる設計書も処理の順序が滅茶苦茶である。
無論、ここは守って貰わないと実装するわけにはいかないから、こういう設計が来たら指摘して突き返している。クソ設計を拒否するのはプログラマーの職責だからな。

でもこの、「デザインパターンという概念を持っていないが、設計者ではある」、というケースが実に厄介で困っている。

もちろん突き返す時に理由は説明はするんだけど、５分や１０分の指摘で理解するのは難しいだろう。最低でも８時間くらいは勉強会開いて僕がレクチャーしないと。

でもそんな時間あるわけ無いし。

いや、プログラマーでなければ設計は出来ないと言うつもりは無いんだけど、だからと言って基礎を勉強しないままフワッと設計をやられてもね。

う～ん。(´・ω・`)

悪循環

遅延が遅延を生む悪循環に陥ってるなぁ。(；´・ω・`)

いや、例えばソースにバグがあって、修正依頼が来たとするでしょ。

僕はその日のうちに直してるのよ。でもその結果を確認する他チームの方は手が回んないから確認が後回しになっている。

その後回しも１０日も後回しになっちゃってて。

１０日前の話なんて覚えてないわな。(´・ω・`)

だから今、記録を見て過去の経緯を遡って思い出していて、あーでもない、こーでもない。１０日もあればそのバグとは別件の修正も混ざり込んでる。
意味分からんわな。仕事の遅れが更なる生産性低下を招く。

進捗率を回復したい一心なのは分かるんだけどね。(；´・ω・`)

これもやっぱり進捗管理の問題なんだけど、

(; ﾟДﾟ)「時間が無いので設計書の修正は後回しにして試験を続けます」

とかやってんのよ。

進捗管理は試験項目の消化数で管理されているから、試験項目さえ消化すれば報告上の進捗率は上がる。でも実態としては「設計書の修正を後回しにする」という進捗管理の計算に載らない部分に寄せて誤魔化しているだけ。

進捗管理の甘さから来る盲点を進捗管理やっている本人が自ら突いている。

典型的な手段と目的の逆転なのよ。

プロジェクトを正しく遂行するには、これを間違えてはいけない。管理表上の進捗率が上昇すれば、実態としての進捗が遅れていても構わない、と。
こんなことやってたら進捗管理なんてやってる意味無いし、むしろ更なる判断ミスを招く。リスクの上乗せでしか無い。

ま～、この辺が若いから分かんないんだろうなぁ。別に本人も悪気があるわけじゃなくて、進捗が遅れて焦る余りに、ついつい、という感じなのだろうが……。

ちょっと本当、介入してテコ入れしなきゃいけないんだけど、あくまで隣のチームの出来事だしなぁ。

参ったね、こりゃ。(´・ω・`)