IT 業界には「エンジニア 30 歳定年説」というものがあります。IT 技術の進歩は日進月歩で SE は 30 歳を過ぎたら情報技術に頭が追いつかず、引退を余儀なくされる、という意味です。これは白亜紀から議論されてきたことで、正直この話題は扱うかどうか悩んだのですが、SNS 上で未だにこの議論がなされているのをみて、本ブログでも取り扱うことにしました。
まず「エンジニア 30 歳定年説」の真偽について結論を申し上げます。
というか、これが事実だとして、30 歳以上の SE がこの世から消えたとしたら、IT 業界は成り立たないと思います。このテーマを扱っているひとにしても、この説について真面目に考えているひとはいないと思います。単純に雑談というかネタとして扱っているものかと思います。僕もそうです。この言葉を知らなかったひとや IT 業界に関わっていないひとに向けて申し上げると、はっきり言って取るに足らない話だと思ってもらって大丈夫です。
「エンジニア 30 歳定年説」みたいなどうでもいい話はさておき、これを聞いて思いついたことがあったので、それらについて徒然なるままにお話しようと思います。
エンジニアは後発のほうが技術的に有利
人間の身体的なピークは 20 歳前あたりで、それ以降は老化の一途を辿るとされていますが、20 代が社会人としてピークということはありません。大抵の業界では「若さ」より努力によって積み重なる能力や経験が物を言うことが多いです。士業や医療などでは若いほうが不利なこともあるでしょう。逆に「若さだけ」が物を言うのはアスリートくらいのものだと思います。
SE の世界で言うなら若い世代（或いは後発）のほうが技術的には有利であることは間違いないと思います。僕のような昭和生まれはよほどの興味がない限り学生までで日常的にコンピュータに触れていたひとは少なかったと思います。2013 年まで僕が所属していた会社では当時にして40歳を超えるベテランでPCを所持していない先輩がいたのですが、特段珍しいこともなく、僕も 20 代の頃は兄から譲ってもらったPCを使っていて、自前で購入したのは 30 を過ぎてからです。つい最近までガラケーだった友人もいますが、その程度のリテラシーのひとがいても不思議ではない世代と言えます。
一方で現在 20 代前半（2000年代生まれ）の世代は物心がついた頃にはインターネットは普及が当然で、PCどころか彼らが思春期の頃にはスマホが爆発的に普及した時代でもあります。学校によっては授業にタブレットを使ったり、全国的にプログラミングが義務教育化されてもいます。僕ら昭和世代は待ち合わせに遅れそうになっても伝える手段がなかったのに対し、SNS でいつでも連絡可能になったわけです、うらやましい。
当然 PC が自宅にあるのも当たり前で情報技術になんの抵抗もなく接してきたわけです。プログラミングに興味を持つ人が増えやすい環境でもあります。2010 年代前半くらいまではスマホ・タブレットアプリはもちろん Web アプリもそこまで普及していませんでしたが、今やブラウザで買い物をするのが当然、つまり彼らには情報技術が広まりきった現在こそが平常運転なわけです。何をするにもまずはスマホで調べることが当然、何なら目的がPCやスマホで完結することも多々あるでしょう。（買い物や情報収集など）
とまあ、一般論ばかり書いたら飽きてきたのでエンジニアリングの話をします。芸人の養成所ではお笑いの基本やメソッドを学習して個々のネタに取り入れるそうです。活動を開始したばかりの若手芸人でも昔よりはずっと質が高いようです。
それと同じように現在は大学や専門学校でプログラミングのカリキュラムもあり、社会人向けにプログラミングスクールも活況です。書籍も充実していますし、YouTube や Udemy で配信しているも多く、Progate のように一部のカリキュラムを無料で提供するサービスもあります。プログラミングやエンジニアリングを学習する場が広く提供されています。僕の世代では SE を挫折したひとであっても現在の環境であれば芽が出た人もいるのではないでしょうか。
技術的な話をすると、僕がSEとなった2000年代後半ではプログラミング言語で仕事として多かったのが、基幹系であれば COBOL や C 、Web の世界では Java の一強だった印象です。COBOL はそもそも自宅の PC でインストールして実行するのが（少なくとも当時は）難しい状況で、かといって C 言語は致死率 100% の難易度でしたし、C 言語は基幹系の中でもメーカのシステムでよく使われていたため、プロジェクト自体の難易度も高く、僕もアサインされたことはありません。Java は仮想マシンを立てる都合で当時の PC ではそれなりのスペックがないとまともに動きませんでした。現在は PC のスペックも上がり、流行の言語：JavaScript、PHP、Ruby、Python は軽量化が進んでいるので自宅 PC でも快適に動作します。
DB にしたって基幹系は Oracle が主流ですが、当時のOracleは無料版がありませんでしたし、他の DB でも無料で軽量なものはなかった印象だったため、永続性のない SQLite を使っていました。現在は MySQL や PostgreSQL が基本無料で使えますし、Web の世界では基本的にどちらかを使うので、実務にも活かしやすいと思います。
これらの技術的な進歩や一般かもプログラミングにハードルを下げることに一役買っていますが、それ以上に洗練されてきたのは開発工程の自動化や効率化です。僕が Web の世界に入った2010年代前半と現在を比較して大きく変わった点は以下の通りです。
- ドキュメントの簡略化
- アジャイルの普及
- オンプレからクラウドへ移行
- CI/CD の導入
- QA チームの編成
現在の若手エンジニアはこれらが当然の環境で業務に勤めています。それぞれの詳細は別の記事で言及するとして、これらは僕からすると大変羨ましい限りで、僕も同じ環境ならより多くの、より高品質なプログラムを残すことができたことでしょう（負け惜しみ）。プログラミングはそれだけ仕組みづくりが重要だと考えています。
情報技術は常に進化を続けています。後発であればあるほど先進的な技術に触れる機会が早く、そしてそのキャリアも長くなり、成果物も高品質になりやすい傾向があると言えます。
それでもベテランが重宝される理由
技術的にはまだ原始的だった時代を通過したベテランエンジニア（1990 – 2000 年代からキャリスタート）が、なぜ未だに重宝されることについて、僕の経験ベースでお話します。
実際僕が重宝されていることや他の同世代かそれ以上のエンジニアで優秀なひとをみていてベテランの持つ長所は以下の通りです。
- 情報技術を本質的に理解しているため、キャッチアップが早い
- ゼネラリスト志向だったため、スコープが範囲が広い
- 経験による独自のエラーシューティングリストがある
- 最終的に力技・長時間労働に慣れている
それぞれについて詳細な説明は他の記事に譲りますが、上ふたつは現在のように明確な分業がされているプロジェクト[1]大規模プロジェクトでは今も昔も分業が進んでいるが、中規模以下では担当が曖昧化なプロジェクトが多かったでは専門外の知見を問われることは少なくなってきた印象です。かつては専門性の高いエンジニアでない限り、スキルが完全にマッチしていなくても、或いはひとつもマッチしてなかったとしても、プロジェクトにアサインされることも多く、結果エンジニアには広く浅い知見が蓄積されることになりました。
「経験による独自のエラーシューティングリストがある」については、相応の努力を積んできたエンジニアには過去の成功体験（＝失敗経験）が積み上がっていますので、現在の課題が過去の事象と照らし合わせて解消へと導くことができます。
「最終的に力技・長時間労働に慣れている」については、現在はプロジェクトの体型上、或いは法的な制約で長時間労働を強要されることのない若い世代には逆に経験できないこともあるでしょう。要するに炎上中の処世術を知っている、ということです。長文の SQL を Excel やサクラエディタで無理やり作成したり、金曜締め切りのタスクを当日の金曜に渡されても、「金曜は 72h ある」という謎の理論で何とか月曜に間に合わせたりする（吐き気のする）能力が備わったりしています。
中年の偉人エンジニア
ここからが本題になるのですが、中年で未だ現役のオッサンたちを紹介します。
まずは IT 界隈で最も高齢かつ有名なひとで言えばセキュリティ分野の大御所、徳丸浩さんは 70 歳近いとのこと、Ruby を開発したまつもとひろゆきさんは 1965 年生まれ、Laravel を日本語翻訳されている川瀬裕久さんは 50 代後半とのことです。
まつもとさん以外正確な年齢はわかりませんが、僕が過去のプロジェクトでご一緒させていただいたエンジニアでとても顔が広い方がいらっしゃってその方にだいたいの年齢を伺いました。50 をとうに超えた人が活躍を続けている人は徳丸さん、まつもとさんだけでなく実際の現場にいくらでもいるものです。徳丸さんに至ってはダブルスコアですが、権威として未だに君臨し続けています。
「偉人と比較しても…」と思うかもしれませんが、現場でも僕と同年代（40 代）のエンジニアに会う機会は多い印象です。結局夢中になってやっているうちに経験も手伝って年齢がそれほど障害にならないこともあるんじゃないかと思ってます。何の根拠もありませんが、歳をとって特段アホになるエンジニアもあまり見かけません。考えが足らなかったり、ミスが多いエンジニアは若い頃からすでにその状態にあったと考えたほうが適切に思えます。
ここでちょっとしたエピソードを紹介します。
ほんの短い間プログラミングスクールの講師をしていたことがあるのですが、そこで社内研修のようなものに出席した際の話です。オンラインでの参加だったのですが、そこに初老の男性が方がいらっしゃって、その会社の相談役のようなポジションだったと思います。
その方は現役のエンジニアで、見た目は 60 歳をとうに超えているように見えましたが、自己紹介の言葉が非常に印象深かったのを覚えています。
僕は Windows, Mac, Linux どれも好きです。プログラミング言語では Java, C, PHP, Ruby, Python, React…（略） どれも好きです。
DB はどの製品も好きです。それ以外でもどんな技術でも好きです。どれも可愛い。
これをおヒョイさんみたいな特徴的な声で優しくゆっくり話されていました。
エンジニアでないひとにはピンと来ないと思いますが、たいていのエンジニアはお気に入りの言語やスキルというものがあり、その対となる「嫌いな技術」というものが存在します。
僕が不得意な言語としては Windows ライクの言語全般で、VisualBasic や C# などはほとんど業務経験がないこともあって、特に VisualBasic なんかは文法なども不自然に思えます。DB も Oracle と SQLServer はやたら重いイメージがあり、主に炎上した現場で使われていたこともあって、できればあまり触りたくありません。
エンジニアとして後発で言語やミドルウェアにはあまりこだわりがありません。そんな僕ですらこの有様なのですが、学生の頃からプログラムを嗜んできたひと、つまり生粋のプログラマはもっと過激な意見を持っているひとはいくらでもいます。COBOL は負の遺産、PHP は素人向けのクソ言語、C や Go こそ至高、jQuery はおもちゃで TypeScript こそ至高、など書いているだけで鳥肌が立つような過激なことを言うひとは少なくありません。
そんな業界で十数年身を置いていておヒョイさんのような言葉を聞いたのは初めてでした。この言葉を反芻していて思うのは、おヒョイさんは単純に技術マニアということではなく、サービスの奥にある人たちが見えていたんじゃないか、ということです。言語やサービスなどのソフトウェアに実体はなく、内部的にはあくまで 0 と 1 の羅列で構成されていて、一時的な電気信号で動作しているに過ぎません。しかしながら、それらは必ず人の手を使って構築されています。AI を採用しているサービスであっても同様に、人によって構築されています。結局のところ人が介在する以上はナマモノであるということです。完全無欠のロボットではなく、欠陥を抱えた生き物とも言えます。
確かに同じリクエストを送れば大抵の場合は同じ回答を返すのがシステムというものですが、その裏には多くの人が関わっており、大げさに言うと無数のドラマがあるものです。エンジニアが泣いたり、（ほんのたまに）笑ったりしながら実装されています。追い詰められて飛んだ人や飛んだ人の代わりに補充されて泣きそうになって実装した人もいるでしょうし、幾つものアプリを作って当たらず、何回も挑戦した上でヒットするアプリを作った人もいるでしょう。そのような背景をひっくるめておヒョイさんの発言に繋がったと思います。
もちろん OS もプログラミング言語も人がいちから実装しています。それらを否定することは実装したエンジニアらを否定する行為とも言えるでしょうし、本来褒められたことでありません。ましてや同業者であるエンジニアであれば、同じような苦労していることも多いでしょうし、そんなエンジニアに悪く言われるのは気の毒にすら思えます。そもそも開発現場で使われるような技術を作る時点で相当腕利きのエンジニアと言えるでしょうから、その他大勢のエンジニアと思想が異なっていて当然に思えます。
おヒョイさんの発言は頑張っている（いた）エンジニアに対する賛辞だったんじゃないかと考えています。もっと言うと与えられたカードに感謝してどう活かすかを考えるべき、と言う示唆を与えるものだったかもしれません。
おヒョイさんの年代（1990 年代以前）ではシステム構築の環境がどれだけ過酷だったかは容易に想像がつきますし、50 を超えたエンジニアは非常に用心深く、ともすれば用心深過ぎて話が進まなかったり、ネガティブな思想に凝り固まったりしている人をよく見かけます。どのような経験をすればあの発言が出るのか想像はつきませんが、少なくとも僕には大きな気づきを与えてくれた言葉として今後も度々思い出すことになると思います。
取り急ぎその言葉を聞いた時点で、まずは言語の悪口はやめようと思いました（笑）
脚注
| ↑1 | 大規模プロジェクトでは今も昔も分業が進んでいるが、中規模以下では担当が曖昧化なプロジェクトが多かった |
|---|
