個人の向き合いを支えられるチーム - 混乱期の先にあるもの

この記事では、「個人の向き合いを支えられるチーム」の必要性と、それが具体的にどういうことを意味するか、ということを示します。キーワードは 混乱 で、主旨は次のようなことです：

• チーム形成において、混乱期は（長期的な最適を望むなら）避けられない。
• 混乱期においては、その他の混乱による負荷をコントロールして下げる。
  • その他の混乱は、解消すると個人にとって有効な知識を得られる種類の混乱である。
• 混乱期を過ぎたら、その他の混乱を徐々に増やし、かつチームから個人に混乱解消機能を提供する。
  • 「個人の向き合いを支えられるチーム」になる。

チームのライフサイクルと混乱期

まず、前提となる知識をいくつか紹介します。既にご存知の方は斜め読みして次の「チームに参加するメンバーに混乱を生じる要因」に進んでいただいて大丈夫と思います。

タックマンモデル

タックマンは、グループ形成のライフサイクルを以下のように定めるモデル（タックマンモデル）を提唱しました。これは元々グループセラピーなどにおけるグループ形成などについての研究のメタ分析で考えられたものですが、チームのライフサイクルとみなして考察されています。

段階	キーワード	主なチームの状態・行動	リーダーに求められること
Forming（形成期）	探り合い・期待	メンバーは互いを観察し、目標や役割を理解しようとする。表面的に友好的だが実質的な進捗は小さい。	目的・役割・ルールを明確に示し、心理的安全性を確保する。
Storming（混乱期）	衝突・不満	方針や優先順位を巡り意見がぶつかり、権限や責任の曖昧さが顕在化する。	コンフリクトを建設的に扱い、合意形成を促進する。
Norming（秩序期）	役割確立・合意	ルールや期待が共有され、互いの強みに合わせた協働が始まる。	自主性を尊重しつつ、合意したプロセスの定着をサポート。
Performing（活動期）	高成果・自己組織化	目的達成に集中し、高い協働と成果を上げる。問題解決も自律的。	障害除去・外部調整・将来ビジョン提示など上位の支援に注力。
Adjourning（散会期）※	評価・移行	プロジェクト終了や組織改編で解散。成果の振り返りと学習共有が重要。	成果を称え、学びをドキュメント化し、次の挑戦へ接続する。

※タックマンが1977年にジョンセンとともに追加した第5段階。

この各段階におけるメンバーのモチベーションを模式的に表した図を「外資系コンサルが教える課題を解決する12ステップ プロジェクトリーダーの教科書」より引用します。

このようなライフサイクルを経て、単なる個人の集団として集めて規定されたグループが、協調的に動作するチームになるというモデルです。

二重関心モデル

混乱期にはコンフリクトが発生します。このコンフリクトに対する各メンバーの態度を、自己および相手への関心・配慮の強弱によって分類するモデルが「二重関心モデル」です。この二重関心モデルの概要図は以下のようなものです。（「二重関心モデルに基づく協働的メンバ編成に向けた疑似的コンフリクトの適用方法の提案」より引用します。）

混乱期を避けるべきか否か、避けた場合の課題

このとき、混乱期をどれぐらい避けるべきか？という議論があります。というのも、混乱期に入ると集団のアウトプットは一時的に下がり、またメンバーがそのまま定着せずに離脱するリスクが生じたり、あるいは回避的な傾向を持つメンバーは混乱期に入りにくいということがあるからです。
「外資系コンサルが教える課題を解決する12ステップ プロジェクトリーダーの教科書」などでは、どんなプロジェクトでも100%混乱期が訪れるという主張があり、またタックマンモデルに基づく限りでは混乱期は避けられぬものとして扱われています。
しかし、実際には、二重関心モデルにおける回避傾向のメンバーが多い場合には、混乱期を避けて集団を運用することができます。^[1]ここでチームと書かずに集団と書いたのは、この集団は個の集合体の域を超えないからですが、この集団はそこそこワークします。メンバーの技能にもよりますが、一般的なソフトウェア開発で〜8名程度の一般的なメンバーを私が直接マネジメントする場合、1年ぐらいまでは混乱期を回避する運用がコスパの意味で最適である（または、最適でなくても十二分にワークする）と考えています。ここで最適と言っているのは、一般に同程度の開発を行うコストの1/3〜1/2程度のコストで開発できることを意味します。これは、10年ほど前からほぼ確実に再現できています。
この方法はチームが2年ぐらいまでは通用する感触がありますが、チームが3年目ぐらいになってくると（私の場合は）だんだんと厳しくなります。私は個人的に低レベルクリアと表現していますが、このプロジェクト達成は個が指示に対して動くことでなされるものであって、チームでなされるものではないことが大きな理由です。特に私がこのやり方をすると、プロジェクトを通して飛び交う莫大な情報を吸収できれば学習ができてメンバーが成長するが、その情報を吸収できないメンバーは静かに離脱していく、ということが発生します。したがって、元々学習意欲が強かったり、学習能力が高い場合には相当な速度で成長できますが、そうでない場合には低レベル状態で行き詰まることになります。また、学習能力が高いメンバーにあっても、チームの中で主体的に行動するということができません。形式的にチームであっても、実態としてメンバーが自律的に協調動作できるチームになっていないからです。

そのような事があり、長期的な観点においては、混乱期を避けることはおすすめできません。混乱期とどう向き合っていくか、ということが重要になります。^[2]
（私は、これを切り替えるときに、切り替えた時点で効率が1/2〜1/3ぐらいになることを躊躇して、ずっと切り替えができませんでした。ただ、それを乗り越えないと自律的な動きはできず、最終的にスケールしないと思います。）

混乱期との向き合い

チームの混乱期を乗り越えるには、基本的には真剣に話し合いをしていくしかないと思っています。これはすごく骨の折れる作業であり、時間もかかります。少なくとも1年以内のスパンで見るならば、実質コストとしても精神的体力的な面でもコスパが悪いです。それでも、長期的なことを考えるならば、やるしかありません。
具体的にどういった話が必要かというと、例えば期待値や求められていることのイメージであったり、価値観についての伝達やわからない部分の整理であったり、 チームとして動くために必要な組織文化的なこと・役割のこと・技術的なことで記号接地できていないことをすべて精査して話し合う ということが必要です。具体的な量でいえば、それぞれのメンバーについて話をする時間が数十時間以上、総工数で言えば数人月程度は必要であると思います。（これを、必ずしも短期間に実施する必要があるとは思っていません。数ヶ月、または結果的に年単位ということもあると思います。）
ただ、この話し合いも、やり方を失敗すると単に過剰な負担となって消化しきれずに終わります。そのような離脱する個人を発生させないために、「個人の向き合いを支えられるチーム」が必要となるのですが、以降でチームに参加するメンバーの混乱をもう少し詳しく分析して、そのインパクトや乗り越え方・向き合い方について検討していきます。

チームに参加するメンバーに混乱を生じる要因の分類

議論をわかりやすくするために、既にチームがある程度形成されて、混乱期を脱したチームにあとから参加するメンバーにおいて、どのようなことが混乱を生じる要因になるかを考えてみます。（チームが形成されていない場合は、これに加えていくらかの要因が追加になる、という見方ができるでしょう。）
なお、ここで考えている混乱が生じる一般的なメカニズムについては、以前書いた成功と失敗、学習と混乱 - 混乱を乗り越えるにはを参照ください。

• 組織・チームの考え方や評価、期待される役割についての混乱
  • チームがどういうあり方を理想としているのかということ
    • 自分が何をすればいいのかということ
    • 他人が何をすればいいのかということ
  • 自分が今までに実践していないことや、異なる考え方の整理による認知負荷
  • 必ずしも別の環境で期待されることというよりは、チームへの依存性が比較的高く、かつ単純な業務遂行に影響するもの
  • 信頼関係の欠如についてもここに分類
• 組織の独自性なく、単純に職能として要求される技術についての混乱
  • この仕事であれば一般的に要求される、というようなこと
    • 例えば技術者としての常識など
  • ソフトウェアエンジニアの場合には、一般論としてのソフトウェアを開発する技術知識と、対象業務領域特有の知識の両方
• 必ずしも組織や職能と直接関係ない、広く習得・振り返りが必要なことについての混乱
  • 仮説思考、問題解決能力のような、概ねどのような状況でも必要なこととの向き合い（職種への依存性が多少はあるにしても）
  • 行動習慣、例えば「人に感謝されることを目的とする」「忘れ物をしない」のようなレベルの、人によっては小学生でも実践していること
  • 特に振り返りの方法など、単純に業務遂行そのものに比例的に影響するというよりは、メタ的に影響するもの

これは、その混乱要素が影響している内容について、それがチーム特有の事情なのか、職種特有の事情なのか、一般的な働き方としての事情なのか、ということで分類をしていますが、いずれも根本的なメカニズムは同じものと考えています。具体的には、先に挙げた成功と失敗、学習と混乱 - 混乱を乗り越えるにはおよびその参考となった「学力喪失──認知科学による回復への道筋」で示されているような記号接地できていない状態が作られる場合と同じメカニズムです。
なお、このように分類をしてはいるものの、いずれも環境や仕事の内容から全く影響を受けないということはないです。例えば、一人で実施する作業が多く、かつ方法や成果物もほぼ一意に規定されているような場合においては、他者と協調的に仕事をすることが比較的求められないので、そのような仕事からいきなり協調が必要な職種に転職をすると、上記分類の「必ずしも組織や職能と直接関係ない、広く習得・振り返りが必要なこと」による混乱が発生します。ただ、相対的に他の環境で直ちに使えるかとか、仕事の"結果に比例"するのか"結果の時間微分に比例"するのか、といったことの違いがあるので、そのような観点で定性的にざっくりと分類をしています。

混乱期の本質的な要因はどれか

これらの混乱のうち、特に「組織・チームの考え方や評価、期待される役割についての混乱」として挙げたものが、本質的に混乱期を生じる要因であると考えています。というのも、職能を十分に獲得し、また行動習慣面でも優れたメンバーでチームを編成すれば「組織の独自性なく、単純に職能として要求される技術についての混乱」「必ずしも組織や職能と直接関係ない、広く習得・振り返りが必要なことについての混乱」は発生しないはずです。混乱期が回避できないものであるとするならば、この2つを除いた「組織・チームの考え方や評価、期待される役割についての混乱」と分類したものが必然的に混乱期の主たる要因となります。
そうすると、この混乱は チーム形成のライフサイクルの早期に出てくるという都合上、タイミングや量をあまりコントロールできない ということになります。（もちろん、事前に一定の準備をするにしても。）

混乱の解消による成長

また、逆に「組織の独自性なく、単純に職能として要求される技術についての混乱」「必ずしも組織や職能と直接関係ない、広く習得・振り返りが必要なことについての混乱」の2つの混乱は、個人特性に負うところの多い混乱、言い方を少し変えると「この混乱を解消することで特定のチームに留まらない、ある程度普遍的な能力の獲得・成長が期待できる」ということになります。個人への成長を求めるようなチームにおいては、この混乱の継続的な解消がチームにとっても個人にとっても重要となります。

混乱のタイミングをずらす、混乱設計の必要性

この3つの混乱が同時にやってくると、メンバーには大きな負荷がかかります。一方で、いずれの混乱も、高いパフォーマンスを上げるためには避けることのできない混乱です。混乱が一度発生すると、解消する努力をしなければずっと混乱したままの状態である（学力的に落ちこぼれてしまった場合に、解消するための努力を、本人・外部ともにしなければいつまでも落ちこぼれた状態になってしまうのと同じ）ことを考慮すると、生じる混乱の量を設計・管理する必要があります。端的には、これらの混乱のタイミングをずらすということが必要です。

チームにおける混乱の設計と、解消への貢献

ここで、上記の各分類の特性を踏まえて、チームにおける混乱をどう設計・管理するかを考えます。

組織・チームの考え方や評価、期待される役割についての混乱

この混乱は、そのチームで特有、かつ混乱期の主たる要因でした。
チームを構成するにあたって早期に経験すべき混乱なので、この混乱への対処を優先します。 具体的には、新しいメンバーがチームに受け入れられている（受け入れたい）ということをしっかりと示したうえで、いわゆるバリュー・評価基準を示し、その上で期待される役割などを伝えていくようにします。
これは、残りの混乱を解消するための土台となります。

組織の独自性なく、単純に職能として要求される技術についての混乱

この混乱は、例えば新しい職能への挑戦、これまでにやったことのないことを行う際などに発生します。
チーム参画のタイミングでは、特に業務領域特有の知識が不足している場合があるので、最初はオンボーディングで知識を獲得できるようにします。未経験からの参画においては、技術的なこともオンボーディングで厚めにフォローします。
この混乱は、オンボーディングによって解消速度を、期待値の調整によって発生量を、それぞれコントロールすることができます。マネジメントではなくコントロールと言っているのは、オンボーディングや期待値の調整のイメージは「混乱の調整弁（蛇口）をひねること」であって、「投入する混乱の量を多くするか少なくするかを直接的に変化させる」ことを意味するからです。期待値を増やすということは、蛇口をひねって流量・圧力（の合力）を強くするのと同じということですね。
上記の混乱期の混乱は早期に発生して避けられないので、それが発生している時期は意図的に期待値を下げることで対応します。というと表現が少し強く聞こえるのですが、オンボーディング等で学習期間として、直ちに職能が必要にならない期間を置いたり、こうした避けられない混乱の構造の存在を説明したうえで順番に対処していくという姿勢を伝えるようにします。
また、混乱期の混乱を過ぎたあとには、信頼関係等の面において、チームからの援助をより受けやすくなっているはずです。

必ずしも組織や職能と直接関係ない、広く習得・振り返りが必要なことについての混乱

この混乱は、日常的な業務への取り組み方など、特定の職能と結びついてはいないような習慣・能力に対して生じるものです。私自身は、社会人になったときにこのような事についての教育を叩き込まれました。この叩き込まれた知識は、どのような仕事にあっても単純に仕事を速くするとか、正確にできるようになるとか、そういったことに強く影響していて、仕事の基本として大変重要なことであると思っています。
ただ、この混乱を上の2つの混乱と同時に圧として加えると、単純にしんどく、個人の混乱解消能力を超えると脱落してしまいます。そこで、もし「組織・チームの考え方や評価、期待される役割についての混乱」があるならそれを優先して、この混乱の要因となる期待値・圧を下げます。最初はゼロということもあるかもしれません。そのうえで、「組織の独自性なく、単純に職能として要求される技術についての混乱」とのバランスを取りながら、メンバーに無理のない範囲の知識習得・混乱を生じるようにします。こちらも、期待値を上下することによって調整することが可能なはずです。
この混乱についても、チームからの援助が有効に機能します。特に、メンバーが実際に働く中でのフィードバックを受けるということは、そのチームにおいてのみできることです。これは、チームがメンバーに対してできる大きな貢献となり、「個人の向き合いを支えられるチーム」ということです。

チームがあるからできる挑戦、単に職能のある個を超えたチーム

これまでの内容を簡単にまとめると、次のようになります。

• チーム形成において、混乱期は（長期的な最適を望むなら）避けられない。
• 混乱期においては、その他の混乱による負荷をコントロールして下げる。
  • その他の混乱は、解消すると個人にとって有効な知識を得られる種類の混乱である。
• 混乱期を過ぎたら、その他の混乱を徐々に増やし、かつチームから個人に混乱解消機能を提供する。
  • 「個人の向き合いを支えられるチーム」になる。

本質的な内容としては以上で、あとは個人的な感想のような話です。

この整理は、いくつかの点で個人的に感慨深いものでした。
一つは、チームは単に現時点の課題をこなすための職能の集まりではないということ。チームは単に職能を有する個人の集まりではないということ、それはなんとなくわかっていました。しかし、それだけだと、私が実践してきた混乱期を回避するアプローチは間違っておらず、実際にプロジェクト開始から1年ぐらいは効率も良かったのです。かつ、混乱期を回避できなかった場合にそのまま混乱してチームとしてはほぼ終了、あとは個人で頑張ってなんとかするしかない、といった失敗も何度かあり、チームというものをどう理解すればよいのか、あまり分かっていませんでした。この整理で、チームは現時点での課題をこなすだけではなくて、個人に対して成長（混乱の解消）をもたらすことのできる存在である、ということを理屈として導くことができました。チーム内での切磋琢磨、単純なノウハウの共有、だけではなくて、より本質的な自身の課題への向き合いという部分で整理をできたことが本当に良かったと思っています。
もう一つは、自分が過去に経験したことが必要なのか必要でないのか、ということの答え合わせができたこと。私は3つの混乱について新卒時代にほぼ同時に対応する必要があり、かつ水準もあまり一般的な水準ではなかったので、相当な苦労をして、「本当にこれを全社会人が経験するのか、するべきなのか...？（困惑）」と思っていました。ただ、それが私の主観で成長をもたらしたということにも間違いはなく、その意味で非常に価値のある経験だったとも思っています。それで、このような経験（の本質的な部分）をインターン生にさせたいと（8年ほど前に）思いながらも、まったく無力だったこともありました。その「答え」がようやくわかって、

• 個々の経験としては、やはり必要なことであった
• しかし、それを同時に経験する必要はなかった（混乱設計）
• チームで支えることができれば、もっと楽に同じことをできる（個人の向き合いを支えられるチーム）

ということでした。自分が理解したことを、あのしんどい思いをせずに学ぶ方法が、チームを通せば存在する。チームこそが必要なもので、ただ、チームを作るには混乱期を経由する必要があった。8年前の自分にはできなかったし、その後気づくまでに8年かかったという悔しさも、逆に去年奇跡的な進捗があって8年でわかったという気持ちも、両方が混在しています。理屈で説明できなくても感覚でわかっている人はたくさんいるだろうし、既に理屈も存在しているかもしれないこと、それが今更ようやくわかったんだな、と思ったりしています。

脚注

1. 厳密には、「混乱期自体は短く小さいものがあるかもしれないが、その後によく機能するチームというよりは、初期の形成期に近い状態であったり、秩序期において形式的な秩序のみが定まってメンバーが協調的に動作しないような状態に至る」といったパターンかもしれません。ただ、いずれにしても本質的な違いはあまりないと感じたので、ここでは単に混乱期を避けるとしていますが、「混乱期にしっかりと腹を割って話すか否か」といった表現もできると思います。

2. 余談ですが、ChatGPT o3に質問してみると、混乱期を避けることはやはり通常は非現実的で、仮に衝突ゼロを目指した場合の損益分岐点は6週間前後というのが回答でした。私の体感する損益分岐点は1年ぐらいですが、これはマネジメントする人がどれぐらい難しい案件を捌けるかなど、色々な条件によるでしょう。