プログラムの生産性が向上した理由

プログラムの生産性は30年間で3倍高くなった

私がプログラマになった30年前は、コーディング〜単体テストの生産性は1,800step/人月でした。
つまり、1人のプログラマが月に1,800行のプログラムを作れればノルマ達成だったのです。

この生産性は当時としては高い方で、同じグループの製品開発部門では1,000step/人月でした。
その他のアプリケーション開発部門でも1,000step/人月となっているところが主流でした。

私が配属された部門は、自動生成ツールを採用していたので、他部門よりもかなり高い生産性が求められていたのです。

30年経った現在では、3,600step/人月〜5,500step/人月が主流であり、約3倍の値になりました。
会社は、この生産性向上について、技術革新の結果だとか、日々の生産性向上努力の賜物だとか言っていましたが、私はかなり疑わしいと思っています。
実際には、プログラマがより過酷に働かせられた結果ではないかと思っています。

技術革新の成果はステップ生産性とは関係ない

確かにシステムの機能から見た生産性は飛躍的に向上していると思います。
現在当たり前になっているＷｅｂシステムを、昔の言語や環境で開発したら大変な労力が必要となったでしょう。

今はとても簡単に作れるようになったのですが、決してプログラムのステップ数が増えているわけではありません。
技術革新によって、少ないプログラムでより多くのことが実現できるようになったのです。

言語に備えられているクラスライブラリが充実して、昔ならいちいちコーディングしなければならなかった処理が、今なら共通クラスを呼び出すだけで済んでしまいます。

しかし、プログラマ側から見ると覚えなければならないことが増えているだけで、ステップ生産性から見ると低下要因となっているのです。

プログラマの働く密度を上げたことが生産性向上につながった

では、なぜ実際に生産性が向上したのでしょうか。
それは、プログラマの働く密度が上がったことが要因だと考えます。

昔は、メインフレームで端末の数も少なかったので、どうしても実機作業が必要な人がマシンを使い、それ以外の人は机上で作業をしていました。

プログラムを打ち込んでコンパイルすると、とりあえずリストを出し、コンパイル・エラーの修正内容をリストに朱書きしていました。
また、実機テストに入る前にコーディングの内容をまず自分で確認して、それが終わったら先輩に見てもらっていました。
マシンが非常に効果で限られた資源だったので、少しでもマシンの使用時間を短くするよう努力していたのです。

これだけ節約していても、テスト作業が集中する年度末には処理速度が遅くなり、エンターキーを押すと1時間応答が返ってこなくなることがよくありました。

ところが、ＰＣが普及し始めると個人に１台割り当てられるようになり、使用時間の制限もなくなりました。
最初は環境が改善されたと喜んでいたのですが、それ以前と比べて非常に疲れるようになりました。

ゆっくりとプログラムを見直す時間やひと息入れる時間がなくなってしまったのです。
環境が改善された分、生産性ノルマも高くなっていったので、ついていくためにはより隙間なく仕事をこなすしかありませんでした。

思い返してみると、この前後で職場の環境もずいぶん変わり、ギスギスしたものになったと思います。