よく、「いい会社に入りたい！」みたいな話が新卒の就活サイトだとありがちなんですが、就職活動/転職活動をしているそれぞれの人にとって、会社に関してはどこがいいというのは意外に説明しにくい気がしています。(そもそも合う合わないがありますし、仕事をして納得感があるかどうかは会社の風土、入る部署、参画するプロジェクトにもかなり左右されるので)
こういった事に関し、いくつかの客観的な尺度はある気はしており、考慮点をリストアップしてみました。あなたの参考になれば幸いです。
- まずそもそもの話として、会社に体力がないと長期の新人研修はできない。
- また、社会人になると専門職なら基本的には何かの仕事に専門化するので、専門化した分野の技術が流行らなくなった(≒稼げなくなった)時のトレーニングコストも、普通に考えれば新人研修が長い会社の方がかけてくれると思われる。そんなわけで研修が長い会社ほど社員の育成コストをかけてくれて、良い傾向にあると思われる。
- また、ＯＪＴはトレーニングという体の即時戦力なので研修と思わない方がいいかもしれない。（ただ、これはＯＪＴで参加するプロジェクトやついてくれる先輩にも大きく影響する。メンターがレベルめっちゃ高かったらＯＪＴの方が成長できる…みたいなケースもある。実際にやってみる事による学びは大きいぞ！）
- 上場すると会社全体の成績を決算として公表する事が必須になるので、会社平均で儲かってるかが客観的にわかる
- 上場企業にはコンプライアンス順守という形で、社会的な責任も求められるので(特に東証一部上場企業などは顕著)、会社として正しい運用がなされている（だろうと思われる）
- 転職するときに前職が東証一部とかだとそれはそれで評価対象になる。(そういう会社の人事が認めて採用された人 という評価にもなる。)
-
それだけで単純に 「会社としての人的資源マネジメントが(だいぶ)できている」と言えるっちゃ言えるので。(実態は作業キャパ的に溢れた分を全部下請けにぶん投げてる可能性はある)
-
また、普通のメーカー系やシステムインテグレーターみたいな会社だと、社会人になってからはただでさえ技術をキャッチアップする時間がマジで取れなくなるのに、残業しまくると後で技術的に頭打ちになりやすいような気がする。
-
ただし残業代がちゃんと出る会社だと給料はマジで増える。目先の小銭を追うよりはトータルでどう成長していきたいかに目を向けたほうが一般的には良いが、奨学金などがあるとまた状況も変わりますよね…
-
いっぱい残業しないといけない会社は、何らかの問題とセットでそういう運用になっているようには思う。(どうしたって過当競争には陥りがちなので仕方がない面もあるのだけど。)以下ありがちな例。
- 技術的にレベルが低いのを稼働でカバーしている
- マネジメントが甘いので稼働で何とかしている
- 利益を出すために社員を使いつぶしている
-
そもそもの話として母数が多いほど平均残業時間は平準化されるし、社員を社内のどこのプロジェクトもオーバーワークで運用しているのは管理としてヤバいので普通はありえない(少しオーバーワークになって全員がキャパを超えだすと、一気に休職者が大量発生してコントロールできずに破綻したりしがち)ので、会社として安定的に利益が出ている場合、ほとんどのプロジェクトや業務は普通の状態である（破綻せずにマネジメントされている）筈。
-
ただ、人が新たに投入されるプロジェクトは一般的には「人が足りない(or 足りなくなる見込みがある)」から投入される(人的資源管理が安定状態にあるところに新しい人を入れても普通はコストが増えるだけなので、トレーニングやジョブローテーションなどの攻める理由が無い限りは普通はやらない)ので、「転職したけどめっちゃキツイなこの会社」は会社がキツイのではなく、そういうところに圧倒的に配属されがちである事は覚えておいたほうがいい。
-
ちなみに稼働時間の匙加減やプロジェクトの方針はPM（プロジェクトマネージャー）が決めていると言いながらもその上司が圧力かけまくってる事が多いので、上司や営業がダメだとその部課は残業させまくりの傾向とか普通にあったりする。(でもまともに運用していて稼働時間が少なめの部課は逆に利益を上げていなくて評価されないというジレンマもある。) プロジェクトが違えば運用は全然変わるし、課が違えば全然文化もルールも働き方すら違うなんていうのもよくある話だったりはする。
-
残業時間に関する、ここら辺の話を実感として知りつつ、もしあなたがIT業界で、ヤバいプロジェクトに触れる前に血肉にしておきたかったらとりあえず 人月の神話1って本を読もうな… なお、情報処理技術者試験の設問で出てくる「ブルックスの法則」の元ネタだったりもする。なってないプロジェクトを経験する前に必ず読むべき。(システム開発における定石の一つなので、「この本にこう書いてあるんですけど？」で上司や元請の無茶を止めたりできるぞ！ なお装丁が変わったのでなんか増えたんかしら？と思って買ったら中身が一緒だったので、この項を記載している筆者の家には2冊ありますよ orz…)
-
職場の稼働時間を見るのに職場が何時ごろまで電気ついてるか見てみたらいい みたいな話がたまにあるのですが、実態は結構な人数が客先常駐だったりするのでその状況は会社の電気ついてるかは当てにならない という話もあるし、持ち帰りの開発をしてるので自社でゴリゴリ作業してて電気ついてるケースもあります。結局は行くプロジェクト次第です。ある程度の目途はつくでしょうが、その程度のものという割り切りも必要。あと、外から見たときにどの窓が何階なのか意外にわかりづらかったりもしますよね。
-
システム開発系の会社に関する話でいうと、ソフト専業の会社だと歴史的な経緯から労組がある事は珍しいが、いわゆるメーカー系は労組があるので会社に対して文句を言いたいときに労組がないと手段がマジでない事があります。
-
ただし労組があったからといって、そこまで役立つかというと…という話もよく聞きます。
-
でも客観的に見て、やっぱり労組がある会社のほうが社員の権利は守られている気はします。
-
ただ、労組があるのか、面接などで聞くと人事総務に勘ぐられて、自殺行為になりかねないので、こういう情報に関してはネットで調べるのが無難かなという気はします。(もしくはOB訪問とかの手段もありですね。)
-
労基法を自分で拾いたいのであれば、社労士試験の教科書とか読むと簡潔で手っ取り早い。(そんなに難しくもない) 真面目に人的資源管理をするのであれば遅かれ早かれ知る必要はあるし、知っておいて損はない。（だいたいこの本にもマジの要点はエッセンスとして残してありますが。）
-
システム開発の多重下請け構造に絡む会社であれば、ｎ次請のレベルが同じなら、結局どこの会社でもやる事そんなに変わらない(気がする)ので、給与が高いほうが同じ仕事をどうせするなら嬉しいですよね。
-
給与が高いということは、別の切り口で考えると協力会社さんの単価も高いはずです。（そりゃ誰だって自社の給与より協力会社さんの給与のほうが高かったら嫌でしょう？）
-
給与に関しては、**残業時間も含めたトータルの稼働時間に対しての時間給としてどうか？**という点と
-
通勤時間がどれぐらいになるのかは考慮しておいたほうが良い気がします。
-
転職するときも「前職の給与を基準に初めの給与を決めましょう」で給与が決まるケースが結構ありがちです。下がるのは簡単。上げるのは難しい。(なお住んでるエリアを跨ぐ転職は当然それに応じた給与見直しが入ります。特に減方向は顕著ですね。)
-
居住エリア(東京近郊とか、名古屋大阪の大都市圏とか、地方とか)にはよるのですが、給与が高いということは普通は請けの上位側にいる可能性が高い(お金は上から下に流れるので…) もしくは請けの金額が高いため、会社として参加してるプロジェクトのレベルの平均が高い ないし 会社が上前を撥ねてないという事になります。おかね大事。
-
転職の際に、給与が低いと、「この人は会社から評価されていなかった（＝無能だった）のでは」という疑念が浮かぶことがある。本人の資質とは別問題なので、悲しい・・・おかね大事。
-
まず、ITは技術が陳腐化しやすい業種のため、技術を習得するコストをかけつづけないとスキルレベルを維持しにくい特性があります。(陳腐化しにくい技術も当然あるにはありますよ。DBまわりの設計であったり、プロトコルだったり、情報理論だったり、理論として動かないものは覚えてしまえば勝ちなので強い。)
-
また、ITではない他の業種でも安心はしてられません。ITはどんな技術にも混ぜられるので、他の分野に混ざった瞬間、その分野の技術の進捗速度はITに牽引されて一気に加速します。（もう誰も逃げられないのかもしれない…）
-
技術が陳腐化しやすい事がシステム開発・リプレースのトリガーになったりもするので、それ自体はピンチでもありチャンスでもあるのですが、開発する側のスタッフも技術変化と少なくとも等速以上で技術をキャッチアップする必要が出てきます。
-
この際、例えばGoogleさんの20%ルールのように、勤務時間内で技術検証・習得を行えるのであれば良いのですが、工数は100%(残業ありきだと100%以上…)を開発に充てろという会社は少なくなく、そういった会社に入った場合は技術習得を自分の時間を割いて持ち出しで対応するか、技術習得をせず、マネジメントに寄せていくという動きになると思います。(まともにロジックも書けないのにふんぞり返っている、「なんちゃってPM（プロジェクトマネージャー）」が量産されるのはこのせいだと個人的には考えています。)
-
持続可能な形で開発を続ける場合、インプットは必要コストなので相応の工数に関しては会社が負担するのが、個人的には正しいと思いますが、企業の余力が少ない会社ほどこういうところにコストをかけず、人が育たず、育ったと思ったら人が流出し、スキルが無い人をマスで使って技術的な解決能力が足りない状況でプロジェクトに突撃して大炎上 というのはIT業界のあるあるなわけです。
-
なので、そういったところに気を配れる会社はかなりホワイトな可能性が高いと思われます。(たぶんQiitaとかgitとかに社員がガンガン勤務中に投下してる会社はいい意味でヤバい。)
※ここからはIT業界のシステム開発に関する話がメインになりますがご容赦を… 大規模なプロジェクト構造を持つ業態であれば似た話は多いかもしれません。
-
発注者側にいると起きる事
- プロジェクトにロックインされる(ので、やりたい方向の仕事と違う仕事にアサインされて長期に関わる可能性もある)
- お金の流れの上流にいるので権力が強い(ただしお金がないとなんでも自分でやるはめになったりもする。力はつくけど。)
- 上流にいるので技術を追っかけるというよりもマネジメント方向の仕事になる事も多い(手を動かしたい人には向かないかもしれない)
-
一次請(元請)にいると起きる事
- 設計から開発、運用まで、契約した事の責任は全部負う必要がある。
- そのかわり、技術の取捨選択(トレードオフに関する意思決定)にいろいろ関与できる。初期開発時は特に顕著。(うまくトレードオフを検討して設計しきれると、転職活動の時などでスーパー切り札になりうる開発事例とかが仕込めたりします。)
- ちなみに私の場合は転職前、実際に結構有名な商用ミドルウェアの公式開発事例を1本仕込めたのが転職にかなり効きました。客観的な事例に到達したアウトプットは話せるネタでもあるので超強い。
- 上流にいるので権力がやや強い(基本的に組織って上は選べないが下は選べるのだ…)
- プロジェクトのロックイン期間が長くなる傾向にはある。(お客さんにウケているシステムは往々に機能拡張が頻繁に行われ、延命して長期運用されがち)
- プロジェクトで使っていない技術は自習しない限りキャッチアップしにくい(ので勉強会に行く人も多い)
- 結果、同じことを続けてやり続ける事になるので特定分野や特定業務(≒特定クライアント)のスペシャリストになりがち。受諾開発のシステムエンジニアだと、究極的にはクライアントの社内SEにコンバートする人とかもいたりする。
- 客先コンバートは**「強くてニューゲーム」**で社内SEにシフトできるので、転職先の会社にもよるけど結構勝ち組な気がする。転職元の会社的にはいいのか？みたいな話は出るのだが、「職業選択の自由」の方が強いので普通はセーフ。(同業他社への転職のほうが営業上の秘密の問題があって実はグレー)
-
二次請以降にいると起きる事
- 権力が弱いので請先と殴り合うためには一工夫要る。(例:こういった技術書には○○と書いてあるのですが貴社ではどうお考えですか？ みたいな。本や規格といったものをうまく使う必要がある。でも正論は耳に痛いのでやりすぎると切られる。ヤバい。 切られる以上に上司のレベルが低い時がヤバい。)
- 一次請から切り出された仕事だけをする事になるので技術の取捨選択(トレードオフに関する意思決定)を０から検討するタイミングがめちゃ少ない
- 技術的にチャレンジングな事は(丸投げという形で)めちゃくちゃ降ってくるか、(パターンワークに落とし込めるものばかりを下ろしているので)全く降ってこないかのどちらかに偏る事が多い気がする。
- 一次請がパーフェクト丸投げ体質だと(責任も含め)全部降ってくるが、上前だけを撥ねるのもあるある。(かといって一次請の人たちが技術がわかっているかというとアレ…) そういう時はメールや議事録でエビデンスを残して防衛線を張らないと死ねる。(そしてマネジメントコストが上がる)
- 会社の体質がお金のあるところに全員突撃を命じがち。そのためプロジェクトがころころ変わりがち。(１年同じ所にいないとかザラ)
- プロジェクトがころころ変わる事でいろんなプロジェクトを経験しがち。なんでも降ってくるのを捌いているとオールラウンダーになりがち
- そしてなぜか全部なんとかしてくれるオールラウンダーは逆に特筆したポイントがないので評価が低くなりがち
- 自分のスキルやキャリアのデザインから大きく外れる仕事を「できないと言ってしまって振ってくる仕事の範囲をある程度絞る」のか、「精力的に拾う」のかはブレると厄介なので、戦略としてあらかじめ決めておくほうが良いかもしれない
- なおできる事がバレてからできません はだいたい通用しない(逆はいける)。ただし、技術的な課題をどう捌くか(だいたいは何かと何かのトレードオフなのでその調整をする)は、主導的な立場でエンジニアリングしていくのに必要となるスキルなので(情報処理技術者試験の高度情報と呼ばれるレベルの試験などでもそういう出題ですよね。午後Ⅱとか。)、苦労して検討しまくらないと身につかない。悩ましいね
- 「苦労は買ってでもしたほうが良い」はある意味では真なのだけど、それを言ってくる上司がさせたいのは苦労じゃなくて単純労働だったりする。脳みそに汗をかいて必死になって設計する経験は多ければ多いほど糧になるけど、単純労働はぶっちゃけそこまでスキル積めるわけでもなく、持ち出しの方が多い事もままあるので気を付けた方がいいのかも
-
多い会社
- 特定資格をもっていると毎月手当が出たりする(IT業界であれば、だいたい情報処理技術者試験はそういう制度があるところは絶対ある。分野的には一部の資格かもしれないが。ITパスポートとかセマネは無い会社もありそう。)
- 資格があったほうが会社として旨いので手当が厚い(要は他の会社に派遣や請負で人を突っ込む時に有資格者をアサインするかわりにスキルの低い人も抱き合わせで突っ込んだりできるので…)
- 会社が育った時に制度見直しが入って手当が一時金になったり減額されたり無くなったりするリスクがある(実際あった… 40万ぐらいの手当てが10万以下になったりしたよ)
- 余談な気もするが、こういう制度がある事で資格を取っていった結果、転職もしやすくなる…みたいな面もある。(どこの人事部も採用に関して「なぜこの人を採用したのか？」を説明できる人の方が当然内定を出しやすい。**客観的な説明責任を負ってくれる「資格」**が転職に強いのはこの為で、無名な資格にあまりメリットがないのもそういう理由だろうと思います。)
-
少ない会社
- だいたい会社の規模がでかく、必要な資格があれば会社がお金を出して受けさせるので手当なしという企業もあったりする
- よく普通の上場企業や大手でありがちなのは一時金支給のみのパターン。(○○取れたら10万円とか。)
-
ハードウェアに絡む会社
- いわゆるメーカーとか
- ハードウェアまで責任をもってシステムを請けられるのはだいたい一次請になる
- 組込み系などもハードとソフト両方を見ることになる。実機は個人的には楽しかった。(人によると思うけど)
- 売れないソリューションを担がされると辛い気がする
- ハードウェアの取り合いになることでオーバーワークが防げるケースがある。(実機は貴重だったりする)
- 実際に関わったプロダクトがいろんな人の見えるところにあり、生活を支えていたりするのは意外に嬉しいです。(組込みでやってたのはそういうプロダクトだったので。)
-
ソフト専業の会社
- いわゆる独立系システムインテグレーターとか
- 今はクラウドがあるのでソフト専業でも上流はありうる(昔はハードウェアの責任を負えない会社は一次請になれなかった)
- 顧客に対してのシステム受諾開発だとハードの責任を負わない会社はケースバイケース(今は仮想機環境とかが一般的にあるのでハードの責任を負えなくても良いケースも多い)
- ソフトだけで完結すると、人を稼働させた分だけ進捗が上がるので、プロマネが残業ありきの計画とか立てがち
-
大きい会社
- 個人でめちゃくちゃ利益に貢献しても埋もれがち(一人を成果に比例してめちゃくちゃ評価するのが難しい面もある)
- マスとして考えた時に平均以上のパフォーマンスをコンスタントに出す人が評価されがち
- 逆に利益に全然貢献できなくても給料はもらえる(ぶらさがり社員が発生しがち)
- 中堅ぐらいまでの人から見ると、困った時に助けてくれる人が多い(技術を主導する立場になると持ち出しばっかりになる事も多い)
-
小さい会社
- 一人エキスパートがいるといないとで状況が激変する
- 個人でめちゃくちゃ利益に貢献した時に評価されやすい
- 自分よりレベルの高い人がいないとレビューを受けれない問題とかある(実際困ってるなう。ある程度経験と知識があればいろいろな手段で問題を回避もできるけど、心配っちゃ心配。)
- 創業者が自ら立ち上げたオーナー企業だったりすると、その創業者がOKといえば何でも通る。（結果、昇給査定で一発で上の桁が上がるような昇給とかありうる。）
-
インフラ(最重要なやつ 例:インフラ死ぬと人が死ぬレベルのやつとか)
- 発注側だと維持は大変そう。
- 社内で内製なんてとてもできないので外注して作ってもらう感じのシステムが多そう
- 元請けなどだと利益高めな傾向にある(リスクが高いので金払いは良い)
- テストとかもしっかりやるけど、意図しないバグとか起きるとヤバいみたい
- そういえば5G以降は通信もインフラの要求レベルが上がってこっち側に来るみたいな話を聞いた（リモート手術とかに使われるので…）
- 地頭が良い人が多い傾向。腕を見せると信頼が一気に上がったりする。(逆にトラブルになると結構面倒くさい。なぜなぜ分析とかな…)
-
インフラ(重要なやつ 例:免許制の事業なのでミスると国からお叱りを受けるレベルのやつとか)
- 発注側だとやっぱり維持は大変そう。
- やっぱり社内で内製なんてとてもできないので外注して作ってもらう感じのシステムが多そう
- 元請けなどだと利益高めな傾向にあるが、相見積もりで利益は減りがち
- 外的な環境の変化で発注側の利益が全然出なかったりすると一気にしわ寄せが来たりする
- 結構…仕様が複雑怪奇だったりする
- うっかり止まるとニュースになったり国から叱られるので危機感はある
-
インフラ(ふつーのやつ 社内システムとか)
- 結構ピンキリ。蓋開けてみないとわからん
- 大きい会社はしっかりしてる
- 小さい会社は管理がなってないケースもある(要望した資料がどこにあるかわからないので出せないとか)
- 開発規模に応じて見積は出すけど、小さい会社だと予算が足りなくて機能削ったりとかよくある
- 極論、現場の要望がクリアできればオッケーみたいなところも多い。(過去に経験したケースで一番アレだな…と思ったのは、機能改修の予定だったものが詳細検討をするとDBのクエリ1本書いたら終わりだったので、書いて終わったという…)
- この機能は絶対欲しいって請け先に言っちゃうとそこの工数を多めに(こっそり)積まれる。手札は隠そう！ お兄さんとの約束だぞ！(笑)
- 落ちてもお咎めが無くてうまく処理してくれる(しちゃう)ケースもある(特に小さい会社だと…)
- 面倒くさい人がいる事も多い(理路整然と説明してもわかってもらえなかったり)
-
プロダクト(みんな使ってる製品になるやつ)
- これ俺作ってましたね…って言って( ･´ｰ･｀)ドヤれたり、ドヤれなかったり(元請けじゃなく、かつプロダクト作ってる会社が片手で数えられるほどしかない製品だったりすると…)する
- よく使うものとかに関われると、プロジェクト離任後でも 「おっ、今日も動いてるな…」って気分になってちょっと気分がアガる
- 不具合が出るとみんな使ってるものだから大変
- かといって請けや作業単価が高いかといわれると…
-
プロダクト(あまり日の目に当たらないニッチなやつ)
- ドヤりにくい。(そもそもドヤっても伝わらん…)
- ユーザと密にかかわる事になったりもする
- 機器リプレースに行ったりとかある
- 発注側も儲かってない事が結構あるあるで、請けの価格や作業単価もなかなか上がらない
- それでもプロダクトの方が実際に動いてるモノがあるので後から振り返ると個人的には楽しかった
-
就職/転職試験は減点法の事がほとんど。
- 激しくミスすると他が良くても一発アウトという事はある。
- 会社のレベルや求めている事より低いのもダメだが、高すぎるのもダメだったりする。(うちには来ないと思ってお祈りされる… そういう場合はお祈りされたほうが良いのだが。)
- 基本的に会社が欲しいのは利益を出してくれる人(その利益を出してくれるまでの期間の余裕がが短い・長いという差はあれど)
- じゃあ会社がどうやって「利益をその人が出してくれるか」わかるかといえばわからない。
- もしくはどんな人であれ、採用してチームに突っ込んで、その人がある程度指示が通って稼働あげてくれたら利益が出るような会社の場合は…
- そういえば転職の時、エントリーシート見せたら内定通知送ってきた会社とかあったな…(笑)
- 普通の会社は当然めっちゃ悩んでる(採用って結構コストかかる)ので、最低でも採用が失敗してても客観的な説明をできて責任を負わなくていい人を採用したいように思える。
- そういう責任転嫁できそうなのでいうと、いわゆる学歴フィルターとか、有資格者だと説明がしやすいのは自明ですね…。
-
プログラマ３５歳限界説
- ある意味真実だけど、ある意味盛り過ぎだと思う
- 体力だけで無理やり、残業して稼働時間を増やしても体調が維持できなくなってくるのがこの頃
- 転職も３０歳までとか３５歳までの制限がかかってるところはちょこちょこある(ので転職制限にかかる事はある)
- 年齢に応じたスキルがある程度積めていれば、別に３５歳越えてようがエントリーシートは通る。(実際、情報処理技術者試験の高度情報２種類持ってる状態で転職活動してたときはサクサク通った)
- ただし年齢に応じたスキルが積めている事を証明するには資格とかがないとしんどいかも。
こういうことができたら凄いけど、実際問題としておそらく、 全部そんな簡単にいくなら苦労はしないやつです…
- ブームが立ち上がってくる前の言語、環境をキャッチアップして、対応できるようにする
- 担ごうとしたやつが流行らないと辛いよね… ちなみにイノベーションのジレンマに書いてあるイノベーションのジレンマの回避方法だったりします。(この文章を書いてて牛の牛肉って言ってるようやなと思った…(笑))
- 中抜きしている中間の請けを飛ばして契約してもらえるように調整する
- RFPでの受諾開発の際に起きうるケースと、開発から保守フェーズに移った時の契約切り替えのタイミングなどで起きうる感じ
- 私個人だと、これは1回間接的に関わった事があります。顧客と自社はメリット大ですが、元請けは面白くないので政治力とか結構要る… あとお客さんへのアウトプットやフォローアップのレベルが明確に高いとか、元請けがコストだけ引き上げて何もしてない事に問題意識を持ってるとか、かつお客さんの発注までの社内の流れがシンプルなほどうまくいく気がします。
- 自社でプロダクトを作っちゃう
- 作ったプロダクトがほいほい流行る程のアイデアが出たなら、そもそも独立するなり仕事の後の時間を削ってでも自分で書くよねぇ…
多分こっちの方が圧倒的に簡単です。個人の力で組織を変えれてるならみんなやってますよね。この観点でまず要点として一番大事な点は、どの会社も「使える人」は足りてないです… (どのレイヤーにも共通して…)
-
請けの上位側の会社に転職する
- 転職するためにどうすべきなん？という話ですが、全体的にどこもかしこも人足りてないので行った先の会社でコスト対効果をみて戦力になるだろうと思われれば、普通に内定は出ると思います。
-
行った先の会社で戦力になるだろうと思わせるために (1)実務経験の年数と1社の在籍期間が長い
- どのレイヤーでも経験年数に比例して、やった分野の知識と経験はみっちりつくので、経験年数は純粋な評価指標になると個人的には思います。あとは人事的な観点でいうとずっといてくれる人がほしい… (契約時の年収の3～4割とか人材紹介会社が紹介料として持っていくので、ホイホイ転職されるとバカにならないって現職の人事部もこぼしてました。現職はシステム受諾開発の会社ではないですが。)
-
行った先の会社で戦力になるだろうと思わせるために (2)資格でより高度な仕事ができる事をアピる
- 個人的な主観ですが、基本的に入社したときから情報処理技術者試験で資格が2段階ぐらい増やせてたら転職チャンスじゃないかなぁ。
- 例：(入社時)パスポ→基本情報→応用情報 とか
- 例：(入社時)基本情報→応用情報→高度(情報処理安全確保支援士試験とかデータベーススペシャリスト試験) とか
ちなみに資格取ったからといって同じ会社だとすぐに「お前この仕事やってみろ」とはなかなかなりません。 会社としてそういう「新しい仕事」のパイは決まってるし、うまくいってるチーム構成を変える理由が無いのもあって、そんなホイホイまわってこない。(そのくせ困った時だけ泣きつかれて炎上の火消しに行くとかよくありますよね…)
- 個人的な主観が大きく入っているので恐縮ですが、普通に仕事しているケースでは入った時に比べて、その仕事をみっちりこなせるようになると1段階ぐらいは仕事のレベルが上がってるから、資格1枚だと転職してももろもろの条件が現状維持などになる事もありそうだなあと。(転職準備はいつ始めてもいいのですが。)
- あと、「さらにその1段上の知見を有しているが会社としてはいろいろしがらみがあってそういう仕事を振ってはくれないのでスキルアップのために転職を志望しました。」 は転職志望動機としてかなり強い部類だと思うのもある。(ただ、どんな会社でも仕事をえり好みせずこなしてくれる人が欲しいので、うまくそういうのを言う感じになる)
- 色々なところで見たり経験した結果として、応用情報を持ってれば資格だけで言うとIT職の上位1割には到達している気がします… 私も前職はとあるシステムインテグレーター(東証一部)にいてましたが、そこでも1割ぐらいしか持ってなかったのでお察しです。だって資格なくても仕事できる… (みんな実際言うし、仕事できてる人も多いが全然ダメな人も多いよね…)
- 情報処理技術者試験ばっかり例に出すのは、国内の情報システム関連の会社だと一番汎用的にイケると判断してもらえるからです。(ベンダーに依存しないのと、陳腐化しにくい論点を問われる試験なので技術的な賞味期限が長い。大事。あと受験費も安い。ちょう大事。)
- 正直、部、課以上に配属プロジェクトがどうか？によって転職の納得感は激変すると思うので、「行った先の会社が現職より良さそう」な条件の会社がひっかかるまで現職でぶら下がっておく戦略は有用。以下の観点は持とう（実際もっててよかった観点）
- 仕事の募集要項に書いてある給与はどれぐらいか？（募集要項の上限が高くない会社は転職後に昇給するとしても知れている気がする）
- 転職後の給料は上がるのか？現状維持か？実は下がっちゃう？（下がっても残業代無支給→残業代全支給 とかだと実質上がるケースはありうる… 時間給換算で見るべきかもしれない。）
- 通勤時間が短くなるか？
- 仕事の拘束時間が短くなるか？
- 権限は増えるか？
- ＰＣなどの（経営者からみたらわがままにみえる）要望は通るか？
- 面接で出てきた同僚になりそうな人はどうか？（レベル、相性など）
- 勤務時間中に技術のキャッチアップに時間割いたりさせてくれるか？
- 有給消化率は？
その上で、何が良くなり何が変わらず何が悪くなるのか。(転職活動してて良くなるところがなく、なにかしら悪くなるのであれば年齢が高すぎるとかスキルが全然上がってないとか個人に起因する問題も普通はセットで何かしらあるので、転職をしばらく寝かせておいて、資格を拾って再チャレンジするなどの必要があるかもしれない。)
システムインテグレーターが新卒をガンガン採っているのか、新人が流れるようにシステムインテグレーターに吸い込まれているのか、どちらが先なのかは私もよくわからんのですが、新人はシステムインテグレーターに行きがちです。(きっとあの２人 お付き合いされているんですよね？)
じゃあなんでシステムインテグレーターは新人がんがん採ってんの？という話に関してそれっぽい回答を見たことは私もないのですが、恐らく以下のような理由があるのではないかなと思っています。
そもそも、システムインテグレーターの仕事の大半は新規構築ではなく、既存システムの改修維持が主であり、言語・環境が必ずしも最新でない事も多いです。(よって、昨今のWeb系にありがちなラーニングカーブが平易な言語・環境とかを使えるとは限らない。プロジェクトによってはCとかCOBOLとかVBAとかABAPとか… ※注:この項を記載している筆者は全部実業務で触った事が… お察し下さい。) そのため、開発者として人件費比でペイできるのが結構遅くなりがち（1つのプロジェクトが長くても1年ぐらいで終わるので、複数プロジェクトを経験した状態としてだいたい2年あれば誰でも一応戦力にはなってる感じ ※注:これも環境による。ABAPとかは言語さわれりゃオッケー！みたいなものでは全然ないのでもっと時間かかる。）
よく、転職に関するトピックとして、「一つの会社に３年もいられないのに…」というのが出てきますが、どうにも「３年ぐらいいてくれないと会社として研修費用が持ち出しになってしまいけしからん！」みたいな話も実はあるようです。(なので第二新卒とかは、来てくれる会社からしたら旨いので募集してるよね…)
片やWeb系などであれば「１０００時間で〇〇作ったった～」とかごろごろあるので、別に新卒でなくても採用されたメンバーが根付けば比較的早く戦力になるのでは？という気がします。（だいたいそういう環境でやってるところはペアプロなどのXPに関する文化がセットであるのもめちゃくちゃ大きいとは思いますが。正直、私も誰かに教えて頂きたい…）
それらを踏まえてどっちがいい悪いという話でいうと、どっちもどっちなのじゃないかなと思いますが、 これらの事情でシステムインテグレーター→Web系転職エントリは多いのに、Web系→システムインテグレーター転職エントリは少ないんじゃないかなと個人的には思っています。 (正直なとこ、システムインテグレーターだってWeb系の人とか欲しいんですよ？顧客からの引き合いも多かったりするので。 そういう理由からWeb系の社内勉強会やってるとこも多いです。でもなぜかオープン系のカンファレンスではシステムインテグレーターって会社の規模比でいうとなかなか見ない気がするのですが… 気のせいだろうか。)
転職のインターバルに関しては、個人的にはシステムインテグレーターからWeb系に行くにせよ、システムインテグレーターに再度転職するにせよ、1度入社したら３年ぐらいは腰を落ち着けて仕事するのが、得るものが多くて良いと思います。(個人的には、ある程度いろいろ経験しないと他に持っていけるレベルに知見を昇華しにくいんじゃないかな…と勝手に思ってるだけですが。)
転職に関しては情報処理技術者試験を取れていくと、いろんな企業にドアノックしたときの書類選考の通過率が資格が増えるに伴って激増する(貫通率が上がるという表現が一番しっくりくるかも)ので、受かれば突っ込んだ時間以上の価値はあると思います。保険力が強い。(あと、会社をやめたくなってから準備するのでは一手遅い事があるのも悩ましいですね。半年に1回しか受験チャンスがないので。)
あと全然関係ないのですが、どの会社でもＳＥならＩＴ全部わかってるだろう…とか、誤解がひどいにも程があるのですが、Excel、Word、Powerpointぐらいはある程度触れて人に指導できるようになっておいたほうが無難なきがします。（専門的にやってなくても答えられないとなぜか客に舐められたりするので…）