絶対に仕様変更できないカスシステム。
特に問題になっているのはWeb画面だ。
このWeb画面は管理者用だから一般ユーザが使うことは無いんだけど、
画面にボタンが一個足りないことが判明した。
「○○実行ボタン」をクリックすると「○○処理」が起動する。
こういう機能を実装したいんだけど、画面仕様に「○○実行ボタン」を入れ忘れたわけよ。
普通だったら対応は簡単だ。
「画面レイアウトを作るの間違えた」と連絡して、ボタンを新規で追加させて貰えば良い。
しかし、このクソプロジェクトは死んでもそういった「間違いを認める」という行為は出来ない。
つまり、今から「○○実行ボタン」を画面に追加することは出来ないわけだ。
そこで裏技が考案された。
この画面には、従来から「日付入力欄」と「△△実行ボタン」が搭載されている。
これを活用して、
・存在する日付を入力して「△△実行ボタン」を実行すると、「△△処理」が起動する。
・9999年99月99日を入力し「△△実行ボタン」を実行すると、「○○処理」が起動する。
『99999999コマンド』という脅威の裏コマンド戦術!!
こんなクソ仕様、もう知らんわw
しかし、ここまで仕様がクソだと、他の部分の品質も連動して下がるだろうな。
というのも、人間ってのは惰性で動く生き物だから、こんな感じのクソ仕様があっちこっちに入っていると、
頑張れば本来何となった部分まで手を抜くようになるに決まってるのよ。
SEにとって、モチベーションってのは非常に重要だからな。
気合い入れてSQLチューニングすれば超高速だったはずの機能が、モチベーション低下により「動けばいいいや」ってノリで作った為に超遅くなっちまった、とか十分にある。
「使用感」ってのは「設計書」とか「品質管理表」みたいに目に見えるでは余り出てこないから軽視する人も多いけど、
「他人のモチベーション下げる行為を行うヤツは知らない所で大損害かましている」ってことを知らんとイカンわ。
これから先もSEとして長く生きていく為には、モチベーションだけは高く保っていきたいものよ。(´・ω・`)
- 2014年5月10日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
裏コマンド作戦
- 2014年5月6日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
仕様変更厳禁プロジェクト
GWも今日で終わりか。
また明日から、あのガタガタの崩壊プロジェクトを継続しなければならぬ。
あのプロジェクトの問題点だが、開発マネージメントが出来ていないっていう問題もあるけど、
ダメなプロジェクトは何をやってもダメ。
客先調整も崩壊していると僕は見ている。
どういうことかと言うと、仕様変更・要件変更の禁止という制約があるんだ。
パッと聞いただけだと、「そりゃそうだろ」って思う人も多いだろうな。
基本的に、仕様とか要件は一度決まったら軽々しく変更することは出来ない。
でもね、限度ってものがあるだろ。
仕様が間違っていることに気付いても変更出来ない。
ここまで調整出来ないプロジェクトなんて初めて聞いたわ。
▼例1
物理的に存在しない情報を画面に表示する仕様になっていた。
↓
その項目は常に「-」を表示する。
こんな感じ。
「物理的に存在しないんだから、画面設計を修正して項目から消せよ」ってのが当然だが、それが出来ない。
一度決めた仕様は死んでも変えない。
▼例2
もの凄く画面が遅い。
↓
セッション切れさえ起きなければ良い。
これも同様。
まだ負荷テストやってないけど、1クリックで何分も待たされること確実で、とても使用に耐えられない画面がある。
しかし、そんなことは一切配慮しない。
「セッション切れで落ちなければ良い」という論理で突き進む。
リリースしたらクレーム続出だと思うが、今の所は知らんぷり。
そして、一番酷いのがこれ。
▼例3
完全に仕様が間違っている。機能として成立していない。どうやっても無理。
↓
仕様の拡大解釈、縮小解釈、曲解で乗り切る。
これが一番凄い。
・そちらはそのようなつもりで仕様を書いたのかもしれないが、こちらはそう認識していない。
意図的にこれをやって乗り切る作戦に入っている。
そして、認識齟齬を言い張る作戦でも無理な場合、最終手段を使う。
・それは仕様書の誤記だ。誤記訂正は仕様変更ではない。
これ。マジこれ。
何が何でも仕様変更は認めない姿勢。
どうしても現状の仕様で無理な場合は、勝手に変更して「仕様変更ではない」と言い張る。
黒でも白と言い張る!!
マジでこんな調子だからな。
顧客との信頼関係が丸っきり崩壊しているものと推察される。
しかし、何でここまで仕様変更を拒否するのか。
僕が思うに、損害賠償請求を警戒しているんじゃないだろうか?
このプロジェクトはマジ裁判沙汰に突入しても不思議じゃない案件だ。
その裁判で不利な証拠を残さないよう「仕様変更」という用語だけは絶対に使用出来ない。
事情としてはそんな所なんじゃないかと僕は推測している。
何せ数千人月の超巨大プロジェクトだからな。
本気でヤバいね、これは。
ヤフートップニュースか、日経の「動かないコンピュータ」に掲載される日が楽しみだわ。
また明日から、あのガタガタの崩壊プロジェクトを継続しなければならぬ。
あのプロジェクトの問題点だが、開発マネージメントが出来ていないっていう問題もあるけど、
ダメなプロジェクトは何をやってもダメ。
客先調整も崩壊していると僕は見ている。
どういうことかと言うと、仕様変更・要件変更の禁止という制約があるんだ。
パッと聞いただけだと、「そりゃそうだろ」って思う人も多いだろうな。
基本的に、仕様とか要件は一度決まったら軽々しく変更することは出来ない。
でもね、限度ってものがあるだろ。
仕様が間違っていることに気付いても変更出来ない。
ここまで調整出来ないプロジェクトなんて初めて聞いたわ。
▼例1
物理的に存在しない情報を画面に表示する仕様になっていた。
↓
その項目は常に「-」を表示する。
こんな感じ。
「物理的に存在しないんだから、画面設計を修正して項目から消せよ」ってのが当然だが、それが出来ない。
一度決めた仕様は死んでも変えない。
▼例2
もの凄く画面が遅い。
↓
セッション切れさえ起きなければ良い。
これも同様。
まだ負荷テストやってないけど、1クリックで何分も待たされること確実で、とても使用に耐えられない画面がある。
しかし、そんなことは一切配慮しない。
「セッション切れで落ちなければ良い」という論理で突き進む。
リリースしたらクレーム続出だと思うが、今の所は知らんぷり。
そして、一番酷いのがこれ。
▼例3
完全に仕様が間違っている。機能として成立していない。どうやっても無理。
↓
仕様の拡大解釈、縮小解釈、曲解で乗り切る。
これが一番凄い。
・そちらはそのようなつもりで仕様を書いたのかもしれないが、こちらはそう認識していない。
意図的にこれをやって乗り切る作戦に入っている。
そして、認識齟齬を言い張る作戦でも無理な場合、最終手段を使う。
・それは仕様書の誤記だ。誤記訂正は仕様変更ではない。
これ。マジこれ。
何が何でも仕様変更は認めない姿勢。
どうしても現状の仕様で無理な場合は、勝手に変更して「仕様変更ではない」と言い張る。
黒でも白と言い張る!!
マジでこんな調子だからな。
顧客との信頼関係が丸っきり崩壊しているものと推察される。
しかし、何でここまで仕様変更を拒否するのか。
僕が思うに、損害賠償請求を警戒しているんじゃないだろうか?
このプロジェクトはマジ裁判沙汰に突入しても不思議じゃない案件だ。
その裁判で不利な証拠を残さないよう「仕様変更」という用語だけは絶対に使用出来ない。
事情としてはそんな所なんじゃないかと僕は推測している。
何せ数千人月の超巨大プロジェクトだからな。
本気でヤバいね、これは。
ヤフートップニュースか、日経の「動かないコンピュータ」に掲載される日が楽しみだわ。
- 2014年5月5日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ランス9
- 2014年5月1日木曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
発覚
衝撃の事実が発覚した。
僕が「この人、リーダー務める実力無いだろ」って思っている例の炎上チームのリーダー。
実はリーダーじゃなかった!!
サブリーダーだったらしい。
ずっとその人が仕切ってる風だからその人がリーダーだと勘違いしていたけど、
サブリーダーがピンチヒッターで凌いでいるだけだったんだ。
それなら実力が足らんのも辻褄が合うわな。納得した。
しかし、だ。
「じゃあ、本物のリーダーはどこ行ったの?」って思うだろ。
本物はもう倒れて会社に来てない。
ちゃんちゃん。
僕が「この人、リーダー務める実力無いだろ」って思っている例の炎上チームのリーダー。
実はリーダーじゃなかった!!
サブリーダーだったらしい。
ずっとその人が仕切ってる風だからその人がリーダーだと勘違いしていたけど、
サブリーダーがピンチヒッターで凌いでいるだけだったんだ。
それなら実力が足らんのも辻褄が合うわな。納得した。
しかし、だ。
「じゃあ、本物のリーダーはどこ行ったの?」って思うだろ。
本物はもう倒れて会社に来てない。
ちゃんちゃん。
- 2014年4月26日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
管理とは
「管理職」っていう言葉はサラリーマンやってると、何か色々議論があったりする点だと思うんだけど、
僕が考えるに、管理職の管理業務は以下2ステップだと思っている。
①現状を把握する。
②対策を取る。
で、如何にダメ管理職と呼ばれる人でも、大概は①は出来ているものだと思うんだ。
▼普通のダメ管理職:例1
①進捗が遅れており、このままだと納期に間に合わないことが分かっている。
②でも特に対策も無いので根性で残業して何とかする。
▼普通のダメ管理職:例2
①障害発生。クレームとか色々と来ていて大問題になっているという報告を受けた。
②怒るだけで有効な指示を出せない。
こんな感じ。
②の対処を行う能力が無いのがダメ管理職というのが普通。
でも、僕はこれはやむを得ない部分もあると考え、特にそういう場合でも文句は言わないようにしている。
「分かっちゃいるけど何ともならねえんだよ!!」
ってことってあるでしょ?
「しゃーねぇなぁ」くらいの感覚で、自分なりの現場努力で何とかすることにしている。
こんな風に、「②対処方法の立案、指示」が管理職の優劣のポイントだと思うんだ、普通は。
でも、今現場で問題になっているあのリーダーは①でコケている。
・業務を引き受ける。 ⇒ 忘れてた。
・仕様変更発生。 ⇒ 言って無かった。
・何をやらなきゃいけないの? ⇒ さあ……。
末端社員ならこういうパターンの人も20~30人に1人くらいいるけど、
リーダー格でありながらこれをやる人ってのは初めてだぜ!!
これをやられると何ともならんのよ。
世間ではデスマデスマって言うけど、この状況だとデスマに突入することも出来ないからな。
何すりゃいいのか分からない状況だから。
まあ、金・土でリーダー陣が再調整してくれているはずだから、
月曜からリカバリー作業に入れると期待したいところだが……。
僕が考えるに、管理職の管理業務は以下2ステップだと思っている。
①現状を把握する。
②対策を取る。
で、如何にダメ管理職と呼ばれる人でも、大概は①は出来ているものだと思うんだ。
▼普通のダメ管理職:例1
①進捗が遅れており、このままだと納期に間に合わないことが分かっている。
②でも特に対策も無いので根性で残業して何とかする。
▼普通のダメ管理職:例2
①障害発生。クレームとか色々と来ていて大問題になっているという報告を受けた。
②怒るだけで有効な指示を出せない。
こんな感じ。
②の対処を行う能力が無いのがダメ管理職というのが普通。
でも、僕はこれはやむを得ない部分もあると考え、特にそういう場合でも文句は言わないようにしている。
「分かっちゃいるけど何ともならねえんだよ!!」
ってことってあるでしょ?
「しゃーねぇなぁ」くらいの感覚で、自分なりの現場努力で何とかすることにしている。
こんな風に、「②対処方法の立案、指示」が管理職の優劣のポイントだと思うんだ、普通は。
でも、今現場で問題になっているあのリーダーは①でコケている。
・業務を引き受ける。 ⇒ 忘れてた。
・仕様変更発生。 ⇒ 言って無かった。
・何をやらなきゃいけないの? ⇒ さあ……。
末端社員ならこういうパターンの人も20~30人に1人くらいいるけど、
リーダー格でありながらこれをやる人ってのは初めてだぜ!!
これをやられると何ともならんのよ。
世間ではデスマデスマって言うけど、この状況だとデスマに突入することも出来ないからな。
何すりゃいいのか分からない状況だから。
まあ、金・土でリーダー陣が再調整してくれているはずだから、
月曜からリカバリー作業に入れると期待したいところだが……。
- 2014年4月24日木曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
タワケ
炎上しているタワケリーダーとミーティングしてきたけど、マジカスだった。
大幅仕様変更があるのを周知しないで、ずっと抱え込んでやがったぜ。
あのチームはタスク管理すら出来てなくて、「やらなければならない作業は何か」すら分かってない。
しかも仕様変更と言っても根が深い話で、その要件を実現する為に必要なデータが、現状では取得していないのよ。
だからDB設計変更、業務フロー変更というレベルで大幅手戻りになる。
一番酷い話だと思ったのが、これ。
テーブルが存在しないことに気付かないで実装している。
これ。
気付かないわけ無いんだよ。
取得元のテーブルが無い状態じゃ、その画面は物理的に成立しないだろ。
「見落とし」とか「品質管理」とかいうレベルの話じゃなくて、物理的にありえないことが起きてる。
じゃあ、何だ?
あのチームが『実装』と呼んでいるのは『サンプルHTMLの作成』のことなのか?
サンプルHTMLだけ作っててバックエンドのロジックが未着手なら、テーブルが無いことに気がつかないのも辻褄が合う。
ってことは、あのチームが全員月300時間超も労働してるのに、現状はHTML部分のみの作成しか進んでおらず、バックエンドのロジックは手を着けてないってこと?
それってもう『何もやってない』のと大して変わらないよね?
みたいな。
そんなレベルの話。
マジカス。
あのチームはもう積んでる。
大幅仕様変更があるのを周知しないで、ずっと抱え込んでやがったぜ。
あのチームはタスク管理すら出来てなくて、「やらなければならない作業は何か」すら分かってない。
しかも仕様変更と言っても根が深い話で、その要件を実現する為に必要なデータが、現状では取得していないのよ。
だからDB設計変更、業務フロー変更というレベルで大幅手戻りになる。
一番酷い話だと思ったのが、これ。
テーブルが存在しないことに気付かないで実装している。
これ。
気付かないわけ無いんだよ。
取得元のテーブルが無い状態じゃ、その画面は物理的に成立しないだろ。
「見落とし」とか「品質管理」とかいうレベルの話じゃなくて、物理的にありえないことが起きてる。
じゃあ、何だ?
あのチームが『実装』と呼んでいるのは『サンプルHTMLの作成』のことなのか?
サンプルHTMLだけ作っててバックエンドのロジックが未着手なら、テーブルが無いことに気がつかないのも辻褄が合う。
ってことは、あのチームが全員月300時間超も労働してるのに、現状はHTML部分のみの作成しか進んでおらず、バックエンドのロジックは手を着けてないってこと?
それってもう『何もやってない』のと大して変わらないよね?
みたいな。
そんなレベルの話。
マジカス。
あのチームはもう積んでる。
- 2014年4月21日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
キレ専リーダー
他チームの命運がマジやべえッ!!
我がチームが毎日平均2時間残業という、忙しいながらもコントロールされた状態にあるのに対し、
同僚が入っている他チームの方は23:30まで残業、土曜日も同様、という有様。
完全に暴走状態。
一体どうしたことかと思っていたが、ようやく真相が分かってきた。
・単純に納期が近くて忙しい。
・チームリーダーに管理能力が欠如している。
・チームリーダーの人間性に問題がある。
このトリプルアタックだ!!
あのチーム、まず5月に一回顧客に出さなきゃいけないモジュールがあるらしくて、それを作るのに忙しくなっているわけだけど、問題はその管理状態だ。
納品までにどれだけの作業を行えば良いのか不明。
この有様らしい。
都度、「はい、次これ」「次これ」と作業が出てくるばかりで、結局全部でどれだけやればいいの、みたいな管理や整理が完璧に崩壊している!!
だから進捗が遅れていることは分かっても、どれだけ遅れているのかは分からない。
よっぽどのタワケがリーダーをやっているものと思われる。
で、そのリーダーなんだけど、性格が悪いんだ、これが。
・短気
・嫌み
・粘着質
こんな感じの印象。
ネチネチネチネチ……。
不機嫌さを露骨に顔に出しつつ、しかも声が大きい。
近くで聞いているだけの僕が「鬱陶しいッ!!」「やかましいッ!!」って怒鳴りつけたくなるわッッッ!!
しかも話している内容が「SVNにコミットを忘れて休日出勤した作業が消えた」とかそんなレベル。
「ちゃんと言えよッ!!」とかって怒鳴ってるけど、部下からの報告が滞るのはアンタと話したくないからだよ。
で、コミュニケーションが滞った果てにミスってデータ消失。
マジアホかいな。
キレるだけで管理能力の無いリーダー。
ガチでこれだわ。
こんな無能な人がどうやってリーダー職まで昇ったのかと不思議でたまらんが、社内での出世には業務能力とは別のテクニックでもあるってことか?
それとも、一人で作業やってる分にはいいけど協調性が全然無くて管理職は全然務まらない、みたいな偏った人ってことなのか?
そこまで詳しくは知らんけど、あの様じゃどうせモジュールの品質もボロボロなんだろうな。
多分、「自分の任期である開発フェーズだけ誤魔化せばOK。以後の保守は知らん」みたいなノリでやってんじゃないかと思うけどね。
低スキル人材大量投入に加えてリーダー層にもアホが混ざってるとか、
いや、本当にとんでもないプロジェクトだな、こりゃ。
我がチームが毎日平均2時間残業という、忙しいながらもコントロールされた状態にあるのに対し、
同僚が入っている他チームの方は23:30まで残業、土曜日も同様、という有様。
完全に暴走状態。
一体どうしたことかと思っていたが、ようやく真相が分かってきた。
・単純に納期が近くて忙しい。
・チームリーダーに管理能力が欠如している。
・チームリーダーの人間性に問題がある。
このトリプルアタックだ!!
あのチーム、まず5月に一回顧客に出さなきゃいけないモジュールがあるらしくて、それを作るのに忙しくなっているわけだけど、問題はその管理状態だ。
納品までにどれだけの作業を行えば良いのか不明。
この有様らしい。
都度、「はい、次これ」「次これ」と作業が出てくるばかりで、結局全部でどれだけやればいいの、みたいな管理や整理が完璧に崩壊している!!
だから進捗が遅れていることは分かっても、どれだけ遅れているのかは分からない。
よっぽどのタワケがリーダーをやっているものと思われる。
で、そのリーダーなんだけど、性格が悪いんだ、これが。
・短気
・嫌み
・粘着質
こんな感じの印象。
ネチネチネチネチ……。
不機嫌さを露骨に顔に出しつつ、しかも声が大きい。
近くで聞いているだけの僕が「鬱陶しいッ!!」「やかましいッ!!」って怒鳴りつけたくなるわッッッ!!
しかも話している内容が「SVNにコミットを忘れて休日出勤した作業が消えた」とかそんなレベル。
「ちゃんと言えよッ!!」とかって怒鳴ってるけど、部下からの報告が滞るのはアンタと話したくないからだよ。
で、コミュニケーションが滞った果てにミスってデータ消失。
マジアホかいな。
キレるだけで管理能力の無いリーダー。
ガチでこれだわ。
こんな無能な人がどうやってリーダー職まで昇ったのかと不思議でたまらんが、社内での出世には業務能力とは別のテクニックでもあるってことか?
それとも、一人で作業やってる分にはいいけど協調性が全然無くて管理職は全然務まらない、みたいな偏った人ってことなのか?
そこまで詳しくは知らんけど、あの様じゃどうせモジュールの品質もボロボロなんだろうな。
多分、「自分の任期である開発フェーズだけ誤魔化せばOK。以後の保守は知らん」みたいなノリでやってんじゃないかと思うけどね。
低スキル人材大量投入に加えてリーダー層にもアホが混ざってるとか、
いや、本当にとんでもないプロジェクトだな、こりゃ。
登録:
投稿 (Atom)