企業の大小とＳＥの環境

質問

前回、私の質問にご回答いただいた方々、ありがとうございました。疑問に思うところが出てきたので、さらに質問させてください。

１、大企業、中小企業のＳＥの仕事の違い
先日の飲み会でＳＥの先輩の話を聞く機会があったのですが、ソフトウェア会社の下請け会社はＳＥ(というよりも特にプログラマー)の扱いがヒドイ、と聞きました。親会社からプロジェクトが降りてきて、それを納期までにどんなに残業をしても仕上げなければいけなく、さらに自分の子会社だからその納期や条件が非常に厳しい、とのこと。
こういう子会社というのは、やはり中小企業が多いのでしょうか？それとも中小企業は独自で顧客から直接仕事を受け、プロジェクト→プログラムをするから、ある程度、自分たち(上司)が考えてくれて、残業だらけなんてことは少ないのでしょうか？
私は今のところは、中小企業は後者であり、○立ソフトウェア、○芝ソフトウェアのように、大企業の名前がついている会社の方がキツイんじゃないか？考えています。
間違い、情報などなんでもいいので教えていただきたいです。

２、業界の違い
たとえば、『Ａさんは金融系ＳＥだが、能力のほとんど変わらない友人のＢさんが流通系ＳＥをやっていて、自分は毎日残業、Ｂさんは定時に帰っているのに給料が高くて羨ましい。』こういうことって少なからずあると思うんです。
もちろん、分野が違えば能力は違う、人によっても違うというのもわかりますが、就職活動をしていても、イマイチ『今が旬』な分野が見えてきません。もし、働いている皆さんから見て、『ココは良い！』、『ココは最悪！』、または『ココは、これから落ちぶれるかも！』なところがあれば参考にしたいので教えていただきたいです。

３、大企業ＳＥ、中小企業ＳＥの違い
中小企業は、駆け出しのころは思いっきり下っ端であり、残業に次ぐ残業などのヒドイ扱いを受ける。しかし実力が認められれば管理職に就くことも夢ではない？
大企業ではどんなに頑張ってもしょせんは技術屋であり、大した待遇は受けられない。社長など夢のまた夢であり、管理職に就くことさえ難しい。しかし下っ端でもそこまでヒドイ待遇にはされない。
こんなイメージです。なんか中小企業の魅力ってよくわかりません・・・。

こんな長文を最後まで読んでいただき、ありがとうございます。ぜひ一言でもいいのでアドバイスをいただければ、と思います。

回答No.2

lv4u

１、大企業、中小企業のＳＥの仕事の違い

ANo.1さんのように○○通ソフトウエアって名前の子会社は元に近いですね。ＳＥに限らず、どこでも末端のほうが大変ですよ。例えばトヨタなら、「原価を１０％削れ！」ってトップの指示があれば、「それじゃあ、外注先の納入単価を来年度から下げて１０％になるように『お願い（強制モード）』しよう」とすれば、簡単です。こういうことを過去分に対してＩＴ業界でもやった大企業があって大問題になりましたね。

２、業界の違い

システムが停止したり、誤動作するとマスコミネタになったり、賠償金が発生したりするか？あるいは、停止しても、多少の誤差があっても、来週までに対応すればいいってシステムか？では当然対応が違いますよね。
例えば、来年度の予算計画のためのシュミレーションシステムなら、後者で「来週までに直ればいいよ」とか「多少の数字の狂いはＯＫよ」なんて対応になりそうですね。

（「人間が中に入った自販機」って揶揄される、３交代で手作業でデータ調整して企業トップに情報提供しているＳ社のシステムは、どっちなんだろう？）

公共サービス提供のような業界ほど厳しいでしょうね。

３、大企業ＳＥ、中小企業ＳＥの違い

中小企業なら、「ちょっとできる奴」くらいで管理職になれるでしょうね。でも、大企業では、「すごくできる奴」にならないと難しいと思えます。それは、中学の成績が校内でトップなら、地元高校でトップに簡単になれるけど、東京の有名進学高校に行ったら、「ちょっとできる奴」がごろごろいて、ビリ争いに参加しちゃうようなもんですよね。

でも、一般的に、大企業ＳＥのほうが収入はいいと思えます。

あと、ＳＥ職に限りませんが、「名選手が名監督になれるとは限らない」ってことですね。プログラマやＳＥの実力があっても、管理職は、また別物だと思います。（逆に、ＩＴ系の実力無くても、口先と人事系の実力だけで管理職になれたり・・・）

それから、実力さえあれば、現場で「残業につく残業」ってことは避けられることも多いと思います。「大変な作業だ！」って思えることでも、奇抜なアイデアで、楽々解決ってことあるでしょうし、「その大変な作業をやってくれるプログラム」をちょこちょこって作って、あっという間に終わらせるなんてこともあるでしょう。また、「仕様変更」をあらかじめ予想して、それに対応できる設計にしておけば、楽に対応できます。ほんとにやばい仕様変更なら「反撃モード」で、要求を潰すとか、次期プロジェクトにするとか。
また、ほんとに「このプロジェクトは大変そうだ」って読めたら、最初から回避行動をとって、近寄らないなんて対策もありますよね。（別プロジェクトにアサインしておくとか、退職をネタに脅すとか）

お礼

回答ありがとうございます。
>>また、「仕様変更」をあらかじめ予想して、それに対応できる設計にしておけば、楽に対応できます。
ここにはなるほど、と思わされました。最も効率の良い設計ではなく、最も仕様変更しやすい設計にするんですね。これは思いつきませんでした。