#12 - タブーと呼ばれた使い方への挑戦

　グループウェアが大ブームになっていた頃の話です。日本では、Lotus Notesというソフトウェアが人気を博していました。グループウェアといえば、複数の人が同時にアクセスして文書を作ったり、承認処理をするためのワークフローを流すのに便利なものであり、主として総務系の処理である交通費精算や出張申請などの処理や開発者同士の意見交換のコミュニティの提供や、論文などを集める場所などで広く利用されていました。Lotus Notesはのちにサーバー機能の方をLotus Dominoと名前を変えることになりますが、当時はまだLotus Notesだったので、この文書内では、Lotus Notesまたは単にNotesと表記することにします。

　まだ、スマホが登場する前、いわゆるガラケーが世を席巻していた時の経験です。携帯を製造するお客様のラインは、5-6人程度の組立担当者が製造ラインの横に並び、流れてくる携帯のボディに対し部品を組み込み、最終的に製品に仕上げるというものでした。全てを機械化できなかった当時の理由としては、携帯の形の変化や仕様の向上の競争が激しく、短いインターバルで形状が変更する携帯の組み立ては自動化では逆にコストがかかり、とても対応できないというのが実際の理由でした。つまり、人海戦術のほうが柔軟に対応できる上、品質も良かったということです。やはり、人間の対応能力の方が優れていた時代だったということですね。

　一方、私がいた会社内では、Lotus Notesをグループウェア製品として強力にプロモーションしていました。基幹業務には対応できないけれど、オフィス業務の効率化には大きく力を発揮するソフトウェアとして売り出していました。確かに文書管理のパッケージなので基幹業務には向いていないだろうと思いましたが、無理だと言われるとなんとか突破口を見つけたいと思うのもSEではないでしょうか。

　いろいろと思案を巡らせていて閃いたのが、全くLotus Notesに向かない代表格として定義されていた業務である「在庫管理」の一部をLotus Notesで実現できれば常識を覆せると考え、挑戦してみることを決めました。なぜ、在庫管理はNotesに向いていないかというと、入出庫を同時に実施する可能性があるトランザクション処理であるからです。同一データに対して複数のアクセスが同時に発生するとNotesは、「競合文書」という形で複数のデータに分割してしまう仕様になっていたのです。これは文書管理においては便利な機能であり、もし、3人が同時に同じ文書に対し変更を加えたら、最後の更新が表面的に表示され、残りの2文書は「競合文書」として同時に保存されるので、3人はそれぞれの内容を把握することが可能になり、必要であれば正しい文書を再選択することも可能になるわけです。しかし、数値情報を更新するような通常の業務においてはこれは致命的な機能ということになります。従って、定型業務には向かないという結論になる訳です。

　私は、「じゃあ、入庫と出庫を分けてしまえば処理がぶつかることもないし、Notesでも十分実現できるかもしれない」と考えてみました。これを実現することができれば論文もかけそうだという思いも少しありました。その後お客様と業務確認を実施し、部品の入庫処理から在庫DBへの登録業務、現品の棚卸し処理、翌日生産のための部品の引き当てなどの業務を整理しました。入庫処理はもちろんリアルタイム処理でした。

　一般的に在庫を管理する際は在庫管理DBを一つ準備しアプリケーションからアクセスさせますが、これを、入庫用在庫DBと出庫用在庫DBの二つに分離して物理的に違うDBで実現できれば、デッドロックは発生しないし、在庫量としてもわかりやすいのではないかと考えました。その理由として、受入処理をして入庫処理された部品は、その日の生産工程で利用されることはないということが解っていたからです。当日生産分は既に必要部品が在庫から引き当てられて準備されるのが普通であり、直前に納品される部品をあてにした生産計画は作られません。つまり、入庫される部品と出庫される部品は利用するタイミングが異なるので、物理的に違うものと考えて差し支えないということです。

　入庫の処理は、部品の受け入れ部門があり、一括して処理されます。ここで受け入れして検収された部品を所定の位置に格納したら、入庫用の在庫DBに加算されるようにする訳です。それとは逆に出庫の処理は、部品をピッングした際に出庫用の在庫から減算するだけになる訳です。このことにより、同じ部品に対して、加減算が発生することはありません。

　入庫された部品は、夜間バッチ処理の最初の処理で出庫用DBに移動してしまえば、翌日生産用の部品を引き当てることが可能になるとともに、処理自体もわかりやすくなります。入庫用在庫DBから出庫用在庫DBへの反映はわずかな時間で処理できるので、特に問題になることはありませんでした。もちろん、最終的な器としてはデータベースが望ましいのは変わらないので、メインフレーム内のアプリケーションが処理するRDBと入出庫処理を実施するNotes DB(入庫用と出庫用)をメッセージング・ソフトを使って連携するように設計しました。在庫DBの分散配置を実施した訳です。Notesを利用したことで、開発期間を大きく短縮できたことも利点の一つでした。そして、私のスキルアップとともに論文作成の目標も達成できました。

　常識だと思っていても考え方を変えればより良い方法が見つかることもあります。新しいことを試したいと思ったら、業務にどれだけ有用かということや限られたリソースで実現する最短コースになり得るか、作成した後の保守は容易にできるかなどを検討することが近道だと思います。この時の経験を元に作成した社内論文では優秀賞をとることができ、社内での発表に加え、ハワイで実施されたコンベンションにも参加することができました。忘れられない記憶です。