#Book [[📒「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術]] [[📚第6章 文化を醸成する「恐怖」と向き合う技術②]] ## 5章 > [[🗃️チーム]]の構造を適切な組織パターンに合わせて変えていくことで、柔軟な[[🗃️意思決定]]と情報の流れ（フォース）を作り出します。 　適切な構造がない場合、役割や責任が不明瞭になり、情報の流れが滞りやすく、意思決定の遅延やタスクの重複・漏れが発生するリスクが高まります。構造を整えることで、各メンバーが自分の役割と責任を明確に理解し行動しやすくなり、情報共有がスムーズになり、迅速な意思決定が可能になります。 ^ref-427 ### 5.3 [[🗃️Dynamic Reteaming]]パターンで構造変化を捉える 💭 [[🖇️ダイナミックリチーミングから学ぶ 不確実な状況に適応し続けるための チーム作り ドクセル]]これを見てみた。 >[[🗃️貧困の罠]]とは、チームの中でうまくコミュケーションができなかったり、スキルが合わず、機能しないことです。 ^ref-64841 > [[🗃️硬直の罠]]（ Rigidity）により意思決定が遅くなったり、ムダなフローがあっても暗黙知が邪魔をして「問題を認識しているけれど言わない状態」が見られます。チームメンバーが互いの役割を理解しているがゆえに、コンフォートゾーンの外に出た改善が進まなくなります。 ^ref-52101 > チームが停滞や硬直の兆しを見せ始めた際には、組織として[[🗃️創造的破壊]]（ Creative Destruction）という形で構造改革を行い、新たなフェーズへと再生していくことが求められます。 ^ref-32747 ### 5.4 5つのパターンで変化をつける 💭[[🗃️Dynamic Reteaming]]の考え方は、結構当たり前ではあるけどパターン化されていることで選択肢としてイメージしやすくなる気がする > [[🗃️One-by-One]]パターンは、チームメンバーを一人ずつ増減させる手法です。このパターンは、チームの文化や雰囲気を大きく変えずに、少しずつ構成を調整したいフェーズで検討されます。たとえば、退職によるメンバー交代や新メンバーの追加などで、チーム構成が一歩ずつ変化することを指します。 ^ref-8737 >[[🗃️Grow-and-Split]]パターンは、チームが大きくなりすぎて効率が低下する状況で、チームを2つ以上に分割する手法です。このパターンは、急成長している企業や組織でよく見られます。チームが大きくなりすぎると、効率的に作業を進めるためにチームの分割が必要になることが多いです。 ^ref-9678 >[[🗃️Isolation]]パターンは、既存のチームから独立した小規模なチームを作り、特定のプロジェクトや課題に専念させるパターンです。このパターンは、緊急事態への対応や新製品の開発など、従来のチーム運営とは異なるアプローチが求められる場面で特に効果を発揮します。 ^ref-52952 > [[🗃️Merging]]パターンは、2つ以上のチームが合併して1つのチームになるパターンです。このパターンは、組織再編やプロジェクトの統合などさまざまな目的に実施されます。合併によってチーム規模が拡大し、新たなスキルや知識がチーム内に導入されるため、成果の最大化を目指すことができます。 ^ref-33081 >[[🗃️Switching]]パターンは、チームメンバーがほかのチームへと移動するパターンです。個人のキャリア開発や組織内のスキルバランスを調整するために、このパターンが用いられることがあります。メンバーが異なるチームでそのスキルや経験を活かすことで、組織全体の能力向上やイノベーションが期待されます。 ^ref-6045 #### メンバーの納得度と自由度のバランス > チームの再編成においては、メンバーの納得度や自由度のバランスも重要です。メンバー割り当てが以下のように上から下に進むほど、現場の自主性を尊重した納得度の高い再編が可能です。 > • 上司の誰かが、彼らをチームに配置した > • マネージャーが、彼らの意見を聞かずにチームに配置した > • マネージャーが、チーム配属時に彼らの意見を求めた > • マネージャー／リーダーが、自薦他薦問わずに選抜した > • チームメンバーが立ち位置を交換し、その後マネージャーに報告した > • チームメンバーが自分たちでチームを形成した 💭「チームメンバーが立ち位置を交換し、その後マネージャーに報告した」は面白い発想だな。叩き案をチームに共有して、もっとこうしたら良くなるのではというのをメンバー同士で調整できると納得かんは上がりそう > 最終的に意思決定を受けるメンバー自身も、“[[🗃️Disagree and Commit]]” の精神が必要です。「同意はしないがコミットする」という意味です ^ref-25900 > 互いの信頼関係のうえで、組織の[[🗃️意思決定]]に自分の考え方を述べ、成功／失敗の議論について意見が違っても同意し、組織として前に進むために協力できる姿勢（マインド）ができる組織はきっと強いでしょう。 ^ref-29548 💭議論しにくいことも、ちゃんと話をして納得感を持って進めていけるといいだろうな〜 ### 5.6 裁量と権限を作り、[[🗃️レポートライン]]をつなぐ > エンジニアでいえば、役職者から始まり特定プロジェクトのリーダーに抜擢したり、スクラムマスターやサーバントリーダーを任せたりします。その中でマネージャーとの役割の違いを明文化し、認識合わせをします。たとえば以下のような項目を埋めていきます。 • 役割名 • 任せたい仕事・領域 • 期待する行動 • マネージャーとの役割分担 　たとえば、特定領域のリプレイスを任せるとすると、 表5-6-1 のようになります。 [[🗃️役割]]の定義を行えば、あとはレポートラインを整えて情報が適切に流れるルートを作るだけです（ 表5-6-2）。 ^ref-64827 💭[[🗃️ジョブディスクリプション]]の例。[[🗃️スクラムマスター]]と[[🗃️マネージャー]]の立ち位置はごっちゃになるから、こうやって明確に定義されているとやりやすそう。 ![[20250517_第5章構造を動かす恐怖と向き合う技術_ジョブディスクリプション.png]] 💭[[🗃️ミーティング|🗃️MTG]]の整理もわかりやすい。 ![[20250517_第5章構造を動かす恐怖と向き合う技術_レポートライン例.png]] ### 5.7 構造による力学=リズムが生まれる > [[🗃️マネジメント]]は一度の大きな施策だけでなく、チーム内に改善のリズムを作り出すことが肝要です。リズムがある組織では、メンバーは臆することなくやりたいことに取り組め、[[🗃️ソフトウェア開発]]も順調に回ります。このようなチームは停滞感がなく、流動的に前進し続けており、たとえ失敗があっても常に動き続ける活力を持っています。物事がリズム良く前進している状態です。 ^ref-6662