0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

#4「普通の組織図でいいじゃん」で一人を複数部署に入れたら、“多対多”が始まった 〜兼務・複数所属・部署別役職・過去履歴が一気に絡み始めた〜

0
Last updated at Posted at 2026-09-03

B5CA646C-EF85-4281-92B9-635A77CAA2FD.png

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

会社。部署。人。

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

A「まあね。」

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

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

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

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

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

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

会社

部署

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

そこで、

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

A「たまにって(笑)」

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

A「まあ、あるね。」

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

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

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

A「そこは分かる。」

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

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

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

IMG_2333.jpeg

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

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

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

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

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

私「それは見づらい。」

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

IMG_2362.jpeg

IMG_2361.jpeg

私「そう。」

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「はい、また始まる(笑)」

次回

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

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

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

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

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

最初は、現場名を登録するだけのつもりでした。

――物件マスタが、在庫・予約・人を全部つなぎ始めるまでは。

連載公開分(クリックで開く)
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?