タイトル通り、ちょっとでも詳しい人なら情けなくなるレベルでさえそこに達するのに何年も掛かった。
何せ、本業どころか趣味ですらないし、たぶん一般的なプログラマとは全然違う。
ともかく、レベル的にはがっかりするような話であることは最初にどうしても断っておきたい。
非常に特殊な仕事で、ある環境計測データを現場で測定し、それを持ち帰って取りまとめて分析して報告書を提出するのが主たる業務の会社であった。
世の中にはほんと色んな仕事があるもので、そんな業種があるなんて務めるまで聞いた事もなかっただけど、パソコンという文明機器に触れたのも僕はその会社が初めてだった。とても古い話でお前いったい何歳だ？みたいな。
なので、その最初に触れたPC-9801シリーズの型番は言わないが、勤め始めた時にその会社にあったHDDは外付けでSCSI接続されたものがたった一台あっただけ、とは言っておこう。
環境計測データを取り扱うのが主たる仕事だから、パソコンでデータ処理出来なければ仕事にならない。
その計測機器は基本的に、当時は計るだけであり、記録データと言えば、記録紙にペンで波形記録してくれるレコーダーや、分析値を印字出力してくれる分析器、あるいはまた磁気記録によるデータレコーダくらいしかなく、今みたいにパソコンどころかメモリーカードや、スマホでデータ記録といった直接AD変換記録してくれるものなんてなかった。
・・・いや、あるにはあったけど、そのAD変換機器にパソコンをつないで自家製プログラムで処理したりしていた。
とにかく、アナログ値をどうにかしてデジタル値に変換するのは、手入力やらプログラムやらで処理するほかはなかったから、それなりにプログラム的技術をどうしても身につける必要があった。
一番最初に書いた、ちょっとはまともに動くプログラムとして憶えているのは、サインとかコサインみたいな計算をやってパソコン上で波形を構成し、その値を使ってXYペンプロッターで作図する、というものであった。
ペンプロッターなんて今でも生きているのをたまに見る事があるけど、今は普通にプリンタだよね。
でも当時は、プリンタで作図したものを打ち出すとかありえない世界だった。ドットインパクトプリンタ？くらいしかなかった。
感動したよ、実際には今とは比較にならないほど極超低速だけども、滅茶苦茶にウィンウィン素早く動くペンに感動したもんだ。
僕が書いたとおりに動く、と言う感動。
ペンプロッタをRS-232Cでパソコンと繋いで、描画命令を送るとその通りに動く。
但し、プログラムにバグがあると紙とペンのインクを無駄にする。
僕はそこからプログラムを書くという魅力に取り憑かれるようになり、その会社では在職期間中、多分数で言えば一番プログラムを多く書いたのではないかと思う。と言ったって小さな小さなプログラムばかりだが。
なお、それから何年か経ち、レーザープリンタが導入されたけども、作図のやり方自体は変わらず、プリンタに直接描画命令を送って、みたいなやりかたをしてたよ。だって当時、レーザープリンタを買うと漏れなくコマンドマニュアルが付いてきた時代だったしね。
しかし、言うまでもないけど、DOS上で、いちいちエディタを使ってBasicのソースコードを書き、保存してrunさせるという一連の手続きはとても面倒で、N88－Basicは行番号を行ラベル、GOSUB～RETURNという感じでのサブルーチン処理が出来たくらいで、例えば変数の初期化を忘れて気付かずに同じ変数名でサブルーチンを使ってしまうと、最悪ハングアップしてどうしようもなくなり、リセットする羽目になること屡だった。
だから自家製ブレークポイントと言うか、STOP命令をソースのあちこちに書いて、うまく行けばSTOPを削除するとかコメントアウトするとかは必須な当時だった。
そんなこんなで勤めてから半年くらいで確か社長がマイクロソフトのQuickBasicを買ってきた時にはほんとに感激した。
構造化Basicであることもさることながら、統合開発環境でほとんど全てやってしまえるってのが如何にすごい効率化を生むかを知った。
汎用サブモジュールを作ってしまえば、あとはそのソースファイルを読み込んで、引数与えてサブルーチンを読めば同じ記述を何度もこぴぺする必要から開放される。
あるいはもう、バイナリのライブラリファイルにまとめて、クイックベーシック起動時にスイッチで読み込むバッチファイルとしてしまえば考える必要もない。
さらに、exe形式の実行ファイルも作れてしまい、特定の処理のためにいくつもそれ用に実行ファイルを作っておけば、プロンプトから一発で様々な処理が出来る様になった。
QuickBasic時代が一番多くのプログラムを書いたと思う。もちろん、数だけの話で行数や文字数ではないけれど。
しかしそれは、僕にとってのプログラミングの世界を狭小なものにしてしまった。
ちっとも勉強しなかったと言えばそれまでだけども、僕はいまだにBasic言語しか使えない。
Cやらその他の言語を書けなくはないのだけど、Basic言語で先ず考えて、みたいな頭に出来上がってしまったみたいである。
いや実のところ、早いことBasic以外の言語も覚えたかったのだけど、その会社の社長がそれを許さなかった。
一度、Pascalを使ったプログラムを書いた事があったのだけども、社内で僕以外の他の誰も触ることができないと言う理由で禁止されてしまった。
社長は元々FORTRANから始めた人で、BASICと非常に良く似ていると言う理由で、会社を立ち上げた時からBASIC一本やりだった。
彼はそもそもプログラムは書いたとしてもプログラミング技術にはあまり興味がない人で、とにかく仕事のために問題なく動きさえすればよく、言語などどうでも良かったのである。
だから、プログラムのスピードアップのためにC言語の導入を僕が進言した時には「それを覚える時間が無駄」と取り合ってもらえなかった。
Windows時代になってVisualBasicが導入されてもそれは変わらなかった。
VisualBasic6.0にもなると、純粋なオブジェクト指向ではないが、それなりにオブジェクト指向っぽいことは出来る様になっていたし、オブジェクトを扱う方が、サブルーチンコールだけに頼るやり方よりもずっと能率的だって事くらいは分かっていたので、僕はオブジェクト指向っぽくプログラムを書きたくて仕方がなかったのだけども、社長はユーザー定義型変数を使うことすら許さない。
VisualBasicだから最低限、フォームやらコマンドボタンを使う必要があるから、それらのプロパティやメソッドなどを使わざるを得なくなっていたし、社長も使っていたのに、いざクラスを書こうとすると滅茶苦茶怒られた。
「一つ一つのプログラムは会社の資産であり君のものではない。別の人間が保守できなければ、君がいなくなったらただのゴミだ」
というのが彼の口癖だった。
なので、構造化プログラミングレベルで工夫するしかなく、それから数年後に辞めるまで、僕は構造化プログラミング技術を磨き続けただけで進化は停止してしまったのである。
Windows環境になり、VB5以降にもなると、プログラムはどんどん肥大化して行った。
DOS時代のようにメモリを気にする必要があまりなくなって行き、１つのプログラムで様々な事が出来る様になると、困った問題が１つ重くのしかかるようになって来た。
どんな小さなプログラムでも業務上で使うものである限り、自分しか使わないユティリティーレベルのもの以外については、絶対にフローチャートを提出し確認を貰う必要があった。
細かな変数やら関数やらのドキュメント仕様書は、ソースコード内に所定の様式でコメントを書けばそれでオッケーだったが、小さなサブルーチンでさえもそれが存在する限り、細かくフローにしないとダメなのだった。
入社当時こそ、それが非常に勉強になったし、他人の書いたプログラムを理解するのに役立ったのだけれども、慣れてくると煩わしくて仕方なかった。
だいいち、うちの会社はプログラムを外部に売っているわけではない。
データ処理や分析など、業務に必要だから作っているに過ぎない。
流石に、稀にある、ソフト設計自体が重要な意味を成す業務では、詳しい仕様書をまとめて、その仕様書を通して取引先とやり取りしたりしていたけども、そんなのは滅多にない話だったし、汎用プログラムでさえも、一回完成させたら、その中身を見ることなんか滅多になかった。
実際、不具合があったらフローチャートなんか見ずに、誰もが直接コードを叩いて直したりしていただけだし。
DOS時代の時は、そんなに大きなプログラムは書けなかったので、フローチャートもそんなに面倒ではなかったが（そもそも僕はめんどくさくなると業務自体を早く終わらせたいのでソースを完成させたあとにフローチャートを起こしていた）、VB時代になるとフローチャートがあまりにも複雑怪奇になって行き、そんなフローチャートを例え完璧に作っても、誰も読んで理解しようとは思わないくらいにさえなっていった。
僕以外の社員も実際困ってて、そのせいでみんな夜遅くまで残業するようになっていった。
社長はどうかというと、社長業が忙しくなり、自分でプログラムする事は滅多になくなったし、あっても少しサブルーチン的なところを書いたりとか、大雑把なフロー書いて、実装は社員に任せっきりだった。
但し、社員の作ったプログラムのフローには絶対に目を通す人で、ソースコード自体はあまり見ないが、フローがしっかりしてないと何度でもダメ出しをし、社員は社長のオッケーが出るまで何度も書き直さないといけない。
で、ある業務で、いつものようにプログラムを先に完成させてフローに起こし直していた時のことだった。
どーせソースコードなんか見ないだろう、と辻褄の合うようにだけフローを書き、実際のソースとはかなり違うフローチャートを提出し社長にオッケーを貰った。
ところが、その業務で追加の仕事が発生し、時間的に僕では無理で、社長が僕のプログラムを触るしかない状況になった。
フローとあまりに違うソースコードに社長は激怒し、しかしそれまでめんどくさいフロー起こしに鬱憤を貯めていた僕もその鬱憤を晴らすかのごとく、かなり暑くなって反論し返してしまい、もう少しで暴力沙汰になる手前まで口論して、それから数日後、僕は辞表を提出したのであった。
その会社を辞めてから、次の仕事は全く関連のない無関係な全く違う職種になり、パソコンこそ触るもののプログラムなんか書くことはなくなってしまった。
DOS時代にパソコン通信でフリーソフトを二つほど作った事がある程度で、必要に迫られない限り、プログラミングをする人間ではない。
ただ、当時どうしても許されなかったオブジェクト指向だけはいつの日かチャレンジしてみたいなぁとは思っていた。
それで、あるとき思い立って、何度か仕事で生かせないかなぁと思い、エクセルVBAを使って、昔取った杵柄じゃないけども、こそこそプログラムを書くようになり、もしかしてオブジェクト指向的に書けばちっとは勉強になるかなぁとやってみたのではある。
しかし、大雑把な初歩的・概念的なことは知っていたけども、実際、オブジェクト指向でプログラムしようとしても、構造化プログラミングをあまりにもやりすぎたせいか、どーしてもオブジェクト指向的にならない。
歳を食ったせいもある。頭が新しいことを憶えたがらない。
クラスが設計書であり、インスタンスが実体である、とか言われても理屈こそ分かっても頭が理解を許さない。
フローチャート式ロジックばかりが頭に浮かんでしまい、インターフェース的な理解をしようとしない。
最近になってようやく、少しはまともなオブジェクト指向が身に付き始めたんだけどね。
ほんと、こんな歳になって、いったい何年掛かったのやらｗ