ピラミッド型の組織（仮）にtimesや日常的な雑談が効果的な理由を考えた

自作のポエムです。説明用に書いています。が、なにがしか再利用性のある資料になっていれば嬉しいです。

## 例えばこんな組織

- トップに大きな部の <font color=darkyellow>**包括的なマネージャー**</font> 
- 小隊を束ねる <font color=brawn>**マネージャー（現場リーダー）**</font> 的役割が存在
- 現場のメンバーは各「ピラミッド型」構造の中で問題解決にあたっている
- 通常はピラミッドの枠を超えて業務連絡を定期的に行うことはあまりない

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/b655fdd9-6ec0-da59-eb4e-8bf03f66d9e1.png)

- 実は開発チームA、B、Cのトップ同士は定期的（週1回など）に会議体で情報交換している。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/cbb86a5f-b31a-d725-f11c-ea70083b4c7a.png)

## 例えばこんな役割分担

- **開発チームA**
    - 例えば全製品のインフラを包括的に担当
- **開発チームB**
    - ある業務領域の製品の「セキュリティ」を担当
- **開発チームC**
    - Bとは別の業務領域の製品の「セキュリティ」を担当。製品はチームBの作成しているライブラリに一部依存している。
- <font color=navy>**顧客フロント**</font>
    - 例えばお客様環境の「セキュリティ」のトラブルを解決したい！などというときに関わる。																															
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/f65eca84-bd62-fbe7-0e15-681ae87593bb.png)


## さてこの組織で製品にトラブルが発生した

右側、<font color=navy>**顧客フロント**</font> から問題が発覚する。

- <font color=navy>**顧客フロント**</font>
    - ４の人は製品という軸ではチームCに問合せをする。
- **開発チームC**
    - 問合せを受けたのは３の人。
    - ３の人は問題の原因となった情報を見つけることが出来ないので小隊マネージャーに相談した結果、チームBの作成しているライブラリがコアだと判明した。ので、２のチームの人に聞いて解決することになる。
- **開発チームB**
    - ２の人は製品情報を実は、**Google Docsに保存していた**。インフラの情報は自力で探したり、また自分のマネージャーに相談したり、結果、１の人に直接聞いたりして探して解決している。
    - 今回は、ライブラリの情報は部外公開していなかったので、チームCから直接問い合わせを受けて調べる要請になった。
- **開発チームA**
    - はてさて、１の人はインフラの情報を**GitLabに保存していた**。
    - 今回は、チームBから直接問い合わせを受けてインフラの原因を調べる要請になった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/a1dc8d2e-730d-b1cb-6471-e0cd53296d15.png)
顧客先のトラブル。こうして主管が開発チームC、B、Aと現場で変遷し **めでたく問題解決** する...


## めでたい？

しかしよく考えたい。

- 今回のトラブル、現場が頑張って解決して解決にかかった日数は平日５営業日だったとする。
- ギリギリ週内で解決できたことで、現場同士の連携が多少遅くても、トラブルとして開発部間の「会議体」に報告されることはなかった。など、ありがち。
- が、解決速度は遅いし、１，２、３の皆の開発体験は低い。主に、**情報はどこにあるの～、誰が知っているの～、という問題**である。部外の人に質問するのも割り込みお願いするのも、けっこう緊張しますよね...。
というか現場が頑張っちゃうと「会議体」役に立ってねえな～ という話でもある。


実際は完全に開発部間が断絶しているということはなく、「セキュリティ」、「ミドルウェア」、「Upgrade」などテーマ的な軸で定期的な情報交換があるケースはあるだろう。しかし会議体に頼らずとも

- 「製品情報をGoogle Docsに保存していた。」
- 「インフラの情報をGitLabに保存していた。」

この情報蓄積場所が影響範囲を考えて設計されていたり更新されていたりすれば、それがわかるだけでも解決できるのだがということでもある。多くの部署に関わるアナウンスを行うチームは **自分の仕事を楽にするために** それを考えたい。

## times あるいは日常的な雑談の効果

さてガッカリ感漂うピラミッドの組織だが、意外と効果的なインフラがある。Slackが使える会社はチャンスだと思ってほしい。「Slackのtimes(分報)」である。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/8bb18d50-50f0-ac9e-c2e1-8a871eb34180.png)

たとえば、チーム外に直接問い合わせを行う前にそれぞれでこんな心のつぶやきがあるはずだ。あるいはチーム内で「リーダーに相談する」のにも、もしかしたら半日営業日消費しているかもしれない。つぶやきを可視化する。

- <font color=navy>**顧客フロント**</font> のメンバーのtimes
    - 「うわあああ、（エラーコード）が出た...」。
- **開発チームC** のメンバーのtimes
    - 「チームBの作成しているライブラリ、詳しい人って誰だろう...」。
- **開発チームB** のメンバーのtimes
    - 「チームAへの問合せチャンネルってどこかなあ...」。
- **開発チームA** のメンバーのtimes
    - 「むむむ、今日は（エラーコード）の話題が騒がしいな、なんだろう...」。
   
... などとtimesでつぶやいていたら誰かが気づいて「こういう事が起こっているよ」「誰々が調べているようだよ」かもしれないし、そもそも

- 「製品情報をGoogle Docsに保存していた。」
- 「インフラの情報をGitLabに保存していた。」

という情報にも接することができるかもしれない。そしてそれは現在いるメンバーだけでなくあらたにJoinするメンバーにも引き継がれるなかなか有機的なつながりである。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/4949b6fc-1b7a-df16-94af-e6f0a37ca575.png)


## まとめ

実際は完璧な絶望が存在しないように、完璧なピラミッド型組織など存在しないかもしれない。
[ティール組織って何？　誤解されがちなポイントは？──第一人者 嘉村賢州さんに聞いてみた | サイボウズ式](https://cybozushiki.cybozu.co.jp/articles/m001504.html)

しかし、偉い人ともっと雑談したかったり、timesなかなか良いよというのを説明したかったり、なぜ問題解決に時間がかかるの？というのを説明したかったりする際に、便利な図が書けた気がするので、ポエムとして保存しました。会議に注力したいわけでもない。資料はちゃんと残しておきたいねとも思います。

実際はこんな深刻な話題ばかりではなく「この動画がおもしろい」とか「ごはんがおいしい」、「こどもがかわいい」とか、そんな部署外の人の話題も醍醐味だと思ってもいます。

他、参考: [分報で各自の作業を可視化したら、メンバー間の協力が加速された話 - Qiita](https://qiita.com/kojimadev/items/ea8825dec1b0d0d2874c)

以上なにがしか有用なモノになればさいわいです。