なんか下の増田がバズってたので乗っかってブクマ稼がせてもらいますね。
5年いた富士通を退職した理由
https://anond.hatelabo.jp/20190326233147
自分は2010年から2014年頭までの4年弱勤めてました。
担当業務はスパコンのミドルウェア開発。まあ、いわゆるスパコン京とかのやつですね。
詳しくは以下の退職エントリ参照
https://ryogrid.hatenablog.com/entry/20140120
で、書いてある内容だけど、多分嘘ではないのでしょう。開発機とかは確かに似たようなもんだったし。でも、自分の場合は、どうせ、SSHで開発用のサーバとかに入ってEmacsとかでコード書いてたのでスペックとか別にどうでも良かった。
というか、どこらへんの部署にいたか書いてないのでなんとも言えないというのが正直なところ。
せめて、事業部か、SI部門か、研究所か、それぐらいは書いてくれないと。
職種もよくわからんし。
あと、富士通もでかい組織なので、部門ごとに文化とか全然違ったりするし、みんなこれと同じ環境だと認識されると、さすがになあという気はする。これは大企業全般に言えることだと思いますが。
一方で共感する部分もいくつかある。新しい技術の導入に積極的でないとか、なんだとかはその通りだと思うし、みんな内向きで、プライベートで新たな技術について情報を摂取して研鑽する、ってなことをあまりしないというのも、まあ確か。でも、そうでない人もたくさんいます。ただ、まあ、そういう人はいずれ辞めちゃうんだけどね。。。
開発基準？うんぬんは自分は知らないですね。品質管理のためのドキュメントをやたら書かされるのは確かだけど、まあ、エンタープライズの世界なのでしゃあない。
椅子だの机だのは普通でした。良くもなければ悪くもない。
バージョン管理もちゃんとしてましたよ。チームによって微妙に違ったりとかしたけど、Subversionぐらいは普通に使ってたし、導入に前向きな人がいるチームとかはgitとか使ってた。
ビルドは普通にmakeです。
あと、ウォーターフォールをやたら叩いてますが、重要なのはプロジェクトの性質や規模に合った開発プロセスを選択することです。大人数で回すでかいプロジェクトでアジャイルとかやったら、終わりますよ？
(ただ、細分化されたチームの中でアジャイル的なものを組み合わせる形で取り込むのはアリです。自分もスクラムを導入したりしましたし)
ま、想像するにこの方はSI部門だったんじゃないかなあ。
で、そうだとしたら、大企業のSI部門なんて、どうせ、どこもクソだし、まともにエンジニアリングしようなんて、そもそも無理なんで、新たな職場で頑張ってください。
あと、学生時代に、記事に書いたような事態になることはちゃんと情報収集してれば十分知り得たはずなので(さすがに中途の人じゃないよね？) 、あなたも自分の進路選択の失敗について我が身を振り返って、今後に活かしてください。
以上。
今後のご活躍をお祈りします。
追記: （ブコメに負けたと思われると癪なので、追記部分以外はいじっていません）
つい、仕事を終えて疲れているところで、言及先の記事を目にして、古巣を不当に？過剰に？ディスられていたので、脊髄反射で書いてしまい、汚い言葉を使ったり、本音が漏れてしまったりしてしまいました。
で、ブクマのコメントとか見るとマウントとろうとしているとか言われているのですが、それは否定しておきます。職業に貴賤なし、ではないですが、SIをやってる人間より、まあこの記事の話に限定すれば、スパコンのミドルウェア開発をしている人のほうがすごいとか、えらいとか、そういうことは思っていません。
ただ、現在のSI業界の現場が、特に、大企業に連なる、ITゼネコン？なんて言われてしまうような、多層構造(もっと適当な言葉がある気がする)の中の現場がよろしくないとは認識していて (聞いた話やらなんやらを総合して)、上の文章は、そういうことを汚い言葉で書いてしまったということです。
例えば、開発プロセスだのという観点で言えば、同じSIでも、大企業が受注するようなものと比べれば相対的に小さめな規模のプロジェクトだとは思いますが、ユーザ企業と密に連携し、アジャイル的な手法を使ってイテレイティブに開発を行うことで、より短納期(手戻りを減らすことで)で、よりニーズにマッチした成果物を提供していくといった、新たなモデル？を模索しているようなベンチャーなんかがあることも知っています。その企業は、開発のための人材は全て自社で抱えて、いわゆる下請け企業に投げるといったことはしません（私が知っている限り）。基本的に一次請けだけやっているはずなので、社員一人あたりでみた時の収益もそれなりにあると思います。したがって、労働環境も少なくとも言及先の増田に書いてあるようなことはないはずです。
ただ、これをやるためにはユーザ企業側(発注元)の理解が必須で、単にアジャイルな開発プロセスを導入すればいいという話ではありません。
で、同じようなことが、今の大企業が受注するようなプロジェクトでできるかと言えば、おそらく難しいでしょう。規模が違いますし、発注元の理解を得るというのも、まあ、難しかろうと。というか、現時点では理解してくれる企業のほうがマイノリティなのだと思います。
ま、なので大枠はウォーターフォールで、各工程の中にアジャイルな要素を取り入れるか、
あとは、こっちはまだ十二分に難しいと思いますが、最低限運用可能なレベルを満たしたところからスタートで、何回かインクリメンタルに？納品するというのを認めてもらうか(で、最初の一回はウォーターフォール)。
というのが現実的な落としどころかなーという気がします。
で、それが業界として当たり前になってくれば、業界全体の構造や体質も変わっていく、、、、といいですね。残念ながらここは自信がないです。開発プロセスの話以外にもいろんな力学が働いてると思うので。
ま、ただ、発注元企業の視点で考えてみると、発注をする部門は面倒なことはしたくないわけで、要件定義だけ付き合って、あとはよろしくね、ってのが、まあラクなわけです (発注する部門が必ずしも自社への利益を最優先とした行動原理で動いてるとは限らない)。
じゃあどうすればいいんでしょうね。私にもわかりません。
と、何を書いてるのかわからなくなってきましたが、補足でした。
