なんか下の増田がバズってたので乗っかってブクマ稼がせてもらいますね。
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でも、大企業が受注するようなものと比べれば相対的に小さめな規模のプロジェクトだとは思いますが、ユーザ企業と密に連携し、アジャイル的な手法を使ってイテレイティブに開発を行うことで、より短納期(手戻りを減らすことで)で、よりニーズにマッチした成果物を提供していくといった、新たなモデル？を模索しているようなベンチャーなんかがあることも知っています。その企業は、開発のための人材は全て自社で抱えて、いわゆる下請け企業に投げるといったことはしません（私が知っている限り）。基本的に一次請けだけやっているはずなので、社員一人あたりでみた時の収益もそれなりにあると思います。したがって、労働環境も少なくとも言及先の増田に書いてあるようなことはないはずです。
ただ、これをやるためにはユーザ企業側(発注元)の理解が必須で、単にアジャイルな開発プロセスを導入すればいいという話ではありません。
で、同じようなことが、今の大企業が受注するようなプロジェクトでできるかと言えば、おそらく難しいでしょう。規模が違いますし、発注元の理解を得るというのも、まあ、難しかろうと。というか、現時点では理解してくれる企業のほうがマイノリティなのだと思います。
ま、なので大枠はウォーターフォールで、各工程の中にアジャイルな要素を取り入れるか、
あとは、こっちはまだ十二分に難しいと思いますが、最低限運用可能なレベルを満たしたところからスタートで、何回かインクリメンタルに？納品するというのを認めてもらうか(で、最初の一回はウォーターフォール)。
というのが現実的な落としどころかなーという気がします。
で、それが業界として当たり前になってくれば、業界全体の構造や体質も変わっていく、、、、といいですね。残念ながらここは自信がないです。開発プロセスの話以外にもいろんな力学が働いてると思うので。
ま、ただ、発注元企業の視点で考えてみると、発注をする部門は面倒なことはしたくないわけで、要件定義だけ付き合って、あとはよろしくね、ってのが、まあラクなわけです (発注する部門が必ずしも自社への利益を最優先とした行動原理で動いてるとは限らない)。
じゃあどうすればいいんでしょうね。私にもわかりません。
と、何を書いてるのかわからなくなってきましたが、補足でした。
追記2:
おおむねブコメを見ると叩かれているのですが、ちょっとこれは反論ないし説明しておきたいというものにレスします。
どんな部署でどんなことやっててどんな感じだったかを読みにきたんだけどチリほども情報がなかった
私のことでしたら退職エントリへのリンクを貼っておいたはずなのですが、それでは不足でしたでしょうか。
ブログがレスポンシブにすらなってなくて、「え、これスマホで読むの？」ってまず思っちゃった。そういうとこやぞ。
ご指摘はごもっともです。
私がPC向けのデザインを気に入っているというのと、スマホ用表示が無味乾燥としていて嫌だったので、PC用と同じ（のはず）表示がされるよう設定しています。
要は私の趣味です。
若い人が苦労したブログに乗っかって上から叩いてブクマ稼いで……そんなにいうなら自分はなんで辞めたのか
退職エントリへのリンクを貼ってあるのでご一読いただければ。
追記のがんばってカタカナ使いました感。合わない奴は合わないで済ませればいいのにSIとか邪推してマウント取る根性。
がんばってカタカタ使いました感は自分でも書いてて指摘されるだろうなと思いました。
まあ、ルー語みたいなもんだと思っておいて下さい。
あと、マウントをとろうとかは思っていません。本当に。
SIと邪推しているという指摘はごもっともだと思います。ただ、おそらく当たってはいると思います。
何がしたいかったのかさっぱり分からんw
自分でもそう思います。
レスポンシブデザインにしろよ 今時富士通でもやるぞ(たぶん)
上述の通り
部門によって全然違うのに就活真面目にやれば分かったはずとか、自分で矛盾言ってる事気づかないのだろうか
これですが、増田の人も、結果的に配属されるおおまかな部門（ざっくり、SIか、自社製品の開発か、研究所か）と職種（上記）は、採用を受ける前に想定できたはずなんです。なんかわかりにくいですね。
要はざっくりとしたくくりで見れば、希望したところ希望した職種で配属されるということが想定できたはず。
というのは、少なくとも私が採用された2010年の時点（リーマンショックやらのあおりで採用数が前年の半分？とかになっていた時）でも、面接の中もしくは内定後・入社後に職種（と、あと行きたい部署）の希望はとっていて、職種（詳細は伏せますが、ざっくりとSE、営業、研究開発（ソフトウェア希望なら、いわゆるソフトウェアエンジニア。SI部門には行かない）、その他）についてはごくごく少数の例外を除いては希望通りになっていたと認識していますし、希望部署も、感覚的には少なくとも6割ぐらいは希望通りになっていたように認識しています。別に集計したわけではないので確かなところはわからないですが、そんな感じでした。
新入社員の三年離職率？がかなり高くてやばいとかなんとか言われてる昨今（当時既に）なので、ミスマッチがあると、入社した人も不幸だし、会社からすると辞められちゃう可能性が高まるわけで、全然いいことないですから、人事も（少なくとも最初の）配属は、適当に決めたりはしません。
で、入社後のこのような流れは、FNHTあたりならどこも同じような感じだったはずで、ネットをあさるとか、OB訪問をする、研究室・ゼミの先輩に話を聞く、などで十分知り得たはずです。
情報収集ってどうやるの教えてください
ネットをあさるだけでも結構な情報は得られると思いますが、OB訪問や、内定が出て新年度から社会人、というような先輩に話を聞くのが一番でしょうね。
追記がさらに酷い。テスト駆動開発でも大規模開発出来る事を知らなさそう。
私が薄学で知らないだけなのかもしれないですが、アジャイル = テスト駆動開発なのですか？
まあ、それはさておき、アジャイルで大規模開発が出来るということであれば、私は知らなかったので勉強になります。
ついでに、ネットで参照できる事例なんかも教えていただければありがたいです。
元増田の記事をディスりと感じてしまうのはすごい。ただただ改善すべき点を述べているだけに見えるのだが。そういう声を上げられないような職場環境が富士通の衰退を招いたのかしら？
確かに言われてみればそうだなと思いました。
私が幼稚であったということだと思います。反省です。
自分で6割ぐらいは希望通りに配属っていうなら、元増田は残り4割だったかもしれないのに、就職活動まじめにやってなかった、って決めつけでdisるのはいくらなんでも元増田に対して失礼なのではなかろうか
書き方が分かりにくかったかもしれないですが、私が書いたこと、伝えたかったことの意図は、おおまかな希望した分野？の部署 (SI希望ならSI、自社製品の開発なら同様）に、希望した職種でほとんどの場合配属される、ということです。
そして、それで想定可能な範囲としては十分ではないか、と私は考えているわけです。
部署が違うと文化が違ってうんぬんっててめえが言ってるじゃねえかと指摘されると辛いところですが、ざっくりとSI部門と絞れればまあ、おおむね実態は想定可能だったと、私は思っています（増田の方がいたのがSI部門だったのかは確定事項ではないですが、ここまで書いてしまったので、それを仮定）。
追記3:
正直最初は増田の記事の一部をとりあげて、いいかげんに書いてしまったので、個別にコメントしときます。
開発環境がだめ
使う開発環境によって評価も変わる気はしますが、Chromeとかメモリ食いまくるし、時代と照らし合わせれば確かに低スペックだと思います。
ただ、まあ、高齢化してしまった大企業とかだとこんなもんでは？ぐらいの話のような気もします。
とりあえず、私はスペックが低くて、困ったなあ、と感じたことは特になかったです。
"Macなんか認めん！iOSアプリも富士通PCで作れ！（本当にあった話）。"
これはたしかにかなりアレ
机上環境もだめ
上述
事務室環境もだめ
やっている事業によってはこういう状況なのかもしれません。
不快に思うのは同意します。
評価制度の納得感がない
ごもっとも。
ただ、人事評価ってすごく難しいので、じゃあどうすれば良いのか、と考えてみるといいかなと思います。
古い方法へのこだわり
開発標準とやらは聞いたことがありません。
それ以外は上述。
"工程だけでなく、品質についても言及されている。例えば試験項目の品質はいかにバグが検出されたかで測られる。"
この考え方に疑問を持つ気持ちは良く分かりますが、品質管理？においては一般的？な考え方ではあります。
「バグ曲線」とかでググってみて下さい。
新しい方法・技術の導入の難しさ
上述
クラウドは私がいた当時はまだそこまで普及していなかった？ような気がするのでノーコメントで。
残業時間の評価
基本給が安くて、残業代で稼ぐモデルなのは確か。
でも、新卒で、独り身だとしたら、生活に困るほどでしたか？
ビルドは普通にmakeです。（ブコメでウケがよかったのでもう一度書いておきますね）
スキルと無関係の異動
部署が違うのでよくわかりません。
車輪の再開発してるんじゃね？って話は、まあ気持ちは分かりますが、ビジネスなので、食っていかないといけないので、と割り切ってやるしかないような気はします。
社外技術への関心のなさ
上述
なんちゃってフレックス
これは、増田の人のブコメに少し書いてありましたが、いろいろ事情があるそうです。
最初から今みたいな？ヘンテコなシステムだったわけではなかったないようです。
人が均質的
同意
でも尊敬できる人もたくさんいました。
個人時間のなさ
程度の違いはあれど、同意します。
未来のほの暗さ
同意
