私は、２２歳の時に社会人になりました。以前このブログ記事で書いたように新入社員として、某コンピュータ・ソフトウェア開発会社に勤めることになりました。コンピュータ・ソフトウェア開発の技術者の一人として雇われるまでを、その記事では書いています。２９歳になる直前に、一身上の都合で会社を辞めるまで、私はその会社の社員として（と言っても、大手メーカーへの出向が多かったのですが）働いていました。
学生時代には、アルバイトで貯めたお金でシャープのポケットコンピュータとそのペーパーウェアを記載した本なんかを買って、ＢＡＳＩＣのプログラムをキー入力して遊んでいました。が、その会社で実務につくと、まったくやり方が違うので、そのたびに驚いていました。当時のコンピュータは、社会への普及がまだまだで、お金のある会社や個人でないと手が届かない、貴重な資源でした。ソフトウェアの開発ツールも、やっとそれ専用のコンピュータによってシステム化されてきていましたが、まだまだ原始的な（私が教わったような）開発方法が主流になっていました。
現在は、私はその世界にいないので詳しいことは知りませんが、おそらくパーソナル・コンピュータ（パソコン）が、プログラム開発ツールを活用するための主流になっていて、そこで開発されたプログラムまたはソフトウェアが、実機（ターゲットマシン）で動くという仕組みになっていると思います。スマートフォンなどの携帯端末では、そうしたプログラムやソフトウェアは『アプリ』と呼ばれています。また、インターネットは、そのアクセスポイントの先にプロバイダのサーバー（ワークステーション）があって、パケット通信などの通信システム・ソフトウェアによって、コンピュータの専門的知識を知らなくても、つまり、素人でも便利に使えるようにオートマチックに運用されています。
それはさておき、コンピュータ・プログラマー時代に、私がどんなことをやっていたかを今回は紹介しましょう。まず、実機（ターゲット・マシン）には、ほとんど触らせてもらえませんでした。それもそのはず、コンピュータという機械はスピーディにオートマチックに動くものであって、人間がいちいちボタンやキーを順番に押していたら手遅れになったりトラブルになったり利益を上げられなかったりする箇所に使われる物だったのです。ウィンドウズやマッキントッシュ（ＭＡＣ）のＧＵＩ（グラフィカル・ユーザ・インターフェース）などのＭＭＩ（マン・マシン・インターフェース）は、コンピュータを私たち人間に親しみやすいものにしてくれましたが、それがコンピュータという機械のすべてではありません。本当は、コンピュータを利用する私たち人間に気付かれないで、その影で大事な仕事をしているプログラムやソフトウェアが沢山あります。それらを作る仕事を私はしていました。つまり、実機を動かすためには、なるだけ実機に触れないで、人間が前もって作ったプログラムでコンピュータが自動的に（つまり、オートマチックに）動けるようにしなければなりません。
そのためには、まずコンピュータに何をやらせたいのかを、お客さんと打ち合わせて、要求仕様書という文書にまとめます。その要求仕様に従って、コンピュータを含めたシステム全体でどんなことをするのかを、システム仕様書という文書にまとめます。さらに、そのシステム仕様に従って、具体的にプログラムに何をさせるのかを、プログラム仕様書にまとめます。このような文書化の作業は、プログラムが完成した後の納品前にも、コンピュータの操作手順書・機能仕様書・モジュール仕様書・各種のテスト仕様書の追加という形でついてまわります。
コンピュータのソフトウェアがそれほど複雑でなかった以前は、そのような文書化（ドキュメンテーションと言います。）は、文書ごとの冊子を作ってもそれほどの分量（ボリューム）ではなかったのですが、次第に開発するシステムの規模が大きくなって複雑化するに従って、（大規模システムに着手すればするほど、利益も大きくなるのですが）それぞれの文書の冊子の厚みが半端でなくなります。プログラム完成後にお客さんからの仕様変更の依頼を受けると、あちこち見てあちこち変更しなければならないので、こうした文書の修正箇所だけでも膨大な量になります。
このような文書を扱う作業は、理系の大学を卒業した人にとっては大変な負担でした。彼らにとって、文書の読み書きほど苦手なものはありませんでした。私がなぜ文学部の卒業であっても、この仕事のために採用されたか、やっとわかりました。この技術者（エンジニア）は、途方もなく膨大なページ数を費やして、開発したソフトウェアの内容を説明する文書を作成しなければならなかったのです。
文書の言い回しは、大体いつも決まっていました。たとえば、操作手順書だと「□□キーを押下すると、△△の画面に移行する。」というパターンの繰り返しでした。それを画面の変化する全手順で書いていくと、それだけでＡ４の冊子で百ページ近くなります。そのモジュール仕様書を作ると、Ａ４の冊子で六百ページくらいになりました。
この仕事は、給料を頂かないとしたら、ただの味気ない機械的な作業（ただし、機械ではできない手作業）もしくは拷問にすぎなかったと思われたかもしれません。しかし、私はお客さんのために開発したソフトウェアの内容を説明する大切な仕事だと思って、そのたびに一生懸命にやりました。今になって考えてみると、二十代のあの頃の私がそうした文書を大量に手書きしていたことが（当時はパソコンの日本語ワープロさえ普及していませんでした。）、今になって有形無形で何らかの糧になっていると思います。
また、もう一つ、プログラムを作る上で当時はすごいことをやっていました。それはさしずめ「紙の上で計算機を走らせる。」ということでした。今のプログラム開発の現場では違った形でやっているかもしれません。でも、私がプログラマーをやっていた昔はこんなふうであった、という話をします。
当時の話ですが、コンピュータのソフトウェア開発というのは、それで動く実機（ターゲットマシン）が高価なために、手元に無いのが普通でした。ひょっとすると、そのハードウェア（コンピュータの機械自体）がまだ完成していないで、この世にまだ稼動していない状態なのに、そのソフトウェアやプログラムを同時進行で作る場合もありました。それが上手くいくためには、いろいろとテクニックが必要でしたが、人間の知恵というのは大したもので不可能ではありませんでした。
当時、このソフトウェア開発の仕事は、紙と鉛筆と机があればできる仕事と言われていました。高価なコンピュータの機械（実機）が手元に無くても、紙と鉛筆と机という、わずかな資源でソフトウェアを開発できるのだと言うのです。上に述べたソフトウェア開発のための文書作業の続きを考えてみましょう。
前述のプログラム仕様書に従って、プログラムの動作手順をフローチャートで図式化します。ここで、私のプログラマーの世代では、一番しんどい作業が始まります。それは、『机上デバッグ』と呼ばれるものです。プログラム仕様書に書かれた内容を読んで、それをなるべく具体的なコンピュータの動きに直して、Ａ３かＡ２の大きな紙にそれをフローチャートで全て表現します。それをその仕事（プロジェクト）の責任者である先輩に、一つ一つチェックしてもらいます。コンピュータの動きであいまいな記述があると赤ペンでチェックされて、フローチャートを書き直すよう命令されます。その作業が何度も繰り返されます。
それでＯＫになると、コーディング用紙にコンピュータ・プログラミング言語で、フローチャートに従って内容を書いていきます。そのコーディング用紙に書いた内容を、プログラム開発マシンのテキストエディタ（と言っても、英文タイプライターと同じで、数字とアルファベットしか打てない。）で打ち込んで、ドットプリンタで長いプログラムリスト用紙に印刷します。
しかし、ここで終わりではありません。そのプログラムリスト用紙とフローチャートを見比べて、打ち間違いが無いか、処理内容の手順の間違いや欠落がないか、処理内容が正しく続いているかを先輩とチェックします。これも『机上デバッグ』です。コンピュ―タ・プログラミング言語によるコーディングは、まさに、数式と英文の混合であり、それを見て実際のコンピュータの動作を読み取る必要があります。頭の中でコンピュータが実際にどう動くのかを想像しながら、いわゆる「頭の中でコンピュータを動かして」、このしんどい机上デバッグを続けていきます。間違っている所は赤ペンで直して、後で一括してテキストエディタで直して、修正済みのプログラムリストを新たに用紙に打ち出します。そして、また『机上デバッグ』を繰り返します。
それがある程度完成したら、プログラム開発マシンのコンパイラーとアセンブラーにかけて、私の作ったプログラムを実機で動くマシン語（機械語とも言います。）に変換します。プログラム開発マシンのローダーというソフトウェアによって、私が作ったプログラムのマシン語が実機にやっと転送されます。なお、マシン語（機械語）とは、コンピュータ（計算機）という『機械』が読み込み、それを命令として解釈できる数字の列のことです。
それでも、最初の一、二年目は、私は実機に触ることが許されませんでした。いわゆる実機上のテストは、先輩や目上の外注の技術者に任されていました。そして、実機がちゃんと動かないと、実機の前に連れて行かれて、動かない様子を見せられて、プログラムを直せと怒鳴られました。私は、プログラム仕様通りに作りました、と言っても一切聞き入れてもらいませんでした。先輩の作成したプログラムテスト仕様書を見ると、例外のケースや操作があったりして、その辺を直さなければならず、また、机上では見つからなかったミスも直さねばならず、とにかく実機テスト時のデバッグおよびプログラム修正の指示は厳しかったと思います。
こうして、私は考えた通りに実際にはコンピュータが動かないという失敗を数多く経験しました。そのことから、コンピュータに一切触れずに、そのコンピュータの動きを想像すること、つまり、『机上デバッグ』をちゃんとやることがいかに重要かということを学びました。コンピュータのプログラムは、鉛筆で紙の上で直せば必ずちゃんと動くようになるということも学びました。要するに、コンピュータという『機械』を紙の上で動かすことを、二十代の私は習得することができました。そのために使われたコンピュータ・プログラミング言語は、数式と英文ばかりでしたが、若い私には全く苦になりませんでした。
このように、二十代の私の人生の大半は、こうしたコンピュータ・プログラマーの仕事に費やされました。でも、今になってみると、そうした机上デバッグやプログラム修正作業も、沢山の仕様書を書いたのと同様、書くことに関して何らかの糧になっているような気がしてなりません。こうした経験と努力と苦労が、何らかの違った形で今は表れているような気がしてなりません。
