私「材料がどこに何個あるか見られたら便利じゃん。」

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、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)