変更履歴
2024/3/26
チームの権限構造の再設計として、チームオーナー、グループオーナーの権限と責務について定義
必ず全てのチーム・グループにオーナーを設置するものとする
2024/4/8
プロジェクトオーナーの定義
PMギルドの組織モデルの記載
2024/10/31
リーグの定義・カンパニーの定義を記載
背景
2018年のアジャイル組織宣言以降以下を実施してきた
助言プロセス
権限分散
2020年からは、アサインについても本人のみが権限を持つとした
手挙げなど能動的な行動が浸透する一方、全員が手挙げできるわけではないため、機動的なアサインについては課題があった
一部ギルドでは、課題を解決するためオーナー制などの導入が進んでいった
これまで推進してきた権限分散だが、機動的かつ全体最適視点でのアサインについては、特定の人に委ねることにして課題解決を図ることに
オーナーの定義
チームにおける資源分配の権限を唯一持った上で、分配の意思決定を最優先に行い最適化の責任を負う役割
オーナーは、チーム、グループ、ギルド、プロジェクトなど、組織を構成する領域の全ての単位で存在します
チームオーナーの権限と役割
チームオーナーの定義
チームの中でオーナーという役割を担う人を必ず一人決めます（「チームオーナー」と呼ぶ）
これはルールや標準、ガイドラインでもなく、組織設計の前提となります
チームオーナーがいないチームはチームオーナーがいるチームと結合して、チームオーナーがいる状態にします
チームオーナーの役割
オーナーの役割は以下となります
チームのリソースのアサイン権限を唯一持った上で、アサインの意思決定を最優先に行いリソース最適化の責任を負います
オーナーの役割を担うコミッターのアサイン権限はオーナー自身が行います
オーナーではない、チームのコミッターはアサイン権限を持たないです
オーナー不在時に代理で別のメンバーが役割を担う事は可能です
勤怠ルール・フレックスタイム制 でのフルフレックス勤務の承認を行いますプロジェクトへのメンバーアサインについて
チームオーナーがプロジェクトにチームメンバーの誰をアサインするかを決めます
アサインにおいては、稼働期間や稼働量についても決めます（明確に行う必要がある場合はプロリクで決定します）
チームオーナーの決め方
チームが作成された時点での最初のコミッターがデフォルトでオーナーになります
その後、チームのコミッターが増える中で、別のコミッターがオーナーの役割を担う場合は、プロリクでオーナーの変更を行います
（オーナー変更のプロリクはチームのコミッターであれば誰もが出すことはできます）
オーナー以外のコミッターの役割（重要）
オーナー以外のコミッターの役割は以下となります
オーナーが最適な意思決定を行うことができるように最善を尽くします
意思決定に必要な情報をオーナーに対して集約する
オーナーの意思決定に徹底して従うフォロワーシップを発揮します
オーナーが意思決定に専念できるように業務分担を行います
オーナーズの定義と役割
グループの定義
複数のチームの集まりとしてのチーム・オブ・チームズをグループと呼びます
グループもチームの一種であり（１）ストーリー（２）スコープ（３）ステークホルダーを持ちます
但し、グループのストーリーは独自の定義が必要となります
グループのスコープは、グループを構成するチームのスコープの総和であります
グループのステークホルダーは、コミッターとしてのチーム、コントリビューターとしてのチームから構成されます
グループオーナーズの定義
グループを構成するチームの中にオーナーの役割を持つチームを唯一として定めます
そのチームを正式には「グループオーナーズチーム」と呼ぶが、通常は省略して「グループオーナーズ」と呼びます
グループオーナーズの権限と役割
グループオーナーズの役割は以下となります
グループのリソースのアサイン権限を唯一持った上で、チームへのアサインの意思決定を最優先に行いグループのリソース最適化の責任を負います
グループオーナーの定義
グループオーナーズのチームオーナーは、「グループオーナー」と呼び、グループオーナーはグループに一人だけ存在します
グループオーナーズを構成するメンバーは以下となります
コミッター
グループオーナー
他のコミッター
コントリビューター
グループオーナーズではないチームのチームオーナーは、コントリビューターとしてグループオーナーズに所属することをガイドラインとします
グループオーナーの決め方
チームが二つになったタイミングで、どちからのチームのいずれかが、オーナーズチームになる事を決めます
決め方としては、オーナーズチームになるチームのコミッターが、グループ全体に対してプロリクを出して決めます
オーナーズチームのチームオーナーがグループオーナーになります
何かしらの理由でオーナーズチームになる事を決められない場合は、チームは二つに分けることはなく、一つにしてオーナーズチームを不要とします
この場合、チームの人数が7名を超えても仕方ないものとして許容されます
ギルドオーナー
ギルドの定義
グループの集まりをギルドと呼びます
ギルドオーナーズの定義
ギルドを構成するグループの中にオーナーの役割を持つグループを唯一として定めます
そのグループを正式には「ギルドオーナーズグループ」と呼ぶが、通常は省略して「ギルドオーナーズ」と呼びます
ギルドオーナーズのグループとしての役割は以下となります
ギルド全体のリソース・予算の配分権限を唯一持った上で、グループの優先順位・目標設定などの意思決定を最優先に行いギルドのリソース最適化の責任を負います
なお、ギルドを構成するグループには委員会も含まれる（委員会はWGと呼ばれるチームから構成されるグループとなる）ため、委員会へのリソース分配などの権限も持ちます
ギルドオーナーズを構成するチームの中でオーナーの役割を持つチームを「ギルドオーナーズチーム」と呼ぶますが、通常は省略して「ギルドオーナーズ」と呼びます
ギルドオーナーの定義
ギルドオーナーズチームのチームオーナーは、「ギルドオーナー」と呼び、ギルドオーナーはギルドに一人だけ存在します
ギルドオーナーの決め方
グループが二つになったタイミングで、どちからのグループのいずれかが、ギルドオーナーズグループになる事を決めます
決め方としては、ギルドオーナーズになるグループのオーナーズチームが、グループ全体に対してプロリクを出して決めます
また、その結果オーナーズチームのチームオーナーがギルドオーナーになります
何かしらの理由でギルドオーナーズグループになる事を決められない場合は、グループは二つに分けることはなく、一つにしてギルドオーナーズグループを不要とします
リーグの定義（2024/10/31〜）
ギルドの集まりをリーグと呼びます
現状だと、事業部を構成する職能単位のギルドの集まりがリーグとなり「ビジネス（リーグ）」と呼びます
カンパニーの定義（2024/10/31〜）
リーグの集まりをカンパニーと呼びます
現状だと、ビジネスリーグとコーポレートギルドを合わせた組織をカンパニーと呼び、全社を指します
プロジェクトへのメンバーアサインモデル
プロジェクトにおけるアサインモデルを提示するが、詳細についてはギルド毎に最適なモデルを模索するものとする
グループオーナーズによるアサインモデル
グループオーナーズはグループ内でプロジェクトをどのチームにアサインするかを決めます（明確に行う必要がある場合はプロリクで決定します）
正確なプロセスを敢えて定めるとすると、グループオーナーズのいずれかのコミッターがプロリクによりアサインを決めることになります
グループオーナーからプロジェクトをアサインされたチームでは、チーム内でどのメンバーにプロジェクトをアサインするかを、アサインされたチームのチームオーナーが行います
手挙げの推奨
また、手挙げで可能な限りアサインが決まる流れや、適切なメンバーに直接打診する流れは維持したいため、以下の図のような流れも可能とします
つまり、アサインの全てがチームオーナーが起点となって決まるというよりは、むしろメンバーからの手挙げからアサインが順次決まっていくことが期待されています
調整・窓口業務の分担モデル
なお、チームオーナーは必ずしも外部からの依頼の窓口を行う必要はないです
むしろ、チームオーナーが意思決定に専念できるように、可能な限り窓口業務や各種リソース調整の担当業務は他のコミッターが分担することが望ましいです
以下の図は分担モデルが有効になるケースを表しています
チームオーナー以外が窓口・調整業務を担当して、オーナーが最終確認するモデル（例：REP、リソースマネジメント担当）
素早い意思決定よりもメンバーの細かな調整が必要になるケース
オーナーよりも調整が得意なメンバーがいるケース
オーナーがリードエンジニアなど担当してプロジェクト稼働が高く、調整を行うことが難しいケース
プロジェクトオーナーの定義と役割
プロジェクトオーナーの権限と役割
プロジェクトに内におけるアサイン権限を持つ役割としてプロジェクトオーナーを定めます
プロジェクトオーナーは、プロジェクト内のリソースへの役割・職務のアサイン権限を唯一持った上で、プロジェクト内でのアサインの意思決定を行い、プロジェクトの目的・目標達成の責任を負います
通常、プロジェクトオーナーは、ゆめみでのプロジェクトマネージャーが役割を担うものとします
ただし、デザインプロジェクトの場合は、プロダクトデザイナーの職種がプロジェクトオーナーの役割を担うこともあります
プロジェクト内でのアサインおよびデフォルトアサインについて
メンバーのプロジェクトへのアサイン権限は、あくまでチームオーナーが持ちます
つまり、プロジェクトオーナーが個別にチームのメンバーをプロジェクトにアサインすることはできないです
一方で、チームのオーナーが特定のプロジェクトに対してメンバーをアサインする意思決定を行ったとしても、プロジェクト内での役割・職務のアサイン権限はプロジェクトオーナーが持ちます
ゴミを拾う責任（重要）
何もプロジェクトオーナーからの役割・職務のアサインがなければ、プロジェクトメンバーはプロジェクトにとって必要なあらゆる役割・職務に対して、自身の職種や専門性・得意不得意に関わらず最善を尽くすということを「デフォルトアサイン」とします
リジェクト
したがって、プロジェクトオーナーの意思決定によっては、プロジェクトにアサインされたメンバーに、プロジェクト内での役割・職務をアサインしないという意思決定も行うことがあります
つまり、チームのオーナーが決めたメンバーアサインに対しても実質「リジェクト」が行われることを意味します
すなわち、プロジェクトにチームオーナーが特定のメンバーを0.3人月毎月アサインしたとしても、プロジェクトオーナーがそのメンバーに職務や役割をアサインしなければ、実質的にプロジェクトメンバーとしてはリジェクトされたと解釈できます
これは、プロジェクトのメンバーとして最終的に役割・職務がアサインされるかどうかは、プロジェクトオーナーにおける意思決定が必要となることを意味します
また、このプロジェクトマネージャーによる意思決定は、一旦アサインされたメンバーに対して、プロジェクトの途中の段階でも「リジェクト」判断がなされることも意味します
相反するアサイン
加えて、プロジェクト内での役割・職務のアサイン権限もプロジェクトマネージャーが持つため、プロジェクト全体の最適な意思決定につながるのであれば、プロジェクトマネージャーは、メンバー本人の希望や適性と短期的には相反する業務アサインも行う場合があります
他方で、チームメンバーのアサインはチームオーナーが意思決定できるため、チームにとってのリソース最適に繋がらないと判断される場合は、チームオーナーの判断で特定のプロジェクトからの離脱やプロジェクトで稼働できるリソースを極小化するということもあり得ます
組織アサイン滝状モデル
以上を踏まえた上でモデルの全体像としては、以下の図のように滝状的にアサインが実施されます
リーグ
ギルドの集まりをリーグと呼びます
現時点ではリーグはないため詳細の説明は省略しますかが、ギルド同士良い意味で競い合うことを期待することからリーグと呼びます
その他考察
各ギルド毎の個別モデル
FAQ
オーナーは偉いんでしょうか？
オーナーが唯一の資源分配権限を持つので、一見すると権威性も高いものとして捉えて、暗黙的にオーナーの言うことに従うべきと思うかもしれません
しかしながら、本当に大切なのは限られた資源だということです
実は、権限というものはいくらでも割り当てられる資源として捉えると、権限を唯一にもつオーナーシップに権威性があるわけではなく、あくまで資源が重要であると気づくことができます
その希少な資源を最大限活かすためには、分配についての意思決定能力に長けた人が、その役割に専念できるようにすることが大切だということです
図表として使っているFigjamデータはこちら