チームビルティングを、タックマンモデルに沿って振り返る

はじめに

note初投稿です。はじめまして、b_bと申します。執筆時点で37歳二児の父親です。１０代の頃からおっさん顔と呼ばれた半生でしたが、今は正真正銘のおっさんです。
本記事は「Ateam Group Manager ＆ Specialist Advent Calendar 2020」と題しまして、執筆時現在わたしが所属するエイチームグループのエンジニア/デザイナーのマネジャー/スペシャリスト達によるアドベントカレンダー向けの記事となります。わたしは12日目、ほぼ中間地点ですね。頑張ります。

わたしは株式会社エイチームライフスタイルで、エンジニア/デザイナー組織のマネージャーとして１０数名のメンバーと日々仕事をしております。本業はエンジニアですが、意識低い/こじらせ系の若手時代でウロウロと一貫性のないキャリアを重ねており、当社のエンジニア陣の優秀さには日々頭が上がりません。土下座する勢いです。お世話になります。

タイトルに「チームビルディング」があるので、おそらくそれに類するミッションに取り組んでおられる皆様（その多くは「マネージャー」や「〜リーダー」といった役割を戴いている方だとお見受けします。いつもご苦労様です）は嗅覚が働いたのではないでしょうか？
ご期待通りの文脈かわかりませんが、わたしが普段行なっているチームビルディングの実例や、その背景にある考えをお話します。

なお今回の言語化に際して、タックマンモデルで示されている５つのステージに沿ってお話していきます。こういった学術的視点に照らして自身の取り組みに自信を持つことができたのは、今回の収穫でもありました。さも初めから、わたしのことを様々な知識体系に基づいた確信的なチームビルディングを粛々と進めてきた"やり手"として見ていただくのではなく、"失敗を何度もしながらも、チームビルディングに何度も取り組んできたどこにでもいるチームリーダー/マネージャーの話"として、これからの話にお付き合いいただけると幸いです。

それでは、よろしくお願いいたします。

STEP1. 形成期において

ある目的の元にチームが組織された、あるいはプロジェクトの立て直しのために元々組織されたチームにわたしが招聘された時、どちらの場合も最初に行うべきは「ゴールの設定」です。

チームは全て、何らかの目的を達成する（し続ける）ために存在します。決して会社がそう決めたから集合しただけの集団ではなく、そこにいる全員が一丸で達成すべき同じゴールを潜在的に共有していることがほとんどです。

潜在的にそこにあるゴールは、メンバー全員の目に等しく「そこにある」とは限りません。回りくどい儀式的なものだとしても、リーダーがキックオフの場を設け、ここにおいてゴールの共有をすることはとても重要です。何故ならば、多くの場合相互理解が進んでおらず信頼の土壌ができていない形成期のチームにおいて、彼らのモチベーションの拠り所はチームの目的そのものが一番大きいものだからです。どんな人間たちか期待も不安もある中で、皆が一つの目的の元に集った同志であると言う確認のプロセスは、この段階のチームが一丸となる原動力をつくるからです。

その上で、チームメンバー全員の相互理解を早急に深めて行きます。
この段においては、もちろんわたしと各メンバーの相互理解も早急に深める必要があります。チーム発足からチームが自律的に機能し始めるまでの初期〜中期の段階においては、リーダーである自分の推進力が要となるからです。わたしは多くの場合、形成期の最初期（場合によってはキックオフにも先駆けて）にメンバーとの1on1を実施します。

とはいえ、わたし自身への理解を焦って求めるがあまり、メンバーの話を聞くよりわたし自身の話ばかりしては上手くありません。自分への理解を求めるのであれば、まず相手の理解をわたしが先駆けて深める必要があるからです。

メンバー一人一人の理解が進むと、自然とこのチームの特性も見えてきます。優しい人、クールな人、ロジカルな人、情熱的な人、、。「あまりよく知らない人の集合」から、一人一人のキャラクターが明らかになり、チームのカラーが見えてきます。

チームワークのコツは、全てのメンバーの、ニッチでも良いので”得意なこと”と”苦手なこと”を正しく理解し、他のメンバーの特性を噛み合わせることです。つい、全般においてのスペシャリストと全般においてのアソシエイト、、などのようにチーム内に一方的な師弟関係や主従関係を想像してしまいがちかもしれませんが、全てのメンバーから必ずギブ＆テイクの両方のベクトルの矢印が伸びるようなイメージ（ここではリーダーである自分も当然含みます。わたしは過去全てのチームにおいて全能だったことがありません）を描きます。

若手や、入社以来あまりパフォーマンスが出せず自身喪失しているメンバーの多くは、自身の長所は「何もない」と卑下し、短所ばかりを口にします。そんな時には、苦手なことを言語化できた反語として「苦手ではないこと」に気づいてもらうようにします。極論、チームのムードメーカーとして、発信者へ対するリアクションや、ミーティングのアジェンダ取りまとめやタイムキーパーを買って出るなどの”特別な能力は必要としないが、汗をかく”ことは誰にでも可能だし、だからこそあなたを必要としているのだと言うことを説きます。

チームワークの本質は「ギブ＆テイクを通して、ファインプレーを生み出す機会を最大化する」ことにあると言っても過言でないと思います。「小さくても大したことなくても良いので、テイクされるだけでなく自身が何かギブをチームに返す」ことをそのメンバーに説きます。一方的なギバー（Giver）もテイカー（Taker）も、チームが混乱期を迎えた際の火種になる典型的な存在です。この段階では、実態としてギブ＆テイクが成立していなくても（実際のところ、チームの初期段階で全メンバー間におけるギブ＆テイクが必要十分に成立することはほとんどありません）メンバー全員の意識下にギブ＆テイクの要求を植え付けることを意識して対話します。

リーダーであるわたしがメンバーを理解した側から、メンバー間の関わりも機会づくりをしていきます。チーム形成初期こそ、定例ミーティングや、チャットコミュニケーションが活発になる仕掛けをリーダーが率先して起こしていきます。理解が進んだメンバーの姿について、積極的にそれを他のチームメンバーの耳に入れていきます。

チームは、メンバー間の相互理解を待つことなく、チームの目標（ゴール）に向けて動き出していきます。探りさぐりながら、リーダーの理解やメンバー協議の元で役割分担が生まれ動き出していきます。
その中で、何一つ問題に直面する事なく終結を迎えることはまずありません。チーム醸成の過程で、次に解説する混乱期は必ず訪れます。

STEP2. 混乱期において

「自分たちのチームはうまく言っていない」と自覚がある場合、そのほとんどのケースがこの段階にいます。この段階において、自然に混乱が収まり次の段階である統一期へ移行できることはまずありません。放っておけば、チームはこの状態のまま活動を継続することになり、プロジェクトそのものが不完全燃焼のまま終了を迎えるか、場合によっては終了を迎える前からメンバーの退職が相次ぐなど取り返しのつかない事態すら起こり得ます（わたし自身の経験でもありました。マネージャーとして大変に不甲斐ない経験で、結果として退職してしまったメンバーも、残って引き続き支えてくれたメンバーにも、等しく大変な苦労をかけてしまいました。後述します）。混乱期は必ず迎えるもので、ここをいかに早期に脱出できるか、リーダーとしてこのフェーズが最も腕の見せ所と言えるかもしれません。

混乱期におけるチームの概況は大きく分けて３つに分けられます。「バチバチ/ネチネチと揉めている」か「シラけている/無関心なメンバーが多数」かです。

どちらのケースにおいても、チーム全体で討議すべき問題の整理と掘り下げに全員の目を向けることが鉄則です。混乱期にかかるストレスを、ほとんどの人間は別の人間に転嫁します。その矛先は、リーダーであるわたし自身であることも多いですし、アサインされた業務で要するスキルに乏しいメンバー／非協力的（と他のメンバーが主張する）なメンバーにもなり得ます。

リーダーであるわたし自身の問題であるケース、多くは戦略や戦術のエラーが明るみになっています。戦略や戦術の意思決定がわたしで完結している場合、早急にエラーの原因を分析し、事後策を打ちます。さらに上位レイヤーにおける意思決定が必要な場合、リーダーとして責任を持って事態の解決に動くとともに、事実情報を収集するにあたってメンバーにも役割分担を行い協力して解決に向かいます。

ある業務をアサインしたメンバーが、その業務を遂行する上で要する知識や技術力が不足していることで、進捗が遅れたり、成果物の品質に疑義が発生しているケースもあります。

ここで肝要なのは、ほとんどの複雑な課題を孕むプロセスにおいて一人の人間の知識や技術力のみで最適解を伴っての完結に至れるケースは非常に稀だという原理原則です。なので、主担当メンバーがミスマッチであるという原因と、必要十分なチーム内外からの知見を求める、、というプロセス剥離の原因など、いくつかの定型パターンに照らしながら検証していきます。

前者の原因に対しては、当該問題の単独ケースにおいては、主担当メンバーの交代が相応しいように思えるでしょう。ただし、チームで取り組む業務においては、有識者ほど初期段階でそもそも重要なタスクにアサインされがちである、という法則を忘れてはいけません。メンバAとBにアサインしたタスクの所要スキル適性がたまたまAとBで逆になっているケースでは、タスクの交換で最適解が導き出せますが、どちらのタスクも戦力としてはAが優勢である場合、Aをアサインすべきはどちらのタスクが妥当解か？の観点で、比較検討する必要があります。

後者の原因については、そもそもアサインされたメンバーがなぜ周囲への支援を十分に得られなかったか？その掘り下げが必要です。
支援のリクエストを飛ばさなかったのか、飛ばしたが誰もボールを受け取ってくれなかったのか？リクエストはチーム外にも飛ばしたか？チーム外のどこにリクエストを飛ばすかの助言をするに足る有識者がいなかったか？その有識者が助言できなかったとするならそれはなぜか？
仮定の話であればいくらでも想像することが可能です。その想像の一つ一つについて、関係者と密に振り返りをすることで、問題箇所の仮説を立て、仮説に対して事実関係を分析し、改善施策を実行します。
仮説と施策は、必ずチームにオープンにアナウンスします。類似のケースで何度も仮説立てをゼロベースで行うより、局所のエラーを集合知にしていくことはチームの初期段階ほど意識して行うのが効果的です。

また、対立やリーダーへの反発が表立っていれば、ストレスフルながら解決に向けて動き出せば良いだけですが、問題がわかりやすく表面化せず澱のように沈殿しているケースもあります。
チームのミーティングで、報告に対して特段の指摘も起こらず、意思決定について意義の声は上がらず、、。一見問題なく進行しそうに見えて、進捗が芳しくなかったり取り決めたはずの業務ルールが守られなかったりといったうまく噛み合っていないようなケースです。

こういったケースの多くでは、一部（少数派でも大多数でも）のメンバーにおける無関心が根底にあります。和をもって尊しとなす国民性なのかわかりませんが、現実には停滞しているチームの多くがこちらの状態で、問題が表面化するケースはむしろ健全な議論をしやすい土壌があるか、かなり手遅れな状態かです。

もっと身も蓋もないケースでは、自戒を込めて言いますが、リーダー自身がその無関心状態の一端を担ってしまっています。自分のことは意外に自分が最も無頓着です。メンバーから率直な意見をもらえる関係性を築くのと同時に、その兆しを謙虚に察知するよう心がけます。

自分以外のメンバーが生み出す成果へ明確に関心をもつ雰囲気は、強いチームにおいて数少ない必須要件です。無関心が招く問題は早期に察知し、表面上の問題が起こっていないからと後回しにせず、チームメンバーになぜそれが必要なのかを繰り返し説きながら、確実にチームの文化として行きます。

混乱期の脱出は、問題の早期発見と解決が再現性をもってできるかが大きな分かれ目になります。そのための仕組みとして、定例ミーティングの目的設計と運営指針を取り決めます。

ほとんどの場合で設置するのは日次の短時間ミーティングです。当日の業務開始にあたっての懸念事項を相談するリズム作りのためにも朝会が多く選ばれます。15〜30分程度で、リクエストや相談、皆に目をかけてほしい当日のタスク予定を報告すると共に、継続的にメンバ間相互理解を深めるため、自己開示コンテンツや技術共有などを持ち回りで実施するのも有効です。発言や発信が相対的に少なめのメンバーは、率先して発言を促したりすることで、相互理解のムラ解消にも配慮します。

問題の発見は、直面したメンバーが遠慮や恐れを抱くことなく迅速にチームへ周知相談する機会づくりがこの段階では必要です。とはいえ、問題の本質をついた整理されたレポートを全メンバーが満足にできないことも多いですが、この時点では十分に整理されていなくても良いし、事実か解釈かの切り分けもされていなくて良いものとするのが良いでしょう。問題の本質を掴み取るためには、じっくりと調査や議論を深める機会が必要ですので、まずは”問題の兆し”を敏感に察知できれば、日次の定例ミーティングの目的は達成と言えます。

問題の解決は、週次での定例ミーティングなどが有効です。問題の発生頻度や粒度など、チームのミッション特性によって開催頻度はアレンジすれば良いでしょう。討議したい議題を事前に募り、アジェンダを開催日時に先駆けてメンバー展開し、十分な議論が可能な状態で臨むとより効果的です。
また、モグラ叩きのようにトラブルシュートするばかりではなく、チームの連携をより良くするための課題発見の場として、この場を活用できれば尚良しです。定期的にチームの動きを振り返ることで、自律的にチームをアップデートする文化がチームに根付いていきます。

振り返りの形式は様々な手法があるでしょうが、わたしが関わるチームではKPTの形式で振り返りを行うことが多く、経験上効果的です。
当週（定例間のスパンに読み替えてください）に取り組んだことや発見した、「継続して発現させたい動き」がK(Keep)です。良い動きが、偶然やその当事者の気まぐれ（だとしても、良いものは良いのです）に依存することなく、チームが再現性をもって実行できるよう、言語化して記録します。
反対に、起こった問題がP(Problem)です。朝会等で報告されたProblemのうち、緊急性/深刻度の高いものは早急に取り組む一方、チームの討議に要する期間を許容できる場合は積極的にこのテーブルに挙げます。
そして、Problemに挙がった問題の本質を追求しつつ、改善策としてT(Try)を取り決めます。このTryを振り返りミーティング終了後、各メンバーが取り組むことでチームワークが上方修正され得ます。

チーム全体から、問題や課題の種が積極的に報告され、チーム全員で改善のための議論を起こすこと。それらが、繰り返し継続的に行われるよう、問題に向き合う仕組みを作っていくことで、チームの混乱期を徐々に抜け出していきます。​

混乱期は必ずどのチームにも訪れます。この段階は一度乗り越えても、再度チームの状態が巻き戻ってしまうことも多々あります。乗り越える上で、そのチームにとって再現性のある解決方法を初期段階で見極めておくことは、チーム成熟度を上げていく上で大変に重要なプロセスです。リーダーとして事態の収束を図るべく「おれの責任で、この件はこうする。何故ならば（理由）だからだ」とトップダウンで決めきることも時には効果的ですが、メンバーと（ここではあえて、必ずメンバー全員でなくとも良く、その議論において効果的なメンバー選出しても良い、、と補足しておきます）ともに考え意思決定していくことで、チームワークの改善の文化をチームに芽生えさせることができます。

「チームワーク改善の文化」これこそが、強いチームが備えている性質です。だからこそ、チームの混乱期は強いチームを作るために必要なステージです。事態に対峙した時、リーダー誰しも人間ですからげんなりしてしまうかもしれませんが、実はこの状態こそがチームワーク醸成の最大のチャンスであると理解できると、チームビルディングがとてもやり甲斐のある仕事に見えてくるはずです。

わたしの過去の失敗経験を取り上げます。
わたしの前職において、わたしは「マネジメントはまるで”喧嘩の仲裁だ”」などと大変に歪んだ意識で
マネジメントに取り組むことが心底嫌になってしまった時期がありました。

事実として、当時の期間（プロジェクト炎上中、と解釈ください）において、ほぼ毎日
誰かの怒りの感情に対してのケアを
「宥める」「その場限りで徒党を組む」「当事者たちを会議室に連れていき数時間にわたって話を聞く」
。。といった、場当たり的な対応しか取れていませんでした。

当時のわたしは、目の前にいる人間の信頼を失うこと/怒りの矛先が自分に向かうことを恐れ、
その時々の問題の本質に、当事者たちと一緒に向き合う、、という
一番大切なことが満足にできていませんでした。

誤解を招かないよう添えれば、
問題に向き合うこと＝リーダーとしてメンバーを叱ったり指導しない
。。という訳ではありません。むしろ逆で、
問題に真正面から向き合う姿勢があればこそ、リーダーはメンバーの感情をよりダイレクトにぶつけられても
必要であれば、メンバーに対して強く要求をしたり指導することになります。

わたしの失敗は、問題の兆しを察知すること／問題解決の渦中に入ることそのものを、
出来るだけ避けて通っていたこと（問題から逃げ回っていたこと）
これに尽きると、深く反省しています。

STEP3. 統一期において

混乱期にチームがあるとき、いくら必要なプロセスであると言っても、やはりチームの中でいくばくかの違和感やストレスを感じ続けます。

ところが徐々に、チームの振り返りや相互の連携が増えてくるに従い、チームにいて仕事をすることで喜びを感じる瞬間が多くなってくることに気づきます。各人のストレス耐性にもよるのでしょうが、その辺がごく一般的な感覚である自覚のあるわたしは、ある時まで出勤する足取りが重かったはずが、気づくと軽やかになっていることに気づきます。

この辺りの感覚に覚えが出始めれば、苦しかった混乱期の脱却です。チームは一段階前進しました。

混乱期において、前項で「対立や混乱を、人間ではなく問題そのものに向き合う」という原則について書きましたが、まさにこの統一期においては、チームが”問題と向き合う”ことを原則として定着した状態にあります。

いくつかの問題解決を、チームの力で乗り越えることができたことで、チームメンバーの間には相互の感謝や尊敬の念が高まっていることと思います。チームメンバー間で信頼関係が高まってきています。

とは言え、混乱期と統一期は表裏一体です。全てのメンバーが等しく問題に向き合うスタンスを手に入れ、チームのカルチャーとして浸透しているかはまだ注意深く観察を続ける必要があります。

リーダーとしては、チームの状態が良いステージにきたことを繰り返し発信します。チームメンバーにチームの状態変化をポジティブに意識してもらうと共に、ここにきて自身の振る舞いに違和感を抱くメンバーがいないか、周囲とのギャップを鮮明にして観察する必要があるからです。

この段において混乱期への巻き戻りを防ぐためにも1on1等でメンバーから発せられるメッセージに、より注意深く耳を傾けます。捉え方が違うのが人間、当然のことです。この時点で違和感を感じるメンバーを悪とはせず、未だカルチャーギャップを感じているのは何故なのか、本人の理解をさらに進めつつ、チームにより深く参画してもらうための道を探ります。

また、問題解決の議論を円滑に進めるためにも、混乱期までの段においてはリーダーである自身が重要な議論のファシリテートを意識して務めるようにしていますが、このステージに到達した後は、徐々にメンバーにその役割を譲っていくようにします。より自主的にチームをアップデートできるよう、意識だけではなく技術としても手に入れてもらうためです。

このステージで最も意識して行うのは、チームのポジティブな変化について、出来るだけ具体的に言語化し、チーム内外に向けてメッセージを発信することです。
雰囲気ではなく、具体的な変化点をリーダーが言葉にすることは、メンバーが自分たちの取り組みについて、自信を深め、よりよくしようというモチベーションに繋がる重要な儀式です。
わたしはこの重要なプロセスにおいて、絶対に照れずに、賞賛は全力でエモく行う、、ということを意識しています。感受性は人それぞれとは言え、賞賛を嬉しく思わない人間は最終的には存在しません。伝わらなければ損だからです。

STEP4. 機能期において

メンバー同士の衝突がなく、個々の自立性が高い状態。
非常に理想的な段階です。

この段階までチームが成熟した場合、マネージャー／リーダーとしては非常に感慨深く、頻繁に感動すら覚えます。

問題が発生しないチームなどあり得ませんが、問題は即座にチームメンバーが能動的に察知し、改善に向けて自主的な議論と取り組みが行われます。
メンバーの帰属意識は最大限に高まり、結成当初のモチベーションの拠り所であったゴールの存在に加え、そのチームに所属し貢献できていることそのものがチームメンバー一人一人にとっての動機になります。所属することに喜びを感じ、感謝の言葉が溢れ、ゴールの早期／効果最大限の達成に全力を注ぐチームです。

この段に至って、わたしの経験上では贅沢な悩みながら一定の孤独感を感じることがあります。リーダーがリーダーたる振る舞いをもってチームワークの醸成に貢献することこそがそれまでの自身の存在意義であったために、その実感を感じにくくなることから、自身の存在意義に疑義が生じてしまうことがあります。

しかし、この状態を恐れることはありません。チームの状態に対する気配りを最小限（ゼロにはなりませんし、してはいけません。いかなる段階にあっても、チームの状態が後退することは起こり得ます）にしても差し支えない状態になることで、リーダーとして本来の目的であるゴールの達成に、自身もまた全身全霊で向き合える時が来ているからです。
自身もまた、ある種のスペシャリストとして自己実現に邁進することも選択できれば、マネージャーとしてよりメンバーの成長にコミットメントすることで、チーム力の最大化とともにマネージャーとしての介在価値の最大化を追求することもできます。

この段においては、リーダー／マネージャーが本来なすべきことも積極的にメンバーにボールを渡すよう心がけます。
チームとして派生したサブプロジェクトの企画／発足や、戦略策定すらも、メンバーの成長機会とみなしてどんどん渡していきます。

永久に存続するチームもまた存在しません。チームの目的達成と共に解散するか、さらに上位レイヤの全体最適視点で、メンバーの入れ替わりも起こり得ます。このチームでチームワークの最大化に貢献してくれた頼もしいチームメンバーが、また新たなチームにおいて、チームワークの最大化を担うキーマンとして活躍できるよう、自身が渡せるノウハウや引き継いで欲しい志を惜しみなくメンバーに伝えていきます。メンバーのフォローも状況を見ながら行いつつ、彼らが次の舞台でより高い視座に立って活躍できるような支援をしていくことになります。

”今”のチームが理想の形になった時に、リーダーが率先して”未来”のためにチームメンバーを育成すること。それこそが、この段において唯一のリーダーのミッションと言えるかもしれません。

STEP5. 散会期において

有期性のあるプロジェクトであればどこかでチームの解散が訪れるでしょうし、前述の通りチームメンバーの入れ替わりは様々なポジティブな理由において起こり得るもので、この一つ一つの送り出しの場面もまた、チームにとって小さな散会期のステージと言えるかもしれません。

個別に送り出すメンバーや、チーム解散と共に自身もまた、次なるチームにおいて今回の学びを生かしてさらなるパフォーマンスを発揮すべく、振り返りを行なっていきます。

当社においてプロジェクトを終結するときは、成功しても失敗しても、必ず振り返りは行います。独自性の強いプロジェクトチームという単位では、ほとんどの場合でそのプロジェクトにおける独自の学びや反省があります。これをその場限りのものとしてスルーするのではなく、自分たちの経験として蓄積していくために、振り返りは非常に重要な取り組みであると言えます。

さいごに

３０代になって、マネージャーやリーダーというタイトルの役割を主として担うことがほとんどでした。その駆け出しの頃においては、同一の入力があれば必ず（と言っていいほど）同じ出力が返ってくるエンジニアリングの世界と比べて、人や組織の不安定さを”理不尽”と捉えて、周囲の人間の信頼を損ねたり、必ず起こりうる問題に怯えながら、自らの役割から逃げたくなる毎日でした。
しかし、成功体験はもちろんのこと、失敗体験もそれが糧となりその後の成功に繋がる経験を積めたことで、役割や責任を担うことでの喜びは年々大きくなる一方です。

わたしよりも経験豊富なリーダー／マネージャーの皆様の目にこの記事が触れる機会がどれほどあるか分かりませんが、稚拙な点などありましたら、いつかのご自分の事を思い返して温かく見守っていただければ幸いです。（わたしの見識に何か明確な誤りなどありましたら、ご指摘ください）

そして、何かの縁あってこの記事に触れた駆け出しのリーダー／マネージャーの皆様、明示的にリーダーたる役割を拝命しておらずどもチームワークに悩める皆様にとって、何らかのヒントや勇気に繋がっていれば幸いです。

最後に、これまでのわたしのキャリアの中で、何度もマネジメントに失敗し悩んでいた中で、叱咤激励いただきながらもチャンスを与え続けてくださった関係者の皆さまへの謝辞をもって、締めの言葉とさせていただきます。
これまでありがとうございました。これからもよろしくお願いいたします。

追伸

冒頭に記載の通り、本記事は「Ateam Group Manager ＆ Specialist Advent Calendar 2020」の12日目の記事として執筆しました。アドベントカレンダーは明日以降もまだまだ続きます。引き続きお楽しみください。