在庫。予約。お気に入り。機能が増えてくると、どこでも同じ情報を使うようになりました。

会社。部署。人。

私「予約でも在庫でも、結局『誰が使うか』必要じゃん。」

A「まあね。」

私「だったら、機能ごとに同じ人を別々に登録するの面倒じゃん。」

A「結局また“面倒”から始まる（笑）」

私「名前変わったら全部直すとか嫌でしょ。」

B「ここからはマスタデータ管理ですね。複数機能で使う会社・部署・人を、一か所で管理する考え方です。」

私「当時は『同じ人何回も登録するのおかしくない？』だった。」

最初に考えたのは、本当に普通の会社の形でした。

会社

↓

部署

↓

人

会社。部署。人。ここまで登録して、すでにつながっている。

そこで、

私「あとさ、たまに組織図見たくなるじゃん。」

A「たまにって（笑）」

私「誰がどこの部署だっけとか、この部署に誰いたっけとか。」

A「まあ、あるね。」

私「だったら、この情報そのまま組織図にすればいいじゃん。」

A「組織図専用のデータをもう一個作るんじゃなくて？」

私「同じ情報二個持つ必要ないでしょ。」

A「そこは分かる。」

B「既に持っている会社・部署・所属情報を正として、そこから組織図を生成する考え方ですね。」

私「そう。組織図を見るために、また同じ人を登録するのは嫌だった。」

そこで、登録してある会社・部署・所属情報から、組織図を出すようにしました。部署を変えれば、組織図にも反映される。人の所属を変えれば、そこにも反映される。

私「組織図だけ別管理にしたら、絶対どっかでズレるじゃん。」

B「元データを正として、そこから表示を生成するわけですね。」

さらに、組織図を見ていると、

私「部署押したら、もう少し詳しく見たいじゃん。」

A「組織図に全部表示する？」

私「それは見づらい。」

A「じゃあ部署詳細へ飛ぶ。」

私「そう。」

A「組織図が見るだけじゃなくて入口になる。」

私「その方が自然でしょ。」

ここまでは、まだ普通でした。

A「珍しく平和。」

私「俺もそう思ってた。」

A「その言い方、もう嫌なんだよ（笑）」

現実の会社を考えたら、すぐに崩れました。

私「一人が二つの部署を兼務してることあるじゃん。」

A「あるね。」

私「じゃあ両方に所属させればいい。」

A「はい来た（笑）」

私「何？」

A「“両方に入れればいい”で済ませる人（笑）」

一人が複数の部署へ所属する。そして、一つの部署にも複数の人がいる。

B「これは多対多リレーション、Many-to-Many Relationshipですね。」

私「今なら多対多って言われても分かる。」

A「当時は？」

私「兼務してるんだから両方に出せばいいじゃん。」

A「その一言の裏が重い（笑）」

さらに、複数所属できるだけでは足りませんでした。

私「兼務してる人って、部署ごとに役職違う場合あるじゃん。」

A「例えば？」

私「こっちの部署では課長。でも別の部署では担当者とか。」

A「あるね。」

私「じゃあ人そのものに役職一個だけ持たせたら変じゃん。」

A「……また増えた（笑）」

例えば、Dさん。

設備部では、課長。

品質管理部では、担当者。

同じDさんでも、所属先によって役職が違う。

B「ここまで来ると、役職は人そのものではなく、人と部署をつなぐ所属関係に持たせる属性になります。」

私「当時は『部署ごとに役職持てばいいじゃん』だけ。」

A「要求は一行。実装は一行じゃない（笑）」

A「つまり最初は。」

私「会社、部署、人。」

A「一人一部署。」

私「そう。」

A「そこへ兼務。」

私「そう。」

A「多対多。」

私「入った。」

A「さらに部署別役職。」

私「入った。」

A「普通の組織図どこ行った（笑）」

私「見た目は普通の組織図だよ」

そして、兼務だけではありません。

出向。グループ会社。協力会社。

私「会社だって一個だけと関係するとは限らないじゃん。」

A「部署を複数にしたと思ったら、今度は会社まで（笑）」

私「現実にあるでしょ。」

A「あるから困るんだよ（笑）」

所属元の会社がある。でも、別会社へ出向している。グループ会社側でも役割を持つ。協力会社の人と同じ現場で仕事をする。

B「ここまで扱うと、単純な部署所属だけでなく、組織間リレーションや所属スコープまで必要になります。」

私「当時は『会社だって複数と関係する人いるよな』くらい。」

A「その“いるよな”でデータ構造を広げるな（笑）」

ただ、利用者へ裏側の複雑さをそのまま見せたいわけではありません。

私「内部で複雑でも、見る側には普通の組織図でいいじゃん。」

A「会社を開く。」

私「部署が見える。」

A「部署を開く。」

私「人が見える。」

A「でも裏では、その人が別部署にもいる。」

私「それでいい。」

B「内部のデータ構造と、利用者へ見せる構造を分けるわけですね。」

A「一回整理する。」

私「はい。」

私「会社・部署・人を共通で持つ。」

B「マスタデータ管理。」

私「会社→部署→人で見せる。」

B「階層構造。」

私「登録情報から組織図を作る。」

B「元データからのビュー生成。」

私「一人が複数部署に所属する。」

B「多対多リレーション。」

私「所属先ごとに役職を変える。」

B「中間エンティティへの属性付与。」

私「出向やグループ会社も扱う。」

B「組織間リレーション・所属スコープ。」

A「……最初は普通の組織図だったんだよね？」

私「現実に合わせただけだよ。」

A「その“現実に合わせる”が一番怖い（笑）」

ただし、ここはすべて完成しているわけではありません。

《未実装領域》

組織改編履歴。
Effective Dating（有効期間管理）。
過去／未来時点参照。

このあたりは、まだ未実装の領域です。

そして、組織を共通で持つようになると、次に必要になったのが、現場そのもの。

予約でも、どこで使うのか。

在庫でも、どこにあるのか。

人でも、どの現場を担当しているのか。

私「だったら現場も、一回ちゃんと登録して共通で使えばいいじゃん。」

A「物件マスタ？」

私「そう。」

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