5.1 設計から単体テストまで
（１）各種の設計書作成
（２）コーディング
（３）NIP疎通テスト
（４）単体テスト
（５）不破工場長の激励
（２）コーディング
（３）NIP疎通テスト
（４）単体テスト
（５）不破工場長の激励
（１）各種の設計書作成
製品開発には各種の設計書を作成する必要がある．工場にはドキュメント作成の規則が定められており各設計書ごとにその詳細なルールが定められている．何をどの部分に記述すべきかを標準として定めているため設計書作成ではこのルールにしたがって書けば良い．その意味ではノウハウの蓄積がなされているわけである．
プログラムの解析が進むにつれ，徐々に概念設計書から書き始めた．当時はワープロやPCを使うことはなかったため，すべてを手書きで行った．この意味では現在のようにPCが普及している時代のドキュメント作成は飛躍的に効率的になったと言える．特に，修正・加筆，そして図の作成などはPCが有効である．
ソフトウェア開発は最終的にはプログラムに帰着するがそれはソフトウェア製品の一部にすぎない．Public DomainのMVSソースコード（プログラム）は水面上に出ている氷山の一角に似ている．水面上の氷山も重要であるが，水面下にある氷山の部分がより重要であり，その製品の考え（設計思想），機能分割，機能実現の各プログラムモジュールの機能とプログラム間のインターフェース，制御情報のデータ構造，各モジュールの動作確認方法とテストプログラムの仕様，コンビネーションテストの方法，などが水面下にあるノウハウである．したがって他社が開発した水面上の製品を入手しても，製品の10％程度の情報であり，その製品を顧客に継続的に提供していくには絶対に水面下の部分を準備しておく必要がある．我々がソースコードから処理のロジックをPADなどで書いたが，これも水面下にある重要なドキュメントなのである．つまり，我々は水面上の氷山部分から水面下の90％の部分を想像を交えて作り上げる作業を強いられたのである．
＜先頭へ＞ ＜ページの最後へ＞
幸いなことにMVSのプログラムモジュールからは基本的なモジュール構造やモジュール間インターフェースがそのまま利用したほうが良いことが分かった．IBMのソースコードは実に良く書かれているし，またコメントの英語表現も的確であった．中には，プログラマとその上司の名前が入っている部分もあった．31ビット拡張のための概念設計（基本的な考え方）とそのために必要な新モジュールの設計，従来の制御情報を含むデータ構造の再設計などが必要であることが分かった．これらを概念設計書，機能設計書，構造設計書，詳細設計書，テスト仕様書，などに書き1984年１月末までにVersion 1として完成した．これらは設計部内でレビューし修正を加えて検査部のチェックを受けることになった．ひとまず工程遅延なく使命を果たすことができた．その後，多少の指摘事項はあったが適宜対応し検査合格となる．
話は逸れるが，プログラムを調査中に日立SKの人から「吉澤課長，このコメントは一体どんな意味なのでしょうか？」と聞かれたことがあった．見るとそこには「この部分はコンピュータアーキテクチャを理解していない人間は手を加えてはならない」と書かれていた．よく見ると，そのプログラムはページ(4KB)内をゼロクリアする処理をしていた．この処理のプログラム部分はバウンダリ調整がされていて，そこには，MVC(move character)命令が16個並べてある．MVC命令は6バイト長であるので96バイトを占めている．前後の処理もあるが，これらの処理プログラムがキャシュメモリの１ラインに収まるようにバウンダリ調整されているのである．つまり，ページクリア操作中にはキャシュミスを起こさないようにプログラムされていたのである．これを日立SKの人には説明し，納得して貰った．ＯＳやコンパイラのプログラマにはこの程度のコンピュータに関する教養が必要なのであるが，果たして，現在のコンピュータ技術者と言われる人はどの程度コンピュータに関する教養を身につけているだろうか？大学の教員になってからインテルのアーキテクチャ(AI-32)を使い計算機械という講義・演習を担当した．しかし現在殆どのPCに採用され使用されているこのアーキテクチャを情報系の学科を卒業した者が理解しているか甚だ疑問である．現在はAI-64が主流かもしれない・・・
＜先頭へ＞ ＜ページの最後へ＞
（２）コーディング
一般的にソフトウェア工場ではシステムプログラムの平均的なプログラム生産量（製品として書き上げるプログラムステートメント数）は一人あたり年間500ステップとされていた．アバウトであるが年収を500万円とすれば￥10,000/ステップである．従業員には現金支払以外に社会福祉・社員福祉，建家や水光熱費，管理費用，などが加算されるので，支払う給与と同等以上の費用がかかるとされている．このことから，当時はシステムプログラムの値段は￥15,000/ステップ以上と言われていた．このような分析はIBMがOS/360を開発した際の経験談を著した「ソフトウェア開発の神話：THE MYTHICAL MAN-MONTH: Essays on Software Engineering」の中に紹介されている．そこではＯＳの場合は一人・年間600-800ステップでありＯＳの開発は難易度が高く，一方，言語処理プログラムでは2,200ステップと書かれている．もちろんこの数字は単にプログラムを書く時間だけではなく，設計などのドキュメンテーション，コード化，テスト，デバッグ，などの時間も含まれている．この本はIBMのFrederick Brooksが1975年に出版したものでソフトウェア工学のバイブル的な教科書になっている．
我々のグループはその平均の数倍の働きをし，研究所で私が鍛えた人材の質の高さを示すことができたと思っている．話を元に戻す．設計が済み1984年2月からはコーディングをする段階に入った．ここでも問題はテキスト編集をするTSS端末数の制約にあった．システムプログラム部が一斉にプログラミングのフェーズに入ったため端末数が圧倒的に不足していた．我々の担当した部分はVOS3/ES1の最も重要な機能であるのであるが，コンピュータを使用する段階では全プログラマは端末の前には平等なのである．コーディングの量が平均以上であるためTSS端末を我々のグループ専用に割当てて欲しいのが本音であった．
実はこの開発当初に神奈川工場長がソフトウェア工場を訪れた際に，私の職場にわざわざ挨拶のため足を運んでくれた．その時，「吉澤君．頑張ってくれよ．もしマシンが不足するならいつでも私に言って欲しい．マシン不足など絶対にさせないから．」と言ってくれたのである．マネージャとしてはこのぐらいのことしか言えないのは理解していたが，TSS端末やマシン時間で優遇されることは決してなかった．工場では特定の人間を優遇するような不公平をするとモラルの低下に繋がるためであろう．しかし，端末が無くて作業が遅れるのは大きな問題である．そこで，システム開発研究所のTSS端末状況を調べると十分な量があり，４台ぐらいはいつでも利用可能であることが分かった．
本当は，工場外に持ち出し禁止となっているソースコードであるが，自己責任でこれを持ち出して（シ研）に一時的に戻り日夜プログラミングを行った．このお陰で無事にプログラミング作業を期日前に終了させることができた．プログラムの入力が済めば次はコンパイルである．これは（ソフト）に戻ってやる以外に無いがプログラム入力や修正に比べると端末使用時間は短くて済む．コンパイルするとコーディングの文法的誤りが出てくる．コンパイルによる文法エラー（フラグ）を取り去ると，それ以降のすべてをバグ・修正として記録を残す．モジュールごとにすべての修正の記録を書くことになっていた．このような管理を行うことで各プログラムの品質管理がなされる．マシン使用によるバグ取りの方法もあるが，そのようなバグ取りは極力避けねばならない．私は入社当時，マシンデバッグではなく机上デバッグを徹底的にやるように上司に仕込まれていた．現代はコンピュータが豊富に用意されているためか，机上デバッグせずにマシンデバッグに頼りすぎているように思えるが，悪い習慣になっていなければ良いか心配する．
＜先頭へ＞
＜ページの最後へ＞
（３）NIP疎通テスト
コンパイルしロードモジュールがリンケージエディタにより作られると，いよいよすべてのモジュールを一つのプログラムとしてまとめるシステムジェネレーションの作業に入る．ここで時折問題になるのはモジュール提出忘れである．担当しているプログラムを決められた通りに提出していないミスである．提出はシスジェン（System Generationの略）の係りが行う．システムジェネレーションの作業はシスジェン係りの仕事である．ここでも提出したモジュールにコンパイルエラーが出るなどのトラブルが発生すると大いに怒鳴られる．よくある誤りはマクロライブラリの指定誤りである．シスジェンは時間のかかる大きな仕事である．SEはシスジェンを顧客サイトで行うので，その経験がないと一人前ではないと言われていた．
こうして1984年4月に入ってVOS3/ES1がその形を見せた．だがバグの山である． 最初の難関はNIP(Nucleus Initialization Program)であった．NIPはコンピュータに電源を入れると指定した外部記憶（多くはＯＳをインストールした磁気ディスク）からＯＳを主記憶に読取るハードウェア機構(IPL*: Initial Program Loading)の延長上で動作するプログラムである．NIPの処理により無機質なコンピュータに命を吹き込み，まるで生き物のように動き出させるのである．電源を投入してからNIPの完了までをブートストラッピング(bootstrapping)と云う．丁度，編上靴を徐々に組み上げて行く過程に似ているので付けられたのであろう，コンピュータ用語はほとんど全てがアメリカ人の英造語である．ハードウェアに備わった基本的な動作の詳細を（注）で説明しているので興味あれば読んで欲しい．
（注）IPL*のハードウェア動作は次の通りである．
①オペレータはローディングすべき装置アドレスを操作パネル（当時はサービスプロセッサ）で指定する．多くは磁気ディスクのチャネル・装置番号を16進数で入力する．一般的に磁気ディスクからブートするので，これをブートディスク:Boot Diskと云う．
②LOADを指定する．
この２つの操作によりIPL機構が指定された周辺装置から主記憶上にデータを読込み，その後ある特定の処理を実行する．それらは以下の通りである．
(a) IPLとして指定された装置の最初のレコードから24バイトを読取り，主記憶の0番地からロードする．0-23番地までデータが入る．
(b) 主記憶に読込んだ第8番地から８バイトをCCW(Channel Control Program)として実行する．チャネルもコンピュータでありstored program方式である．CCWはそのプログラムコードである．（これをCCW1とする）
(c) CCW1をチャネルが実行すると，次の８バイト目を次に実行すべきCCWとして実行する．（これをCCW2とする）このため，通常CCW1はチャネルプログラム完了のフラグ（コマンドチェインフラグ）をオフとしてCCW2を実行させるようにしておく．そして，CCW2はチャネルプログラム完了フラグをオンとする．
(d) チャネルプログラムが完了すると操作パネルで設定したチャネル・装置番号が主記憶の2-3番地にセットされる．さらに0-7番地の内容が現PSW(current PSW: Program Status Word)になる．つまり，主記憶の4-7番地に格納された番地に分岐命令が実行されることになる．この番地がNIPというプログラムの先頭アドレスであるのでこのような動きを知った上でIPLレコードの24バイトを作成してブートディスクに書き込んでおく．
＜先頭へ＞
＜ページの最後へ＞
NIPが動かない限りＯＳのみならず全てのテスト・デバッグは不可能である．つまり，すべてのＯＳコンポーネントの単体テスト・デバッグも不可能だ．ただNIPの過程では多くのＯＳコンポーネントが初期設定として動くのでNIPの担当者はNIPの動きがどこまで来たかを常時監視し，障害が起きた時にはすみやかに担当グループに連絡を取り対応してもらう方法を取っていた．大きな模造紙にこの流れが一目瞭然で分かるようにされ，通過した日時が書き込まれていった．これを疎通テストというが，疎通テストは拡張アドレッシングを持つマシンが大森別館（コンピュータ事業部の本拠地）にあり，そこまで毎日通う必要があった．大森別館には仮眠所があり徹夜勤務のような変則勤務体制が可能になっていた．
このNIPの疎通は1984年３月中旬から開始された．担当者は大学卒の中堅どころ(Mr.O)であった．しかしNIPを完全に理解しているとは思われなかった．仕方がない．皆，素人なのである．特に，今回の31ビット拡張アドレッシングについては勉強不足の感が否めなかった．我々の設計した内容を説明する機会が無かったのも問題であった．NIPの進行が遅延していることが明らかになり，急遽，手助けすることとなった．メモリ管理の方式や仮想記憶の仕組みなどを中心に説明し理解して貰った．
我々はNIPが躓いている間に机上デバッグを徹底的に行なった．そしてやっとメモリ管理にNIPが差し掛かるとの連絡が入り，大森に出掛けてメモリ管理部の疎通テストを行った．この時はいささか緊張した．プログラマは自分のプログラムが最初に動くとき不安を抱くはずである．我々は工場での初めてのプログラム開発体験であり，研究所から派遣されているという緊張もあった．いろいろな疎通テストの方法がある．もっとも簡単なのは一気に止まる所まで動かして見る方法である．バグがなく，うまくいけば通り抜けるはずである．つまり，何もしないという方法で，止まった時点で情報を収集して後に分析する．だが初めてのＯＳ開発でこの方法を取ると分析の手がかりを見つけるにも相当の時間がかかる．
もう一つの疎通テストの方法は，サービスプロセッサのアドレスストップ機能を使う方法である．CPUが指定されたメモリ番地を参照した際にコンピュータを停止する機能である．この疎通テスト方法ではテストするプログラムの先頭番地をストップアドレスとして指定しておき，CPUが命令フェッチ（Fetch: 読み出す）したときに停止するようにする．その後，要所要所を指定してアドレスストップをかけCPUが命令をフェッチしようとした時にを停止させ，場合によってはこの間に行った処理内容をサービスプロセッサで確認しながらメモリ内容を確認していく方式である．しかし，あまり細かな処理内容を確認していると与えられたマシン時間がなくなるので他に迷惑がかかる．一般的にはメインプログラムがサブルーチン（関数とも云う）を呼び出す寸前で止め，次に，サブルーチンからリターンして来たところで再度止める，という操作を繰り返す．リターンしない時はたいてい，墜落ということである．NIPの疎通テストが完了しないかぎり他のモジュール単体テストができないのである．
我々の担当したメモリ管理の部分は確か３日程度で通過したと記憶している．当初の予定の数分の１の時間で通過できた．このためにNIPの工程遅れをやや取り戻せた．研究所の最初の評価はこれで高まった．疎通テストもほぼ予定どおりに終わり，1984年５月から全モジュールの単体テストが開始した．
＜先頭へ＞
＜ページの最後へ＞
（４）単体テスト
いよいよ機能追加した部分のプログラムをテストする工程に入れるようになった．NIPではメモリ管理の基本部分しかその動作確認をしていない．ＯＳが動作開始するための必要最低限の環境整備をしただけである．それらも完全か否かは未確認であり，ひとまず問題なくメモリ管理の初期化部分を通過して他の担当部署のプログラムに引き渡されたという状況である．
プログラムモジュールの単体テストはテスト仕様書に書いた通りのテストプログラムを作成し，その各々を実行することでモジュールが設計通りの動きをしたかチェックすることである．テストプログラムもプログラムであるのでそれ自身のデバッグも必要である．ここで重要なのはテストプログラムの中に被テストモジュールの処理結果を自動確認するロジック（論理）をテストプログラム内に組み込んでおくことである．しかもその証拠となる情報を出力することができなければならない．しかしこのような手法が不可能なケースもあるので，その場合は立会（マシン時間を予約しシステムディスクを運び込みオープン使用する）によりオペレーションし，動作確認するしかない．テスト仕様書ではこれらをPCL(Program Check List)と呼んでおり，各自がPCLの処理件数を保有していた．プロマネ（工程管理者）は各プログラマに「今日はPCLを何件処理しましたか？」と毎日のように聴きに来ると同時にプログラマの顔色を見て状況判断をしていた．
PCLの処理件数は毎日計算され進捗管理がなされていた．どのグループが遅れている，進んでいるなどが日々の課長会議の場で報告され図表に掲示された．毎日のように開催される部長席での課長会議では全体の進捗状況の報告，遅れているグループの対応策，見通し，などが検討されていた．PCLの処理件数は新規コーディング量，改造部分では被対象モジュールサイズと改変の割合，などから検査部の長年の経験から割り出された値との比較で是正されていた．工場はどれだけ遅れるとリカバリ不能になるかというノウハウを持っていた．我々のメモリ管理グループのPCL消化は順調であった．
＜先頭へ＞
（５）不破工場長の激励
PCL消化のために一生懸命作業をしているとき，私の机の前に立つ人間がいた．誰かな？と思い顔を上げると不破工場長であった．時折このように私の机の前に姿を現す．そして「君だけが頼りだからな．頼むよ！」「私はこうして時々激励にくるしか役にたたないんだ．まるで靴の上から水虫の痒みを掻いているような気分なんだ．それも靴の上からならまだマシだけど，空中で掻いている感じなんだな！」と良く言っていた．確か，不破工場長は1984年8月の人事で工場長を終え，高須昭輔工場長に替わったのだと思う．高須昭輔工場長は昔からの知り合いで，中田育男さんの１年後輩（東京大学・数学科）であった．（中研）に入社したらしいが，神奈川工場に移籍し，そのままソフトウェア工場勤務となったらしい．高須工場長は一度だけ私を激励のために豪華な夕食を御馳走をしてくれたことがあった．日立を退社する時には高須工場長は日立情報システムの社長になっていた．渋谷本社に退社のご挨拶に行ったが，昼食に鰻重を御馳走してくれた．社長就任直後だったせいか，かなりくたびれた顔をしていた．退職金はどうした？なんて話をした記憶がある．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
我々のグループはその平均の数倍の働きをし，研究所で私が鍛えた人材の質の高さを示すことができたと思っている．話を元に戻す．設計が済み1984年2月からはコーディングをする段階に入った．ここでも問題はテキスト編集をするTSS端末数の制約にあった．システムプログラム部が一斉にプログラミングのフェーズに入ったため端末数が圧倒的に不足していた．我々の担当した部分はVOS3/ES1の最も重要な機能であるのであるが，コンピュータを使用する段階では全プログラマは端末の前には平等なのである．コーディングの量が平均以上であるためTSS端末を我々のグループ専用に割当てて欲しいのが本音であった．
実はこの開発当初に神奈川工場長がソフトウェア工場を訪れた際に，私の職場にわざわざ挨拶のため足を運んでくれた．その時，「吉澤君．頑張ってくれよ．もしマシンが不足するならいつでも私に言って欲しい．マシン不足など絶対にさせないから．」と言ってくれたのである．マネージャとしてはこのぐらいのことしか言えないのは理解していたが，TSS端末やマシン時間で優遇されることは決してなかった．工場では特定の人間を優遇するような不公平をするとモラルの低下に繋がるためであろう．しかし，端末が無くて作業が遅れるのは大きな問題である．そこで，システム開発研究所のTSS端末状況を調べると十分な量があり，４台ぐらいはいつでも利用可能であることが分かった．
本当は，工場外に持ち出し禁止となっているソースコードであるが，自己責任でこれを持ち出して（シ研）に一時的に戻り日夜プログラミングを行った．このお陰で無事にプログラミング作業を期日前に終了させることができた．プログラムの入力が済めば次はコンパイルである．これは（ソフト）に戻ってやる以外に無いがプログラム入力や修正に比べると端末使用時間は短くて済む．コンパイルするとコーディングの文法的誤りが出てくる．コンパイルによる文法エラー（フラグ）を取り去ると，それ以降のすべてをバグ・修正として記録を残す．モジュールごとにすべての修正の記録を書くことになっていた．このような管理を行うことで各プログラムの品質管理がなされる．マシン使用によるバグ取りの方法もあるが，そのようなバグ取りは極力避けねばならない．私は入社当時，マシンデバッグではなく机上デバッグを徹底的にやるように上司に仕込まれていた．現代はコンピュータが豊富に用意されているためか，机上デバッグせずにマシンデバッグに頼りすぎているように思えるが，悪い習慣になっていなければ良いか心配する．
（３）NIP疎通テスト
コンパイルしロードモジュールがリンケージエディタにより作られると，いよいよすべてのモジュールを一つのプログラムとしてまとめるシステムジェネレーションの作業に入る．ここで時折問題になるのはモジュール提出忘れである．担当しているプログラムを決められた通りに提出していないミスである．提出はシスジェン（System Generationの略）の係りが行う．システムジェネレーションの作業はシスジェン係りの仕事である．ここでも提出したモジュールにコンパイルエラーが出るなどのトラブルが発生すると大いに怒鳴られる．よくある誤りはマクロライブラリの指定誤りである．シスジェンは時間のかかる大きな仕事である．SEはシスジェンを顧客サイトで行うので，その経験がないと一人前ではないと言われていた．
こうして1984年4月に入ってVOS3/ES1がその形を見せた．だがバグの山である． 最初の難関はNIP(Nucleus Initialization Program)であった．NIPはコンピュータに電源を入れると指定した外部記憶（多くはＯＳをインストールした磁気ディスク）からＯＳを主記憶に読取るハードウェア機構(IPL*: Initial Program Loading)の延長上で動作するプログラムである．NIPの処理により無機質なコンピュータに命を吹き込み，まるで生き物のように動き出させるのである．電源を投入してからNIPの完了までをブートストラッピング(bootstrapping)と云う．丁度，編上靴を徐々に組み上げて行く過程に似ているので付けられたのであろう，コンピュータ用語はほとんど全てがアメリカ人の英造語である．ハードウェアに備わった基本的な動作の詳細を（注）で説明しているので興味あれば読んで欲しい．
（注）IPL*のハードウェア動作は次の通りである．
①オペレータはローディングすべき装置アドレスを操作パネル（当時はサービスプロセッサ）で指定する．多くは磁気ディスクのチャネル・装置番号を16進数で入力する．一般的に磁気ディスクからブートするので，これをブートディスク:Boot Diskと云う．
②LOADを指定する．
この２つの操作によりIPL機構が指定された周辺装置から主記憶上にデータを読込み，その後ある特定の処理を実行する．それらは以下の通りである．
(a) IPLとして指定された装置の最初のレコードから24バイトを読取り，主記憶の0番地からロードする．0-23番地までデータが入る．
(b) 主記憶に読込んだ第8番地から８バイトをCCW(Channel Control Program)として実行する．チャネルもコンピュータでありstored program方式である．CCWはそのプログラムコードである．（これをCCW1とする）
(c) CCW1をチャネルが実行すると，次の８バイト目を次に実行すべきCCWとして実行する．（これをCCW2とする）このため，通常CCW1はチャネルプログラム完了のフラグ（コマンドチェインフラグ）をオフとしてCCW2を実行させるようにしておく．そして，CCW2はチャネルプログラム完了フラグをオンとする．
(d) チャネルプログラムが完了すると操作パネルで設定したチャネル・装置番号が主記憶の2-3番地にセットされる．さらに0-7番地の内容が現PSW(current PSW: Program Status Word)になる．つまり，主記憶の4-7番地に格納された番地に分岐命令が実行されることになる．この番地がNIPというプログラムの先頭アドレスであるのでこのような動きを知った上でIPLレコードの24バイトを作成してブートディスクに書き込んでおく．
＜先頭へ＞ ＜ページの最後へ＞
NIPが動かない限りＯＳのみならず全てのテスト・デバッグは不可能である．つまり，すべてのＯＳコンポーネントの単体テスト・デバッグも不可能だ．ただNIPの過程では多くのＯＳコンポーネントが初期設定として動くのでNIPの担当者はNIPの動きがどこまで来たかを常時監視し，障害が起きた時にはすみやかに担当グループに連絡を取り対応してもらう方法を取っていた．大きな模造紙にこの流れが一目瞭然で分かるようにされ，通過した日時が書き込まれていった．これを疎通テストというが，疎通テストは拡張アドレッシングを持つマシンが大森別館（コンピュータ事業部の本拠地）にあり，そこまで毎日通う必要があった．大森別館には仮眠所があり徹夜勤務のような変則勤務体制が可能になっていた．
このNIPの疎通は1984年３月中旬から開始された．担当者は大学卒の中堅どころ(Mr.O)であった．しかしNIPを完全に理解しているとは思われなかった．仕方がない．皆，素人なのである．特に，今回の31ビット拡張アドレッシングについては勉強不足の感が否めなかった．我々の設計した内容を説明する機会が無かったのも問題であった．NIPの進行が遅延していることが明らかになり，急遽，手助けすることとなった．メモリ管理の方式や仮想記憶の仕組みなどを中心に説明し理解して貰った．
我々はNIPが躓いている間に机上デバッグを徹底的に行なった．そしてやっとメモリ管理にNIPが差し掛かるとの連絡が入り，大森に出掛けてメモリ管理部の疎通テストを行った．この時はいささか緊張した．プログラマは自分のプログラムが最初に動くとき不安を抱くはずである．我々は工場での初めてのプログラム開発体験であり，研究所から派遣されているという緊張もあった．いろいろな疎通テストの方法がある．もっとも簡単なのは一気に止まる所まで動かして見る方法である．バグがなく，うまくいけば通り抜けるはずである．つまり，何もしないという方法で，止まった時点で情報を収集して後に分析する．だが初めてのＯＳ開発でこの方法を取ると分析の手がかりを見つけるにも相当の時間がかかる．
もう一つの疎通テストの方法は，サービスプロセッサのアドレスストップ機能を使う方法である．CPUが指定されたメモリ番地を参照した際にコンピュータを停止する機能である．この疎通テスト方法ではテストするプログラムの先頭番地をストップアドレスとして指定しておき，CPUが命令フェッチ（Fetch: 読み出す）したときに停止するようにする．その後，要所要所を指定してアドレスストップをかけCPUが命令をフェッチしようとした時にを停止させ，場合によってはこの間に行った処理内容をサービスプロセッサで確認しながらメモリ内容を確認していく方式である．しかし，あまり細かな処理内容を確認していると与えられたマシン時間がなくなるので他に迷惑がかかる．一般的にはメインプログラムがサブルーチン（関数とも云う）を呼び出す寸前で止め，次に，サブルーチンからリターンして来たところで再度止める，という操作を繰り返す．リターンしない時はたいてい，墜落ということである．NIPの疎通テストが完了しないかぎり他のモジュール単体テストができないのである．
我々の担当したメモリ管理の部分は確か３日程度で通過したと記憶している．当初の予定の数分の１の時間で通過できた．このためにNIPの工程遅れをやや取り戻せた．研究所の最初の評価はこれで高まった．疎通テストもほぼ予定どおりに終わり，1984年５月から全モジュールの単体テストが開始した．
＜先頭へ＞ ＜ページの最後へ＞
（４）単体テスト
いよいよ機能追加した部分のプログラムをテストする工程に入れるようになった．NIPではメモリ管理の基本部分しかその動作確認をしていない．ＯＳが動作開始するための必要最低限の環境整備をしただけである．それらも完全か否かは未確認であり，ひとまず問題なくメモリ管理の初期化部分を通過して他の担当部署のプログラムに引き渡されたという状況である．
プログラムモジュールの単体テストはテスト仕様書に書いた通りのテストプログラムを作成し，その各々を実行することでモジュールが設計通りの動きをしたかチェックすることである．テストプログラムもプログラムであるのでそれ自身のデバッグも必要である．ここで重要なのはテストプログラムの中に被テストモジュールの処理結果を自動確認するロジック（論理）をテストプログラム内に組み込んでおくことである．しかもその証拠となる情報を出力することができなければならない．しかしこのような手法が不可能なケースもあるので，その場合は立会（マシン時間を予約しシステムディスクを運び込みオープン使用する）によりオペレーションし，動作確認するしかない．テスト仕様書ではこれらをPCL(Program Check List)と呼んでおり，各自がPCLの処理件数を保有していた．プロマネ（工程管理者）は各プログラマに「今日はPCLを何件処理しましたか？」と毎日のように聴きに来ると同時にプログラマの顔色を見て状況判断をしていた．
PCLの処理件数は毎日計算され進捗管理がなされていた．どのグループが遅れている，進んでいるなどが日々の課長会議の場で報告され図表に掲示された．毎日のように開催される部長席での課長会議では全体の進捗状況の報告，遅れているグループの対応策，見通し，などが検討されていた．PCLの処理件数は新規コーディング量，改造部分では被対象モジュールサイズと改変の割合，などから検査部の長年の経験から割り出された値との比較で是正されていた．工場はどれだけ遅れるとリカバリ不能になるかというノウハウを持っていた．我々のメモリ管理グループのPCL消化は順調であった．
＜先頭へ＞
（５）不破工場長の激励
PCL消化のために一生懸命作業をしているとき，私の机の前に立つ人間がいた．誰かな？と思い顔を上げると不破工場長であった．時折このように私の机の前に姿を現す．そして「君だけが頼りだからな．頼むよ！」「私はこうして時々激励にくるしか役にたたないんだ．まるで靴の上から水虫の痒みを掻いているような気分なんだ．それも靴の上からならまだマシだけど，空中で掻いている感じなんだな！」と良く言っていた．確か，不破工場長は1984年8月の人事で工場長を終え，高須昭輔工場長に替わったのだと思う．高須昭輔工場長は昔からの知り合いで，中田育男さんの１年後輩（東京大学・数学科）であった．（中研）に入社したらしいが，神奈川工場に移籍し，そのままソフトウェア工場勤務となったらしい．高須工場長は一度だけ私を激励のために豪華な夕食を御馳走をしてくれたことがあった．日立を退社する時には高須工場長は日立情報システムの社長になっていた．渋谷本社に退社のご挨拶に行ったが，昼食に鰻重を御馳走してくれた．社長就任直後だったせいか，かなりくたびれた顔をしていた．退職金はどうした？なんて話をした記憶がある．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
プログラムモジュールの単体テストはテスト仕様書に書いた通りのテストプログラムを作成し，その各々を実行することでモジュールが設計通りの動きをしたかチェックすることである．テストプログラムもプログラムであるのでそれ自身のデバッグも必要である．ここで重要なのはテストプログラムの中に被テストモジュールの処理結果を自動確認するロジック（論理）をテストプログラム内に組み込んでおくことである．しかもその証拠となる情報を出力することができなければならない．しかしこのような手法が不可能なケースもあるので，その場合は立会（マシン時間を予約しシステムディスクを運び込みオープン使用する）によりオペレーションし，動作確認するしかない．テスト仕様書ではこれらをPCL(Program Check List)と呼んでおり，各自がPCLの処理件数を保有していた．プロマネ（工程管理者）は各プログラマに「今日はPCLを何件処理しましたか？」と毎日のように聴きに来ると同時にプログラマの顔色を見て状況判断をしていた．
PCLの処理件数は毎日計算され進捗管理がなされていた．どのグループが遅れている，進んでいるなどが日々の課長会議の場で報告され図表に掲示された．毎日のように開催される部長席での課長会議では全体の進捗状況の報告，遅れているグループの対応策，見通し，などが検討されていた．PCLの処理件数は新規コーディング量，改造部分では被対象モジュールサイズと改変の割合，などから検査部の長年の経験から割り出された値との比較で是正されていた．工場はどれだけ遅れるとリカバリ不能になるかというノウハウを持っていた．我々のメモリ管理グループのPCL消化は順調であった．
＜先頭へ＞