【短編小説】箱の中身を読み解く日々。データと心の交差点

ここは中堅玩具メーカーの情報システム部。

私は、新卒で入ってすぐ、情報システム部に配属になった。コンピュータやシステムに詳しかったわけじゃない。今年の新卒入社は5名。他の4名は、専門領域を持った人ばかりだ。

弁理士資格を持っていて、すでに法務部門への配属が決まっていた女性。
機械、電子の専門に強く、商品開発部門への配属が決まっていた男性が2名。もう一人は、地方採用というわけでもないが、子会社の工場長の息子で子会社工場の創業者の親族だ。最初から工場勤務が決まっていた。何の特技も、専門領域がない新卒は、私だけだった。

今年は採用に力を入れていて、採用予定は10名だったらしいが、もっと大手の企業に採用が決まった6名が辞退。私は、辞退した人のさらに補欠だった。ずっと人が足りないと数年声を上げ続けてきた情報システム部に配属することが入社の前から決まっていたそうだ。一か月の研修の後、僕は、情報システム部に入り、ここ半年、ずっと同じ作業をしている。

MRP（Material Requirements Planning）の検証作業だ。受注計画、部品の構成情報、在庫情報、工程の経路情報などをインプット情報として、生産の各工程で必要な部品数を算出するプログラムのことだ。プログラムは、複雑なロジックらしく、大手のシステム開発会社が提供したものを使っている。MRPは、うちの会社以外にも、さまざまな製造業、工場で使われていて、処理の内容はブラックボックスになっている。特殊なロジックで、計算されているそうだ。

この計算がうまくいかないと、工程に過剰な在庫が溜まることになるし、他社で生産してもらう部品生産依頼のタイミングも変わってくる。無駄な在庫を持たず、ちょうど生産をするタイミングで、工程に部品が到着するのがベストだ。プログラム自体は、研究を重ね、さらに無駄の少ない、適切な在庫量で済むようなロジックを継続して研究開発しているそうだ。時々、その研究成果が反映され、見つかった不具合を改修したバージョンがリリースされる。だが、提供されたままに、新しいバージョンに変更すると、とんでもないことが起きる。

すべての製品の生産が早まってくれればいいが、これまで3日で生産できていたものが、ロジックの変更で7日と計算されることもある。これまでのバージョンでは不具合が見つからなかったのに、新バージョンでは、正しいロジックになったことで、今あるデータの不正が見つかることもある。

部品情報は、ある部品とそれを構成する子部品を登録している。Aという部品を作る材料がBとCであれば、Aの子部品にBとCを登録する。Cの部品がさらに、D、E、Fで構成されているといった場合は、Cを親部品として、D、E、Fを子部品として登録する。

簡単に問題になったケースを説明すると、Cの部品に、DとEとAの3つの部品を登録していた。これまで製品Aの計算をする時、エラーは出なかったが、孫部品に同じAが入っていることで、新バージョンではエラーになった。

計算ロジックに孫部品情報を使う時（正確にはひ孫部品だったのだが）、そこに自分がいるために計算結果が算出されない事態が発生した。そんな部品はないだろうと思われるかもしれない。Aは玩具用の塗料で、途中の工程で追加することがあるのだ。この場合、登録上、製品であるものは塗料はA、部品で使う塗料は、A´と名前を変えて登録することで回避した。

MRPがバージョンアップされる時には、いい結果ばかり起きるわけではない。他社にとって適切な計算をされることになっても、うちにとっては適切なロジックとは限らない。

だから、同じ製品を作り続けている工場では、同じMRPを10年、20年、長いところでは30年使っているところもあると聞く。プログラムの利用料を払いたくない理由もあるだろうが、実際に、どんなロジックをもってきても、今利用しているMRPの計算結果と大差がないから変更する理由がないのだ。

うちでは、他社も利用しているMRPを使うので、新バージョンがリリースされる前に、新バージョンと現バージョンのMRPに本番データを投入して、結果を比較する。検証は、新バージョンの利用可否を決めるまで（利用しない場合は、次期のバージョンまで同じバージョンを使う）、ずっと続けられる。主に、生産量が多く、種類も多い毎月中旬の本番データを使って検証することが多い。半年間、毎月、生産量が多い日の本番データを取得して、それをもとに検証を行う。時間ばかりかかって、自分の仕事もできなくなるので、誰もやりたがらなかった仕事だが、僕はこの仕事が結構好きだ。

朝は、前日に検証用に流した現バージョン、新バージョンの出力結果の差分を確認することから始まる。おかしなデータ、特に生産量が大きく、全体への影響が大きい差分を確認して、なぜそのデータができたのか推測する。データの不正なのか、ロジックが変わったせいなのか？　どういうロジックが組み込まれたのか、あるいはロジックの条件が変わったのか、別のロジックが採用されたのか。経路や部品構成に特徴を見つけて、当たりをつける。

検討した理由の通りかどうか、一番簡単なデータを作成して、新MRPで実行して結果を確認する。検討した内容が正しいことのほうが少ない。それを一日に何度も繰り返すのだ。

夕方までその作業を続けることになる。問題の原因を特定した場合、これじゃうちは使えません。回避方法か、バージョン内での対応をお願いできますか？　とシステム開発会社の開発者にメールする。

僕以外の情報システム部門の人間はとても忙しい。
いつも工場からのクレーム対応をしている人もいれば、生産が今よりもっとうまくいく施策、品質を向上するための施策を立てて、一日中、システム改善を検討するミーティングに参加している人もいる。問題が発生して、生産計画通りにいかない時は、当初の売上計画を達成できなくなることになるわけだから、定時後だろうが、原因を調べ、対応を考える人たちばかりだ。

僕は、その横で、ひたすらにMRPの検証と推測を繰り返している。定時に作業を終えて、問題となりそうなデータを一通りつっこんで、MRPの処理を実行して帰宅するのだ。

みんながやりたがらないこの作業が僕はとても好きだ。パズルを解くようなおもしろさもあるし、すごく考えられたロジックの一端を知ることができる。博士号を持ったような素晴らしいシステム開発会社のエンジニアとのやりとりも楽しい。そして、定時で帰っても文句を言われない。おかげで就活中に知り合った彼女とも週に3日は会える。

そんな彼女にある時、前触れなく機嫌が悪くなる日に気づいた。最初は気にするほどでもなかったが、夏ごろから極端に機嫌が悪い日も出てきた。最初、気づいた時に「どうしたの？」「べつに」というやりとりをしてから、それ以降、理由も聞かなくなった。

入力のパラメータは毎日違うけれど、人の行動原理、思考パターンはそんなに変わることがない。毎日、中身のロジックがわからないプログラムを相手にしているのだ。

機嫌が悪かった日、よかった日、その日と前日に起きた出来事を記録につけるようにした。仕事よりもずっと、パラメータの数は多い。天気、前日の彼女の気分、LINEのやりとり回数、当日のニュース、彼女が見ているドラマの予告内容、会話に出てきたちょっとしたことをメモるようにした。そして、メモをつけだして3ケ月、ようやく原因がわかった。

今日は絶対に機嫌がいいはずだ。

今、速報では、8回表、巨人が5点差で勝っている。

以前、スポーツ観戦の話になった時、「プロ野球は？」「お父さんが巨人が好き」って言ってたのを聞いてから、野球の結果もメモするようになった。会った時間帯の試合の回数と両チームの得点、首位とのゲーム差も記録した。

今日は、時々行くバーのマスターに、スペシャルなカクテルを用意してもらっておこう。

ようやく答え合わせができそうだ。

先に一杯、会社近くの立ち飲み屋で飲んで、バーに電話しようとした時、速報を見ると、9回裏に5点差がひっくりかえって同点になっていた。

スペシャルなカクテルは無しだ。検証結果の確認はまたの機会になってしまった。はぁ…　たぶん合ってる自信があるだけに、今日は会うのがとても憂鬱だ。