コンピュータ
ドキュメントということについて
時は、コンピュータの発展期の初めの頃であろう。
ある日のこと、技師長が研究室に入ってきて、「アメリカにはドキュメントというものがあるそうだよ」と、印象に残ることを言われたことがあった。
私は、その頃、研究所において、日本のコンピュータ史に残る名機とされる大型コンピュータのOSの開発、その前段の開発環境ツールの開発中であったかもしれないが、に従事していた。
その頃のソフトウエアの開発においては、設計ドキュメントいうものを体系的に作成し残すという習慣、いや設計方式が確立されていなかったのである。しかし、設計ドキュメントのようなものを作成しなかったといえば語弊がある。ソフトウエアの開発を進める過程で、いろいろな設計メモが作成されたのである。しかし、その設計メモは、その設計者の思考の援助、体系的な設計などを目的に作成したものであり、設計者によって書く内容が異なり、ソフトウエアが完成すると雲散霧消してしまう類のものだったのである。
ソフトウエアをどのように作るかということが中心課題であり、ソフトウエアの保守や再利用という視点にまで、目が行き届いていなかった時代ということができるのであろう。こういう時代に頼りになるものは、マニュアル、論文、研究報告書に加えてプログラムリスト（印刷物）である。
FORTRANという言語のシンタックスチェッカ・プログラムを、入社して最初に開発したときには、開発済みのFORTRAN言語翻訳プログラム（FORTRANコンパイラ）が存在していたので、そのFORTRAN言語マニュアル、言語翻訳方式に関する論文(英文）、FORTRANコンパイラのリストといくつかの設計メモを与えられ、四苦八苦しながら理解した記憶がある。そして、FORTRANコンパイラのリストの解読が主体であった。
その後、OSの中のスーパバイザのターミネータの開発担当となった。ターミネータなる言葉も知らなかったので、上司に質問をしたところ、ジョブが終了したときにメッセージをプリントするのだと教えられ、そのようなものは担当者を決めるほどのことではないだろうとがっかりした記憶がある。
しかし、そのがっかり感がひっくり返えされるのに長い時間を要しなかった。
ある日、ジョブ管理というプログラムの担当者からジョブが異常終了したとき、登録してあるタイマ設定をどのようにリセットすればよいのかという質問を受けたのである。
聞かれても回答できないばかりでなく質問についてもあまり理解できない。こういう時に設計ドキュメントがあれば、それを見て対応できるが、前記の通り、設計ドキュメントが存在しない時代のことである。
さらに不幸であったのは、そのスーパバイザの中枢部を開発した人が、他のプロジェクトに移動してしまい、新しい担当者に交代してしまったことである。その時点では、スーパバイザの中枢の仕様を理解している人が皆無となってしまったのである。
こういう時には、設計ドキュメントの有用性を実感するものなのであろうが、設計ドキュメントというものが存在しない時代のことであり、そのような感傷を味わうこともなかった。
やむなくスーパバイザの中枢部のプログラムリストを取り寄せ、解読することにしたのである。質問の回答は延期してもらった。そして、このときから、私の悪戦苦闘が始まったのである。
スーパバイザの中枢部分は、OSの制御中枢であるので性能優先のプログラミングがしてある。ある条件が発生すると、数ページ先にブランチしてしまうので、リストのあちこちをめくり返しながら解読作業を続ける必要が出てきたのである。まだ、構造化プログラミングという概念が確立される前のことなのでやむを得ない側面があるが、このようなスタイルのプログラムの解読は難解を極めるのである。
さらに、OSはテーブルドリブンプロセサといわれるほど多くのテーブルが存在するが、そのテーブル構造を記した設計メモもない。やむを得ず、テーブル構造を記した設計メモを作り、アクセス条件等も記すようにしたのである。
数ヶ月ほど悪戦苦闘をしたであろうか、ようやくスーパバイザの中枢部のイメージを掴めるようになった。
しかし、残業が多いということから、組合からは当時流行っていた「三匹の侍」というテレビ映画に言寄せて「六人の侍」といって名指しされた苦い記憶がある。
しかし、この解読作業は、その後に大きな効果をもたらした。
まず、スーパバイザの中枢部、すなわちOSの制御中枢の振る舞いを理解できるようになったということである。また、設計ドキュメントの有用性についても実感できた。さらに、リストのあちこちをめくり返しながら行った解読作業の体験は、私のプログラムスタイルに陰に陽に影響を与えたことは確かなことである。
担当したターミネータは、スーパバイザの後処理部分である。使用中の残骸として残っているテーブル類をリニューアルし、実行中の入出力は完了まで待ち合わせる。処理に長時間を要する場合には、発生している割込み要因をときどき割り込ませてやることも必要である。こうして、後処理を完了させ、次のジョブを実行できる環境を準備するのである。
こういうことを通じて、ターミネータはどういう機能をもつべきかを独学で学ぶことができた。またどのような処理方式を採らなければならないかということも経験的に学んだ。特にターミネータ故の特別な処理方式を採る必要性は、解読作業をした故の成果であったと思われる。
こうして、まったく独学で学んだ機能・方式に基づいてターミネータを設計し、実装したのである。設計ドキュメントがないだけでなく設計担当者もいないという最悪の条件が私にとっては反面教師となったのである。
その後、このOSの設計ドキュメント作りが行われたことはもちろんのことである。
