KEIS BLOGは株式会社ケイズ・ソフトウェアが運営しています。

KEIS BLOG

なぜ若手は挫折するのか?

10,000時間の“名人方程式”は、もはやソフトウェア開発に当てはまらない

──労働時間の半減とスキル半減期が示す新しい熟練ライン
という事で、この業界、若手がとにかく挫折するんですよ。ブラックだからでは無いんです。なんでだろうなーと思っていて、ふとある記事がきっかけで、アハ体験的な気づきがあったので、ブログにまとめてみました。

TL;DR

普通の人が勉強しちゃいけない、時間を費やしてはいけない分野がある。にもかかわらず、そのような分野はネットなどの情報量がおおく、初学者が引っかかりがち。そっちに時間を使ってしまうと、スキルの蓄積が効かず、永遠に熟練者になれない。

10,000時間ルールとは何だったのか

1993年、心理学者アンダース・エリクソンのバイオリン研究を下敷きに Malcolm Gladwell が広めた「10,000 時間の意識的練習で一流になれる」という経験則。これ、ソフトウェア開発の世界でも有名で、1万時間で一人前になれるっていう通説があったんです。

熟練段階 典型的な有効ストック量 (h) コメント
Novice → Advanced Beginner \~1 000 h 手順を覚え始める
Advanced Beginner → Competent \~3 000 h 「自分なりの型」ができる最初の跳躍
Competent → Proficient \~6 000–8 000 h 設計判断の直感が働き始める大きな跳躍
Proficient → Expert 10 000 h 以上 “匂い”の高解像度域

※ Competent=中級熟練者、Proficient=熟達者

そして、いわゆる「学習曲線」というのは線形ではなくて、ジャンプが起きる、と。「ファッ」と目の前が開けるようなことが起きるんですね。それを「跳躍」とここでは書いてます。階段みたいなイメージでしょうか。

その反面、近年の再検証(実証メタ分析)では 必要時間の幅が 728 〜 16,120 時間と 22 倍もばらつく ことが確認され、「固定値では語れない」と結論づけられているそうなんです(Macnamara et al., 2014)。必要時間そのものは大幅には伸びてない、という事と、「一律1万時間」っていう話の方がそもそも雑過ぎるんで、まそらそうだよね、という話です。

外的要因(1):年間労働時間の半減

そもそもなんですが、単純に労働時間が違うんですよね。
平均年間労働時間(日本)を昔と今で比較してみましょう。

指標 1990 年ごろ 2020 年ごろ 変化要因
平均年間労働時間(日本) 2,250 h (japanesestudies.org.uk) 1,690 h (FRED) 働き方改革・残業規制 (docs.iza.org)
フル残業層の実働 3,000 h超えの層が 800 万–1,000 万人(1994 推計)
(Roads & Kingdoms)
3,000 h 以上は制度上ほぼ不可能 法定上限 80–100h/月、違反罰則

※ 2019 厚労省「毎月勤労統計」の数字だと1,580 h(さらに少ない)

いや、昔すげーな・・・。ソフトウェア開発の世界っていうのはその昔長時間労働で有名でした。まあ、3000時間っていうと月に300時間も行かないですから、私の感覚としてもそんなもんです。労働時間、随分短くなったんですねえ。(私は1990年にはまだ仕事してませんが)

外的要因(2):スキル半減期の短縮

こちらはIBM Institute for Business Value, 2021 “The Enterprise Guide to Closing the Skills Gapから持ってきました。

90年ごろは主要スキルの半減期が推定 10 年以上
20年ごろ、これが2.5年に短縮

「そっちから来た?」という話なんですが、今覚えた主要スキルが何年使えるか、という話ですね。

半減を「陳腐化」と表現するんであれば、覚えた技術が陳腐化するまでの寿命が 10 年→2.5 年に短縮。習得後も 継続的な再学習コスト が発生。という事なんですね。

ちなみに、他にこういうの書いてる人居ないかな?と探して見たところ、いくつかあって、

  • ・ソフトウェア工学アイデアの半数が 5 年で陳腐化(2008年)
  • ・実務スキルの鮮度中央値は 2–3 年
  • ・SWエンジニア技能の中央値 2–3 年;ハード技能は 4–6 年(2023年)

ちゃな感じです。私自身の経験ともこれは符合するところがあります。
IBMの出してる数字は妥当そうです。

必要な実質学習量は無限大?

実務が「意識的練習」と言えるかどうかはともかくなんですが、ここでは「実務時間=学習投入時間」とするとして、
年間学習投入(ここでは OECD「平均実働」=1 600 h)
知識半減期:10年、2.5 年

計算式はややこしくなるので省略しますが、このペースで半減されてしまうと、
減る量と勉強する量が均衡しちゃうんですよねえ。

半減期が 10年 → 2.5年 と4倍減ると、保持できる有効スキル量は
ちょうど4分の1になる(23,080 h → 5,770 h)。

長時間労働 + 長半減期 の1990年代モデル (3 000 h, 10 年) なら 4万h超まで漸近――10 000 hを大幅に上回り、“Expert”域に比較的容易に届く。

短半減期 (2.5 年) 下では、現代平均投入 (1 600 h/年) だと Proficient 上限 <= 5,770h で頭打ち。

跳躍 目安ストック 到達可否
Novice→Competent \~3 000 h ◎(2.5 年)
Competent→Proficient 6 000–8 000 h × (ぎりぎり届かない)
Proficient→Expert ≥10 000 h ×

若手が挫折しやすいメカニズム

カレンダー年換算の伸長

同じ投入量でも熟練到達までの “見かけ年数” が倍近くに。

学習対象の拡散

言語・FW・クラウド・CI/CD・セキュリティ … 習得すべき面積が指数関数的に増大。

達成感が遅れる

“最初の跳躍”(Competent)が 1 年目→2.65年目に後ろ倒し、
そして、1990年にはわずか2.15年で到達していた熟練者レベル(Proficient)に、永遠に到達しない→モチベーションを保ちにくい。

若者ほど半減期が短い技術を学ぶ傾向

これは主観的な話になりますが、若手ほど流行り技術を追いかける傾向があるように思います。流行り技術は半減期が短い傾向があります。シニアでも半減期が短い技術を追いかけているとこの現象は起きると思われます。

“時間”じゃない。「何を学ぶか」で勝負が決まる

昔も今も、流行りものの「半減期」は速かったです。基盤技術に寄れば寄るほど半減しません。例えば、OS(Linuxとかですね)やネットワークの知識は半減どころかここ20年でまったく減っていません。リレーショナルデータベースの知識はどうでしょう、まあ、半減くらいしたかもしれません、20年で。深いリレーショナルデータベースの知識であればそんなに減ってないかもしれません。(私の体感的な話ですが)

もっと上のレイヤーの話、言語とかフレームワークはここ20年で見たら半減どころの話では無いですね。数年でゼロになったものも有り、長いものでも半減はしていると思います。

学習速度より半減期の方が速いような技術を勉強してたら一生前に進めません

  • 労働時間の減少とスキル半減期短縮が、若手の「到達までが遠い」感覚を生む最大要因。
  • 中でも初学者、若手は半減期間の短い「最新の技術」を選好する傾向。
  • いたずらに時間を投入してても前に進めない場合がある。学習密度 × 半減期 を意図的に設計することが現代の熟達戦略になる。

若手だけの問題ではない

Messmann & de Grip (2023) では、「スキルの半減期(half‑life)」という概念を用いて、「スキル」が労働市場でどの程度の速度で価値を失うかを実証的に測定した数少ない研究の一つです。330 万件超の求人広告(OCR+機械学習でスキル語をタグ付け)を元にしているという、ちょっと面白い切り口の論文ですね。

  • ・プログラミング言語・機械操作等の「ハードスキル」は 年率 11–15 % 程度で減価。実務上は「獲得から 4–6 年で価値が 50 % に低下」する
  • ・対照的に「ソフトスキル」(交渉能力・リーダーシップ等)の減価率は年率 5 % 未満で、10 年超の半減期

この辺が骨子でしょうか。基盤技術に負けず劣らず、「ソフトスキル」も半減期が長いようですね。統計的にはシニアもソフトスキルがあった方が楽(スキルを保有しやすい)なように見えます。

この論文では「ハードスキル」の半減期も長めですが、測定方法が独特なので、差異が出たのかもしれません。他の論文ではおしなべてもっと半減期は短いという結論でしたが。

まとめ

「昔は 3 年で“匂い”が分かったのに」と嘆くより、実務の中で、半減期が長く、積み上げの効く仕事をコツコツとこなしていく、これがいまの開発者には現実的な近道じゃないかな、とおもいます。

また実際には業務外学習が当たり前の世界ですから、労働時間=学習時間なんて乱暴すぎる前提ではあります。

また別に若手だけの話でもありません、シニアだって一緒です。

学習設計もスキルの一部。がんばろう。