そろそろ「プログラマー35歳定年説」を徹底論破しとくか（書架とラフレンツェ）

今回はaliliputさんのブログ『書架とラフレンツェ』からご寄稿いただきました。

そろそろ「プログラマー35歳定年説」を徹底論破しとくか（書架とラフレンツェ）

世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。

・ プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説)
・ プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説)
・ プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説)

以下、ひとつずつ検証していく。

体力低下説

まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそうだ。普段から食事や睡眠をしっかり取り、適度な運動をしているならば、35歳でもどうということはないだろうし、そうでないならば25歳だって成人病になったり過労死する人もいる。

また「プログラマーは激務」も、一体どこまで当然としてよい話なのだろうか？確かに過酷な開発現場も多いだろう。しかしプログラマーの仕事の本質は不眠不休コンテストではない。休まずに働けるのが良いプログラマーの条件ならば、人間ではなくキリンでも雇っておけばよいのだ。若者しか勤まらないような過酷な開発現場は単にマネジメントが失敗している一部に存在するだけであり、専門職としてのプログラマーがその専門性を発揮するのに不適切なところだ。

したがって体力低下説は、例外的な一部の不摂生プログラマーや破綻した開発現場にのみ適用される限定的な説であり、元よりそのような専門性を語るに値しない領域の話をプログラマー全体の話として一般化できない。

なお、不幸にしてそのような悲惨な現場に放り込まれてしまった場合のサバイブ術については、事項で少し触れる。

学習能力低下説

次に「学習能力低下説」だが、最近の脳科学の研究成果によると、35歳を超えての学習能力低下は認められていない。もちろん単純な記憶能力は年齢とともに低下するが、論理的思考力や創造性などはむしろ年齢にしたがって上昇するとの研究報告もあり、35歳程度での年齢での学習能力低下を裏付けるエビデンスは現在のところ見つかっていない。
もしプログラマーに求められる能力が丸暗記ならば、プログラマーの定年は35歳どころか20歳だ。しかし知識もさることながら、経験に裏打ちされた問題解決力や創造的思考が重要ならば、65歳くらいまでは常に新しい知識を取り入れつつ経験を積んでいるベテランほど専門性が高まる。

これらの脳科学における研究成果は、そのものズバリ脳と学習との関係について現在までの研究成果を包括的にまとめた『脳からみた学習』*1が大変参考になる。

*1：「脳からみた学習 －新しい学習科学の誕生」 OECD教育研究革新センター(著) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/475033314X/

脳科学の知見から加齢と学習能力の関係、右脳-左脳論のウソ、学習したい内容に対する効率のよい学習方法についてなどが豊富な実証研究結果と共に紹介されており、読みごたえがある。

この本によると、学習能力は新しいことを学んだ経験を積めば積むほど高まる。したがって、プログラマーとして必要な学習能力を維持向上したければ、常に新しいことを学ぶべく勉強を続ける必要がある。

効率のよい学習の方法としては『誰かを教えることになったあなたへ -IDへの招待 ※6/24追記 – 図書館学徒未満』*2を自分に適用すればいいが、学習方法よりも切実なのが学習にかかる時間をどのように確保するかという問題だ。まず業務を効率よく終わらせ、学習時間を確保するには『エンジニアのための時間管理術』*3が実践的な内容を豊富に含み役立つ。

*2：「『誰かを教えることになったあなたへ -インストラクショナル・デザインへの招待』読む時間がないひと向けまとめ」 2013年06月20日 『図書館学徒未満』
http://lovelibrary.hatenablog.com/entries/2013/06/20

*3：「エンジニアのための時間管理術」 Thomas A. Limoncelli(著), 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4873113075/

また、少し踏み込んだ内容となるが『アジャイルサムライ －達人開発者への道－』*4も比較的すぐに取り入れやすいプロジェクト管理のノウハウを豊富に集めている。ただチーム単位で導入すべきテクニックが多いので、個人ですぐにやってみるという訳にはいかないかもしれない。

*4：「アジャイルサムライ－達人開発者への道－」 『Hatena』
http://d.hatena.ne.jp/asin/4274068560/

小手先のノウハウではなくプロジェクト全体に対するマネジメントを学ぶには、「クリティカルチェーン」（現時点でクリティカルパスの計算にはリソースの競合を考慮に入れることになっているので、クリティカルチェーン法とクリティカルパス法の計算方法はほぼ同じです）というアイデアの元となったTOC解説書である『クリティカルチェーン』が分かりやすい。破綻しそうなプロジェクトを闇に落とさない方法を小説形式で解説しているが、時系列順に登場人物の思考を追う形で考え方が解説されているので自然に理解しやすい。

「クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」 エリヤフ ゴールドラット(著), 三本木 亮(著) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4478420459/

クリティカルチェーンは単なる見積り法の一つではなく、TOCというシンプルで強力な経営管理理論から導出された「プロジェクト管理」というものに対する思想的態度であるとわかる。

日々のタスク処理においてもプロジェクト管理においても、どちらにも重要なのはボトルネックの検出と解消だ。ボトルネックの存在を意識しつつタスクを処理していくだけでも、大幅に効率を向上させられる。

「どんなに素晴らしい時間管理法が分かったとしても、上司やクライアントが協力してくれなければ何にもならないよ……」とお嘆きの場合は、そういったひとたちに納得してもらいやすい説得方法が豊富に詰まった『週四時間だけ働く』が参考になる。

「「週４時間」だけ働く。」 ティモシー・フェリス(著), 田中じゅん(翻訳) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4905042097/

ひとりで頑張っても効率よく時間は作れない、だから同僚や上司やクライアントを巻き込む必要がある。それはその通りだ。彼らを説得するには説得技術そのものも大切だが、それと同時に彼らを取り巻く世界のパワーバランスを理解しておく必要がある。プログラマーが上司やクライアントに制約されているのと同じように、彼らもまた”何か”の制約を受けており、それに逆らうことはできない。プログラマーの勉強時間を確保させないマネージャーには、そうするだけの理由があるのだ。

それが一体なんであるかは、次の項で述べる。

マネージメント原因説

これについては@Grabacr07 氏による解説が分かりやすい。

ぐらばく@Grabacr07
@liliput 大仰な言い方ですが、SIer は人月商売をしており、プログラマーを「技術力問わず交換可能なただのリソース(=単純労働者としてのプログラマー、いわゆる PG)」とした前提で、「月単価いくらか」でしか見てません。

2015年2月26日
https://twitter.com/Grabacr07/status/571132262109982721

ぐらばく@Grabacr07

@liliput その月単価は年齢と共に上昇していくので、管理職が視野に入る 35 歳を超える年齢だと、単価が高すぎて PG としてアサインできなくなります。これが 35 歳定年 (= 開発職として参画できる限界、それ以降は管理者としてしか参画できない) だと思っています。
2015年2月26日
https://twitter.com/Grabacr07/status/571132310180859904

ぐらばく@Grabacr07

@liliput (SIer だった前職では高齢のプロパー社員 1 人アサインする予算があるなら若手の派遣 3 人アサインできるからそっちを使え、みたいなことは多々ありました (エンジニアのまま高齢になったそのプロパー社員はどのプロジェクトにも参画できず、的な))

2015年2月26日
https://twitter.com/Grabacr07/status/571132429714345984

ぐらばく@Grabacr07

@liliput よって、これは SIer のような「エンジニアとしてのキャリアパスが存在しない」会社の話であって、技術力を問われる本来のエンジニアとは関係のない考え方ですね。こういう記事は好きです

「プログラマ35歳定年説は覆せる | 米マイクロソフトの開発者となった河野通宗の働き方」 『CAREER HACK』
http://careerhack.en-japan.com/report/detail/287

2015年2月26日
https://twitter.com/Grabacr07/status/571132541467430914

つまり「単価と年齢が比例する」かつ「開発者としてのキャリアパスが存在しない」の2条件が揃う企業(あるいは業種)では、35歳以上の開発者の就業維持が事実上難しく（なんでその分水嶺が35歳なのか、という点については『日本資本主義の精神』に詳しいです。結論を言いますと、宗教上の理由です）、それがプログラマーの技術職としてのキャリアを途絶えさせる原因となっている。そして、そうした企業はSIerが多いため、SIerでは「プログラマーは35歳が定年」と言われるのだ。この説に基づくとこれは純粋に企業のマネジメント上の問題であり、個人としてはそのような企業を就業先に選ばない、という以上の回避策はない。

さて「単価と年齢が比例する」かつ「開発者としてのキャリアパスが存在しない」の2条件の存在は、すなわちその企業ではプログラマーの「技術力」を評価対象としていないことを意味する。もしその企業で技術力が評価対象になるならば、単価は年齢ではなく技術力によって決まるはずだし、評価軸はシーケンシャルなものだから、開発者が技術力を向上させていく上でのキャリアパスも存在するはずだ。

SIerは労働集約型産業だから、その富の源泉は「資源」、すなわち人間に宿る高度なスキルではなく、「プロセス」、すなわちビジネスを効率よく処理する仕組みにある。富の源泉がプロセスにあるならば、従業員の技術力はそのプロセスを回す程度にあればよく、それ以上の技術力を評価しても手間ひまがムダになるだけだ。もちろん勉強時間や教育機会を従業員に与えるのもムダで、そんな余裕があるならば少しでも「コスト削減」に費やすべきだ、という考え方になる。企業をある程度以上の規模に育てるにはどこかの時点で富の源泉をプロセスに移行する必要があるので、このような考え方には一定の合理性がある。

「イノベーションへの解 利益ある成長に向けて (Harvard business school press)」 クレイトン・クリステンセン(著), マイケル・レイナー(著) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4798104930/

しかしクリステンセンによる『イノベーションへの解』での指摘によると、そのプロセスには絶えず改善を加えないと陳腐化してしまう。市場も顧客も技術も常に進歩し続けるから、いつまでも同じプロセスでは対応できなくなるのだ（このプロセスを自律的に改善し適切な資源配分を行っていくメタな仕組みが確立した状態が、富の源泉が「価値基準」に移行した状態で、詳しくは『イノベーションへの解』を読んでください）。そして改善を行うには「資源」が必要である。そうしない企業はいつしか陳腐化したプロセスとそのプロセスを回すしか能のない肥大化した人員を抱え込んだまま市場から追い出されてしまう。だからそうならないためには、労働集約型産業とは言え一定の「資源」、つまりこの場合は技術力の高い人員を常に維持しておく必要はある。

まぁこれは一般論だから、現実のSIerがこれからどうなっていくのかはまだわからないけれど。

では、企業はどんな方法で資源である技術力の高い人員を確保し続けるのだろうか？その方法には以下の2つがある。

1. どこかから雇ってくる(含外注)
2. 社内で育成する

1の採用方法については以前『採用で失敗しない、たった一つの冴えたやり方 – 書架とラフレンツェ』*5で書いたのでここでは省略する。そして社内で育成する、というやり方でも、その記事で紹介した「職務記述書」が重要な役割を果たすのだ。

*5：「採用で失敗しない、たった一つの冴えたやり方」 2015年02月09日 『書架とラフレンツェ』
http://lafrenze.hatenablog.com/entry/2015/02/09/120000

古典的な組織論の教科書である『組織デザイン』によると、企業が必要とするスキルには2種類がある。

「組織デザイン」 沼上 幹(著) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4532110238/

1. 会社の外でも通用するスキル(専門性; professionality)
2. その会社の中でしか通用しないスキル (ローカルスキル)

一般に労働者個人の市場価値を高めるのは前者の「専門性」の方だが、企業にとっては後者も同程度かそれ以上に重要であり、それを育成するには社内で育成する以外の方法がない。これは日本でも海外でも変わらない。だから、アメリカなどの企業でも当然に人材育成を目的とした配置転換は行われているし、経営者は離職率を下げるための施策に頭を悩ませている。「アメリカの企業はジョブ型雇用で、メンバーシップ型雇用の日本とは違って配置転換なんかしないから～」などという俗説ははっきり言ってウソだ。この辺りの実例を垣間見るにはゲイリー・ハメル『経営の未来』*6がホールフーズやゴアテックス、そしてグーグルなどの興味深い実例が豊富で面白い。

*6：「経営の未来」 ゲイリー ハメル(著) 『amazon』
http://www.amazon.co.jp/exec/obidos/ASIN/4532313805/

『採用で失敗しない、たった一つの冴えたやり方 – 書架とラフレンツェ』＊5で、職務記述書にはそのポストに必要なスキルのセットが記載されていると説明した。これはもちろん採用にも使用できるが、社内での人材育成計画を立てる上でも重要な指針となる。

『イノベーションへの解 』＊7では、経験こそがスキルを生むと説明されており、これが当然であることも先の記事で解説した。つまり企業が職務記述書に基づきある人材を育成しようとするならば、そこに記載されているスキルを必要とするような経験を計画的に社内で積ませることになり、その結果として異動が発生する。このように新人をエキスパートに育てるための計画と指針をキャリアラダーと言う。職務記述書では、ある職種について初心者から専門家まで、それぞれのスキルについておよそ5段階程度にレベル分けされているのが普通だ。

*7：「イノベーションへの解 利益ある成長に向けて (Harvard business school press)」 『Hatena』
http://d.hatena.ne.jp/asin/4798104930/

逆に言えば、職務記述書がない状態ではスキルの計画的な育成ができず、適当に異動をしたところで無意味になってしまう。それでは従業員も納得はするまい。これが、メンバーシップ型雇用と称される我が国の企業でも職務記述書が必要となる理由である。

残念ながら職務記述書が存在しない企業において自分の価値を高めるには

・ 「俺の考える社内で必要とされているスキル」を推察してそれを自力で育成する
・ 社の内外で同様に珍重される専門性を育成する

の2通りの方法が存在する。どちらにせよ、これができる高スキルプログラマーの価値は35歳を超えても高まり続けるに違いない。

プログラマーの皆様のご健勝とご健闘を祈ります。

執筆： この記事はaliliputさんのブログ『書架とラフレンツェ』からご寄稿いただきました。

寄稿いただいた記事は2015年03月13日時点のものです。