人件費削減の手段として、フィリピンに拠点作って、現地の人間雇ってデバッグ作業させるんだとか。
そんなその場しのぎの対処療法みたいなことしてないでカイゼンを図るべきだと思うんだがな。カイゼンしてから雇うことをすればもっと効果あるだろうに。
何が最も酷いかって、プログラムがスパゲティコード化してることだな。
コーディング規約なるものはあるけど、そんなもんは守って当たり前の最低限で、モジュール結合は疎結合が基本だと思うんだがの。
よほどデン○ー様が怖いのか、『まともな仕様書書いてこい。多意解釈の出来る曖昧な仕様書なんて糞だろ』くらい言えればいいのにな。
仕様書単位で関数無理矢理作ろうとしてるから今の酷さがあると思う。
勘繰った言い方をすると、デン○ー様に工数水増しするためにわざとあんな糞プログラム作ってるのかと疑いたくもなる。
『仕様通りに動けば良い』
そんな考えじゃいくら経っても工数は減らない。
可読性の良い、小規模単位の疎結合関数のプログラムにリファクトすれば工数は減るはずなんだがな。
人は雇いたくない、けど工数減らしたい。それなら工夫するのが筋だろう。フィリピンに拠点作ってそこでデバッグさせて人件費削るとか抜かしてるけどアサハカだ。その程度の対策では、発狂するフィリピン人続出すると思うがな。
プログラムの作りからして考えるべきで、やり方も工夫すべきだ。
得てしてマーカーで塗り潰しチェックとかやってるけど、どーでもいい場所指差して『ここ塗ってないけど』とか言ってる馬鹿もいるくらいだからな。
塗り潰すことが目的だと勘違いしてる馬鹿が量産されているってことだろ。
塗り潰しは手段であって目的じゃない。
人件費を削るんだったら雇う人間を変えるだけってのはその場しのぎでしかなく、カイゼンじゃない。カイゼンするんなら現場でちゃんと現物見て、何が工数のボトルネックなのか、見るべきなんじゃねーのかな。
フィリピン人に同じことを試しにさせたら日本人の６倍工数がかかってるんだと。ただでさえ日本人でも可読性が悪いと思う仕様書なのに、フィリピン人が読めるのかね。
俺はここでグチってるだけだけど、どうせ本気でやるなら現地現場現物で何が悪いのかちゃんと原因分析して、やり方を改善した上で、フィリピン人雇うなりしたほうがいいと思うんだが。人件費削減のやり方があまりにも浅はかなのでグチった記事でした。