What is it, naokirin?

プログラマ35歳定年説について就職前の学生が考えてみた

最近、よくプログラマ35歳定年説についてのブログの記事がTwitterで流れてきます。

実際はもともと有名な話で、おそらくたまたまTwitterでフォローしている人数が増えたから多くなったように感じているだけだと思います。

でも、私もそちらの業界を目指す学生のはしくれ。多く見かければ、気になります。

35歳定年説とは

そもそも、35歳定年説とは一体何でしょうか。
簡単に言えば、文字通りプログラマは35歳で定年(プログラマ職としてやっていけなくなる、別の職へ移行する)ということのようです。

35歳定年説については理由が諸説あるようですね。私が見かけた中でいえば、例えばプログラマ本人の側にあるとか業界の体質にあるとか、様々です。


さて、もう少し掘り下げて調べてみたいと思います。
まずはWikipediaプログラマについて調べてみます。

プログラマ(programmer)とは、コンピューターのプログラムを作成する人全般を指す。プログラマーとも表記される。

なるほど、つまりはプログラミングをやっている人はみな等しくプログラマと言うわけですね。


一方、システムエンジニアの項目を眺めてみます。

システムエンジニア(SE)とは、日本の情報システム分野におけるコンピュータ技術者の分類の1つである。情報システムの要件定義、設計、開発、運用などや、それらを統括管理するプロジェクトマネジメントなどに従事する者をこう呼ぶことが多い。

主に上流工程(要件の整理や見積もりなど)を中心とする事が多く、プログラマやハードウェアの保守を行うカスタマーエンジニアなどとは区別される。


よく比較されるSEは、やはり上流工程を主に担当するイメージのようですね。ただちょっと下を見ると

プログラミング環境が進化した現代のシステム構築では、システムエンジニアプログラマを兼任することも多くなっている。

という文もあるので、そこまで明確な区分があるわけではなさそうです。


さて、そこで本題のプログラマ35歳定年説についても、Wikipediaから引用して見てみます。

プログラマ定年説

プログラミング技術は進歩が激しく、技術の陳腐化も著しいため、常に新しい技術に目を向け習得していくバイタリティや、場合によっては永年の努力によって培ってきた技術を捨て去る柔軟性が必要である。また、年功序列的賃金体系のもとでは、高年齢のプログラマはコストが高すぎると考える企業がある(特にプログラミングを単純作業と考える企業に多い)。俗にIT土方とも呼ばれデスマーチとなった場合は徹夜が続いたり体力が必要となってくる。そのため、プログラマとしての限界は30〜35歳前後であるという説が存在した。これは「プログラマ35(30)歳定年説」と呼ばれる。現在では経験豊かなプログラマにも一定の需要があり、プログラマ定年説はもはや過去のものとなっているが、コストの観点からは、一定年齢に至ったプログラマに、より単価の高いシステムエンジニアや営業へ転向がすすめられることがある(参考:SEと記者,どちらが短命?36歳になって思う「プログラマ35歳定年説」)。

なお、NT開発者で知られるマイクロソフトデヴィッド・カトラーは60歳超えてもソースコードを自ら記述しており実例からもアメリカにおいては35歳定年説は否定されている。ただし、パソコン黎明期といわれた1980年代のアメリカにおいては、30歳までに巨万の富を稼ぎ、そのまま引退する事例も多い。(HyperCard の開発者ビル・アトキンソンなど)対して、日本では、長時間労働、下流工程での賃金の頭打ちなどにより35歳定年説がささやかれている。

この文章を見る限り、そもそも日本だけで言われていたことではないようにも見えますね。

日本で言われている35歳定年説はプログラマ側からすると「長時間労働、下流工程での賃金の頭打ち」、逆に雇用する側からすると「高年齢のプログラマはコストが高すぎる」というのがあるのでしょうか。

この辺りは最近の実情としてはどうなのでしょうか。
さすがに私はIT業界で働く身ではないので確かなことは分かりませんが、やはりIT業界でプログラマとして働いていると言う人は、若い人が多いような気がします。
もちろん日本でも反例はたくさんいらっしゃると思います。ただ、反例があれば、だれしもがそこから脱却できるという話でもないと思います。特殊ケースを挙げて「あの人ができているから、みんなできるはずだ」なんていくらなんでも無茶です。

ではそもそもの解決策は無いのでしょうか。
最近の議論でよく聞くのは、「下流工程の軽視によるもの」による起因と、「プログラマ自身の変化への対応とスキルアップ」が問題視されています。

「下流工程の軽視」

下流工程はいまだ軽視される傾向にあるみたいですね。

プログラマに与えられることは『仕様と納期』」。そんな話はよくネット上にあります。

そういうことをする人たちは一体どのように下流工程を見ているのでしょうか。


「仕様通りに作ればいいのだから、知的労働ではない」
「バグを作らないように作ることは難しくない。プログラマが頑張れば100%バグの無いものが作れる」
プログラマが頑張れば、納期に仕様通りのものが作れる」


ネット上での意見はこんな感じなのでしょうか。

プログラミングをやってみると即座にこんな冗談は考えられなくなるのとは思います。
この状況が日本のたIT業界の大勢を占めているというのであれば、非常に残念ですね。
実際にこの状況を改善したいと思う人もいらっしゃるようですが、下から変えていくと言うのは難しいようです。こればかりは、下流工程のことをある程度知っている人、分かってくれる人が上司になってくれることを祈るしかなさそうです。

プログラマ自身の変化への対応とスキルアップ

これはRuby合宿で35歳定年説の話ではないですが、それに近い話を企業でプログラマとして働いている方としました。


「技術・知識を率先して継続的に学ぶことは重要」
この話はでました。

「この先、IT業界に行くなら、自分の将来の道のようなものは早めに考えておくべき」
キャリア戦略ですね。


これを明確にもっている、そして実践できている人は意外と35歳定年説を乗り越えられるのかなと思います。プログラマ側ができるのは継続的学習とキャリア戦略。そして変化を良しとする心を持つことでしょうか。

私の結論

35歳定年説には「社会に出て様々な業界をみて、プログラマとしてのやる気が失われてしまう。」「他の業界への興味や賃金、労働時間等による別業種での優遇を知って転職する。」こういうことも含まれていると思われます。
もちろん、これを35歳定年説と言うのであれば、それほど大きな問題でもないと思います。


ただ、プログラマとしてやりたくてもやっていけなくなる状況のプログラマはどうすればいいのでしょうか。
プログラマ側ができることと言うのはそこまで大きいことではないようです。
ですが、なにもできないわけでもなさそうです。


継続的に学習を重ね、スキルアップを図る。そして自分の将来設計を明確にしておく。
変化を恐れず、そこへ飛び込むような心すら時には持たなければプログラマとして長くはやっていけない。

これができることのようです。
たまに聞く話では、下から変えていくことも時には恐れず挑戦することも必要みたいですが。
とはいえ私は学生の身分です。もっと実情は異なり、そしてそれほど甘くはないのかもしれません。