お疲れさまです、uni'que若宮です。

日経COMEMOから↓のようなお題が出ているので、今日は「チームビルディング」について書きたいと思います。

#日経COMEMO #チームビルディングおすすめのやり方

２つの協働を使い分ける

「チーム」は協働して何かを成し遂げるものですが、協働の仕方というのは実は一種類ではありません。

ちょうど最近「collaborate」と「cooperate」という言葉について最近考える機会があったのですが、その違い、説明できますでしょうか？

↓のイラストがとてもわかりやすいので、ご覧ください。

チームワークと聞いた時イメージが湧きやすいのは「cooperate」のほうでしょうか。「一つの仕事をみんなで進める」っていう感じですね。他の言葉に言い換えると、「協力」とか「一致団結」とかはこちらの方がイメージが近いかもしれません。collaborateと比べると、cooperateは「やることや方向性が見えている」時にやる感じになります。

もう一つは「collaborate」ですが、collaborateでは「やることや方向性が見えていない」場合です。一緒に考えることでその方向性自体を見出すような感じ。言い換えるなら「協創」がイメージが近いかもしれません。

注意したいのは、cooperateとcollabolateでは、メンバーが向かうベクトルがちがうことです。

右側のcooperateでは「進む方向」が決まっているのでみんなが同じ方向を向いています。しかしcollaborateではお互いに向き合っています。お互いに意見を出し合うことで、新しい方向性を模索しますから、collaborateではそれぞれのメンバーがちがう方向から意見を出し合うことが重要なのです。

「チームビルディング」というとcooperateの方がイメージされがちかもしれませんが、いつでもこのような同じ方向の「協力」が向いているわけではありません。cooperateは語義通り、「運用operation」のフェーズや解決法が決まっている場合に力を発揮します。方向性がわからないときにはcooperateのイメージでは上手くいかないときがあるのです。

これは「技術的問題」と「適応課題」のちがいにも対応するかもしれません。（このあたりは宇田川センセの下記書籍が参考になります）

「技術的課題」とは解決策がすでに分かっていて、知識やスキルを身につければ解決できる問題で、問題は自分たちの外にあります。しかし、「適応課題」は自分たちも課題の一部であり当事者なので、自分自身のものの見方や、周囲との関係性が変わらないと解決できない問題です。適応課題の解決にはチーム全員が変化し、関係性をアップデートすることで方向性を見出すようなcollaborateの意識が重要だと思います。

「混乱」の重要性

もう一つ、別の観点から考えてみます。チームビルディングのプロ・仲山進也がくちょの↓タックマンモデルを元にしたこちらの図がとてもわかり易いのですが、実はチームがチームになるためには一度「混乱」を通ることが必要です。

（↓の記事より引用）

「混乱期」というのはメンバーそれぞれのベクトルがバラバラになるタイミングとも言えます。stormingというのは「ブレインストーミング」などでも使われるように「嵐」のような混乱の時期なのですが、上記のcooperateとcollaborateでいえば、それぞれの価値観が交錯するcollaborateなフェーズと言えるかもしれません。

たとえば、見知らぬ人とチームを組んでなにかアウトプットをするような課題に取り組むとします。①最初の段階はForming期、みんな遠慮しあっていて形式張った状態で衝突もない代わりにどこか上辺の関係です。その後②storming期では徐々に本音が出てきて意見がまとまらなくなります。

がくちょの定義ではここまでは「グループ」本当のチームではありません。storming期の混乱をくぐり抜けることで「混乱」を通ることで心理的安全性が形成され、本当の意味で「チーム」となり、③norming期で新たな規範が生まれ、④有機的なチームへと変化するわけです。

これをベクトル的に考えれば、①はまだ矢印がない様子見の状態で、②でcollaborativeになり、③でcooperativeな方向性が見え、④はcollaborate+cooperateな状態、という風に言えるかもしれません。

注意しないといけないのは、多くの組織ではたとえば後からメンバーがjoinしたりすると②をすっ飛ばして③から行こうとしてしまう時があることで、この時あとから入ったメンバーは実はフォーミング期のままにノーミングの矢印に「なんとなく合わせる」状態になってしまったりします。

「偏愛」と「弱み」でつながる

なので本当は、メンバー同士が向かい合い、それぞれのベクトルを向き合わせる時間もちゃんと取ることが重要です。既存の組織であっても、たとえば前述したようにメンバーが増えた時や組織の目標や環境が変わったときなどに定期的にcollaborateし、自分たちの方向性を見直す必要があるでしょう。

collaborateやstoming期ではメンバーそれぞれのベクトルが相互に自由に交錯することが必要です。この状態になるには一定の時間を要しますが、どうにかそれを短期的にすることはできないのでしょうか。

僕はここ数年、自社でもその外でもコミュニティ的な組織について実験・研究をしているのですが、色々試してみて、「偏愛」と「弱み」でつながるワークなどがけっこう役に立つ手応えを得ています。

collaborateが起こりやすくするためには、上述のとおり、いかにメンバーそれぞれの異なるベクトルを引き出すか、が大事です。

「偏愛」のワークというのは、その名のとおりで、メンバー間で自分のフェチや推しなどといった「偏愛」をプレゼンし合う、というワークです。これをすると仕事上では知らなかった意外な一面が見えますし、そこから互いの価値観をなんとなく共有することができます。「偏愛ワーク」のいいところはすべてロジカルには説明仕切れないことで、それによって言語を超えた価値観が共有できますし、お互いに完全には一致できない価値観がある、ということを体感することができます。

「弱み」のワークは、メンバーがそれぞれ弱点や苦手なこと、直せないことや欠点などを書き出すワークです。それぞれに書き出してもらった後、あえて「弱さ」だけを組み合わせてチームを考えてもらったりもします。

チームビルディングというと、ストレングスファインダーなどを使って「強み」を出し合うワークはけっこうされることがあると思うのですが、「強み」だとどうしてもセルフブランディングやタテマエが入り、メンバーの本心や個性が出てきにくいことがあります（Formingっぽくなる）。「弱さ」を見せ合うことで「様子見」から一歩踏み込み、チームの受容性があがります。いわば擬似的にstormingを起こしている感じかもしれません。

「偏愛」や「弱み」を見せ合うことは平均値ではないお互いのでっぱりや凹み、つっまりお互いのいびつさを見せ合う、ということでもあります。

こうしてメンバーそれぞれのいびつさが見えているチームではメンバー間のつながりは増し、目的や役割分担が明確だけれども「責任分界点」みたいな話が出るドライな「機械的組織」ではなく、collaborativeに適応課題も乗り越えていける、セーフティーネット的な有機的な「生体的組織」になることができるのではないでしょうか。