• 2014年5月6日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/2014/05/blog-post_6.html

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

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

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

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

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


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

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

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

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

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


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


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


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

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


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

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


これが一番凄い。

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

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

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


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



これ。マジこれ。

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

黒でも白と言い張る!!



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

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

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

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

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

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

3 件のコメント:

天野 さんのコメント...

開発側は顧客の指示に従ったということにして、受け入れテストの段階で湧き出る障害に対して、「仕様通り。変えるなら金払え!」で戦う気なんだな…
開発段階で変えてしまうと、
 プロが設計したのに間違っていた。
 →自分で気づいたんだから、金は出さない。
  →他も見なおせ。
になるから、死んでも認めない感…
たしかに、顧客との信頼関係が壊滅しておる(´・ω・`)

kakkou さんのコメント...

何そのSE初級者が考えたような・・・・・・
そんなの一般に出してもすぐに廃れるわ
開発委託先との信頼関係が無い
→低レベルのものしか作れない
→最終的には一般顧客から廃れる
ってレベルじゃ・・・・・・
これ、製造部とそれ以外の部署との
信頼関係がまるで無い
今のパート先と重なる・・・・・・
正直、そんなとこなら
技術員全員撤退させればいいのに

ウズマスターRYU さんのコメント...

一度入った以上は撤収は難しいんだけど、要員追加には応じないという姿勢はある。
詳しくは知らんが、みずほ銀行なんか、そういうイメージだな。
動かないコンピュータに載ったらいい思い出になる。