• 2014年5月14日水曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

ふう

もう現場飽きた。(´・ω・`)
  • 2014年5月10日土曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

裏コマンド作戦

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

特に問題になっているのはWeb画面だ。

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


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


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

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

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

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


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


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

これを活用して、

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



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



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



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

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

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

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

これから先もSEとして長く生きていく為には、モチベーションだけは高く保っていきたいものよ。(´・ω・`)
  • 2014年5月6日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

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

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

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

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

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


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

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

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

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

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


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


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


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

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


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

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


これが一番凄い。

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

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

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


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



これ。マジこれ。

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

黒でも白と言い張る!!



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

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

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

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

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

ヤフートップニュースか、日経の「動かないコンピュータ」に掲載される日が楽しみだわ。
  • 2014年5月5日月曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

ランス9

ランス9

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

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

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

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

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

いつ発売になるか分からんが、楽しみに待っていよう。
  • 2014年5月1日木曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

発覚

衝撃の事実が発覚した。

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

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

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

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

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

しかし、だ。

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







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








ちゃんちゃん。
  • 2014年4月26日土曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

管理とは

「管理職」っていう言葉はサラリーマンやってると、何か色々議論があったりする点だと思うんだけど、
僕が考えるに、管理職の管理業務は以下2ステップだと思っている。

①現状を把握する。
②対策を取る。

で、如何にダメ管理職と呼ばれる人でも、大概は①は出来ているものだと思うんだ。


▼普通のダメ管理職:例1
①進捗が遅れており、このままだと納期に間に合わないことが分かっている。
②でも特に対策も無いので根性で残業して何とかする。

▼普通のダメ管理職:例2
①障害発生。クレームとか色々と来ていて大問題になっているという報告を受けた。
②怒るだけで有効な指示を出せない。


こんな感じ。
②の対処を行う能力が無いのがダメ管理職というのが普通。

でも、僕はこれはやむを得ない部分もあると考え、特にそういう場合でも文句は言わないようにしている。


「分かっちゃいるけど何ともならねえんだよ!!」


ってことってあるでしょ?
「しゃーねぇなぁ」くらいの感覚で、自分なりの現場努力で何とかすることにしている。

こんな風に、「②対処方法の立案、指示」が管理職の優劣のポイントだと思うんだ、普通は。



でも、今現場で問題になっているあのリーダーは①でコケている。


・業務を引き受ける。 ⇒ 忘れてた。
・仕様変更発生。 ⇒ 言って無かった。
・何をやらなきゃいけないの? ⇒ さあ……。


末端社員ならこういうパターンの人も20~30人に1人くらいいるけど、
リーダー格でありながらこれをやる人ってのは初めてだぜ!!


これをやられると何ともならんのよ。

世間ではデスマデスマって言うけど、この状況だとデスマに突入することも出来ないからな。
何すりゃいいのか分からない状況だから。

まあ、金・土でリーダー陣が再調整してくれているはずだから、
月曜からリカバリー作業に入れると期待したいところだが……。
  • 2014年4月24日木曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2014-05-14T18:31:00-07:00&max-results=7&start=7&by-date=false

タワケ

炎上しているタワケリーダーとミーティングしてきたけど、マジカスだった。

大幅仕様変更があるのを周知しないで、ずっと抱え込んでやがったぜ。

あのチームはタスク管理すら出来てなくて、「やらなければならない作業は何か」すら分かってない。

しかも仕様変更と言っても根が深い話で、その要件を実現する為に必要なデータが、現状では取得していないのよ。
だからDB設計変更、業務フロー変更というレベルで大幅手戻りになる。

一番酷い話だと思ったのが、これ。


テーブルが存在しないことに気付かないで実装している。


これ。

気付かないわけ無いんだよ。
取得元のテーブルが無い状態じゃ、その画面は物理的に成立しないだろ。

「見落とし」とか「品質管理」とかいうレベルの話じゃなくて、物理的にありえないことが起きてる。

じゃあ、何だ?
あのチームが『実装』と呼んでいるのは『サンプルHTMLの作成』のことなのか?

サンプルHTMLだけ作っててバックエンドのロジックが未着手なら、テーブルが無いことに気がつかないのも辻褄が合う。

ってことは、あのチームが全員月300時間超も労働してるのに、現状はHTML部分のみの作成しか進んでおらず、バックエンドのロジックは手を着けてないってこと?


それってもう『何もやってない』のと大して変わらないよね?


みたいな。

そんなレベルの話。


マジカス。


あのチームはもう積んでる。