無起動

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

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



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

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

そりゃそうだわな。


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


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


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

サビ残強要

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

あのチームは完全に崩壊しているから勤怠管理とか無茶苦茶なんだけど、
先月はとある協力会社メンバーに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チューニングすれば超高速だったはずの機能が、モチベーション低下により「動けばいいいや」ってノリで作った為に超遅くなっちまった、とか十分にある。

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

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

仕様変更厳禁プロジェクト

ＧＷも今日で終わりか。
また明日から、あのガタガタの崩壊プロジェクトを継続しなければならぬ。

あのプロジェクトの問題点だが、開発マネージメントが出来ていないっていう問題もあるけど、
ダメなプロジェクトは何をやってもダメ。

客先調整も崩壊していると僕は見ている。

どういうことかと言うと、仕様変更・要件変更の禁止という制約があるんだ。


パッと聞いただけだと、「そりゃそうだろ」って思う人も多いだろうな。
基本的に、仕様とか要件は一度決まったら軽々しく変更することは出来ない。

でもね、限度ってものがあるだろ。

仕様が間違っていることに気付いても変更出来ない。

ここまで調整出来ないプロジェクトなんて初めて聞いたわ。

▼例1
物理的に存在しない情報を画面に表示する仕様になっていた。
　　↓
その項目は常に「-」を表示する。


こんな感じ。
「物理的に存在しないんだから、画面設計を修正して項目から消せよ」ってのが当然だが、それが出来ない。
一度決めた仕様は死んでも変えない。


▼例2
もの凄く画面が遅い。
　　↓
セッション切れさえ起きなければ良い。


これも同様。
まだ負荷テストやってないけど、1クリックで何分も待たされること確実で、とても使用に耐えられない画面がある。
しかし、そんなことは一切配慮しない。
「セッション切れで落ちなければ良い」という論理で突き進む。

リリースしたらクレーム続出だと思うが、今の所は知らんぷり。


そして、一番酷いのがこれ。

▼例3
完全に仕様が間違っている。機能として成立していない。どうやっても無理。
　　↓
仕様の拡大解釈、縮小解釈、曲解で乗り切る。


これが一番凄い。

・そちらはそのようなつもりで仕様を書いたのかもしれないが、こちらはそう認識していない。

意図的にこれをやって乗り切る作戦に入っている。

そして、認識齟齬を言い張る作戦でも無理な場合、最終手段を使う。


・それは仕様書の誤記だ。誤記訂正は仕様変更ではない。



これ。マジこれ。

何が何でも仕様変更は認めない姿勢。
どうしても現状の仕様で無理な場合は、勝手に変更して「仕様変更ではない」と言い張る。

黒でも白と言い張る！！



マジでこんな調子だからな。
顧客との信頼関係が丸っきり崩壊しているものと推察される。

しかし、何でここまで仕様変更を拒否するのか。
僕が思うに、損害賠償請求を警戒しているんじゃないだろうか？

このプロジェクトはマジ裁判沙汰に突入しても不思議じゃない案件だ。
その裁判で不利な証拠を残さないよう「仕様変更」という用語だけは絶対に使用出来ない。
事情としてはそんな所なんじゃないかと僕は推測している。

何せ数千人月の超巨大プロジェクトだからな。

本気でヤバいね、これは。

ヤフートップニュースか、日経の「動かないコンピュータ」に掲載される日が楽しみだわ。