学問の世界と現場の道具

一応、20 年ほど前に、情報工学科なる学科を卒業しているので、学問としてのソフトウェアの世界も、多少かじっているんだけど、その当時から、アカデミックな世界とソフトウェアの現場の違いを意識していたような気がする。

卒業して間もない頃、雑誌で「オブジェクト指向はプログラマーを二分する」といった内容の話があった。当時はピント来なかったが、C++ が PC 用のプログラミング言語として登場したころ、その意味が分かった。オブジェクト指向の恩恵に預かるものと、そのオブジェクトを慎重に、精密に設計・実装するもの。

それを端的に示したのが VisualBasic だった。言語仕様としては、オブジェクトを設計・実装するための機能をばっさりと切り落とし、オブジェクトを使ったプログラミングに特化することで、とかく面倒で複雑になりやすい GUI アプリケーションのプログラミングを劇的に簡便なものにした。BASIC でプログラミングを始めて、C でプログラムが書けるようになったと思ったら、Windows の登場で BASIC に戻った、なんて話もあった。

サラリーマンになって 20 年弱。その間にプログラミングに対して大きく意識が変わった点がひとつある。

「自分ひとりでプログラムを作る訳ではない」

最初のころ、大部分を一人で作るようなことが多かった。自分の職場はソフトウェア開発が専門な訳ではなく、真似事みたいなことを始めたところに入ったもんだから、自分より詳しい人がいる訳でもなかった。

最初がそんな職場だったものだから、ソフトウェア開発の技術者としては、かなり異端。先輩技術者から開発のノウハウを教えられた訳でもなく、ほとんど独学。逆に、そうやって独学でやってきたから、周りに比べると、仕事とは直接結びついていない知識が妙にあったりする。今勤めている、しがない地方のソフトハウスの社員に、Scheme というプログラミング言語があることを知っているものは居ない。

自分があれこれ試して、「これは使えそう」と思っても、グループで開発するとなると、その全員にある一定以上のスキルや知識が必要になってくる。しかし、しがない地方のソフトハウスでは、社員の半分以上はどこかに派遣されているし、社内に残っていても、その場しのぎの下請仕事。元請もいろいろだから、会社としては技術力よりも、「それなり」で「安い」人間を、いかにタイムリーに投入できるかが、会社としての最大の関心事。

そんな状況化で、その辺の本屋で入門書が手に入るレベル以上の技術を持つ人間は育たない。いや、会社としても育てる必要が無い。極端なことを言えば、30 近くなったら勝手に辞めてくれる方が会社は儲かる。

そんな中で仕事をしていると、アカデミックな世界で言われている「プログラミングとはなんぞや」とか、プログラミング言語が持つ特徴やコンセプト、といったものは無意味に思えてしまう。

最近、仕事で流用するプログラムのソースコードを見ていた。10 年ほど前に書かれたプログラムだったが、

memset(buf, NULL, 32);

といった記述を見た。ちなみに char *buf;。趣味の世界なら笑って済ませられるが、こんなコードを書いても給料がもらえるのが現実。これを書いた人に NULL と \0 の違いを話したところで、現にプログラムは動いている。

ゼネコン構造の最下層にいるプログラマにアカデミックなプログラミングの話は届かない。工事現場の日雇い労働者に耐震強度の計算に用いる計算モデルの話をしているような、というとちょっと違うかな。

...なんかまとまらないなぁ。

ま、自分も会社の中では「詳しい人」なんだけど、同じ「プログラミング」というものでも、必要とされる「詳しさ」が、学問の世界と末端の現場では雲泥の差があって、そういった差があることを知らないと「こんなことも知らないのかぁ」「はぁ、そんなマイナーな使えない言語の知識が何になる」みたいなことになるんだと思う。仕事でプログラムを書いている人の多くは、日々の仕事をこなすためのスキルを身につけることで精一杯なんだから、アカデミックな世界を知らないことは責められないと思う。むしろ、アカデミックの世界の人が、そういった「末端の現場」に対して、知っていて欲しいなぁ、と個人的には思うのだが。