第16回 キャリコン事例（9） ITエンジニア35歳定年説の壁
こんにちは、キャリア・コンサルタント高橋です。
今回のキャリコン事例は、『ITエンジニア35歳定年説』という言葉を知ったITエンジニアの話です。ITエンジニアにとって35歳定年説が指し示すモノとは一体何なのでしょうか？ そして、それを超えてキャリアを創り出すためにはどのように考えればいいのでしょうか？
それでは、始まりっー！ ……って、今回もちょっと長めの話ですので、途中で休憩を入れながら読んでください。
…………
■相談者のプロフィール
佐々木さん（男性・25歳）、小規模ソフトハウスのITエンジニア。業界経験3年。専門はWebアプリケーション開発で、得意言語はC#、VB.NETなど。
佐々木さん 「入社以来、社内でWebアプリの開発を行っています。主に.NET系での開発で、詳細設計、コーディング、単体テストなどを担当しています。それ程規模が大きくない案件を担当しているので、担当しなくてはならない範囲は多いのですが、その分任せてもらえることも多く、やりがいのある仕事だと思っています」
佐々木さんはちょっと小柄な方ですが、受け答えの反応は早くしっかりしているので、俗に言う“頭の良い”ITエンジニアのようなイメージがあります。
佐々木さん 「最近、先輩から『ITエンジニアは35歳あたりで終わりになるだろうから、それまではしっかり働けよ！ 』と言われました。意味がよく分からなかったので聞き直したところ、IT業界には『35歳定年説』という考え方が昔からあることを教えてもらえいました。一般的に、ITエンジニアはIT土方※と言われるほど労働環境が苛酷なので、肉体的にも精神的にも長く続けられる職業ではないということらしいんです。そう言えば、私も他業種の仕事をしている同年代の友達と比べ、圧倒的に多く働いているような気がします。もし、この35歳定年説が本当なら、私は後10年程しかITエンジニアとして働けないことになります。それを思うと、この先どうすればいいか思い悩んでしまいます……」
※IT土方：ITエンジニアの別称。ITエンジニアの仕事は地味で単調で長時間に及ぶため厳しい労働環境となるケースが多く、これを建設・土木業界における土方（土木作業員）に見立てた言葉。筆者のイメージですが、どちらかと言えば蔑称（べっしょう）の意味で使われることが多いような気がします。
佐々木さんは今の仕事にやりがいを感じている半面、重労働が続くIT業界で長く働けるかを気にしており、この先どうすればいいか分からなくなっているようです。そこに迷いがあるということは、佐々木さん自身はこの先もITエンジニアとして頑張っていきたいとお考えなのでしょうか？
佐々木さん 「そうですね。自分で言うのも何ですが、私はこの仕事が向いていると思います。コツコツと設計書を書いたり、コーディングをしたり、テストでバグをつぶしたりする仕事が自分の性格に合ってるような気がします。できるならばこの仕事をずっと続けていきたいと思っています」
佐々木さんはITエンジニアの仕事が自分に向いていると感じており、この先もITエンジニアとして働いていきたいと思っています。それでは、ここで佐々木さんの想いをまとめ、問題点をはっきりさせてみましょう。
《佐々木さんの想い》
・ITエンジニアの仕事がはやりがいもあり向いていると思っているので、この先もITエンジニアとして働いていきたい
↓
・しかし、IT業界は重労働が続くため、35歳になるころにはITエンジニアとして働けなくなるとも感じている（35歳定年説の壁）
↓
・この先どのようにすれば35歳定年説の壁を乗り越えられるのか、その方法が知りたい
佐々木さん 「そうです！ 35歳定年説の壁を乗り越えるために、何をすればいいのかを知りたいです！ 」
そのためには、まずITエンジニアにおける35歳定年説の本当の意味を理解していただく必要がありますね。一般的にいわれている35歳定年説には大きく分けて2つの問題が含まれています。
1つは“就業環境”の問題。
ITエンジニアの開発現場では稼働時間が高くなってしまうことがよくあります。その原因を掘り下げてみると、以下のようになるのではないでしょうか。
《ITエンジニアの稼働が高くなってしまう原因》
- プロジェクト管理が杜撰なことで起こる納期遅延で、プロジェクト全体の作業工数が肥大する
- 上流工程（要件定義、基本設計）で検討や考慮が漏れた機能や仕様を下流工程で吸収しようとすると、下流工程の作業工数が肥大する
このような状況で仕事を続けていると、肉体的にも精神的にも体調を崩しかねません※。しかし、これら健康面について言えば、近年はかなり環境が整備され改善されつつます。
※体調を崩しかねません：その最たる例がうつ病に代表される精神疾患です。
《ITエンジニアの健康面への配慮》
- 肉体的負担への配慮：時間外労働（残業）時間については、会社と社員との間で三六協定※を締結させることで、協定で決められた時間外労働時間をオーバーしないように会社が社員の時間外労働時間を管理しなければならない
- 精神的負担への配慮：会社は労働契約法における「安全配慮義務」を遵守しなければならないため、会社は社員のメンタルヘルスについてもコンプライアンス（法令遵守）の観点から対応しなければならない
※三六協定：労働基準法に記載されている法令で、時間外労働や休日労働について会社と社員とが取り交わす協定のこと。労働基準法第36条に記載されていることから、三六（さぶろく）協定と呼ばれます。実際は三六協定を超えてしまう時間外労働や休日労働が発生する場合もあり、これらは特別条項として、あらかじめ三六協定に明記しておくことで特例として認められます。これを特別条項付き三六協定と呼びます。
こういったことを考えると、ITエンジニアへの健康面のリスクは少なくなっており、このことを原因とした35歳定年説の考え方は近年成り立たなくなってきています。それでは、就業環境の問題ではない35歳定年説のもう1つの問題とは一体何でしょうか？
それが2つめの“報酬と技術スキル”の問題です。
この話は報酬と技術スキルに分かれますので、まずはITエンジニアの報酬から見てみましょう。一般的にシステム開発が行われる場合、それはプロジェクトによって管理されます。このとき、プロジェクトを遂行させるための予算がプロジェクト・オーナーから与えられます。言い方を変えると、プロジェクトは与えられた予算以内で目的であるシステム開発を実現させなければならないのです。
このシステム開発にかける予算のうち、一番多くの予算が割り当てられているのが人件費といわれています。その金額はプロジェクトよとって違いはありますが、プロジェクト総予算の50～70％程度です。プロジェクトは、この限られた人件費からシステム開発に携わるITエンジニアを調達しなければなりません。
ここで、ITエンジニアの契約単価について考えてみます。例えば、以下のエンジニアを見てください。
Aさん：年齢25歳、業界経験 3年、契約単価50万円／月
Bさん：年齢35歳、業界経験13年、契約単価60万円／月
この2人のいずれか1人にプロジェクトへ参加してもらうとします。当然、2人ともプロジェクトで仕事をするための技術スキルを有しています。プロジェクトはどちらのITエンジニアを選択するでしょうか？ 当然、Aさんですよね。理由は単価が安いからです。プロジェクトの視点で見れば、同程度の技術スキルを有しているなら、より単価が安いITエンジニアを選んだ方が人件費の削減に繋がるからです。
それでは、この話をちょっと脇に置いておき、ITエンジニアの技術スキルに進みましょう。ここでは、技術スキルとしてコーディング技術について考えてみます。以下のコーディング方法について見てください。
C：最先端のプログラミング技術を駆使し、実行速度やレスポンスは非常に優れているが、内容が複雑すぎてメンテナンスがしづらいコーディング
D：世間一般で広く使われているプログラミング技術を使用し、実行速度やレスポンスは必要最小限システム要件を満たしている程度だが、メンテナンスしやすいコーディング
この2つのコーディング方法のうち、どちらが実際のシステム開発で使われるでしょうか？ これは、その時のシステムの要件にもよりますが、ほぼDになるのではないでしょうか。システムは一度構築したらそこで終わりではなく、システムが稼働し続ける限りメンテナンスされる可能性があります。そのため、開発後にメンテナンスすることも考慮し、一般的には、誰にでも分かりやすく、メンテナンスが行いやすいコーディングを心がけることが求められます。
これはもっともな話ですが、このような案件ばかり対応していると、ITエンジニアの技術スキルどのようになっていくでしょうか？ 素直に考えば、誰にでも分かりやすく、メンテナンスしやすいコーディング方法を身に付けたITエンジニアになっていきます。それ自体は素晴らしいことなのですが、ここに1つ落とし穴があります。この「誰にでも」という言葉をよく考えてみてください。この言葉には当然経験年数の少ないITエンジニアも含まれています。そうです、経験年数の少ないITエンジニアでも理解し対応できるような難易度でコーディングをすることが求められているのです。これを逆に考えると、一部のITエンジニアしか理解できないような難易度の高い技術スキルは、一般的なシステム開発では求められていないということになります。ITエンジニアである以上、より高度な技術スキルを身につけて、システム開発に生かしたいという想いがあるかもしれません。しかし、実際のシステム開発では高度な技術スキルより、誰にでも分かりやすく、メンテナンスしやすいことが求められやすいのです。
このことを裏読みすれば、ある一定水準以上の技術スキルは実際のシステム開発では必要とされないため、これまで対応してきた案件と同じ難易度の仕事が続く限り、無理に一定水準以上の技術スキルを身に付けなくても対応ができることを暗に示しています。そして、それはITエンジニアの技術スキルの成長を止めてしまうことに繋がります。そうなると、ある一定の段階に達したITエンジニアはそこで市場価値が止まってしまうことになります。
この話には、さらに続きがあります。日本にはまだ終身雇用の考え方が根強く残っています。これは、その会社に入社したら定年まで働き続けられるという考え方ですが、当然、入社時の給料のまま定年を迎えるということはほとんどなく、金額の大小はともかく、徐々に給料は上がっていきます※。ここで考えなければならないこととして、給料を上げるためには、給料の原資を引き上げなければなりません。ITエンジニアにとって給料の原資はプロジェクトにおける契約単価ですので、給料を上げるということは給料の原資であるプロジェクトにおける契約単価を引き上げなければならなりません。それは、技術スキルが身に付いていないにもかかわらず、単なる経験年数だけで契約単価が上がることを表しています。
※徐々に給料は上がっていきます：求人募集欄にある「昇給年1回、賞与年2回……」の記載がそれにあたります。
ここで最初のITエンジニアの“報酬”の話に戻ります。先ほど出てきたAさんとBさんの話をもう一度見てください。もし仮にAさんの技術スキルがこの段階で止まったとして、そこから10年経ったらどうなるでしょうか？ そうです、Bさんになるのです。つまり、BさんはAさんの10年後の姿だったのです。最初の選択では、当然のようにAさんを選択しましたね。それでは、選ばれなかったBさんはどうなるのでしょうか……？
これが、もう1つの35歳定年説の考え方です。
それでは、このようにならないためにはどうすればいいでしょうか？ それは、ITエンジニアとしての付加価値を高め、プロジェクトに必要とされる人材を“自発的”に目指すことです。
《プロジェクトに必要とされる人材の例》
- プロジェクト・マネージャ
- 要件定義、基本設計といった上流工程を担当できるシステムアーキテクト（上級SE）
- サーバ、ネットワークなどインフラ基盤構築が行えるスペシャリスト系エンジニア
このように、プロジェクトに必要とされる人材を自発的に目指してステップアップするということは、ITエンジニアとして生き残っていくということも意味しているのです。
佐々木さん 「なるほど、35歳定年説にはそんな意味が込められていたんですね。仕事自体は楽しいのでこのままずっと続けていきたい気持ちはありますが、それだけだと10年後には通用しなくなっているかもしれないですね。プロジェクトの視点に立って、もっと単価が高い仕事が取れる付加価値のあるITエンジニアを目指すことが、この先、ずっとITエンジニアとして続けていくことになるんですね。ちょうど今やっている仕事の先にプロマネや上流工程の仕事がありますので、まずはその仕事ができるよう、頑張ってみたいと思います」
それでは、また次回お会いしましょう！