決断科学ノート－31（迷走する工場管理システム作り－5；先行する和歌山工場の苦悩－1）

　前回述べた“統一仕様”検討前後、川崎工場がスコーピング・スタディを進めている時、60年代後半から本社コンピュータで試行を重ねていた和歌山工場管理システムは、その実行予算申請最終段階で第一次石油ショックに遭遇する。当初の計画は既存工場に倍する有田工場建設を前提としていた。大掛かりな建設計画に組み込まれる設備投資は予算審査も全体計画の中で捉えられるのが通例で、経済性評価基準も緩くなりがちである。また、生産量が増えるし人員も増えることが前提となるので、経済性改善効果算出のベースが大きくなり、容易に査定基準を超えることが出来た。これらが全て石油ショックでご破算になってしまったのだ。
　既存の工場だけで出せる経済効果は半分に減じ、新たな省エネルギーや人員削減効果を更に積み上げなければならなくなる。一方、設備投資額は大幅に圧縮しなければならない。このような作業に最も重要な役割を担う、プロセス・システム・エンジニア（PSE；数理より化学技術の専門家）は、焦眉の急の既存工場の省エネ活動に投入され、止むを得ず数理・情報技術者が中心に進めることになる。本社の予算審査の要は化学工学バックグランドのエンジニアだから、なかなか歯車が噛み合わない。
　次の課題は工場用コンピュータの仕様・機種決定である。最重要条件は工場線形モデル（LP）を“効率良く”扱えることである。工場の装置群を数学モデルで表記すると数千におよぶ一次線形方程式になる。これを“早くかつ安く”解けることが必須条件なのだ。早く解くために最も効くのは主記憶装置の容量である。しかし、当時の汎用機はこの容量で価格が決定的に違ってきた（今のPCでもその傾向はあるが）。だから比較的小さな記憶容量で大きな問題を解く手法が数理技術者によって種々工夫されてきた。ただこれらの手法はそれぞれのコンピュータメーカー・機種に大きく依存した。結局、和歌山ではこのLP処理が決め手となってIBMが採用されることになった。
　本社のメイン・コンピュータもIBMだったから、それを使った試行段階からの経験・知識が生かされ、プロジェクト推進スタッフも慣れた機械なので、開発はスムーズに進む予定であった。しかし、ことはそう単純ではなかった。予算をギリギリに詰めたことから、主記憶の容量も必然的に小さくなった。IBMのSE（営業SE）と充分検討して決めた筈の仕様が甘かったのである。何とかこの問題を解決すべく、IBMはこの分野を専門にする数理SEを投入したが、結局主記憶の増設しか解決策はなかった。追加予算のために新たな経済効果をひねり出さねばならなくなったのである。後年、この時の数理SE（女性）と当時の話をすることがあった。彼女曰く「営業が全く無茶な売込みをしたんですよ」とのことだった。
　もう一つの難所はスケジューリング・システムである。既に本ノート－29でも書いたように、工場の生産管理の工夫しどころ、従って利益を左右する根源はここにある。各装置の特徴・構成を充分把握したベテラン計画員（スケジューラー）が長年その任に当たり名人芸を発揮してきた。これを数理技術者が聴き取り、プログラム化するのである。今なら人工知能技術や図形処理ツール、表計算ソフトなどを利用することになるのだが、当時はそんな道具は無い。全てプログラム言語（この場合はフォートラン）で書いていくのだ。原油の変化、配管の追加、装置の効率低下や故障なども考慮しなければならない。一度完成したものも環境変化が起こる度に修正が必要になる。原油処理、白物、黒物、ブレンディングそれぞれ分割して作った（和歌山の場合これに潤滑油も加わる）プログラムは、開発のみならず運用段階でもこまめにメンテナンス（修正）しなければならない。安定的な運用は前途遼遠、いつまでたっても日々の実用に供する形に仕上がらない。
　和歌山工場管理システムの肝は、LPを使って月次の最適生産計画を作り、スケジューリング・システムでこの月次計画を日程計画に割り振るところにある。二つの中核システム開発・定着遅延はプロジェクト全体に対する厳しい批判につながっていく。そして、それは次ぎなる課題を提起することになる。
（次回；先行する和歌山工場の苦悩－2）