ステップ数

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

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

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


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


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

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

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

ってのは別の話だよ。

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

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


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


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

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

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




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

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

と言うのも、ステップ数計測ツールってのは「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
完全に仕様が間違っている。機能として成立していない。どうやっても無理。
　　↓
仕様の拡大解釈、縮小解釈、曲解で乗り切る。


これが一番凄い。

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

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

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


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



これ。マジこれ。

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

黒でも白と言い張る！！



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

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

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

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

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

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

ランス9

ここ最近プレイしていたシミュレーションＲＰＧ「ランス9」をクリアしたぞ。

実に面白いゲームだったぜ。

内容としては、同じ会社が大昔に出した「ママトト」っていうゲームとそっくりだ。
ママトトも好きなゲームで、ランスシリーズも好きなシリーズだから、
両方合体すると僕にとってはハズレの無い名作だった。

ラスボス戦の音楽はママトト戦闘曲のアレンジで懐かしかったわ。
僕も歳を取ったのう。(´；ω；`)

このシリーズも長く続いているな。
ようやく9か。
10で完結らしいから、もう少しだな。

いつ発売になるか分からんが、楽しみに待っていよう。

発覚

衝撃の事実が発覚した。

僕が「この人、リーダー務める実力無いだろ」って思っている例の炎上チームのリーダー。

実はリーダーじゃなかった！！

サブリーダーだったらしい。

ずっとその人が仕切ってる風だからその人がリーダーだと勘違いしていたけど、
サブリーダーがピンチヒッターで凌いでいるだけだったんだ。

それなら実力が足らんのも辻褄が合うわな。納得した。

しかし、だ。

「じゃあ、本物のリーダーはどこ行ったの？」って思うだろ。







本物はもう倒れて会社に来てない。








ちゃんちゃん。