# プレーンユニット(Plane Unit)
# 何らかのシステム上で表現された、特定の組織自体を純粋に表現した概念。

# [🙏組織単位](🙏組織単位.md)との関係
# 例として「🐶🐱🐑🐵の4人チーム」を上げる
- プレーンユニット
    - 「🐶🐱🐑🐵」という情報
    - システム上では原始的なIDのリスト等で管理されていると思う<a href="sta.md"><img src="https://gyazo.com/a0a22d2fc5cf4fb2525db091fb66594b.png" alt="sta" width="16"/></a>
- 組織単位
    - プレーンユニットをシステムの世界観に落とし込んだもの
    - たとえば「4人だけが属するSlackチャンネル」「4人だけが見れるBoxフォルダ」「Entra ID上に登録された "🐶チーム"」
    - 最後の「Entra ID上に登録された "🐶チーム"」は、プレーンユニットとしても使える。特にAzureやM365前提のシステムをつくる場合<a href="sta.md"><img src="https://gyazo.com/a0a22d2fc5cf4fb2525db091fb66594b.png" alt="sta" width="16"/></a>

# プレーンユニットのイメージ
- ⭕
    - 🐶チーム: 🐶、🐱、🐑、🐵
```txt
xxxx
yyyy
zzzz
abcd
❌
table:🐶チーム
名前	社員ID	入社年次	メールアドレス	……
🐶	xxxx	...		
🐱	yyyy			
🐑	zzzz			
🐵	abcd			
たとえば「データベース」が持ち出されるのはやりすぎで、データベースはプレーンユニットと組織単位の中間くらいのイメージ
```

# 意義
- ソフトウェアや仕組みをつくる際に楽できる
    - まずはプレーンユニットを据えれば良い
    - プレーンユニットを据えて、ここにどんな機能や関連をつけるかを考えていけばいい
    - [分離エンジニアリング](分離エンジニアリング.md)の一例となる。文書を常にWordでつくるよりも、装飾のないプレーンテキストベースのフォーマット、たとえばMarkdownでつくった方が、純粋に内容や構造に専念できる。同様に、組織を伴うシステムをつくる際も、まずは純粋な「組織を表す概念」から扱うのが良い<a href="sta.md"><img src="https://gyazo.com/a0a22d2fc5cf4fb2525db091fb66594b.png" alt="sta" width="16"/></a>