会社。部署。人。一回登録した組織情報を、いろいろなところから使えるようにしました。
すると次に、同じことが気になりました。
現場です。
私「予約で『どこで使う？』って入れたじゃん。」
A「使用先ね。」
私「在庫にも現場が出てくる。」
A「現場在庫。」
私「人にも担当現場がある。」
A「また同じものが何回も出てきた。」
私「だったら現場も、一回登録して使い回せばいいじゃん。」
A「お前、だんだんパターン化してきたな（笑）」
そこで、物件マスタを作りました。
現場名。住所。会社。担当者。その現場に必要な情報を、一つの物件情報として持つ。
B「物件・現場マスタですね。現場名を各機能へ文字列で直接持たせず、正式な現場データとして一元管理します。」
私「当時は『現場も一回登録すればいいじゃん』だった。」
まず、担当者。
物件には、「この現場の担当は誰？」という情報が必要です。でも、前回すでに、人は組織側へ登録しています。
私「物件用に、また人を登録する必要ないじゃん。」
A「組織にいる人から選べばいい。」
私「そう。」
例えば、物件担当者がDさんなら、物件側に「Dさん」という文字を保存するのではなく、組織側に登録されているDさんを参照する。
B「物件とユーザーのリレーションですね。」
A「Dさんが名前変わっても？」
私「元を直せばいい。」
A「物件用の担当者名簿を別に直さなくていい。」
私「それがやりたかった。」
そして、物件を登録できるようになると、当然、在庫にも使いたくなりました。
私「現場って、在庫の置き場所にもなるじゃん。」
A「第1弾のロケーション。」
私「そう。」
A「じゃあ物件と在庫ロケーションを別々に作る？」
私「同じ現場なのに？」
A「ですよね（笑）」
例えば、中央病院改修工事という現場を物件として登録する。在庫側で、また「中央病院改修工事」というロケーションを手入力する。
私「これ嫌じゃん。」
A「同じ名前のデータが二個できる。」
私「片方だけ名前変えたら？」
A「ズレる。」
私「だから同じ現場を参照する。」
B「物件と在庫で同じ正式IDを参照するわけですね。」
予約でも同じです。
車を予約する。機器を予約する。施設を予約する。そのとき、どこの現場で使うのかを選ぶ。
私「そこも登録済みの物件から選べばいい。」
A「使用先を毎回文字で打たない。」
私「そう。」
すると、一つの現場が、いろいろな機能につながります。
物件情報。担当者。現場在庫。予約の使用先。
私「全部同じ現場の話なんだよ。」
A「今までは機能ごとにバラバラだった。」
私「それを同じものとして見る。」
B「技術的には業務データの横断参照ですね。物件・在庫・予約が、同じ現場IDを参照します。」
A「これ結構大きいね。」
私「何が？」
A「今までは在庫機能、予約機能、組織機能って別々に作ってたじゃん。」
私「うん。」
A「でも同じ人、同じ現場を参照し始めた。」
私「そう。」
A「ここから“一個のシステム”っぽくなってくる。」
私「それはある。」
利用する側から見ても、少し変わります。
例えば、まず物件情報を見る。そこに担当者がいる。その現場に関係する情報がある。予約するときも同じ現場を選ぶ。在庫を見るときも同じ現場が出てくる。
私「同じ現場を、機能ごとに別物として覚えなくていい。」
A「裏でも一個。」
私「画面でも同じもの。」
ただ、共通で使うようにすると、新しい問題も出ました。
A「現場終わったら？」
私「新しく使う必要はなくなる。」
A「じゃあ削除？」
私「……いや。」
A「なんで？」
私「昔その現場で予約した履歴とか、在庫使った履歴から現場が消えたら困るじゃん。」
A「なるほど。」
例えば、半年前にA現場で車を使った。履歴には、使用先：A現場と残っている。
工事が終わったからといって、A現場そのものを消してしまったら、過去の記録から参照できなくなる。
私「だから終わったら、消すんじゃなくて、新しい予約とかでは選べないようにすればいい。」
B「論理削除やアーカイブの考え方ですね。利用対象から外しつつ、過去の参照は残します。」
私「当時は『終わった現場でも昔の履歴には必要じゃん』だった。」
A「じゃあ現役の現場一覧には？」
私「出さない。」
A「過去の予約履歴では？」
私「出る。」
A「データとしては？」
私「残ってる。」
B「現在利用できるかどうかを、データの存在そのものと分けているわけですね。」
さらに、もう一段面倒なことがあります。
物件担当者が、途中で変わる。
例えば、3か月前はDさん。現在はEさん。
A「物件マスタの担当者をEさんに変える。」
私「うん。」
A「じゃあ3か月前の予約履歴を見たとき、担当者は誰って出す？」
私「……。」
A「現在のEさん？」
私「当時のDさんを見たい場合もあるよね。」
A「来た（笑）」
B「ここは現在値と履歴値の問題ですね。」
私「今の物件情報を見たいのか、その時点の情報を見たいのか。」
B「必要に応じて、履歴管理やスナップショットの考え方が関係します。」
A「物件を共通化したら、過去まで気にしないといけなくなった。」
私「共通にしたからこそ、勝手に変わると困る場所が見えてきた。」
A「整理するよ。」
私「はい。」
私「現場を一回登録する。」
B「物件・現場マスタ。」
私「担当者は組織側の人を使う。」
B「ユーザー参照。」
私「在庫のロケーションでも同じ現場を使う。」
B「共通ID参照。」
私「予約の使用先でも同じ現場を使う。」
B「業務データの横断参照。」
私「終了した現場を過去履歴から消さない。」
B「論理削除・アーカイブ。」
私「今の情報と、その当時の情報を分けて考える。」
B「履歴管理・スナップショット。」
ただし、現時点で扱っているのは、終了した物件を過去の記録から消さないところまでです。
担当者変更などをEffective Datingで管理し、
「その日時点の状態」を完全に復元するところまでは、まだ実装していません。
A「現場名登録したかっただけだよね？」
私「最初はね」
そして、物件をいろいろな会社で使うことまで考えると、また気になりました。
私「そもそもさ。」
A「まだある？」
私「俺は『物件』って呼んでるけど。」
A「うん。」
私「会社によっては普通に『現場』って呼うじゃん。」
A「あるね。」
私「『案件』って呼ぶところもある。」
A「……。」
私「予約の時間単位だって会社によって違う。」
A「第2弾の15分、30分とか。」
私「休日の扱いとか、申請が必要かどうかとかも違う。」
A「はい。」
私「だったら――」
A「分かった。次それだ（笑）」
次回
同じ仕組みをいろいろな会社で使うなら、会社ごとの違いも気になります。
「物件」と呼ぶ会社もあれば、「現場」「案件」と呼ぶ会社もある。
予約の時間単位も、休日の扱いも、申請のルールも違う。
だったら、会社ごとに変えられるようにすればいい。
最初は、表示する名前を設定で変えるくらいのつもりでした。
――業務ルールまで設定で変え始めるまでは。
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)