【第7回なんちゃってSEのゆらゆら日記】35歳定年説

そういえば、『35歳定年』というまことしやかな話があったなぁ。
あの話は今も生きているのだろうか。
検索してみると意外と出てくる。

35歳前の時は、どきどきしながらどうやったら何をしたら逃れられるのか。
いや、いっそ違う仕事に就くべく行動をとっていくべきか。

まぁ、悩みはつきないと思ったものだ。

結果的に大きく超えてもなんとなく業界に喰らいついている。

あれは、なんだったのか。
経験的に振り返ると、そこを乗り切れるかどうかはそれなりに重要な気もする。
他人の設計でコードを組むしかないプログラマーだと、たしかに超えられない人が多い。

私が超えられたのは、設計もするけどコードもテストもやってねっていう何でも屋な仕事を求められる時期があり、それが結果的には35歳定年説に抵抗できたのではないかと考える。
プログラムは組めるけど、設計はできません。
となると、工程としては製造と単体テスト（通常は両方合わせて一工程）までしか担当できないだろう。

なるべく上流工程から本番リリース、なんだったらリリース後の稼働確認くらいまで携われると見えてくるものが違う。
同じシステムを保守でもいいので、長く長く担当し仕様を知ることはもちろんのこと、開発時の注意点やシステムの背景や歴史のようなものまで知り尽くすと設計書には載っていない、載せるようなものではないとしても知識があることは強味なので、定年を意識することなく仕事を獲られる可能性が増すだろう。

ということが書かれているのが

エンジニア 35歳 / 定年説を検証

「エンジニアの定年は60歳じゃなく、35歳だ」そんな話を聞いたことはありませんか？最近では冗談半分で使われることも多いフレーズですが、少し前までは35歳定年説がIT業界の常識となっていました。では、

おっしゃることはごもっとも。
とも思うけど、なかなか難しい。

プロジェクトが縮小するから人員整理が必要となると、できる人よりも自社正社員を残すようにするため、長く続けたくても続けられない場合はよくある話。

ちょっと話は変わるが、この業界だけに関わらず仕事を引き継ぐとか、仕事を説明するとなると作業手順を伝える。
なぜその作業が必要なのか、こういう情報が必要だからこの作業が必要だなどという説明は省かれて、作業の手順のみを伝えてくる。
伝える人が理解していないから作業手順を伝えることになるのだろうが、伝えられたほうも理解していないからルーチン作業となる。
だいぶたってから「そういうことか」みたいな気付きはあるけど、そこまでの道のりが無駄だ。
作業手順についてもアレ、ソレ的な、自分よがりな説明をする人も多い。
説明を受けるほうは、呑み込めていないから何を質問していいのかもわからない。
質問がないから理解しているのだろうと判断するのだろうが、「そういうことか」と思ったころに“あいつの説明最低最悪だ。（説明した人に対する評価は言わずもがな）”となる。
ようするにきちんと相手に伝える説明ができる人が少なすぎる。
この上手な説明ができるというスキルは大きな武器だと思う。