5.2 検査部：探針と検査工程
（１）検査部へ試送
（２）検査部の総合テスト
（３）メモリダンプ解析
（４）困難なＯＳのバグは何か
（５）どのようにデバッグするのか
（６）罠パッチの領域
（７）なぜソフトウェアにはバグがあるのか
（８）ソフトウェアの開発は鎖の強さと同じ
（９）過酷な検査部対応
（１）検査部へ試送
VOS3/ES1の全モジュールに対する単体テストが1984年6月でほぼ完了した．もちろんこの段階では，ある程度の総合テストも行って来ている．これらからいよいよ検査部に検査をお願いするフェーズに入る．しかし正式な検査部の検査に入ってからバグが多発した場合には工場の規則上いろいろと面倒な事態になりかねない．今回のように大規模なソフトウェアの改修作業と新アーキテクチャのサポートという特別の事情があるため，検査工程に入ると相当な困難が生じる可能性が高いと思われていた．つまり縦割り組織の壁により生じる摩擦が起きるのである．そこでこのような場合は，検査部に直接，正式な検査フェーズに入ることを避け，検査部に事前の検査をしてもらうことにした．このような非公式な検査を探針テストと呼んでいた．検査部も新しいテストプログラムの作成もあり，それらが正しいテストになっているかという問題も含んでいるので一石二鳥というわけである．これらから探針テストに入り，その結果を待った．
探針テストの結果は過去のデータからみてそれほど品質が悪いとは思われないという結果であった．もちろんバグが指摘されないわけではなく初期の段階であるため非常に多くのバグが指摘される．これらは単純なミスが多い．１ヶ月ほどの探針テスト，その結果の修正を繰り返し，設計部と検査部は検査の体制が整ったと判断した．そこで，1984年8月からは本格的な検査部による検査に入った．実はここからが検査部との真剣勝負で苦しい戦いが始まるのである．検査部との戦いになるが，本当の敵は検査部ではなく自分たち設計部内にある．
＜先頭へ＞
＜ページの最後へ＞
（２）検査部の総合テスト
1984年８月より検査部による検査が開始された．検査部は検査結果が予想以上に悪いときは検査打ち切る．つまりバグが多発するようであると設計がそれらのバグ対策の許容範囲を越えてしまい，工期がむしろ遅延してしまうことへの気遣いである．検査部から指摘されたバグの各々にはペナルティが設計部に課される．ペナルティとは一件のバグあたりの潜在バグの検出数：Nである．指摘されたバグ１件に対して，設計は潜在しているN個のバグを新たに見つけて検査部に報告しなければならない．この方法は残酷に見えるが設計には利点が多い．検査部から指摘されるよりも自分たち自身でバグを発見し修正するのが正常でありまた得策である．
検査初期の段階ではNの値は小さいが検査工程が進むに従いNの値は大きくなっていく．検査初期の段階は検査から指摘されるバグ件数が一般的に多いため，Nの数は小さくても潜在バグを見つけなければならない数も大きい．逆に，工程が進むにつれて検査部のバグ指摘件数は少なくなるが，Nが大きくなる．工程が進んでから指摘されるバグは原因究明に時間を要するようになる．また，プログラムの品質は徐々に高くなっていくため，ペナルティのNが大きくなると潜在バグを見つけづらい．この矛盾に工程完了まで設計部は悩まされるのである．この結果，検査部と設計部は検査のフェーズに入ると協力関係から敵同士のようにになってしまい，工場長臨席の御前会議の場において感情的になるぐらいの戦いをすることがある．板挟みになる工場長も大変な思いであったろう．
検査部の指摘は検査結果の簡単なメモしかない．どのような検査によりどのような症状でシステムダウンになったなど親切な説明は一般的にはない．システムがおかしくなった時点のメモリダンプ＊はファイル名：XXXである，というぐらいの情報しかもらえない．しかし，この検査結果に対する設計部の対応はきちんと行わねばならない．すべてバグ報告書として採番され責任者の押印をもらいドキュメントを残すことになっている．報告書にはバグの原因，対策，動作確認方法とその結果，ソースプログラムのPAD図（変更前後が対になったもの）などを作成する義務がある．
（注）メモリダンプ＊：
memory dump は主記憶の全体を2次記憶に格納したものである．コンピュータがシステムダウンしたときなどはメモリ内容をそのまま全部，磁気ディスクや磁気テープに吐き出しておく．つまりコンピュータのダイイングメッセージ(dying message)である．人間で例えるならば死体のようなものであり，これを詳細に調べることで死因を判定しなければならない．コンピュータの場合は，死因が分かれば死なないように処置をして少しずつ長寿命の身体を作っていける．
当時は検査によりシステムダウンとなると，検査部はメモリダンプを磁気テープ（多くは2400フィート）に格納し，テープに検査番号を書き所定の場所におくことになっている．軽微な障害の場合はシステムダウンとせずにＯＳ自身のメモリダンプとしてSVC（スーパーバイザコール）ダンプが同様に取られコンソールにその旨が印字される．検査部はSVCダンプ取得用に常時磁気テープをマウントしている．これらの情報も設計部には通知される．そこで，我々は検査部から知らされたこれらのダンプ情報を基にバグ解析を行い，上記の通りの作業を約４ヶ月間行ったのである．したがって毎日のようにメモリダンプを睨む生活が続いた．
＜先頭へ＞
＜ページの最後へ＞
（３）メモリダンプ解析
ソースコードはHPLというPL/1のサブセットにシステム記述のための機能が加わった言語で記述されている．しかしＯＳのデバッグはほとんどがバイナリイメージのメモリを眺めて作業を進める．つまり，HPLの出力リストのアセンブラ部分を頼りにメモリダンプを眺めることになる．
31ビットアドレッシングにより仮想記憶領域の拡大と実記憶領域の拡大から従来以上にメモリダンプのサイズが巨大化した．膨大なメモリダンプの数をいかに短時間で解析するのかが問題であった．この長期派遣の前に私が提案し実現したＯＳ開発用生産治工具であるOSTD(Operating System Test Driver)は現場で大いに力を発揮したのである．（OSTDについては別のところで説明するつもりなので関心のある方は読んでいただきたい）
検査部から指摘のあったバグに対応するメモリダンプの磁気テープ内容をOSTDのマシンに備えられた磁気ディスクに格納し，TSS端末からOSTDの機能を立ち上げてダンプ解析が可能になったのである．OSTDのオペレータには磁気テープ内容をOSTDにコピーする依頼を出しておけばディスクに空きができた段階でコピーされ，その完了通知が来る．この通知がくるとTSS端末さえあればダンプ解析が可能となる．私は主任研究員（課長）の権限で研究所からB16というパソコンを手に入れ自分の席に設置した．このパソコンにはVOS3のTSS端末シミュレータというアプリケーションが載っていた．つまり，B16を使ってOSTDを使用できたのである．またワープロ機能もあり，検査部に提出すべきバグ対策用のドキュメントの作成が可能となっていた．これは大いに効率的であった．
OSTDではダンプ解析の自動化機能も可能になっていた．通常ダンプ解析にはVMコマンド（VMSという仮想計算機を実現する制御プログラムの実行コマンド）を逐次タイプインしながら作業を進めるのであるが，この一連のコマンドをコマンドプロセジャ（一連の手続き）としてファイルに登録しておけば自動的に一塊の作業が行えるのである．例えば，メモリ内のある番地からリスト形式になっている制御情報のテーブルをたどりながらその内容の正当性をチェックするような作業をコマンドの列としてコマンドプロセジャのファイルとしておける．この種のプロセジャを蓄積しておけばメモリダンプの解析・診断を自動化できるため解析の省力化が図れるのである．UNIXのシェルスクリプトと同一の機能である．これらの解析・診断結果を踏まえた上で次の解析作業が進められる．メモリ管理のメモリダンプをチェックする機能を蓄積して相互に利用することでさらにバグ解析が効率的になった．
＜先頭へ＞
＜ページの最後へ＞
（４）困難なＯＳのバグは何か
検査部の指摘には当然のことだが対応しなければならない．しかし，設計部として検査部に指摘される前にバグ取りをするのは当然の義務である．そこで私は膨大な総合的・複合テストのプログラムを開発した．このプログラム群はメモリ管理だけではなく多くのモジュールをテストでき，たくさんのバグを検出した．このテストプログラムは評判になり，テストプログラムの集合が「Dr. Yoshizawa Job」と呼ばれるようになった．これを耳にした検査部は「Dr. Yoshizawa Job」を使用したいので貸して欲しいと申し込んできたので提供することにした．ピープルウエアなる本で述べられていたか定かではないが，もし学卒新入社員が10名配属になったと仮定して，あなたなら優秀な人材を設計部と検査部のどちらにどのように配属をしますか？という問題を提起していたように思う．一般的には設計は製品開発の要所であるので一番優秀な人材を投入するのが常識的と思われる．誤解を生むのは承知での発言となるが，ソフトウェア工場においてはそれが顕著であった．しかし，製品のテストという仕事は地味ではあるがかなり創造的な仕事であるということがテストプログラムの作成で痛感した．極めて多くのテストプログラムをこの時に作成したが，自分達の開発したＯＳをどうすれば強固にできるのかを徹底的に考えた．テストプログラムは通常はユーザプログラムとして動作するが，VOS3には特権状態に出入りできる隠しSVCがあり，これを使うと強力なテストが実行出来る．コンピュータが壊れるのではないかと云うぐらいの覚悟でテストプログラムを作ったのである．
蛇足だが（中研）入社後１年ぐらい経た時に，堤正義主任研究員から「吉澤を見込んで，メモリ（当時はHITAC 5020のコアメモリ）テストのプログラムを作ってくれないか？」と依頼されたことがあった．そのときは，単に，堤さんから言われたメモリパターンを指定の番地に書込み，それらを指定された回数だけ繰り返し連続領域に（おそらくメモリバンク毎に）書込み，読出しするだけであり自分の創造性はなかった．しかし，これでメモリの不具合を発見できたと感謝されたことがあった．このケースでは堤さんの創造性が優れていたのであり，当時の私は単なるプログラマであった．
最後の最後までテストプログラムの作成は続いた．この結果，メモリ管理以外にも多数のバグを発見でき品質向上に寄与できたと思っている．本来の趣旨であるメモリ管理の品質も抜本的に向上した．ソフトウェア工場ではVOS3/ES1の拡張メモリの実現よりも，このテストプログラムの方がより価値が高いなどと冗談を云う人がいた．これこそ，社長ソフト賞に値するとまじめに云う人もいたぐらいである．設計部は今までPCL消化のための単体テストプログラムだけを作り，version upの際にそれらを再利用するだけであった．私のように，総合的なテストプログラムをシステマティックに開発してこなかったのである．
＜先頭へ＞
＜ページの最後へ＞
話を元に戻す．ＯＳでのバグ解決でどのような部分が難しいのかを説明する．上記にメモリダンプの解析などで触れたように，ＯＳのデバッグでは制御情報のデータ構造（これを制御テーブルと呼ぶことが多い）の整合性をチェックすることに主眼がある．つまりデータ構造の各要素；状態変数，カウンタ値，アドレス（ポインタとも云う）表示，などの正しさが問題となる．つまりバグの多くは，これらのデータ構造の要素が「何者か」によって不当に書き換えられているときに矛盾が生じることで誤動作に繋がりシステムダウンとなる可能性がある．「何者か」と云う点が問題である．
一般的に：
「プログラム」＝「手続き:procedure」＋「データ構造:data structure」
と云われるように手続きはデータ構造の内容にもとづいて，あるいは処理結果をデータ構造内に記録し処理を完了するため，何者かがデータ構造を不当に操作したならば，このプログラムは誤動作を免れない．ところが，やっかいなことにこの「何者か」は決して「私がその犯人です」とは自首しないのである．自首する場合もあるが，めったに無い．その理由はＯＳがCPUの特権状態というメモリ保護の対象外で動作しており不当な書込みをしてもハードウェア的な記憶保護機構には引っかからない．つまり最も権限の強いモード（特権状態という）で命令実行しているためである．プログラムではレジスタ内の情報を一時的にメモリに書込み，その後，その値をレジスタに回復して処理を続けるることがある．このような時，誤った領域に対する書込みは「何者」にとっては正常な処理となる．しかし，書き込まれたデータ構造に基づき処理をしている手続きは誤動作をする可能性が高く，これが直接，もしくは間接的な原因でシステムクラッシュに至ることがある．
このような不当書込みをされて誤動作したプログラムのデバッグはとても厄介である．このバグの解決は被害者たるプログラマが証拠と犯人である「何者か」を共に特定し，かつ相手に承認させねばならないというルールになっている．この種のバグは検査工程が進むに連れて多くなりバグ潰しを困難なものにしている．初期の段階では軽微なバグが多いので，「それじゃ，昼のウドンをおごるから勘弁して！」で済むが，だんだん工程が進み，バグが深刻な影響を与えるようになってくると，自分が犯人であることを正直に言えなくなってくる．これが大きな問題点である．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題）
IBM System/370では主記憶の０ページ，つまり0から4095番地までの領域をプリフェックス領域(prefix area)と呼んでいる．この部分はハードウェアと密接な関係がある情報が格納されている重要な部分がある．ある機種以降のバージョンからこの領域にはたとえ特権状態であっても書込み禁止にする機能となった．日立のマシンも同様の機能を備えたところ，VOS3がシステムダウンを多発するようになった．理由は簡単である．IBM System/360以降のアーキテクチャでは，アドレッシング（メモリの番地付け方法）における実効アドレス(effective address)の計算は以下のようになっている．
（実効アドレス）＝（基底アドレス）＋（インデックス）＋（変位） である．
ここで（基底アドレス）はベースレジスタで指定する．また（インデックス）はインデックスレジスタの値である．そして最後の（変位）は命令オペランド内の12ビットである．各命令のベースレジスタやインデックスレジスタの指定はプログラマにより行われる．このことから，実効アドレスを求める際に，ベースレジスタとインデックスレジスタの指定を忘れるようなことをすると（変位）のみの値が（実効アドレス）となることがある．その結果，0〜4095番地を示すことになる．この事実から不当な書込みをしても今まではシステムダウンにならないケースが多くあったことを意味している．おそらく，IBMはこのようなアドレッシングエラーによるバグを解決する手段として０ページのメモリ保護機構を新たに作ったのではないだろうか．
＜先頭へ＞
＜ページの最後へ＞
（５）どのようにデバッグするのか
メモリダンプにはシステムダウン時のPSW(Program Status Word：（注）を参照）,汎用レジスタ値，制御レジスタ値，などの情報がある．デバッグ作業はまずこの情報の分析から始める．どこの番地で何が起きたのか，レジスタの内容から処理の過程をおおまかに把握する．そして16個のレジスタ値を詳細に眺め，不審な値を含んだレジスタは無いか，などを注意深く観察する．VOS3ではシステム全体としてレジスタの使用方法には一定の決まりがある．この決まりはすべてのコンパイラの作るオブジェクトプログラムに共通している．これはプログラム間の相互の約束のためである．ちなみに，GR1はパラメータ（引数）領域を示し，GR13はレジスタの退避領域を，GR14はサブルーチンの帰りアドレス，GR15はサブルーチンのアドレスである．ここでGRはGeneral Register（汎用レジスタ）でありGR0からGR15まで16個ある．このような規則をリンケージコンベンション(linkage convention)と云う
（注）
PSW: CPUの状態を示すフラグ類と次に実行すべき命令アドレスを示す８バイト情報．
また，ＯＳは重要なイベント（事象）情報を特定の領域に記録しておりシステムダウン寸前にどのようなイベントがあったのかを知ることができる．イベントには割込み（入出力，タイマ，スーパーバイザ命令実行，ディスパッチ，など）の情報が記録されていて，各プロセスが実行してきた経過を知ることができる．ただしイベント情報は領域の関係からラップアラウンドで記録されているので，それほど長い時間帯をカバーできるわけではない．最近の自動車にはドライブレコーダーが装備できるが，この機能はまさに事故発生時の事象を記録するものであり，ＯＳのこの機能に類似している．
＜先頭へ＞
＜ページの最後へ＞
肝心の不当書込みであるが，まずはシステムが誤動作した原因となる不当書込みの領域を特定する．特定できたならばその部分がバイト単位（つまり８ビットだけ）なのか，２バイトか４バイトかの区別をする．稀に８バイトやそれ以外の長さであることもある．その後，不当書込みで壊されたと思われる部分のビットパターンを注意深く観察する．例えば，フラグ操作の類の場合は１ビットあるいは数ビットだけが変更されていることが多い．そのビットポジションが判明すれば操作するモジュールを推測する．またバイト単位の操作であるならば文字を書き込んだのか？それともカウンタ値のようなものかなどの判断をする．カウンタとして使用したようであればそのようなモジュールを調べる．文字についても同じである．４バイト長の書込みの場合もカウンタ値のように+1や-1されたものか，それとも，メモリのアドレスのような値であるか，などを観察する．メモリアドレスと思われる場合はそのアドレスには何が入っているのか，該当領域はどのモジュールの管理領域なのか，などを調べる．多くは制御情報のデータ構造が入っている領域であることが多いので「何者」を特定することが可能となる．
いろいろな思考を重ねて「何者か」のあたりをつける．その後，「何者か」のプログラムソースコードを調査して，先に述べたアドレッシング際に使う「変位」の値から，その変数名をアクセスしている手続き部分をすべて調べる．このために，変数を参照しているモジュール名とそのソースコード番号のすべてが分かるクロスリファレンスリストがあった．分厚いリストをひっくり返して調べるのが大変な作業だった．UNIXではこれがいとも簡単に出来ること後にを知った．こうやって，犯人らしき「何者か」を特定していくのである．特定できれば不当書込みの行為をしている現場を押さえるために，メモリにパッチを当て，被害を受けた制御情報のデータ構造のアドレスであることを確認し，犯行現場を押さえる．多くの場合はメモリダンプを出して処理を終了させる．このようにして証拠を揃え，犯人である相手方に証拠を揃え，そのバグの指摘が正しいことを認めさせる．このように一件ずつの不当書込みバグを潰していくのである．
＜先頭へ＞
＜ページの最後へ＞
（６）罠パッチの領域
上記のようにメモリへのパッチはデバッグに良く利用される手法である．ソースコードを書き換えるような修正を加える方法でのデバッグ方法は，そのバグが解決した時にパッチを取り除き元に戻す必要がある．ソースコードはある意味で神聖な製品であるので余計な手を加えない方が良い．そこでロードモジュールにバイナリイメージを書き込む方法がパッチである．いわゆる temporary fixである．
デバッグを容易にするにはパッチは必要悪である．パッチはそのプログラムが実行されたときに問題となっている変数のチェックをしたり，その時のレジスタの値を調べたりする小さなプログラムを実行させるために使う．あるいは，制御の流れを変更することで仮想的な条件下のテストを行うことなどが可能になる．このためは各モジュールにパッチによる処理を可能にするだけのプログラム領域が必要となる．そこでプログラマは密かに各モジュールにパッチ領域をある程度設けておき，チェックなどしたいところに無条件分岐命令をパッチしパッチ領域でチェックの動作を行う．これらの領域は本来の製品には無駄なメモリ領域となるため作ることは禁止されているがデバッグの効率化のためには必要悪として作っていた．もちろん，最終のソースコード提出版にはこれらの領域は取り除いてある．パッチを当てる時は，モジュール名はEBCIDIKであるが，メモリアドレス，書き込む値，などはすべて16進数で表示しなければならない．つまり書き込む値の多くは命令語であり，そこではレジスタ，ベースレジスタ，インデックスレジスタ，そして変位（displacement）などを正しく指定しなければならない．
＜先頭へ＞
＜ページの最後へ＞
（７）なぜソフトウェアにはバグがあるのか
ソフトウェアの開発の大部分の時間は品質向上，つまりデバッグ作業の時間である．プログラマは大半の時間をプログラミングに費やしているのではなく，自分で作った誤りの修正に終始しているということである．どうしてこのようにデバッグに長時間を費やすのか一般人には理解されない．プログラマは頭脳が劣っているからだろうか．これも一般的にはそのように解釈はされていない．プログラマは頭脳が少し優秀であるというのが一般的な考えではないだろうか．我々の世代では知能検査に似たプログラマ適性試験のようなものがあったように思える．当時のコンピュータは極めて高価であり頭の回転が良くないと，また数字を瞬時に覚えるなどの能力，数字を見て類推する能力などが必要だったためであろう．
いろいろな議論がなされてきた．今のようにソフトウェアの価値が高くなる前はデバッグ作業に多くの時間を割くことに理解はされていなかった．これは人からに聞いた話であるが，NECの小林社長が新装となった府中のソフトウェア開発現場を訪れた際に，責任者に対して「あのパーティションに入ってブラウン管の画面をずっと眺めている多くの人達は一体何をしているのかね？」と尋ねたところ，「あれはプログラムのデバッグをしているのです」と答えたという．そこで社長は「デバッグとは何だね？」と聞くと「プログラムの誤りを修正しているのです」と．すると小林社長は「プログラマは自分で作ったミスを修正するために長時間仕事を続けるとは何事だ！」と怒ったと聞いたことがある．確かに小林社長のいうことは常識的で正しいように思う．
一方，ハードウェアの場合はデバッグに長時間をとられるのだろうか？彼らに聞くとソフトウェアほど長くは無いとのこと．その理由は論理（ロジック）がソフトウェアに比べると浅いとい言うのである．確かにソフトウェアの場合は単純なコンピュータの命令を数千，数万，いやそれ以上に長く続けて一つの仕事（機能）を達成している．例えば，磁気ディスクからデータを読み込むためには，現代のＯＳでは数千から数万の命令を誤りなく実行しなくてはならない．しかも入出力の場合は機械的な動作があるために，CPUの命令実行とは非同期な割込みを使った処理が一般的である．この長い命令列の中で一つでも誤りがあってはならないのである．さらに，この長い命令実行列（プロセスと呼ぶ）とは別の処理（プロセス）も並列に実行されるため複雑な動きになる．つまりハードウェアと異なりプロセスの実行過程が長い命令実行列になっており，加減乗除命令というより比較，判断などの論理的な処理が多く論理が深いのである．このように論理が深いため機能分割してプログラムを作成する．そうすると相互のモジュールの間にはインターフェースを明確にしておく必要がある．このような開発をせざるを得ないので，ソフトウェアではインターフェースを相互に守ることが重要になる．
重要なのはプログラム間のインターフェースであるがここに落とし穴がある．具体的なインターフェースはパラメータでありモジュール間の約束で相互に引き渡される．つまりインプットとアウトプットである．ところが多くのプログラマは受取ったパラメータ値が正しいと見做して処理を進める．パラメータの各々の正当性をチェックするとプログラムの量が増えてしまうため一般的にはチェックを行わない．仮に誤ったパラメータに基づき処理を進め，得られた結果を第３のモジュールに渡すとどうなるであろう．第３のモジュールも受取った値を正しいと信じて処理を進めた結果，不当な書込みを第４の管理する制御情報データ構造内に行うことがある．その結果，第４のモジュールが実行されると破綻する．ＯＳでは前に述べた通り特権状態でプログラムが実行されるために記憶保護は無効である．このように，プログラマとは不完全な人間が完全なるものを要求される製品を作らねばならないという矛盾のある職業なのである．先に述べた制御情報テーブルもモジュール間のインターフェイスである．この部分に第三者から不当な書込みがなされればインターフェイスは崩れてしまう．
＜先頭へ＞
＜ページの最後へ＞
（８）ソフトウェアの開発は鎖の強さと同じ
優秀な人材だけを集めて相互のコミュニケーションも円滑であり互いに協調しあうような職場は理想である．大規模なプログラムを大人数で開発する時代にあってこのような理想的な職場は実現不可能である．開発現場では多種雑多な人間集団であり（協力会社と呼んでいたが）下請け会社も入っていた．日本のソフトウェア産業の三重構造は大きな問題である．日立製作所の正社員は主に管理の仕事に従事し手を汚す実際の仕事は下請け会社，そのまたその下請け会社が行う仕組みになっている．我々研究所の人間も工場では手を汚す作業員であり，下請けに位置づけられていたのかも知れない．こうなると命令指揮権の問題が派遣法などの法的制約からあるため技術的指導などが間接的にしか行えない．
具体的には，協力会社に入社したばかりの高等専門学校卒の従業員がグループに配属されていた．協力会社のマネージャはこの人間にも製品の一部を担当させて欲しいと要求してくる．そうしないと協力会社の使命を果たせないためもある．それに派遣者の成長も期待できないためであろう．私にとってこれはあまりにも無謀と思えた．日立側の部課長も協力会社との関係を良くしておきたいので，私に我慢するよう協力を要請してくる．だが明らかにズブの素人でありＯＳの概念，プログラミングの基礎，その他ドキュメンテーション能力，などあらゆる点で製品に関与できる水準のスキルを身につけていない人間である．このような人間を今回のような緊急の状況下で投入すべきでは無いと思っていた．
案の定，このような人間に仕事を与えると何もしなくてよいにもかかわらず与えられたプログラムに手を加えるのである．これは明らかに破壊行為である．これがバグとして検査部から指摘される．この種の人間は自分で潜在的なバグなど発見できるはずがないので，この結果，例のペナルティNが課せられ我々がその尻拭いをしなくてはならないことになる．時間と費用の無駄である．そこでこのような事態が数回起きたので，私はその新人からプログラムに関する仕事をすべて取り上げてしまった．ソフトウェアの品質は鎖の強さと同じなのである．つまり一番強度の弱いところが製品の品質になってしまう．Brooksも同様のことをOS/360開発時に経験したことを著書の中で述べている．
プログラミングの仕事もいろいろある．職場の整理整頓，メモリダンプの整理やコンピュータ内のファイル管理，プログラムをコンパイルしたリストの収集（コンピュータセンターからプリントアウトされたリストを運搬する），自分たちの担当している部分の設計書を読んで理解するなどの勉強，そしてMシリーズコンピュータのアーキテクチャの勉強，等など．これらをこなしながら，門前の小僧習わぬ経を読むではないが，徐々に能力を高めていくべきだ．だが，私の取った行為に日立サイドの部課長は批判的であった．しかたなく修正や改良の必要のないモジュールを担当させ，勉強するだけの義務を与えた．この問題は民主的な運営がよいのか貴族主義がよいのか哲学の問題になる．
＜先頭へ＞
＜ページの最後へ＞
（９）過酷な検査部対応
大分横道にそれてしまった．本論に戻る．８月に入り本格的な検査に入った．検査部は設計部の要求通りには検査をしてくれない．前回の検査結果のバグを全部解決し，さらに課されたペナルティをすべて解消し，さらにどのような品質向上を行ったのかを説明する必要がある．次回の検査結果に対する見通しも宣言する必要がある．検査部は製品保証の責任者であって製品出荷期日の責任者ではない．製品出荷は企業の収益に関係しており設計部は全国の営業と検査部との間にあり常に苦しい立場である．このような役割分担であるので設計部が収益管理の中心（profit center）になっていた．したがって最も責任が重いのである．
検査部からのバグ指摘に対する対処は過酷であった．作業内容は先に述べた通りである．８月から工期完了までの勤務スタイルをここで説明しておく．戸塚と長後の中間地点の立場（たてば）に曙寮という独身寮がありここに単身赴任で住んでいた．寮では朝７時45分頃に起き朝食を摂る．８時過ぎに寮を出発し，ほとんど毎日歩いてソフトウェア工場に通っていた．工場の門近くにパン屋がありそこで昼食を買い職場に８時40分までに到着する．寮には月曜から金曜まで泊まり土曜は立川の自宅に帰るのが常であった．８月以降の勤務時間は月曜から金曜までは午前２時より前に退社したことはない．工場では毎日のように午後10時から部長席でその日の進捗状況報告，問題点の洗い出しと対策，責任者のアサイン，翌日行うべき重点作業の確認，などを１時間ほど行う．それから席に戻り部下に必要事項を報告し作業を継続する．午前２時ぐらいになるとタクシーを正門に呼び頃合いを見て帰り支度をする．タクシーで立場の交差点近くにある（ファミレスの）スカイラークまで乗りここで夕食を摂る．寮には午前３時前に帰り微温くなった風呂を浴びて二段ベッドで午前３時には寝るという生活を繰り返した．
土曜の休日は少し朝寝坊して寮でゆっくり朝食を摂り午前9時過ぎに工場に向かう．当時は形の上では管理職であったので土曜はその残務処理をすることにしていた．たくさんの回覧物に目を通したりIBMや業界の動向を把握したりした．また（シ研）の上司に報告書などを書き状況を知らせた．土曜は午後５時ぐらいに残務処理を終わらせ立川の自宅に帰った．日曜はほとんど身体を休めることにした．当時の唯一の楽しみは，役所広司が主演していた宮本武蔵の録画を見ることだった．吉川英治の作品を随分たくさん読んでいたのでこの番組がNHKで始まるということから，土曜のある日，秋葉原に途中下車し，日立製のVHSビデオデッキを18万円で買った覚えがある．当時はVHSビデオ（マスタックスだったか？）が出始めたばかりでも随分高かったが画質がそれほど良いとは思えなかった．そして月曜は朝５時に起きて午前６時１５分ぐらいには家を出て国立駅から東京駅で乗換え，戸塚駅まで行き，また深夜までの仕事を繰り返した．
管理職，つまり非組合員であったため残業代はゼロであった．部下は皆，残業代が本給よりも多いと給料日のたびに喜んでいたがこちらの収入は従来と全く同じであった．少し増えたのは単身赴任していたので別居手当だけであったが，寮費，毎週のように自宅に帰る交通費，そして食費などで消えていた．工場の人達もいつもの残業代よりもこの脱IBMのお陰で随分給料が増えたことを喜んでいた．収入という意味では管理職には恩恵がなかったのは事実である．こんな生活が1984年の年末ぎりぎりまで続いていた．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題）
ドキュメンテーションとプログラム書き
プログラムの天才と世間で言われる人物がいる．そのような多くのプログラマは確かにプログラムを他よりも早く作成することができる．この種の人間は私の廻りにも何人か居た．しかしこの種の人間はプログラムを書くだけの能力しか備わっていない傾向にある．企業でソフトウェアを作る上で重要なのは単なるプログラミング能力だけでは困るのである．必要なのはソフトウェア開発で必要となるドキュメンテーション能力である．つまり各種の設計書を作成する能力が不可欠となる．また一人で仕事をするようなことは少なくグループでの仕事となるため相互のコミュニケーション能力も必要である．
プログラミングにだけ特化したスキルがある人間はそれなりに貴重な人材であるが，これだけでは企業の技術者とはいえない．この種の人間は技能者あるいは技師(technician)であって，技術者(engineer)ではない．技術者は問題を発見して定式化し，その解決策を見出し，その効果を（できれば定量的に）予測しドキュメンテーションを整え，関連部署を説得し製品化に結びつけるという一連の仕事を成し遂げられねばならない．つまり創造性が求められる職業なのである．日本では技術者と技能者，工芸家(craftsman)を区別することなく「技術者」という言葉で括っているように思える．職業に貴賎はないというのは分かった上で言うのだが，指示されたプログラムだけを作る人間は技能工であり左官屋，タイル工，溶接工，などと同レベルである．このようなことは学生時代の社会学という永井道雄教授の講義で教えてもらった．その際，故永井教授は「諸君は税金で賄われている国立大学で教育を受けている．だから創造的なエンジニアとなり国家にお返しをしなくてはならない．決してテクニシャンになるな．」という意味のことをおしゃっていたことを覚えている．永井教授は1974年三木内閣の時に文部大臣に就任されたのを覚えている．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
（１）検査部へ試送
（２）検査部の総合テスト
（３）メモリダンプ解析
（４）困難なＯＳのバグは何か
（５）どのようにデバッグするのか
（６）罠パッチの領域
（７）なぜソフトウェアにはバグがあるのか
（８）ソフトウェアの開発は鎖の強さと同じ
（９）過酷な検査部対応
（１）検査部へ試送
VOS3/ES1の全モジュールに対する単体テストが1984年6月でほぼ完了した．もちろんこの段階では，ある程度の総合テストも行って来ている．これらからいよいよ検査部に検査をお願いするフェーズに入る．しかし正式な検査部の検査に入ってからバグが多発した場合には工場の規則上いろいろと面倒な事態になりかねない．今回のように大規模なソフトウェアの改修作業と新アーキテクチャのサポートという特別の事情があるため，検査工程に入ると相当な困難が生じる可能性が高いと思われていた．つまり縦割り組織の壁により生じる摩擦が起きるのである．そこでこのような場合は，検査部に直接，正式な検査フェーズに入ることを避け，検査部に事前の検査をしてもらうことにした．このような非公式な検査を探針テストと呼んでいた．検査部も新しいテストプログラムの作成もあり，それらが正しいテストになっているかという問題も含んでいるので一石二鳥というわけである．これらから探針テストに入り，その結果を待った．
探針テストの結果は過去のデータからみてそれほど品質が悪いとは思われないという結果であった．もちろんバグが指摘されないわけではなく初期の段階であるため非常に多くのバグが指摘される．これらは単純なミスが多い．１ヶ月ほどの探針テスト，その結果の修正を繰り返し，設計部と検査部は検査の体制が整ったと判断した．そこで，1984年8月からは本格的な検査部による検査に入った．実はここからが検査部との真剣勝負で苦しい戦いが始まるのである．検査部との戦いになるが，本当の敵は検査部ではなく自分たち設計部内にある．
＜先頭へ＞ ＜ページの最後へ＞
（２）検査部の総合テスト
1984年８月より検査部による検査が開始された．検査部は検査結果が予想以上に悪いときは検査打ち切る．つまりバグが多発するようであると設計がそれらのバグ対策の許容範囲を越えてしまい，工期がむしろ遅延してしまうことへの気遣いである．検査部から指摘されたバグの各々にはペナルティが設計部に課される．ペナルティとは一件のバグあたりの潜在バグの検出数：Nである．指摘されたバグ１件に対して，設計は潜在しているN個のバグを新たに見つけて検査部に報告しなければならない．この方法は残酷に見えるが設計には利点が多い．検査部から指摘されるよりも自分たち自身でバグを発見し修正するのが正常でありまた得策である．
検査初期の段階ではNの値は小さいが検査工程が進むに従いNの値は大きくなっていく．検査初期の段階は検査から指摘されるバグ件数が一般的に多いため，Nの数は小さくても潜在バグを見つけなければならない数も大きい．逆に，工程が進むにつれて検査部のバグ指摘件数は少なくなるが，Nが大きくなる．工程が進んでから指摘されるバグは原因究明に時間を要するようになる．また，プログラムの品質は徐々に高くなっていくため，ペナルティのNが大きくなると潜在バグを見つけづらい．この矛盾に工程完了まで設計部は悩まされるのである．この結果，検査部と設計部は検査のフェーズに入ると協力関係から敵同士のようにになってしまい，工場長臨席の御前会議の場において感情的になるぐらいの戦いをすることがある．板挟みになる工場長も大変な思いであったろう．
検査部の指摘は検査結果の簡単なメモしかない．どのような検査によりどのような症状でシステムダウンになったなど親切な説明は一般的にはない．システムがおかしくなった時点のメモリダンプ＊はファイル名：XXXである，というぐらいの情報しかもらえない．しかし，この検査結果に対する設計部の対応はきちんと行わねばならない．すべてバグ報告書として採番され責任者の押印をもらいドキュメントを残すことになっている．報告書にはバグの原因，対策，動作確認方法とその結果，ソースプログラムのPAD図（変更前後が対になったもの）などを作成する義務がある．
（注）メモリダンプ＊：
memory dump は主記憶の全体を2次記憶に格納したものである．コンピュータがシステムダウンしたときなどはメモリ内容をそのまま全部，磁気ディスクや磁気テープに吐き出しておく．つまりコンピュータのダイイングメッセージ(dying message)である．人間で例えるならば死体のようなものであり，これを詳細に調べることで死因を判定しなければならない．コンピュータの場合は，死因が分かれば死なないように処置をして少しずつ長寿命の身体を作っていける．
当時は検査によりシステムダウンとなると，検査部はメモリダンプを磁気テープ（多くは2400フィート）に格納し，テープに検査番号を書き所定の場所におくことになっている．軽微な障害の場合はシステムダウンとせずにＯＳ自身のメモリダンプとしてSVC（スーパーバイザコール）ダンプが同様に取られコンソールにその旨が印字される．検査部はSVCダンプ取得用に常時磁気テープをマウントしている．これらの情報も設計部には通知される．そこで，我々は検査部から知らされたこれらのダンプ情報を基にバグ解析を行い，上記の通りの作業を約４ヶ月間行ったのである．したがって毎日のようにメモリダンプを睨む生活が続いた．
＜先頭へ＞
＜ページの最後へ＞
（３）メモリダンプ解析
ソースコードはHPLというPL/1のサブセットにシステム記述のための機能が加わった言語で記述されている．しかしＯＳのデバッグはほとんどがバイナリイメージのメモリを眺めて作業を進める．つまり，HPLの出力リストのアセンブラ部分を頼りにメモリダンプを眺めることになる．
31ビットアドレッシングにより仮想記憶領域の拡大と実記憶領域の拡大から従来以上にメモリダンプのサイズが巨大化した．膨大なメモリダンプの数をいかに短時間で解析するのかが問題であった．この長期派遣の前に私が提案し実現したＯＳ開発用生産治工具であるOSTD(Operating System Test Driver)は現場で大いに力を発揮したのである．（OSTDについては別のところで説明するつもりなので関心のある方は読んでいただきたい）
検査部から指摘のあったバグに対応するメモリダンプの磁気テープ内容をOSTDのマシンに備えられた磁気ディスクに格納し，TSS端末からOSTDの機能を立ち上げてダンプ解析が可能になったのである．OSTDのオペレータには磁気テープ内容をOSTDにコピーする依頼を出しておけばディスクに空きができた段階でコピーされ，その完了通知が来る．この通知がくるとTSS端末さえあればダンプ解析が可能となる．私は主任研究員（課長）の権限で研究所からB16というパソコンを手に入れ自分の席に設置した．このパソコンにはVOS3のTSS端末シミュレータというアプリケーションが載っていた．つまり，B16を使ってOSTDを使用できたのである．またワープロ機能もあり，検査部に提出すべきバグ対策用のドキュメントの作成が可能となっていた．これは大いに効率的であった．
OSTDではダンプ解析の自動化機能も可能になっていた．通常ダンプ解析にはVMコマンド（VMSという仮想計算機を実現する制御プログラムの実行コマンド）を逐次タイプインしながら作業を進めるのであるが，この一連のコマンドをコマンドプロセジャ（一連の手続き）としてファイルに登録しておけば自動的に一塊の作業が行えるのである．例えば，メモリ内のある番地からリスト形式になっている制御情報のテーブルをたどりながらその内容の正当性をチェックするような作業をコマンドの列としてコマンドプロセジャのファイルとしておける．この種のプロセジャを蓄積しておけばメモリダンプの解析・診断を自動化できるため解析の省力化が図れるのである．UNIXのシェルスクリプトと同一の機能である．これらの解析・診断結果を踏まえた上で次の解析作業が進められる．メモリ管理のメモリダンプをチェックする機能を蓄積して相互に利用することでさらにバグ解析が効率的になった．
＜先頭へ＞
＜ページの最後へ＞
（４）困難なＯＳのバグは何か
検査部の指摘には当然のことだが対応しなければならない．しかし，設計部として検査部に指摘される前にバグ取りをするのは当然の義務である．そこで私は膨大な総合的・複合テストのプログラムを開発した．このプログラム群はメモリ管理だけではなく多くのモジュールをテストでき，たくさんのバグを検出した．このテストプログラムは評判になり，テストプログラムの集合が「Dr. Yoshizawa Job」と呼ばれるようになった．これを耳にした検査部は「Dr. Yoshizawa Job」を使用したいので貸して欲しいと申し込んできたので提供することにした．ピープルウエアなる本で述べられていたか定かではないが，もし学卒新入社員が10名配属になったと仮定して，あなたなら優秀な人材を設計部と検査部のどちらにどのように配属をしますか？という問題を提起していたように思う．一般的には設計は製品開発の要所であるので一番優秀な人材を投入するのが常識的と思われる．誤解を生むのは承知での発言となるが，ソフトウェア工場においてはそれが顕著であった．しかし，製品のテストという仕事は地味ではあるがかなり創造的な仕事であるということがテストプログラムの作成で痛感した．極めて多くのテストプログラムをこの時に作成したが，自分達の開発したＯＳをどうすれば強固にできるのかを徹底的に考えた．テストプログラムは通常はユーザプログラムとして動作するが，VOS3には特権状態に出入りできる隠しSVCがあり，これを使うと強力なテストが実行出来る．コンピュータが壊れるのではないかと云うぐらいの覚悟でテストプログラムを作ったのである．
蛇足だが（中研）入社後１年ぐらい経た時に，堤正義主任研究員から「吉澤を見込んで，メモリ（当時はHITAC 5020のコアメモリ）テストのプログラムを作ってくれないか？」と依頼されたことがあった．そのときは，単に，堤さんから言われたメモリパターンを指定の番地に書込み，それらを指定された回数だけ繰り返し連続領域に（おそらくメモリバンク毎に）書込み，読出しするだけであり自分の創造性はなかった．しかし，これでメモリの不具合を発見できたと感謝されたことがあった．このケースでは堤さんの創造性が優れていたのであり，当時の私は単なるプログラマであった．
最後の最後までテストプログラムの作成は続いた．この結果，メモリ管理以外にも多数のバグを発見でき品質向上に寄与できたと思っている．本来の趣旨であるメモリ管理の品質も抜本的に向上した．ソフトウェア工場ではVOS3/ES1の拡張メモリの実現よりも，このテストプログラムの方がより価値が高いなどと冗談を云う人がいた．これこそ，社長ソフト賞に値するとまじめに云う人もいたぐらいである．設計部は今までPCL消化のための単体テストプログラムだけを作り，version upの際にそれらを再利用するだけであった．私のように，総合的なテストプログラムをシステマティックに開発してこなかったのである．
＜先頭へ＞
＜ページの最後へ＞
話を元に戻す．ＯＳでのバグ解決でどのような部分が難しいのかを説明する．上記にメモリダンプの解析などで触れたように，ＯＳのデバッグでは制御情報のデータ構造（これを制御テーブルと呼ぶことが多い）の整合性をチェックすることに主眼がある．つまりデータ構造の各要素；状態変数，カウンタ値，アドレス（ポインタとも云う）表示，などの正しさが問題となる．つまりバグの多くは，これらのデータ構造の要素が「何者か」によって不当に書き換えられているときに矛盾が生じることで誤動作に繋がりシステムダウンとなる可能性がある．「何者か」と云う点が問題である．
一般的に：
「プログラム」＝「手続き:procedure」＋「データ構造:data structure」
と云われるように手続きはデータ構造の内容にもとづいて，あるいは処理結果をデータ構造内に記録し処理を完了するため，何者かがデータ構造を不当に操作したならば，このプログラムは誤動作を免れない．ところが，やっかいなことにこの「何者か」は決して「私がその犯人です」とは自首しないのである．自首する場合もあるが，めったに無い．その理由はＯＳがCPUの特権状態というメモリ保護の対象外で動作しており不当な書込みをしてもハードウェア的な記憶保護機構には引っかからない．つまり最も権限の強いモード（特権状態という）で命令実行しているためである．プログラムではレジスタ内の情報を一時的にメモリに書込み，その後，その値をレジスタに回復して処理を続けるることがある．このような時，誤った領域に対する書込みは「何者」にとっては正常な処理となる．しかし，書き込まれたデータ構造に基づき処理をしている手続きは誤動作をする可能性が高く，これが直接，もしくは間接的な原因でシステムクラッシュに至ることがある．
このような不当書込みをされて誤動作したプログラムのデバッグはとても厄介である．このバグの解決は被害者たるプログラマが証拠と犯人である「何者か」を共に特定し，かつ相手に承認させねばならないというルールになっている．この種のバグは検査工程が進むに連れて多くなりバグ潰しを困難なものにしている．初期の段階では軽微なバグが多いので，「それじゃ，昼のウドンをおごるから勘弁して！」で済むが，だんだん工程が進み，バグが深刻な影響を与えるようになってくると，自分が犯人であることを正直に言えなくなってくる．これが大きな問題点である．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題）
IBM System/370では主記憶の０ページ，つまり0から4095番地までの領域をプリフェックス領域(prefix area)と呼んでいる．この部分はハードウェアと密接な関係がある情報が格納されている重要な部分がある．ある機種以降のバージョンからこの領域にはたとえ特権状態であっても書込み禁止にする機能となった．日立のマシンも同様の機能を備えたところ，VOS3がシステムダウンを多発するようになった．理由は簡単である．IBM System/360以降のアーキテクチャでは，アドレッシング（メモリの番地付け方法）における実効アドレス(effective address)の計算は以下のようになっている．
（実効アドレス）＝（基底アドレス）＋（インデックス）＋（変位） である．
ここで（基底アドレス）はベースレジスタで指定する．また（インデックス）はインデックスレジスタの値である．そして最後の（変位）は命令オペランド内の12ビットである．各命令のベースレジスタやインデックスレジスタの指定はプログラマにより行われる．このことから，実効アドレスを求める際に，ベースレジスタとインデックスレジスタの指定を忘れるようなことをすると（変位）のみの値が（実効アドレス）となることがある．その結果，0〜4095番地を示すことになる．この事実から不当な書込みをしても今まではシステムダウンにならないケースが多くあったことを意味している．おそらく，IBMはこのようなアドレッシングエラーによるバグを解決する手段として０ページのメモリ保護機構を新たに作ったのではないだろうか．
＜先頭へ＞
＜ページの最後へ＞
（５）どのようにデバッグするのか
メモリダンプにはシステムダウン時のPSW(Program Status Word：（注）を参照）,汎用レジスタ値，制御レジスタ値，などの情報がある．デバッグ作業はまずこの情報の分析から始める．どこの番地で何が起きたのか，レジスタの内容から処理の過程をおおまかに把握する．そして16個のレジスタ値を詳細に眺め，不審な値を含んだレジスタは無いか，などを注意深く観察する．VOS3ではシステム全体としてレジスタの使用方法には一定の決まりがある．この決まりはすべてのコンパイラの作るオブジェクトプログラムに共通している．これはプログラム間の相互の約束のためである．ちなみに，GR1はパラメータ（引数）領域を示し，GR13はレジスタの退避領域を，GR14はサブルーチンの帰りアドレス，GR15はサブルーチンのアドレスである．ここでGRはGeneral Register（汎用レジスタ）でありGR0からGR15まで16個ある．このような規則をリンケージコンベンション(linkage convention)と云う
（注）
PSW: CPUの状態を示すフラグ類と次に実行すべき命令アドレスを示す８バイト情報．
また，ＯＳは重要なイベント（事象）情報を特定の領域に記録しておりシステムダウン寸前にどのようなイベントがあったのかを知ることができる．イベントには割込み（入出力，タイマ，スーパーバイザ命令実行，ディスパッチ，など）の情報が記録されていて，各プロセスが実行してきた経過を知ることができる．ただしイベント情報は領域の関係からラップアラウンドで記録されているので，それほど長い時間帯をカバーできるわけではない．最近の自動車にはドライブレコーダーが装備できるが，この機能はまさに事故発生時の事象を記録するものであり，ＯＳのこの機能に類似している．
＜先頭へ＞
＜ページの最後へ＞
肝心の不当書込みであるが，まずはシステムが誤動作した原因となる不当書込みの領域を特定する．特定できたならばその部分がバイト単位（つまり８ビットだけ）なのか，２バイトか４バイトかの区別をする．稀に８バイトやそれ以外の長さであることもある．その後，不当書込みで壊されたと思われる部分のビットパターンを注意深く観察する．例えば，フラグ操作の類の場合は１ビットあるいは数ビットだけが変更されていることが多い．そのビットポジションが判明すれば操作するモジュールを推測する．またバイト単位の操作であるならば文字を書き込んだのか？それともカウンタ値のようなものかなどの判断をする．カウンタとして使用したようであればそのようなモジュールを調べる．文字についても同じである．４バイト長の書込みの場合もカウンタ値のように+1や-1されたものか，それとも，メモリのアドレスのような値であるか，などを観察する．メモリアドレスと思われる場合はそのアドレスには何が入っているのか，該当領域はどのモジュールの管理領域なのか，などを調べる．多くは制御情報のデータ構造が入っている領域であることが多いので「何者」を特定することが可能となる．
いろいろな思考を重ねて「何者か」のあたりをつける．その後，「何者か」のプログラムソースコードを調査して，先に述べたアドレッシング際に使う「変位」の値から，その変数名をアクセスしている手続き部分をすべて調べる．このために，変数を参照しているモジュール名とそのソースコード番号のすべてが分かるクロスリファレンスリストがあった．分厚いリストをひっくり返して調べるのが大変な作業だった．UNIXではこれがいとも簡単に出来ること後にを知った．こうやって，犯人らしき「何者か」を特定していくのである．特定できれば不当書込みの行為をしている現場を押さえるために，メモリにパッチを当て，被害を受けた制御情報のデータ構造のアドレスであることを確認し，犯行現場を押さえる．多くの場合はメモリダンプを出して処理を終了させる．このようにして証拠を揃え，犯人である相手方に証拠を揃え，そのバグの指摘が正しいことを認めさせる．このように一件ずつの不当書込みバグを潰していくのである．
＜先頭へ＞
＜ページの最後へ＞
（６）罠パッチの領域
上記のようにメモリへのパッチはデバッグに良く利用される手法である．ソースコードを書き換えるような修正を加える方法でのデバッグ方法は，そのバグが解決した時にパッチを取り除き元に戻す必要がある．ソースコードはある意味で神聖な製品であるので余計な手を加えない方が良い．そこでロードモジュールにバイナリイメージを書き込む方法がパッチである．いわゆる temporary fixである．
デバッグを容易にするにはパッチは必要悪である．パッチはそのプログラムが実行されたときに問題となっている変数のチェックをしたり，その時のレジスタの値を調べたりする小さなプログラムを実行させるために使う．あるいは，制御の流れを変更することで仮想的な条件下のテストを行うことなどが可能になる．このためは各モジュールにパッチによる処理を可能にするだけのプログラム領域が必要となる．そこでプログラマは密かに各モジュールにパッチ領域をある程度設けておき，チェックなどしたいところに無条件分岐命令をパッチしパッチ領域でチェックの動作を行う．これらの領域は本来の製品には無駄なメモリ領域となるため作ることは禁止されているがデバッグの効率化のためには必要悪として作っていた．もちろん，最終のソースコード提出版にはこれらの領域は取り除いてある．パッチを当てる時は，モジュール名はEBCIDIKであるが，メモリアドレス，書き込む値，などはすべて16進数で表示しなければならない．つまり書き込む値の多くは命令語であり，そこではレジスタ，ベースレジスタ，インデックスレジスタ，そして変位（displacement）などを正しく指定しなければならない．
＜先頭へ＞
＜ページの最後へ＞
（７）なぜソフトウェアにはバグがあるのか
ソフトウェアの開発の大部分の時間は品質向上，つまりデバッグ作業の時間である．プログラマは大半の時間をプログラミングに費やしているのではなく，自分で作った誤りの修正に終始しているということである．どうしてこのようにデバッグに長時間を費やすのか一般人には理解されない．プログラマは頭脳が劣っているからだろうか．これも一般的にはそのように解釈はされていない．プログラマは頭脳が少し優秀であるというのが一般的な考えではないだろうか．我々の世代では知能検査に似たプログラマ適性試験のようなものがあったように思える．当時のコンピュータは極めて高価であり頭の回転が良くないと，また数字を瞬時に覚えるなどの能力，数字を見て類推する能力などが必要だったためであろう．
いろいろな議論がなされてきた．今のようにソフトウェアの価値が高くなる前はデバッグ作業に多くの時間を割くことに理解はされていなかった．これは人からに聞いた話であるが，NECの小林社長が新装となった府中のソフトウェア開発現場を訪れた際に，責任者に対して「あのパーティションに入ってブラウン管の画面をずっと眺めている多くの人達は一体何をしているのかね？」と尋ねたところ，「あれはプログラムのデバッグをしているのです」と答えたという．そこで社長は「デバッグとは何だね？」と聞くと「プログラムの誤りを修正しているのです」と．すると小林社長は「プログラマは自分で作ったミスを修正するために長時間仕事を続けるとは何事だ！」と怒ったと聞いたことがある．確かに小林社長のいうことは常識的で正しいように思う．
一方，ハードウェアの場合はデバッグに長時間をとられるのだろうか？彼らに聞くとソフトウェアほど長くは無いとのこと．その理由は論理（ロジック）がソフトウェアに比べると浅いとい言うのである．確かにソフトウェアの場合は単純なコンピュータの命令を数千，数万，いやそれ以上に長く続けて一つの仕事（機能）を達成している．例えば，磁気ディスクからデータを読み込むためには，現代のＯＳでは数千から数万の命令を誤りなく実行しなくてはならない．しかも入出力の場合は機械的な動作があるために，CPUの命令実行とは非同期な割込みを使った処理が一般的である．この長い命令列の中で一つでも誤りがあってはならないのである．さらに，この長い命令実行列（プロセスと呼ぶ）とは別の処理（プロセス）も並列に実行されるため複雑な動きになる．つまりハードウェアと異なりプロセスの実行過程が長い命令実行列になっており，加減乗除命令というより比較，判断などの論理的な処理が多く論理が深いのである．このように論理が深いため機能分割してプログラムを作成する．そうすると相互のモジュールの間にはインターフェースを明確にしておく必要がある．このような開発をせざるを得ないので，ソフトウェアではインターフェースを相互に守ることが重要になる．
重要なのはプログラム間のインターフェースであるがここに落とし穴がある．具体的なインターフェースはパラメータでありモジュール間の約束で相互に引き渡される．つまりインプットとアウトプットである．ところが多くのプログラマは受取ったパラメータ値が正しいと見做して処理を進める．パラメータの各々の正当性をチェックするとプログラムの量が増えてしまうため一般的にはチェックを行わない．仮に誤ったパラメータに基づき処理を進め，得られた結果を第３のモジュールに渡すとどうなるであろう．第３のモジュールも受取った値を正しいと信じて処理を進めた結果，不当な書込みを第４の管理する制御情報データ構造内に行うことがある．その結果，第４のモジュールが実行されると破綻する．ＯＳでは前に述べた通り特権状態でプログラムが実行されるために記憶保護は無効である．このように，プログラマとは不完全な人間が完全なるものを要求される製品を作らねばならないという矛盾のある職業なのである．先に述べた制御情報テーブルもモジュール間のインターフェイスである．この部分に第三者から不当な書込みがなされればインターフェイスは崩れてしまう．
＜先頭へ＞
＜ページの最後へ＞
（８）ソフトウェアの開発は鎖の強さと同じ
優秀な人材だけを集めて相互のコミュニケーションも円滑であり互いに協調しあうような職場は理想である．大規模なプログラムを大人数で開発する時代にあってこのような理想的な職場は実現不可能である．開発現場では多種雑多な人間集団であり（協力会社と呼んでいたが）下請け会社も入っていた．日本のソフトウェア産業の三重構造は大きな問題である．日立製作所の正社員は主に管理の仕事に従事し手を汚す実際の仕事は下請け会社，そのまたその下請け会社が行う仕組みになっている．我々研究所の人間も工場では手を汚す作業員であり，下請けに位置づけられていたのかも知れない．こうなると命令指揮権の問題が派遣法などの法的制約からあるため技術的指導などが間接的にしか行えない．
具体的には，協力会社に入社したばかりの高等専門学校卒の従業員がグループに配属されていた．協力会社のマネージャはこの人間にも製品の一部を担当させて欲しいと要求してくる．そうしないと協力会社の使命を果たせないためもある．それに派遣者の成長も期待できないためであろう．私にとってこれはあまりにも無謀と思えた．日立側の部課長も協力会社との関係を良くしておきたいので，私に我慢するよう協力を要請してくる．だが明らかにズブの素人でありＯＳの概念，プログラミングの基礎，その他ドキュメンテーション能力，などあらゆる点で製品に関与できる水準のスキルを身につけていない人間である．このような人間を今回のような緊急の状況下で投入すべきでは無いと思っていた．
案の定，このような人間に仕事を与えると何もしなくてよいにもかかわらず与えられたプログラムに手を加えるのである．これは明らかに破壊行為である．これがバグとして検査部から指摘される．この種の人間は自分で潜在的なバグなど発見できるはずがないので，この結果，例のペナルティNが課せられ我々がその尻拭いをしなくてはならないことになる．時間と費用の無駄である．そこでこのような事態が数回起きたので，私はその新人からプログラムに関する仕事をすべて取り上げてしまった．ソフトウェアの品質は鎖の強さと同じなのである．つまり一番強度の弱いところが製品の品質になってしまう．Brooksも同様のことをOS/360開発時に経験したことを著書の中で述べている．
プログラミングの仕事もいろいろある．職場の整理整頓，メモリダンプの整理やコンピュータ内のファイル管理，プログラムをコンパイルしたリストの収集（コンピュータセンターからプリントアウトされたリストを運搬する），自分たちの担当している部分の設計書を読んで理解するなどの勉強，そしてMシリーズコンピュータのアーキテクチャの勉強，等など．これらをこなしながら，門前の小僧習わぬ経を読むではないが，徐々に能力を高めていくべきだ．だが，私の取った行為に日立サイドの部課長は批判的であった．しかたなく修正や改良の必要のないモジュールを担当させ，勉強するだけの義務を与えた．この問題は民主的な運営がよいのか貴族主義がよいのか哲学の問題になる．
＜先頭へ＞
＜ページの最後へ＞
（９）過酷な検査部対応
大分横道にそれてしまった．本論に戻る．８月に入り本格的な検査に入った．検査部は設計部の要求通りには検査をしてくれない．前回の検査結果のバグを全部解決し，さらに課されたペナルティをすべて解消し，さらにどのような品質向上を行ったのかを説明する必要がある．次回の検査結果に対する見通しも宣言する必要がある．検査部は製品保証の責任者であって製品出荷期日の責任者ではない．製品出荷は企業の収益に関係しており設計部は全国の営業と検査部との間にあり常に苦しい立場である．このような役割分担であるので設計部が収益管理の中心（profit center）になっていた．したがって最も責任が重いのである．
検査部からのバグ指摘に対する対処は過酷であった．作業内容は先に述べた通りである．８月から工期完了までの勤務スタイルをここで説明しておく．戸塚と長後の中間地点の立場（たてば）に曙寮という独身寮がありここに単身赴任で住んでいた．寮では朝７時45分頃に起き朝食を摂る．８時過ぎに寮を出発し，ほとんど毎日歩いてソフトウェア工場に通っていた．工場の門近くにパン屋がありそこで昼食を買い職場に８時40分までに到着する．寮には月曜から金曜まで泊まり土曜は立川の自宅に帰るのが常であった．８月以降の勤務時間は月曜から金曜までは午前２時より前に退社したことはない．工場では毎日のように午後10時から部長席でその日の進捗状況報告，問題点の洗い出しと対策，責任者のアサイン，翌日行うべき重点作業の確認，などを１時間ほど行う．それから席に戻り部下に必要事項を報告し作業を継続する．午前２時ぐらいになるとタクシーを正門に呼び頃合いを見て帰り支度をする．タクシーで立場の交差点近くにある（ファミレスの）スカイラークまで乗りここで夕食を摂る．寮には午前３時前に帰り微温くなった風呂を浴びて二段ベッドで午前３時には寝るという生活を繰り返した．
土曜の休日は少し朝寝坊して寮でゆっくり朝食を摂り午前9時過ぎに工場に向かう．当時は形の上では管理職であったので土曜はその残務処理をすることにしていた．たくさんの回覧物に目を通したりIBMや業界の動向を把握したりした．また（シ研）の上司に報告書などを書き状況を知らせた．土曜は午後５時ぐらいに残務処理を終わらせ立川の自宅に帰った．日曜はほとんど身体を休めることにした．当時の唯一の楽しみは，役所広司が主演していた宮本武蔵の録画を見ることだった．吉川英治の作品を随分たくさん読んでいたのでこの番組がNHKで始まるということから，土曜のある日，秋葉原に途中下車し，日立製のVHSビデオデッキを18万円で買った覚えがある．当時はVHSビデオ（マスタックスだったか？）が出始めたばかりでも随分高かったが画質がそれほど良いとは思えなかった．そして月曜は朝５時に起きて午前６時１５分ぐらいには家を出て国立駅から東京駅で乗換え，戸塚駅まで行き，また深夜までの仕事を繰り返した．
管理職，つまり非組合員であったため残業代はゼロであった．部下は皆，残業代が本給よりも多いと給料日のたびに喜んでいたがこちらの収入は従来と全く同じであった．少し増えたのは単身赴任していたので別居手当だけであったが，寮費，毎週のように自宅に帰る交通費，そして食費などで消えていた．工場の人達もいつもの残業代よりもこの脱IBMのお陰で随分給料が増えたことを喜んでいた．収入という意味では管理職には恩恵がなかったのは事実である．こんな生活が1984年の年末ぎりぎりまで続いていた．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題）
ドキュメンテーションとプログラム書き
プログラムの天才と世間で言われる人物がいる．そのような多くのプログラマは確かにプログラムを他よりも早く作成することができる．この種の人間は私の廻りにも何人か居た．しかしこの種の人間はプログラムを書くだけの能力しか備わっていない傾向にある．企業でソフトウェアを作る上で重要なのは単なるプログラミング能力だけでは困るのである．必要なのはソフトウェア開発で必要となるドキュメンテーション能力である．つまり各種の設計書を作成する能力が不可欠となる．また一人で仕事をするようなことは少なくグループでの仕事となるため相互のコミュニケーション能力も必要である．
プログラミングにだけ特化したスキルがある人間はそれなりに貴重な人材であるが，これだけでは企業の技術者とはいえない．この種の人間は技能者あるいは技師(technician)であって，技術者(engineer)ではない．技術者は問題を発見して定式化し，その解決策を見出し，その効果を（できれば定量的に）予測しドキュメンテーションを整え，関連部署を説得し製品化に結びつけるという一連の仕事を成し遂げられねばならない．つまり創造性が求められる職業なのである．日本では技術者と技能者，工芸家(craftsman)を区別することなく「技術者」という言葉で括っているように思える．職業に貴賎はないというのは分かった上で言うのだが，指示されたプログラムだけを作る人間は技能工であり左官屋，タイル工，溶接工，などと同レベルである．このようなことは学生時代の社会学という永井道雄教授の講義で教えてもらった．その際，故永井教授は「諸君は税金で賄われている国立大学で教育を受けている．だから創造的なエンジニアとなり国家にお返しをしなくてはならない．決してテクニシャンになるな．」という意味のことをおしゃっていたことを覚えている．永井教授は1974年三木内閣の時に文部大臣に就任されたのを覚えている．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
検査初期の段階ではNの値は小さいが検査工程が進むに従いNの値は大きくなっていく．検査初期の段階は検査から指摘されるバグ件数が一般的に多いため，Nの数は小さくても潜在バグを見つけなければならない数も大きい．逆に，工程が進むにつれて検査部のバグ指摘件数は少なくなるが，Nが大きくなる．工程が進んでから指摘されるバグは原因究明に時間を要するようになる．また，プログラムの品質は徐々に高くなっていくため，ペナルティのNが大きくなると潜在バグを見つけづらい．この矛盾に工程完了まで設計部は悩まされるのである．この結果，検査部と設計部は検査のフェーズに入ると協力関係から敵同士のようにになってしまい，工場長臨席の御前会議の場において感情的になるぐらいの戦いをすることがある．板挟みになる工場長も大変な思いであったろう．
検査部の指摘は検査結果の簡単なメモしかない．どのような検査によりどのような症状でシステムダウンになったなど親切な説明は一般的にはない．システムがおかしくなった時点のメモリダンプ＊はファイル名：XXXである，というぐらいの情報しかもらえない．しかし，この検査結果に対する設計部の対応はきちんと行わねばならない．すべてバグ報告書として採番され責任者の押印をもらいドキュメントを残すことになっている．報告書にはバグの原因，対策，動作確認方法とその結果，ソースプログラムのPAD図（変更前後が対になったもの）などを作成する義務がある．
（注）メモリダンプ＊：
memory dump は主記憶の全体を2次記憶に格納したものである．コンピュータがシステムダウンしたときなどはメモリ内容をそのまま全部，磁気ディスクや磁気テープに吐き出しておく．つまりコンピュータのダイイングメッセージ(dying message)である．人間で例えるならば死体のようなものであり，これを詳細に調べることで死因を判定しなければならない．コンピュータの場合は，死因が分かれば死なないように処置をして少しずつ長寿命の身体を作っていける．
当時は検査によりシステムダウンとなると，検査部はメモリダンプを磁気テープ（多くは2400フィート）に格納し，テープに検査番号を書き所定の場所におくことになっている．軽微な障害の場合はシステムダウンとせずにＯＳ自身のメモリダンプとしてSVC（スーパーバイザコール）ダンプが同様に取られコンソールにその旨が印字される．検査部はSVCダンプ取得用に常時磁気テープをマウントしている．これらの情報も設計部には通知される．そこで，我々は検査部から知らされたこれらのダンプ情報を基にバグ解析を行い，上記の通りの作業を約４ヶ月間行ったのである．したがって毎日のようにメモリダンプを睨む生活が続いた．
31ビットアドレッシングにより仮想記憶領域の拡大と実記憶領域の拡大から従来以上にメモリダンプのサイズが巨大化した．膨大なメモリダンプの数をいかに短時間で解析するのかが問題であった．この長期派遣の前に私が提案し実現したＯＳ開発用生産治工具であるOSTD(Operating System Test Driver)は現場で大いに力を発揮したのである．（OSTDについては別のところで説明するつもりなので関心のある方は読んでいただきたい）
検査部から指摘のあったバグに対応するメモリダンプの磁気テープ内容をOSTDのマシンに備えられた磁気ディスクに格納し，TSS端末からOSTDの機能を立ち上げてダンプ解析が可能になったのである．OSTDのオペレータには磁気テープ内容をOSTDにコピーする依頼を出しておけばディスクに空きができた段階でコピーされ，その完了通知が来る．この通知がくるとTSS端末さえあればダンプ解析が可能となる．私は主任研究員（課長）の権限で研究所からB16というパソコンを手に入れ自分の席に設置した．このパソコンにはVOS3のTSS端末シミュレータというアプリケーションが載っていた．つまり，B16を使ってOSTDを使用できたのである．またワープロ機能もあり，検査部に提出すべきバグ対策用のドキュメントの作成が可能となっていた．これは大いに効率的であった．
OSTDではダンプ解析の自動化機能も可能になっていた．通常ダンプ解析にはVMコマンド（VMSという仮想計算機を実現する制御プログラムの実行コマンド）を逐次タイプインしながら作業を進めるのであるが，この一連のコマンドをコマンドプロセジャ（一連の手続き）としてファイルに登録しておけば自動的に一塊の作業が行えるのである．例えば，メモリ内のある番地からリスト形式になっている制御情報のテーブルをたどりながらその内容の正当性をチェックするような作業をコマンドの列としてコマンドプロセジャのファイルとしておける．この種のプロセジャを蓄積しておけばメモリダンプの解析・診断を自動化できるため解析の省力化が図れるのである．UNIXのシェルスクリプトと同一の機能である．これらの解析・診断結果を踏まえた上で次の解析作業が進められる．メモリ管理のメモリダンプをチェックする機能を蓄積して相互に利用することでさらにバグ解析が効率的になった．
蛇足だが（中研）入社後１年ぐらい経た時に，堤正義主任研究員から「吉澤を見込んで，メモリ（当時はHITAC 5020のコアメモリ）テストのプログラムを作ってくれないか？」と依頼されたことがあった．そのときは，単に，堤さんから言われたメモリパターンを指定の番地に書込み，それらを指定された回数だけ繰り返し連続領域に（おそらくメモリバンク毎に）書込み，読出しするだけであり自分の創造性はなかった．しかし，これでメモリの不具合を発見できたと感謝されたことがあった．このケースでは堤さんの創造性が優れていたのであり，当時の私は単なるプログラマであった．
最後の最後までテストプログラムの作成は続いた．この結果，メモリ管理以外にも多数のバグを発見でき品質向上に寄与できたと思っている．本来の趣旨であるメモリ管理の品質も抜本的に向上した．ソフトウェア工場ではVOS3/ES1の拡張メモリの実現よりも，このテストプログラムの方がより価値が高いなどと冗談を云う人がいた．これこそ，社長ソフト賞に値するとまじめに云う人もいたぐらいである．設計部は今までPCL消化のための単体テストプログラムだけを作り，version upの際にそれらを再利用するだけであった．私のように，総合的なテストプログラムをシステマティックに開発してこなかったのである．
話を元に戻す．ＯＳでのバグ解決でどのような部分が難しいのかを説明する．上記にメモリダンプの解析などで触れたように，ＯＳのデバッグでは制御情報のデータ構造（これを制御テーブルと呼ぶことが多い）の整合性をチェックすることに主眼がある．つまりデータ構造の各要素；状態変数，カウンタ値，アドレス（ポインタとも云う）表示，などの正しさが問題となる．つまりバグの多くは，これらのデータ構造の要素が「何者か」によって不当に書き換えられているときに矛盾が生じることで誤動作に繋がりシステムダウンとなる可能性がある．「何者か」と云う点が問題である．
一般的に：
「プログラム」＝「手続き:procedure」＋「データ構造:data structure」
と云われるように手続きはデータ構造の内容にもとづいて，あるいは処理結果をデータ構造内に記録し処理を完了するため，何者かがデータ構造を不当に操作したならば，このプログラムは誤動作を免れない．ところが，やっかいなことにこの「何者か」は決して「私がその犯人です」とは自首しないのである．自首する場合もあるが，めったに無い．その理由はＯＳがCPUの特権状態というメモリ保護の対象外で動作しており不当な書込みをしてもハードウェア的な記憶保護機構には引っかからない．つまり最も権限の強いモード（特権状態という）で命令実行しているためである．プログラムではレジスタ内の情報を一時的にメモリに書込み，その後，その値をレジスタに回復して処理を続けるることがある．このような時，誤った領域に対する書込みは「何者」にとっては正常な処理となる．しかし，書き込まれたデータ構造に基づき処理をしている手続きは誤動作をする可能性が高く，これが直接，もしくは間接的な原因でシステムクラッシュに至ることがある．
このような不当書込みをされて誤動作したプログラムのデバッグはとても厄介である．このバグの解決は被害者たるプログラマが証拠と犯人である「何者か」を共に特定し，かつ相手に承認させねばならないというルールになっている．この種のバグは検査工程が進むに連れて多くなりバグ潰しを困難なものにしている．初期の段階では軽微なバグが多いので，「それじゃ，昼のウドンをおごるから勘弁して！」で済むが，だんだん工程が進み，バグが深刻な影響を与えるようになってくると，自分が犯人であることを正直に言えなくなってくる．これが大きな問題点である．
IBM System/370では主記憶の０ページ，つまり0から4095番地までの領域をプリフェックス領域(prefix area)と呼んでいる．この部分はハードウェアと密接な関係がある情報が格納されている重要な部分がある．ある機種以降のバージョンからこの領域にはたとえ特権状態であっても書込み禁止にする機能となった．日立のマシンも同様の機能を備えたところ，VOS3がシステムダウンを多発するようになった．理由は簡単である．IBM System/360以降のアーキテクチャでは，アドレッシング（メモリの番地付け方法）における実効アドレス(effective address)の計算は以下のようになっている．
（実効アドレス）＝（基底アドレス）＋（インデックス）＋（変位） である．
ここで（基底アドレス）はベースレジスタで指定する．また（インデックス）はインデックスレジスタの値である．そして最後の（変位）は命令オペランド内の12ビットである．各命令のベースレジスタやインデックスレジスタの指定はプログラマにより行われる．このことから，実効アドレスを求める際に，ベースレジスタとインデックスレジスタの指定を忘れるようなことをすると（変位）のみの値が（実効アドレス）となることがある．その結果，0〜4095番地を示すことになる．この事実から不当な書込みをしても今まではシステムダウンにならないケースが多くあったことを意味している．おそらく，IBMはこのようなアドレッシングエラーによるバグを解決する手段として０ページのメモリ保護機構を新たに作ったのではないだろうか．
（５）どのようにデバッグするのか
（注）
PSW: CPUの状態を示すフラグ類と次に実行すべき命令アドレスを示す８バイト情報．
また，ＯＳは重要なイベント（事象）情報を特定の領域に記録しておりシステムダウン寸前にどのようなイベントがあったのかを知ることができる．イベントには割込み（入出力，タイマ，スーパーバイザ命令実行，ディスパッチ，など）の情報が記録されていて，各プロセスが実行してきた経過を知ることができる．ただしイベント情報は領域の関係からラップアラウンドで記録されているので，それほど長い時間帯をカバーできるわけではない．最近の自動車にはドライブレコーダーが装備できるが，この機能はまさに事故発生時の事象を記録するものであり，ＯＳのこの機能に類似している．
肝心の不当書込みであるが，まずはシステムが誤動作した原因となる不当書込みの領域を特定する．特定できたならばその部分がバイト単位（つまり８ビットだけ）なのか，２バイトか４バイトかの区別をする．稀に８バイトやそれ以外の長さであることもある．その後，不当書込みで壊されたと思われる部分のビットパターンを注意深く観察する．例えば，フラグ操作の類の場合は１ビットあるいは数ビットだけが変更されていることが多い．そのビットポジションが判明すれば操作するモジュールを推測する．またバイト単位の操作であるならば文字を書き込んだのか？それともカウンタ値のようなものかなどの判断をする．カウンタとして使用したようであればそのようなモジュールを調べる．文字についても同じである．４バイト長の書込みの場合もカウンタ値のように+1や-1されたものか，それとも，メモリのアドレスのような値であるか，などを観察する．メモリアドレスと思われる場合はそのアドレスには何が入っているのか，該当領域はどのモジュールの管理領域なのか，などを調べる．多くは制御情報のデータ構造が入っている領域であることが多いので「何者」を特定することが可能となる．
いろいろな思考を重ねて「何者か」のあたりをつける．その後，「何者か」のプログラムソースコードを調査して，先に述べたアドレッシング際に使う「変位」の値から，その変数名をアクセスしている手続き部分をすべて調べる．このために，変数を参照しているモジュール名とそのソースコード番号のすべてが分かるクロスリファレンスリストがあった．分厚いリストをひっくり返して調べるのが大変な作業だった．UNIXではこれがいとも簡単に出来ること後にを知った．こうやって，犯人らしき「何者か」を特定していくのである．特定できれば不当書込みの行為をしている現場を押さえるために，メモリにパッチを当て，被害を受けた制御情報のデータ構造のアドレスであることを確認し，犯行現場を押さえる．多くの場合はメモリダンプを出して処理を終了させる．このようにして証拠を揃え，犯人である相手方に証拠を揃え，そのバグの指摘が正しいことを認めさせる．このように一件ずつの不当書込みバグを潰していくのである．
デバッグを容易にするにはパッチは必要悪である．パッチはそのプログラムが実行されたときに問題となっている変数のチェックをしたり，その時のレジスタの値を調べたりする小さなプログラムを実行させるために使う．あるいは，制御の流れを変更することで仮想的な条件下のテストを行うことなどが可能になる．このためは各モジュールにパッチによる処理を可能にするだけのプログラム領域が必要となる．そこでプログラマは密かに各モジュールにパッチ領域をある程度設けておき，チェックなどしたいところに無条件分岐命令をパッチしパッチ領域でチェックの動作を行う．これらの領域は本来の製品には無駄なメモリ領域となるため作ることは禁止されているがデバッグの効率化のためには必要悪として作っていた．もちろん，最終のソースコード提出版にはこれらの領域は取り除いてある．パッチを当てる時は，モジュール名はEBCIDIKであるが，メモリアドレス，書き込む値，などはすべて16進数で表示しなければならない．つまり書き込む値の多くは命令語であり，そこではレジスタ，ベースレジスタ，インデックスレジスタ，そして変位（displacement）などを正しく指定しなければならない．
いろいろな議論がなされてきた．今のようにソフトウェアの価値が高くなる前はデバッグ作業に多くの時間を割くことに理解はされていなかった．これは人からに聞いた話であるが，NECの小林社長が新装となった府中のソフトウェア開発現場を訪れた際に，責任者に対して「あのパーティションに入ってブラウン管の画面をずっと眺めている多くの人達は一体何をしているのかね？」と尋ねたところ，「あれはプログラムのデバッグをしているのです」と答えたという．そこで社長は「デバッグとは何だね？」と聞くと「プログラムの誤りを修正しているのです」と．すると小林社長は「プログラマは自分で作ったミスを修正するために長時間仕事を続けるとは何事だ！」と怒ったと聞いたことがある．確かに小林社長のいうことは常識的で正しいように思う．
一方，ハードウェアの場合はデバッグに長時間をとられるのだろうか？彼らに聞くとソフトウェアほど長くは無いとのこと．その理由は論理（ロジック）がソフトウェアに比べると浅いとい言うのである．確かにソフトウェアの場合は単純なコンピュータの命令を数千，数万，いやそれ以上に長く続けて一つの仕事（機能）を達成している．例えば，磁気ディスクからデータを読み込むためには，現代のＯＳでは数千から数万の命令を誤りなく実行しなくてはならない．しかも入出力の場合は機械的な動作があるために，CPUの命令実行とは非同期な割込みを使った処理が一般的である．この長い命令列の中で一つでも誤りがあってはならないのである．さらに，この長い命令実行列（プロセスと呼ぶ）とは別の処理（プロセス）も並列に実行されるため複雑な動きになる．つまりハードウェアと異なりプロセスの実行過程が長い命令実行列になっており，加減乗除命令というより比較，判断などの論理的な処理が多く論理が深いのである．このように論理が深いため機能分割してプログラムを作成する．そうすると相互のモジュールの間にはインターフェースを明確にしておく必要がある．このような開発をせざるを得ないので，ソフトウェアではインターフェースを相互に守ることが重要になる．
重要なのはプログラム間のインターフェースであるがここに落とし穴がある．具体的なインターフェースはパラメータでありモジュール間の約束で相互に引き渡される．つまりインプットとアウトプットである．ところが多くのプログラマは受取ったパラメータ値が正しいと見做して処理を進める．パラメータの各々の正当性をチェックするとプログラムの量が増えてしまうため一般的にはチェックを行わない．仮に誤ったパラメータに基づき処理を進め，得られた結果を第３のモジュールに渡すとどうなるであろう．第３のモジュールも受取った値を正しいと信じて処理を進めた結果，不当な書込みを第４の管理する制御情報データ構造内に行うことがある．その結果，第４のモジュールが実行されると破綻する．ＯＳでは前に述べた通り特権状態でプログラムが実行されるために記憶保護は無効である．このように，プログラマとは不完全な人間が完全なるものを要求される製品を作らねばならないという矛盾のある職業なのである．先に述べた制御情報テーブルもモジュール間のインターフェイスである．この部分に第三者から不当な書込みがなされればインターフェイスは崩れてしまう．
具体的には，協力会社に入社したばかりの高等専門学校卒の従業員がグループに配属されていた．協力会社のマネージャはこの人間にも製品の一部を担当させて欲しいと要求してくる．そうしないと協力会社の使命を果たせないためもある．それに派遣者の成長も期待できないためであろう．私にとってこれはあまりにも無謀と思えた．日立側の部課長も協力会社との関係を良くしておきたいので，私に我慢するよう協力を要請してくる．だが明らかにズブの素人でありＯＳの概念，プログラミングの基礎，その他ドキュメンテーション能力，などあらゆる点で製品に関与できる水準のスキルを身につけていない人間である．このような人間を今回のような緊急の状況下で投入すべきでは無いと思っていた．
案の定，このような人間に仕事を与えると何もしなくてよいにもかかわらず与えられたプログラムに手を加えるのである．これは明らかに破壊行為である．これがバグとして検査部から指摘される．この種の人間は自分で潜在的なバグなど発見できるはずがないので，この結果，例のペナルティNが課せられ我々がその尻拭いをしなくてはならないことになる．時間と費用の無駄である．そこでこのような事態が数回起きたので，私はその新人からプログラムに関する仕事をすべて取り上げてしまった．ソフトウェアの品質は鎖の強さと同じなのである．つまり一番強度の弱いところが製品の品質になってしまう．Brooksも同様のことをOS/360開発時に経験したことを著書の中で述べている．
プログラミングの仕事もいろいろある．職場の整理整頓，メモリダンプの整理やコンピュータ内のファイル管理，プログラムをコンパイルしたリストの収集（コンピュータセンターからプリントアウトされたリストを運搬する），自分たちの担当している部分の設計書を読んで理解するなどの勉強，そしてMシリーズコンピュータのアーキテクチャの勉強，等など．これらをこなしながら，門前の小僧習わぬ経を読むではないが，徐々に能力を高めていくべきだ．だが，私の取った行為に日立サイドの部課長は批判的であった．しかたなく修正や改良の必要のないモジュールを担当させ，勉強するだけの義務を与えた．この問題は民主的な運営がよいのか貴族主義がよいのか哲学の問題になる．
検査部からのバグ指摘に対する対処は過酷であった．作業内容は先に述べた通りである．８月から工期完了までの勤務スタイルをここで説明しておく．戸塚と長後の中間地点の立場（たてば）に曙寮という独身寮がありここに単身赴任で住んでいた．寮では朝７時45分頃に起き朝食を摂る．８時過ぎに寮を出発し，ほとんど毎日歩いてソフトウェア工場に通っていた．工場の門近くにパン屋がありそこで昼食を買い職場に８時40分までに到着する．寮には月曜から金曜まで泊まり土曜は立川の自宅に帰るのが常であった．８月以降の勤務時間は月曜から金曜までは午前２時より前に退社したことはない．工場では毎日のように午後10時から部長席でその日の進捗状況報告，問題点の洗い出しと対策，責任者のアサイン，翌日行うべき重点作業の確認，などを１時間ほど行う．それから席に戻り部下に必要事項を報告し作業を継続する．午前２時ぐらいになるとタクシーを正門に呼び頃合いを見て帰り支度をする．タクシーで立場の交差点近くにある（ファミレスの）スカイラークまで乗りここで夕食を摂る．寮には午前３時前に帰り微温くなった風呂を浴びて二段ベッドで午前３時には寝るという生活を繰り返した．
土曜の休日は少し朝寝坊して寮でゆっくり朝食を摂り午前9時過ぎに工場に向かう．当時は形の上では管理職であったので土曜はその残務処理をすることにしていた．たくさんの回覧物に目を通したりIBMや業界の動向を把握したりした．また（シ研）の上司に報告書などを書き状況を知らせた．土曜は午後５時ぐらいに残務処理を終わらせ立川の自宅に帰った．日曜はほとんど身体を休めることにした．当時の唯一の楽しみは，役所広司が主演していた宮本武蔵の録画を見ることだった．吉川英治の作品を随分たくさん読んでいたのでこの番組がNHKで始まるということから，土曜のある日，秋葉原に途中下車し，日立製のVHSビデオデッキを18万円で買った覚えがある．当時はVHSビデオ（マスタックスだったか？）が出始めたばかりでも随分高かったが画質がそれほど良いとは思えなかった．そして月曜は朝５時に起きて午前６時１５分ぐらいには家を出て国立駅から東京駅で乗換え，戸塚駅まで行き，また深夜までの仕事を繰り返した．
管理職，つまり非組合員であったため残業代はゼロであった．部下は皆，残業代が本給よりも多いと給料日のたびに喜んでいたがこちらの収入は従来と全く同じであった．少し増えたのは単身赴任していたので別居手当だけであったが，寮費，毎週のように自宅に帰る交通費，そして食費などで消えていた．工場の人達もいつもの残業代よりもこの脱IBMのお陰で随分給料が増えたことを喜んでいた．収入という意味では管理職には恩恵がなかったのは事実である．こんな生活が1984年の年末ぎりぎりまで続いていた．
プログラミングにだけ特化したスキルがある人間はそれなりに貴重な人材であるが，これだけでは企業の技術者とはいえない．この種の人間は技能者あるいは技師(technician)であって，技術者(engineer)ではない．技術者は問題を発見して定式化し，その解決策を見出し，その効果を（できれば定量的に）予測しドキュメンテーションを整え，関連部署を説得し製品化に結びつけるという一連の仕事を成し遂げられねばならない．つまり創造性が求められる職業なのである．日本では技術者と技能者，工芸家(craftsman)を区別することなく「技術者」という言葉で括っているように思える．職業に貴賎はないというのは分かった上で言うのだが，指示されたプログラムだけを作る人間は技能工であり左官屋，タイル工，溶接工，などと同レベルである．このようなことは学生時代の社会学という永井道雄教授の講義で教えてもらった．その際，故永井教授は「諸君は税金で賄われている国立大学で教育を受けている．だから創造的なエンジニアとなり国家にお返しをしなくてはならない．決してテクニシャンになるな．」という意味のことをおしゃっていたことを覚えている．永井教授は1974年三木内閣の時に文部大臣に就任されたのを覚えている．