カス営業

営業さんから「客先に説明する営業資料を作成したから、事実誤認が無いか確認してくれ」と頼まれて見たんだが。

何じゃこりゃ、カスだな～。(´・ω・`)

資料を読むとすぐ分かるんだけどね～、まるっきり、僕の言葉の横流しなのよ。

バカヤロ～。
僕の説明は技術者の立場からの内部報告であって、僕の言葉をそのまま客先に転送して良いもんじゃねえよ。

例えば、

(´・ω・`)「本件の修正を行うと、Mレポートの過去履歴の表示件数に不整合が発生します」

と僕が内部説明するじゃない？
すると、このカス営業はこういう報告書を作成するわけよ。

( ﾟДﾟ)「本件の修正を行うと、Mレポートの過去履歴の表示件数に不整合が発生することが判明致しました」

バカヤロ～。お前、何も理解せずに僕の言葉をコピペ改変しとるやろ。

この場合、Ｍレポートってのは内部用語なのよ。プログラム名が MonthlyReport.php だから略称としてそう呼んでいるに過ぎず、客先に提出している資料の名前は「営業実績月次報告書」だ。

つまり、

「どういう言葉、表現を使えば顧客にスムーズに理解して頂けるかな？」

という観点が、プログラマーの僕にはあるのに、営業には無い。

バカヤロ～。立場が逆やろが。
その辺を使い分けるのが営業の仕事だろ。

それをせずに僕に資料をレビューして貰って、何や？

(´・ω・`)「いやぁ、このような表現だと客先には伝わらないと思います。客先の要望はこうこうこういう事なので、その意を汲み取って対応プランをご提案する、というスタイルとするならば、この資料はまず用語を客先に伝わるような表現にすることに加え、このような改修を行うことで客先の業務にデメリットもある一方、メリットに繋がる部分もある、という点をお伝えしていくことが重要になるのではないでしょうか？」

こんな感じの返事を聞きたいんか？

バカヤロ～。それが営業やろが。
技術職と営業、職分の違いを分かっとるんか？

まあ、それでも答えられることは答えてあげたいんだけどね。
僕は技術職ではあるが、こういう事態に備えて営業視点、客先視点というものも備えるようにしているから。

でもね～、これってもう越権行為じゃん。

やり過ぎると「ウズマスは技術職の癖に営業に口出ししてくる」とか悪く言われる可能性もあるから、単純に実力を発揮すれば良いというタイミングとは限らない。

気付いていても敢えて口に出さないのも生存戦略の一つ。
しかし、今回の場合はこの余りにも露骨なクソ資料を見ちゃったから、

(；一_一)「ウズマスさん、これを見て何も思わなかったんですか？」

みたいな感じに、黙っていたら怠慢を糾弾される可能性もある。

• 指摘したら越権行為
• 黙っていたら職務怠慢

バカヤロ～。
クソみたいな話に巻き込みやがって！！

僕はこういう組織力学の嗅覚を要求される場面は苦手なんだ。( ；´Д｀)

まあ、苦手でもやらなきゃ生き残れないから、まあ何とかゴニョゴニョと今日のところは乗り切ったが。

叶わんな～、このカス営業は！！

４０歳か５０歳か知らんが、何をやっとるんや。

言葉の意味を自分で理解しないまま他人に連携するな！！

もう今日は萎えちゃったわい。(´・ω・`)

既存バグ

参ったなぁ。(´・ω・`)

いや、仕事で統計データ出力の改修を依頼されてるんだけどね、どう見たって数字がバグってるのよ。

過去からの時系列を順に追って毎月の数値を出すというものなんだけど、正しいデータは今月だけ。先月以前の数字はデタラメ。
しかも露骨に。

1000件と出力されるべき数字が2件とか出る。

もう２年くらい使ってるんでしょ、このシステム。
数字がデタラメなのに誰も気づかない。

「販売実績1000件と1001件」の違いを見落とすなら分かるよ？
「販売実績2件」って、全然違うがや。

殆どゼロやがや。何を見ちょるんや。(´・ω・`)

数字がデタラメでも誰も困らないような無意味な帳票ということだろう。

でもエンドユーザは誰も使っていないのに、提供者側は正しく提供する義務があると思ってる。
だから改修依頼があって、その仕様を決めなければならない。

と言ったって、仕様も何も、今既にデタラメじゃないか。

新しい要件に従っても出てくる数字はデタラメになる。

1000件と出力されるべき数字が101件とか出るに過ぎん。
意味無いがや。

これについて正しく要件定義しろって、どこから話を始めりゃええんや。

お前ら目潰れとるんか？(´・ω・`)

多忙

 急に忙しくなっちゃったな。ふう。(´・ω・`)

非プログラマー採用

我が社はまだ５人くらいしかいないけど、拡大に向けて未経験者採用もしようという風に話が進んでおる。(´・ω・`)

しかし、この手の話題でずっと疑問に思っているのが、非プログラマーの未経験者採用なのよ。

僕は僕自身がプログラマーだから分かるんだけど、未経験であってもプログラマー志望であったら、採用募集の時に言うことは決まってるのよ。

• そもそもＩＴに興味がある。興味があるから応募している。
  
• 自分なりに勉強はした。理解度はこれくらい。足らんかもしれんが勉強はした。
• 資格はこれを持ってる。持ってない資格も取るつもりはある。
• やる気はあるつもりだから雇ってくれ。

これで、素質がありそうだったら採用、センス無さそうだったら不採用だ。

プログラミング業界は、未経験者は未経験者なりに努力可能な業界なのよ。
だからそこを頑張ることがアピールポイントになる。

でも、ＩＴ業界はプログラマーばかりではないでしょ？

• 「私は要件定義がやりたいです！！」
• 「私はネットワークが大好きです！！」
• 「私はマネージメントに向いている！！」

って、こんなヤツおるんか？(´・ω・`)

この分野は実際に現場で経験を積む以外にやれること無いやろが。

経験者なら経験をアピール可能だけど、「自分はＩＴ業界未経験者だが、かと言ってプログラマー志望でもない」って人は、どういう論調で自分を売り込んでいるのだろうか？

本当に分からん。

ちょっと僕も人事に関わらなきゃいけなさそうあし、ぜひこの辺の深淵を教えて欲しいわ。(´・ω・`)

仕事無し

やることあらへんな、全く。(´・ω・`)

いや、どうも客先の受け入れが遅れているみたいでね。

そもそも要件定義も自分達では満足に出来ない人達だから我々が提案ベースで「こんな感じでどうでしょう？」と作ったシロモノ。
これを見て貰って、イマイチな部分があったら指摘を貰って直す。

その工程が今の時期だったはずなんだけど、その受け入れが全然進んでないみたいなのよね。だから指摘ゼロ、やること無し。

あの様子だと９月にズレ込みそうだな。

となると、今月はもう殆ど作業無しな雰囲気が見えて来てる。(´・ω・`)

何して過ごすかのう。(´・ω・`)

技術士セミナー口頭試験

今日から技術士セミナー再開だ～。(´×ω×`)

そもそも論文試験が受かってるかどうか分からんのだが、受かっていたら１２月に口頭試験に進むことになるから、その対策が本日よりスタート。

まあ、口頭試験の方は論文試験の時ほどハードな詰め込み勉強はしなくて良いから、肉体的な負担は論文試験より低い。

しかし、問題は精神的な負担だ。

もうね、心底、嫌になっちゃってるの。試験というものが。(´×ω×`)

受かるか、落ちるか。生と死の戦いじゃない？
どれほど僕がこの試験というものに生命力を消耗してきたことか。

基本情報や応用情報の頃とは違うんよ。
あれは、僕の実力だったら１００％受かる。１００回受けて１００回合格する。
楽勝な試験を楽勝するのは気分が良い。
だから若い頃は頑張れた。

今は違う。技術士試験はもう能力の限界に来ている。
全力で頑張って勝率５０％くらいなのよ。

いや、違うな。
自力では０％だから、セミナー業者に数十万円を支払って、指導を仰いで、ようやく５０％。

もう本当にキツいの。キツいの。かなり無理してる。(´×ω×`)
心底、もう凹みきっちゃってるの。(´×ω×`)

が、何としても、あと少し頑張らないと。
今年がダメでも来年、再来年。
話にならないほどダメってわけじゃないから、食い下がればいつかは受かる。
受かるまで継続すれば受かる。
鉄の精神力を示す時なのよ。

ここで放り投げてしまうことは、このウズマスの精神力の限界を曝け出すことになってしまうから、どんな代償を支払ってでも続けなければならん。

人間ってのは、精神力の限界を線引きしてはイカンのよ。
そこで負けた人間は人生を逃げるようになる。仕事に対してナナメに構えるようになるとか、本業を手抜きして株とかで一発逆転を夢見るようになるとか。
精神力の限界を曝け出した人間は必ず卑しい身分に堕ちる。
耐えねばならん時は耐えねばならん。

でも本音としては、もう無理無理無理無理。(´×ω×`)

心底、嫌になってる。

泣きながら勉強している感じ。(´；ω；`)

この歳になってくると、もう指導者なんかいなくて、全部自分で何とかしなきゃいけない。勉強仲間なんてどこにもいない。一人で勝手に勉強して、一人で勝手に耐えて、一人で勝手に合格し、一人で勝手に人生の戦略を考える。

もう本当に辛いの。嫌なの。(´；ω；`)

う～。(´；ω；`)

みずほ銀行、技術力の限界

ん～。みずほ銀行、また障害か。(´・ω・`)

• みずほ、信頼回復険しく　再発防止中の失態　自浄作用に疑問符

これは難しいなぁ。
僕の理解を越えている感がある。(；´-ω-`)

と言うのも、一言で障害と言っても、障害の性質ってものがあるじゃんね？

一般的に言うクソシステムは、ソフトウェアの品質が悪いという意味で使われることが多い。

例えばＤＢ設計の割り振りが下手で、その結果としてソースが劣悪になり、結果として不正な挙動をしてしまう、みたいな。

だけど、「別の人間に振り込んじゃった」とか、「利息の計算が間違ってる」とか、「画面に全然違う金額が表示されちゃってる」とか、そういうロジック的バグに起因する問題は発生していない。

つまり、ソースがダメダメであることに起因する問題じゃないわけよ。

じゃあ何かと言うと、インフラ系かつイレギュラー系だな。

• 特定の機器が故障すると全システムが使用不能になる。
  
• 障害時にＡＴＭが通帳を飲み込んだままになってしまう。
• 負荷が高まるとＤＢに遅延が発生する。

などなど。

正常系が腐ってるわけじゃない。
システムがもの凄く膨大で、各種サブシステムを組み合わせていくパズルの中に見落としが多い、ということだ。

う～ん。(；´-ω-`)
これは正直、見直ししようにも難しいものがあってね。

システムが膨大だと組み合わせが無数にあるから、「同じトラブルでも通常は大丈夫なようになっているが毎月１５日の夜間に発生した時だけアウト」みたいに時間やタイミング次第でＯＫがＮＧに変わってしまうとか、「機器故障にしても機器が丸ごと止まった場合は待機系に切り替わるが、止まるんじゃなくて挙動がおかしくなった場合は切り替えが作動しないからＮＧ」みたいに、故障と一言で言ってもどういう風に故障するかでＯＫがＮＧに変わってしまう、とか。

と、「え、そんなパターン、気付くわけないじゃん！！」ってのが発生する。

みずほ銀行の場合は、そういうのが大量に潜在しているのだろう。

無論、初期開発の時に、システム全体のカラクリをシンプルな形に整理出来ていれば、そういうのが潜在するリスクを小さくすることは出来る。
だが、みずほ銀行の場合は初期開発に失敗があって、システム全体がピタゴラスイッチみたいになっちゃってるのだろう。

だから今更どんな優れた技術者が目を凝らしても見直しし切れない深淵が生じている。

と考えると、「再発防止策」と言っても、技術的に抜本的な改善することは不可能と言って良いだろう。

よく、「みずほ銀行は第一勧業銀行・富士銀行・日本興業銀行が統合された銀行だから、その組織の対立により合理的な対応が出来ない」という組織論について触れられることが多いが、もうそういう段階ではない。

もう物理的にどうにもならんシステムがそこに存在しちゃってるの。ここで心を入れ替えて一致団結して取り組もうとしたって、技術的に手の施しようが無いわけよ。

既に過去形、戦後なんだ。

じゃあどうするかと言うと、やれることがあるとすれば、継続的リファクタリングだろうな。

つまり、

• 偶々問題に気付いたら改善する。
• 障害が発生したらその部分を改善する。

これを繰り返す。

問題が多いと言っても無限ではないから、１０年２０年と続けていれば、いずれは安定する。
こういうやり方だ。

このやり方は、通常のプロジェクトでは不可能。予算計画が立たないからね。

１年とか、２年とか、定められた期間でキッチリ終えるから予算の範囲内で収まるのであって、
「完了まで５年か１０年か分かりません」では、お金が延々と垂れ流しになってしまうから、会社が潰れてしまう。

でも、みずほ銀行に限っては、例外的にその費用の捻出が可能な希有な組織だろう。

いくらか知らんが、本来のシステム保守費用が年間１００億円で計画されていたとしたら、そのコストが３倍に増えた状態を３０年続ける、という対応も不可能ではない。

この費用はエンジニアだけじゃなく、オペレータ部門とかも含む。
例えば、システムが止まった場合、エンジニアの力では早期復旧が難しくとも、電話での問い合わせが充実していれば被害が減らせるでしょ？
いつ発生するか分からん障害の為に、必要かどうか分からん人間をキープする。

こんなのは普通の企業では無理だが、みずほ銀行の資金力なら可能だろう。

みずほ銀行に出来る「再発防止策」とは、こういう「普通に考えたら拒絶反応を示すようなやり方に社内で承認を通すこと」ではなかろうか。

みずほ銀行は組織構造の問題についても、それが改善出来れば１０年で完了、改善出来なかったら３０年で完了、とか最早そういうスケールになっちゃってるだろうな。

いやぁ、しんどいなぁ。(；´・ω・`)