見出し画像

チームの構造をデザインする。

 「組織やチームの中であえて境界をつくる」というと眉をひそめられるかもしれない。普段から越境(役割や前提を踏み越える)を声高に言っているにも関わらず、最近はそんな真逆のことを考えていることが多い。

 ここでいう境界は、役割のこと。チームの中で、大小程度はあるが越境を求めるならば役割の定義なんてもはや最初から無くて良いのではないかと考えていた(スクラムでも個々の専門領域は認めつつもチームの中での肩書きは認めないしね)。

 だが実際には、我々が直面する問題やタスクを対処するには専門知識、技術、経験が必要だ(これはソフトウェア開発の話を想定している)。当然チームメンバーのそれらは個々で出っこみ引っ込み異なる。そういう状況下で、役割の定義が無いということで「全員が同じレベルで理解する」を目指すのは、現実的では無い。やれなくは無い。しかし、時間がかかりすぎる。チームにはミッションがある。ミッションを果たすにはそのやり方では時間が足りなさすぎる。

 「役割の定義が無いので全員がその役割をつとめる」というのは、論理的には正しい方向性と言える。ただし、論理的に正しい帰着が常に問題解決に対して適しているわけではない。チームに方向性を与えるのは、そのチームの構造に依るところが大きい。その際、チームは無意識に近い形で自分たちの方向性を選択していることもある。

 構造とはどのような要素で決まるだろうか?できるだけシンプルに考えると、以下の4つではないかと考えた。

1. 役割 2. 交流の場 3. ルール 4. 共有されたミッション 

 この4つはスクラムから拝借している部分が多い。つまり、スクラムでの役割と言えば、プロダクトオーナー、開発チーム、スクラムマスターであるし、交流の場とはスクラムイベントのことだ。ルールは、完成の定義や透明性などの原則。共有されたミッションは、スプリントゴール+プロダクトバックログに落とし込まれる、チームの目的という捉え方だ。

 この4つの要素の状態で、どんなチーム状態があるか、考えてみた。

 例えば、1役割、2交流の場、3ルールはあるが4共有されたミッションが無いとすると、個々人がそれぞれの責任を果たすだけの個人商店のような状態。

 あるいは、1役割、3ルール、4共有されたミッションはあるが、2交流の場が無いとすると、目の前の仕事を個別に倒していくだけの塹壕のような状態。

 または、1役割、2交流の場、4共有されたミッションはあるが、3ルールが無いとすると、お互いの活動が噛み合わない烏合の衆のような状態。

 そして、2交流の場、3ルール、4共有されたミッションはあるが、1役割が無いとすると、チームプレー第一、仲良しこよしのような状態。

 チームの練度が足りない(結成されたばかり、人の出入りが多い、ビギナーが多いなど)場合、4つの要素が設計されていないと、チームの活動が成果に繋がりにくい。

 逆に、チームの練度が高まってきたら、各要素は見直した方が良いだろう。役割の定義がなくても自立的に動ける、交流の場が少なくても阿吽の呼吸でやれる、ルールがなくても整合性の取れた活動ができる、ミッション自体を問い直し、より高次のミッションを自分たちで見い出せる。 

 構造が人のふるまいを左右する。好ましい状況にも、好ましくない状況にも導く影響を持っている。

この記事が気に入ったらサポートをしてみませんか?