0. そういえばもう半年以上たってた
世の中の状況もいろいろ変わってるし、転職前後の自分を少し振り返ってみることにする。
自分の場合、家族の事情や自分が当時私的に抱えていた役職なんかもあるわけで、そのあたりをつまびらかにすると収拾がつかなくなるのと、これらの対策に必要なものは、極言すると自分の待遇に行き着くので、一番わかりやすい金銭面にフォーカスして書いてみることにする。
言い換えれば、キラキラした希望とかそういうものがあっての話じゃないことは、先に断っておく。
1. 前職でのざっくりした業務
前職での僕の動き(?)はざっくりこんなところ。あえてネガティブな書き方をしているのはご了承いただきたい。
- 1年目 : 異業種からの転職組で特に技術があるわけでもなかったので、大手SIerにフィールドエンジニアの間接派遣としてねじ込まれる(いわゆるSES要員)
- 2、3年目 : 同上
- 4年目 : 同上、派遣先のプロパーの張った罠に引っかかってしまったことが転機になり、「これではだめだ」とようやく必死に勉強するようになる
- 5年目 : 同上、必死に勉強したおかげで、つたないながらも自力でAndroidアプリを公開するまでに至る
- 6年目 : 一次受けとプロパーとの間の契約が終了したため自社に戻る、社内でなぜかAndroidの第一人者に祭り上げられる
- 7年目 : Androidの案件が結構降ってきていたので、ひたすらAndroidの案件をやるが、それもなくなってきてWebアプリの案件もやり始める
- 8年目 : ある案件でいきなりPLが引き抜かれて、ところてん式にプロジェクトリーダーならぬプレイングリーダーになってしまい、自爆する
- 9年目 : 自爆の影響か再びSES要員に、しかも入場先は県外で、また間接入場
- 10年目 : 同上、転職を決意、水面下で活動を開始
- 11年目 : プロパー側の入場者人員整理の結果、県外SES案件が終了、転職活動の成果が実り、ついに転職
こうしてみるとこの並び、キャリア形成としては碌なもんじゃないな、というのが正直な感想。
しかも、自社に戻る理由が自社からの引き揚げ指示ではなく、相手先の人員整理が理由というのも、はたから見たらただのお荷物にしか見えないだろう。
実際そうだったんじゃないの？と言われたらそうかもしれないが。
で、自分が仕事を通じてやりたいことと、実際に自分がやれることがそのまま一致する人はそうそういないんじゃないか、とも思うけど、今から思えばその「不一致による違和感」を顕著に感じだしたのは、上記でいう８年目～９年目のさなかに起きたある事件からだったように思う。
当時、n次受けとはいえご新規のWebアプリ開発案件が舞い込んできて、どういうわけかその要件定義を行うことになったのだが、「Javaを使うということ以外何も決まっていない」ということだったので、これ幸いとJava SE 8 + Spring Bootによる開発を推して見事これが採用された。
当時の僕は、うれしさのあまり
....というツイートを残していたのだが、この案件は自分がやりたい、と願っていたにも関わらずそれが本格的に滑り出す直前、自分が外されて県外SES要員になってしまった。
前職では、半年に１回程度1 on 1を上長とやるのだが、そのときに「この(Java 8 + Spring Boot)案件はお前にやってほしかったのにな～」という発言を上長から賜った。
なお、僕を県外SES要員にした人物と同一人物である。
県外SES案件にアサインされている間に、当時町内会長を拝命していたのにまともな活動もできずに終わることになり、そのうえ家庭内の状況も悪化の一途をたどることに。
家庭から悪い話を聞いたら自宅に帰って対応をするわけだけど、会社からは交通費が月あたり１往復分しか支給されないので、残りの交通費は自腹である。これが何気に重くのしかかる。
で、あるとき異変に気が付く。極端に給料が少ないのである。
家庭の状況は悪くなる一方だが、帰ってケアに当たろうにも移動のための交通費が捻出できない、というジレンマに陥ることになる。
結果、何もできない間に状況だけ悪くなる、という悪循環に陥ることに。
2. たまたまため込んでいたエビデンス
僕は前職での給与明細をほぼすべて保管していた。
何か目的があったわけでもなく、これはもうたまたまとしか言いようがなかったんだけど、「これは何かの縁だ」と思って手元にある給与明細の棚卸を始めることにした。
今回はMicrosoft SQL Serverを使ってみた。DDLはこんな感じ。
USE [salary]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[会社](
[会社番号] [int] NOT NULL
[会社名] [nvarchar](32) NULL
CONSTRAINT [会社_pk] PRIMARY KEY NONCLUSTERED
(
[会社番号] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[給与履歴](
[id] [int] IDENTITY(1,1) NOT NULL,
[支給日] [date] NOT NULL,
[差引支給額] AS ([総支給額]-[控除合計]),
[総支給額] [int] NOT NULL,
[控除合計] [int] NOT NULL,
[基本給] [int] NULL,
[休日手当] [int] NULL,
[時間外手当] [int] NULL,
[深夜手当] [int] NULL,
[その他] AS (((([総支給額]-[基本給])-[休日手当])-[時間外手当])-[深夜手当]),
[出勤日数] [float] NULL,
[休出日数] [float] NULL,
[有給使用日数] [float] NULL,
[普通残業] [float] NULL,
[深夜残業] [float] NULL,
[特別休出日数] [float] NULL,
[特別残業] [float] NULL,
[会社番号] [int] NULL,
[賞与] [bit] NOT NULL,
CONSTRAINT [給与履歴_pk] PRIMARY KEY NONCLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[給与履歴] ADD CONSTRAINT [DF_新給与履歴_総支給額] DEFAULT ((0)) FOR [総支給額]
GO
ALTER TABLE [dbo].[給与履歴] ADD CONSTRAINT [DF_新給与履歴_控除合計] DEFAULT ((0)) FOR [控除合計]
GO
ALTER TABLE [dbo].[給与履歴] ADD CONSTRAINT [DF_新給与履歴_基本給] DEFAULT ((0)) FOR [基本給]
GO
ALTER TABLE [dbo].[給与履歴] ADD DEFAULT ((0)) FOR [賞与]
GO
早い話このテーブルに給与明細の数字をINSERTして
select
datepart(year, [支給日]) as 支給年,
sum([差引支給額]) as 差引支給額計,
sum(総支給額) as 総支給額計,
avg(基本給) as 基本給平均,
max(基本給) as 最大基本給,
sum(普通残業) + sum(深夜残業) + sum(特別残業) as 残業計,
(sum(普通残業) + sum(深夜残業) + sum(特別残業)) / 12 as 月残業平均,
(sum(差引支給額) / 12) as 月平均手取り,
count(支給日) as 明細枚数
from 給与履歴
group by datepart(year, [支給日]);
みたいなSQLで分析していくわけである。まぁ、SQL Serverを使ったのは、「あまり使ったことがないものをあえて使うことで、やれることのすそ野を少しでも広げよう」というやつである。それ以外の意味はない。
これで約10年分の給与明細を入力したところ、いくつか見えてきた。
- 入社後５年間は基本給が上昇していない
- 同様に、入社後６年間は、月平均35時間程度残業していた
- 入社後７年目に給与テーブル改訂が行われた関係で基本給が上がったものの、その後はじりじり減っていた
自爆後の下げ幅が一番大きかった
- 県外SES要員になってからは年合計で残業が60時間だった
早い話、自分の収入は長時間残業に支えられていたわけで、残業がほとんど発生しなくなった県外SES要員になってからは、その残業ブースト分がなくなったため給料が下がった、ということだ。
残業がないこと自体は素晴らしいことなんだけど、自分の仕事にはその程度のお金しかついてこないと考えると悲しいやら悔しいやら、分析していた当時は複雑な気分だった。
3. 「これではだめだ」(通算２度目)
と同時に、前職における僕の価値とはその程度だった、ということが改めて認識できたので、「これではだめだ。システムエンジニアとしての自分はこのままだと腐るだけだし、何よりも家族を養えない」とここでようやく転職を決意。
自分のスキルの棚卸をやり、効果的な職務経歴書の書き方を調べ、履歴書を送った会社は現職を含め10社だったが、うち面接までこぎつけたのは4社ほどしかなかった。
特に、ハロワ経由で紹介されたところは、履歴書を送っても音沙汰なしのほうが多かった。法律上、求人票を出さないといけないんだろうけど、採用するつもりはないということなのか。
スキルの棚卸については、カイゼンジャーニーという本で触れられていた星取表が役に立った。
これをもとに履歴書を書き、目当ての会社に履歴書を送るのだが、n次受け案件ばかり、しかもいわゆる下流工程ばかりをやってきた自分にとっては、職務経歴書をどう書くかでとても苦労した。そのまま案件を列挙したら、数だけ多くて何をしていたのかさっぱりわからないのである。
最終的には特徴的な部分だけ切り出して短いレジュメ形式にすることで、どうにか職務経歴書の体裁を整えることができた。
そして10社目にして、ようやく採用の内定をいただくことができた。調剤薬局の社内SEというポジションである。本当に運がよかったとしか言いようがない。
4. そして転職へ
ただ、前職には転職活動をするなど一言も言わずに、すべて気が決まってから「転職するので辞めさせてください」と切り出したので、そこから(大っぴらには出さなかったものの)裏切者扱いである。
すべてが決まってから退職を切り出した理由は単純だ。SES要員としての前職に未練はなかったことと、家族を養わなければならない手前、無収入になる瞬間の発生は是が非でも回避せねばならないことだったからだ。
とはいえ会社から見たら、あてにしていた人員が抜けることで事業計画の練り直しになってしまったわけだから、「会社に損害を与えた裏切り者」とみなされても不思議ではないだろう。気にならなかったけど。
Twitter界隈でも、SESの駒になっていた人の転職では一悶着あった話ばかり伝わって来るので、SESが絡む転職では100%の円満退職なんてものは幻想にすぎないのだろう。
もっとも、相当バイアスがかかっていそうではあるが。
現職に転職した後はどうなったかというと、収入も家族との時間も満足のいくものになったし、何よりも棄民同然のSESとは違い、自分の手が届く範囲で自分の技術でひとつずつ問題を解決していくところが性に合っていた。
これも生存者バイアスと言えばそうかもしれないが。
5. 得られた学び
- 給与明細は残しておこう、いざというときに役に立つ
- 転職サービスは複数のチャネルを持っておこう
- 自分の棚卸は定期的にやろう
最近のコメント