IT技術者の憂鬱TL

この世の全てのシステムがHaskellで書かれるようになれば良いのに・・・
1
ちゅーん @its_out_of_tune

技術者を信用しないユーザーが信用出来ない技術力の開発屋に開発業務を委託すると(´・ω・`)・・・やっぱ不自然だなぁ

2012-10-20 22:05:52
ちゅーん @its_out_of_tune

あとは需要の問題で、ユーザー側に出来るコボラーが居たりすると、「OOPだかなんだか知らないが得体のしれない技術でうちのシステムを動かすなんてとんでもない」って話になる。

2012-10-20 22:18:27
ちゅーん @its_out_of_tune

OOPにせよ関数型にせよ、パラダイムの抽象度が上がれば基本的に生産性も保守性も上がる。ただしそこには「そのパラダイムに対する正しい理解と設計」が、技術者レベルで必要なワケだから・・・

2012-10-20 22:24:25
ちゅーん @its_out_of_tune

リアルな話としては「SI屋に必要なのは業務知識」というのがあるかもしれないけど、本来あるべき姿じゃないよなぁと。

2012-10-20 22:25:06
ちゅーん @its_out_of_tune

業務は業務のプロフェッショナル、技術は技術のプロフェッショナルが居る、っていうのが理想形なんだろーけど、それじゃこの国でご飯は食べていけませんよーっと。

2012-10-20 22:26:33
ちゅーん @its_out_of_tune

で、面白いのは、件の上司曰く「OOPでは業務の細部をカプセル化してしまうため、手続き言語と比べて技術者が業務知識を身に付けるのが難しい」という話。

2012-10-20 22:28:34
ちゅーん @its_out_of_tune

結局、委託開発でOOPを導入する難しい所はユーザーにメリットを説明する所なんだとか。んで、先述のように「業務に精通した技術者」が出来ないから、古い体質のまま導入すると、それが原因で長期的に失敗したプロジェクトなんかもあったりするとか。

2012-10-20 22:39:57
ちゅーん @its_out_of_tune

最終的には、「ちゃんとそういう所にSEとして入って、俺が言ってるのはどういう事か理解しろ。30くらいにはPMとしてプロジェクト回せ。」とゆーお話だったので、まぁ、期待はされてるんだと思う。

2012-10-20 22:40:57
ちゅーん @its_out_of_tune

しかし「設計が無い」(否設計書)現場での仕事はもう二度としたく無いです。あれはしにます。

2012-10-20 22:54:08

おまけ

SKS rep @repeatedly

なんだこの掟はwww > "IT系奥様必見!プログラマのダンナにしてはいけない7つの掟" http://t.co/t8mmqGOG

2012-10-20 22:47:12