動画の概要欄にあるトピックをベースに、エンジニア業界の歴史的経緯や裏話、AI時代における解釈を交えて掘り下げます。
「プログラマー生産性28倍差」の元ネタと歴史的背景
1968年のサックマン実験（Sackman et al.） 概要欄にある「28倍」という数字は、1968年に心理学者ハロルド・サックマンらが発表した研究が元ネタです。
-
実験の目的: 当時登場し始めた「タイムシェアリング（オンライン対話型）」と「バッチ処理（紙のパンチカード）」のどちらの作業効率が良いかを比較すること。
-
偶然の発見: 方式の違いよりも「プログラマー個人の能力差」（コード作成時間で16倍、デバッグ時間で28倍、実行速度で13倍）の方が遥かに大きいという結果が出たため、業界に衝撃を与えました。
後日談：28倍の「神話」と批判 動画の最終章でも触れられている「意外な後日談」にあたる部分ですが、現代のソフトウェア工学において、この「28倍（あるいは10倍）の差」は実験手法に不備があったとしてしばしば批判されます。
-
被験者がわずか12名と極めて少なかったこと。
-
最も遅かった被験者はアセンブラ言語（低級言語）に不慣れだったこと。
-
プログラミング経験年数のカウント方法が曖昧だったこと。
とはいえ、「優秀なエンジニアは単にキーボードを叩く速度が速いのではなく、無駄な作業を一切しない」という本質自体は、現代でも「10x Engineer（10倍の生産性を持つエンジニア）」という言葉に引き継がれています。
各章の行動パターンと業界あるある
動画で挙げられている4つの共通行動は、ベテランや「デキる人」が無意識に行っている認知負荷の削減テクニックです。
1. 質問の仕方が異常にうまい（5W1Hとコンテキスト）
-
あるある: 経験の浅いエンジニアは「動かないです」とだけ聞きがち（いわゆる「お気持ち表明」）。
-
デキる人の型: 「①期待した挙動」「②実際の挙動」「③試したこと」「④自分の仮説」の4点を揃えて質問します（いわゆるSTUCKフレームワークや Rubber Duck Debuggingの応用）。質問を整理する段階で自己解決することも珍しくありません。
2. 速さを目的にしない（手戻りの防止）
-
業界の金言: “Fast is smooth, smooth is fast.”（速さは滑らかさから、滑らかさは速さから）。
-
いきなりコードを書き始める人は、仕様の誤解やエッジケースの考慮漏れで後から大規模な修正（手戻り）が発生します。デキる人は「仕様確認」「設計」「インターフェース定義」に時間を割き、コーディング自体は最後の確認作業として処理します。
3. ログと切り分け（二分探索的デバッグ）
-
切り分けの鉄則: 問題が発生した際、影響範囲を半分ずつ削っていく「二分探索（Binary Search）」の思考を使います。「ネットワークか・アプリか」「フロントか・バックエンドか」「DBか・ロジックか」と境界線を引いてログを確認するため、「どこが分からないか分からない」という状態に陥りません。
4. 準備で仕事の半分を終わらせる（環境構築とチェックリスト）
-
ローカル開発環境のコンテナ化（Docker等）、定型作業のスクリプト化（MakeやCLIツール）、手順のチェックリスト化により、脳のワーキングメモリを作業の自動化で節約しています。
AI時代における「有能さ」の変容
LLM（大規模言語モデル）やAIエージェントが普及した現代において、「コードを書く速度」そのものの価値は急激に低下しました。
-
かつての「デキる人」: 言語の文法やライブラリのAPIを暗記しており、実装スピードが圧倒的に速い人。
-
AI時代の「デキる人」:
-
問題定義力: AIに何を指示すべきか、仕様や境界条件を言語化できる力（＝動画の「質問力」や「準備」と同義）。
-
検証力・デバッグ力: AIが生成したコードの妥当性を見極め、ログや挙動から不具合の原因を特定する力（＝動画の「切り分け」と同義）。
-
結局のところ、サックマンの実験から半世紀以上が経過した現在でも、「問題を正しく分解し、構造化して考える力」こそがエンジニアの生産性を決める本質であり、それらはAIの登場によってむしろ浮き彫りになったと言えます。
サックマン実験（1968年）の「28倍」は、意図せざる発見が伝説化した典型例で、現代の「10xエンジニア」神話の直接の源流です。 追加の雑学・業界話を交えつつ掘り下げます。
実験の舞台裏と「偶然の衝撃」
実験はSystem Development Corporation（SDC）で行われました。SDCはRANDのスピンオフで、冷戦期のSAGE空防衛システムのソフトウェア開発を担っていた組織です。当時のコンピュータは極めて高価で、タイムシェアリング（オンライン対話）vsバッチ（パンチカードをオペレータに渡す）の効率比較がARPA（現DARPA）の関心で優先されていました。被験者は経験平均7年のプロ12名（もう一群は研修生）で、タスクは代数式解釈と20×20迷路探索のデバッグ中心。
結果としてオンラインの方がデバッグが速かったのですが、それを「影で圧倒した」のが個人差です。特にデバッグ時間で最速6時間 vs 最遅170時間という28:1が出てしまい、「When a programmer is good, he is very, very good. But when he is bad, he is horrid」（童謡のもじり）という有名な表現まで論文に載りました。コード作成16倍、実行速度13倍など、指標によって幅はありましたが、「個人差がツール差を凌駕する」という結論が衝撃を与えました。
興味深いのは、この研究が「生産性差の研究」として設計されたわけではなかった点です。オンライン/オフライン比較が主目的で、個人差は副産物。にもかかわらず、1968年のNATOソフトウェア工学会議などで言及され、瞬く間に業界の「常識」になりました。SDC自体が「業界を訓練した」と後年自慢するほどの人材輩出組織だったこともあり、数字の伝播力が強かったのでしょう。
「28倍神話」の崩壊と修正の歴史
現代ではこの数字はほぼ「伝説」として扱われます。Lutz Prechelt（1999年のテクニカルレポート）やDickey（1981年）らによる再分析が決定的です。
- 28:1はオンライン群とオフライン群を混ぜた上での最速/最遅比較で、群間の系統的差を無視している。
- 12名中3名が推奨の高レベル言語（JTS、ALGOL系）ではなくアセンブラを使っており、その中に最遅組が含まれていた。
- 最速と最遅を単純比で取るのは統計的に不適切（外れ値に敏感）。群を分けたり言語を揃えると5:1〜14:1程度に下がる。
- 経験年数のカウントも曖昧で、生産性との相関もほとんど出なかった。
それでも「オーダー・オブ・マグニチュード（桁違い）の差がある」という定性的結論自体は、Curtis（1981）、DeMarco & ListerのPeopleware、BoehmのCOCOMO関連研究などで繰り返し確認されています。ただ、現代のより大規模なデータでは「大多数は2〜5倍程度の範囲に収まり、極端な外れ値が平均値を歪める」というニュアンスが強いです。Steve McConnellも「再現性の高い結果」としつつ、数字の使い方には注意を促しています。
業界での広がり方として象徴的なのは、Fred BrooksのThe Mythical Man-Month（1975年）です。彼はSackmanらを引用して「年収2万ドルのプログラマが1万ドルの10倍生産的であることもあり得る」と書き、外科手術チームモデル（一人のエースを中心にサポート役を配置）を提唱しました。これが「10xエンジニア」概念の普及に大きく寄与しました。一方で、2010年代以降は「10xは存在するか？」論争が再燃し、2019年のTwitterスレッド（「会議嫌い・黒背景・思考を即コード化」などのステレオタイプ）が炎上して「1xエンジニア」パロディサイトまで生まれるなど、文化的な反動も起きています。
行動パターンの業界あるある深掘り
動画で挙げられた4点は、認知負荷管理の観点から見ると、まさに「無駄をしない」達人の習慣です。
- 質問の上手さ：STUCKや「期待値・実際・試行・仮説」のフレームワークは、Rubber Duck Debuggingの進化形でもあります。新人あるあるの「動きません」は、相手にコンテキスト再構築を丸投げする行為。ベテランは質問を整理する過程で自己解決することが多く、これが「生産性差」の一因です。
- 速さを目的にしない：“Fast is smooth, smooth is fast.” は軍事訓練由来の格言で、ソフトウェアでもよく使われます。手戻りコストは指数的に増えるため、「いきなり書き始める」は短期的には速く見えて長期的に遅い。
- 二分探索的切り分け：ネットワーク/アプリ、フロント/バック、DB/ロジックと境界を引く思考は、デバッガが発達した現代でも基本です。AIがコードを生成する時代では、むしろ「どこが怪しいかの仮説生成」能力が差を生みます。
- 準備で半分を終わらせる：Docker、Makefile、チェックリストは「ワーキングメモリの節約」そのもの。1960年代のバッチ時代には環境構築の手間がもっと大きく、この差がさらに目立っていたはずです。
AI時代での再解釈
コード生成速度の価値が急落した今、「28倍差」の本質は「問題を正しく分解し、構造化して考える力」に収束しています。かつての「APIを暗記して爆速実装する人」はAIに置き換えられつつあり、代わりに「AIに的確な仕様と境界条件を与え、出力を検証・修正できる人」が相対的に有能になります。これはSackman実験で観察された「無駄な作業をしない」能力とほぼ同義です。
結局、半世紀以上経っても「個人の認知的な質」がツールを上回るという教訓は生き続けています。ただし、現代のチーム開発では「個人の28倍」より「チーム全体の摩擦を減らす仕組み」や「1xエンジニアでも持続可能な生産性」の方が実務的には重要、というのが最近の業界コンセンサスに近いところです。数字の神話を鵜呑みにせず、「差があることは確かだが、測り方と文脈を慎重に」と捉えるのが健全でしょう。
0 件のコメント:
コメントを投稿