変更履歴
組織が拡大する中で、チーム分割や新設を繰り返してチームが増えていく。
その際に、自己組織化が行われるには、以下の３つのタイプを考慮した組織設計が行われることが重要である。
以下の説明は、協調構造を保ったまま相似形をなす事を、原理的に確認する内容になっているため、説明が冗長であったりする部分はある事は了承ください
- 親子関係（権威モデル）
- 師弟関係（助言モデル）
- 社会的関係（成熟モデル）
（１）親子関係にあるチームにおけるチーム・オブ・チームズ（権威モデル）
上記の左図のように親子関係にあるチームの場合は、二重連結(Double Linking)の原則によりお互いのチームのコミッターが相手チームのコントリビューターとして貢献する（真ん中の図）
親チームと子チームを合わせた複数のチームを、チームの集まりとして「チームズ」として捉えることができる（真ん中の図では４つのチームがある）
次に、右図にあるように、チームズを全体として眺めると、複数のチームから構成される１つのチームのように捉えられる。
この１つのチームを、「チーム・オブ・チームズ」（複数のチームの集まりからなる１つのチーム）とした上で、通常は「グループ」と呼ぶ
ここで、チーム・オブ・チームズがチームであるからは、チームの定義にあるように、「ストーリー・スコープ・ステークホルダー」の３つが定義されるべきである。
ここで、チーム・オブ・チームズの、「ストーリー・スコープ」は親チームと子チームのストーリー・スコープを足し合わせたものになる。
では、チーム・オブ・チームズの「ステークホルダー」特にコミッターはどのように定義されるか？
チーム・オブ・チームズを眺めた時に、複数チームから構成されているが、一つ一つのチームは、チーム・オブ・チームズに対して、コミッターの役割とコントリビューターの役割のチームが存在する。
上記の右図で言えば、もともとの「親チーム」が「コミッターの役割としてのチーム（Team as committer）」として定義される。
実際に、チーム・オブ・チームズという全体のスコープに対して影響あるプロリクをコミットする権限をもつのである。
例えば、200_hr（人事） 190_Recruit（採用）などは、人事や採用全般に関わる影響あるプロリクをコミットする事が期待される。
それに伴い組織見取り図では、下記のように全体に影響するスコープを担当するという関係性を図式化している
一方で、もともとの「子チーム」は、チーム・オブ・チームズという全体に影響あるプロリクをコミットはできないが、その方針に沿った貢献を行う「コントリビューターの役割としてのチーム（Team as Contributor）」である。
以上のように、チーム・オブ・チームズは、チームの定義に従っているチームであるだけでなく、コミッターとコントリビューターを持つ構造になっている。
この、コミッターとコントリビューターを必ず持つ構造は、実は、真ん中の図にある、親チームや子チームとも同じ構造をとっている。
このように、「全体のいずれの部分をとって見ても、全体と部分が相似形（＝フラクタルな構造）」をとることは、自己組織化において重要な構造になる。
ゆめみでは、常にコミッターとコントリビューターが協調する事によって、外部に適応的に振舞う事ができると考え、コミッター・コントリビューターを持つ構造を組織図の全てにおいて相似形で持つ事を意識した組織設計にする。（組織設計を行う 200_hr（人事）はこの相似形を常に意識する）
参考：自律分散型リーダーシップとフラクタル組織http://www.nids.mod.go.jp/event/symposium/pdf/2012/J-01.pdf
フラクタル構造によるメリットは、各チームでの組織における動き方が、グループでの動き方の参考になったり、他グループの動き方を参考にすることができることがある。適切な競争原理が働いて、グループ間で良いプロセスや仕組み作りを促す仕掛けになっている。
（２）師弟関係にあるチームにおけるチーム・オブ・チームズ（助言モデル）
上図ではAndroidグループを例にして、分裂してできた兄妹関係のチーム（Team1, Team2, Team3）に対して、師弟関係として支援するTeachlead Teamを示している。
上図にあるように、師弟関係における師匠となるTechLead Teamの誰か一人のコミッターは、弟子チームのコントリビューターにならないといけない。
これによって、常に弟子チームの状況を師匠チームは身近に観察した上で、状況に応じた支援を行う事ができる。このモニタリング機能は極めて大事になる。
一方で、弟子チームのコミッターは、師匠チームのコントリビューターになる必要はない。あくまで、一方通行の連結ピンでお互いのチームは繋がる。（※親子関係の二重連結ピンの制約とは異なる）
あくまで、弟子が主役であり、弟子が進む方向性に置いていかれないように、連結ピンで繋がるイメージである。
チーム・オブ・チームズとしては、上図の右のように、４つのチームから構成されるが、TechLeadTeamは全体に対してはコントリビューターとしての支援的な立ち位置にある点が親子関係とは異なる点である。
また、全体を構成するどのチームを見ても、師匠のような役割としてのコントリビューターがチームに存在する状態になっている。
ただし、TechLeadTeamの成熟していく過程においては、弟子チームに対して、師匠のような存在になれる人がいない、あるいは少ない状態がある。
その場合は、左図にあるように、外部から技術顧問を招聘して、コントリビューターとして関わってもらう事が強く望まれる。
その状態になってはじめて、全てのチームにコントリビューターが存在するフラクタル構造をとる事ができ、グループ全体が外部に対して適応的に振舞う事ができるのである。
なお、TechLeadチームのコミッターは、弟子チームのコミッターになる事もできる。この場合は、TechLead Teamのコミッターとして弟子チームに支援的な役割を果たしたり、モニタリング機能を果たす中で、必要に応じて自身も弟子チームに対してコミッターとして関わる場合があるためである。
参考）テクニカルリードロールの戦術的プレイガイドライン における緊急時などの対応
また、キャリアとしてリードエンジニア兼テックリードを行う人については、両方の役割を柔軟に行き来するためにも、二つのチームのコミッターであることが望ましい。
（３）社会的関係にあるチームにおけるチーム・オブ・チームズ（成熟モデル）
チームが持続的に共通の目標を達成し続けるには、組織として学習していくプロセスが必要になる。組織としての学習を行うために、それぞれのチームが協力して、組織全体のメリットに繋がる活動を行う必要がある。
上図のように、短期的な目標達成や成長を目的とした「Short Term Project Team」は、その活動を通して得られた利益や余力の時間を使って、業務改善、能力開発、ブランド価値向上といった、中期的な目標達成やt成長を行う為の活動「Long Term Project」をチームとして行うのである。
その結果として、Short Term Project Teamには更なる余力が生まれるといった好循環サイクルを実現していく事で、より早く目標に到達する事ができる組織学習が実現される。
具体的には、委員会チームが中期的な観点での組織学習を行うチームとなる。
下図のように、Android Team1~3は、それぞれ短期的な目標達成を目的として、複数のプロジェクトをスコープとするチームである。
ここで、中期的な目標を達成する為の活動を行うのが、委員会（Android Committe）となる。
例として、Andorid委員会では、大きく３つの目的として「業務改善」「技術開発」「ブランディング」といった中期的な目標達成や組織全体の成長を目的として、１０個の役割（Role）から構成されるものが標準となっています（標準なので上書き可能です）
委員会のメンバーが多くなってきた場合は、委員会の会議体とは別の会議体を設定するため、分科会を設置してタスクフォースで協議する。
特に、定常的に継続する常設の会議体は「分科会（Working Group：通称ワージー）」期限を決めた臨時的なプロジェクトを「特別分科会（Special Working Group)」と呼ぶ。
委員会・分科会形式というのは、一般的な会社や組織でも運用される方式であり、奇抜なアイデアはではない。
一方で、委員会というのは、なんとなくボランタリーなチームのように捉えられてしまって一部の人だけが頑張ることになったり、あるいは、やたら関係者が多くて物事が決まらない事になりがちである。
ゆめみも実際、そのような局面は生じており、改めてチーム・オブ・チームズの構造を明確にとるように連携の原則を定義する。
まず、Android Groupを例にして、チームの関係性を分析する。
上図にあるように、複数のプロジェクトをチームが分担する形で担当している。チームのコミッターは、チームが担当しているプロジェクトに対してコミットする事が求められている。
従って、自分が主担当として関わっているプロジェクト以外であっても、コントリビューターとして支援する事が求められる。具体的には、チーム内の別プロジェクトのレビューを行う事が挙げられる。
また、Android Groupのチーム間でも協調する事が求められる為、別チームから支援の要請があれば、コントリビューターとして別チームのプロジェクトにも支援をする事が求められる。
このように、プロジェクトの数が多くなると、チームでプロジェクトのまとまりをそれぞれ分担をしながらも、グループ全体として協力して全てのプロジェクトを遂行できるようにするのである。
Android委員会も同じように、中期的な目標を達成する為の３つの目的があって、複数の役割が存在する。
従って、Android委員会でも、チームがプロジェクトを分担する構造を下図のように取る事で、フラクタル構造を保つ事ができる。
また、Android Groupの中のいずれかのチームのコミッターにAndroidエンジニアはならないといけないように、フラクタル構造をとる為には、委員会標準で記述するようにAndroid委員会の３つのチーム（Branding/Tech Dev/Kaizen）のいずれかのチームのコミッターにならないといけない事をルールとする