システム開発プログラムの生産性は30年間で3倍高くなった私がプログラマになった30年前は、コーディング〜単体テストの生産性は1,800step/人月でした。1人のプログラマが月に1,800行のプログラムを作れればノルマ達成だったのです。この生産性は当時としては高い方で、同じグループの製品開発部門では1,000step/人月でした。その他のアプリケーション開発部門でも1,000step/人月となっているところが主流でした。私が配属された部門は、自動生成ツールを採用していたので、他部門よりもかなり高い生産性が求められていたのです。30年経った現在では、3,600step/人月〜5,500step/人月が主流であり、約3倍の値になりました。会社は、この生産性向上について、技術革新の結果だとか、日々の生産性向上努力の賜物だとか言っていましたが、私はかなり疑わしいと思っています。実際には、プログラマがより過酷に働かせられた結果ではないかと思っています。技術革新の成果はステップ生産性とは関係ない確かにシステムの機能から見た生産性は飛躍的に向上していると思います。現在当たり前になっているWebシステムを、昔の言語や環境で開発したら大変な労力が必要となったでしょう。今はとても簡単に作れるようになったのですが、決してプログラムのステップ数が増えているわけではありません。技術革新によって、少ないプログラムでより多くのことが実現できるようになったのです。言語に備えられているクラスライブラリが充実して、昔ならいちいちコーディングしなければならなかった処理が、今なら共通クラスを呼び出すだけで済んでしまいます。プログラマ側から見ると覚えなければならないことが増えているだけで、ステップ生産性から見ると低下要因となっているのです。プログラマの働く密度を上げたことが生産性向上につながったでは、なぜ実際に生産性が向上したのでしょうか。それは、プログラマの働く密度が上がったことが要因だと考えます。昔は、メインフレームで端末の数も少なかったので、どうしても実機作業が必要な人がマシンを使い、それ以外の人は机上で作業をしていました。プログラムを打ち込んでコンパイルすると、とりあえずリストを出し、コンパイル・エラーの修正内容をリストに朱書きしていました。実機テストに入る前にコーディングの内容をまず自分で確認して、それが終わったら先輩に見てもらっていました。マシンが非常に効果で限られた資源だったので、少しでもマシンの使用時間を短くするよう努力していたのです。これだけ節約していても、テスト作業が集中する年度末には処理速度が遅くなり、エンターキーを押すと1時間応答が返ってこなくなることがよくありました。ところが、PCが普及し始めると個人に1台割り当てられるようになり、使用時間の制限もなくなりました。最初は環境が改善されたと喜んでいたのですが、それ以前と比べて非常に疲れるようになりました。プログラムを見直す時間やひと息入れる時間がなくなってしまったのです。環境が改善された分、生産性ノルマも高くなっていったので、ついていくためにはより隙間なく仕事をこなすしかありませんでした。思い返してみると、この前後で職場の環境もずいぶん変わり、ギスギスしたものになったと思います。早期解決を図らないとプログラマがもたない2000年代にはプログラマの人権が問題になりました。アジャイル開発手法もその流れで提唱されたものだと記憶しています。国際競争がし烈になる中、プログラマの人権問題について聞くことがなくなり、メンタルヘルス等の問題に置き換わってきたような気がします。今後も生産性向上圧力は強まっていくと思います。それを解決するために、オフショア開発が進み問題自体をアウトソースすることになるのか、プログラム生成自動化などの技術革新が進んでいくのかは分かりませんが、早く解決しないとプログラマが持たないのではないかと危惧しています。technology.。