読者です 読者をやめる 読者になる 読者になる

受託開発って面白いのかな?ってもやもやしてる。

ござ先輩の記事を読んで、最近もやもやしていた受託開発について書きたいと思います。正直まとまってないのですが、この「もやもや」の気持ちを気持ちを書き留めておこうと思います。

私は、IT業界に入ってから3年ほど立ち、担当レベルの仕事なら一通り覚えたかなという感じです。入社してから、何もわからず、ただ教えられるがままに仕事をする域を超えた時点で、自分に芽生えた感情が「受託って面白くないな」ということです。

何故かという、自分のやりたい仕事に就けなかったり、何となく技術が古くさく感じたり、何かを改善するにもユーザー企業と自社の間に壁があったりといくつか要因はあったと思うのですが、一番は「つくらされている感」だったのかなと思います。

受託開発ってどうも『ものつくらされ』感は否定できない。
でこの『ものつくらせれ』感ってどこから来るんだろうと自問自答していくと、結局のところ、仕事の進め方や案件の取り方などの会社的な要因が大きくて、受託開発がウンコってことには繋がらない。
受託開発しかしたことないけど言ってみる - regtan’s TechNote

ちょっと前に読んだ「受託開発の極意」の冒頭にも同様なことが記述されていました。

現場の開発者は「やらさている感」「顧客に振り回されている感」「自分の仕事が何の役に立っているかわからない感」といった目に見えにくい問題に悩んでいます。

で、なんで「つくらされてる感」「やらされてる感」を感じていたかというと、単純に「提案する」ということが出来ていなかったからなのかなと思いました。まぁ、あたりまえのこと。

ござ先輩の記事にも、こう書いてある。

僕は受託開発しかやったことがないですけど、今まで作ってきたシステムに対して深い所まで考え提案し作っていけるような仕事を与えてもらったので、受託開発でも楽しく仕事が出来るはずだと思っています。
受託開発がつまらないなんて言わせない - GoTheDistance

実際私は、要求定義という工程には参加したことがない(類似のことはやったことがあるが、やったことないに等しい)。そうか!じゃあ、要求定義から参加して、「こんな機能どうですか!」「ここは、こう作った方が運用が楽ですよ!」「このフレームワークを使うと保守が楽ですよ!」とか色々提案して、それから製造に入れば楽しんだ!と、思うのですが一筋縄ではなかなか行かなさそう。

と言うのはいわゆる要求定義を行っているのは、元請けのそれも上級職な人な感じがするからです(たぶん、これは会社の規模とか、SIerなのかソフトハウスなのかとか状況によって状況はかなり異なると思いますが)。ということで、「提案する」ってフェーズに参加できない!たぶん、これは、2次下請け、3次下請けなんて状況になると、もっと顕著なんじゃないかと思います。

自分が案件に参加した時には、もう全ての仕様は固まっていて、「この仕様は変じゃないです?いや、そういうお客さんとの契約ですから」「ここはこういう作り方のほうがメンテしやすいと思うのですが?もう契約終わってるんで、規模は増やせません」こんな状況ってありません?たぶん、これを解決するには元ネタの記事にあることかなと思います。

日本のSI業界の過酷な労働条件を改善したければ、やるべきことは労基法の改正とかじゃなくて、市場メカニズムを正しく機能させることだ。
ニッポンIT業界絶望論

ちょっと記事の意味は流れが違うかも知れませんが、結局のところIT業界の「受託」仕組み、多重下請けの仕組みを改善するとかなのかなと思ってしまうのです。

とか思いつつ、自分の出来ることから、自分の周りを少しずつ変えていくしかないんだ!っという多少マッチョな気持ちもあるのですが...

そんなかんじで、色々もやもやなのです。