さて、私が就職した先は社員300名弱のソフトハウス。ソフトハウスという名のプログラマー派遣会社というのが実態だったのだが、気まぐれではじめたマイコンプログラムの受託開発のために新聞に出した募集広告に私はひっかかったわけだ。面接に行って、Z80のアセンブラがわかると言った瞬間にあっさりと内定を出されて唖然としたのだが、その理由は入社してみてわかった。開発チームの人数は数名いるものの、まともにZ80アセンブラでプログラムを書けるのは、私を含めて3名だけ、完全に仕事がオーバーフローして、危機的状況になっていると知ったのは入社当日、しかも終電車が出たあとだった。つまりは、入社当日に徹夜仕事になったわけだ。信じられないような本当の話である。
なんで、こんな話をするかと言えば、そもそもコンピュータのプログラミングという作業は、個人の技量や経験に依存しやすい。そして、ある程度の規模のプログラムまでは、優秀なプログラマーの職人芸にまかせたほうが、生産性が上がる・・・ように見える。しかし、規模が大きくなると、それだけの「職人」を調達するのが困難になる。また、「職人芸」で作られたプログラムは効率がいい反面、保守性は悪い。まして、作ったプログラマー以外がメンテナンスすることは難しい。よく、古いシステムのバグを直してもらおうとしたら、作ったプログラマーが会社を辞めていたため、誰も直せないといった事態が発生している。だから、当時でも大規模な開発が多かったメインフレームの世界では、システム・エンジニア(SE)とプログラマーという階層関係や、開発方法の標準化による保守性の向上、設計文書などドキュメンテーションの重視などが一般的に行われていた。設計者とプログラマーを分離することで、優秀な技術者のノウハウを共有し、なおかつその人間がいなくなっても保守ができるように、というわけだ。SEは花形、プログラマーは下働きという悪しき構造が出来上がっていた。やがて、この二つの階層は業界の下請け構造によって分離され、プログラムの基本もわからないSEや設計どおりに書くことしか知らない思考停止型プログラマー(コーダーとも言われた)を量産した。この形が日本のソフトウエア業界をダメにした元凶だと私は思うのだが、それは日本固有の話だったのかもしれない。本来、分業化や標準化、文書化は生産性や保守性を向上させるべきものだが、それをあまりに杓子定規に適用しすぎたことで、結果的に業界の階層構造を作ってしまったり、下層にいるプログラマーたちを思考停止に追い込んだというのが当時からの日本の状況ではなかったのかと思う。
そんな雰囲気の中、私がいたチームは異質だった。上司は標準化、ドキュメント重視を念仏のように唱えていたが、我々プログラマーはそれどころではない。徹夜続きで死にかけている人間たちには、それこそ馬の耳に念仏である。どんなことをしてでも、納期までに、しかも何度もお客とかけあって引き伸ばした納期までに仕上げなければならないとなれば綺麗ごとなど言っていられるわけがない。そんなわけで、とにかくフローチャートもまともに描かずに、頭の中で書いた流れに基づいて直接、プログラムをおこしていった。もちろん、そんなプログラムが一発で動くはずがない。しかも、アセンブラとくれば、もう作った本人以外はだれも触ることができないような代物が出来上がってしまう。
私が作っていたのは、工場内の搬送システムを制御するプログラム。ある意味で、信頼性が人命にかかわりかねないプログラムだ。もちろん、ハードウエアはフェイルセーフに出来ているので、万一プログラムが暴走しても大事故になることは、まずないのだが、それでも、テスト中は愉快なことがいっぱい起きた。コーナー手前で減速しなければならない搬送台車が減速せず、ドリフトしながらコーナーを飛び出すといったことだ。床面には誘導無線のワイヤが埋めてあって、これをはずれると台車は停止するようになっているので、大事には至らないのだが、導入後にこんなことが起きると危険極まりない話だ。
開発環境も劣悪だ。そもそも、こんなプログラムをシミュレーションもなしに、いきなり実機に入れても動くはずがないのだが、手元には開発用の8ビットマイコンが1台とアセンブラとROMライター(機械語プログラムを不揮発性メモリに書き込む装置)があるだけ。単純に文法エラーが取れただけのプログラムを実地でデバッグするわけだから、大変だ。おまけに、テスト現場には開発マシンはない。それでどうやってデバッグするかといえば、プログラムリストでバグを見つけ、その部分に手作業でパッチをあてる。ROMの中身をROMライターに吸い上げ、ROMライター上で修正したい部分の機械語命令をいくつかつぶしてそこに16進コードでジャンプ命令の機械語を入れて、ROMの後ろ側に残った空き領域に飛ばす。そしてそこに修正プログラムを、これも機械語で打ち込み、またジャンプ命令で元の場所に戻すといった具合だ。ここで、趣味で機械語コードを暗記していたことが役立ったというのは、なんとも皮肉な話である。テストサイトに何日も泊まり込んで、ようやく出来上がったプログラムは、パッチの山。もう、最初のソースコードは跡形もない。リストに書き込んだ修正は何度も上書きされ、もはや、元のソースコードにどんな修正を加えたかもわからなくなってしまっていた。これでは、ソースコードが納品できないので、納品前に逆アセンブラを使って、ソースコードに戻し、それにコメントを入れて納品するといったことが、日常茶飯事のように行われていた。
こういう個人作業を続けていると、そのうちプログラマーの何人かは、以前に作ったプログラムを再利用するようになる。そして、それらは、再利用しやすいように整理されて、その人のノウハウがつまったプライベートなライブラリが出来上がる。こうなるとその人の生産性はどんどん向上する。だが、残念ながらこうしたライブラリが共有されることはあまりなかった。なぜなら、人のライブラリは、その人でなければ使えない代物だったからだ。こうして、プログラマーの生産性はその人の資質によって、さらに大きくばらつくことになる。結果として、出来るプログラマーにどんどん仕事が集中するという現象が発生してしまうわけだ。こうなると、最初は効率よく作業できることに喜びを感じていたプログラマーもマインドがどんどん下がってくる。自分のペースをコントロールして、納期ぎりぎりを目指すようになってしまう。こうなると、その人自身の成長も止まってしまう。優秀なプログラマーをどんどん潰していく環境が出来上がってしまうわけだ。この経験は、自分の中では、開発のありかたを考えていく上で大きな教訓になっている。
(続く)