私「材料がどこに何個あるか見られたら便利じゃん。」
A「まあ、普通だね。」
私「だから最初は在庫。」
A「で、プログラミング分からないのに、どうやって作ったの？」
私「AIに『こういうの作りたい』って伝えて、出てきたものを動かしてみる。」
A「動かなかったら？」
私「『これ何？』ってエラーをAIに貼る。」
A「AI開発って聞いてたけど、かなり人力じゃん（笑）」
私「最初はね。」
A「AIと初心者でエラーをキャッチボールしてたの？」
私「だいたいそんな感じ。」
B「やっていること自体はデバッグですね。エラーや実行結果から原因を探して、修正して、もう一度確認する。」
私「当時は『デバッグしてる』なんて思ってないよ。『赤いの出た。直して』だから。」
A「急にデバッグが原始的になった（笑）」
最初に欲しかったのは、会社に何が何個あるか見えること。
ところが、作り始めてすぐ疑問が出ました。
私「例えば材料が10個あるじゃん。」
A「うん。」
私「でも明日誰かが8個使う予定だったら、『在庫10個あります』だけだと変じゃない？」
A「……もう始まった。」
私「何が？」
A「『こっちの方が便利じゃん』。」
私「実際に自由に使えるの2個じゃん。」
A「使う側から見ればね。」
私「だから、総在庫と予約されてる在庫と、実際に使える在庫を分けた。」
つまり、
総在庫（10）：実物として存在する数量
予約在庫（8）：すでに使用予定として押さえられている数量
有効在庫（2）：今、自由に使える数量
です。
B「それは在庫引当ですね。物理的には存在していても、すでに用途が決まっている数量を確保して、利用可能な数量と分ける考え方です。」
私「当時はそんな名前知らないよ。『予約してる分は他の人が使えないでしょ』ってだけ。」
A「名前知らないまま在庫引当始めたの？（笑）」
私「だって、10個あるって表示されてるのに8個予約済みなら、使えるの2個でしょ。」
A「考え方だけ先に実装して、技術用語が後から追いかけてきてる（笑）」
そうすると、当然、予約するときにも数量が必要になります。いつ使うのか。何個使うのか。この頃の在庫予約は、まだそれくらいの単純なものです。
さらに、こんなことも考えました。
在庫が10個ある。でも、どうしても11個必要。
A「足りないね。」
私「普通なら予約できない。」
A「そうだね。」
私「でも会社によっては、それでも先に予約だけ入れたい場合あるんじゃない？」
A「在庫足りないのに？」
私「後から入ってくる予定が分かってるとか。」
A「ああ。」
そこで、マイナス在庫を許可するかどうかも設定できるようにしました。
許可しない会社なら、在庫を超えた予約はできない。許可する会社なら、不足していても予約自体は入れられる。
A「その『会社によって違う』、他にもあとで絶対増えるよ。」
私「めちゃくちゃ増えた（笑）」
B「これ、技術的には設定駆動の入口ですね。会社ごとに違う業務ルールを、コードに固定せず設定として持たせる考え方です。」
そして、在庫を見ていると、今度は数量だけでは足りなくなりました。
私「これ、どこにあるの？」
A「倉庫。」
私「どの倉庫？」
A「……。」
私「本社に5個、倉庫に3個、現場に2個だったら？」
A「ロケーションが必要になる。」
私「そう、必要になった。」
そこで、在庫をロケーション別に持つようになりました。
本社。倉庫。現場。その他の保管場所。
さらに、ずっと存在する本社や倉庫と、工事が終わればなくなる現場では扱いも違います。
A「固定の場所と、増えたり消えたりする場所。」
B「固定ロケーションと動的ロケーションですね。」
ここまで来ると、今度は一か所だけ見ても意味がありません。
例えば、必要数が10個。倉庫Aに4個。倉庫Bに3個。現場Cに3個。
私「全部合わせたら10個あるじゃん。」
A「まさか。」
私「寄せ集めればいいじゃん。」
A「ほら始まった（笑）」
複数拠点から、必要数量を満たす組み合わせを探す。
でも、組み合わせが複数あるなら、また選び方が出てきます。
私「近いところから集めたい場合もある。」
A「距離優先。」
私「でも3か所回るより、少し遠くても1か所で済む方がいい場合もある。」
A「箇所数優先。」
私「そう。」
B「つまり、同じ在庫探索でも、何を優先するかによって最適化条件を切り替えるわけですね。こうした複数の条件を扱う考え方は、多目的最適化につながります。」
私「当時は『近い方がいい』とか『回る場所は少ない方がいい』って考えただけだけどね。」
A「また技術用語が後から追いかけてきた（笑）」
しかも、距離と言っても、単純に現在地から近いだけではありません。
私「これから現場に向かう途中だったら？」
A「……。」
私「今いる場所から近い倉庫より、目的地へ向かう途中で寄れる倉庫の方がよくない？」
A「最初、おまえは在庫数見たかっただけだよね？」
私「そうだけど（笑）」
だから、現在地だけではなく、出発地・目的地も使って、移動途中を考えた在庫探索まで考えるようになりました。
A「在庫検索に経路まで入れ始めた。」
私「使う側からしたら、その方が便利じゃん。」
A「その『使う側からしたら』で裏側の難易度上げるのやめてくれ（笑）」
さらに、在庫の置き場所も、単なる倉庫だけではなくなりました。
現場在庫。
そして、
現場共有在庫。
ここは同じものではありません。
現場在庫は、その現場にある在庫。その中から、他の人にも使ってもらってよいものを、明示的に共有側へ出す。それが、現場共有在庫。
私「現場にあるからって、全部勝手に持っていかれたら困るじゃん。」
A「それはそう。」
私「余ってて、他で使っていいものだけ共有に出す。」
B「つまり、物理的な保管場所だけではなく、誰が利用できる在庫なのかという利用スコープまで分け始めたわけですね。」
私「俺としては『現場にある＝みんな勝手に使っていい、ではない』ってだけ。」
A「言い方は簡単なんだよな（笑）」
在庫を別の場所へ移すときも、考え方は単純です。
元の在庫が減る。移動先の在庫が増える。
私「片方だけ変わったらおかしいでしょ。」
A「言ってることは当たり前。」
私「そう。」
A「その当たり前を壊さず実装するのが面倒なんだよ（笑）」
私「それは後から知った。」
B「技術的には、こういう処理でデータ整合性が重要になります。移動元だけ減って移動先が増えない、逆に移動先だけ増える、といった状態を残さないようにする必要があります。」
私「当時はそんな言葉知らないよ。『片方だけ変わったら変でしょ』ってだけ。」
A「また考え方だけ先に来てる（笑）」
A「一回整理するよ。」
私「どうぞ。」
A「最初は？」
私「材料がどこに何個あるか見たかった。」
A「そこから？」
私「総在庫、予約在庫、有効在庫。」
A「在庫引当。」
私「名前はあとから知った。」
A「マイナス在庫。」
私「入った。」
A「ロケーション。」
私「入った。」
A「複数拠点。」
私「入った。」
A「寄せ集め。」
私「入った。」
A「距離優先と箇所数優先。」
私「入った。」
A「出発地と目的地。」
私「入った。」
A「……。」
私「何？」
A「在庫一覧だけ作る話、どこ行ったの？（笑）」
私「便利かなと思って（笑）」
そして、ここからは将来構想。
在庫を探すなら、距離や箇所数だけではなく、消費期限・使用期限が近いものを優先して候補にすることも考えています。
私「同じ物があるなら、期限近い方から使えた方がいいじゃん。」
A「また増やすの？」
私「構想だから。」
B「期限情報を持たせれば、将来的には期限優先の在庫探索にも広げられますね。」
私「使える物を期限切れにするより、その方がいいでしょ。」
A「また『その方が便利じゃん』か（笑）」
それと、この先の開発では、現場在庫や現場共有在庫、在庫移動、固定拠点と現場の違いみたいな話も出てきます。
ただ、それは実際に作った場面で改めて触れます。
A「まだ在庫の話、残ってるんだ。」
私「残ってる（笑）」
でも、この時点では、まだ在庫が中心でした。
私「在庫を予約できるようにはした。」
A「うん。」
私「で、思ったんだよ。」
A「嫌な予感しかしない。」
私「予約アプリって、世の中にいっぱいあるじゃん。」
A「あるね。」
私「だったら車とか機器とか施設も、在庫管理と一緒にこのアプリ一個に入ってたら便利じゃん。」
A「……在庫だけで終わらなかったか（笑）」
次回
在庫の次に思ったのが、
「予約機能も、このアプリ1個にまとめれば便利じゃん。」
でした。
車も。機器も。施設も。
空いている時間を見て、押して予約する。
今度こそ、そんなに難しくないと思っていました。
――時間を扱い始めるまでは。
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全16弾無邪気な実装 vs 架空エンジニア2人の容赦なきツッコミ ※便利かなと思ってどんどん追加しちゃうんだよね
- #1「在庫が見たいだけ」だったのに、引き算ひとつから在庫引当と多目的最適化まで始まった ※総在庫・予約在庫・有効在庫を分けた瞬間、ただの在庫表示が別物になった
- #2「予約機能もこのアプリ1個にまとめれば便利じゃん」で、“時間”が一気に牙をむいた ※時間重複・境界条件・時間粒度・スマホ操作まで、空いてる時間を選ぶだけでは終わらなかった
- #3 「機能増えたら毎回探すの面倒じゃん」で、お気に入りから共通UI設計まで広がった ※機能を増やした結果、「何を作るか」より「どう辿り着くか」が問題になった
- #4「普通の組織図でいいじゃん」で一人を複数部署に入れたら、“多対多”が始まった ※兼務・複数所属・部署別役職・過去履歴が一気に絡み始めた
- #5「どこの現場で使うかも持てばいいじゃん」で、物件マスタが在庫・予約・人を全部つないだ ※機能ごとにバラバラだった情報が、共通マスタを境に一つのシステムへ変わり始めた
- #6「会社ごとにちょっと変えたい」で、設定駆動とバリデーションが殴り合いを始めた ※柔軟にしたら、「自由に設定させすぎない仕組み」の方が難しくなった
- #7「ログインできたからって何でも触れたらまずいじゃん」で、認証より面倒な認可の沼に入った ※管理者か一般かでは足りず、「誰が・誰に・何をできるか」まで判定することになった
- #8「二人とも空いてる画面を見てたら、どっちが勝つの？」でRace Conditionが牙をむいた ※在庫も予約も、画面に表示された「空き」を信用しただけでは守れなかった
- #9「自分の在庫も持てた方が楽じゃん」で、“場所・所有・利用範囲”が全部別問題だった ※マイ在庫・現場在庫・共有在庫を分けたら、在庫数よりスコープ管理が難しくなった(近日公開予定)
- #10「申請もこの中でできた方が楽じゃん」で、CRUDの裏に状態遷移が増殖した ※申請・承認・差し戻しを入れた瞬間、「保存できる」だけでは何も足りなくなった(近日公開予定)
- #11「資格もQRで見られたら早いじゃん」で、“全部見せる”より“必要な答えだけ返す”方が難しかった ※資格・個人QR・権限をつないだら、識別より情報開示の方が本題になった(近日公開予定)
- #12「一輪車を“ネコ”で探せないの不便じゃん」で、Canonical IDと人間の曖昧さを両立させることになった ※人間には優しく、内部は厳密に−−別名検索から正式IDへ収束させるまで(近日公開予定)
- #13「機能増えすぎて説明する方が面倒」で、“どれが今の正解？”問題がコードの外まで広がった ※ヘルプ・仕様・会話・引き継ぎがズレ始め、Single Source of Truthが必要になった(近日公開予定)
- #14「Codexなら全部見てくれるじゃん」で、AIの作業速度が人間のレビュー限界を超えた ※コードベース横断調査が便利すぎて、変更範囲・Git・差分・安全コミットが主役になった(近日公開予定)
- #15「テストこんなに通るじゃん」で安心しかけたら、“全部緑なのに間違ってる”が普通に出てきた ※横断テストで見えた、Interaction Bug・境界値・期待結果そのものの罠(近日公開予定)
- #16「人間＋AI＋Codex、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)