アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
要求を獲得できないし、要求を仕様化できない (スコア:1, すばらしい洞察)
何につけても、要求の獲得ができないPMがいて、仕様を確定できない日本のソフトウェアの仕組みじゃないかと思っていたりします。
仕様を確定できないんで、アウトソースに対しても、オフショアに対してもうまく成果があげられないんですよね。
派遣に対して責任を擦り付けるのはどうかと思ったりします。
# 特に今のソフトウェア産業を今の状態に導いた人はそう思って自己納得するしかないかも。
Re:要求を獲得できないし、要求を仕様化できない (スコア:2, 興味深い)
と言うか、「仕様があるのが当たり前である」と考える時点で終わっているのかも知れません。
この業界でよく言われるのは、
「欧米はシステムに合わせて業務を最適化するが、
日本は業務に合わせてシステムを最適化する。」
と言うことですかね。
日本の場合、明文化されていない業務まで無理矢理システムに押し込もうとするので、
いらないものまで仕様書に反映せざるを得なくなり、
かつ後で見つかって手戻りなんかが発生したりするから、
期間もコストも莫大にかかる(=システム化する意味が薄い)んだとか。
欧米はパッケージ買ってきて業務変えちゃうのでその辺りは素早い。
発注者側にもそうした意識があるのと無いのとでは、
手に入るものが全然変わっちゃいますから…。
#日本人は「一品モノ」大好きなので難しいかもしれませんが。
Re:要求を獲得できないし、要求を仕様化できない (スコア:1)
ACでやっちゃった。
業務にあわせてシステムを最適化するのは、悪いことじゃないと思いますよ。
XPなんかでも変化を許容せよと言いますし、CMMIなんかでもそういうのは十分許容しています。
どんだけ完璧に仕様を作っても、後で技術的な制約とかで手戻りは出るのは、私は仕方ないと思っています。
でも、その波及がどれほどに及ぶかを設計することをしないので、雪達磨式に色々増えていくんですよね、これが。
トレーサビリティ・マトリックスという言葉を知っていると、そういう現場は少し幸せになれるんですが。
>欧米はパッケージ買ってきて業務変えちゃう
日本でもこれはよくやりますし、ベースラインになるプロダクトからの派生開発も盛んですね。
ところが、派生開発の意味をよく知らないので、発生がいわゆる「手戻り」方式になるから、結局大変で収拾がつかなくて、現場的には最初から作り直すってなことをやっているのが現実だったりします。
最初から作り直すのも、リファクタリングとかになればいいんですが、そんな言葉を知らない現場がほとんどなので、デスマーチってな不幸な現実に直面したりするんですね。
仕様がないよ文化だもの (スコア:0)
その場その場で勝手に破るのもアホみたいに厳守させるのも日常茶飯事。
重視されるのはルールじゃなくて、それを恣意的に運用する権力、それが日本の文化。
目的に合わせた適切なルールを定めて運用するなんて習慣が無いからその能力もない、それが普通。
コンピューターに限った話じゃない。