○○歳定年説

更新:2016/04/07

retirement-age

巷では、ITエンジニアはX歳程度になると、コストパフォーマンス的に利用価値がなくなる、と言われていました。
(Xには35とか45とかが入ります)
ほとんど都市伝説です。年齢よりも個人の能力の方が大事です。
とはいえ、簡単に解説しておきたいと思います。
例えばプロジェクトの予算配分で考えてみましょう。

開発コストとエンジニア単価

開発予算が3000万円のプロジェクトがあったとしましょう。
かつ、人件費は以下のとおり。
若手エンジニア単価:月30万円
年配エンジニア単価:月60万円
この条件ですと予算の中で、
若手エンジニアは100ヶ月雇うことができますが、
年配エンジニアは50ヶ月しか雇うことができません。
そのため、この例では年配エンジニアは若手に比べて倍近い生産力がなければ、不利ということになります。(とはいえ、現実はここまで如実な年功序列にはなりません)
とはいえ、然るべき経験と学習を積めば、ひとりのエンジニアが新米エンジニアの10倍の成果を出すこともできます。
結局は個人の能力次第というわけです。

年功序列制度の功罪

日本の企業には以前から年功序列の慣行があり、『長い年月を勤めると必ずしも能力に比例せず待遇がよくなる』というスタイルが定着していました。
欧米型の雇用システムからすると、これは異質なものですし、外資系やベンチャー企業からは、悪しき文化と扱われることがあります。
しかしながら年功序列にもいいところがあります。それは、『腰を据えた教育体制を構築できる』という点です。(閉鎖的で封建的と言えばそうなりますが・・)
ガチガチの成果主義&学歴主義の元では、できる人は勝手にでき、できない人はずっとできない、という状況になりがちです。
一方、年功序列的な組織の場合は、『基本的にはずっと在籍して、上下関係の中で業務知識を学び続ける』という構図になります。また、会社への帰属意識も高いようです。
まあ、どちらが正解かはわかりませんが、ほどほどに成果を見てもらえ、ほどほどに腰を据えられる会社がいいな、とは思います。
大事なことは、どんなやり方の会社が自分に合っているか、ということではないでしょうか。

年齢と立場

従来型の体制では、年齢とともにエンジニアはマネージメント職などにシフトしなければならないケースが多いです。
しかしWEB系の企業や前進的な企業では、給料に見合う生産性や創造性を発揮できれば、シニアエンジニアとして開発現場で活躍し続けられます。

このページをシェア Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn