ITエンジニアの仕事をすると障害はつきものです。
障害は情報セキュリティの３要素である、機密性、完全性、可用性 のいずれかが、確保できない状態だと捉えられます。
なかでもダントツに多いのが、可用性の事故です。
可用性とは許可された者が、必要な時に必要な情報にアクセスできることを確実にすることです。
可用性を損ねる要因として多いのは、ネットワークの不調やサーバー機器のリソース不足など、インフラに起因したものがほとんどです。これらは突発的に起きることもありますが、システムの稼働当初から起きることも多くあります。本当はシステムを構築する段階で、可用性に関わる検証をしておくのが望ましいのですが、実際はそういう工程を経るプロジェクトは少ないと思います。
わたしが構築したシステムではじめて障害を起こしたのは、入社二年目の 1992年 です。それ以降も、直接的、間接的に関わらず、何度も障害を経験してますが、やはりはじめての障害は記憶に残ります。
このときは、食料品の生産管理に関わるシステムの設計や開発をしてました。
その一環で「工場の棚卸業務」を効率化する目的でシステムを作りました。
システムの内容を簡単に書くと、工場で原料、半製品、製品の数量をカウントするのに必要なアイテムと理論在庫のデータを数台のハンディターミナルに移植します。工員さんは製造作業終了後、在庫保管場所単位に振り分けたバーコード表と、ハンディターミナルを抱えて、在庫保管の現場ごとに対象アイテムの数量をカウントします。生産管理の担当者は工員から集めたハンディターミナルを読み取り、棚卸の集計を行います。理論在庫と実地棚卸在庫の差異が著しくかい離してないかを確認して、本社のシステムに伝送する仕組みです。
このシステムを設計する際、課題だと思ったのは、ファントム品の扱いでした。
ファントム品は、製造工程のなかで生産される一種の半製品ですが、在庫管理の対象外となるアイテムです。ファントムが起きるのは、BOMと呼ばれる製造を管理するための図表と、製造工程の差異からです。
BOMは下図のような、製品を完成させるのに必要な原料や半製品、包材を集めてます。BOMとして表れているアイテムは、在庫管理の対象です。主に製品を完成させるのに必要となる原材料所要量計算（MRP）に使用されます。
BOMは生産管理の中枢となるマスタです。ただ、メンテナンスは煩雑です。
一方、製造はラインで組み立てられるので、製造の中でBOMに現れないアイテムが発生しえます（下図）。これがファントム品です。
もちろん、ファントム品を半製品の在庫管理品目として、BOMに入れることは可能です。しかし、その分 BOMの構成が複雑になり、メンテナンスに負担がかかります。ファントムを入れることで、BOMが多段階の構成になることで、MRPの計算処理に時間もかかります。
棚卸に際しては、製造ライン上に少なからずファントム品があるのですが、これらは原料や包材に分解して在庫をカウントします。
棚卸作業は全体として、単純作業ですが、ファントム品の数量分解は手間のかかる仕事です。食料品の生産では、原材料によって在庫で扱う単位が異なります。重さで管理する原料と、容量で管理する原料を配合して、個で管理するアイテムになるような例です。数量分解は単位変換を伴うので、その分手間が増えます。
ファントム品の分解を自動化すれば、効率的だと考え、プログラムを作りました。
しかし、いざ本番稼働すると、ことのほか、分解処理に時間がかかりました。
プログラムのテストでは数アイテムのパターンで、処理がうまくいくことを確認しました。しかし、実際に製造現場で扱うアイテムは数万に及びます。入社二年目のわたしには、本番環境を想定した負荷テストを行うという意識がありませんでした。
ファントム品を分解する計算処理に８時間かかる状況が起きました。これだとベテランの生産管理担当者の神わざ計算の方がずっと早いです。
プログラムの見直しで改善しようと試みましたが、CPUの性能も貧弱だったので、大した改善は出来ませんでした。
実は棚卸のシステムを開発するもう一つの目的として、「リレーショナルデータベースを使ったシステムを開発する」というのがありました。
リレーショナルデータベース（RDB）は、項目となる列と、データレコードの行で構成される表にデータを格納する仕組みです。SQL言語を利用し、自由な形式でデータベースを扱えるものです。いまでは当たり前に使われるデータベース管理の仕組みですが、1992年に於いてはまだ新しい領域でした。
RDBのデメリットとしてよく挙げられるのが、データ量が膨大になることで処理速度が遅くなることです。部門でRDBのシステムを取り扱っていなかったことで、先輩の知見を仰ぐことも困難でした。
結局、ファントムの分解処理は取りやめました。
