アカウント名:
パスワード:
どうせ本当に戦闘機が飛んでくるまでは、竹槍を握った自分が如何に愚かなんて気づかないのだし。腐臭漂う日本のソフトウェア開発業界は、さっさと外力で思い切り焼き払ってもらったほうが幸せに思います。
日本のソフトウェア開発業界が本当にダメならとっくに焼き払われてると思います。発注側はとしてお金はあるので。
実際問題、商習慣と言語の壁は思ったより厚い。アジャイルのような素晴らしい開発手法を使ってることよりも、効率悪くても、今の文化で仕様が正確に伝わって、それなりの製品が作れたほうが嬉しいから残っているのではないかと。
# つまり、物理的に戦闘機が飛んできて物理的に焼き払えば実現できますね(オイ
実際問題、商習慣と言語の壁は思ったより厚い。
これだよね。結局のところポジショントークで、日本の商習慣の壁を壊せないから「日本のやり方はクソ」って言ってるだけ。それでも意識高い系の経営者とかは騙されて「よし次の社内システム更改はアジャイル開発しよう」とか考えちゃって海外企業にいいようにされる、って程度の効果はあるだろうけど。
どんな国にも面倒な商習慣とかの壁はあるから（アメリカだとヤードポンド法とか、ＥＵだと面倒な規格対応とか）別に日本に限った話じゃないんだけどなぁ。
商習慣＝安いIT奴隷での多重請負人海戦術 ですよね。 確かにアジャイルとか言われても困るだろうなぁ。上から末端まで情報が届くのに一ヶ月。しかも50%ロスとかだろうし。
ここで言ってるのはエンドユーザー側の商習慣では。どう考えても非効率な業務を変えなかったりみたいな。ERP導入でカスタマイズの嵐になったり。
ひたすらに「最初に仕様を決める手法」を否定するのは何故なんだぜ？
仕様は変化するものだからですよ。それは手法の問題では無く、環境変化や法制度の変化だったりする。
それこそイギリスがＥＵ脱退したら、その辺でも作り直しが多発するんだろうなあ。
「最初に決めた事以外を仕様として認めない手法」は否定に値しますが。。。
うちは外資系だけど日本では顧客側の要望に合わせると開発手法はウォーターフォールにせざるを得ないね。日本はミスやバグを許さない文化だから、ミスやバグが一度でも出るとそれに伴ってミスを繰り返さないためにやらなきゃいけないことが次々に増えるのがまず1つの大きな要因。ちょっとした更新作業とかも、ミスるとすごい面倒だから、評価環境で何度もロールバックしながら更新作業を繰り返し、万全な手順書作って、レビューしてリハーサル環境で顧客立会いでリハーサルして、本当それだけで最低2週間かかるし、問題（環境差分による軽微な差なども含め）が見つ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
はやく海外企業が乗り込んできてくれればよいのに (スコア:0)
どうせ本当に戦闘機が飛んでくるまでは、竹槍を握った自分が如何に愚かなんて気づかないのだし。
腐臭漂う日本のソフトウェア開発業界は、さっさと外力で思い切り焼き払ってもらったほうが幸せに思います。
Re:はやく海外企業が乗り込んできてくれればよいのに (スコア:2, 興味深い)
日本のソフトウェア開発業界が本当にダメならとっくに焼き払われてると思います。
発注側はとしてお金はあるので。
実際問題、商習慣と言語の壁は思ったより厚い。
アジャイルのような素晴らしい開発手法を使ってることよりも、
効率悪くても、今の文化で仕様が正確に伝わって、それなりの製品が作れたほうが嬉しいから残っているのではないかと。
# つまり、物理的に戦闘機が飛んできて物理的に焼き払えば実現できますね(オイ
Re: (スコア:0)
これだよね。結局のところポジショントークで、日本の商習慣の壁を壊せないから「日本のやり方はクソ」って言ってるだけ。
それでも意識高い系の経営者とかは騙されて「よし次の社内システム更改はアジャイル開発しよう」とか考えちゃって海外企業にいいようにされる、って程度の効果はあるだろうけど。
どんな国にも面倒な商習慣とかの壁はあるから（アメリカだとヤードポンド法とか、ＥＵだと面倒な規格対応とか）別に日本に限った話じゃないんだけどなぁ。
Re: (スコア:0)
商習慣＝安いIT奴隷での多重請負人海戦術 ですよね。
確かにアジャイルとか言われても困るだろうなぁ。
上から末端まで情報が届くのに一ヶ月。しかも50%ロスとかだろうし。
Re: (スコア:0)
ここで言ってるのはエンドユーザー側の商習慣では。
どう考えても非効率な業務を変えなかったりみたいな。
ERP導入でカスタマイズの嵐になったり。
アジャイルが「手法」に拘らないを標ぼうしているのに (スコア:0)
ひたすらに「最初に仕様を決める手法」を否定するのは何故なんだぜ？
Re: (スコア:0)
仕様は変化するものだからですよ。
それは手法の問題では無く、環境変化や法制度の変化だったりする。
それこそイギリスがＥＵ脱退したら、その辺でも作り直しが多発するんだろうなあ。
Re: (スコア:0)
「最初に決めた事以外を仕様として認めない手法」は否定に値しますが。。。
Re: (スコア:0)
うちは外資系だけど日本では顧客側の要望に合わせると開発手法はウォーターフォールにせざるを得ないね。
日本はミスやバグを許さない文化だから、ミスやバグが一度でも出るとそれに伴ってミスを繰り返さないためにやらなきゃいけないことが次々に増えるのがまず1つの大きな要因。
ちょっとした更新作業とかも、ミスるとすごい面倒だから、評価環境で何度もロールバックしながら更新作業を繰り返し、万全な手順書作って、レビューしてリハーサル環境で顧客立会いでリハーサルして、本当それだけで最低2週間かかるし、問題（環境差分による軽微な差なども含め）が見つ
Re: (スコア:0)
開発環境と本番環境しかないので環境差異の事本番まで考えてなかったり。
仮想化があってライセンス的にも問題ない環境も作れるのに作らない。
あきらめ入ってるから説得する人も少ないし、説得しても感情論で受け入れない人とかもいるし。
ガチガチで詳細な手順書作ってるくせにそのせいで開発環境のリハーサル回数が足りなかったり、箇条書き程度の手順書にしてみるとやはりリハーサル回数少なくてミスしてくれちゃったり。
アジャイルになれとまでは言わないけど本当に必要な事に時間割かないのをまずなんとかしてほしい。
外資かどうか関係なく、紙の重さで品質図ってるんですか？みたいな文化におかしいと気づかない。上級職が天下りポストにすぎなかったりするからなぁ。