ＤＢ設計無視

このプロジェクトも、結合テストに入ろうかというフェーズに来ている。

要件定義も未完成なのに結合テストってんだから崩壊は確実だが。。。

ともかく、チーム間で作ったモジュールを結合させるフェーズに来ている。


で、カスチームの問題が飛び火しそうな。。。。

カスチームは画面開発チームなんだけど、『ログイン出来ない』のよ。


ログを見てみると、「テーブルがありません」って出てくる。


(・3・)「あるぇー。ＤＢ構築ミスったかな？」


まあ、普通はこう思うわな。
環境作ったばかりで初めての試運転だから、「create table」をミスったんじゃないかとか、そんな風に思う。
最初はそれだけだと思ったんだよ。


でも違った。


環境構築は正しく出来ている。カスチームが間違っている。

しかし、なぜロジックが間違っているとかいう話ではなく、「テーブルがありません」などという環境問題っぽいログが出てくるのか？

ＳＱＬが間違っている？
全然テストしてない？



違う違う違う。

ＤＢ設計を勘違いしている！！




このプロジェクトは要件が不安定だから、ＤＢ設計がコロコロ変わっているのよ。
それ自体が問題ではあるけど、実装側としては合わせて行くしか無いわな。

「ＤＢ設計が変わりました」っていう通知が来たら、作業を手戻りしてＳＱＬを直す。

そういう三歩進んで二歩下がるみたいなやり方で開発を行っている。


でも、カスチームは「ＤＢ設計変更を無視してた」んだよ！！

ＤＢ設計変更通知を無視して、最初の頃の古いＤＢ設計のままでず～っと開発していた。

だから、結合テストの段階で最新ＤＢ設計を適用した途端、「テーブルがありません」とか出てくる。

そりゃそうだ。仕様変更でそんなテーブルは消滅してるんだから。

テーブルは無い。ビューも無い。カラムも無い。主キーも違う。



それってもう、モジュールとして成立してないだろ。

バグとか品質とかってレベルじゃねえよ。

何考えとるん？(´・ω・`)



どうやらあのチームは、何の意味も無い作業の為にデスマしていたようだな。
どれだけの工数をドブに捨てたんだろうか？

そしていつ結合テストは始まるのだろうか？(´・ω・`)

無起動

カスチームの作った画面が起動しねえ。

テーブルが無いだの、カラムが無いだの、カケラも動かん。



事情を聞いてみたところ、どうも「ＤＢ設計変更を無視してた」だけではなくて、「勝手にテーブルを作ってた」ってのもあるらしかった。

ＤＢ設計を担当しているＤＢチームに連絡しないで、画面チームのローカルＰＣだけに勝手にテーブル作って、いざ結合テストに入ったらテーブルが無いという状況。

そりゃそうだわな。


その修正が追いつかなくて、画面チームだけモジュールが起動出来ず、結合テスト出来ない状況だわ。
完全にボトルネックと化した。


とにかく、画面が動くのを待っていると作業が一歩も進まないから、急遽僕が画面の代役を果たすドライバーを作って疎通確認を始めることになった。


先が思いやられるお。(´・ω・`)

サビ残強要

またあのカスチームが問題起こしてくれたわ。(´・ω・`)

あのチームは完全に崩壊しているから勤怠管理とか無茶苦茶なんだけど、
先月はとある協力会社メンバーに70時間もサービス残業させてたんだ。

プロパーではなく、協力会社にサービス残業させる。

これをやられると、協力会社側では経営問題に発展するのよ。

プロパーにサビ残させるのはブラック企業とかそういう話だけど、
協力会社にサビ残させるとなると、ビジネスとして成立しなくなっちまうわけよ。
全然違う次元の話なの。


だから、協力会社から大クレームが入ったんだな。

契約以上の稼働を要求するなら、契約を見直せって。


そしてカスチームリーダーの結論。


サービス残業しない協力会社は契約を打ち切る。


マジかよ、これ。(´×ω×`)

まあ、もちろんこんな言い方は直球な言い方はしていなくて、表向きには「能力が無い」って言うんだ。

ガンガンにサビ残して働いていた頃には何も言わなかったのに、会社としてサビ残拒否の姿勢を示したら、
掌を返して「こいつ使えねー」とか言い出す。



ホント最低だな、こりゃ。(；´・ω・`)



で、契約打ち切りは5月末日。って、あと10日しか無いやんけ。(´×ω×`)

これって正式な企業間の契約だからな。

そんな無茶苦茶な話が通るわけないから、これから営業ルートでバトルになるだろうな。
もっと早く言ってくれれば調整ついただろうに、後手後手の対応でただ揉めるだけという……。


でも、協力会社側としては「もうこんな会社とは取引やめろよ」って方向に進んでいるから、
5月末日は無いにしても契約解除は濃厚だろう。

そして、代わりの補充は無い。

『協力会社の代わりなんかいくらでもいる』っていう優位な背景があって切り捨てるのではなく、もうこんな現場に入ってくれる会社なんて無いのに切っちゃうっていう。

何考えとるん？(´・ω・`)


一応、空いた穴はプロパーで埋めるみたいなこと言ってるけど、要するにもう既にパンパンに残業している別チームのプロパーを引き抜くってわけだから、チームを超えて大迷惑だわな。


あのリーダーは、とことんまで自分のこと、しかも目先のことしか考えられないと見える。

っていうか、そもそもリーダーじゃないんだけどね、あの人は。
本物のリーダーはもう倒れていて会社に来てない。

今リーダーっぽいポジションにいるのは、ただ歳を取っただけの頭の悪いおっさんなのよ。

本物のリーダーが倒れたから、高齢ってだけで代理に収まったんだな。
もちろん能力は並以下のゴミだからプロジェクト炎上に収拾がつかない。


今回の契約解除の一件も、多分性格が悪いとか非道とかいう以前に、単に頭が悪いだけなんだと思う。

複雑で多様な社会の様々な事象に配慮するだけの知性を持ち合わせておらず、
ただただ無意味に非常識な事を延々と繰り返すだけ、っていうイメージ。



しかし、あのチームはもうゲームオーバーしているから、今更何人抜けようと関係無いか。
もっと問題を大きくしてくれた方が、リセットが早まって良いとさえ思う。(´・ω・`)

ステップ数

また炎上チームを偵察してきたけど、実装作業ではなくドキュメント作りしていた。

作成ドキュメントは「機能毎のステップ数」だ。

僕はこの「ステップ数」というのを眉唾モノと思ってるんだけどね。


高スキル者が作ればステップ数は減る。
コピペ野郎が作ればステップ数は激増する。


これを「システムの規模の指標」とするには実態と合わない。

まあ、評価する側からしてみれば数値評価が必要なのは分かるけど、

『実態と乖離していても構わないから何でもいいから数字出せ』

ってのは別の話だよ。

僕はこういう『嘘数字』ってのが非常に気になる。

ＳＥでは無い人でも、『会社への貢献度を、業務成績ではなく、残業時間で評価する』のと似たような行為と考えてくれれば分かり易いだろう。


後々の品質指標として「ステップ数/テストケース数」の計算を行うには必要だけど、システム規模を計るには役に立たんと思うのよ。


とは言え、数字は数字で正確だから、見る人が見れば参考にはなる。
例えば、僕みたいなプログラマーであれば、仕様からステップ数を予測出来る。
それと比較して、提出されたステップ数が妙に多い場合は「きっとコピペ連発のカスソースなんだろうな」と察しをつけられるわけさ。

しかし、実態として、そんな分析は行われないだろう。
多分、どこぞの報告書に「ステップ数：ＸＸＸＸＸ」と書いて終わり。
その数字については誰も見ない。見たとしても実態に則していない。

こんな意味の無い作業に工数を費やす愚かさよ。




ここからがオチなんだけど、上の記事を読んで、読者の人は「ステップ数計測ツールでステップ数を自動計測している」と思っとりゃせんか？

違うのよ。目視計測なの。

と言うのも、ステップ数計測ツールってのは「Javaのクラス単位でステップ数を算出する」機能でしょ？
でもあのチームが作っているのは「機能単位のステップ数の一覧表」なのよ。

だから、単純に計測ツールでザッと計測することが出来ない。

「この機能で使っているのは、このクラスのこのメソッドだから、このメソッドの部分のステップ数を数えて、こっちの別機能に加算して、そのうちコメントアウトになっている部分は･･････」

みたいに、「ツールを使える所は自動ツール、使えない部分的は目視計算」というやり方なの。


こりゃ時間掛かるわな！！


で、ソースや設計はゴミだけど、そのドキュメントは凄い綺麗に書いてあんのよ。
あれは本当に綺麗。
僕はあんな綺麗なドキュメントを書いたことが無い。
綺麗なドキュメントの例として使えるくらい綺麗。

もちろん綺麗なドキュメントを書くには時間が掛かるから、このドキュメント作成に2日3日を費やしている。


実装が月単位で遅れてるのに、嘘ドキュメント作成に数日費やすっていうね。


嘘ドキュメントは上手に作ってあるからタチが悪い。

今でも客先は、このプロジェクトが順調に進んでいると思っているけど、
結合テストの段階で「実は半年遅れてました」みたいなことが露見することにだろう。

その時にどんな泥沼の裁判が待っているのか、僕が知るはずも無い。

カスソース

炎上している画面チームのソースを拝見してきたけど、マジカスだったな。

『Struts1』の画面なんだけど。

そもそも、Struts1ってサポート終了していて、脆弱性も見つかってるけど対応してないのよ。
何でそんな脆弱性入りの古いライブラリを今回の新規プロジェクトに導入したのか、そこがまず分からん。

多分、10年前のスキルしか無い無意味に年齢だけ重ねたタワケが「昔、自分が使ったことあるから」とかいう理由で選んだんだと思うが……。

で、次にソースを見たけど、『継承』って概念が無いの。
ってことは、必然的にコピペ乱射ソースになるわな。

次にjspだが、tilesが無いんだよ。
だから全jspにヘッダーとフッターをコピペしている。
で、ヘッダーかフッターが変わったら、全員で総力を上げて再コピペする戦術。
基本、全部コピペ戦術。

さらにそのjspのソースもチラッと見たけど、JavaScriptがやたらと多い。
僕はあの画面の仕様知ってるけど、あんなに大量なJavaScriptが必要なはずが無いのよ。

多分、他の画面のJSファイルを丸ごとガボーッとコピーして、うち使っているメソッドは1コだけ。
残りは単なるゴミとか、そんな感じだと思う。

しかもコピペどころか、同じソースを何度も作ってる。

ゴミソースのせいでソース量が膨大になってて、コピペしたくてもどこからコピペしたらいいのか見つからない。
もしくは、コピペ元になるようなソースがすでに存在していることに気付かない。

だから複数人で同じような機能をそれぞれコーディング。

無駄。全くの無駄。

何もかもガタガタのカスソースだから、品質も絶対ボロボロに決まってるし。
コピペでやってるから同じテストを何度も行うことになり、同じく修正にも本来の何倍もの時間を要するだろう。

現在の実装フェーズですでに大炎上しているが、工程が後になるにつれて、どんどん状況が悪化していくと思われる。


とまあ、今回は色々とソースの不備について書いたけど、
結局、最も問題なのは仕様が不明確 or 理解しないまま実装しているってことだろうな。

必死にデスマして単体テストを終わらせた後、結合テストに入った段階で全然違う物を作っていたことが発覚ってパターンになるだろう。


まあ、あのチームは完全に積んでるから、今更こんな状況を知っても「やっぱりね」ってだけの感想でしか無いが。


僕としては、あんなゴミをリリースすると数十年に渡って国益を損なうことになるから、
早急にクラッシュさせて計画見直しとして欲しいね。

ふう

もう現場飽きた。(´・ω・`)

裏コマンド作戦

絶対に仕様変更できないカスシステム。

特に問題になっているのはＷｅｂ画面だ。

このＷｅｂ画面は管理者用だから一般ユーザが使うことは無いんだけど、
画面にボタンが一個足りないことが判明した。


「○○実行ボタン」をクリックすると「○○処理」が起動する。


こういう機能を実装したいんだけど、画面仕様に「○○実行ボタン」を入れ忘れたわけよ。

普通だったら対応は簡単だ。
「画面レイアウトを作るの間違えた」と連絡して、ボタンを新規で追加させて貰えば良い。

しかし、このクソプロジェクトは死んでもそういった「間違いを認める」という行為は出来ない。

つまり、今から「○○実行ボタン」を画面に追加することは出来ないわけだ。


そこで裏技が考案された。


この画面には、従来から「日付入力欄」と「△△実行ボタン」が搭載されている。

これを活用して、

・存在する日付を入力して「△△実行ボタン」を実行すると、「△△処理」が起動する。
・9999年99月99日を入力し「△△実行ボタン」を実行すると、「○○処理」が起動する。



『99999999コマンド』という脅威の裏コマンド戦術！！



こんなクソ仕様、もう知らんわｗ



しかし、ここまで仕様がクソだと、他の部分の品質も連動して下がるだろうな。
というのも、人間ってのは惰性で動く生き物だから、こんな感じのクソ仕様があっちこっちに入っていると、
頑張れば本来何となった部分まで手を抜くようになるに決まってるのよ。

SEにとって、モチベーションってのは非常に重要だからな。

気合い入れてSQLチューニングすれば超高速だったはずの機能が、モチベーション低下により「動けばいいいや」ってノリで作った為に超遅くなっちまった、とか十分にある。

「使用感」ってのは「設計書」とか「品質管理表」みたいに目に見えるでは余り出てこないから軽視する人も多いけど、
「他人のモチベーション下げる行為を行うヤツは知らない所で大損害かましている」ってことを知らんとイカンわ。

これから先もＳＥとして長く生きていく為には、モチベーションだけは高く保っていきたいものよ。(´・ω・`)