前編は私がHasuraと出会うまでの経緯です。Hasuraの話は碌に出てきません。悪しからず。
今在籍中の会社で、提携先の工場の在庫管理を一任されている。一人でやらされている、とも言う。
（ちなみにメインの仕事はウェブエンジニアである）
ソフトの開発だけでなく、ハードも作って売る会社なので、基板があと何枚とか、部品があと何個とかそういう情報が大切なのである。
さもなくば、発注受けて工場に製造依頼出したはいいけど、工場側から「基板もケースもないから送ってくれたら製造しますね」とか言われて、やばい納期２週間って言っちゃったのに全く間に合わない！とかそういうことになるのである。
ちなみに工場と言うと大きな建屋にでかい工作機械が並ぶイメージだが、実際には小口の製造受託をやってくれる小規模の会社に頼んでいるので、在庫管理はピッってやって自動です！とかはなく、少なくなってきたら人力で数えて教えてくれる感じなので、数十とか百単位の大口の注文が入って製造かけたりすると、そこで始めて足りない部品が分かっててんやわんやになったりする。
そこで、在庫管理は基本的にこちらで行い、製造依頼を出すたびに使った部品の在庫記録を減らしていく、という形を取っている。
これまでは在庫管理をExcelで行っていた。
部品ごとに在庫数の欄があり、例えばAという製品を作るのに、部品a,b,cが必要なら、A×5個の依頼を出した時は、a,b,cそれぞれから5引いていく、という形を取っていた。
在庫管理Excelのイメージ↓（在庫数は数字直書き）
部品名 在庫数 A用基板 34 A用筐体 4 B用基板 2 B用筐体 0 単4電池 68 （たとえば製品Aを製造したら、使用部品であるA用基板・A用筐体・単4電池の在庫数を1つずつ減らしていく）
最初はメインの製品は4種類くらいで部品点数も少なく、これで問題なかった。
ところが製品はどんどんと増え、バリエーションも増え、部品点数も増え、いくつかの製品で共通の部品も増えていった結果、色々と問題が出てきて破綻した。
まず、製品と部品の対応表が私の頭の中にしかなかったのが問題だった。
覚えていたから記録しなかったというのもあるが、製品が増えたり使う部品が変わったりということが頻繁にあったので、メンテしきれなかった。
ただ、覚えている、ということといつでも100%思い出せる、というのはイコールではなく、たまに一部の部品の在庫数を減らし忘れて、あとで整合が取れなかったということが何回かあった。
次に、製造に使った全ての部品の欄を書き換えていくという作業が負担でしかなかった。
製造依頼1回ごとにExcelを書き換えていければまだマシだったが、在庫管理に回せる時間は少なかったため、何回かの製造後にまとめて数を書き換えていた。
すると、この部品は製造①と製造②で共通して使ってるから合わせて何個減らして……と、どんどんと時間がかかるようになり、結果、大きく時間が空いているときにしかできなくなり、その間にも書き換えタスクはどんどんと溜まっていき、時間がかかる一方となる負のスパイラルに陥ってしまったのである。
これではいかん、となって最初に思い描いたのはExcelの改善である。
そもそも記憶頼りに部品を一つ一つ管理しているから大変なのであって、部品表付きの製品マスタを作成して、製品の製造数を書いたら部品数が自動で減るような仕組みを作れば、そんなに大変ではないはず。
ただ、それをやるには重大な問題が一つあった。
私のExcelのスキル不足である。
VLOOKUPですらググりながらじゃないとまともに書けない私にとって、製品マスタを参照して全ての使用部品を取得するなんて、やり方すら想像がつかない。
一応「在庫管理 Excel」などでググってみたものの、目ぼしい情報は得られなかったので、Excelでなんとかする方法は一旦保留して、他の案を探した。
やはりフルスタックエンジニア(笑)たるものRDBが裏で動いてるブラウザで触れる在庫管理システムを作りたい。
ただ、そんなシステムを作るとなると、どれだけ小規模なものでもDB・サーバー・フロントの３点セットが必要で、構築に結構な時間がかかるのは必至。
正直会社のビジネスの根幹でもない在庫の管理のために「在庫管理システム」なんて大層な代物を時間をかけて作ってる暇ないのである。他にやるべきタスクはいっぱいあるのに。
そんなとき、OpenBOMというサービスと出会う。
（Hasuraいつ出てくるんだよ）
部品表=BOM（Bill Of Materials）とは製品を組み立てるのに必要な部品の一覧のことである。
「OpenBOM」はそんなBOMや部品の管理をするためのクラウドサービスで、部品の在庫数も記録することができ、まさにうってつけのシステムだった。
OpenBOMには無料で使えるプランもあると知り、飛び込むように登録。
触ってみた感想は「素晴らしい」。
まずBOMを作成し、Excelライクなテーブルに構成部品を追加していく。
このとき追加した部品は、初めて登録するものだった場合は勝手に部品マスタが作成され、別のBOMでも使用することができる。
部品には画像を登録できたりして、あとで把握するのも楽そう。
ただ残念ながら、結果的に無料プランでは在庫管理は困難であった。
部品ごとの在庫数の記録は無料プランでも出来るが、生産計画として生産する製品の個数を登録して、そこから在庫数を反映したりするには有料のプランが必要だった。
一応Excelで事足りてる業務に、月額55ドルの予算を請求することは難しい。（一から説明して予算を打診するのが面倒だったともいう）
こうしてBOMによる製品管理や、生産計画と在庫数が連動するシステムの素晴らしさを体験したものの、ひとまずExcelでの管理に帰っていったのである。
ここまで2000文字くらい書いたが、やっとHasuraの話である。
ある日、私は性懲りもなく在庫管理システムを作る手だてを考えてGoogle先生にお伺いを立てていた。
しょうがないので手製でシステムを作ることに否やはない。
クライアント側を作るのも構わない。デザインセンスはないが、ほとんど自分用のシステムだし、ReactとMaterialUIを使えばある程度楽に作れる。
DBを作るのも構わない。出来ればDBも楽に作りたいが、それは贅沢といふもの。
ただしサーバー、テメーはダメだ。
在庫管理のようなシステム、それも小規模なものにおいて、サーバーはフロントとDBを繋ぐだけの存在。
できればクライアントJavaScriptで生SQL作ってDBに直接渡したいくらいである。
セキュリティ的にそんなことダメ、ゼッタイであるので、せめてDBのスキーマからCRUDのAPIを自動生成してくれるようなツールはないものかとGoogleに「CRUD API 自動生成」なんて自堕落なキーワードを打ち込んだ。
これがHasuraとの出会いであった。
つづく。