何か作れと言われたので在庫管理システムを作った（その２）

Last updated at 2026-06-13Posted at 2026-06-03

前回の続きです

E2Eテストで激突した現実と、講師にガチで諭された話」

「テスト」という未知の領域への挑戦
それなりに自分では「いいシステムができた」と思っていた。
しかし、これまでは手動でポチポチ触っていただけで、いわゆる「テスト」というものを一切していなかった。一度ちゃんとやってみようと思い、お馴染みのChatGPTに相談してみた。

すると、「E2E（End to End）テスト」という、ブラウザの動きを自動でシミュレートしてテストする手法があるらしい。

「なら、それをやってみよう！」と、軽い気持ちで導入してみた。

画面がフリーズしているわけでもないのに、何が悪いんだ？
不思議に思ってAIに相談し、返ってきたデータを見て目を疑った。

「在庫：−100個」

……マイナス100？
物理的な商品を取り扱う在庫管理システムにおいて、マイナス100なんていう在庫はこの世に存在しない。完全にシステム上のバグだった。

「そうだ、SQLを入れよう」で無理やりクリア
データのバリデーションがガバガバだったのもあるが、ここで私は気づいた。
「そういえば、データ管理をずっとJSONファイルだけでやってたな。SQLを使ってなかったなぁ」

よし、データベースを導入してデータをちゃんと管理させよう。そう思い立ち、AIの力を借りてシステムにSQLを組み込んだ。
SQLを導入したことでデータ管理の仕組みを見直し、
在庫数に対する制約や入力チェックも追加した。

おかげであれだけ引っかかっていたE2Eテストもすべて綺麗に合格と相成った。めでたしめでたし。

「あーおわった」
テストの自動化もクリアし、私はまた一つ壁を越えたと満足していた。

プログラミングスクール講師の、重い一言
この成果を引っ提げて、プログラミングスクールの講師に色々と相談してみた。
IT転職では、成果物は必須なのは言うまでもないので講師に相談した。

「どうやってマイナスになるバグを解決したの？」
「JSONではデータ管理が安定しなかったので、SQLを導入し、入力制御やデータ管理の仕組みを見直して解決しました！」

ドヤ顔の私に、講師から返ってきたのは褒め言葉ではなく、注意であった。

「ウォーターフォール開発では、初期に決めた設計書（方針）から開発途中でブレてしまうのは良くない。今回は自作の個人開発だから大きな問題にならなかっただけだよ」

「SQLを入れるという判断は、一番最初の設計時点で決めておくべきこと。もし最初にJSONでやると決めたなら、最後までJSONの中で解決すべきだったね。つまりマイナス100がでたら、それをjson内で解決すべき
設計を途中で変えるなら、その影響範囲まで考えないといけない」

アジャイル開発がもてはやされているが、大規模な案件では未だにウォーターフォールが今なお中心なのはこういうことなのか・・・・？

テスト合格の裏にある「前提」と、未経験の壁
うーん、そういうことか……。
「テストをクリアする」というのは大前提として大事なことだけど、そこに至るまでの「設計思想」という前提を踏みにじっては意味がないのかな・・・・・

力技で解決はしたけれど、開発プロセスとしては問題だらけだったらしい。

実務経験が少ない私だが、今回の経験を通じて、目先のバグ修正だけでなく、設計全体を見る視点の重要性を実感した。実務ではこうした視点が求められるのだろうと感じた。

とはいえ、実際に手を動かして痛い目を見たからこそ得られた、最高の経験値だ。この失敗は次に活かせばいい。

実は、作れと言われて作ったソフトはこれだけではない。次回以降も、何本か作ったシステムがあるので、そのあたりの泥臭いエピソードをアップしていこうと思います。