はじめに

よく、「いい会社に入りたい！」みたいな話があるんですが、
その人にとって、会社に関してはどこがいいというのは意外に説明しにくい気がしています
(合う合わないがあるのと、仕事をして納得感があるかどうかはプロジェクトにもかなり左右されるので)

ただ、いくつかの尺度はある気がするので思いつくままに考慮点をリストアップしてみました
凄く主観が入っているので人によっては何言ってんの… って人もいるかもしれません

SIerを選ぶ時になんとなく知っておいたほうがよさそうなことリスト

明確に良し悪しがありそうなもの

新人研修が長い会社のほうが良い

まずそもそもの話として、会社に体力がないと長期の新人研修はできない。
また、社会人になると専門職なら基本的には何かの仕事に専門化するので、専門化した分野の技術が流行らなくなった(≒稼げなくなった)時のトレーニングコストも、普通に考えれば新人研修が長い会社の方がかけてくれると思われる。そんなわけで研修が長い会社ほど社員の育成コストをかけてくれて、良い傾向にあると思うのだけどどうなんだろう
また、ＯＪＴはトレーニングという体の即時戦力なので研修と思わない方がいいかもしれない。（ただ、これはＯＪＴで参加するプロジェクトやついてくれる先輩にも大きく影響する。メンターがレベルめっちゃ高かったらＯＪＴの方が成長できる…みたいなケースもある。実際にやってみる事による学びは大きい。）

上場企業のほうが良い

上場すると会社全体の成績を決算として公表する事が必須になるので、会社平均で儲かってるかがわかる
上場企業にはコンプライアンス順守という形で、社会的な責任も求められるので(特に東証一部)、会社として正しい運用がなされている（だろうと思われる）
転職するときに前職が東証一部とかだとそれはそれで評価対象になる。(そういう会社の人事が認めて採用された人　という評価にはなるので。)

平均残業時間の少ない会社のほうが良い(平均稼働時間に関する話)

それだけで単純に**「会社としての人的資源マネジメントが(だいぶ)できている」と言えるっちゃ言えるので。(実態は作業キャパ的に溢れた分を全部下請けにぶん投げてる**可能性はある)
また、普通のメーカー系やSierみたいな会社だと、社会人になってからはただでさえ技術をキャッチアップする時間がマジで取れなくなるのに、残業しまくると後で技術的に頭打ちになりやすいような気がする。
（ただし残業代がちゃんと出る会社だと給料はマジで増える）
　　
いっぱい残業しないといけない会社は、何らかの問題とセットでそういう運用になっているようには思う。(どうしたって過当競争には陥りがちなので仕方がない面もあるのだけど。)
以下ありがちな例。
- 技術的にレベルが低いのを稼働でカバーしている
- マネジメントが甘いので稼働で何とかしている
- 利益を出すために社員を使いつぶしている
そもそもの話として母数が多いほど平均残業時間は平準化されるし、社員を社内のどこのプロジェクトもオーバーワークで運用しているのは管理としてヤバいので普通はありえない(少しオーバーワークになって全員がキャパを超えだすと、一気に休職者が大量発生してコントロールできずに破綻したりしがち)ので、会社として安定的にシステム開発で利益が出ている場合はほとんどのプロジェクトは普通の状態の筈。(190305追記)
ただ、人が新たに投入されるプロジェクトは一般的には「人が足りない(or 足りなくなる見込みがある)」から投入される(人的資源管理が安定状態にあるところに新しい人を入れても普通はコストが増えるだけなので、トレーニングやジョブローテーションなどの攻める理由が無い限りは普通はやらない)ので、「転職したけどめっちゃキツイなこの会社」は会社がキツイのではなく、そういうところに圧倒的に配属されがち。(190305追記)
ちなみに稼働時間の匙加減やプロジェクトの方針はPMが決めていると言いながらもその上司が圧力かけまくってる事が多いので、上司や営業がダメだとその部課は残業させまくりの傾向とか普通にあったりする。(でもまともに運用していて稼働時間が少なめの部課は逆に利益を上げていなくて評価されないというジレンマもある。) プロジェクトが違えば運用は全然変わるし、課が違えば全然文化もルールも働き方すら違うとかよくある話。(190305追記)
残業時間に関する、ここら辺の話を実感として知りつつ、ヤバいプロジェクトに触れる前に血肉にしておきたかったらとりあえず 人月の神話読もうな… なお、情報処理技術者試験の設問で出てくる「ブルックスの法則」の元ネタです。なってないプロジェクトを経験する前に必ず読むべきかと。(システム開発における定石の一つなので、「この本にこう書いてあるんですけど？」で上司や元請の無茶を止めたりできるぞ！なお装丁が変わったのでなんか増えたんかしら？と思って買ったら中身が一緒だったので私の家には2冊ある orz…) (190305追記)
　
職場の稼働時間を見るのに職場が何時ごろまで電気ついてるか見てみたらいいみたいな話がたまにあるのですが、実態は結構な人数が客先常駐だったりするのでその状況は会社の電気ついてるかは当てにならない　という話もあるし、持ち帰りの開発をしてるので自社でゴリゴリ作業してて電気ついてるケースもあります。結局は行くプロジェクト次第です。ある程度の目途はつくでしょうが、その程度のものという割り切りも必要。あと、外から見たときにどの窓が何階なのか意外にわかりづらかったりもする。(190309追記)

労組のある会社のほうが良い(のかも)

ソフト専業の会社だと歴史的な経緯から労組がある事は珍しいが、いわゆるメーカー系は労組があるので会社に対して文句を言いたいときに労組がないと手段がマジでない
ただし労組があったからといって、そこまで役立つかというと…という話もよく聞く
でも客観的に見て、やっぱり労組がある会社のほうが社員の権利は守られている気はする
ただ、労組があるのか、面接などで聞くと自殺行為になりかねないので、こういう情報に関してはネットで調べるのが無難かなという気はする。(もしくはOB訪問とかの手段もあり)
労基法を自分で拾いたいのであれば、社労士試験の教科書とか読むと良い。(そんなに難しくはない)真面目に人的資源管理をするのであれば遅かれ早かれ知る必要はあるし…

給与が高いほうがいい

SIerだと、請のレベルが同じなら、結局どこの会社でもやる事そんなに変わらない(気がする)ので
給与に関しては、**残業時間も含めたトータルの稼働時間に対しての時間給としてどうか？**という点と
通勤時間がどれぐらいになるのかは考慮しておいたほうが良い気がする
転職するときも「前職の給与を基準に初めの給与を決めましょう」で給与が決まるケースが結構ありがち。(なお住んでるエリアを跨ぐ転職は当然それに応じた給与見直しが入る。特に減方向は顕著。)
居住エリア(東京近郊とか、名古屋大阪の大都市圏とか、地方とか)には依るが、給与が高いということは普通は請けの上位側にいる可能性が高い(お金は上から下に流れるので…)　もしくは請けの金額が高いため、会社として参加してるプロジェクトのレベルの平均が高いないし会社が上前を撥ねてないという事になる

20%ルールみたいなのがあるほうがいい(190522追記)

ITは技術が陳腐化しやすい業種のため、技術を習得するコストをかけつづけないとスキルレベルを維持しにくい特性があります。(陳腐化しにくい技術も当然あるにはある。DBまわりの設計とか。)
技術が陳腐化しやすい事がシステム開発・リプレースのトリガーになったりもするので、それ自体はピンチでもありチャンスでもあるのですが、開発する側のスタッフも技術変化と少なくとも等速以上で技術をキャッチアップする必要が出てきます。
この際、例えばGoogleの20%ルールのように、勤務時間内で技術検証・習得を行えるのであれば良いのですが、工数は100%(残業ありきだと100%以上…)を開発に充てろという会社は少なくなく、そういった会社に入った場合は技術習得を自分の時間を割いて持ち出しで対応するか、技術習得をせず、マネジメントに寄せていくという動きになると思います。(まともにロジックも書けないのにふんぞり返るなんちゃってPMが量産されるのはこのせいだと個人的には考えています。)
持続可能な形で開発を続ける場合、インプットは必要コストなので相応の工数に関しては会社が負担するのが、個人的には正しいと思いますが、企業の余力が少ない会社ほどこういうところにコストをかけず、人が育たず、育ったと思ったら人が流出し、スキルが無い人をマスで使って技術的な解決能力が足りない状況でプロジェクトに突撃して大炎上　というのはSierあるあるなわけです。
なので、そういったところに気を配れる会社はかなりホワイトな可能性が高いと思われます。(たぶんQiitaとかgitとかに社員がガンガン勤務中に投下してる会社はいい意味でヤバい)

ケースバイケースなもの

メーカー系Sier(だいたい一次請ないし発注者)と独立系Sier(二次請～)

発注者側にいると起きる事
- プロジェクトにロックインされる(ので、やりたい方向の仕事と違う仕事にアサインされて長期に関わる可能性もある)
- お金の流れの上流にいるので権力が強い(ただしお金がないとなんでも自分でやるはめになったりもする。力はつくけど。)
- 上流にいるので技術を追っかけるというよりもマネジメント方向の仕事になる事も多い(手を動かしたい人には向かないかもしれない)
一次請(元請)にいると起きる事
- 設計から開発、運用まで、契約した事の責任は全部負う必要がある。
- そのかわり、技術の取捨選択(トレードオフに関する意思決定)にいろいろ関与できる。初期開発時は特に顕著。(うまくトレードオフを検討して設計しきれると、転職活動の時などでスーパー切り札になりうる開発事例とかが仕込めたりする。)
- ちなみに私の場合は転職前、実際に結構有名な商用ミドルウェアの公式開発事例を1本仕込めたのが転職にかなり効きました。客観的な事例に到達したアウトプットは話せるネタでもあるので超強い。
- 上流にいるので権力がやや強い(基本的に組織って上は選べないが下は選べるのだ…)
- プロジェクトのロックイン期間が長くなる傾向にはある。(お客さんにウケているシステムは往々に機能拡張が頻繁に行われ、延命して長期運用されがち)
- プロジェクトで使っていない技術は自習しない限りキャッチアップしにくい(ので勉強会に行く人も多い)
- 結果、同じことを続けてやり続ける事になるので特定分野や特定業務(≒特定クライアント)のスペシャリストになりがち。究極的にはクライアントの社内SEにコンバートする人とかもいたりする。
- 客先コンバートは**「強くてニューゲーム」**で社内SEにシフトできるので、転職先の会社にもよるけど結構勝ち組な気がする。転職元の会社的にはいいのか？みたいな話は出るのだが、「職業選択の自由」の方が強いので普通はセーフ。(同業他社への転職のほうが営業上の秘密の問題があって実はグレー)
二次請以降にいると起きる事
- 権力が弱いので請先と殴り合うためには一工夫要る。(例:こういった技術書には○○と書いてあるのですが貴社ではどうお考えですか？みたいな。本や規格といったものをうまく使う必要がある。でも正論は耳に痛いのでやりすぎると切られる。ヤバい。切られる以上に上司のレベルが低い時がヤバい。)
- 一次請から切り出された仕事だけをする事になるので技術の取捨選択(トレードオフに関する意思決定)を０から検討するタイミングがめちゃ少ない
- 技術的にチャレンジングな事は(丸投げという形で)めちゃくちゃ降ってくるか、(パターンワークに落とし込めるものばかりを下ろしているので)全く降ってこないかのどちらかに偏る事が多い気がする。
- 一次請がパーフェクト丸投げ体質だと(責任も含め)全部降ってくるが、上前だけを撥ねるのもあるある。(かといって一次請の人たちが技術がわかっているかというとアレ…)　そういう時はメールや議事録でエビデンスを残して防衛線を張らないと死ねる。(そしてマネジメントコストが上がる)
- 会社の体質がお金のあるところに全員突撃を命じがち。そのためプロジェクトがころころ変わりがち。(１年同じ所にいないとかザラ)
- プロジェクトがころころ変わる事でいろんなプロジェクトを経験しがち。なんでも降ってくるのを捌いているとオールラウンダーになりがち
- そしてなぜか全部なんとかしてくれるオールラウンダーは逆に特筆したポイントがないので評価が低くなりがち
- 自分のスキルやキャリアのデザインから大きく外れる仕事を「できないと言ってしまって振ってくる仕事の範囲をある程度絞る」のか、「精力的に拾う」のかはブレると厄介なので、戦略としてあらかじめ決めておくほうが良いかもしれない
- なおできる事がバレてからできません　はだいたい通用しない(逆はいける)。ただし、技術的な課題をどう捌くか(だいたいは何かと何かのトレードオフなのでその調整をする)は、主導的な立場でエンジニアリングしていくのに必要となるスキルなので(高度情報とかもそういう出題ですよね。午後２とか。)、苦労して検討しまくらないと身につかない。悩ましいね
- 「苦労は買ってでもしたほうが良い」はある意味では真なのだけど、それを言ってくる上司がさせたいのは苦労じゃなくて単純労働だったりする。脳みそに汗をかいて必死になって設計する経験は多ければ多いほど糧になるけど、単純労働はぶっちゃけそこまでスキル積めるわけでもなく、持ち出しの方が多い事もままあるので気を付けた方がいいのかも

資格に伴う手当の多い会社と少ない会社

多い会社
- 特定資格をもっていると毎月手当が出たりする(だいたい情報処理技術者試験はそういう制度があるところは絶対ある。分野的には一部の資格かもしれないが。ITパスポートとかセマネは無い会社もありそう。)
- 資格があったほうが会社として旨いので手当が厚い(要は他の会社に派遣や請負で人を突っ込む時に有資格者をアサインするかわりにスキルの低い人も抱き合わせで突っ込んだりできるので…)
- 会社が育った時に制度見直しが入って手当が一時金になったり減額されたり無くなったりするリスクがある(実際あった… 40万ぐらいの手当てが10万以下になったりしたよ)
- 余談な気もするが、こういう制度がある事で資格を取っていった結果、転職もしやすくなるみたいな面もある。(どこの人事部も採用に関して「なぜこの人を採用したのか？」を説明できる人の方が当然内定を出しやすい。**客観的な説明責任を負ってくれる「資格」**が転職に強いのはこの為で、無名な資格にあまりメリットがないのもそういう理由だろうと思います。)
少ない会社
- だいたい会社の規模がでかく、必要な資格があれば会社がお金を出して受けさせるので手当なしという企業もあったりする
- よく普通の上場企業や大手でありがちなのは一時金支給のみのパターン。(○○取れたら10万円とか。)

ハードウェアに絡む会社と絡まない会社

ハードウェアに絡む会社
- いわゆるメーカーとか
- ハードウェアまで責任をもってシステムを請けられるのはだいたい一次請になる
- 組込み系などもハードとソフト両方を見ることになる。実機は個人的には楽しかった。(人によると思うけど)
- 売れないソリューションを担がされると辛い気がする
- ハードウェアの取り合いになることでオーバーワークが防げるケースがある。(実機は貴重だったりする)
- 実際に関わったプロダクトがいろんな人の見えるところにあり、生活を支えていたりするのは意外に嬉しいです。(組込みでやってたのはそういうプロダクトだったので。)
ソフト専業の会社
- いわゆる独立系Sierとか
- 今はクラウドがあるのでソフト専業でも上流はありうる(昔はハードウェアの責任を負えない会社は一次請になれなかった)
- 顧客に対してのシステム受諾開発だとハードの責任を負わない会社はケースバイケース(今は仮想機環境とかが一般的にあるのでハードの責任を負えなくても良いケースも多い)
- ソフトだけで完結すると、人を稼働させた分だけ進捗が上がるので、プロマネが残業ありきの計画とか立てがち

大きい会社と小さい会社

大きい会社
- 個人でめちゃくちゃ利益に貢献しても埋もれがち(一人を成果に比例してめちゃくちゃ評価するのが難しい面もある)
- マスとして考えた時に平均以上のパフォーマンスをコンスタントに出す人が評価されがち
- 逆に利益に全然貢献できなくても給料はもらえる(ぶらさがり社員が発生しがち)
- 中堅ぐらいまでの人から見ると、困った時に助けてくれる人が多い(技術を主導する立場になると持ち出しばっかりになる事も多い)
小さい会社
- 一人エキスパートがいるといないとで状況が激変する
- 個人でめちゃくちゃ利益に貢献した時に評価されやすい
- 自分よりレベルの高い人がいないとレビューを受けれない問題とかある(実際困ってるなう。ある程度経験と知識があればいろいろな手段で問題を回避もできるけど、心配っちゃ心配。)

作る対象の最終成果物がインフラなのかプロダクトなのか

インフラ(最重要なやつ例:インフラ死ぬと人が死ぬレベルのやつとか)
- 発注側だと維持は大変そう。
- 社内で内製なんてとてもできないので外注して作ってもらう感じのシステムが多そう
- 元請けなどだと利益高めな傾向にある(リスクが高いので金払いは良い)
- テストとかもしっかりやるけど、意図しないバグとか起きるとヤバいみたい
- そういえば5G以降は通信もインフラの要求レベルが上がってこっち側に来るみたいな話を聞いた
- 地頭が良い人が多い傾向。腕を見せると信頼が一気に上がったりする。(逆にトラブルになると結構面倒くさい。なぜなぜ分析とかな…)
インフラ(重要なやつ例:免許制の事業なのでミスると国からお叱りを受けるレベルのやつとか)
- 発注側だとやっぱり維持は大変そう。
- やっぱり社内で内製なんてとてもできないので外注して作ってもらう感じのシステムが多そう
- 元請けなどだと利益高めな傾向にあるが、相見積もりで利益は減りがち
- 外的な環境の変化で発注側の利益が全然出なかったりすると一気にしわ寄せが来たりする
- 結構…仕様が複雑怪奇だったりする
- うっかり止まるとニュースになったり国から叱られるので危機感はある
インフラ(ふつーのやつ社内システムとか)
- 結構ピンキリ。蓋開けてみないとわからん
- 大きい会社はしっかりしてる
- 小さい会社は管理がなってないケースもある(要望した資料がどこにあるかわからないので出せないとか)
- 開発規模に応じて見積は出すけど、小さい会社だと予算が足りなくて機能削ったりとかよくある
- 極論、現場の要望がクリアできればオッケーみたいなところも多い。(過去に経験したケースで一番アレだな…と思ったのは、機能改修の予定だったものが詳細検討をするとDBのクエリ1本書いたら終わりだったので、書いて終わったという…)
- この機能は絶対欲しいって請け先に言っちゃうとそこの工数を多めに(こっそり)積まれる。手札は隠そう！ お兄さんとの約束だぞ！(笑)
- 落ちてもお咎めが無くてうまく処理してくれる(しちゃう)ケースもある(特に小さい会社だと…)
- 面倒くさい人がいる事も多い(理路整然と説明してもわかってもらえなかったり)
プロダクト(みんな使ってる製品になるやつ)
- これ俺作ってましたね…って言って( ･´ｰ･｀)ドヤれたり、ドヤれなかったり(元請けじゃなく、かつプロダクト作ってる会社が片手で数えられるほどしかない製品だったりすると…)する
- よく使うものとかに関われると、プロジェクト離任後でも「おっ、今日も動いてるな…」って気分になってちょっとアガる
- 不具合が出ると大変
- かといって請けや作業単価が高いかといわれると…
プロダクト(あまり日の目に当たらないニッチなやつ)
- ドヤりにくい。(そもそもドヤっても伝わらん…)
- ユーザと密にかかわる事になったりもする
- 機器リプレースに行ったりとかある
- 発注側も儲かってない事が結構あるあるで、請けの価格や作業単価もなかなか上がらない
- それでもプロダクトの方が実際に動いてるモノがあるので後から振り返ると個人的には楽しかった

全然関係ないけど就職/転職で知っておいたほうが良い事

就職/転職試験は減点法の事がほとんど。
- 激しくミスすると他が良くても一発アウトという事はある。
- 会社のレベルや求めている事より低いのもダメだが、高すぎるのもダメだったりする。(うちには来ないと思ってお祈りされる… そういう場合はお祈りされたほうが良いのだが。)
- 基本的に会社が欲しいのは利益を出してくれる人(その利益を出してくれるまでの期間の余裕がが短い・長いという差はあれど)
- じゃあ会社がどうやって「利益をその人が出してくれるか」わかるかといえばわからない。
- もしくは誰つっこんでもある程度指示が通って稼働あげてくれたら利益が出る…
- そういえば転職の時、エントリーシート見せたら内定通知送ってきた会社とかあったな…(笑)
- 普通の会社は当然めっちゃ悩んでる(採用って結構コストかかる)ので、最低でも採用が失敗してても客観的な説明をできて責任を負わなくていい人を採用したいように思える。
- そういう責任転嫁できそうなのでいうと、いわゆる学歴フィルターとか、有資格者だと説明がしやすいのは自明ですね…。
プログラマ３５歳限界説
- ある意味真実だけど、ある意味盛り過ぎだと思う
- 体力だけで無理やり、残業して稼働時間を増やしても体調が維持できなくなってくるのがこの頃
- 転職も３０歳までとか３５歳までの制限がかかってるところはちょこちょこある(ので転職制限にかかる事はある)
- 年齢に応じたスキルがある程度積めていれば、別に３５歳越えてようがエントリーシートは通る。(実際サクサク通った)
- ただし年齢に応じたスキルが積めている事を証明するには資格とかがないとしんどいかも。

続編そのうち書きます

親友がこの記事をみて「詰んだ…」とか言い出したので、入っちゃったあとのリカバリをどうすんの？という話は別記事で~~書く予定です~~書きました。(190309追記)

就職/転職でSIerを選んだ後になんとなく知っておいたほうがよさそうなことリスト

おわりに

見た人で何か思いついたらなるべくコメントとかで教えてください。