ＲＯＳ ＣＯＰ－Ｌ

　どうにか「ＲＯＳ　ＣＯＰ－Ｆ」開発プロジェクトを卒業させてもらった後、「ＲＯＳ　ＣＯＰ－Ｌ」の開発に携わった。入社二年目、昭和４５年の秋からである。岡山県水島にある製鉄会社の圧延工場のシステムで利用されるソフトの開発だ。当時の班長さんから１５０ページ程の青焼ドキュメントを渡され、解説を受けた。お客様に出入りするＳＥさんからは、お客様のコンピュータを適用する業務内容の解説も受けた。鉄の塊を圧延して鉄製品を作る工場の、工程と製品在庫を管理するシステムだ。１台のコンピューターで２つの製造ラインを管理するというものであった。ハードウェアはＦ２３０－３５を２台使用した、デュープレックスシステム構成というところまで決まっていた。

＜お客訪問＞

　最初に指名された開発メンバーは４人だったと思う。班長さんや、顧客担当のＳＥさんの話を聞いたが、どうもグッと納得するものが来ない。メンバで、お客のところに行かせ欲しいと班長さんにお願いして、許可をいただいた。お客担当のＳＥさんにアレンジをお願いして、水島の工場に出張した。安全靴に履き替え、ヘルメットを被り工場の中を案内していただいた。真っ赤になった鉄の塊が圧延され、ものすごいスピードでコイル状に巻き取られる工程は圧巻だった。工場見学後、お客様からどういうシステムを構築しようと考えているかという話を伺った。１泊２日、丸１日かけてお客様の話を伺い、３ケ月の時間を頂戴し帰って来た。３ケ月後に、我々の提供するソフトウェアの仕様書を提示することを約束しておいとましてきたのである。

　見て、聞いた話は、真っ赤な鉄の塊が生産工程に投入されると、自動秤量器群からカスケード状にデータがシステムに殺到するというではないか。それまで知っていた、到着間隔はランダム、単位時間内に到着するデータ量は指数分布というオンラインシステムとは大きな違いがあった。とにかく、お客様のシステムの使い方・特徴をつかむことができたので、半分以上はシステム設計を終えたと同様な気分だった。知らないというのは恐ろしい！

　事務所に帰ってきてから、今度は他の工場も見学してみたいということになった。先輩SEさんにアレンジをお願いし、神奈川県にある自動車組み立て工場の見学に行った。工場の生産工程の様子を学ぶことができたのは大きな収穫だった。

＜外部仕様書＞

　まずはソフトの基本設計である。どんなソフトを作るかというドキュメントを書くのだ。何をどう作るかを一緒に書く方法もあるが、昔というかＣＯＰ－Ｌでは「何を作るか」と「どう作るか」を別けて書いた。使う側のお客様から見て、どんなソフトウェアＰＫＧなのか、どのように使うものかという内容を『ＲＯＳ　ＣＯＰ－Ｌ　外部仕様書』として記述するのだ。お客を訪問したメンバーでどんなもの・何を作るかを検討した。結果、お客様を訪問する前に班長さんから渡されていた青焼ドキュメントは、ごみ箱行きとなってしまった。

　どんなものを作るのか、何を作るのかを検討しまとめることは、これはソフトウェア開発に当たっての基本中の基本である。つまり、ソフトウェアの基本設計なのだ。しっかりした、コンセプト・思想・哲学がなければお客様に説明した時に仕様変更要求の嵐に見舞われるのだ。我々が提案するＳｐｅｃをお客様に理解して頂くには、何を作るかという「コンセプト」が明確でなければならないのだ。それと、その時代のキャッチアップ可能な技術を見極めていることが必要だ。つまり、外部仕様書を書きながら頭の中ではそれをどう作る、というシミュレーションをくり返すのだ。そうでなければ、提案／約束したソフトウェアの提供が出来ないということになるからだ。

　班長さんの青焼を捨てた原因はＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）と重複した機能をＰＫＧに持ち、その機能で待ち合わせ制御問題を解決しようという案だったからだ。我々の案は、全面的にＯＳの機能を使って待ち合わせの制御をし、システムとしての無駄を無くそうという案だった。ということで、お客様向けの外部仕様書を新しくゼロから書き直すことに決めてしまった。

＜外部仕様説明会＞

　昭和４６年の３月の初め、外部仕様書の執筆を終えて、お客様への説明に出かけた。お客様には２日間をかけて外部仕様書の説明を行った。今でも忘れないが、１つだけお客様から注文がつけられた。我々は、アプリケーションプログラムの異常を検出した時に、システム停止状態とする提案だ。お客様からは、１システムで２ラインの生産工程を管理しているのだから、それは困る。そのアプリケーションだけを殺して他は動かし続けて欲しいという要求だ。

　お客様の要求はもっともである。たった一つのアプリケーションのエラーが２本の製造ラインを管理するコンピュータを止めてしまうのだ。だが、我々のＯＳではその要求を受ける自信はなかった。まだ、マルチジョブの機能が実装されていないため、アプリケーションの異常が発生しても、その後始末の範囲（回収処理）を特定することが出来ないのと、一つのアプリケーションの悪さを他の生産ラインのアプリケーションに影響を与えないようにするガードをかけられないのだ。それを、ＰＫＧサイドで実現することは難しいことだったのだ。

　お客様のシステムは２４時間動き続けるシステムである。そう、当時の工場は３交代で２４時間動き続けていた。まず、お客様の要求を実現するには、技術が追随できていないこと。２４時間動き続けるシステムだからこそ、アプリケーションを含めて直ちにバグは取り除かれなければならないシステムであること。アプリケーションの異常でシステム停止という仕様を認めて欲しい、但し、アプリケーションが異常となった原因を追求するための資料を取得し、システムを５分以内に（だったと思う）再立ち上げ可能にしましょう。と言って、仕様の理解を求めたところ、我々の提案はその場でお客様に受け入れられた。これは想像だが、我々が一所懸命お客様のシステムがどうあるべきか必至で考えたSpecであることが伝わったのだと思っている。

　なお、この時お我々が提供出来なかった客様から要求された機能、ＲＯＳの次に登場したＯＳⅡで開発されたＣＯＰ－Ｌでは実現され、千葉工場のシステムに適用された。何とその開発プロジェクトにはJoBlogのジョージが参加していた。

＜内部仕様書＞

　事務所に戻ってからは、お客様と約束した外部仕様を持ったPKGを「どう作るか」という内部仕様の基本設計にとりかかった。「どう作るか」、これも外部仕様でいう「何を作るか」と同じように、どう作るかという「コンセプト・思想・哲学」を明確に持つことが非常に大事である。ソフトは大勢で分担して開発を進めるわけである。開発者仲間が同じコンセプトを共有して開発に当たらないと、プロジェクトの進行に手戻りが発生してしまうのだ。また、他のお客様にも適用しようとした時に、PKGの大部分が活かされない結果となってしまうからだ。PKGの適用範囲に対する指針、適用範囲が拡大した時の、PKGの機能拡張方式に対する指針、これらのことに対し明確な考え方を持って基本設計に当たらなければ、新たに開発したPKGの大部分が先々活かされないという、開発期間も含めた大きな損失になるからだ。これだけは言っておきたい「何を作るかというコンセプトと、どう作るかというコンセプトは一致するものではない。両者とも必要なもので全く別のものだ」と。

＜告白＞

　PKGの開発が本格化してきたゴールデンウィーク明け、春の健康診断で開発仲間の一人がつかまった。結核で長期入院が決定してしまった。実は哲、その年の１０月１０日、札幌で結婚式を挙げることが決まっていたのである。昭和４５年の暮から正月にかけ、北海道の実家（当時は北見枝幸）に帰り、結婚を決めたことを告げ、両親と相談し日取り、式場、仲人さんを決めて帰京していたのだが、そのことは事務所の誰にも秘密にしておいたのだ。

　１０月の１週間ほどの休み計画を、８月に入ってからでも、班長さんや仕事仲間に言おうと思っていたのである。ところが、開発の中心人物の一人が長期入院、しかも、１０月は開発作業が佳境という時期だ。やばい、早めに休みの計画を言っておかねばと、予定よりもかなり早く自分の結婚計画を白状することになってしまった。同じSE部門に配属された同期の中で、３番目だった。班長さんに「ウッソ～」と驚かれてしまったのは当然かもしれない。何しろ、徹夜での仕事が多い部署だったのだから・・・