会社に在庫があり、現場にも在庫がある。でも、現場仕事をしていると、自分で持っている材料もあります。車に積んでいる物。自分の棚に置いている物。だったら、それも自分専用の在庫として持てばいい。
A「次、マイ在庫。」
私「これは、かなり個人的な理由で作りました（笑）」
A「個人的？」
私「昔、現場仕事してたとき、よく使う材料を自分用に少し持ってたんだよ。」
A「車に積んでるとか？」
私「そう。車とか、自分の棚とか。」
A「会社の物？」
私「会社の物ではある。」
A「でも会社の普通の在庫とは別？」
私「言い方悪いけど――」
ちょっと隠して持ってる材料（笑）。
A「隠すな（笑）」
私「いや、本当にそんな感じだったんだって（笑）」
急に必要になったときのため。よく使うから、少し確保しておく。
自分の棚。車の中。場合によっては、別の保管場所。
私「で、たまになるんだよ。」
A「何が？」
私「『あれ、俺まだ持ってたっけ？』」
A「自分で隠した本人が分からなくなってる（笑）」
私「そう（笑）」
持っている記憶はある。でも、車だったか。会社の棚だったか。別の場所だったか。分からない。
私「だから思った。」
「これ、自分が何を何個持ってるか管理できたら便利じゃない？」
本当に、それくらいの始まりでした。
A「これ、もし他にも材料隠し持ってる人が居て使ってくれたらいいな（笑）」
私「ユーザー層をそこに限定するなよ（笑）」
B「表現はともかく、会社全体の在庫とは別に、本人が管理している在庫を分けたいという話ですね。」
例えば、自分の車に材料が10個ある。それを、会社の共通在庫と同じように、全員から使える在庫として見せる。
私「それ変じゃん。」
A「自分が明日使うつもりで積んでるかもしれない。」
私「そう。」
B「ここからは、在庫のロケーションだけでなく、所有・管理スコープも必要になりますね。」
私「当時は『俺の車に積んでる物まで、みんなが使っていいみたいに出すな』だった（笑）」
そこで、マイ在庫を作りました。
本人が管理する、基本的に本人専用の在庫。
会社全体へ、「私はこれを持っています」と公開するための機能ではありません。
自分が、何を持っているか。何個持っているか。どこに置いているか。それを、自分で確認するための場所です。
A「一個の“マイ在庫箱”？」
私「いや。」
A「また？」
私「自分の物でも、どこに置いたか分からなかったら探すじゃん。」
例えば、車に3個。個人棚に5個。別の保管場所に2個。
同じ自分の在庫でも、場所は分けて持つ。
A「本人専用の中にもロケーションがある。」
私「そう。」
B「所有スコープの内側に複数ロケーションを持つ形ですね。」
私「当時は『車3、棚5って見たい』だけ。」
A「やっぱり普通の言葉だと軽い（笑）」
これ、現場にいたときは結構ありました。
持っている記憶はある。でも、
私「あれ、車だっけ？会社の棚だっけ？ってなる」
A「だから最初から隠すなって（笑）」
私「突っ込むのはそこじゃない（笑）」
数量だけではなく、「自分のどこにある？」まで持たせたい。
だから、マイ在庫の中にも、保管場所を持たせました。
そして、場所を分けたら、当然、移動したくなります。
私「車に10個ある。」
A「うん。」
私「そこから3個だけ棚に移す。」
A「車7、棚3。」
私「そう。」
B「Inventory Transfer、在庫移動ですね。」
ただし、移動先の状態によって、処理は少し変わります。
棚に同じ材料がすでに5個あるなら、そこへ3個足して8個。
でも、その棚にその材料がまだ一個もないなら、新しく、その棚での保有情報を作る。
A「“3個移す”は同じでも、移動先に既にあるかどうかで違う。」
私「そう。」
B「数量移動だけでなく、移動先の保有状態も見る必要があります。」
そして、前回の競合も、ここでまた効いてきます。
A「移動しようとしてる間に、元の数量が変わったら？」
私「古い数量のまま動かさない。」
A「移動先も誰かが同時に触ってたら？」
私「そこも見る必要がある。」
B「競合検知と、移動元・移動先の整合は分けて考える必要がありますね。」
A「前回の話が、そのまま在庫移動に戻ってきた。」
私「毎回説明し直すと長いから、今回はそれで十分（笑）」
でも、マイ在庫の中だけで、物が動くわけではありません。
私「自分の車に積んでた材料を、現場へ持っていくことあるじゃん。」
A「ある。」
私「だったら、マイ在庫から現場在庫へ動かしたい。」
A「逆も？」
私「現場で使わなかった物を、自分の車へ戻す。」
A「現場在庫からマイ在庫。」
私「そう。」
B「ここでは数量だけでなく、管理スコープそのものが変わるわけですね。」
例えば、車に10個積んでいた材料のうち、5個を現場へ持っていった。
実物は、車から現場へ移っている。
でも、アプリでは、
マイ在庫10個。
現場在庫0個。
そのままでは、実際の物の動きと合いません。
だから、
マイ在庫 → 現場在庫
へ移す。
逆に、現場で余ったものを、また自分で持ち帰るなら、
現場在庫 → マイ在庫
へ戻す。
私「現物が動いたら、アプリの中でも同じように動かしたい。」
A「そこは分かりやすい。」
そして、ここで第1弾から出ていた、
現場在庫と現場共有在庫
の違いが、はっきり出てきます。
A「現場に材料10個ある。」
私「うん。」
A「それが現場在庫。」
私「そう。」
A「じゃあ他の現場の人も使っていい？」
私「現場にあるだけじゃダメ。」
A「そこ大事だね。」
現場在庫は、その現場に存在して、その現場で管理している在庫。
一方、現場共有在庫は、その現場にある在庫のうち、余剰などを、
他の人にも使ってもらっていい
と明示したもの。
私「同じ場所に置いてあっても意味が違う。」
A「現場在庫10個のうち、3個だけ共有とか？」
私「それもある。」
B「ロケーションは同じでも、公開・利用スコープが違うわけですね。」
例えば、その現場で後から使うために残してある3個。
それなのに、「現場にあるから」という理由だけで共有在庫に出ていたら、別の人から見れば、使っていい3個なのか、その現場用に残している3個なのか分からない。
私「だから、現場にある＝共有にはしない。」
A「場所と、使っていい範囲を分ける。」
私「そう。」
そして、ここはさらに、入口も分けました。
私「共有在庫に、いきなり直接入庫できるようにはしたくない。」
A「まず現場在庫として存在する。」
私「そう。」
A「その中から、『これは共有していい』って出す。」
私「その方が意味が明確でしょ。」
B「共有在庫を自由に新規生成するのではなく、現場在庫から明示的に共有状態へ移すわけですね。」
つまり、共有在庫が、どこから来たか分からない状態を作らない。
私「突然、共有在庫100個とか生えてきたら変じゃん。」
A「どこから来た100個だよってなる（笑）」
私「だから直接入庫は禁止。」
A「現場在庫から共有へ。」
私「そう。」
例えば、自分の車から現場へ材料を持っていった。工事が進んで、3個余った。
A「自分で持ち帰る？」
私「また使うなら、それでもいい。」
A「もう使わないなら？」
私「他の現場で使ってもらってもいい。」
A「そこで共有。」
私「そう。」
つまり、
「また自分で使うから持ち帰る」なら、
現場在庫 → マイ在庫。
「もうその現場では使わないから、他で使ってもらう」なら、
現場在庫 → 現場共有在庫。
私「同じ余った材料でも、その後どうするかで行き先が変わる。」
B「物理的な場所だけでなく、次の利用目的によってスコープが変化するわけですね。」
そして、共有した在庫を、他の人が使いたい場合。
私「共有だからって、勝手に早い者勝ちで持っていかれるのも困る場合あるじゃん。」
A「じゃあ予約申請？」
私「使用予定日と数量を出す。」
A「承認が必要な運用なら承認。」
私「そう。」
B「共有資源に対する利用申請ですね。」
承認が必要なら、基本的には、その現場を管理する側が確認する。
A「ここで物件担当者が戻ってくる。」
私「そう。」
A「権限も？」
私「戻ってくる。」
B「前に作った物件・認可の仕組みを再利用するわけですね。」
A「別々に作ってた機能が、だんだん集合してくる（笑）」
A「じゃあ整理する。」
私「はい。」
私「自分用に持ってる在庫を管理する。」
B「所有スコープ・可視範囲。」
私「本人の中でも場所別に持つ。」
B「ロケーション別在庫管理。」
私「車から棚へ一部数量を動かす。」
B「Inventory Transfer。」
私「マイ在庫から現場在庫へ。」
B「管理スコープの変更。」
私「現場にあるだけの在庫。」
B「現場在庫。」
私「その中から、他の人にも使わせると明示したもの。」
B「現場共有在庫・公開スコープ。」
私「現場にあるだけで自動的に共有しない。」
B「ロケーションと利用範囲の分離。」
私「共有在庫へ直接入庫させない。」
B「共有状態への明示的な遷移。」
私「使うときは必要に応じて申請する。」
B「利用申請。」
A「第1弾から気になってた『現場在庫と共有在庫って何が違うの？』が、やっと全部つながった。」
私「長かったね」
A「で、始まりは？」
私「昔、自分がちょっと隠して持ってた材料（笑）」
A「技術用語だけ見たら、そんな始まりだとは誰も思わない（笑）」
改めて考えると、この機能の始まりは、本当に小さなものでした。
「あれ、俺まだ持ってたっけ？」
「車だっけ？棚だっけ？」
それだけ。
そこから、自分の在庫を持つ。置き場所を分ける。場所の間を移動する。現場へ持っていく。余ったら戻す。不要なら共有する。必要なら申請して使う。
まで増えていきました。
私「はたして、これは業務改善なのか（笑）」
A「かなり個人的なところから始まってるからな（笑）」
私「でも、現場にいた頃なら欲しかった。」
A「じゃあいいんじゃない？」
私「そう思ってる。」
A「完成したら、昔のお前みたいに材料ちょっと隠し持ってる人が使ってくれたらいいな（笑）」
私「だからターゲットをそこに限定するなって（笑）」
そして、この頃になると、在庫や予約とは違う、もう一つの業務も入ってきました。
私「申請もこのアプリでできた方が楽じゃん。」
A「何の申請？」
私「例えば有給とかの勤怠申請。」
A「出勤・退勤全部？」
私「そこは混ぜない。ここで中心なのは申請。」
A「申請して、誰かが確認して。」
私「承認する。」
A「問題あったら？」
私「差し戻す。」
A「修正したら？」
私「また出す。」
A「……はい、状態が増えた（笑）」
B「次はWorkflowとState Transitionが、具体的な業務として出てきますね。」
次回
「申請もこの中でできた方が楽じゃん」で、CRUDの裏に状態遷移が増殖した
申請・承認・差し戻しを入れた瞬間、「保存できる」だけでは何も足りなくなった
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)