CAD/CAM 開 発 に 捧 ぐ
守屋 洋之助あったが，それを数千巻格納できる専用保管室が機械室脇に設えられ，厳重な防火扉がついていた．
計算機の記憶容量は 4K ワード（16KB），
OS は TOS（Tape Operating System），コンソール・ボードは
16 進のパネル・スイッチであった．大きな図体にもかかわらず処理スピードは，現在のデスクトッ
プ PC に比べ一万分の一以下に過ぎなかった．その計算機の容量不足はたちまち深刻になり，入社 2
年足らずの間に 300MB のディスク装置の付いた
新型汎用計算機（記憶容量 256KB，DOS－Disk
Operating System）が導入された．運用切替には時日を要することから新旧計算機の並存が避けられず，スペース確保のため，他の階への移動を含む部内の配置換えが行われた．年々の開発技術者増員およびエンド・ユーザ部門との密接化も配置換えでの考慮点であったはずである．なお，このような動きは，その後 3，4 年に一度は繰り返されて行った．入社当時，開発者事務室の総勢は 5~60 人，
その 90％が男性であったが，機械室は若い女性 20人余りの職場であった．この女性の職場は，その後 10 年程の間に，入力の端末化やオペレーションの自動化によって分散・縮小され，さらに PC 化のなかで解消されて行ったのである．技術環境の変化とは言え，仕事仲間に関わるこのような変化には一抹の哀愁を覚えざるを得ない．

１．はじめに
日本の造船業が率先してコンピュータ導入を始めたのは，船舶大型化の潮流にあった 1960 年（S35）頃と聞く．私が大学を卒業して日立造船に入社した 1967 年（S42）当時，草分けからの先輩達の下で若い一団がコンピュータの応用開拓に燃えていた．時を経て，今や IT は世界の一般共通語になり，「e シンドローム」の状況にあるが，コン
ピュータ応用 40 年の歴史を有する日本の造船業が情報化における伝統的地位を保っているか気になるところである．ついては，造船情報システム化を代表する CAD/CAM 開発の歩みはどうであったか，私自身の経験事例を記し，これからの展開に関わる方々の参考に供したい．

２．造船，コンピュータとの出会い：1967 年（S42）
大学では理論物理を専攻した身，海や船は好きな方であったが，入社するまで造船に関しては全く無知であった．また，学生時代にアナログ計算機なるものを展示で観たことはあったが，ディジ
タル*1 計算機がどのようなものか知る由も無かっ
た．入社配属先は，造船所現場からかけ離れた大阪本社の事務管理部技術計算課システム 2 係．1
係は，陸機関係の技術システム，2 係は造船向け技術システム専門*2 であった．別に，事務計算課があったのは勿論である．事務管理部は本社ビルの最上階を占め，半分が開発事務室，残り半分が機械室であった．床上げされ，強力な空調が施されていた機械室には，カード・パンチ・マシン*3 数
十台，汎用計算機 1 台，そして，カード・リーダ，
磁気テープ装置，ライン・プリンタ，紙テープ・
リーダ／パンチャなど周辺装置が置かれていた．
また，磁気テープ（12 インチ・リール）は，プロ
グラムやデータを保存・再利用する枢要な媒体でさて，仕事の始まりは勉強からである．造船プ
ロセスの概要，技術計算プログラム開発用言語
Fortran*4 およびプログラム・フローチャートの書
き方などを諸先輩から教わった．部分的な手引書・参考書は幾つか存在したが，先端的ないし総合的なテキストなどは無かったので，経験者から学び，自分でやってみるのが早道であったのである．簡単なテスト・プログラムを幾つかこなした
あと，初めての実用プログラム開発テーマとして，
船舶空調用コンプレッサの所要容量を決定するプ
ログラムの開発が与えられた．区画毎の潜熱のほか，壁材と温度勾配による外部からの伝導熱を求め，適切な室内温度・湿度を保つための吹き出し*1

当時，「コンピュータ」とは呼ばれていなかった．
「システム」は，ソフトと同意語であった．
*3
プログラムやデータの入力媒体は IBM カード
か紙テープのみであった．
*2*4

因みに，事務計算プログラム開発言語は Cobol
であった．

286

夜間のコンピュータ処理に多忙を極めた．入社間もない私もその徹夜作業にしばしば加わったものである．図 1 に HIZAC 運用プロセスの概要を示す
が，（後期）と付記があるのは，後述する統合シス
テム運用時のものである．

温度・湿度・風量を計算するものであった．これ
らの計算に必要な情報は殆ど造船設計便覧から得ることができたが，潜熱と温度・湿度との関係をグラフ化した空気湿線図の扱いが問題であった．
全体を表す関数式なるものはないか調べたが何処にもない．やむを得ず，カーブ毎に複数の線形式を当て嵌めて近似することとした．プログラム完
成に数ヶ月を要したと思うが，計算結果がそれらしく得られ，機装設計技術者と共著の社内技術論
文に纏められた時，初めて開発の面白さとやりがいを覚えたものである．

３．船殻生産設計・NC 統合システム HIZACの開発： 1968 年（S43）~1977 年（S52）1965 年（S40）10 月，国内造船他社に先駆け，堺新工場に鋼板 NC 切断機と大型自動（NC）製図機が設置された．この計画は，新工場構想の一環であり，本社では，NC テープ作成に必要な図形処
理 言 語 HIZAC （ ハ イ ザ ッ ク ， Hitachi Zosen
Auto-Coding System）の開発がその数年前からスタートしていた．そして，稼動時の運用手順は，工場で構造・部品図形のパート・プログラムを HIZAC
専用シートに手書きし，本社に定期トラック便で届け，カード・パンチを経て HIZAC で処理，出力
NC テープを工場に返送，大型自動製図機で確認しながら手作業でネスティング，それを基に NC テープを編集，完成した NC テープを現場の NC 切
断機にかける，と言うものであった．メールの往復で各 1 日，本社での処理に 1 日，いわばコンピ
ュータ処理に最低 3 日を要していたのである．しかも，コーディング・ミスやプログラム・バグ，
計算機異常，処理オーバーフローが伴うとコンピ
ュータ処理に 1 週間前後を費やすことになった．
HIZAC 開発チームは，そのような大きな遅れが出ないようにするため，プログラムの改良・バグとりを続ける傍ら，パートプログラムのチェックやこの鋼板 NC 切断システムに限定された開発の一方で，現図作業全体のコンピュータ化に関する研究開発が始まっていた．その主な項目は，既に十分とされた内構大型部品形状処理を除いて，船体線図フェアリング，工事用ボディプラン作成，
外板・ロンジ展開形状処理，ブラケットやスティ
フナ等小型部品形状処理，外板曲型寸法計算，外板組立治具寸法計算などであった．それらは全て船体曲面に関わる処理であり，中でも，船体曲面の表現をサポートする船体線図フェアリングの実現が要であった．それは，縮尺 1/50 または 1/100のラフな基本線図（LINES）を基にしていた．このラフ LINES は，船体曲面を深さ・幅・長さ方向
それぞれの断面曲線群，すなわち，ウオータ・ライン，バットック･ライン，オーディネート・ステ
ーション・ライン，および，それらの交点を座標値で示すオフセット・テーブルで表現されているが，真に滑らかな曲面からすると実寸で最大数百ミリの誤差を有する．船体線図フェアリングとは，この誤差を最大数ミリ以下に調整し，さらに，それに基づいて工事用断面曲線群（フレーム・ライン）を求め，結果として LINES およびフレームラ
イン正面線図を作成する一連の処理のことである．
ただし，私が開発を継承したとき，このような処理手順・手法は未だ解明されておらず，各断面の点列をどのように滑らかな曲線（バッテン・カー
ブ）で近似するか，そして，曲面全体のフェアリ
ングをどのように達成するかが中心課題であった．
まず，バッテン・カーブについては，既に先輩が研究調査して来ていたものであるが，解析スプラ
インの一種で，3 次曲線を重ねたタイルハイマーの入力修正・再入力
プリンタ
バッチ方式
手書シート

カード
プログラム

紙テープ

（後期）ＯＣＲ（後期）フロッピー

図 1 : HIZAC のバッチ方式運用プロセス

287

自動製図機

ＮＣ切断機

曲線近似式*5 を応用することにした．まず，このながらも数年を要し，その後も 5 年余りに亙って式の係数をどのように求めるかが課題であったが， 改良を重ねることとなった．事由の一つは，船体バッテンの性質を模して，与えられた点列からの曲面フェアリングは，工芸に似て一意的にできな乖離を最小にすると共に全体としての曲率の変化
いことである．すなわち，曲面の微妙な変化につを最小にする条件式と始終点での拘束条件から得いて，ベテラン現図工が常に納得するように制御られる連立方程式を解くこととした．また，曲線する計算論理が無い．また，船首尾や船側・船底を表現するＸＹ座標としては，船体曲面全体を表平面部との境界線のとり方によっては，クロス・現する船体座標の直接的な適用は無理であり，汎フェアリングの収束計算が正常に終了しないこと
用化も考慮して，始点と終点を結ぶ直線をＸ軸ともある．私自身，40~50 隻にのぼる実船処理を行するローカル座標系を用いることとした．さらに， い，問題点の本質を追求しながら，一方で自動化の限界を理解せざるを得なかったのである．実用
一つの断面曲線は，直線部分が含まれたり曲がり
化初期の忘れられないエピソードは，社内の基本が大きいときなど，一般に１本のバッテンでは近設計で「LINES の神様」と謳われた LINES 製図の似しきれないので，直線部分の境界を指示可能とすると共に，点列の状態を解析して複数のバッテベテランが，コンピュータで LINES が作られるのン・カーブを接続するという工夫を採り入れた．
を見て間もなく，職場を去ったことである．
こうして開発できた点列近似曲線処理ルーチンは，
船体線図フェアリングの実用化に目処がついた
船体曲面の各断面や境界線の表現に適用され，ま1969 年（S44）頃，船体線図情報をデータ・ファ
た，別の応用として外板ロンジやシームの曲線表イルとして保持し，それをベースとして鋼板 NC
現にも役立つものとなったのである．次に，曲面
切断用内構図形処理およびその他の現図処理を統のフェアリングとして，曲面上の任意のオフセッ
合的にサポートするシステムの開発が開始された．
ト点で交差する二つの近似曲線，すなわち，ウオ
私の担当は，システム構成の企画のほか，船体線
ータ・ラインとオーディネート・ステーション・
図フェアリング，船体線図データ･ファイルを発展
ラインの間の誤差を最小化するため，全てのオフさせたデータ・ベース，外板シームや外板ロンジ
セット点について，それぞれから計算される二つの曲線を扱うサブルーチン，スロット形状処理やのオフセット値の平均値を新しいオフセット値と外板ロンジを境界とするスティフナやブラケット
し，改めてそれぞれの近似曲線を求め，この手順の形状処理に必要なロンジ断面・境界形状を扱う
を誤差が与えられた許容値以下に収束するまで自サブルーチンなどの開発であった．その頃デー
動的に繰り返すこととした．これは，手作業によタ・ベースと言う言葉もなかったが，その開発にるクロス・フェアリングのシミュレーションであ当たっては，幾つかのアプリケーションが共用する．そして，フレーム・ラインは，クロス・フェることから，共用しうるデータを全て包含するこアリングの結果として得られたウオータ・ラインと，DAM（Direct Access Method）ファイルとするからフレーム・ラインの点列を計算し，その近似こと，データ更新に伴うスペース管理をサポート
曲線として求めた．しかし，LINES やフレーム・することなどを考慮して設計し，データ・ベース
ライン正面図を図面として得るためには，自動製管理および書込・呼出用サブルーチン群を開発し図機用 NC テープの出力が必要であった．そのた
た．この開発が比較的スムースにできたのは，一め，上記で得られた各曲線を，更に，連続する円人で設計・開発を行ったことが幸いしたと思う．
弧ないし線分で近似し直し，それを独特の NC フ
曲線データとしては，船体線図フェアリングにおォーマット（ESSI または EIA）に変換した．開発
ける点列の近似曲線そのままとするとデータ量がした機能の概要は以上のようなものであるが，全かさむこと，データの内容が他のアプリケーショ
面的な実用化には，ベテラン現図工の協力を仰ぎ
ン開発者にとって理解しがたいこと，他の図形表
現との統一と最終出力には円弧･直線分に近似しなければならないことなどから，全て円弧・直線
分表現とした．外板ロンジの曲線表現では，ランディング・ラインとして定義される空間曲線，および取付角度・捩れを表現する倒れ角度曲線をベ*5点列（X1,Y1）, （X2,Y2）…（Xn,Yn）に対する
タイルハイマーの曲線近似式：
Y=F(X) = aX3+bX2+cX+d+∑Ki ( X-Xi )†3（ i=1~n ）ここに， a, b, c, d, Ki…… 係数( X-Xi )† = |X-Xi| …… X-Xi＞0 の時( X-Xi )† = 0…… X-Xi≦0 の時

288

ースとして，フランジ面*6 の両端を示す 2 本の空間曲線を求めて加えた．各空間曲線は，実際には平面投影，側面投影の 2 本の平面曲線となり，一つのロンジを表現するのに倒れ角度曲線を含め計7 本の曲線を用いたことになる．
これでよいか少し気になったが，ロンジ断面形状およびスティフナ
やブラケットの境界形状が期待した精度で得られたとき，内心ほっとしたものである．当時，HIZACのソフト開発チームは外注エンジニアを含め 10 人ほどであったが，開発の効率化のため，当時大阪市内にあった IBM データ・センターに詰め，最新･大型コンピュータ IBM360 を自由に使えたのは，上司のよい采配であったと思う．また，ユーザである堺・因島・舞鶴各工場生産設計部門との間に，要求仕様作成，システム仕様検討，テスト入力データ作成および出力データ検証に関する緊密な協力体制が維持され，これが各機能の有用性を保証すると共に運用化をスムースにしたと言える．

正当性が問われたのである．技術的には，コンピ
ュータの処理時間（CPU タイム）が大き過ぎないかと言う問題である．調査に当って，まず，HIZACと同様のシステム SHIP を開発・運用していた三菱・長崎を訪れ，関連する処理方式・処理時間について情報交換を行った．SHIP でのコンピュータ
処理時間は問題となるほどではない．処理方式や運用に違いがあるが，それは HIZAC での処理時間の問題に結びつくとは考え難い．そこで，問題は処理方式以外にあることを確信し，プログラムの
何処で CPU を喰っているか細かくチェックすることとした．その結果，統合システム開発以前に作られた一連のサブルーチンに原因があることが判明したのである．主な原因は，図形データの内部処理でワーク・ファイルにシーケンシャル・アク
セス・ファイルを使っていたことにあった．その一連のサブルーチンが開発された時のコンピュー
タでは，主記憶容量が小さいためワーク・ファイ
ルを多用するほかなく，しかも，磁気テープによるシーケンシャル・アクセス・ファイルしか使えなかったのである．そこで，2 万ステップに及ぶプ
ログラムの流れを追跡してワーク・ファイルの使用を減らすと共に，必要なワーク・ファイルの全てをダイレクト・アクセス・ファイルに切り替えるという手術をほどこした．多くの人が手分けし継承して開発してきたこのようなプログラムを一つの目で見直すと言うのは空前絶後のことであろう．ともかく，この集中対策により，処理時間が一挙にほぼ十分の一に短縮されたのである．このような見直しが夙になされていたなら，1 億円は 1千万円に節約でき，システム・ランの外注も必要でなかったかも知れない．当時そのような責任は問われなかったが，当事者の一人して赤面する手
抜かりではあった．

統合システムの開発に入ってから 2 年足らずで部分的な運用が始まり，開発チームも本社に戻っていたが，機能の拡充は勿論，ソフトの安定化と性能向上のための開発が延々と続いた．その頃，より大きな船をより多く建造する趨勢の中でシス
テムの運用化に拍車がかかっていたが，処理量が急速に増大して本社コンピュータの容量不足という予期せぬ事態を招き，急遽，鋼板 NC 切断テープ作成に関わるシステム・ランを東京にある他社の計算センターに委託せざるを得なかった．そして，毎日の入出力データは，大阪～東京間の深夜専用トラック便で運んだのである．そうした中，第一次オイルショックが始まっていたこともある
が，社外計算センターの利用に伴うシステムのラ
ンニング・コストが問題となった．40 万トン・タ
ンカー1 隻の外注計算コストが 1 億円に達し，そのデータベース

バッチ方式プログラム

Ａ

・工事用線図バッチ方式プログラム

Ｂ

バッチ方式プログラム

Ｃ

・内構図形
・一品図形

図 2 : HIZAC 統合システムの処理形態*6I 形鋼，バルブプレート，T 形鋼を含め，仮想の不等辺山形鋼モールド形状で表現した．

289

こうして HIZAC の開発は，有明新工場稼動 1 年
後の 1974 年（S49）頃までに一段落し，運用効率化のための環境作りにウエートが置かれるようになったが，それは全社的な対策の一環でもあった．
すなわち，都心から外れた所に新設された計算センターに HIZAC や他の技術計算，事務計算のシス
テムを設置し，本社や各工場との間でデータ通信
によるジョブの遠隔入出力（リモート・バッチ）を実現することになった．センターのコンピュー
タは，新鋭の大型汎用機でそれまでの数十倍の性能と容量を有し，何十分も要していた HIZAC ジョ
ブが数分以内に完了するようになった．10 年掛けて開発したソフトに見合うコンピュータにやっとなったと実感し，「要求性能に関する限り，ソフト
は常にハードに先行する」と納得したものである．
一方，各工場においても，入出力処理環境向上対策がなされた．HIZAC 関連では，手作業ネスティ
ング支援システムの開発，NC 切断機シミュレータでもある大型自動製図機の更新，紙テープからフロッピー･ディスクないし磁気テープへの変更などである．中でも，カード・パンチの代替として
手書文字読取装置 XONDEX（ゾンデックス）が社内で開発され，リモート・オンライン入力端末として活用されたことが特筆される．このような一連の環境開発に HIZAC 開発の一環として関わったが，システムをソフトだけでなく運用環境全体として捉える目が養えたと思う．

４．外販ビジネスへの取り組み：
1978 年（S53）~1980 年（S55）

しいと悟っていた．もう一つには，コンピュータ
技術とそれに伴う情報システム産業が拡大発展の趨勢にあることは疑いの余地も無く，自由に羽を伸ばす機会が得られるとの期待もあった．ショッ
クであったのは，むしろ，経営戦略的に重要性の増す情報システム部門をなぜ分離することにしたのか理解し難かったことである．この疑問は，爾来解消していない．ともかく，新会社が新たに顧客を求めてスタートできるビジネスは，開発してきたソフトや機器製品とそれらによる情報処理サービスを本格的に販売することであった．こうして，我がチームの任務は，親会社工場向けに HIZACの改良・保守サービスを継続する傍ら，HIZAC の外販を試み，また，向島工場の一角に設営された
造船現図情報処理サービス・センターをサポートすることになったのである．私は，商社や切断機メーカなどの協力も得ながら，多くの国内中小造船所や海外造船所を訪問することになり，それぞれ異なる個性をもった状況を直に見聞することができた．しかし，HIZAC 販売の実績をつくることはできなかった．その主たる事由は，客先造船所
として，ソフト，ハード，切断機などの購入もさることながら，人材問題を含め運用体制確立に多大の投資が求められ，導入を躊躇せざるを得なかったことである．また，受注しても HIZAC チーム
は顧客サポートでかなりの困難に遭遇したかも知れない．しばらくは，HIZAC 外販を横に置いて，現図情報処理サービスに力を入れることになり，
私自身一時センター長を務めたが，結局落ち着くことはできなかった．

HIZAC の開発があらゆる面で一段落した頃，「ソ
５．造船設計支援システム HICAS の開発：
フト開発担当は 30 代が限界」なる 10 年来の世評
1970 年（S45）~1977 年（S52）もあって，個人的には，生き甲斐になっていた開発業務から離れ，どう転進できるか不安を抱いて船殻生産設計・NC 統合システム HIZAC の開発
いた．一方，企業レベルでは，第一次オイルショをスタートした頃，配管ルートの決定と管一品図ックを契機に高度経済成長が終焉して合理化の波
作成の自動化を主なテーマとした配管設計自動化が高まりつつあり，情報システム部門のコストをの研究開発が別のチームによって始められた．間どうするかは重工各社の共通課題となっていた．
もなく，配管設計の自動化には船殻構造の幾何情
その中で，日立造船はいち早く情報システム部門
報が不可欠との認識が生まれ，また外からは，対の分離独立を進め，1977 年（S52）12 月，日立造
話図形処理装置「スケッチパッド」が米国で誕生
船情報システム（HZS）が誕生，情報システム部したとのニュースや土木設計エンジニアリング向門の管理者以下全員が新会社に移行したのである． け総合データベース・システムの開発に関する情当事者として，身分保障上の危惧はいくらかあっ報が伝わり，幾何図形を扱う設計作業全般へのコたものの，それにショックは覚えなかった．理由
ンピュータ応用すなわち総合 CAD の可能性への期待が齎された．そこで，配管設計自動化の研究の一つは，開発業務が開発予算管理とユーザに挟
開発は，1970 年（S45），テーマを拡大して造船設
まれ，開発担当責任者としてもがきに近い思いに
計総合支援システム HICAS（ハイキャス，Hitachi
なっていたからである．端的に言えば，開発業務
Zosen Computer Aided Shipbuilding System）の開発について他部門が理解し正当に評価することは難290

へと発展し，データベースに基づくアプリケーション・システムとして，船舶算法統合システム
HICAS-C，船殻システム HICAS-H，および配管シ
ステム HICAS-P の開発がスタートした．データベースについては，米国の技術を導入する努力が払われたが，コンピュータ技術の急速な進歩のなかで基本技術が陳腐化してきており，また重すぎると判断されて，結局，基本システムを独自開発することになった．まず，HICAS-C は，線図データの一元化を除くとそれまで開発されてきていた個別の計算プログラムをまとめ直すだけで比較的容易であり，運用もほぼ軌道に乗ったといえる．
HICAS-H については，HIZAC との統合を前提に，新たに船殻構造に関する幾何図形対話定義機能と外板展開図（Shell Expansion）作成機能の開発に的が絞られた．幾何図形対話定義の基本システムをどうするかがまず問題で，ベクトル式の最新表示
装置を１セット購入して検討したが，余りに高価（当時 1 台約４千万円）で造船に相応しくないと思われたこと，ホスト・コンピュータに接続して基本設計・詳細設計のユーザが使うには，単なる製図ツールでは効率化が期待できないとの見通し
から，新たにソニーなどが開発した蓄積型表示装置を採用するとともに，構造図形のマクロ処理開発に重点が移された．そして，HIZAC が完成して私が HICAS-H 担当を引き継いだ 1975 年（S50）頃
テスト運用が行われ，また，HICAS として外販の動きも始まったが，ホスト直結（オンライン）対話処理ではレスポンス性能が不十分など設計ユー
ザの支持が得られず，外板展開図作成機能を除いて運用されないままとなった．一方，HICAS-P は，配管系統図・配置図・一品図作成機能が開発され，
特に一品図作成を中心に運用が定着し，外販も海外に数件の実績が得られた．残念ながら配管系統
図・配置図は本格的に定着しなかった．理由としては，導入・運用コストが依然として高価で，レスポンスに不満が残ったことが挙げられる．なお，一品図作成は正確な生産資料出力として歓迎された訳であるが，その前提となる配置図情報の入力については，配置図作成機能のオプションであったバッチ方式マクロ入力が活用された．そして，
HICAS の運用は，外板展開図と配管一品図に関する限り，開発中断後，すなわち 1978 年（S53）以降も，次に述べる HICADEC が運用されるまで続けられたのである．

291

６．統合 CAD/CAM システム HICADECの開発： 1981 年（S56）~1994 年（H6）1980 年（S55）秋，その 1 年前に始まった第二次オイルショックが深刻化し，日本造船界では，過剰設備削減と共に「如何なる船を如何に造るか」が緊急の課題となっていた．そして情報システムの高度化による武装が必要との認識が高まる中，日立造船設計部門と HZS から幹部が集まって意見交換が行われた．それは，関係者で話題となりつつあった統合 CAD/CAM システムの新規開発は是
か非か，是とすればどのような開発とすべきかについてであった．その背景として，設計業務の情報処理効率に関連しては，基本設計・詳細設計（ヤード設計）・生産設計の垂直統合，並びに船殻設計・各種艤装設計の水平統合をデータベースに基づいて進めたいとの総合的な要請があり，また，
図面や技術資料の配布･保存･検索における効率化としてのペーパーレスが求められていた．特に生産情報に関連しては，正確な重量・切断長･溶接長
等の物量把握，3 次元情報によるブロック組立作業支援，そして，研究開発が進行していた溶接・塗装ロボットとの接続が求められていた．これらは，
HICAS では達成されなかった課題であり，また，
2 次元情報ベースの HIZAC では対応困難と見なされた課題である．一方，HZS では，米国製スタンド・アロン型 2 次元 CAD システムを 1978 年（S53）から導入し製図サービスに活用していたが，日本語化や個別顧客ニーズに向けたアプリケーション
開発が難しいことから，自前の CAD ソフトが必要であることを痛感して，1980 年（S55）始め，2 次
元･3 次元ハイブリッド汎用 CAD である GRADE/Gの開発に着手していた．また，ちょうどその頃，
CADAM や CATIA に代表されるようなホスト・コ
ンピュータによる 2 次元，3 次元 CAD が話題となる一方で，汎用コンピュータに対抗するスーパ
ー・ミニコンが登場し，UNIX による仮想記憶制御の下，マルチ・ジョブや対話端末などが効率よく，安くサポートできる可能性が開けていたのである．
さて，意見交換では，CAD/CAM 市場に該当ソ
フトがなく，HICAS など既存ソフトの拡張は難し
いとの認識で一致し，開発ビジョン，すなわち，
内容・ステップ・体制・コスト・効果について半
年間のフィージビリティ・スタディを行うことになった．そして，夢と現実の狭間で多くの関係者を交えた検討が行われ，1981 年（S56）7 月までに
HICADEC （ ハ イ キ ャ デ ッ ク ， Hitachi Zosen
Computer Aided Design, Engineering and Control

System）開発プロジェクト計画が承認・決定された．それは，開発するシステムの概容として，船殻システム HICADEC-H，配管等艤装システム
HICADEC-P，電装システム HICADEC-E のサブシステムで構成し，図形入出力とサブシステム間図
形参照をサポートする基本システムに GRADE/Gを適用するものであった．開発期間については，
当事者周辺で「10 年は掛かるだろう」との意見も多かったが，企業として許される限界から 5 年，
遅れても 6 年と設定し，しかも，1 年毎に何らかの成果が見られるべしとの条件付であった．また，開発体制としては，関係部門の責任者からなるプ
ロジェクト推進委員会を調整機関とし，作業専従部隊として，工場設計部門に要求仕様開発チーム，
HZS にシステム開発チームを置くことになった．
特に，作業専従部隊の編成では，要求仕様開発チームを有明工場一箇所に集中することと各所設計部門の若手をシステム開発チームに加えることを重視した．これは，この開発が長期かつ総合的であり，継続的で纏まりのある要求仕様とユーザ体制の開発が鍵であることが痛感されていたからである．また，このような新たな生産ソフトの開発
は，システム・エンジニアと設計エンジニアが共に一線からスタートし，互いに学びながら協働するものとの認識があった．

図形表示端末（GD）をペアで採用した．しかし，一台の SMC に対し，レスポンスの劣化が受容できるレベルで同時に使用できる WT の接続台数が問題であった．運用では最高位の SMC が採用されたが，WT30 台程度の接続が限界で，ユーザ 100 人の工場では，3~4 台の SMC が必要であった．SMC
登場から 10 年後の 1990 年（H2）頃，CPU は更に
コンパクトになり，図形表示端末と CPU が一体となったワーク・ステーション（WS）が登場して，
俄かに SMC 構成から WS 構成への切替が始まった．
ただし，SMC 本体は，データベースとバッチ・ジ
ョブ専用のサーバーとして，3~4 年後に専用サーバーに切り替えられるまで残された．私がHICADEC 開発･保守の担当責任から離れた 1994
年（H6）以後では，WindowsNT の成熟を待って，
1997 年（H9）頃からクライアントについて PC への転換が図られている．なお，対話図形処理における入力に関連して，ライト・ペンとタブレットの選択肢が当初からあったが，アプリケーショ
ン・コマンド・メニューを指示し易いタブレットを採用してきた．そして，WindowsNT への移植においてプルダウン・メニューも採用されたが，面白いことに，以前からのユーザーの殆どがタブレ
ットの利用を強く推奨しているとのことである．
ソフトの開発は，大きくフェーズ 1 とそれに続くフェーズ 2 に区分した．フェーズ 1 は，基本シ
ステム GRADE/G，データベースおよびヤード設計
支援機能の開発，フェーズ 2 は生産設計および基
本設計の支援機能の開発が目標であった．当初，それぞれ 2 年の計画であったが，GRADE/G とデー
タベースの開発に予想外の時間を費やし，フェー
ズ 1 の完了にはほぼ倍の期間を要した．また，1年毎に成果を披露することが求められ，裏話ではあるが，1 年目にデータベースに基づく機能を見せることが不可能なことから，GRADE/G をベースに
船体中央断面図を作成する機能を別途開発し，デモを行ってお茶を濁したことがあった．なお，造船環境の変化の中で，残念ながらフェーズ 2 基本設計支援機能の本格的開発には手が届かずじまいとなった．

こうして，1981 年（S56）7 月から作業専従部隊の編成が始まり，直ちに作業が開始されたが，マニュアルもない状況の中では，アドホックな提案に基づく試行錯誤の形をとらざるを得なかった．
これを軌道に乗せるために重視したのは，システ
ム・コンセプトと開発プロセスに沿ったドキュメ
ント作りである．サブシステム毎に担当チームを編成して作業を委託したが，私は基本的・共通的な内容に関与することとした．それからの具体的な経緯については，情報技術環境の急激な変化などを背景に幅・密度が以前の経験を大きく上回り，
ここに語り尽くせないのが残念である．なお，統合 CAD/CAM シ ス テ ム の 概 念 で あ る CIM（Computer Integrated Manufacturing）が話題となり始 めた 1984 年（S59）頃 以降は，こ れに倣 い「HICADEC は造船 CIM 実現が目標」との触れ込
データベースについては，データの格納・参照
みにした．以下では，HICADEC 開発における共通に関する基本機能を開発し，データの内容構成は的な事柄と各サブシステムについて要約を試みる． 各サブシステムが分担した．基本機能を独自開発したのは，多重アプリケーション・プロセスに必要なマルチ・アクセスとコマンド当たりの高頻度アクセスをサポートするエンジニアリング系デー
タベース管理システム（DBMS）が当時のソフト

ハード環境については，HZS での開発に続いて各工場での運用向けに，当初，米国製スーパー・ミニコン（SMC）およびそれに接続する各作業端末（WT）として文字表示端末（CD）および国産

292

バッチ方式

対話方式

文字表示

アプリケーション
図形入出力 IF
図形表示

プログラム

諸プログラムＡGRADE/G
マルチ・アクセス

タブレット

制御プログラム
対話方式

文字表示

アプリケーション
プログラム B

図形入出力 IF
図形表示

GRADE/G
データベースタブレット

図 3 : HICADEC の処理構造

市場に見当たらなかったからである．しかし，マルチ・アクセス制御の実現は，オペレーティング・システム（OS）の核機能との連携が避けられず，
SMC メーカーサイドの協力がなければ困難であったであろう．この機能は当初 SMC 内でのディス
ク・アクセスに限定されていたが，WS 採用時には，
サーバーと WS 間でのデータ授受頻度を最小限にできるような工夫が加えられ性能が一段と向上した．基本機能の他の側面として，データベース初期化がある．開発当時，ディスク・ファイルの信
頼性は万全でなく，ファイル・バックアップ管理を容易にするため，物理的なディスク毎にファイルとその容量を設定するものとした．運用障害に備えるバックアップとデータベース復帰の方法については，事あるごとに繰り返して検討し，データベース更新記録を含む差分ファイルのバックアップにより障害発生の直前状況に直ちに復帰できるような方法まで詰めたが，開発コストの問題の一方で夜間の一括バックアップがスムースになってきたことと機械的な重大障害が事実上発生しな
くなったことから，開発は保留されたままとなっている．ところで，データの内容構成を各サブシ
ステムで分担することにしたのは，データ内容は各機能に直結すると判断したからである．プロダ
クト･モデルのコンセプトが当時既にあったとし
たら，HICADEC 全体のデータ・モデルの定義を優先したかも知れない．しかし，その是非の判断については，HICADEC を超えたより総合的な観方が必要となったであろう．

293

開発チームは，当初，従来からの開発室内に置かれたが，SMC と WT を置いた機械室が席から離れ，また，増大するチーム要員の席が分散してきたことから，フェーズ１開発ピークに備えて，社屋から離れた貸しビル一ヶ所に集中することにした．実際，ピーク時には，要求仕様，システムそれぞれの開発チームに 50 名，全体で 100 人の規模に達していた．しかし，1985~6 年（S60~61）の厳しい造船不況の中で開発コストの見直しを迫られ，やむなく HICADEC-H を除いて開発を中断ないし
HZS 商品開発に統合することとなり，開発プロジ
ェクトと共に開発チームは縮小され，貸しビルからも撤退したのである．
基本システムに適用した GRADE/G は，HZS 商品として開発されたものであるが，幾何形状を 3次元ワイヤ・フレーム・モデルで表現するとともに，図面化などビューの扱いが容易なように 2 次
元表示モデルを同時にサポートしていた．例えば，
モデル要素を指示するには，3 次元要素，2 次元要素のどちらからでも可能であった．この仕様はHICADEC にとって好都合だったのである．すなわ
ち，HICADEC の各アプリケーションは，独自の 3次元モデルをデータベースに持ちながら，
GRADE/G を共通のユーザ・インターフェースない
し図面出力基本システムとして活用できたからである．しかし，HZS のメカニカル系商品としては，サーフェス・モデルやソリッド・モデルのサポートが難しい GRADE/G のままでは不十分となり，
1990 年（H2）頃からは HICADEC 専用の基本シス

テムとして生かされてきている．
HICADEC-H では，HIZAC や HICAS-H の開発経験が活かされているが，新たな工夫として，「マル
チ・プロセス・サポート」
，
「要素図」
，
「自動修正」，「類似構造処理」，「処理標準」などがあり，また，
新たな応用機能としては，「内構設計機能」，「組立
モデルの取り扱い」，「一括部品展開」，「対話ネスティング」などがある．
「マルチ・プロセス・サポ
ート」は，データベースのマルチ・アクセス制御を活用するもので，マルチ・プロセス間で同一データ項目に関する定義･参照・変更･削除の衝突を回避する機能である．たとえば，ある設計者が定義ないし修正中のデータ項目を他の設計者が参照する場合，参照処理は，定義ないし修正処理が完了するまで自動的に待機する．勿論，待機中に参照処理の変更などの対応措置も可能である．
「要素
図」は，HICADEC-H の基本的なアーキテクチャーを支えるもので，構造定義・修正における一つの作業領域かつ表示領域である．この名称は，一つまたは複数の要素図から最終的な設計図面を構成することに由来している．すなわち，要素図は，
視線方向投影による製図機能を有している．これは，一つの全船体構造を複数の設計者が分担して設計することを前提に，定義・修正の競合を避けることのほか，
3 次元表示による直接入力は難しい
ことと，設計図の形態での情報交換・出図を効果
的にサポートできることを考慮したものである．
「自動修正」は，構造幾何のトポロジーと定義手順に基づき，構造要素に変更があった場合，その影響を受ける他の構造要素を自動的に変更するものである．しかし，参照関係による伝播のみでは，実際には影響のないものまで変更処理を行うことになるので，これを抑止するのに工夫・改良が必要であった．この機能をサポートするには，デー
タベースの内容を構造要素と定義手順の組合せで構成することがポイントになっており，この意味では，プロダクト・モデル・サポート機能の先取りであったと言えよう．
「類似構造処理」は，類似する形状の多いトランス構造の設計効率化を特に狙ったもので，自動修正の仕組みを応用し，ある
ベースとなる構造の要素図から類似する構造の要
素図を創生するものである．なお，一つの横断面
全体を一つの要素図とした時などに，類似構造が要素図の部分に限定される場合があることから，
要素図単位によらず，指定した部分毎に同様の処理が行える「部分類似構造処理」が追加された．
「処理標準」は，開口，スロット，ブラケット，ステ294ィフナなどの形状処理や開先形状に関する設計標
準のほか，図面表示規約，図面枠など設計図面に関する標準，および，ネスティングや NC 切断データ生成に関わる各種標準を総合したものである．
特に形状に関わる標準については，処理方法・条件を記述する必要がある一方，定義内容を随時視認できる必要があるので，専用の定義言語と形状シミュレーション機能が用意されている．
「内構設計機能」に関連しては，基本設計から生産設計までの垂直統合に関わる課題として，モールド形状と板厚を含む形状を一貫して如何に扱うかが基本問題であった．これについては，モールド形状の設計時点において一般に板厚情報が付加され，また，その板逃げ（向き）が意識されているはずと理解し，板厚情報を属性として扱うとともに，モールド形状表現において板逃げを考慮した板厚をデフォルトとして含めることにした．板厚のデフ
ォルト値は数ミリ以下なので，図形表示上は，特に拡大しない限り見えないものである．具体的な板厚は，ヤード設計の段階で決定されるが，それはデフォルトからの修正とみなすことにした．
「組
立モデルの取り扱い」に関しては，当初，組立形状モデルを設計の構造モデルから切離すべきかど
うか少し悩んだ．それは，設計と生産準備作業の間にある程度の独立性が必要ではないかと考えたからである．しかし，相対的な独立性のニーズはあらゆる場面にあり，これに着実に対応するためには，設計･生産の全プロセス構成を明確にして，それぞれのプロセスが担うデータの継承・世代管理をサポートする必要がある．結局，これは難しすぎると考え，構造部品と関係付けした組立ネッ
ト・ワーク（組立シーケンス・ダイヤグラム）の定義を加えるにとどめ，ブロックにいたる組立製品の 3 次元モデルは，必要に応じて生成できるようにした．この 3 次元モデルの表示はワイヤ・フ
レームによるもので，陰線処理などに苦労しながらやはり独自開発した．この独自開発の理由は，3次元モデルながら，情報を簡明にするためモールド形状を扱う必要があったこと*7，当時のソフト市
場にサーフェス・エッジを正確に描画する 3 次元
表示ツールが無かったことなどによる．なお，その後，改良されたサーフェス・モデル表示ツールを組み込み，組立モデルのほか任意の構造についてシェーディングによる表示が可能となっている．

*7

ソリッド・モデルによる表示ではデータが重過ぎると考えられていた．

とから，HICADEC-E 独自の開発を進めた．ただし，また，任意の組立データは，溶接ロボットや塗装
1985~6 年（S60~61）のプロジェクト縮小に伴い，ロボット用 CAM システムに IGES 形式で渡すこと
その後は HZS の受託として開発を継続し，一部のができる．
「一括部品展開」は，外板部品など曲り機能を除いて 1990 年（H2）に開発を終焉した．
部品の展開を含め，ブロック毎に全生産部品デー
タを一括生成するものである．生成された部品デ以上 HICADEC の開発経験について概観したが，ータは，部品図出力，ネスティングに供され，直日立造船以外に開発初期から導入を決めていたユ接の変更･修正はできない．ただし，構造の設計変ーザである北欧の一造船所から強力な支えがあっ更に伴う変更は，自動修正の中で部品毎に行われたことは，長期かつ膨大な開発を継続できた大きるようになっている．また，構造に関係のない部な要因であった．また，関係者の間で，技術規模，品を別途定義して追加することは可能であり，他
体制，コストなどの面から「このようなシステムのシステムからの部品データを変換して取り込み， の開発は，造船一，二社だけでは無理」との認識
ネスティングすることができる道も残されている． に至ったことを付け加えておきたい．
なお，板厚を考慮した部品形状データは，隣接境
７．次世代造船 CAD システムへの挑戦：
界構造との取り合いから部品の表裏で一般に食違
1995 年（H7）~い，正確な開先・削り処理に対応するため，表裏それぞれの形状を持っている．「対話ネスティン
ワーク・ステーションが登場した 1990 年（H2）グ」については，特徴的な点として，構造変更が頃から，コンピュータのダウン・サイジング，シ部品データを経由してネスティング・データに伝ステムのサーバー／クライアント・モデルが話題
わり，ネスティングの見直しなどが的確にできるになっていたが，その頃，トップから「HICADECようにしたことと，近年，遺伝的アルゴリズムのの再開発の必要性はあるか？」との質問に，「今後応用による実用的な自動ネスティングがサポート
少なくとも 10 年間は，拡張・改良で追随できる」
されたことが挙げられる．
と言い切っていた．しかし，これを反省すること
HICADEC-P は配管設計を主体にしたが，艤装設計支援機能が多岐に亙り，部分的にソフト開発を進めながらも全体の仕様開発に難渋していた．一方，HZS は，プラント・エンジニアリング向けの配管 CAD である GRADE/P の開発を別途進めていたのである．別々に開発することを選択したのは，ユーザや詳細仕様が異なるとの見方をしていたからであるが，1985~6 年（S60~61）のプロジェクト縮小策の中で，配管 CAD に的を絞って GRADE/P
開発に移管・統合することになった．ただし，造船設計標準や配管一品図など造船特有部分が残ることから，HICADEC-P の名称の使用は継続した．
運用については，系統図，機器配置図，管一品図についてスムースに定着したが，管配置図については，管一品図処理のためのバッチ入力オプショ
ンを除き，設計への時数効果に疑問が持たれ運用が遅れることになった．何があれば運用できるか，
断続的ながら長期に亙って検討された結果，1995
年（H7）までに管支柱処理機能と管配置図自動仕
上機能が追加され，また，生産管理関連の諸シス
テムとも連動されるようになって，その後は全面的運用の状況にある．
HICADEC-E は，系統図，機器配置図について
HICADEC-P に類似するが，詳細配置図，電線配置
図，電線管理，取付図などに固有の要素があるこ295になったのは間もなくのことである．まず，PC の普及によりあらゆる業務分野で情報化が促進され，「 共 有 デ ー タ ・ ベ ー ス 」 や 「 EUC （ End User
Computing）」の掛け声が姦しくなってきた．造船
では，あらゆる設計情報のデータベース化が始まり，工程計画・管理を含む CIM の充実，さらにCIM と ERP（Enterprise Resources Planning）との連携が求められるようになった．また，情報技術では，文書管理，工程管理を含む製品情報管理 PDM（Product Data Management）が流行する中で，オブジェクト指向技術の応用によるプロダクト・モデ
ルへの志向が強まり，また，COM（Component
Object Model）技術による Windows や WindowsNTが登場し，開発言語は C++や VB（Visual Basic）の時代になった．実際，身近な例として，1993 年（H5）秋，有明工場に開発スタッフを集めて教育訓練からスタートし，HICADEC の組立モデルを採り入れた組立工程シミュレーション・生産管理応用プロ
ダクト・モデル PHI（ファイ，Hitachi Zosen Product
Model）の開発が進められた［1997 年（H9）夏，完了］．最早，独自のデータベースと Fortran 言語
ベースの HICADEC が状況に適応しにくいことが明確になったと認めざるを得ない．また，
HICADEC その他の設計関連独自ソフトに関する
開発・保守体制の維持・再編がコストや人材面で難しくなってきた．しかし，造船にとってこのような情報システムは今や不可欠であり，さらに強化・発展が求められている．既存造船ソフト市場に代替案は未だなさそうであるし，規模の小さい
この市場における開発を黙して期待する状況でもない．造船 STEP は業界標準化の動きとして重要であるが，新しい情報システムの内なる仕組みへの適用には疑問である．それではどうするか，これが CIM 次世代化挑戦の出発点であり，具体的な模索が始まったのは 1995 年（H7）である．

８．おわりにCIM 次世代化に関連する経験として，一つのエピソードがあった．それは，溶接ロボットが実用化され，塗装ロボットの実用化も見え始めた頃，
造船トップからの色々な課題提示の中に，「CAD/CAM の統合を推進し，ロボットの応用を促進すべし」と言うのがあった．それまでの対応
は，CAD と CAM をそれぞれ別部隊で開発し，インターフェースのみ話合って決めてきていたが，改めて「統合」を掲げるとしたら，業務組織のあり方から誰が中心の指導責任者となれるか，疑問に思ったのである．現状，業務組織に当てはまる
立場の人はいない．強いて挙げればトップとなるが，直接の技術的指導を期待できるとは思えない．
また，インターフェース仕様が標準として根付いているなら「統合」として改めて開発することもない．さらに，CAD が不十分なまま，CAM との統合をテーマにするのも無理がある．このことから，システム・インテグレーションの本質を悟ることになったのである．これが，本節見出しに「CIM」でなく「CAD」を用いた事由の一端でもある．

何の因果か造船 CAD/CAM 開発に会社人生を捧
げ，まもなく定年となるが，悔いはない．支えてくれた顧客，会社，仲間および関係業界に感謝す
る．ただ，造船 CAD/CAM 開発が造船業と IT 業の接点で成り立つツール提供に限定されて来たことと，造船業内部で造船情報プロセス統合を主眼とする企画業務の地位確立がなお不十分なことを背景として，システム・インテグレーションへの取組が遅れていると思われるのが心残りである．

以上，日立造船における CAD 開発の歴史を主体に紹介してきたが，CAM 開発について殆ど記述できなかったことをお詫びしたい．なお，CAD/CAM
開発の歴史と趨勢は他社も大同小異と思われ，次世代としての展開では，造船技術固有ニーズとして CAM 開発努力は継続されるが，CAD 開発は，
情報共有とツール・インテグレーション，すなわ
ち，システム・インテグレーションに比重が移るであろう．

ともかく，現在はなお挑戦中であり，また，本誌面も限られているので，具体的な記述について
は将来の機会を期待したい．

296

著者プロフィール
守屋洋之助
1942 年生
岡山県倉敷市出身
最終学歴：
京都大学理学部理論物理学科
1967 年 日立造船入社
1977 年 日立造船
情報システム㈱ 転籍
1978 年 設計情報
サービス・センター長
1979 年 重機事業部造船システム部長
1988 年 造船重機システム事業部長
1994 年 日立造船出向，情報システム室技術システム担
当部長
1996 年 次世代造船システム開発海外プロジェクト出向，技術主任2000 年 同退任，嘱託