戦う_ソフトウェア_エンジニア

【小説】戦う!ソフトウェア・エンジニア

『盤下の敵』(2)

●トロール来襲

現場の接続図はこうだった。

取引先の全社ERP(エンタープライズ・リソース・プランニング)から、当月の生産指示が各工場に割り当てられる。
当然、ERPの指示はもっと上位の指示であるため、今回の問題の範囲外だと考えられた。

問題はその後だった。

弊社が提供した生産管理システムからそれぞれの現場機器に対して生産計画をダウンロードする。

必要な部材を各印刷工程に搬送するのは「部材供給システム」の役目。

これは自動倉庫を扱う搬送管理と、在庫管理(材料在庫がどれだけあるか、仕掛品はどれだけか、ライン上にどれだけ部材が流れているかを管理)が担当する。

自動倉庫側にも自立して動くシステムが搭載されていて、搬送台車をコントロールしたり、自動倉庫内の内部の棚状態やロケーション管理自体は自動倉庫システムを作った別会社の管理システムが担当してくれている。

よって、我々側としては、

・何を
・いつ
・どこからどこに
・どれくらいの量

を「運んでくれ」と部材供給システムに指示を出せば倉庫側から必要な量の部材がそれぞれのラインに搬送される仕組みだった。

製造管理は、在庫量と生産計画を付け合わせ、印刷装置(印刷機が複数台あっても、各印刷機に対して細かい配分はしない)に対して「今日の生産計画はこれだけ」という指示を出す。
これが「製造指図」と呼ばれる。

その先が工程管理の仕事である。

各ラインに合わせて、必要な部材の量を割り振り、スケジュールを計画し、分単位・秒単位の指示を作成し、印刷装置へと送る。

今回のラインでは印刷機が複数あるが、カラー印刷や大判印刷など、印刷機で性能が異なるのでそれぞれの印刷機に合わせて指示を出す必要がある。
これが「工程指図」である。

装置が詰まってしまわないように、タイミングと必要な部材が間欠しないことが重要だった。

出来上がった印刷物は製本機に集められ製本されて、梱包工程に送られる。

梱包工程では製本された本を一定数束ねて梱包し、必要な在庫置き場に送ったり、そのまま発送場へ送付したりする。

この工場では梱包後は自動台車は使わない。人間が端末から必要な処置を読み取って、バーコードラベルを印刷してから、ダンボールに貼り付けて、発送場から発送するのだ。

各装置を繋ぐ通信ラインは装置ごとにバラバラで、RS485RS232Cといったアナログな通信がメインだった。

現在のようなイーサネットによる通信が整備された時代とはまったく違い、工場中にアナログな通信線が張り巡らされている。
(つまり、4-20通信だ)

その通信の一切を私が担当していたのだ。

Tが設備図を見ながら語り出す。

T:「全社ERPと生産管理データベース側のマスタデータに問題はなかったから、ここから先が問題なんだよなぁ」
私:「最初は部材供給システム側への指示ミスかと思ったけど、それだけじゃ説明できないしなぁ。うーん、困った」

そうなのである。

最初に報告された問題は

「部材供給側が送り出した部材量が、印刷機Bで受け取るはずだった必要量と合っていない」

というもの。

障害がこれだけなら、いくつかの障害原因の候補が考えられる。

1. 製造管理で指示した「製造指図」の「部材の量」と「生産数」が合っていない。
2. 工程管理で指示した「工程指図」の「各印刷機への生産数」と「各印刷機に渡されるはずの部材の量」が合っていない。

である。1が原因でも2が原因でも最初の障害の原因にはなりうる。

しかし、今一歩詰めができていないのである。

印刷機AとBは高速だがモノクロ印刷用にセットアップされていた。印刷機Cは低速だがカラーが印刷できる。

今回、差し込み用のカラーは印刷機Cに送り、通常印刷はAとBに送られた。

さて、生産数自体に増減があった場合は、A、B、C全部への指示が狂うはずだった。

T:「今回は単純増刷だから、個別指示じゃない。全部に同じ数量分分配される指図だった。これだと多くても少なくても全機がストップするもんな」
私:「そうだよなぁ。現場で収集してもらったログが正しいとすると、製造指図に指図ミスはない」

ということで、製造管理側へ追求は一旦ストップする。

工程管理のログを見て見ても

私:「なぜ印刷機Bだけなんだろう?ここへの指示が10分の1なんだよ。」
T:「分配する処理って、単なるfor文でのループ処理かい?」

for文とは、プログラムを記述するときに一定回数ループ(繰り返し)処理をしたい場合に用いられる文法である。

よくループ回数を間違えてデータ無しのパケットを生成したり、データが十分に送れなかったことはあった。

しかし、今回は同じループを回した「部材」の処理は正常で、「生産数」の処理のうち「指示の一つのデータが10分の1」だったのだ。

T:「まさに”神隠し”だな」

私は不謹慎にも笑ってしまった。

勝手に10分の1にする神様って何?そんな神様は要らない、と。

やめてくれよ、こんな深夜に冗談は、、、と思っていたとき

「おい、なんだ、やけに楽しそうじゃないか!」

と、背後から突然に声がしたのだ。

私もTも心臓が非常停止するかと思った。
(いや、非常の場合こそ停止してもらっては困るが)

真っ暗な廊下から得体の知れない物体…がこちらを凝視していたのだ。

と、トロール???

「おいおい、何だよ。俺がそんなにバケモンに見えるか?」

それは、私たちの方にズカズカと歩み寄ってきた。

T:「な、なんだ。F主任じゃないですか、脅かさないでくださいよ。今、俺たち弱ってるんで、ちょっとした衝撃で死んじゃいますよ」

そう。入ってきたのは我々第3課のF主任だった。

トロールとか言って(口に出してはいない)悪いとは思ったが、F主任の風体はネアンデルタール人かトロールだった。
巨人でいかにも屈強そう。
学生の頃は卓球部だと言っていたが、絶対にレスリング部の間違いだろう。
筋肉量はきっと我々の倍以上はあるに違いない。
どう見てもソフトウェア・エンジニアには見えない。

人を見かけで判断しては駄目だという良い見本だ。

F主任は我々の方に近寄ってきて、ふんと言った感じで言った。

F:「バカ言ってんじゃねえ。そんくらいで人が死ぬか。いいか!勝手に死ぬなよ。その前に俺が冥土に送ってやるから」
私、T:「(ちょ、冗談になってませんって!)・・・」

主任は我々の目の前にドカッと座り、設備図やソースコードの紙の束を見つめながら、言った。

F:「どうだ?そろそろ堂々巡りにハマりこんでる頃じゃないか?」

まさにそうだ。これは堂々巡りだ。

私もTも2年目社員。そんな社員が作ったプログラムが製品になっている。こんなヒヨッ子が作ったプログラムをヒヨッ子だけで追いかけている。

知識も経験も中途半端なのに、職場は慢性的な人手不足なので支援はほとんどなかった。

地獄絵図のソフトウェア版だ。

主任は我々の疲労度を感じ取ってか、心配になって様子を見にきたらしい。

F:「おい。人間はなぁ、そんなに長期間集中できないもんだ。そら、行くぞ!」

我々がキョトンとしていると。

F:「もう、電車もバスもない。俺が車で来たから、近くのファミレスまで連れてってやる。どうせロクなもん食ってないだろ」

ああ、神様!(トロールから異例の昇格)

F:「で、食ったらな、戻ってきて仕事をするんだぞ」

なんだよ!この悪魔(わずか数秒で降格)

(つづく)




ソフトウェア・エンジニアを40年以上やってます。 「Botを作りたいけど敷居が高い」と思われている方にも「わかる」「できる」を感じてもらえるように頑張ります。 よろしくお願い致します。